絶対に失敗する開発外注

システム開発が失敗するケースは多く、一説によるとシステム開発を外注した際の成功率は約30% *1 と言われています。残りの約70%が何らかの問題があったと言えそうです。このコラムではシステム開発を外注した中で起こった具体的な失敗例と対策について解説します。システム開発を外注するに際しての失敗例を知ったうえで、「外注して良かった！」と思える開発の参考にしてください。
*1 引用：https://diamond.jp/articles/-/135048?page=2

 

1.よくある開発外注における代表的な失敗3選　

a.「納期オーバー」の失敗例

「納期オーバー」とは、納期の期日が過ぎてしまうことをさしています。この中でも特に失敗例に多い原因が、開発途中で手戻りが発生するケースです。こうしたケースでは当初策定したスケジュール内に開発が完了せず、納期の期日に間に合わないことに直結してしまいます。

例えば要件定義の工程で、発注者と開発者の認識のズレを抱えたまま基本設計、詳細設計の工程へと進んでしまった場合、プログラミングの工程やテストの後半の工程の中で認識のズレが判明するケースがあります。こうした失敗では、上流工程に立ち戻り認識のズレを正し新たに工程を改めて進めなくてはなりません。こうして発生した手戻りによって納期遅れが起こります。

システム開発は下流工程になるほど、関連するタスクや開発するサブシステムの数も増加します。そのため手戻りが起こると納期オーバーの日数が増加してしまいます。こうした失敗が起こらぬように上流工程である要件定義や基本設計の段階でズレは解消しておきましょう。

b.「コストオーバー」の失敗例

「コストオーバー」の失敗例について説明します。納期は極めて大切な要素ですが、納期遵守を重視するあまり、開発要員の増員を繰り返した結果、人件費が増加する場合があります。

一括請負契約による受託開発 *2 であれば、開発会社側の増員コストは発注者側に請求されることはありませんが、契約形態によっては開発予算をオーバーします。過大な超過コストはプロジェクトの進行自体にも影響を及ぼします。
*2：一括請負契約による受託開発とは・・・プロジェクト全体をカバーし、成果物を納品することで報酬が発生する契約を指し、開発内容はオーダーメイドで行う

c.「完成したシステムの機能が想定通りでなかった」失敗例

このケースは発注者と開発者の認識のズレや理解の深さに乖離がある場合などです。システム要件やユーザーニーズが反映されていない場合、手戻りによって納期遅延のみならずコストオーバーが発生してしまいます。

発注者と開発者ではそもそも立場と背景が異なります。発注者の業務内容や業務フローに対する理解の深さも異なります。共通言語が不足しがちの状況で、コミニュケーションに課題があり、意思疎通ができていないと当初の目論見とは異なるシステム開発になりかねません。

 

2.特に避けたい大失敗事例

a.納期遅延

納期遅延はシステム開発を外注する際に多く見られる失敗例です。納期遅延の原因は、要件定義や設計工程における不備、開発プロジェクトの混乱、コミュニケーション不足などによって発生します。 

例えば、ウォーターフォール型のシステム開発において要件定義が不明確な場合、開発の段階が進むにつれて課題が発生し、それに伴い開発スケジュールが遅れることがあります。開発プロセスが明確ではない場合や、計画通りの進捗しない場合も、納期遅延の原因となります。

納期遅延が起こると、さまざまな領域に影響がおよびます。

まず、システムのユーザーに対してはあらかじめ発表されていたリリース日にサービスが利用ができないため、運営元に対しての不信感や不満感が生まれます。また開発内容が新サービスへ差し替わる場合、現行システムを使い続ける期間が延びることで生産性や効率の低下、さらには新しいシステムで得られたであろう機会の損失が想定されます。

さらに事業運営に対する影響です。とりわけ基幹システムや大規模システムの場合、納期遅延による影響範囲は自社のみならず、ネットワークで接続されたシステムにも及ぶこともあります。

b.コストの増大

開発コストの増大はシステム開発の外注において頻繁に発生し、その要因は無数にあります。

