「ウォーターフォールとアジャイルを考える」に参加しました

2016/6/21(火) 「ウォーターフォールとアジャイルを考える」に参加してきました。

connpass
http://ita-ws.connpass.com/event/32899/

Togetter
http://togetter.com/li/990231

場所は新宿のグロースエクスパートナーズ株式会社さんです。
参加者は８０人くらいでしょうか。

先日5/18(水)、 "「アジャイルがダメだと思う7つの理由」について議論する会"に参加しました。
そんとき書いたブログはこちら。
http://makopi23.blog.fc2.com/blog-entry-214.html

たしかのこのイベントの後、雄介さんがこの会を提案していたように記憶しています。
ネタ的に繋がってますね。

あと、今回のイベントについて、後日、雄介さんがブログに書いてます↓

ウォーターフォールとアジャイルを考える
http://arclamp.hatenablog.com/entry/2016/06/23/172941

以下、スライドに無い口頭説明を中心に、当日取ったメモを書き起こしてみる。

---

講演

ウォーターフォールとアジャイルを考える #ita_ws from yusuke suzuki

はじめに

• 今日は方法論の話に特化する。WFとアジャイル、どっちがいいかは後半のディスカッションで。
• アーキテクチャの話はちょっと入れて、最後に例の牛尾さんのブログに触れる。

プロジェクトマネジメント

• プロジェクトの定義で「有期性」がよく言われる。対として、「プロダクト」がよく言われる。
• プロダクトのライフサイクルが終わるまで継続する活動。

失敗あるある

• 計画の失敗
• 実行の失敗　・・・　スキルセットが合わなくて計画どおりに作れない。
• 計測の失敗　・・・　進捗８０％です、の報告のまま１週間経つ、みたいな。
• 調整の失敗　・・・　明らかに遅れてるのに何も手を打たない。
• PMはこのPDCAをどう上手くやっていくのか、というのが大事。

PMBOK

• PMBOKは今年２０年目。ソフトウェアのために作られたわけではなく、製造業のためにアメリカで策定された。
• ９０年代からプロジェクトマネジメントはこうあるべき、と整備されてきた。

ウォーターフォールの表　（P.11）

• 横の５個（立ち上げ、計画、実行、監視・コントロール、集結）がプロセス。
• 縦の１０個（統合、スコープ、時間、コスト、品質、・・・、ステークホルダー）が管理領域。
• PMBOKは今見ても面白い。網羅的に書かれている。ちょろっと見るだけでもおすすめ。
• 計画・実行・調整を回していく。

PMBOK： ５つのプロセス

• 計画プロセスにやることがいっぱいある。

PDCAをフェーズで管理する

• PDCAをフェーズで管理するのがPMBOKで大事なポイント。
• プロセスや知識領域よりは、フェーズというのが大事。
• 大事なのは、フェーズを管理すること。
• 要件定義、設計、実装、テスト、・・・
• そのフェーズを決めて、フェーズごとに完了判定をしながら次へ進んでいく。

ウォーターフォールあるある

• フェーズが完了していないのに先に進む
  • 計画が正しくない、実行に失敗、とかはあるが、フェーズが完了していないなら戻れ、は大前提。

アジャイル

• ウォーターフォールへの反省が活かされている。時代背景もそう。
• PMBOKが出たのが１９９６年なので、それより前の１９８０年代から議論があったはず。
• １９９０年代には「プロジェクトマネジメントはこうやるんだよ」というのが固まってきて、「それってイケてないよね」でアジャイルが出てきた。
• ウォーターフォールは計画が失敗すると、実行、計測、調整は漏れ無く失敗する。
• なので、ウォーターフォールは「最初の計画」がある程度正しい必要がある。
• バイアスがどうしてもかかる。日付が来たら、終わってなくても終わってる、とするみたいな。
• 最初にフェーズやプロセスへの分解を行う。分解されたものは、それぞれが、一番やるのに適切な人を連れてくる。
• 分解を達成することを目的化しがち。そもそも何をするんだっけ、が抜けがち。
• 分けちゃうことで頭使わなくなっちゃうよね。個々人の参加意識もなくなる。
• PMがナレッジ職になってしまった。
• 実行と計測の失敗は、PMの力量に関係ない。計画と調整がPMの力量により左右される。
• 調整はぜったい出る。QCDSを調整する政治的な調整能力が大事。技術職でなく知識職。
• PMの資格を取ってても意味がない。

逆転の発想

• アジャイルは逆転の発想をしてる。
• 失敗を前提にする。
• 計画は、小さくして、精度を上げる。
• 実行は、計画どおりに実行する。計画が小さいので実行リスクが下がる
• 計測は、動くソフトウェアでやる。最終的な進捗の棚卸しは２週間ごとにやる。
• 調整は、全員でやる。実行中はスコープ調整をやらない。
• スコープ調整が粗くなる。
• 失敗しても範囲が小さい。

PMがいない、フェーズがない

