だいぶ間が空いてしまいましたが、気を取り直して書きます。

前回プロジェクトを成功させるためのヒントを2つ書きました。
①の「プロジェクトマンジメント手法を現場に取り入れる（Doing)」の方は、PMBOKに書いてあることなのでおさらい程度と、プラスして若干補足を書いてみようと思います。

まず、「プロジェクトにおける3つの制約」ですが、
1．コスト
2．時間
3．スコープ
になります。

1．コスト
これは一番分かり易いですよね、開発コストです。
人件費や材料費や設備費など、それから間接費用、そういったものすべてですが、プロジェクト計画を作るときにコストの制約を明確にします。
リスクマネジメントなど（詳細は別途書きます）を含めると、どこまで対応するからこのコストです、ということを決めますが、プロジェクトが進むにつれてだんだんそのコスト制約に対して怪しくなってきます。
いわゆる予算オーバー。
こうなると利益も出なくなったりして、やるんじゃなかった！！、と嘆いても一度受注したら止めれませんので、泣き寝入りか、その他の制約（スコープなど）を削るかなど、考えなくてはならなくなります。

2．時間
言わずもがなですが、これは言い換えると「納期」になるわけですが、時間というリソースは何者にも代えがたい最高に貴重なリソースです。
よく予算を見積もるときに、「人月」という単位を使います。
これは、人×時間、なので何人でどれぐらいの時間がかかるという単位です。
・10人月＝2人×5ヶ月
・10人月＝5人×2ヶ月
いずれも同じ10人月ですが、どちらがより信憑性が高いでしょうか？
あきらかに、2人×5ヶ月、です。
2人ならちょっと相談して解決できることも、5人もいたら会議をしなくてはなりませんし、そんなに大人数でたった2ヶ月しかないとしたらまとまるものもまとまらない。
つまり、人数を増やすより時間を延ばす方が確実に効果が大きい。
私の経験上、人数を2倍にしても成果は良くて1.4倍、時間を2倍にするともしかしたら2倍以上の成果になるかもしれない、ぐらい違います。
開発に遅れが出始めた時に、担当者にどうしてほしい？　って聞くと、ほとんどの場合、時間をくださいとか、納期を少し遅らせて下さい、と言います。10人月＝1人×10ヶ月、これが最高に効率が良く信憑性が高いと思います。

3．スコープ
これは直訳すると「範囲」ですが、基本的には要件のことです。
以下の投稿で、「何を作ればいいの？」が一番難しい、と書きましたが、まさにそのことです。

お客様の要件を聞いて要件定義書を書くというのが一般的ですが、まず「何を実現するか？」の中に、機能要件と非機能要件があります。
機能要件は分かり易いですね、どんな機能を実装するかなのでお客様に聞くと要望を言ってくれます。
非機能要件は、お客様に聞いても明確に答えてくれません。
可用性、拡張性、保守性、移行性、セキュリティ、環境、などです。
これらはシステムがどの範囲でどのように使われるかを考慮して、SEが決めて提案するのが一般的です。
それから、「やらないこと」を明確にすることも重要です。
例えば、「Windows Vistaは対象外」とか、「ADSLは非対応」とか、明記しておかないと、もしかしたらお客様は期待されているかもしれませんので、納品した後に、”なんでこれ使えないの？”とならないために事前に明確にしておきたいという事です。

これら3つの制約の上で、システムの要求品質を獲得してお客様が満足してもらえるサービスを提供する、これがプロジェクトの宿命なのです。
辛いですよね・・・。

次回は、プロジェクトに影響を与える3つの要因、の予定です。