無料ブログはココログ

« 軽量、自立、手帳型 iPhone 6 plus ケース(701円)購入記 | トップページ | リリースを間に合わせる方法 -プロセスのリエンジニアリング- »

クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

小規模開発の難しさは独特です。これまでも問題点の指摘と解決法が提案されてきました。

改善に書けられる工数が少ない

プロセス改善ブームの前、多くのヨレプロジェクトが予算の2倍を消費していた頃は、会社の存続を左右する大規模開発に比べて被害が少ないので、小規模プロジェクトはあまり関心を持たれませんでした。やがて、大規模プロジェクトが統計的な手法でうまくいくようになると、小規模プロジェクトの被害が無視できなくなりました。

しかし、小規模プロジェクトでは改善の工数を大きく割く事が困難で、標準プロセスを管理する独立したSEPG(Software Engineering Process Group)を作る事も困難です。そこで行われたのは、大規模システムで行われている管理手法の簡素化です。標準プロセスをシンプルにすることと、自律的な改善活動でした(VSEセンター:資料ダウンロード)。

外乱による変動が大きい

しかし、小規模プロジェクトの難しさは、改善の工数が少ないだけではありません。規模が小さいので外乱による影響を受け易いのです。

環境、実現方法、業務ドメインの未知の問題が発覚すると、プロジェクトはその対応に追われます。脆弱性対応など、外乱による問題は規模に関係なく同じように理解と対応が求められますので、知識と経験の蓄積が必要とされます。

増員が難しい

このような問題を認識しても、まだ小規模プロジェクトの難しさの本質を表現できずにいました。先日、CCPM(リンク先はWikipedia)におけるクリティカル・チェーンの定義を見ていて、増員できない事が問題を難しくする事に気付きました。

大規模プロジェクトでは、クリティカルパス法やPERT法のように「作業員を雇用することが容易」という前提を置く事が可能です。しかし、小規模プロジェクトでは

  • 増員によるコスト増加の比率が高い
  • 教育コストの比率が高い
  • 一人分の初心者向け作業を切り出すことが困難

といった理由から、増員が困難です。このことで、「作業工程上の従属関係」だけでなく、クリティカルチェーンの様に「必要リソースが限られているために発生する従属関係」の考慮が必要になります。

リソース制限による難しさ

例えば並行して実行可能な2、3、4人日の作業A、B、C、があった場合、3人で実行すれば最短の4日で完了できますが、メンバーが2人なら最短で5日かかります。これを4.5日でとりあえず動かして欲しいと言われたなら、どのような対応ができるか考えてみましょう。

増員:トレーニングに1日かかるなら、指導1日もかかるので、3、4、4日となって4日で終わらせる事ができる反面、2人日の追加工数が必要です。このようにうまく配員できるかどうかという問題もあります。

手伝い:半日分の作業をもう一人に手伝ってもらえるなら、何とかなりそうです。しかし作業に専門性があるなら、その理解に必要な時間分は、はみ出てしまいます。

共通化:まだまだ上流なら、作業や構造の共通化で何とかなるかもしれません。でも、すでにきちんと設計されていたなら、難しいでしょう。

作業をショートカット:テストを端折ってでもリリースして欲しい。というお話を聞く事もありますが、障害対応に必要な作業で他の作業ができなくなりますので、一番危険な方法です。

後回し:保守用ドキュメントはリリース後に回すなど、作業内容を精査してリリースに必要な作業だけを実施します。リリースの目的が他のモジュールとの結合テストなら、有効な方法かも知れません。

以上の方法を考えると後回しが有効だと思われますが、開発標準に抵触する可能性がありますし、全体の作業内容を良く理解していないと混乱を生じる可能性があります。

残業というバッファ

クリティカルチェーンの正攻法はCCPMのように、あらかじめバッファを確保する事、他の作業からリソースを回す事です。本当に使える開発プロセスで書かれているように、大規模プロジェクトでは理想見積もりの1.5〜2倍の予算を確保してスケジュールがきめられるので、バッファをとれるかもしれません。

しかし、小規模プロジェクトの場合は、発注側が詳細な作業内容を把握しています。このため、理想見積もりを基準に予算が確保され、スケジュールを決められる傾向があります。

そこで小規模プロジェクトでは、残業時間がバッファになりがちです。スケジュールが厳しいからと、あらかじめ残業が見込まれてしまうと、さらに打つ手が限られてしまいます。

小規模プロジェクトの難しさ

そこで、いざとなれば開発標準をよく理解して、顧客との合意が可能な範囲で作業の最適化を行い、優先度の低い作業や手戻りの可能性のある作業を後に回すといった柔軟さが求められる事になります(Win-Winプロセス(ウォータフォール編)追記)。

このような方策は作業のショートカットと紙一重です。作業間の関係を理解した上で、独自のプロセスを構築する。そのようなアクロバティックな難しさが小規模プロジェクトには存在します。

クリティカルチェーンの定義から小規模プロジェクトの難しさを考えてみました。小規模開発では、改善工数の制約や外乱の影響を受け易いほか増員が困難で、クリティカルチェーンの特性であるリソースの制約があります。そこに予算とスケジュールの制約が加わるので、独特の難しさが生じているのだと思います。

このエントリーをはてなブックマークに追加

« 軽量、自立、手帳型 iPhone 6 plus ケース(701円)購入記 | トップページ | リリースを間に合わせる方法 -プロセスのリエンジニアリング- »

ソフトウェア」カテゴリの記事

チケット駆動開発」カテゴリの記事

プログラミング」カテゴリの記事

私のアジャイル」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« 軽量、自立、手帳型 iPhone 6 plus ケース(701円)購入記 | トップページ | リリースを間に合わせる方法 -プロセスのリエンジニアリング- »