予算ブレの原因

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

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

3つの壁とは

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

失敗を防ぐ視点

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

成功する会社の共通点

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

まとめ

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

内製化の壁

システムの内製化が重要ということは、どこでも聞くと思う。しかし、具体的に内製化していくための段取りを整理して教えてもらうのは難しいのかもしれない。業種業態によって様々なケースが存在するからである。内製化を成功させるには、単に技術的な知識だけでなく、組織全体での戦略的な取り組みが不可欠となる。

経営コミット

システム開発の内製化を行っていくには、まず経営層からのコミットメントが必要不可欠である。これが必要であるから諸外国ではCRO（Chief-Revenue-Officer）という部門を横断した権限を持つ人を据えている。その上で、まず内製化の目的を明確にする。おおむねコスト削減、スピード向上、ナレッジ蓄積などであろう。目的がきまると、企画、開発、保守、インフラなどのどの範囲で内製化するのが見えてくる。組織全体での合意形成が内製化成功の基盤となるのである。

失敗回避策

よく聞く失敗例では、権限のないIT戦略室、デジタル推進部などを作ってしまうことである。あるいは、適切な人員の配置や育成がなされないパターンも同様である。大きな権限を持つことになることを前提に考えると、実施するプロジェクトについても小さなプロジェクトにおいて実績を積み上げたほうがいいだろう。たとえば、小規模低リスクである業務改善ツール（例：Power AppsやExcelマクロ）から市民開発を実施していくなどを計画することをお勧めする。段階的なアプローチが組織の信頼獲得につながる。

仕組み化

小さなプロジェクトで実績を積むと、こなれてきてしまうため、やはり属人化の危険性が伴う。ここで、いかに永続的に考えることができるか、内製化のための仕組みを構築できるかは、システム開発経験者などの知見のある人も交えて人材育成に取り組むべきである。定期的な振り返り（レトロスペクティブ）やナレッジ共有会、現場からの改善提案を吸い上げる文化を育て、仕組化していく。持続可能な内製化には組織文化の変革が欠かせない。

まとめ

開発基盤とガバナンス整備、ソース管理やドキュメント管理などの定性的な内製化は簡単に作ることができる。しかし、そのマインドや仕組み、自然とDevOpsをはじめとしたPDCAサイクルにもっていくには、システム知見だけでも難しくある。持続的な内製化にたどり着くためには最初の企画や構成段階で知見をもつメンバーを入れておくのがよいだろう。

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか？
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか？
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。