なぜ「アジャイル」が「アジャイルもどき」になってしまうのか
――ここから、少し具体的に「アジャイルによるプロダクトづくり」のあり方についてお話しを聞きたいと思います。先ほど山崎さんが指摘されたように「プロダクト思考でのものづくり」が世の中で注目されており、その手法として「アジャイル」が広く受け入れられつつある一方で、結果的にその取り組みが失敗に終わってしまうケースも増えているように見受けられます。その原因をどう見ておられますか。
山崎：私見ですが、いわゆるアジャイルを実践しているつもりで、やっていることが「アジャイルもどき」になってしまっていることが多いように感じます。「アジャイルもどき」の代表格は「分割ウォーターフォール」ですね。
本当の「アジャイル」というのは、小さなイテレーションの中で得たプロダクトとプロセス、両面の「学び」を、次のイテレーションに生かして「前とは違うことをやる」ところにあります。いわば「学びを生かして進化しながら作っていく」ことがアジャイルの本質です。一方で、ウォーターフォールでは最初に要件が固定され、完成までにそれが変化しないことが前提です。
私が「分割ウォーターフォール」と呼んでいるのは、「作るべきものが最初に固定されてしまっているにも関わらず、作るプロセスだけを小分けにして、アジャイルっぽくしたやり方」です。そこには、アジャイルの本質である「学び」や「進化」がありません。結果的に「やっていることはアジャイルっぽいけど、できあがるものはウォーターフォールと変わらない」という状況になりがちです。
市谷：「アジャイルの本質は人やチームが学ぶこと」というのには強く同意します。ここは、全部太字にした方が良い（笑）。
アジャイルで「小さく、こまめに形にする」ことが重要な理由は、形にすれば、それに触れて、試す機会が生まれる。それによって「新たに分かることが増え、学びが得られる」というのがねらいです。学びを得ることで、次の意思決定ができるようになる。イテレーションで生み出せるアウトプットは、次に何をすべきかの判断の元になるわけです。
このあたりの本質が抜け落ちた、繰り返し型の開発というのは、山崎さんがおっしゃる「分割ウォーターフォール」になるわけですね。ただ、最初に決めたやる範囲を分割して、こなしていく開発。そういう開発が全くダメなのではなくて、狙いが全く違うということです。あらかじめ決めた範囲をやりきることに目的を置くなら、分割開発でもいい。一方、プロダクト作りで求められるのは、「何が価値となのか？」という問いに答え続けるわけですから、学びを得て、意思決定を変えていける開発が必要となるわけです。
山崎：私や市谷さんは、アジャイルという言葉が注目される以前から、その本質を感覚的に理解していたのではないでしょうか。とにかくやってみて、形にし、試してみれば、その中で必ず改善案が出てきますし、以前のやり方は「筋」が良かったのか、悪かったのかも見えてきます。それが「学習」ですよね。アジャイルは、個人やチームの「学習の力」をエンジニアリングに最大限に生かす方法論なはずです。
よく「アジャイルは開発途中で要件が変わることを前提にする」という部分が引き合いに出されますが、要件が変わる理由は「学んだことから、次の目標なり、やり方なりをアップデートする」からなのです。いわゆる「アジャイルもどき」では、その「学び」や「変化」を抑制する力が働いてしまいます。
市谷：非常によく分かります。最近、企業のDXに向けた組織作り、プロダクト開発に関わる機会が増えているのですが、最初にルール作りや段取りといった「立て付け」ばかりに時間をとられてしまって「実際の行為から学ぶ」ことが、どんどん遠ざかっていくケースを多く見ています。
山崎：「立て付け」をきれいにすることばかり考えていると、プロジェクトが文字どおりの「絵に描いた餅」になりがちですよね。絵を描くのは良いのですが、同時に「とにかく何かやってみる」ことが伴わないと意味がありません。特に最初の段階では、人数も少なくていいのです。まずは3人くらいのチームで、とにかく始めて、そこから学びを得て、うまくいったら、適用範囲や人数、チーム数を増やしていくという進め方が良いのではないかと思います。
――たしかに、スモールチームだと「こうすればうまくいく」という学びが生まれやすい実感がありますね。山崎さんの経験から、アジャイルチームの適正な規模感はどのくらいだと感じておられますか。
山崎：「学びが全員で共有できる」という意味だと「7±2人」くらいがベストのような気がしています。大切なのは「やったこと」つまり「体験」を全員で共有できる規模であるということですね。これが15人くらいになってしまうと、現場に常にはいられない人が出てきてしまいがちです。そうすると「一緒に体験していない人」の「そうじゃないのでは？」という意見に、チームが惑わされがちになります。
市谷：「体験と学び共有できる範囲」の設定はとても大切ですよね。ところで、山崎さんはエムスリーで、より大きな組織でのプロダクトづくりをやっていらっしゃると思います。組織作りにあたって工夫されていることはあるのでしょうか。
山崎：エムスリーでは現在、QAを含むエンジニア、デザイナーといったプロダクト開発に関わるメンバーが100名以上います。プロダクトマネージャーとしての役割を担っているのは、企画系も含めて25名くらいです。
組織運営にあたって、うまくいっている仕組みとしては「プロダクト支援チーム」の設置が挙げられます。
「プロダクト支援チーム」は、主に既存のプロダクト開発チームに落下傘して、新しいプロダクトづくりを「支援」する組織です。現在の陣容としては、エンジニアリングをバックグラウンドに持つプロダクトマネージャー3名、エンジニア3名、プロダクトデザイナー3名に、リーダーである私の10名体制です。
このチームでは、週に1回、「支援チーム」全体での定例ミーティングを行います。ここでは、各チームの進捗報告ではなく、メンバーが参加している先で「起こったこと」「学んだこと」の共有を重視しています。
以前は、メンバーと私による1on1でのミーティングをやっていました。そこで聞ける内容は非常に良いものだったのですが、1on1だと時間がかかってしまいますし、共有の範囲が1名に限定されてしまいます。支援チームの定例ミーティングは、より効率良く「みんなで集まって各メンバーの学びを共有する」ための場なんです。
市谷：すごいな、全く同じ構想を私も進めてきています。「プロダクトマネジメントオフィス（PdMO）」と呼んでいるのですが、プロダクトチームを横断的に支援する、独立した専門チーム、機関のイメージです。プロダクト開発で必要となる専門性は組織にとって多くの場合「希少」なので、すべてのチームに常に入れるとは限らない。だから、個別チームから独立させて、適時適宜で支援に回る運用を取るわけです。
ちなみに、「PdMO」と呼称しているのは、DXの文脈では「PMO」という言葉に組織的に馴染みがあるからなんですね。なんなら「PMO」とうっかり間違えて、プロダクトマネジメントの専門チームが出来上がるのを狙います（笑）。
山崎：プロダクトマネージャーというのは基本的に孤独になりがちですよね。プロダクトマネージャーの学びを他のプロダクトマネージャーと共有しやすい環境というのは、あまりないのではないでしょうか。プロダクトチームによるものづくりの経験が浅い企業だと、1つの会社の中で、同等の環境に置かれたプロダクトマネージャーが2人以上いるケースは少ないでしょうし、プロダクトマネージャーの活動が競争力の源泉になっているという認識があると、社外のプロダクトマネージャーとざっくばらんに情報交換することも難しいと思います。私達の場合は、プロダクト支援チームという形で、社内のプロダクトマネージャーを集めて学びを共有する機会を作っていますが、こうした仕組みは、プロダクトによる競争力の拡大にあたって、今後は益々重要になると考えています。
（後編に続く）
ProductZine読者向けウェビナーのお知らせ（第7回：2021年2月24日開催）
毎月開催しているProductZineの読者向けウェビナーですが、2月開催分は本対談でお話しいただいたエムスリー山崎聡さんにご登壇いただきます。
テーマは「プロダクトマネージャー育成」と「チーム作り」。事前登録制で参加無料です。ぜひ併せてご参考ください！
- 詳細・参加申し込み⇒ https://codezine.jp/application/15/
