TL;DR
大きい組織とか、でっかいプロダクトでアジャイル開発するの難しいよね。
同僚たちの悩み━今の開発プロセスに違和感がある
このところ立て続けにこんな話を職場でした。
同僚："ウォーターフォールみたいな開発になってるからもっとアジャイルに開発した方がいいと思うんです"
僕："そうだね、それは理解できるんだけど、実際問題としてこの規模になるとそれは難しいんだよね"
ざっくり書くとこんな会話をした。
はじめに断っておくと、この疑問や問いかけ、提案はとても素晴らしいと思っている。僕の同僚たちは、自身がこれまで10人もいない程度のフルスタックなチームでアジャイルなプロダクト開発（スクラムとかなのかな）をしてきた経験をもとにこういった提案をしてくれた。こういった組織が増えているんだろうな、と感じたし、こういう経験を積んできたメンバーと一緒に働けることはシンプルに嬉しい。
だからこそ、その時の経験が比較対象となり、トップダウンでおりてきた期限付きかつ大方の仕様が決まってる案件をチームで対応することに違和感があるんだと思う。気持ちはよくわかる。ただ、大きな組織や大きなプロダクトにおいて、こういったことは実際問題よく起こるし、これはスクラムでどうこうできる規模ではない（スクラムそのものは10人いないくらいの規模であればとてもよく機能する良いフレームワークだと思ってるけど、それを越え出すと実際難しいと考えてる）。
僕はスクラムを教えるライセンスを持っている講師でもないし、スクラムやアジャイルに関して誤解していることもあると思う。
"これはスクラムで、それはスクラムではない"
"これはアジャイルで、それはアジャイルではない"
みたいな議論は好きではないしあんまり興味はない。そんなことをここで吐露するつもりはない。
僕が大事だなと思っていることは、ウォーターフォール型の開発モデルと比べた時、より変化に対応できる開発プロセスモデルがアジャイルということがなのかなという点。それを実現するためのHow、すなわちうまくソフトウェア開発を進めるための方法論が数多く提案され、そしてその実践事例が日々報告されていると思っている。
LeSSをはじめSAFeなど多くの大規模アジャイル開発フレームワークが提案され、実践されていることはとても良いことだと思っている。
一方で書籍"モダン・ソフトウェアエンジニアリング"で著者らが述べているように"手法の戦争"をしている状態では、僕らはいつまでたってもソフトウェアをうまく作れるようにならない気もしている（ここでいう手法とはLeSSであったりSAFeのようないわゆるフレームワークのことと解釈してOK）。
だから、現時点だと僕は書籍"モダン・ソフトウェアエンジニアリング" で著者らが述べているようにこれまで議論され、実践されてきたさまざまなフレームワークのプラクティスをチームや組織、組織の文化、プロダクトなどの変数に合わせてピックアップして取り入れるのが良いのだろうと思っている。著者らは手法はプラクティスの合成であって、チームや組織は独自の手法を作るべき、と言っている。特定の手法にとらわれる必要はない、という。
我々はすべてのチームや組織が独自の手法を構築すべきだと考えている。問題となるのは、それを実現する方法がなかったことだ。
"モダン・ソフトウェアエンジニアリング"で述べられていることは非常に難解で正直著者らの主張をしっかり理解できているかは自信がない。が、著者らが主張している"手法の戦争"という話はよく理解できるし、"手法の監獄"という表現もよくわかる。
あなたが何らかの手法を選択すると、手法の監獄の中にいるような気分になる。
同僚たちの悩み━ウォーターフォール型モデルに対する誤解
話を戻す。
そんなわけで、同僚からの素直な疑問に1on1や打ち合わせの場で説明をする機会が最近多い。ここまで細かな話をするわけではないのだけれど、説明をするのが大事だと思っているし、良いアジャイル開発の経験を積んでいるからこその素晴らしい疑問だと思うからしっかり話をしていた。
もう一つこの同僚たちの疑問に答えていく中で大事なポイントがあった。ウォーターフォール型の開発モデルに対する誤解を解くこと。これは教育のせいだと思うんだけれど、ウォーターフォール型の開発モデルのようにプロセスが進むことは良くないことだと思い込んでいるように見える。ここで書籍"ソフトウェア工学の基礎 改訂新版"からウォーターフォールモデル（落水型モデル）について述べている文章を引用する。
このように落水型モデルがいろいろ批判を受けながら現場では長い間主流であったのは、プロジェクト管理上、都合がよいという理由からである。
プロジェクト管理上都合が良い、というのはまさにそう。そして周知のように手戻りが発生した時のことを考えると大変なのそうなのだが、そればかりが切り取られて理解がされてると思っている。もちろん実際に手戻りは発生する。書籍中でも以下の通り記述があるしそりゃそうだろう、と思う。
実際のプロジェクトを観測すると、手戻りをなくすことは現実的ではなく、多くの手戻りが発生しているという伊藤暁人と筆者による調査がある。
たしかにウォーターフォール型の開発プロセスというのは悪だと教育されたり刷り込まれそうなんだけども、前述の通り"プロジェクト管理上都合が良い"、ということは大事なのだ。特に大規模なプロジェクトの場合はそう。たとえば、以下論文では計画型のプロセスモデルとアジャイルのアプローチを組み合わせてソフトウェア開発をしている組織が多いことを述べている（abstractの一部をピックアップしているので読み解きにくいと思うがご容赦を。）。
We further show that hybrid software development approaches are independent from the company size and external triggers. We conclude that such approaches are the results of a natural process evolution, which is mainly driven by experience, learning, and pragmatism.
計画型(plan-driven approaches)の一例がウォータフォールになると思うが、アジャイルの対局にあるモデルと理解して良いと思う。
で、この論文から学べることは数多い。僕が同僚にこんな論文もあるんだよ、と説明したのは、計画型（ウォーターフォールなど）がダメっていうことはないんだよ、という根拠として紹介をした。We conclude that such approaches are the results of a natural process evolutionて著者らが言ってるのは何だか心強い。僕も大規模な開発をしている中でどうしても計画型のプロセスになっていくことをモヤモヤ感じていた時期があったけど、そういったプロセスになっていくことはある意味自然だと理解ができた。もちろんそれはそうとして、改善は積み重ねるべきだけども。
多分、この論文での調査対象となっている組織やプロジェクトでは"モダン・ソフトウェアエンジニアリング"で述べられているように組織やチームに合うプラクティスを組み合わせ、独自の手法を作っていった結果が計画型のプロセスモデルとアジャイルのアプローチに結果的になったんだろうなと思う。論文の著者らが言うように、そう考えるとたしかに自然なプロセスの進化だ。
そんなわけで、こういう論文もあってね、という説明を同僚たちに1on1で説明したりした。そしたらみんな納得してくれたようで安心したんだけど、
"そうか、こういう説明が必要なんだな、なるほど"
と話しながら思っていた。この記事を書くモチベーションもそれによる。
そういえばつい先日も共著で書かせていただいた書籍 "エンジニアチームの生産性の高め方 〜開発効率を向上させて、人を育てる仕組みを作る "の出版イベントで小澤さんが
"アジャイルでずっとやってきたけどウォーターフォールで開発を進めることが適することがあるんですよね"
みたいなことをパネルトークでお話ししていて、会場で聞いてた参加者の方々がその後すごい参考になったとお話ししていたことがあって、印象的だった。僕の同僚たちのように疑問に思う方が多いのだろう。まあそれもそうか、と思う。僕にとっては自明なことだったんだけど、たしかに僕も昔同じことでモヤモヤして色々勉強して経験を積んで今に至るのでそれはそうだ。というか、そういう話を体系的に教えてくれる本があんまりないんだな、知っている限りでは"モダン・ソフトウェアエンジニアリング"にはそういった事柄は記載されているけども読み解くのは非常に難しい。
『アジャイルっぽいウォーターフォールやその逆などもいい面もあるのでは？』 #engprodbook
— atsushi wada (@wats) 2024年11月1日
↑出版イベントに参加していただいた方が小澤さんの話を聞いて投稿してくれたコメント
まとめ
さて、長くなってしまったんだけれども、言いたいことはタイトル通り。
組織が大きくなったりプロダクトが大きく成長した際のアジャイル開発難しいよね、
ということ。それを認識して、計画的に、でもアジャイルのプラクティスを取り入れることができるならそれを取り入れていく、みたいな独自のプロセスを組み立てるのだって良いんだよ、ということを言いたかった（前述の通り、モダン・ソフトウェアエンジニアリングの主張に近い意見）。
図らずも、少し前に話題になった圧倒的なまとめ記事の結論とも重なっているようでやっぱそうだよなと思った。
プロジェクトの性質によって開発プロセスを使い分けるべきとは言うが、それはなかなかに難しい。同じ組織が、複数の開発プロセスを起用に使い分け、使いこなすことなど本当に可能なのだろうか。1つの開発プロセスでさえ、なじませ、改善を重ねることに苦労する。結局のところ、なにか1つに定めて、それを組織の目的に合わせて調整し、改良し続けるのが一番なのではないだろうか。
そして、そういう環境でエンジニアリングマネージャがやるべき仕事は山のように生まれてくる。前述の"アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog"において実際問題そういうプロセスを使い分けしたり、使いこなすことが可能なのだろうか、という疑問が投げかけられているけども、まさにそこはエンジニアリングマネージャがどうアプローチしていくかになるんだろうなと思っている。大変だ。この記事を書きながら改めて読み直したけど、エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法 の11章 「プロジェクトって難しい」にはまさにそのやるべきことの一例が生々しく書かれている。相変わらず素晴らしい本だ。
チームがスピードについて直接文句を言われないように、あなたがチームの盾になりつつも、会社の成長とともに1人あたりの生産性が下がるという事実は受け入れなければいけません。そして、それをチームに説明できるようにしておかなければいけません。
僕もスクラムを勉強して、資格を取り（認定スクラムマスター）、大きいプロダクトの開発に携わって、スクラム（アジャイル）したいのに上からどんどん案件が降ってきてどうしていいかわからなかったし、そんなことをさせる会社が嫌になってたこともある。
そんな時、こういう説明というか納得できる言葉をかけてくれる人はいなかった。
だから、同僚たちの気持ちを考えるとできるだけ納得できるようしっかり説明をしたいな、という思いで今回1on1で話をしていたりした。どれだけ伝わったかはわからないけど、
"色々難しいけど、頑張ろうかな"
という風に納得してくれたら嬉しい。納得はできないけど、モヤモヤが少し晴れて、その状態を受け入れるようになったら嬉しい。一緒に頑張れたらいいなーと思っている。
そんな感じで前向きになれるなら、エンジニアリングマネージャも向いてるからぜひやりましょう。向いてると思います、多分。以上、終わり。