• アジャイルはPMがいない、フェーズがない。
• なので、PMがやることを全員でやる。結果として、PMの能力に依存しなくなる。
• スーパーPMってなかなかいない。技術も最近は複雑で、ビジネスも複雑で、限界がある。
• なので、一人で判断するのは難しいので、全員で分担してやりましょう。
• プロセスそのものがマネジメント行為に織り込まれている。
• 完了基準は時間。スプリント２週間の最後に、PMはいないので、みんなで計測する。
• RUPとか、ウォーターフォールとアジャイルの中間にあるプロセスにはPMがいる。
• アジャイルはPMがいないのが特徴的。あと時間駆動。この２つがアジャイルのすごく特徴的な部分。

制約というか前提

• アジャイルには制約条件、前提条件がある。
• PMには依存しないけどチームには依存する。なのでチームを成熟させていく必要がある。
• ウォーターフォールは「調達」があって、その時々のタスクに応じて、スキルの出し入れができる。
  • ここには実装が得意な人をいれる、とか。
• アジャイルはスキルの出し入れが困難になる。
  • 「知らない、できない」があると、「あの人ができるよ」としないのがアジャイル。
• 全体の終了、という概念がない。できるところまでやるので、全体、というのが無い。
• 「全体がわからないからアジャイルでやるんでしょ」という考え方。
• プロダクトが終わるまで続ければいい、というのがアジャイルのゴール。
• アジャイルの場合は、時間がきたか、プロダクトが終わるか、のどちらかまでは継続的に活動を続ける。

ウォーターフォールとの違い

• 計画駆動（＝ウォーターフォール）か、変化駆動（＝アジャイル）か。
• 調達もなにもかもうまくいくなら、理論的にはウォーターフォールの方が早く上手くいく。
  • ゴールが明確でない場合はゴールを探しながら進むしか無いが、作りながらウネウネと進む。
  • 時間がかかるかもしれないが、そちらのほうが効率がいい。
• ケント・ベックはXP本で車のハンドルの例を上げている。
  • ハンドルをちょっとずつ調整して進む。ハンドルを見るんじゃなくて前を見て進んでいきましょう。
  • 道路の条件、まわりの変化にちょっとずつ合わせていく。
• ウォーターフォールもアジャイルも、効率の良さを目指している。

PMBOKとアジャイル

• PMBOKの第５版でもアジャイルに言及している。
• ライフサイクルを３つ定義している。予測型、反復型、適応型（アジャイル)、の３つ。
• PMBOKは予測型に最初からフォーカスが当たっているので、適応型でやろうとすると無駄が出てくる。
• ３つの使い分けもPMBOKに書いてある。
• 予測型は、最初になるべく決めましょう、決められるなら採用しましょう、というスタンス。
• アジャイルは２週間とか短い反復でやる。
• 予測型、反復型、適応型、と、下に行くほど変化に対応できるようになる。

アジャイルあるある

• アジャイル、と言っているのにアジャイルじゃないもの。
  1. マネジメントがないもの　・・・　計測とか計画をしない、とか。
  2. コミュニケーションが健全でないもの　・・・　チーム外に何かを説明するときにはドキュメントが必要になるので、作りましょう。
• マネジメントはちゃんとしましょう。

アーキテクチャ

• アーキテクチャはプロジェクトマネジメントの基盤。
• 「構造」には「工法」がセットになる。
• アーキテクチャを決める　＝　構造と工法を決める
• スコープからタスクへの分解をする以上、必ずアーキテクチャがある。必ず誰かがアーキテクチャ設計をしている。
• 最近は技術的複雑さが進んでいるので、アーキテクトが必要になることがある。
• アーキテクトを不要にするには、前回のプロジェクトと同じアーキテクチャにすること。ERPとかパッケージとか。
• アジャイルはPMもアーキテクトもいないが、プロジェクトマネジメントもアーキテクチャも必要。

アーキテクチャは選択肢を残す

• アーキテクチャは選択肢を残す、というのが今的に重要。
• 現在的なアーキテクチャは、決めない、ということ。
• 大切なのはモジュール化。部品を交換可能にすることで、あとで取り替えられる。変化の境界線で分け、適切に組み合わせる。
• 例：南北戦争における「銃」
  • 銃は壊れるところが決まっているので、交換可能にして、量産化が可能になった。
• ゼロ戦が負けたのは部品交換ができなかったから、という考えもある。
• 昔は銃とか大砲は一体型だったが、分解可能でメンテナンス可能になったのは、標準化とかが進んだから。
• 成熟させてモジュール化していくことが大事。

MSA

• サービスの分割
• モジュールごとに、好きなタイミングでリリースしていいですよ。
• システムごとにライフサイクルを好きに変えられる。
• 昔は１個のシステムは１個のマネジメントでやるのが普通だった。
• 今はサービスを分割することで、それぞれでマネジメントを合うようにやれる。
• 必要なときに必要なものを割り当てるという思想。
• ただし安全弁が必要。CIやカナリヤリリースなど。

例のあれ

• 牛尾さんのブログ：　私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い
• 牛尾さんはと知り合いで、仲良くやってる。
• マイクロソフトの見解ではない。
• Windows10の自動アップデートも、マイクロソフトがアジャイル化した例。あれだけのことができるようになった。

ウォーターフォールのメリットは？

