１人月を削る妄想（1）

ここ数年、ソフトウェア開発のリードタイムを確実に短縮できないもんか、と色々考えておりました。加えて、元請と下請の責任の擦り付け合いとネガティブなヒエラルキー祭りに巻き込まれてすっかり忘れておりました＞＜
なので、全然実現できていないのですが、自分自身を取り戻す的な意味合いも含めて、とりあえずメモ。

まず、ソフトウェアを開発する上で必要な情報は、「要望」と「要件」です。
この２つからいわゆる「仕様」を決めていき、最終的にコードに落とし込むんですね。
そして、コードが「仕様」「要件」「要望」に沿ったものかどうかを確認します。

まず、要望と要件なのですが、これを定型的に把握しようとするのはそうとう難しそうです。お客様独自のコンテキストもあるでしょうし、担当者それぞれのビジョンもあるでしょう。

そして、「要望」として出てくる様々な言葉の断片を拾い集めて、そこから「要件」と呼べるものを導き出す訳です。

これを定型化してどうこうしようというのは大変そうですし、無理なようにも思えるので今度考えるとします。

続いて、仕様化のフェイズについて考えてみます。
俗に要件定義と呼ばれるフェイズからこの仕様化のフェイズ、つまり「設計」フェイズに移るのがSIerにいる人間にとっては殆どのパターンだと思います。
そして、SIerでの殆どのパターンとしてこの仕様化フェイズがスタートした時点で、お客様の要望を十分要件にまとめらていないケースが多いです。また、要望をお伺いしたところで要件化が十分でない場合が多いように思います。

そんな状態で仕様化のフェイズがスタートしたらヤバイ設計書が出てくるんじゃない？
と言われそうですが、この時点でこれから開発するソフトウェアの細かな挙動を想定する事が難しい（試してみないと、調べてみないと分からない。でもそんな時間は無い、といった感じに）し、でもとりあえずプロジェクトのステータスは進めないと、といった感じです。
プロジェクトの進捗はもっぱら成果物ではなく政治的に算出される、みたいな感じですね。Geekな方々に「Suit爆発しろ」等と言われそうです。

結局のところ、要件定義のフェイズだけでお客様の要望を完璧に要件にすることは難しいです。
たいていの場合が、後の工程で「やっぱり難しい（というか無理）」みたいな事が分かって、要件として一度は決めたけどもう一度考え直そう、みたいなイベントがあったりします。そして、そこで出した代替案がその他の部分にどう影響を与えるのか、がキーポイントになるのですが、ヒドイところだとこの時点で設計書は完全に放置されてしまう為、コードだけが文書化されていない仕様を追いかけ、ドキュメントがデグレートし続けます。（たまに見るドキュメント軽視の風潮は多分このへんが原因って気がします）

でも、初回の企画やらコンセプトで１ヶ月程度、要望をお伺いして要件化するのに２ヶ月、要件化してから仕様化するのに２ヶ月、そこからようやく「開発らしい仕事」が始まりますが、業務システムだと開発費そのものが年間予算に織り込まれてたりするので、よほど大きなプロジェクトでもなければ１年前後でカットオーバーを迎えますから、この時点で既に残り７ヶ月です。

リリースの前後はどうやってもばたつきますので、バッファを取って（たいてい足りないけど）１ヶ月。

ここで残された猶予は半年。

要件ががっちり決まっていて、業務フローなんかもバッチリ書かれていれば、あとは要件にしたがって望まれた機能を作りこんでいくだけなのですが、前述のようにこの時点で結構ボリュームのある課題などが残っていたりします。

僕自身の過去の経験では、こういったシチュエーションの仕事が多かった気がしました。

で、要望と要件をガッチリ決める、またはブレを吸収できるような手法は無いもんか、とT字形ER設計技法とか勉強しようとしたりしましたが、結局お客様も開発者も要望をはっきり要件化できていないまま仕事を進めてしまうので、どうやっても要件や仕様の変更は生まれ続けるんじゃないだろうか、と。

って事は、開発のリードタイムを縮める以外に、要望と要件にお応えしていく方法は無いんじゃないか、と。

こう思い始めたのがちょうど３年くらい前。

さて、イイカゲン何かを形にしなくては＞＜