規模がわからないプロジェクト、というものが時折ある。やったことがないので試算の根拠がない、そもそも発注者がなにをしたいのか自分でもわかっていない（！）、そんなプロジェクトである。
だが、そんな曖昧な状態であっても、やるからにはプロジェクトを管理しないといけない。どう対処したものだろうか。
精度の高い見積もりを出すためには前提条件がある
いつまでに、いくらで、なにができるのか。発注者が気になるのはそこだろう。だから事前に高い精度の見積もりが欲しいわけだが、それを可能にするためには条件がある。
日数（≒費用）を算出するためには、必要な工数を算出できなければならない。
工数を算出するには、必要な作業を洗い出せていなければならない。
必要な作業を洗い出すには、1) なにをしたいのか(要求定義) 2)それを実現するためにどうすべきか（要件定義/基本設計） を両方とも把握できていなければならない。
つまり要求定義と要件定義/基本設計をカッチリ行えてようやく使い物になる見積もりができる（正確には、その可能性が出てくる）。
逆に言えば、それができないなら、信頼できる見積もりは出せない。曖昧な状態で信頼できる見積もりを出せるなどと考えてはいけない。
※ 要求定義と要件定義について
要求と要件は似ているが異なる。要求定義は基本的に発注者がなにをしたいか(What)、要件定義はそれを実現するための物事(How)、と考えておけば大体どのプロジェクトでも通じやすい。
- 要求定義の例
- お客さんがオンラインで決済を済ませられるようにしたい
- 要件定義の例
- クレジット決済
- Paypal決済
- 入金消込
- etc...
※ たとえ圧をかけられても見積もりを雑に行ってはならない
自分も発注者の立場になることがあるが、その際は期日と費用の情報が早く欲しいと思う。
これは自分だけでないと見えて、発注側になった方は、しばしば無理めな状況からでも見積もりを取りたがる。時には策略じみたやり方――「目安でいいですから！」と口で言っておいて、後になって「○○までって言ったじゃないですか！」と詰めるような――を使うことさえある。
しかし、これは大変危険なことで、受注側としては、適当な見積もりは絶対に控えなければならない。いかなる理由があっても、である。それは独り歩きして関係者に不幸をまきちらす不誠実な行為である。
デキる営業のようにするべきだ。彼らは決していい加減な見積もりに応じない。どれほど強く、どれほどしつこく何度も、見積もりを出せと圧をかけられても、である。彼らは予算感をすり合わせるためであっても、見積もりと思われないよう他者事例の形を使うなどの工夫をしつつ、とても慎重に話す。プロとはかくあるべし。
ではどうする？ その１（要求定義がないケース）
まず要求定義がないプロジェクトにはどう対応するか、から考えたい。
恐ろしいことだが、そんなプロジェクトもなくはない。予算と期日だけ決まっていて、あとはなにも決まっていないも同然、というプロジェクトだ。この時点で失敗が約束されているようなものだから、そもそも関わらないのが最善となるのだろうが、不幸にして関わらざるを得ないこともある。
この場合、誠実な仕事とはなにかを考えるに、やはり要求定義をちゃんと決めるところからスタートだろう。発注側が要求定義を出さないのは、出さないなりの事情があるはずなので（まっとうな理由ではないのだとしても）、生半可なことではないが、しかしそこがいい加減では、プロジェクトを進めれば進めるほど災害の度合いが大きくなる。基本に立ち戻るよりないだろう。
それすらできないとなると、最早私にはどうしたらいいかわからない。
ではどうする？ その２（精度の高い要件定義ができないケース）
要求定義は明らかである。しかしそのために必要な物事が定かでない。そんなケースにどう対応するか。
わかる相手に頼む、とする手もあろうが、あいにくそれで済ませられるケースばかりではないであろう。また、エンジニアがそんなことばかりしていたらスキルの幅が広がらず、従って仕事の選択肢も狭まり、先細りになってしまう。自らチャレンジすべき時も多々あろう。
できる範囲で、必要なレベルまで詰める
まず現時点でわかる範囲で要件を定義すべきだろう。いうまでもなくその要件定義は精度が低いから、あまりアテにならないが、やらないよりはいい。ただし、行った場合でも、見積もりとしてコミットしてはいけない。雑な見積もりは計画としてまともに機能しない。これは肝に銘じておく必要がある。
それを踏まえた上で、しかしわかる範囲で、必要な粒度まで落とし込んだ項目のリストアップを行うべきである。
「どうせ雑にしかわからないのだから粒度を大きく大ざっぱにしておくしかない」とする判断は誤りで、必ず妥当なレベルまで落とし込む。どの道それはいずれやらないといけないことなのである。そして、万一それを今もしできないのなら、必要に迫られた時もできないのである。
できる範囲でいいので（というか仕方ない）、必要なレベルまでがんばって詰めるべきだ。そのための調査も必要なだけ行わねばならない。その上で概算でも工数をつけてみれば、規模感が低い精度でもうっすら見えてくるはずだ。もしもそのための時間すら取れないほど時間や予算がひっ迫しているなら、そのプロジェクトはすでに破綻していると考えざるを得ないから、要求定義に戻ってプロジェクトそのものを見直すべきだろう。プロジェクト管理に奇跡を期待してはいけない。管理を放棄して楽になった気がしたところで、事態は悪化しこそすれ好転しないのだから、ツケが後になってのしかかってくるだけだ。
なお、この方式は、成果物が少ない上に品質が低く、しかも無駄に時間がかかっているように外部からは見える。従って、上長がもしいるならしっかり関わってもらうほうがいい。頑張って成果も（実は）出しているのに低い評価をもらうのは侘しいことである。逆に自分が上長の立場なら、進捗状況の確認は比較的きめ細かく行うようにするべきだし、そもそも困難なプロジェクトという前提を忘れず評価するべきだ。投げっぱなしにしてはいけないし、進捗が期待に反しているからと拙速にパフォーマンスの低さをなじるのも巧くない。
随時アップデートして精度を上げていく
やりながらわかってくることもある。そうなれば要件についても加筆修正や削除が可能になるだろう。どんどんアップデートしていくべきだ。
これは最初に精緻な計画を作り上げられないことを最初から織り込むべき理由にもなる。要件がどんどん変わっていくとわかっていれば、全体スケジュールを正確にだせるわけがないことも自明だ。
途中でギブアップがありえることも織り込む
途中で予想以上に困難や規模があることがわかるかもしれない。そういうケースではギブアップを視野に入れざるを得ない。
技術というより経営的な話になるが、危険なプロジェクトは失敗リスクへの対応も考えておくべきである。のるかそるかで全賭けするなど以ての外である。
当たり前なのだが、やはり知識や経験が不足している中でのチャレンジングなプロジェクトは、失敗のリスクが高い。必ずうまくいく、うまくいかせざるをえない、そんな危険な状況――たとえば請負で成功を約束してしまっているとか――でチャレンジングなプロジェクトを行うのは間違いだ。
いくら無理をしたところで無理なものは無理とわきまえる
要するにブラック労働やデスマーチのことなのだが、計画時にそれを織り込むのは誤りである。ロクな結果にならない。人を粗略に扱うものではない。その人物が自分のことであってもだ。他人ならなおさらだ。
細かく区切る
正確なスケジュールなど出せるわけがない、といっても、だからといってノーコンではプロジェクト進行が散漫になるのは目に見えている。難易度の高さを勘定に入れても、成果は低いものにならざるを得ないだろう。
そこで範囲を小さく区切り、一週間なら一週間分の作業として切り出して管理する手法を取り入れたい。アジャイル開発のスプリントや、段階開発の手法だ。大きすぎる物事は把握しきれないが、細かくして小さくなった物事ならなんとかなる（事が多い）。それで作業量とパフォーマンスの管理は――全体スケジュールは怪しい状況が続くにしても――ひとまず妥協できる程度には確保できるだろう。
あまり先々まで期日まで決めようとするのは、要件の精度が低いうちはあまり有効ではないだろうから、極力避けたほうがいいと思う。品質の低いスケジュールをいじくりまわすためだけに時間を使うのはもったいない。
あるいは成果ベースで区切るのもいいかもしれない。たとえば下位問題を切り出してそこだけ独立させて考えるのは悪くないアイディアではないか。
スケジュールか成果物で調整しながら管理する
不透明なプロジェクトでのまともな進め方は、結局、成果物を固定してスケジュールを可変にするか、スケジュールを区切って成果物を可変にするか、にならざるをえないように思われる。
バッファまみれのスケジュールをたてる手法がよくあるが、あれはあれで微妙だし、それでも上手くいく保証はない。
不味い事態が起こっても不思議がないプロジェクトになるから、融通を効かせられる状況を事前に作っておくのが命綱、と考えれば、当たり前のことではある。
