最初の投稿です。
普段の仕事から学んだことをアウトプットしつつ、自分の中でも整理していきたいなあと思っています。
というのも、アジャイル開発にまつわる仕事をしていく中で、一番助けられたのは、Web に落ちている(失礼)、先達の足跡（やらかし事例含む）だったので。
で、タイトルの件。
よく対比に上げられて、仕事でもよくそういう質問を聞くことが多い。
ウォーターフォールは、決めてから作る アジャイルは、少しづつ決めながら作る
ウォーターフォールは、変更を(あんまり)前提としない アジャイルは、変更を受け入れる
ウォーターフォールは、計画を重視する アジャイルは、現実を重視する
って言われても正直ピンとこない人は多いし、自分の プロジェクト 仕事に当てはめてもどっちを適用すべきかわからない人も多い気がする。
そもそもアジャイルの現場ってプロジェクトじゃない場合が多いよね、っていう話
そういえば、「プロジェクト」ってなんですかね？
って聞かれて、
「独自性」と「有期性」
っていう言葉がすぐに出る人は、ある程度プロマネ経験のある人だと思う。
PMIが制定しているPMBOK（第5版）の定義では、「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」とされている。
お堅く定義されてもわかりにくい新卒の子向けに ↓ みたいな雑な対比を使っている。（超適当）
| プロジェクト | プロジェクトじゃない |
|---|---|
| 大学受験 | 日々の勉強 |
| 卒論研究 | 輪講・ゼミ |
| システムを作る | システムを維持する |
| 事業を立ち上げる | 会社を運営する |
| プロジェクト X ～挑戦者たち～ | プロフェッショナル ～仕事の流儀～ |
大きな違いは、やはり期限と独自性があること。 この二つを「目標」とか、「ゴール」とかでまとめて表現すること(人)も多い気がする。
そして「目標」とか「ゴール」とかいうふわっとした言葉で定義が始まると、 大抵の場合、伝わりやすいけど混乱を生む（わかったつもりにはなれる）
プロジェクトとして、「いつまでに」、「何を」実現するのかを 定義できたら 、 それに向けて計画を立てることになる。
この 定義できたら がクセモノだったりする。
よく言われているように、目下 Web サービスなんかを中心に、各ドメインで百家争鳴、雨後の筍のようにスタートアップな諸々がワシャワシャ出てきている。（いいこと）
そんな環境で、自分たちのサービスが継続して成長していくために、 いつまでに何をやれば 勝てる かは、正直読めない場合が多い。
無理矢理ゴールを決めて、大きな機能・サービスをぶち上げて、ゴールに向けた投資をしても、意味ない、効果が薄くなった、他がやりだした、みたいな状況にぶち当たると、目も当てられない。
なので、見えている目標に対して 必要最低限の投資と回収 をすることが、成功する 失敗しないための最低条件になる。
→ アジャイルみたいな、変化に柔軟に対応しないとねっていう話になる。
ところでこういった、サービスや会社の成長、というものは、上の表の「プロジェクトじゃない」活動になる。
結局のところ、
「プロジェクトを成功させるためのウォーターフォール」
と、
「プロジェクトじゃない活動を成功させるためのアジャイル」
を比較してもあまり意味がない。
もちろん、プロジェクトをアジャイルに進めることにも効果はあるけれども。 無駄な機能を作らないとか、無駄な中間成果物を作らないとか、まずは動いているからリスクが少ないとか
よく、「ウォーターフォールはやめてアジャイルだ！」とかいう言葉に振り回されたかわいそうな人たちを見かけるが、そもそも対比として間違ってね？は気にしてもいい。
そういえば、Agile Japan 2018 のテーマが "Why Agile ?" だったのはそういう事例が増えているからかもしれない。
と思ったらまあまあそうだった。
一抹の不安
この状況は新たな価値や成果をもたらすと期待される一方、一抹の不安も感じています。アジャイルへの関心やニーズが急速に高まりすぎるあまりにアジャイル開発を導入するということ自体が目的となってしまい、本来達成すべきことはなんであったのかを忘れてしまうことにならないか？ということです。
これを履き違えてアジャイルが目的化すると、アジャイルへの信頼はともかく、チームも作れないし結局アジャイルプロセスは実行できるけどビジネスで勝てない、みたいになるんですよね。かなC。
