LIGのくまこと久松です。システム開発事業でマネージャーを担当しています。
いわゆるDXの一角でお仕事のご相談をいただくことが増えてきました。DXという言葉自体は様々なエッセンスを含んでいるのですが、なかでも「システム開発は内製でしましょう」というメッセージを含んでいる場合が多々あります。
一方でITエンジニアの採用は難しさを増すばかりです。採用を待っているといつまでもプロジェクトが始まらないので、社外リソースを調達することが現実解になります。
内製化するにせよ、社外リソースに依頼するにせよ失敗はつきものです。私も内製化、外注、そして受注する側を経験してきましたが、失敗したり炎上したりするプロジェクトには共通点が見られます。今回は私の実体験を踏まえたシステム開発の失敗理由と、注意点をお話します。
お客様から「何はなくとも内製化したい」「いつかは内製化したい」とよくお聞きします。ITエンジニア採用をして内製化するにしても、社外に受託開発や準委任契約を求めるにしても、ITエンジニアにものづくりを依頼する前に、明らかにしていなければならない事柄があります。
それらを明確にしていないとシステム開発は失敗するケースが多いです。外注と内製のそれぞれの失敗パターンを取り上げながら確認していきましょう。
目次
システム開発の失敗理由（外注編）
請負契約や準委任契約で外の企業にまとめて開発を依頼する形式です。
作りたいものがはっきりしていない
システムを実現することで解決したい課題は何でしょうか？ この課題設定がブレると途中で方針転換や仕様変更をしたくなります。下記のような項目が代表的な事象です。
- やりたいことは設定したが課題設定をしなかった
- 設定した課題が適切ではなかった、課題だと思っていたものが課題ではなかった
- 途中で課題が分からなくなった
- 途中で課題を変えた
ある程度の規模のプロジェクトであれば、コンサルタントを入れて課題設定をしておくと良いでしょう。第三者視点を入れることによって、プロジェクトの置かれた状況を見直すことも中長期的には有効です。
要件定義が甘い、あるいは伝えきれていない
作りたいもののイメージはどの程度まとまっているでしょうか？ よくあるパターンとして、漠然としたイメージを共有して開発者に渡したものの、何だかイメージと違うという現象があります。
解決したい課題は伝えた、画面のイメージを作っただけでは内製でも外注でも伝わりません。何のボタンを押せばどういう振る舞いになるのか、遷移先の画面に表示される文字は何を引っ張ってくるのか、計算式はどういったものなのか。こうしたITエンジニアに渡す直前までの要件の噛み砕きをしないとエスパー以外は開発成功には至りません。
途中で根本に繋がる大きな仕様変更をする
プロダクトオーナー（PO）が情熱的であればあるほど、自身のアイディアに対して「ここをこうすれば良いのではないか！？」と開発着手中の状態でもアイディアを反映したくなります。
設計段階である程度予見された変更であれば吸収できる可能性もありますが、開発中に抜本変更される内容はインパクトが大きいもの。
私の経験でいくと、あるFacebook API連携をするアプリで「友達の友達」を拾いたいという仕様を差し込まれたことがあります。友達までであれば多くても1,000名程度ですが、友達の友達は何名が対象になるでしょうか。
平均100名であっても1ユーザーにつき100名×100名で10,000名のデータを引き回さなければなりません。インフラでもプログラムでもデータベースでも想定していない要件だったため、実装期間もサービス品質も耐えられずに頓挫してしまいました。
金額が膨らむ
準備不足などにより結果的に開発費用が著しく膨らんでしまうこともあります。発注者側にシステムに詳しいメンバーがいないと、受注者に足元を見られることも。元は2,000万円程度でスタートしたシステム開発がトータルでは1億円を超えるケースもこれらが原因のことが多いです。
逆に発注者側が怒って不払いを言い渡す泥沼のケースもあります。こうしたやり取りが重なった結果、「内製化に限るね」となりがちです。しかし実際は「外注に不慣れ」というのが根本原因です。
コミュニケーション不足で、違うものができあがる
上司と部下のコミュニケーションで、10割完成してから見せるのより、1割できたところで方向性を確認したほうが良いというお話があります。これはシステム開発も同じです。少しずつできた範囲でレビューをするべきです。
これに関連してですが、インフラエンジニアとして一切アプリケーションログを出力しないシステムの面倒を見たことがあります。開発者に質問をすると「発注者に一切のログを見せないようにして欲しいと言われたため、すべての画面でログ出力を潰してしまった」とのこと。
察するに「一般ユーザーにシステムエラーなどのダイアログを出さないようにして欲しい」ということだったようです。このシステムについてはその後ログイン周りで問題が起きたのですが、全くログが出ないためにひたすら勘とログ出力の段階的追加で5営業日ほど頑張る羽目になってしまいました。
システム開発の失敗理由（内製化編）
正社員採用をし、自社内で開発を完結させる形式が内製化です。近年ではSES、派遣、フリーランス、副業人材なども含めた状態で広義の内製化というのが一般的になっています。
システム開発に詳しくない人による採用ミス
ITエンジニアの採用ミスは大きく分けて三つあります。
- スキルのミスマッチ
- スキルレベルのミスマッチ
- フェーズのミスマッチ
スキルのミスマッチは採用側の不慣れさにあります。実は古いシステムの実装経験しかなかった、キャッチアップできれば問題ないだろうと思ったなどといったものです。具体的には言語やフレームワークのバージョン、チーム開発などがありがちです。
また、エンジニア採用に不慣れだったり選考フローが整備されていないとスキルレベルを図ることも難しいです。入った現場の半数がプログラミングができないプログラマで構成されたチームを見たことがありますが、経営者が「ノリで入れた」「できそうな雰囲気だった」ということでした。
フェーズのミスマッチもよく聞きます。0→1フェーズのスタートアップに大手有名ベンチャー出身のCTOを入れたところ、開発ステップや採用に対するこだわりが強すぎて実装速度が落ちたお話をよく聞きます。事業フェーズ（0→1、1→10、10→100）に合わせた人材のアサインが必要です。
社内人員への依頼だということで要件定義に甘えがある
社内の人なので顔が見えるから安心、仕様はいつでも変えられると思っている方がおられます。
ひどいケースでは締切のない宿題のような形で、いつまでも仕様が纏まらずにグダグダになってしまうケースも。ユーザー部門Aは◯◯と言っている。でもユーザー部門Bは△△と言っている……これを繰り返して一向に要件定義が終わらないプロジェクトは内製の場合によく見かけられます。
サービスをローンチした後も、効果や優先順位を意識せずに「こうした方が使いやすいのでは？」と思いつきベースで改修を依頼し、収集がつかなくなっているプロジェクトも特に社内システムでありがちです。誰かしらが責任を持ってハンドリングし、仕様を詰める必要があります。
この際に指針となるのが先に出てきた課題設定です。課題に対して解決策に繋がるのか？ 費用対効果はどうなのか？ そうした要素を考えながら進める必要があります。
社員のエンゲージメントを管理しないと途中で転職する
現在の中途エンジニア採用シーンでは、ある程度のスキルがあるITエンジニアは引く手数多の状態です。フリーランスについても案件の多さや節税テクニックの充実っぷりからそれほど心理的ハードルの高いものではなくなりました。
つまり、よほどの残る理由がない限りは定着しないものだと想定して良いとさえ考えています。これが外注の場合、メンバーの補填や補償は契約ベースで先方責任にすることができますが、内製化した場合の正社員の転職による開発リソースの欠落は経営層から見て自己責任です。
継続的にエンゲージメントをしたり、1on1によって心境の変化を確認したりする必要があります。このエンジニアリングマネージメントコストを加味しないと内製化は危険です。
「いつまでもあると思うな親、金、エンジニア」です。
システム開発を成功させるためのポイント
次に、成功したプロジェクトの例からわかるシステム開発で失敗しないポイントを見ていきます。
企業選定時に実績を確認する
実際に各企業がリリースしてきたシステムはどういったものなのかを確認しましょう。また、現在進行系の実績について具体的にどの工程から、どの部分を、どのくらいの期間で担当したのか教えてもらうようにしましょう。自ずと任せられそうなスキル感が見えてきます。
企画から同じ座組に加わってもらう
課題設定や要件定義に自信がない場合、同じプロジェクトの座組に加わってもらいコンサルティングフェーズから入ってもらうのが有効です。変に強がってしまうとアウトプットが妙なものになります。
むやみに仕様変更を差し込まない
世間に散らばる炎上案件を見ると下記のような失敗の傾向があります。
- リリース日が迫っても「緊急」の仕様変更があり、それを止められない
- 開発遅れが発生し、パワーバランス的に依頼者が強くなり仕様変更についてNoと言えない
- アジャイル型開発であれば仕様変更をいつでもして良いという誤解がある
- アジャイル型開発を聞きかじり「（ウォーターフォール型であっても）最近は仕様変更しても開発できるらしい」と誤解している
よく「ウォーターフォール型だと失敗するのでアジャイル型にしたい」という声をお聞きするのですが、基本的に関係ないことです。仕様を固めて設計・開発・テスト工程に順にシフトするのがウォーターフォール型ですが、これを無視して仕様をひっくり返すと失敗します。
アジャイル型であればある程度吸収できますが、リリース日を延ばしたり、実現したいことを削減すれば対応できる場合があるという程度のお話です。
正社員採用・雇用継続はあとで考える
フリーランスや副業人材を入れての開発は定石となっていますが、核となる中堅ITエンジニアやプロジェクトマネージャーを引き入れないとシステム開発はいずれかのフェーズが滞り、破綻します。
しかし今は中堅ITエンジニアの転職傾向が一部のユニコーン・ネクストユニコーン、外資コンサル、フリーランス、スタートアップに集中しており、必ずしも自社にジョインしてくれるとは限りません。
内製化に拘りたい理由は何でしょうか？ その理由が「なんとなく内製化が良さそう」というものであれば採用に投下する金額を外注やマーケティングに投じた方が事業は前に進むでしょう。
どうしても内製化をしたい場合は、事業が成功してお金が潤沢に出きてから取り組まないと人材採用理由で事業が傾くケースは容易に想像できます。
まとめ
私自身が経験してきたシステム開発の失敗談と、そこから学んだ成功のポイントをご紹介いたしました。
特に大切なのは以下の4つです。
- やりたいことを固める。固められない場合はエンジニアも巻き込む
- いちど走り始めたら変更を加えたい場合はリリースしてからにする
- エンジニアとマメにコミュニケーションを取る
- システムのローンチを最重要目的とし、内製するかどうかは儲かってから考える
内製化するか外注するか。これは企業内の人員や事業のフェーズ、予算によっても大きく異なるところです。迷うところがありましたら一度ご相談いただければと思います。
皆様のシステム開発が成功に繋がる参考になれば幸いです。
▼LIGのシステム開発の強みは以下で詳しく解説しています。
“DX with Global Team” LIGのシステム開発の強み
Noriaki Iwata