一般的にシステム開発のスケジュールは遅れがちです。そのため、納期遵守や納期短縮のために開発要員を増員したりリソースの追加したりすることで予算が膨張する可能性があります。また、要件定義が甘くシステムの完成像が曖昧なケースもコスト増大の要因となりえます。これにより、外注先が必要以上のリソースを割いたり、結果として予算が膨張する可能性があります。

さらに手戻りの工数が発生した場合もコストが増加する可能性があります。例えば、下流工程でシステムの要件や機能が満たされていないことが判明した場合、上流工程に戻って修正をしなくてはなりません。そうなった場合、修正の工数に必要な開発要員などのリソース追加がコスト増大に直結します。

c.成果物のクオリティの低下

成果物のクオリティに満足することができない事例として、ユーザビリティの不足があります。ユーザビリティとは、システムの便利さや使いやすさを指します。この点が不足していると、ユーザーの満足度に大きな影響を与えます。例えば、生産性の向上や業務効率化を目指して開発されたシステムの場合、そもそもの使いやすさの要件を満たしていないものがリリースされれば、ユーザーの不満が高まることは容易に想像できます。

このような失敗は、発注者側のシステムの完成像が曖昧だったり要件が明確でなかったり、開発に携わるメンバー間で認識が不一致であると発生する確立は高くなります。さらに開発者が業務フローやユーザーの視点を適切に理解できない場合も発生します。結果として、成果物のクオリティが低く、ユーザビリティが低いシステムが構築されてしまうのです。

 

3.外注しないほうがよかった？！
ありがちな失敗のパターン3つ

システム開発の場合「外注をしない方がよかったのでは？」と思われる、失敗の中でも特に「外注を選択した」こと自体に課題が大きく、外注という方法自体が該当のプロジェクト・発注側との適合性が乏しいケースも発生します。そうしたケースについて具体的に説明します。

a.外注と丸投げとは異なることを理解しよう

システム開発の外注は、システム開発会社に丸投げをすれば進むものではありません。依頼元である発注者側はしっかりと進捗管理を行う必要があります。こうした工数を怠った場合、成果物が当初想定した要件と異なるイメージになってしまう可能性があります。

仮に丸投げを行う場合は、発注者側の業務についてコンサルティングも行える開発会社に依頼する必要があるでしょう。一方でこうした場合はコストアップになる可能性があります。外注を行う場合は全ての工数ではなく、一部の工数を依頼する程度が望ましいと言えるでしょう。

b.開発後に想定外の不具合発生、保守運用は自社を目指そう

システムは開発が完了して終わりではありません。むしろ安定的に稼働を続けるための保守運用のフェーズが極めて大切です。ランニングコストをカットするため自社による保守運用を想定していた場合、いざトラブルが発生した時に対応できず、ユーザーから大クレームが起こることがあります。発注側のシステム担当者は板挟みに悩むことになります。 

世の中には「完璧」なシステムは存在しません。特に新規開発のシステムはどんな想定外のトラブルが発生するかわからないため、一定の期間は開発会社に引き続き保守運用を依頼する方が良いでしょう。安定的に稼働しはじめ、安定的な運用が見えてきたタイミングで自社による保守運用に切り替えていく方法は安定した運営とランニングコストを考えた賢い選択です。

c.成果物が詐欺まがいの仕上がり

システム開発会社の実績や強みについて、事前調査をしっかりと行わずに決定した場合、成果物が期待する品質に至らないケースもあります。また、発注者側が一方的に短い納期を決めてしまったような場合も、品質が担保されないケースが起こり得ます。

問題の原因はケースバイケースですが、こうしたリスクを避けるためには対策を次の章で説明します。

 

4.失敗を未然に防ぐ対策　

システム開発における失敗の対策を3つ下記に説明します。

a.システム開発会社の選定基準

システム開発会社を選定するときは複数のポイントを基準にして選択するとよいでしょう。選定基準には主に下記の６つのポイントがあります。

1）得意分野や強みがある領域の確認
2）開発実績や技術力、経験値の確認
3）システム開発会社のセキュリティに対する意識や対策
4）担当者のコミニュケーション能力について確認する
5）運用・保守など開発後のサポートがあるか
6）その他（受託開発会社の経営や業績の安定性、オフショア開発を取り入れているか） 

