まだ会社にいたときに「なぜ、週40時間にこだわるのか？」と何度か上司に聞かれたことがあります。そのころはXP（エクストリーム・プログラミング）が始まったころで、当時はそのプラクティスのひとつとして「週40時間勤務」が重要だったのと、来日したケント・ベック氏に勢いで「ケント・ベック氏自身は勤務時間40時間を守れているのでしょうか？」と質問したときに、「文章書きのときは守れていない。けど、プログラミングをするときには週40時間が必須！」と強調されたから、という理由があったわけですが、実はもうちょっと別な根拠があります。
その後、日本のIT業界は少し不況に入ったので、仕事が減り少しずつ勤務時間も改善されてきたので、週の勤務時間にこだわる必要もなくなったのですが、たまに「炎上プロジェクト」をみるので、勤務時間の話を書き残しておきます。
正確な事前見積もりをあきらめる
大抵のプロジェクトで「炎上プロジェクト」（あるいはデスマーチプロジェクト）となるのは、事前のスケジュールミスが問題です。昨今の炎上プロジェクトはITプロジェクト自体が短期化しているところもあって、短い時間の中に開発を詰め込みすぎ、人数が足りなくて「炎上」ということが多いです。炎上とは言え、プロジェクトは完了します。たまに、大規模プロジェクト（IBMの特許プロジェクトのような）で炎上後にプロジェクトが崩壊するパターンもありますが、数か月から半年以内のWebプロジェクトやシステム開発のようなものは、炎上しつつも、なんとか納品するという（スケジュールは伸びるかもしれませんが）という結末を得ることが多いです。
半年以下のプロジェクトの場合、週で言えば、24週間になります。契約がうまく移動できるスクラムや顧客を含めたチケット駆動で行っている場合は、金額やスケジュールの調節でうまくできるかもしれませんが、たいていのプロジェクトでは、事前に金額やスケジュール（納品日）が決まっていることが多いです。
納品日がずれると、検収日がずれるので会社としては集金日がずれます。と同時に、伸びた分だけ社員に給与を払うことになります（派遣ならば、派遣先に延長を申し込むことになる）。この増加分や遅延分を顧客が支払ってくればよいのですが、そうもいきません。
その昔、ファンクションポイント法（FP法）などで見積もりの正確さを求めいた時期があるのですが、最近のアジャイル開発を含めて計画駆動でさえ、正確な事前の見積もりはうまくいきません。本来ならば概要設計まで行って機能別に見積もりをしたいところですが、事前の要件定義すらぐらぐらなところがあるので、そのぐらぐらの事前条件に使って概要設計をして精密な見積もりを出しても意味はありません。
アジャイル開発においては正確な事前見積もりを清く諦めます。諦めて、プロジェクトが進む中で機能の増減やスケジュールの遅延などを調節していきます。が、果たして、日本のIT業界の現状としてはそれはできないことが多いのです。
概算であれ事前の見積もりが求められ、ざっくりとした見積金額がそのまま正式な金額になりがちで、さらにサービスリリース日は顧客の営業の都合で決められることが多く、開発側の都合だけで金額も開発スケジュールも決められるものではありません。
プロジェクト予算とスケジュールを固定化する
以前にも何度か話していますが、プロジェクトの予算については二重帳簿方式を使います。二重帳簿というと聞こえは悪いですが、まあ、仕方がないです。
- 顧客に提示するプロジェクト予算
- 社内で開発するときのプロジェクト予算と実績
顧客や営業先に用意する「プロジェクト予算」は、見積もりを提示した突端に固定化されます。割引交渉で減額されることはあっても、増額されることはまずありえません。機能はそのままで、割引を要求されることも普通にあります。これは、営業の値段交渉のうちなので、実装するときの機能とは切り離しておくとよいです。
つまり、切り離したところに、実績としてのプロジェクトの内部予算があります。実際に社員や派遣さんなどが働いた工数を積んで、具体的に払う金額つまりプロジェクトで利用した金額を積み重ねていきます。
同時に、顧客に提示するスケジュールも提示した途端の固定化されます。納品日あるいはリリース日が決定されると、プロジェクト開発において前に倒すことはあっても後ろに倒れることはあり得ません。ごめんなさいするしかない場合は、後ろに倒れますが。
ここで「プロジェクトバッファ」を取って、プロジェクトのスケジュールを立てたいところですが、もう少し泥臭い方法があります。プロジェクトのバッファの方式は、バッファ自体を食いつぶさないの注意しないといけません。これは、チケット駆動やスクラムとの併用も可能（PMBOKにも指針があります）なのですが、常に「学生症候群」（夏休みの宿題を後ろに残すあれ）を気にかけてチームマネジメントをしないといけないので、途中で機能が増減する場合は、なかなかハンドリングが大変です。
プロジェクト計画時に月160hで計算する
小規模のプロジェクト（5,6名程度）で期間が半年以内のプロジェクトに限定するものですが、プロジェクトメンバの勤務時間を柔軟にすること（残業も含めてという意味で）を前提にして、プロジェクトのスケジュールを立てます。
このとき、週40時間、月160時間で見積もりをします。稼働日数を22日にしたり、忙しい月だからといって稼働時間自体を月200時間で計算してはいけません。あくまで、週40時間、月160時間で統一的に計算してしまうのがミソです。
プロジェクトバッファ（「保険」とも言う）の仕組みは簡単です。
- 通常は、週5日で8時間勤務で行う
- 少し忙しいときは、週5日で10時間勤務（2時間残業）で行う
- 炎上間近のときは、週6日で10時間勤務、土曜出勤日曜日は休みで行う
こうすうことによって、週40時間が、少し忙しめのときは2割増し、炎上ぎりぎりのときは1.5倍のときの開発時間を確保できます。休日を外さないのは、継続的に１か月以上働けるのはこれが限界だからです。その後に燃え尽きてしまいますからね。
このように、月160時間でプロジェクトの期間見積をしておくと、機能追加や見込み違いなどでも同じメンバーで1.5倍までは開発期間を確保できます。
逆に言えば、1.5倍を超える場合は、人員を確保しないと駄目≒予算が増える、ということです。本来ならば残業代が増えるのですが、それは会社によりけりなので。
また、あらかじめ Google の 20% ルールを採用しておいて、繁忙期には20%ルールを外してもよいというルールにしておきます。フリーランスでだらだらとやっている身ですが、本の執筆や開発が混ざったときはこのパターンを採用していますね。お試しあれ。
