日本の技術人材不足とオフショア開発

導入しても使われない現実

Power Appsを導入したものの、ほとんど使われないまま放置されている中小企業は少なくない。ローコードツールは「誰でも簡単にアプリが作れる」と紹介されがちだが、実際にはうまくいかないケースが多いのが現状だ。問題はツール自体ではなく、導入する会社側の準備や進め方にある。失敗する会社にはいくつかの共通した特徴がある。

3つの壁とは

Power Apps導入が失敗する会社には、大きく3つの壁がある。1つ目は「使いこなせない」壁だ。操作方法を十分に学ぶ機会がないまま、現場にツールだけが渡されるケースである。2つ目は「現場に定着しない」壁。初期の熱量が冷め、結局Excelに戻ってしまうパターンだ。3つ目は「サポートがない」壁。導入後に困っても相談先がなく、改善が止まってしまう。これらは個人の能力の問題ではなく、組織としての支援体制の欠如が原因である。

失敗を防ぐ視点

これらの壁を乗り越えるには、「ツールを入れて終わり」ではなく、組織として仕組みを整えることが必要だ。まず教育面では、操作研修だけでなく「どの業務に使うか」を一緒に考える伴走型の支援が有効である。定着面では、小さな成功体験を積み重ねることが重要になる。最初から大きなアプリを作るのではなく、日報や申請書など身近な業務から始めると、現場の抵抗感が薄れる。そしてサポート面では、困ったときにすぐ聞ける相談窓口があるだけで、改善のサイクルが回り始める。失敗は、正しい準備で防ぐことができるのだ。

成功する会社の共通点

成功している会社に共通しているのは、「教育・定着・サポート」の3つを同時に整えている点だ。どれか1つが欠けても、現場は元のやり方に戻ってしまう。自社だけで全てを整えるのが難しい場合は、外部の伴走支援を活用するのも有効な手段である。特にPower Appsの導入では、最初の設計段階で専門家の知見を借りることで、手戻りを大幅に減らせる。「一度失敗したから」と諦めるのではなく、やり方を変えれば成果は出せる。まずは自社の課題がどの壁に当てはまるか、整理するところから始めてみてほしい。

まとめ

Power Apps導入の失敗には「使いこなせない」「定着しない」「サポートがない」の3つの壁がある。いずれも個人ではなく組織の問題であり、仕組みで解決できる。教育・定着・サポートを同時に整えることが、成功への近道だ。

DX着手の課題

「DXを進めたいが、何から手をつければいいかわからない」。多くの中小企業がこの悩みを抱えている。実際、DXに取り組みたいと考えながらも着手できていない企業は約7割にも上るというデータがある。人材不足、予算の制約、そして「失敗したくない」という不安が足かせとなり、一歩を踏み出せずにいるのだ。DX成功の鍵は、最初の一歩をどこから始めるかにかかっている。

優先順位の決定法

DXの第一歩は「業務の棚卸し」から始まる。まず自社のすべての業務を書き出し、どこに無駄や非効率があるかを可視化する。次に、各業務について「改善効果の大きさ」と「導入の難易度」の2軸で評価する。効果が大きく難易度が低い業務こそ、最優先で取り組むべき領域である。たとえば、紙ベースの勤怠管理、手作業での請求書発行、属人化した顧客情報管理などは、比較的着手しやすく効果も実感しやすい分野といえる。重要なのは経営課題と紐づけて考えること。売上向上なのか、コスト削減なのか、目的を明確にすることで優先順位が定まる。

スモールスタートの原則

DX推進で最も重要な考え方が「スモールスタート」である。いきなり全社的な大規模システムを導入しようとすると、多大なコストと時間がかかり、途中で頓挫するリスクが高まる。まずは1つの部署、1つの業務から小さく始めるべきだ。たとえば、営業部門の顧客管理をクラウド化する、経理部門の請求書をデジタル化するといった身近なところからで十分である。小さな成功体験を積み重ねることで、社員のDXへの理解と協力が得られやすくなる。ある建設会社では、現場写真の共有をクラウド化しただけで、1日あたり1時間以上の工数削減に成功した。「まずやってみる」という姿勢が、DX成功への近道なのである。

経営者主導の重要性

DXを成功させるには、経営者自身が旗振り役となることが不可欠である。「現場任せ」「担当者任せ」では、部門間の壁や既存業務への抵抗に阻まれ、改革は頓挫してしまう。経営者がDXの目的とビジョンを社内に発信し続けることで、組織全体の意識が変わる。また、導入後の定着も見据えた計画が重要だ。新しいツールを入れただけでは、誰も使わなくなってしまう事例は少なくない。操作研修の実施、マニュアルの整備、成功事例の社内共有など、継続的なフォロー体制を構築すべきである。DXは一度きりのプロジェクトではなく、継続的な改善活動だ。PDCAを回しながら少しずつ変革を広げていく姿勢が求められる。

まとめ

DXは「どこから始めるか」で成否が分かれる。業務の棚卸しで課題を可視化し、効果と難易度から優先順位を決め、スモールスタートで成功体験を積む。この流れを意識することが重要である。経営者が主導し、全社一丸となって取り組むことで、着実にDXは前進する。最初の一歩を踏み出すことが、企業変革への大きな第一歩となるのだ。

開発手法の選択基準

大がかりなシステム開発においては、ウォーターフォールモデルという開発手法がとられ、設計書などのドキュメント類も整理してから、プログラミングへ着手する。逆に中小規模なシステム開発においては、アジャイル開発と呼ばれ、プログラミングをしながらシステム開発が進められたり、ドキュメント類は簡易にして、プログラミング工程へ着手するといった方法がとられる。状況に応じて開発手法は使い分ける必要がある。

設計書の必要と課題

建築では図面なく建物を建てることはないが、中小規模のシステムについては簡単な概要だけでシステムの開発ができてしまう。もちろん設計書をしっかりと書いて、要件を詰めてシステム開発を進めることができれば、トラブルもなくていいのではないかと言われる。しかし、設計書を作成するにはシステムをプログラミングすることと同じくらい費用が掛かる。

設計書の粒度と要因

中小規模のシステム開発において設計書が簡易になってしまう理由は、ユーザー側や発注側の予算が乏しいという理由がある。建築のパターンの場合は、法律によって作成しなければならない図面や、施主から同意をもらうべき書類などが決められている。システム開発には法的に作成しなければならない書類が明確にされているわけではないため、この粒度が各社・各エンジニアによりバラツキが発生する。

文書管理の現状

中小規模のシステム開発において、最悪の場合は設計書がないケースもある。小さなプロジェクトの場合は予算も少なく特にドキュメント類がないが多くある。あるいは、システムはアップデートされ続けているのにドキュメントはアップデートされていなかったり、ひどい場合にはシステム保守ベンダーが紛失している場合もある。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われる。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかる。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がる。つまり、非エンジニアが単純に開発費用を値切ると、プログラミング以外の重要な情報を削っていくことになる。