言いたいこと

「アジャイルはウォーターフォールより開発速度が速い」というのは「ウォーターフォールより早く完成する」という意味ではない

アジャイルは速くないのか？

プロジェクトの進め方によるという前提はあるのだが、結果的に見るとウォーターフォールと同じぐらいの工数が必要になるだろう、と考えるべきという立場である
たとえば、どんなにプロジェクトのPDCAを回しても、ユーザーの目的を達成するために絶対必要な工数は（ロスも含めて）発生すると考えている。
これはSIerがどれだけ手を尽くしても、クライアント側に発注ノウハウがあったとしても、である。
特に開発の進め方について、ある一定の「こうした方がいい」という話はあったとしても、その時の体制や予算は完全に再現することはできないので、評価はできても正しい比較は難しいと考えている。

その上で、ウォーターフォールだろうがアジャイルだろうが共通して開発者の数を増やしてもボトルネックがあるという前提を見ると開発速度は早くならない
（人を増やしたらカップ麺が1分で出来るか？という話と同じだと考えてみて欲しい）
ボトルネックの解消または着手をどれだけ早められるか？という観点でみても、タスクの総量が決まっている（ウォーターフォールだとこの構造を作りやすい）ならまだしも、アジャイルになると要件定義の甘さを許容する進め方になるため、タスクの総量が当初段階より見かけ上増えてしまうという徒労感がエンジニアの精神を蝕んでしまっているように感じられる。

ややグチを含む実体験

まず、私のマネジメントスキルが高いか低いか、でいうと低い方だという認識がある。
そして、マネジメントスキルが低いながらマネジメントロールを求められる状態であるという事もある。
そのため「能力が低いマネージャーのプロジェクトは炎上するし地獄だよな」には申し訳なさしかないが、その中でもできる事はないか模索をしている。

さて、私は人のことは決して言えないのだが、アジャイル開発であろうともウォーターフォール同様、いったんの終わりを決めておいて、かつ全体であらかじめ周知しておく必要があると感じている。
たとえば、準委任契約などで稼働期間に定めがある（多くの場合、双方の申し入れがない場合は自動延長される）ケースについては、当該期間を延長することになる場合に対応可能かどうか調整もあるし、離任により新しい要員を探すとなると、同等程度のスキルであってもドメイン理解の部分でどうしても対応が遅れてしまう事は考えられるため、開発期間を延長すると言う判断は軽々に行われるべきではない。
これが正社員でSESなら企業戦略や方針こそあれ、大体の場合個人の意思は無視されがちである事が多いので、結果としてエンジニアの職種・業務体験が下がってしまっているのだと思う。
すなわち、エンジニアにとってよくない→マネージャーになる前にエンジニア職を辞めてしまう要因なのではないだろうか？と考えている。

エンジニア目線で見るアジャイルの問題点

終わりが見えない。

元々やりたい事が何なのか、やりたい事は解決できているのか、解決するためには何が必要なのか。
エンジニアロールでミーティングに参加はしても、全体で見た時にはWBSでしか把握できない事が多いため、WBSに存在しないタスクについては「いやいやそれはやらないでしょ」と思ってしまうし、後から追加されたとなるとマネージャーを恨みたくもなる。
頑張れば頑張るほど報われないと感じたその時に、まずはいったんやる気がなくなる。

で、やる気がなくなると成果量に反映されるため、どんどん開発が遅れ火がつき、最低効率・能率になりプロジェクトの収拾がつかなくなる。
マネージャーからは「今日これぐらい出来てないとプロジェクトが終わらない」と言われるが、言われた量をやっても新しいタスクが追加されるぐらいなら、今日の目標達成より今日の自分ができる量をこなして後は交渉頑張ってください、というスタンスの方がまだ精神衛生上良いのだ。

アジャイルが早いと言われる理由は？

ユーザー（クライアント）が介入できるタイミングがウォーターフォールと比べると圧倒的に早い。
ただし、誤解を恐れずにいうと初回リリース版はプロトタイプでもあるので、完成ではない。

ウォーターフォールは一定のスケジュールにおいて見積もりを出すが、アジャイルはクライアントの要望の数だけ見積もりを行い、実施判断をする。
大枠に「このようなシステムを作って欲しい」という要望があったとして、それっぽいシステムを組み上げることはできるが、追加であの機能が欲しい、どの項目が足りなかった、あるいは初期に話していた要件から変わったなど様々な要因で「当初開発者側が想定しなかった業務」を依頼できるのがポイントだろう。
アジャイル開発は発注側と受注側さえ良ければいつまでも開発できてしまうため、初期に要件を固めてウォーターフォールで作っていた方が結果的に工期も予算も釣り合いが取れる状態になっている可能性がある。

とはいえ、要件を確定させる（特に発注側）のは非常に難しいため、クライアントの要望をシステム化するとどうなるか？を見えやすくしたという意味ではアジャイル開発の恩恵は大きく見える。
（ただし、実質プロトタイプでしかないので、ここにアジャイルだとかウォーターフォールの概念を取り入れるのは違う）

アジャイルを本当に早い開発にするには？

