昨日から３日間、西新宿の本社で要件定義に関する研修。
要件定義概論、要件定義計画、業務要件定義、システム要件定義、全４回をイッキに受ける。
普通は細切れに少しずつ受けるみたいだけど。
事前課題としてこれまで成功した／失敗した要件定義を振り返るというものがあった。
世の中に成功した要件定義なんてものはあるんだろうか？ と最初は思ったが、よく考えたらあった。
30代に入ったばかりの頃、凄腕のプロジェクト・マネージャーと２回続けて仕事をさせてもらった。
どちらも新しく立ち上げるサイトのバックエンド側、会員管理や認証基盤を構築するというものだった。
彼は顧客のキーマンをがっちり掴んでコストやリスク、制約事項をきっちり押さえてしまう。
ここまでは今回システム化するけどここからは対象外という線引きが絶妙で、
そこを超えて追加要望が上がるときっちりはねのける。
何がそのプロジェクトにとっての成功で、何が失敗なのかを明確にする。
事前に落とし穴を見つけ、対処しておく。
その地ならしの上で僕ら現場のシステムエンジニアは、具体的に何を作るか詰めていく。
半年でサイトを立ち上げるというスケジュールを無理なくクリアして、
それなりに残業はあったけどきちんと利益を出した。
とにかくすごい人だった。
どんなシステム、どんなプロジェクトでもそれは可能かというとそんなことはなく、
恐らく適切な規模だったからだと思う。
全体像を俯瞰して把握できるかどうか。
プロジェクトマネージャー、プロジェクトメンバー、両方にそれができると
そのプロジェクトはうまくいくのだと思う。
あるラインを超えると全体像を把握できる人がいなくなってプロジェクトはカオスとなる。
マネージャーは現場を見なくなって計数や定量的な報告だけを見るようになる。
チームは縦割りになって横串で動く人がいなくなる。
一社だけで開発するのではなく、対等な立場で複数社入った場合にはもうだめだ。
（もちろんそれは建前上の対等であって、すぐにパワーバランスが崩れていく）
僕がこれまでに関わってきた数億規模のプロジェクトは
どれもしっちゃかめっちゃかになって胴体着陸で無理やりサービスインを迎えた。
上記２プロジェクトは１億を超えることはなかった。
この間のどこかに分界点があるのだろう。
いや、数億規模でも方法論によってはそれは可能となるのだと思う。
失敗した要件定義は振り返ってみると方法論がなかった。
どういう情報を集めて、どう整理するのか。
それは顧客のやりたいことを御用聞きのように聞くことではない。
そもそも要件定義と設計の区別がなく、
スケジュール上の線が来たのでなし崩し的に設計フェーズが始まってしまうとか。
要件定義は本来、顧客側が主体的に何を作りたいかを明確にすることなのだから、
設計とは全くの別物なのだ。
もうひとつ、失敗するプロジェクトに言えることは
要件定義の前段にてまとめたはずの顧客の経営課題やそれに対する解決策といった大方針が忘れ去られて、
というか後工程で大量に投入された開発要員に全く伝わっていなくて、
場当たり的に目の前の仕様書に従って開発するだけでバラバラなまま全体がまとまらない。
言い方を変えると、同じ方向に向かって進んでいくという雰囲気がない。
結合テストでサブシステム連携が全然うまくいかないという要因のひとつに、実はそういうのもあると思う。
連携インタフェーズを両者が丁寧に確認したかどうかとは別の次元で。
最後にもうひとつ。
要件定義がうまくいかない理由には体制上の問題もある。
プロジェクト立ち上げに当たって上流工程ができるシステムエンジニアを揃えられなくて
前のプロジェクトを抜けるのに時間がかかってマチマチなタイミングで参画することになる。
この頃の１週間、２週間先に入って手を動かしたり打ち合わせに出ているというのは大きな差を生む。
後から加わったメンバーは往々にしてキャッチアップするだけで大半の時間が終わってしまう。
なかなか足並みがそろわない。
そういったことのひとつひとつの積み重ねが要件定義を形だけのものとしてしまい、
後のフェーズで「時間が足りない」という事態を招くことになる。
要件定義をどれだけ充実させるかで、その後のプロジェクトの成否が８割方決まるのだと思う。
