システム開発の難しさ その1
顧客が説明した 要件 |
プロジェクト リーダーの理解 |
アナリストの設計 |
プログラマの コード |
営業の表現、約束 |
プロジェクトの 書類 |
実際の運用 |
顧客への請求金額 |
得られたサポート |
顧客が本当に 必要だったもの |
これはITビジネスにおける多難なシステム開発プロジェクトの姿を風刺した絵です。
情報システム開発における要求仕様作りの難しさを示す例として、さまざまな本や論文で引用されています。
要約すると、発注する側の顧客が期待した通りのシステムとして完成しなかった原因は、開発側の勝手な思い込みや都合の押し付けだと思いきや、そもそも「最初に顧客が説明した要件からしてズレていた」、ということを表しています。
つまり、顧客自身も自分が必要とするものを開発側に対して説明しきれていなかったのです。
さらに踏み込んで言えば、開発側もそのことに気付けずに、指摘できていませんでした。
それでは、それぞれの絵が意味するところを読み解いていきましょう。
顧客が説明した要件
「顧客が説明した要件」は以下の通りです。
@ それは木の枝に2本のロープでつながれている。
A 2本のロープの下には、腰かけるためのものがある。
椅子になる板が3枚もある、ちょっと機能過剰なブランコの製造依頼です。
ただ、この時点ですでに完成型のピントが合っていません。
どこかで似たようなものを見聞きして作ってみた素人考えレベルのシステム提案といったところでしょうか。
問題解決を求めている当事者でありお金を払う立場なのだから、と自信を持って提案してきています。
もちろん、お金を払う立場でもあるのでシステム開発を請け負う側もあまり批判的なことは言えない状況も多いです。
開発側もお金をもらってシステムを作るプロなので、お客様の要望をできるかぎり汲む必要はあるのですが、それでもこのような文章でお客様の意図を読み取れと言われたら、どのようなプロでも悩んでしまうでしょう。
ここで重要なことは、「本当に解決すべき問題の本質が正しく見極められているのか」を何度も問い直すことです。
誰かが勝手に提案してきた「解決策」らしきものを、評価せずにいきなり飛びついてはいけません。
また、一番最後の「顧客が本当に必要だったもの」を見ればわかりますが、顧客自身も、きちんと自分の要求を相手に理解できるように表現する技術がないと、どんなに頭のいいシステムエンジニアがついていたとしても現場に伝わる段階では、このように理解されてしまう可能性があります。
きちんと完成品についてビジョンを持ち、それを全員で共有できるように「翻訳すること」が大事なのです。
要求する側の説明が足りないと、この後に示すように各部署はその足りない説明に自身の解釈を補足しながら仕事をこなし、結果、誰にも内容を説明できない完成品が出来てしまうことになります。
プロジェクトリーダーの理解
「木にぶら下がったブランコが欲しい」という顧客の要求はなんとか理解できたようです。
さらに、顧客の提案にある不必要な部分(3枚の板)はシステムの専門家として排除することができました。
その結果、枝1本では体重を支えきれないと評価したリーダーがたどり着いた解決案がこの絵です。
枝への負荷は軽減されたものの、そもそも木の幹が邪魔になって、これではブランコが動きません。少しでも技術を知っている人が側にいれば、その妥当性を検証できるのですが、そういう体制はないようです。
プロジェクトリーダーは、顧客にいちばん近い位置で開発に必要な情報を取り入れ、顧客のためのシステムを提案し、開発チームに完成品のビジョンを共有させる立場であるはずですが、既にこの段階で顧客との意思の疎通に齟齬が発生しているのです。
また実際に動くかどうか分からないシステムが構想されているのですが、システム全体の妥当性を検証する手段を持っていないということでしょうか。
同情的に見れば妥当性を検証する時間がないとも解釈できますが、うがった見方をすれば、プロジェクトリーダーの自信過剰とも受け取れます。
システム開発の難しさ その1 関連ページ
PR