WF型開発におけるプロマネのテクニック

WF型開発におけるプロマネのテクニックを見ると、アジャイル開発に似ている部分もあれば、異なる部分もある気がした。
考えたことをラフなメモ書き。

【1】段階リリース、一定期間の仕様凍結、部分稼働
Twitter / @akipii: WF型開発における段階リリース、一定期間の仕様凍結、部分稼働、低リスクの都度対応はプロマネが良く取る手段だが、それはアジャイル開発につながるのか？多分アジャイル開発とは本質的に異なると直感している。

Twitter / @MyTH774: @akipii リスク受容が事前に行われるか事後あるいは暗黙に行われるかの違いかと。後者の方が発注側の開発結果から直接利益を受けない担当者からは予算ありきで主導権を握ることができるので好まれますね。

Twitter / @MyTH774: @akipii 社内システム開発を想定しています。そこで担当者は工期と予算の変更について必ず説明責任を負うが効果については融通が利くことがあります。WF型でリリースできたことにし立ち入った問題解析と責任を回避しつつ恩を着せるというあまり気持ちのよくないでもままある構図かと思います

WF型開発でもアジャイル開発のように、システム対象をフェーズ化して分割してりりーする「段階リリース」という手法が存在する。
段階リリースでは、1～3ヶ月単位でサブシステム単位にミニWF型開発を行う手法。
段階リリースは、プロジェクトマネジメントの経験が豊富なプロマネがよく取るテクニックの一つ。
1年以上かけてシステムを工程単位に開発していくのはやはりリスクが大きいからだ。

だが、段階リリースのテクニックはアジャイル開発とは本質的に異なると思う。
何故なら、アジャイル開発では、イテレーションと言う1ヶ月のタイムボックス内では、工程単位の開発スタイルではなく、設計も開発もテストも同時並行で作業しているから。
段階リリースのタイムボックスを3ヶ月、2ヶ月、1ヶ月、3週間とどんどん短くしていけば、ミニWF型開発を実施できる限界が来て、そこで破綻するか、アジャイル開発のように全ての作業を同時並行で作業するように変わるしか無いだろう。

また、段階リリースの場合、最後の工程である総合テストやシステムテスト、受入テストで、仕様凍結の期間が設けられる。
最後のテスト工程で、仕様変更が起きると手戻り作業が発生して納期が遅れる可能性もあるし、せっかくテストで仕上げた品質に修正したソースのバグが紛れ込んで品質が劣化する可能性もあるからだ。
つまり、仕様凍結の期間は、顧客のバックログが貯まるだけで消化されない期間になる。
この点はアジャイル開発とは根本的に違う。

そして、WF型開発では、バグ退治に一括修正する期間を設けるパターンが多い。
バグの都度対応ではコストがかかるだけで完全根治が難しいから、全てのバグを確定した後に要員を一気に投入して解決する手法をよく取る。
アジャイル開発は継続的に機能改善やバグ修正を行っていくから、都度対応を実施している事と同じゆえに、全く異なる。

また、納期遵守が厳しく、どうしても全ての仕様を実現できない場合、システムの部分稼働という手段もよく取られる。
つまり、顧客の業務に必要最低限の機能は本番稼動させるが、低頻度の性能要件や重要度の低い機能は2次開発で対応する手法だ。
例えば、トランザクション量が増えると機能要件すら満たさなくなる場合は非常に危険だが、そのリスクが1年後に発生すると分かるならば、今すぐに対応する必要はない。
@MyTH774さんが言うように、まずはシステムが部分稼働であれ本番稼動したことを顧客に恩に着せて、その後、性能要件や未実装の機能要件を実現していく構図はとても多い。

【2】プロジェクトオーナーやプロダクトオーナーの権威を利用する
Twitter / @akipii: プロマネの手法として、事態打開のためにプロジェクトオーナー(SI側の決裁権限を持つ上司。多分部長クラス)やプロダクトオーナー(顧客側の決裁権限を持つ上司)へ直訴する回答が多い。Agile開発であれWF型開発であれこの手法がいつも有効なのか、疑問に思う。

例えば、現場リーダーがプロジェクトを運営していてどうしても人が足りないケースや予算が足りないケースでは、自分よりも格上の上司(プロジェクトオーナー)に人員投入や予算増額を決裁してもらわないといけない。
あるいは、顧客サイドから膨大な要件があり、予算や納期の都合上全てを実現できない場合、顧客サイドの責任者(プロダクトオーナー)と調整しなければならない。
あるいは、顧客企業の窓口が一本化されておらず、あちこちの部署から要望が開発側へ来る場合、変更管理の手順を守ってもらうように顧客側の責任者(プロダクトオーナー)へ要請しなければならない。

この内容については、プログラマにコミュニケーションが足りないと言われる時: プログラマの思索で書いた。
WF型開発では、顧客側も開発側も体制が複雑な階層構造になっているため、この種の調整が非常に難しい。
だがとても重要な作業なので、放置されるとプロジェクト破綻のリスクが高まる。
Agile開発では、顧客側はプロダクトオーナー又はオンサイト顧客という役割で窓口が開発側に近く、舵取りはWF型開発よりも楽な構造になっている。

【3】稼動実績のあるシステムを流用
Twitter / @akipii: プロマネの手法として、運用実績のあるシステムやモジュールを流用してプログラムをコピー＋新規で作り、カスタマイズする手法が良く取られる。確かに当初リリース時の品質はいいだろうが、似たようなPGMが増えて保守性が悪くなるし最新の技術を取り入れにくい。そんな手法を取ってよいのか？

WF型開発では、既存の業務システムのプログラムを流用して、コピー＋新規でプログラムを作る手法をよく取る。
何故なら、既に本番運用されているプログラムはバグが少なく、品質が安定していると思われるからだ。
この種の品質を運用品質と呼び、テスト工程を通過した品質はテスト品質と呼んで区別している。

だがこの手法は、クローンプログラムを増殖させて、リファクタリングしにくくなる危険性があると思う。
また、最新のフレームワークや技術を反映しづらくさせる弱点があると思う。

【4】システムのフィージビリティスタディー(実現可能性検討)
Twitter / @akipii: 提案や要件定義でアーキテクトやSEは、システムのフィージビリティスタディー(実現可能性検討)の説明責任を顧客に対して負う。プログラマはシステムの完成責任を顧客に対して負う。アジャイル開発ではフィージビリティスタディーはどのように解決されるのか？

システム提案時に顧客に大きな夢を語り、要件定義でシステムの概要を煮詰めて、外部設計でシステム対象を確定させる。
その時、システムをどんな方式で実現するのか、というフィージビリティスタディー(実現可能性検討)をアーキテクトが中心になって外部設計で固める。
その外部設計終了時に再見積を実施して、開発金額や納期を確定させて、開発の請負契約を締結させる流れがWF型開発では一般的。

アジャイル開発では、システムのフィージビリティスタディー(実現可能性検討)をどのフェーズで実現するのか、あるいは誰が責任を持っているのか、という話はあまり議論されていないように思う。
基本は開発チームがイテレーション単位に開発していくから、開発チームがシステムのフィージビリティスタディーもシステムの開発も責任を持つ。
その意味では、開発チームの責任はとても重い。
既にフレームワークなどの方式要件が決まっていれば、アジャイル開発はとてもスムーズに行くが、それすらも曖昧な場合、作っては壊して検証していく開発スタイルになる。
その開発スタイルがどこまで通用するのか、はやってみないと分からない。