リリースを間に合わせる方法 -プロセスのリエンジニアリング-

納期は延ばせるがスコープとリリース時期だけは守らないといけない場合に、どのような手段がとれるかを整理しました。

見積もりを減らして無理な線を引く

作業の効率化なら良いのですが、バッファもとらずに「なんとかなるだろう」で計画してうまくいくはずがありません。詳細でなくても具体的に検討した結果で計画すべきです。方策がないままに、無理な期間で開発はできません。見積もりを減らすなら、開発する機能を減らして工数を削減すべきです。

残業を見込む

残業を見込む事でも、全体スケジュールを短くできます。しかし、残業を見込んでしまうとイザという時にトラブル対応ができなくなるほか、健康への不安が出ます。どうしても残業を見込むなら、休日出勤を計画した方がマシだと思います。休日出勤を避けようと平日の深夜残業で乗り切ろうとして体を壊してしまうからです（休日出勤と深夜残業の両方を計画する事が論外である事は言うまでもありません）。

人を増やす

問題の発覚した時期が比較的早い時期であれば、タイミングを見計らって増員すれば、立ち上がり教育や情報共有などの工数を考慮しても期間的にはうまくいくかもしれません。なるべく効率的に増員するには、その回数を減らしてなるべくトレーニングをまとめる。単純作業や汎用機能など、独立した作業を切り出す。過去の経験者に手伝ってもらって教育工数を削減する。という方策をとれば、成功の可能性を高くできるでしょう。開発の後期になるとトレーニングのコストの吸収が困難になり、単純作業もあまりなくなりますので、客先へのアピール以外のメリットはあまりなく、逆効果になる可能性も高いでしょう。

品質作業をショートカットする

CMMを提唱したHumphrey氏とKellner氏の論文に、書かれている悪い方策です。リリースのプレッシャーに負けて品質作業を省いてしまうと、結果的に良い事はありません。リリース後のバグ対応はリリース前よりも緊急度が高くなりますので、まとめて対応する事もできないので繰り返しのリリース作業が必要で、膨大なサポート工数が必要になるでしょう。あまりにも品質が悪い場合はサービスを停めざるを得ないので、補償問題も発生するかもしれません。

段階リリース

開発の後期や小規模開発では、結果的に段階リリースしかないと思っています。回数を増やすとリリースの工数がかかりますし、リリース後のサポートと本来の作業を並行に実施しないといけません。その反面、増員しないことでトレーニングや情報共有の工数がかからない方法です。

段階リリース計画時に行うプロセスのリエンジニアリング

段階リリースをすれば必ず成功する訳ではありません。計画時に合理的で実現可能なプロセスになるように、下記の作業を繰り返してプロセスをリエンジニアリングします。

(1) 全体工数を確認する
まずは、全体工数を確認します。もし、納期までの期間に入らなければ、納期の変更や増員を検討します。納期の変更は時間がかかる事もありますので、概算で納期に納まる事を先に確認しておきます。増員の場合は、単純作業を切り出せしたり、トレーニングや環境準備などの立ち上げるための工数も必要です。

(2) 各リリースに必要な作業と納品に必要な作業を分ける
見積もった作業を各リリースに必要な作業と納品に必要な作業を分けます。デプロイなど、各リリース毎に作業が抜けていないかも確認します。作業分類の際は、従来よりも細かな作業に分ける事も検討します。詳細設計しないと実装できませんが、DB設計やUIの設計ができているなら、クラス図とシーケンズ図から実装をすすめられるかもしれません。プロジェクトに合わせて実現可能な作業分類をします。

(3) 線表を後ろから引く
それぞれの作業の依存関係を考慮して、リリースや納品から担当者を決めながら、後ろからスケジュールを引いていきます。再度、(2)のリリース毎の作業を見直しても期間に納まらないなら、リリース時期の変更が必要です。

(4) 全体を調整する
担当者ごとの作業を見直して、負担の平準化をします。リスクの高い作業が特定の担当者に集中せず、能力に見合わない作業が割り当てられないように確認します。適宜、担当者にも相談しておき、緩いコミットメントを得ておくと、後の混乱を避ける事ができます。

段階リリースの効果

段階リリースはリリース工数が増えるなどの負担が増える反面、増員をなるべく避けながらリリースを守る事ができます。また、開発作業のサプリング（クヌース先生の本の選び方）でもありますので、

• 初期のリリースをもとに横展開して、リスクの低減と手戻りの削減ができる（大規模なプロトタイピング）
• リリースした内容をもとに利害関係者と納品に関する具体的な合意形成ができる
• テスト段階での不良の先取りである「探針」(ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点 参照)のように、品質の予想や改善に利用できる

といった効果があります。

おわりに

前回はクリティカルチェーンと小規模プロジェクトの観点から整理しましたが、今回はプロセスプログラミングの観点で整理してみました。

プロセスをリエンジニアリングする場合、それが開発標準で許されるテーラリングできるかを確認してください。利害関係者との調整が必要かもしれません。

また、どのような作業が必要かをきちんと理解していないとリエンジニアリングはうまくいきませんし、トップダウンのコマンドコントロールでは難しいことも注意が必要です。チーム内の合意を得ながら最大限の能力を発揮して、強いチームを実現すれば、きっとうまくいくでしょう。