• 特定の文脈ではメリットがある。
• 「いまどきのシステム開発ではウォーターフォールにするメリットはない」はある程度そのとおり。
• ウォーターフォールで考えられる領域は少なくなってきている。
• リスクや変化をどう取り入れながらやっていくのは腕の見せ所。

質疑応答

• 保守はインシデント駆動型なのでアジャイルっぽくなるのは当たり前。
• アジャイルが安い、というのも嘘。
• 全部決まっているならウォーターフォールのほうが安い。
• 建築では構造と工法がセットなのは当たり前だった。

ディスカッション

雄介さんと参加者全員とで、「いまどきのシステム開発においてウォーターフォールを採用するメリットはない」か？について議論しました。
議論で上がった意見はスライド後半（P.38～）に雄介さんが纏めてくださっています。
以下、個人的に取ったメモ。

そもそもWFは必要なのか？

• 例のあれは、個人的見解では、正しい。
• 今更「アジャイル、ウォーターフォール」を議論しても意味はない。
• 個人的には、アジャイルの価値って、マネジメントもそうだけど、XPのライフサイクルを見るとわかるが「コードの共同所有」が挙げられる。
• これが建築とソフト開発との決定的な違いを産んでると思ってる。
• ウォーターフォールは中間成果物を作るが、それはなんの価値も生まない。
• それを「コードで会話しようよ」としてが、それはソフトウェアでしかできないし、アジャイルのコアを活かした価値じゃないか。
• 中間成果物を削減することで、アジャイルでも安くできる。
• もしスコープを決められるのなら、それをインプットにしてアジャイルチームを作れば一番うまく行くんじゃないか。
• WF型が合う局面もあるが、WFがアジャイルか、の2択じゃない。その間があるんじゃないか。
• それはRUPでもない。RUPのイテレーションはミニWFなので。

とはいえWFを採用するケースは？

• メンバーの力量が読めないなら、WFを選ぶ。
• 基幹システム連携の場合、連携先の期間側がWFなら、こちらもWFでやるしかないかな。
• 1年後の約束されたリリース（法律改正対応）とか
• チームやプロジェクトが永続的ならアジャイルがいいのでは。
• 発注者が公共（計画ありき／透明性の確保）ならWF。
• 研究開発ならアジャイルが合う。
• 期間に対してスコープが多い場合（大量リソース）ならWFがよい。
• 保守開発でメンバーが決まっているならアジャイルがよい。
• 請負契約だとアジャイルやりづらい。
• ユーザ／開発者にヤル気がないならWF。
• 発注側がスコープ確定を要求するならWF。

アジャフォール

• 準委任で要件をアジャイルで決めて、スコープ確定したらWFで作る、というのアジャフォールと言う。

準委任契約

• 準委任契約にしてもらった時は、お客さんが雄介さんの目を見て、「信じてるから準委任にするね」と言われた時。
• この時、「下手な人は出せないな」と思った。
• お客さんは準委任にするのに、稟議にすごい苦労していた。
• 先行着手書でやる場合は、アジャイルで最初やって、状況が見えてきたらWFに変える。
• お客さんがリスクを取ってくれている。

チーム編成

• 素直な子を半分は配置する。
• フロントエンドとバックエンドがぜんぜん違うアーキテクチャでは、おっさんはバックエンド、素直な子はフロントエンド、みたいにしてバランスを取ってる。
• 素直だと、変なところを深堀しない。
• タイムボックスで動いているので、わからないならすぐアラートを上げてほしい。
• バックエンドは多少ベロシティ下がっても、しっかり作って欲しい。（なので、おっさんを割り当てる）
• アジャイルでコードが書けない人は、テスターをやってもらっていた。
• 教育のストーリーを入れさせてもらって、新人を投入した。
• スクラムマスターはお世話係で、誰かが休むと穴を埋める

アジャイルの失敗のあるある

• 細かい仕様変更に対応しすぎて、お客さんの要求を聞きすぎて、全体のコントロールができずに、プロダクトができない。
• PMロス対応　・・・　オレオレでやるのは、そもそも無理。コンサルやコーチを入れよう。

コーチは役に立つのか

• ある程度のアドバイスは必要。
• 週1回、ディスカッションに参加してくれると良い。メンターのような感じで。
• いろいろ教えてもらった。「自分たちのことは自分たちで考えろ」という姿勢を教えてもらったことが一番大きかった。

感想

ちょうど、WFの経験しか無い、とあるプロジェクトへのアジャイル適用を支援しようとしている私にとって、タイムリーなネタでした。
最後のワークで、WFを採用する場合のシチュエーションとして「規模が大きいこと」という意見が出なかったのは意外でした。
（期間に対して規模が大きいこと、という前提付きの意見は出たが）
確かにボーイングの航空機開発やマイクロソフトの大規模ソフト開発でアジャイルが使われている、という事例紹介などを目にすることが多くなりましたが、「規模が大きい　＝　ウォーターフォール」というイメージは無くなりつつあるのかなぁ、と思う次第でした。

こーゆうイベントは良いですね。また次回も参加したいです。
雄介さん、関係者の皆様ありがとーございました。