プロジェクト初期はどうしても発注側の知見や、受注側も発注側の意図を読み取るのが難しく目的外の対応になってしまう可能性がある。
そのため、発注側が過度にカスタマイズをしない方針を立てることが重要で、メンテナンスの観点からもフィット・トゥ・スタンダードの考えが重要であることが強調されるようになった。
いわゆるバニラ実装（製品本来の仕組みを使う）であるが、製品自体を知り尽くす（事前に調査あるいはプレ運用する）必要があるため、要件フェーズの重要性が更に高まったと考えることもできる

サービスを拡張せざるを得ない場合は？

やや業務システム系ITコンサルタントの視野を入れると、業務フロー自体を見直した方が良いことがある。
それも、個別最適ではなく全体最適の観点から不要な（というよりは、簡易化できる）業務を割り出し、別の方法で代替するなどの対応が考えられる。
たとえば、既存システムを長く使っていて、法改正などでサービスの内容が変わった際にシステムを継ぎ接ぎして何とか運用していく方針にした結果、業務フローもビジネスロジックも実装コードもぐちゃぐちゃで誰もメンテナンスできない、という事態が発生しうる。
そのため、既存システムを丸ごと刷新して重要なデータだけ何とか移行して運用を続けるという事が起こりがちだ。

本来であれば、この段階までに運用を整備して、プロジェクト進行中に要件や設計を変えざるを得ない部分を先にキャッチアップできるのが理想ではある。
が、実際問題として規模の大きなシステムほど要件定義にもシステム設計にも時間がかかるもので、要件を決めている間に法改正があって追加対応が必要になるケースなども考えられる。

後進育成の観点で考えるアジャイル開発

まず、プロジェクトは教育の場ではない。少なくともクライアントは自身のプロダクトに巨額の投資をしているので、クライアントの資金を使ってエンジニアを育成するというのは良いやり方ではない。これがクライアント側のエンジニアであるなら例外だ。
そして、プロジェクト経験を積まないとエンジニアは育たない。先述の通りクライアント側のエンジニアであるならまだしも、SIerエンジニアの方が圧倒的に数が多いので、SIer側が技術をつけるための方法を検討しなければならない。

この二つの矛盾をうまく解決する事がマネージャーに求められている命題だと考えている。
もちろん、マネージャーは教育係ではないという前提ではあるが、その上で後進育成できるならすべきという考え方でもあるため、マネージャーが後進育成を考えられるならどうするか？が以降の議論になる。

さて、予算などの取り決めはマネージャーの管轄外であるため、ある程度決められた要因や体制の中でプロジェクトを成功に導きつつ、後進を育てていく事になる。
マネージャーが後進を育てるメリットとして、PMOロールができるエンジニアがいると作業がやりやすくなることと、事業レベルで見るとスキルアップしたエンジニアがいると案件が取りやすくなると言うメリットに目を向けたい。
たとえば、私は個人事業主の立場ではあるが、私が育成を担当したエンジニアから案件相談（受託してくれ、という内容もあれば、受託した案件のメンターになってほしいという話もあり）があったので、どんどんネットワークを広げていくべきだと考えている。
また、シンプルに付き合いとして「人のためになることを考えようとする姿勢が好印象」というご評価をいただいたり、その中でも特にお願いしたい（リップサービスの可能性もあるが）というお声もいただくことがある。
こういった観点からも他者への配慮という形でプラスアルファの対応をすることで結果的に自分に返ってくるということがある。

アジャイル開発の前にウォーターフォールを体験しておくべきか

Yes
開発が速くなる、という観点で見た場合では無関係が回答になるが、一度は各フェーズのステップでやるべき作業などがあり、そもそもフェーズごとに分けている理由は何かという意味を理解するためにも一度はウォーターフォールを経験しておくべきだ。
その上で、アジャイル開発の現場になったことでプロジェクトが完了した時にウォーターフォールとどうだったか？を見つめ直す（繰り返すが、単純な比較はできない）のが重要である。

ウォーターフォールを経験しておくとアジャイル開発は早くできるか？

繰り返すが関係ない。あくまで工程を分けて開発している理由を把握するためのものであり、開発速度を上げると言う考え方がそもそも間違っている。
理由は先述までの通り。

ただし、ウォーターフォールを経験することでアジャイル開発の際にも活かせるものがある。
逆に、アジャイル開発からウォーターフォールに移行すると各工程ごとに落ち着いて取り組めるという点で、各工程の勘所に向き合う時間が増えると考える事もできる。
とはいえ、単純に短納期であるためリリースの機会が一度しかないアジャイル開発は擬似的にウォーターフォールと考える方法もある。

アジャイル開発においてリリースの頻度や回数はあくまで目安。期日ベースで終了を決めておこう

ただのナレッジ共有になった感はあるが、あくまで「こうするとうまくいく」ではなく「うまくいった例がある」と考えて欲しい
プロジェクトマネジメントに銀の弾丸はない。

ただし、プロジェクトマネジメントにおいて様々な手法があり、ケースバイケースで活用できる方法があるという事は認識しておきたい。