アジャイル開発とWF型開発をハイブリッドにしたマネジメント・デザインパターン

アジャイル開発を日本風にアレンジしたプロセスをマネジメント・デザインパターンとして説明した記事があったのでメモ。

【参考】
ウォーターフォール開発とアジャイルの本質 - プロマネブログ

サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

炎上プロジェクトの責任はプロマネが９割 - プロマネブログ

【1】WF型開発とアジャイル開発には、それぞれの特徴があり、適用の問題点がある。

WF型開発は、仕様変更に弱く、無駄なドキュメントが多い。
アジャイル開発は、変化に強く、スピード重視で開発できるが、従来のプロセス手法と発想を変えないといけないので、実現しづらい。

上記の記事によれば、各プロセスの特徴は、「WFが形式知の作成を行うことで、開発体制と開発工程を管理する手法」「(アジャイル開発は)フォーカス管理の最適化」。

つまり、WF型開発は、体制と工程を形式知として残すために、ドキュメントを重視し、厳密に管理しようとする。

アジャイル開発は、イテレーション単位に開発するために、全工程を一気通貫で開発するので、小さい機能を実装対象にする。
すなわち、各工程はとても小さいので、形式知に残さずとも暗黙知でもやれる、と。
すると、「暗黙知をもつメンバーを如何に活かすか、という観点が重視されるようになり、スクラムなど各種手法が生きてくるようになります。」と、上記の記事では言っている。

【2】上記の記事で面白いのは、アジャイル開発とWF型開発を日本風にアレンジしたプロセスをパターンとして分類しようと試みていること。

【2-1】ウォーターフォールベースのスクラム／ウォーター・スクラム・フォール

「ハイブリッドアジャイルの実践」でも提唱されている手法。
要件定義などの上流工程はWF型開発、開発・テスト工程はアジャイル開発で分けて行う手法。

「スパイラルモデルに近く、SIerなどで導入しやすということで最近注目のデザインパターンです。」

確かに、日本のSIでアジャイル開発を実践する場合、ウォータースクラムフォールのパターンになる場合が多いだろう。
受託した開発案件が一括請負契約の場合、要件定義で開発スコープを顧客と握っておかないと、スコープクリープが発生してしまい、納期前に必ず破たんする危険が大きいから。
つまり、日本の契約スタイルでは、どうしても上流工程はWF型開発でやらざるを得ない。

【2-2】リーン開発のフォーカス管理を利用したウォーターフォール／リーン・ウォーターフォール

スクラムウォーターフォールとは逆に、上流工程をリーン開発、下流工程をイテレーション単位のWF型開発で行う手法。

「要求仕様をリーン開発と同様に分解、優先度付けを行い、優先度の高いものからWFで開発を行うことで柔軟性を高めたデザインパターンです。
開発部分を五月雨式WFなどと併用して更に速度を上げることもあります。」

SIの運用保守、保守案件では、工数が確定した委任契約になりやすいので、このパターンを使っている事例は多いのではないか。
なぜなら、予定している機能改良の作業だけでなく、突発的に発生する本番障害や問合せをやりくりするには、開発チームに作業指示を出す前に、やるべき作業をプロジェクトリーダーが優先順位づけしなければ、破たんしてしまうから。
プロジェクトリーダーが保守作業の内容を優先順位づけしておけば、開発チームはそれに従って作業を開始し、WFが開発のフローに沿って、設計書を書き、テストやレビューをきちんとやる、という流れになるだろう。

【2-3】複雑なシステムを分解／スクラム＆ウォーターフォール

要件定義をきちんと行った後、設計・開発・テストの各工程内でスパイラルに開発する手法。

「最初の要件定義だけを行い、要件のウチ変更の多い部分と変更の少ない部分を分け、それぞれを平行して開発するデザインパターンです。」

適用場面としては、初めてのフレームワークの技術検証や性能要件の事前検証などを設計工程で早めに行ってリスクを事前に洗い出し、開発やテスト工程で、判明したリスクをつぶしていく手法。
一部の画面やUIを開発して、顧客に事前に評価してもらうプロトタイプ開発もあるだろう。

つまり、技術リスクが大きい案件では、このプロセスを使って、リスクを事前に洗い出して潰していく戦略を取る時が多いだろう。

【2-4】期間短縮を目指した改良型ウォーターフォール／パラレル・ウォーターフォール

「WFとアジャイルのハイブリッドではなく、WF単体の組み合わせです。
前回、五月雨式WFを説明いたしましたので、オマケで。
ベースはWFですが、中間の開発～テスト工程を分割可能な機能単位などに分解し、並列開発を行うデザインパターンです。
純WFよりも、開発工程をパラレルにした分だけ開発期間短縮を行えることがポイントです。」

いわゆるパラレル・WF、ないし、五月雨WF型開発。
大規模案件を担当したプロジェクトマネージャで、経験が深い人は、サブシステムに分割し、五月雨形式で開発する手法を採用する時が多い。
結合テストでビッグバンテストを実施したら、障害を収束できなくなると気付いているから。

【3】上記4つのパターンは、日本のSIではおそらくどれも経験しているだろう。
アジャイル開発をそのまま実践できる環境にないけれど、アジャイル開発の利点を生かしたい時に、WF型開発をカスタマイズして変形するパターンとして、とてもうまくまとまっている。

上記の記事のパターン集が優れている点は、日本のSIでも既にアジャイル開発に近いプロセスは経験しているよ、とよく言っている事例をパターンカタログとして分類し、そのパターンの本質に焦点を当てている点だ。

経験知をパターンで整理するだけでは、オリジナリティはない。
それらパターンについて、適用範囲やその構造、効果や課題を整理し、単独のWF型開発とアジャイル開発に対して何が異なるのか、を深く掘り下げて考察することが大切だ。
その「考察」こそが、本来の研究だ。

上記の記事はラフに書かれているけれども、筆者の経験の深さを感じられる部分がある。
ただ、もっと考察できる部分があると思うので、いろいろ考えてみる。