数千万円を投じたのに使えないものが納品された、納期が半年以上遅れた。こうした失敗はニュースになりやすく、自社のプロジェクトも同じ道をたどるのではないかと不安になります。その不安は当たっています。システム開発は不確実性が高く、何も手を打たなければ失敗の確率は上がるからです。ただ、炎上した案件を後からたどっていくと、原因は技術よりもずっと手前の、発注側と開発側が交わす言葉のほうにあることがほとんどです。
失敗の多くは技術力ではなくコミュニケーションで起きている
原因はたいてい同じ場所にあります。プロジェクトが炎上した経緯をたどっていくと、エンジニアの技術的なミスよりも、発注側と開発側のあいだで言葉の意味がすれ違っていた瞬間に行き着きます。
とくに多いのが、誰が何のためにシステムを使うのかという目的を定義しないまま機能のリストだけを渡してしまうケースで、これと並ぶのが、開発途中で追加の要望が次々に出てスコープ（開発範囲）が無限に膨らみ、予算とスケジュールが同時に破綻していく型です。どちらも珍しい事故ではありません。
発注側がプロジェクトを制御する3つの手順
手順1：ビジネスの目的とユーザーストーリーを共有する
機能から入らないでください。誰がどのような環境で何をしたいのかを先に伝えると、開発会社は背景ごと理解したうえで、技術的な観点からこちらが想定していなかった代案まで出してくれます。書き方はユーザーストーリーのテンプレートと具体例にまとめています。
手順2：要望は引き算で決める
全部は入りません。社内から集まった要望をすべて盛り込もうとしたプロジェクトは、まず失敗します。システムに必要なコア機能を定義し、それ以外は次回の開発に回す。この削る決断は、開発会社の側からは言い出しにくく、発注側にしか引き受けられません。判断の物差しにはFM法によるスコープ管理が使えます。
手順3：進捗はビジネス価値の単位で管理し、動くもので確認する
単位を変えます。データベース設計といった技術用語で進捗報告を受けても発注側には評価できないので、「ユーザーが登録できる」というビジネス価値の単位に置き換えてください。そのうえで1〜2週間ごとに実際に動くデモを見せてもらえば、手遅れになる前に問題を察知できます。
チェックリストは3行で足ります。
- 開発会社に機能リストだけでなく、業務の目的と背景を伝えているか
- 要件が無限に膨らまないよう、不要な機能を削ぎ落とす判断をしているか
- 書類上の進捗率だけで判断せず、定期的に動くデモで確認しているか
スコープ膨張で半年遅れた案件と、優先順位で守り切った案件
よくある失敗例
在庫管理システムの開発で各部署から集まった要望をすべて実現しようとしたところ、開発が進むほどあれもこれもと機能が積み上がり、やがて開発会社の対応能力を超えました。納期は半年遅れ。追加費用が膨らんだうえに、最後に残ったのはバグだらけで稼働できないシステムでした。
どう防ぐか
要望をリストアップした段階で、経営陣がビジネスの優先度と技術的な実装コストを天秤にかけ、これがないと業務が止まる機能だけに絞り込みました。開発中も2週間ごとに動くデモを確認し、追加要望が出たときは優先度の低い既存タスクと入れ替えるルールを徹底しました。システムは納期どおりに動きました。
発注側が握っておく4行
- システム開発の失敗は、技術力より認識のズレから生まれる
- 背景にあるユーザーストーリーを開発会社と共有する
- 要望をすべて盛り込もうとせず、優先順位をつけて引き算する
- 進捗は動くデモで定期的に確認する
FAQ
Q1. 開発途中で仕様変更をお願いすると失敗しやすくなりますか？
A. 仕様変更そのものは問題ありません。不確実な開発では起こり得るものだからです。危ないのは、追加に伴って他の機能を削るなどの調整をしないまま要望だけを足し続けたときで、その延長線上にプロジェクトの破綻があります。
Q2. エンジニアの言っていることが理解できず、進捗が把握できません。
A. 専門用語を無理に理解する必要はありません。ビジネスへの影響や、ユーザーがどう使えるようになったかで説明してもらうようリクエストしてください。
Q3. 丸投げするとどうして失敗するのですか？
A. 自社の業務を最もよく知っているのは発注者自身だからです。システムは業務を改善するために作るものなので、その知識が設計に入らないまま進むと、現場の実態と噛み合わないシステムができあがります。