勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

日本型ソフトウェアファクトリーこそ真の敵

最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。

最近アジャイル界隈でよく聞く話
「自分の現場がウォーターフォールで全然ダメで
 それをアジャイルなら変えられないかと思って」
いったい誰と戦っているんだ・・・・・・
History of WaterFall - Speaker Deck

真の敵はこいつだ!

ソフトウェアファクトリ
software factory / ソフトウェア工場 / ソフトウェア生産工場
 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、このアプローチを具体化するための開発環境、あるいは設備や組織体制をいう。
(中略)
 ソフトウェアファクトリの定義や具体的取り組みは一様ではないが、ソフトウェア開発に必要な技術・知識・設備・人員を集約して利用効率を高め、工程・作業・ツールを標準化して非熟練作業者の戦力化を図るとともに、厳密な工程管理と品質保証・品質管理を適用して品質を維持するというのが一般的なアプローチである。
ソフトウェアファクトリ(そふとうぇあふぁくとり):情報システム用語事典 - ITmedia エンタープライズ

リリースライフサイクルとしてのウォーターフォール

リリースライフサイクルとしてのウォーターフォールはひとつの選択肢であって、プロジェクトのリスクの考え方などによって選ぶものだ。たとえはManage It! 現場開発者のための達人式プロジェクトマネジメントではこんなように整理されていて参考になる。

ライフサイクルの種類 この種類のライフサイクルの例 長所および成功に必要な条件 プロジェクトの優先順位 成功の見込み
逐次型 ウォーターフォール、フェーズゲート ・コストのリスクを管理できる
(経営陣がフェーズゲートを使用する場合)
・既知かつ合意済みの要件
・システムアーキテクチャをよく理解できている
・プロジェクトの過程で要件が変動しない
1.機能セット
2.欠陥の低減
3.リリース期日
フィードバックが得られれば成功する
反復型 スパイラル、進化的プロトタイピング ・技術的リスクを管理できる ・要件が進化しつづける 1.機能セット
2.欠陥の低減
3.リリース期日
仕上げの段階が計画され、計画通りに実行されれば成功する
漸進型 スケジュールに応じた設計、段階的納品 ・スケジュールのリスクを管理できる
・要件の小幅な修正を吸収できるが、アーキテクチャに影響を与える変化には十分に対応できない
1.リリース期日
2.欠陥の低減
3.機能セット
成功する
反復/漸進型 アジャイルスクラム/XPなど) ・スケジュールのリスクと技術的リスクの両方を管理できる
・すべてのメンバが同一サイトで作業を行える
・統合チーム以外では円滑な進行が難しい
1.リリース期日
2.機能セット
3.欠陥の低減
成功する
場当たり型 コードアンドフィックス - 1.リリース期日
2.機能セット
3.欠陥の低減
成功しない

ただ、今のご時世だとウォーターフォールの前提である要件の変動リスクが大きくなっている。だから他のライフサイクを選択すべきときにもウォーターフォール固執してしまうと悲惨なことになる(もちろん逆の場合もある)。

問題は、ウォーターフォール開発とソフトウェアファクトリー型のアプローチをとってきた組織(所謂SI屋)が他のライフサイクルモデルを選択することができない、というところにあるのではないか。

ソフトウェアファクトリー型アプローチの問題点

冒頭で紹介したソフトウェアファクトリーの定義を読めば改めて整理するまでもないが、ソフトウェアファクトリー型アプローチに長期間取り組んできた組織は以下のような問題を孕むだろう。

  • 開発者の熟練度が低い。熟練度がビジネス的に重要なパラメータではないから、熟練度を上げることに力を入れない。
    • 開発者の教育は「トラブルを起こさない程度の能力獲得」を主眼に行われる
    • 開発者のキャリアパスなどにはもちろん注意が払われない
    • プロセスやツールの改善、ノウハウの集約などには力が入れられる(ただし、効果があるのかは別の話)
  • ライフサイクルとしてウォーターフォール以外を選択できない。他のライフサイクルでは品質保証が難しくなるから
    • 技術・知識・設備・人員の集約がポイントになるので、集約が成立しないプロセスを選択できない
  • 非熟練者をプロジェクトによって調達し、プロジェクト終了時にはリリースすることになるため、自然と外注主体の体制となる
    • 自社で大量の技術者を抱えることはリスクとなるため
    • 結果として多重請負の構造に最適化されていく

たしかにその現場はダメだ。

ソフトウェアファクトリー型でない形のウォーターフォールはどうなんだ

じゃあソフトウェアファクトリー型でない形のウォーターフォールはどうなるのだろう。

  • 前提として要求の変動リスクが小さいこと
  • 熟練者で構成されている
  • 実績のあるアーキテクチャ
  • 熟練者を想定した必要最小限のドキュメント
    • 後続のプロセスのインプットとして十分なもの
  • 実効性のある計画と必要最小限のプロセス
  • 要求の変動に応じた細かいコスト管理

どうだろう。この現場はダメだろうか?
けっこうイイかも?

ウォーターフォールを選ぶとき

冒頭で紹介したHistory of WaterFall - Speaker Deckの結びでは反復型ウォーターフォールによる改善を提言しているのだけど、ちょっと違うと思っている。どんなに工夫してもウォーターフォールを選ぶべきではない場合もあるし、その逆もあるだろう。そこらへんはアジャイルと規律にチェックリストがあったような気がするが、その紹介はまたどこかで。