右記の記事で詳しく説明していますので是非参考にしてください！
「受託開発の外注先選定　システム開発会社を見極める６つのポイント」

b.発注直前～発注

開発会社が決定し、発注するまでのプロセスではコミュニケーションが極めて重要です。発注者側は開発社側としっかりと打ち合わせを行い、双方の齟齬を無くしておきましょう。まず認識すべきは発注側が必要な情報を持っているということ。自社にとっては当たり前の情報も開発会社にとっては初めてのことがあり、双方で解像度は異なります。また理解度の深度も異なります。

情報の伝え方も適切なタイミングで適切な粒度で伝える必要があります。良かれと思い、最初からすべての情報を詳しく伝えても、人の記憶は減衰し曖昧になって行きます。こうしたことは抜け漏れや認識の相違につながります。プロジェクトの初期段階では情報の全体像を抽象的に伝え、プロジェクトの進行に伴って、フォーカスを絞って具体的に伝えるなどの工夫も必要です。

情報を伝えるタイミングも「現在進行形のタスク」「直近で進行するタスク」「将来進行するタスク」などの時間軸に基づき、発注者側、開発者側で整理していけることが理想的です。

c.開発中の対応

システム開発に失敗しないためには、システムの開発中の対応が極めて重要です。3つのポイントについて説明します。

1）定期的な打ち合わせを設ける

システム開発にはオンライン、オフラインを問わず定期的な打ち合わせが大切です。打ち合わせの目的には発注者側と開発者側がシステム開発に関わる情報や課題の共有、理解の深度の確認や、進捗やリスクの確認などがあります。また、打ち合わせの頻度には、主にDaily（日）、Weekly（週）、Monthly（月）、Quarterly、（四半期）、Yearly（年）があります。
打ち合わせの内容やステークホルダーの人数によって開催する頻度や内容が異なるため、適切なタイミングで行うとよいでしょう。

一般的にDaily（日）やWeekly（週）は短い時間軸で直近の進捗や部分的な確認などで行われ、Monthly（月）、Quarterly（四半期）では長い時間軸でプロジェクト全体の確認などのために行われるため、開催頻度の参考にしてください。

さらに実際に対面で打ち合わせを行うことで「相手の顔を見て理解できたかどうかを判断する」ことができるでしょう。打ち合わせの出席者から質問が無く、理解されたと思っていても後々で解釈が異なっていることが、時として発生します。対面の打ち合わせによるコミニュケーションを行うことで、チャットやメール等のテキストベースのコミニュケーションツールではわからない文脈や相手の反応を確認できるでしょう。対面が難しい場合は、画面をオンにしたオンライン会議も有効です。 

2）適切なコミュニケーションツールでのやりとり

システム開発にはコミニュケーションツールが必要です。在宅勤務やオフショア開発などリモート勤務が一般的な環境では、リアルタイムにやりとりできるSlackやチャットワーク、SNSベースのツールが最適でしょう。こうしたツールでは社内外のコミニュケーションを効率化し、コミニュケーションコストを低減できます。また、情報共有を行うためのナレッジマネジメントツールも、データの集約と更新情報の管理に有効です。

3）進捗管理を行う

進捗管理はシステム開発会社に丸投げをせず、進捗管理の主導権は発注者側が握ることが大切です。進捗管理に適切なガントチャートや進捗管理ツールを活用し、発注者側と開発者側の双方でしっかりと管理しましょう。

d.その他

開発が終了した後の運用保守の工程でも失敗の原因となることが発生します。システムが安定稼働するまで発注者側と開発者側で緊密なコミニュケーションをとりながら、初期トラブルの解決やユーザーからのフィードバックを行っていきましょう。

5.まとめ

本コラムでは、「絶対に失敗する開発外注」について解説しました。内製による開発を希望しながら外注を選択する場合もあるでしょう。一方で、さまざまな失敗が多いこともシステム開発の特徴です。このコラムではシステム開発を外注した時に失敗しないためのポイントについてまとめました。情シスナビでは、本コラム以外にも、情報システムの開発に関わるさまざまなコンテンツを提供しています。是非確認してみてください。