なぜ要件定義はろくな事にならないのか？〜情シス目線のプロジェクトマネージメントTips#08

世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。

プロジェクトの失敗原因No1は「要件定義」

統計を取ったわけではありませんが、システム開発プロジェクトの失敗の元として一番多く出てくるのが「要件定義」。とくに業務改革を伴うようなシステム開発プロジェクトや古いシステムを刷新するシステム刷新のプロジェクトでは、まずこの「要件定義」が原因である確率は非常に高い気がします。

みんな大好き日経コンピュータの「動かないコンピューター」でもよく読んでみるとやっぱりユーザー企業の要求が曖昧だったり、「今のシステムとおんなじ仕様で」のようないい加減な要件だったりします。

実際にプロジェクトを回していて困るのは仕様の「変更」です。

その原因は何かというと、突きつけてみるとやっぱりヒアリングが足りていないとか、意見がまとまっていないとか・・・元々の業務要件が曖昧だったのが原因だったりします。

・・・・要件定義はしっかりとやったほうが良いですよね

しかし、はっきり言って堅実的には要件定義がちゃんとしているプロジェクトなんて見たことがありません。

・・・・・このへんが「前工程が完璧なこと」を前提に進めるウォーターフォール系の開発をする上での最大の矛盾点です。しかし完成委託でシステム開発を受注するSIerやシステム開発ベンダーは「仕様変更」されるとコスト計画、要員計画が狂ってしまい、たいへん困ってしまいます。

そこで自己防衛のために大量のドキュメントや、やたらとキッチリした議事録をものすごい時間をかけて作るわけなのです。
議事録や資料を元に変更を諦めてもらうか、追加された要員で個別に開発したりするための別料金を取るようにするわけです。
・・・このあたりがSIer系のプロジェクトマネジメントの教科書にはたくさん書かれています。

・・・・でも、これではSIer的には赤字にならないよう防衛できますが、ユーザーである事業会社としては何も改善されません。

いっこうに良くならない要件定義

この状況を放置していても誰も幸せにならないので、いろんな人たちが様々な方法で対策を考えています。

たとえば時間をかけて要件定義を行う、より多くのユーザーにプロジェクトに参加してもらう、ユーザー組織の偉い人を巻き込んで意思統一を図る、要件定義が得意なプロとかコンサルに大金を払ってまとめてもらう、プロセスマイニングやタスクマイニングなどのツールを使って現状を徹底的に調べる。

・・・・それらの弛まぬ努力や資金投入によって若干は改善されてきているのかもしれなせんが、それでも現実的には要件定義で決まった結果である「仕様」はいとも簡単に変更されてしまうのが現実です。

「これこそが決定的な解決策」という話はいまだ聞いたことはありません。

そもそも要件定義は反復しない

要件定義がいっこうに改善されない一番大きな原因は、最も大事な当事者であるユーザーの代表にとっては「一生に１回か２回しか要件定義に関わることがない」ということです。

システム刷新のタイミングはだいたい７年から１４年くらいと言われています。その業務の実担当として、このシステム刷新に関わることなんて、人生の中でそうそうないのです。

人間とは練習しないと上手になる事ができない生き物です。コーチがいくら優秀で指導方法がどんなに優れていても、選手がド素人からいきなり大会に出場するのでは絶対に勝てるわけがありません。

繰り替えしがないということは、つまり決定的に「反省が生かされない」「学習されない」ということなので・・・・改善されていくこともなく、プロジェクトのたんびに経験値はゼロリセットされてしまい・・・いつまでたっても要件定義がよくなることは無いのです。

聞き出す側が優秀なら解決するのか？

対策でよく挙がるのが「聞き出す力」を鍛えろという話があります。先程の例ではコーチを優秀にするという論理です。

しかしながらこれもうまく言ったという話は殆ど聞きません。
なぜなら聞き出す側さえもたいした能力にはならないからです。

ユーザー企業の中で「聞き出す」側に回るのは情シスや企画部門・・・この人達だって、そんなにプロジェクトに関わることはないので、そんなに熟練することはありません。
たまーに居る優れた人や何故かプロジェクトといえば投入されてしまう不幸な人くらいしかまともには要件定義をリードすることは難しいと思います。
コーチ自体が実戦経験がないのだからどうしようもありません。

自分の会社の中で無理なら外部に・・・とも思いますが、残念ながら部外者は、基本的に部外者でしかありません。ユーザーの言う専門用語や現場のシチュエーションを理解しにくいこともありますし、うわべだけの現状把握や要求確認になるのが関の山でしょう。
要件定義に準備される短い期間で真実を完全に把握するためには、心理的にもかなり突っ込んだやりとりが必要で、時にはヒアリング相手の心象を悪くするようなツッコミも必要になります。
受発注関係の中ではそんなヒアリングをするのはなかなか難しいでしょう。

・・・・・要件定義を完璧に・・・・なんてそもそも無理なのです。

昔、要件定義を完璧にやってほしいと頼まれたことはありましたが、こんな返事をした記憶があります。

「自白剤と竹刀の使用を許可していただければ考えます」

２〜３人●害するくらいの特権が無いと厳しいと思います。

ではどうすれば良いのか？

正直、どうすれば良いのかという問いに対する答えは持っていません。

ある程度は圧力をかけながら聞き出して、ちゃんと要件定義をしてはみますが、そこに過剰な期待はしないほうが良いです。いまはパワハラで訴えられかねないですし・・・

お金をかけるにしてもプロジェクトで生まれる成果に見合ったレベルしか投資はできません。

あきらめる

正直、完璧な要件定義など諦めて、むしろ漏れや変更に覚悟を決めて備えたほうが良いと思います。

これは今の受託開発を中心とするSIerの立場では難しいと思いますが・・・・

少なくとも金かけてコンサル雇って要件定義するくらいなら、諦めて柔軟に対応するお金を準備するほうが賢明な気がします。

そういうわけでアジャイルへの流れは止まらないわけです。