『今』、プロジェクトを成功させたい

と思っている人の為の Webインテグレーター細川です。

発注側のみなさんも、受託側のみなさんも、
ITプロジェクトで苦労されていませんか？

苦労するものの1つに、「要件定義」がありますよね。

視覚化が難しいITシステムは、「要件定義」の段階では、実は大まかな要件しか決めないことがほとんどです。

当人たちは結構細かいところまで要件を詰めたつもりでも、
設計以降の工程で、
「あ、○○を考慮していなかった」
「○○と△△が不整合になってる、△△を見直さないと」
といったことがよくあります。

いやホントに、よくあるんです。

この業界に15年以上いますが、
「要件定義が抜け漏れなくちゃんと完了した」って話は、聞いたことがないぐらいです。
(※プロジェクトには大小あるため、要件定義がちゃんと完了するような小さなプロジェクトは存在します)

要件定義がちゃんと完了できない、その理由はいったい何なのでしょうか？

よく言われているのが、以下のような理由なんじゃないでしょうか。
・受託側の業務知識が不足していた
・受託側の技術力不足
・要件定義の期間が短すぎて、詳細まで詰められなかった
・発注側が情報を出し切っていなかった
・発注側、受託側双方で想定していない制約があった
etc

このような理由で、要件定義は失敗に終わります。

もちろん、要件定義している最中は、当人たちはうまくいっていると思っています。
しっかりレビューもやって、抜け漏れないと判断して、要件定義を終わらせています。

が、その後の設計やテストの工程などで、要件定義の抜け漏れが発覚するのです。

上述した理由で失敗することがわかっているにも関わらず、ITプロジェクトの要件定義はそのほとんどが失敗に終わります。

そして、世の中の「要件定義」というものは、失敗し続けています。

なので、僕はこう考えるようになりました。

『そもそも、
ITプロジェクトに「要件定義」という概念はフィットしない』

要件定義という概念は、ウォーターフォールモデルの中のイチ工程で、
日本でも1970年代から国産メーカーが取り上げるようになったようで、
その後ソフトウェア開発にも適用されるようになったようです。
(※この辺りの歴史的なことは曖昧ですね)

もともとは、製造業や建設業で導入された概念なのではないかと考えられます。

工業製品や建物は、つくるモノの定義が明確だったので、要件定義がフィットしたのでしょう。

しかし、ITプロジェクトでつくりあげるソフトウェアは、つくるモノの定義が「曖昧」な部分が多いので、要件定義という概念自体がフィットしないのではないかと考えるようになりました。

IT産業は他産業に比べて歴史が浅いので、当時適したプロセスが何なのかわからず、
製造業や建設業でうまくいっていたプロセスをIT産業にも適用したのではないかと推測しています。 

「でも、要件を決めなければ、何もつくれないじゃないか」
というご意見があるかと思います。

おっしゃる通りです。

でも、
「要件を定義する」
前に、
「どんなサービスにしたいのか」
とか、
「どんなビジネスとして継続したいのか」
という
「目的」
が重要で、要件を決めるのはその後です。

そして、
・要件を決めてからつくる
のではなく、
・つくりながら要件を決めていく
というプロセスが、 ITプロジェクトには最もフィットします。

もういっそのこと、IT産業から「要件定義」という言葉、プロセスは排除してしまいましょう。

「サービス目的確認」とか「ビジネス目的確認」を行って、
その後に、モノをつくりながらシステム要件を固めていけばいいのです。