開発の相場

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。

内製化の壁

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

経営コミット

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

失敗回避策

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

仕組み化

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

まとめ

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

効果検証から始める

多くの人は、試しにAIを導入してみて、効果を見てから予算取りを行っていきたいと考えている。とりあえずツールを導入したいといった理由では、なかなか費用を使っていいとはならないだろう。このような慎重なアプローチは非常に理にかなっており、実際の効果を数値で示すことができれば、その後の本格的な導入に向けた予算確保もスムーズに進むはずだ。まずは小さく始めて、確実な成果を積み重ねることが重要になってくる。

UI重視の効果測定

AIの効果を確認してから検討することを考えたときに最初にやることは、実はUI（ユーザーインターフェース）の部分である。例えば、グラフの表示などだ。結果として何ができれば、どういった業務がどれくらい短縮されるのかを第三者が見ても確認しやすいからだ。データの可視化により、AI導入前後の変化を明確に示すことができれば、関係者全員が効果を実感できる。特に経営陣への報告時には、視覚的に分かりやすい資料があることで、プロジェクトの価値を効果的に伝えることが可能になる。

開発とAIの分離問題

UIを作るとなると、結局はシステムの開発が必要になってしまうのではないかという懸念が生まれる。あるいは、システム開発を行うことで、そもそも期待したAIの活用がなされなくなってしまったりすることもあるだろう。これは、目的をシステム開発とAIとに分けているからだ。本来であればAI活用による業務改善が目標であったにも関わらず、システム開発が主目的となってしまい、AI機能が後回しになってしまうケースも少なくない。このような本末転倒を避けるためには、プロジェクトの優先順位を明確にすることが不可欠だ。

統合的アプローチの重要性

AIはAIの会社に発注する、UIはシステム開発会社に発注するといった、区分けをしてしまうことに誤りがある。まず、やるべきことを分解するのではなく、ITに対する知見のある人に区分けから入ってもらい、技術的な判断も行いつつKPIを作っていくことが重要になる。これは市民開発と呼ばれるものに近く、自社内でローコードを使って軽く開発することを意味する。技術的な専門知識を持つ人材が全体を俯瞰し、最適な技術選択とプロジェクト設計を行うことで、効率的かつ効果的なAI導入が実現できるのだ。

まとめ

部署やグループを横断した視点を持つことがとても大切であることがわかった。ツールや部分的な技術を目的としてしまう前に適した組織体であることの確認が大切だ。AI導入を成功させるためには、技術面だけでなく組織運営の観点からも準備を整える必要がある。