[#TiDD] ウォータフォール型開発の問題点とチケット駆動開発 #seakansai

SEA関西プロセス分科会「 価値ある製品を生み出すためのアジャイル実践ポイント」に参加しました。講師は 日新システムズに移られた前川さんと陸野さん。実践のお話から、チケット駆動開発に関してもより深く考えることができました。

講演は前川さんが共著されたわかりやすいアジャイル開発の教科書を踏まえて、前川さんと陸野さんの経験を語られました。

教科書的な内容を経験談をあわせるといくつか気になるところがありました。それは教科書的にアジャイル開発の対比として扱われるウォータフォール開発(WF)が現実よりもシンプルなことです。お２人の経験を踏まえると、WFの問題点は以下の様になると思います。

a. WFは変更を受け入れすぎる

アジャイル開発は変化を受け入れるがウォータフォールは受け入れない。そんなことはありません。アジャイル同人誌 UAS5のアジャイル放談でお話しした通りです。WFでは変更管理はするもののそのプロセスが重く、任意のタイミングで発生するので混乱しやすいと言う問題があると思います。前川さんの経験でもアジャイル開発導入前は変更要求で混乱していたそうです。

b. WFでもリリースは1回とは限らない

前川さんの事例ではアジャイル開発導入前も納品と最初のリリースが一致しません。リリースが1回ではすまないことが多かったとのこと。また、開発中にも色々な人が途中で見せるように内部リリースを求めてくるので、混乱に拍車をかけたそうです。

c. WFのチーム作りの理想はアジャイル開発と同じ

陸野さんのチームビルディングの説明では、CMMを提唱されたハンフリーさんのTSPガイドブック:リーダー編から引用して説明されました。この本の内容は私が100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊に「リーダーに求められる大切な事」(原稿が読めます)として、サーバントリーダーシップに求められることを引用した本です。

これらを踏まえて他の問題を考慮したWFの問題点と解決策を考えてみました。

1) 変化を受け入れる標準的なタイミングがない

スクラムで言うスプリントはいわばクリティカルセクションで、変更要求から開発チームの「集中」を守ります。
以前に壁の溝で例えた様に変更の受け皿を作る必要があると思います。また、変更要求を前倒し(フロントローディング)できる様に、適切なリリースを作らないといけません。前川さんのアジャイル開発の事例では、複数回リリースすることで変更要求を早期にだせるので、変更からチームを守られているようでした。

2) ロールが多く、構造が悪い

WFでは、マネージャ、リーダ、SQA、品質保証、SEPGのほか、営業や関連部署などが介在することが多く、各ロールの専門性が高いのでそれぞれに教育が必要です。また、それぞれが協調しないとうまくいきません。

スクラムのように組織パターン (Object Oriented SELECTION)の門番や防火壁などを用意して、開発チームへの介入をシンプルにする必要があるでしょう。

3) コミュニケーションが複雑

管理中心にプロセスが構成されていて、チーム内で協力できる様なコミュニケーションが支援されていません。 チームはコマンドコントロールでなく、サーバントリーダーシップによって自律的に行動できるような支援が必要です。

前川さんと陸野さんの発表ではタスクボードを理解した上で、チケット駆動開発を導入されていました。チケット駆動開発では管理のプロセスだけでなく、それ以外の現場プロセスが詳細に見える化されますので、サーバントリーダーシップで活発になったチーム内のコミュニケーションを支援することができます。

4) マネージメントが難しい

WFでうまく開発するにはマネージャやリーダの協力が必要なほか、適切なマイルストーンやリリースの設定される必要があります。また、多くのステークフォルダーと調整しつつ、組織レベルでは規律で管理し、現場レベルではサーバントリーダーシップを発揮しなければいけません。上下関係もあるので、かなり難しい仕事です。

スクラムでは組織パターンで問題を単純化してプロダクトオーナが門番、スクラムマスタが防火壁になります。この点はチケット駆動開発でも意識してワークフローを考えないといけません（必ずしもITSのワークフローで制限しなくて構いません）。

5) スピードが遅い

WFのリスクを考慮したスパイラルモデルでは、部分的なプロトタイピングを取り入れましたが、1回のループ半年から２年と長いものでした。これは変更のリスクだけを考慮してプロセスを再構築したからだと思います。

アジャイル開発ではソフトウェア開発のリスクを見直して、プロセスの優先順位を決めて（アジャイルソフトウェア開発宣言）最適化したので開発スピードを上げることができたのだと思います。

ということで、組織パターンの実現、教育、プロセスの最適化の考慮は必要ですがが、アダプタブルWFで（ウォーターフォール型開発をアダプタブルにする３＋１）もかなりいけるのではないかと思いました。アダプタブルWFの詳しい解説は アジャイル同人誌 UAS5にも書きましたし、SQiP2015の併設チュートリアルでもお話しします。

なお、アジャイル同人誌 UAS5 はXP祭り2015でも頒布される様です。
XP祭り2015にてUltimate Agile Stories頒布 - Yasuo's Notebook