（前編はこちら）
「とにかく速く作る」ことが重要であるいくつかの理由
――「アジャイルの本質は学びにある」というのが大切なのは理解できる一方で、現状、そうしたことが難しい組織が多いのも事実だと思います。その場合の解決策について、何かアイデアはありますか。
山崎：アジャイル開発の中で「学び」の機会を多く作ることが必要だと認識していても、そうしづらいケースはあり得ますよね。プロダクトチームに対する経営陣からの信頼が厚ければ問題は少ないと思いますが、そうでなければ「学びとか言っているヒマがあれば、とにかく成果を出せ」みたいなプレッシャーで、思うように動けないこともあると思います。
私は、そうした場合こそ、「小さく作って形にする」という動き方が大事になると思っています。重要なのは、「学び」は強力な武器である一方で「ユーザーの困りごとを解決する」ための手段でしかないという点です。ここを見失って「学ぶ」ことが目的化してしまうと、肝心のプロダクトがいつまでたってもできあがらないという困った状況になりかねません。プロダクトづくりの基本は「ユーザーの課題を解決できるものを作って、ユーザーを満足させること」なので、そこから離れないように気を付けなければいけません。
リリース期間に対する経営陣の期待が、学びを阻害するリスクになりやすい状況であるほど「小さく、短い時間で、モノをつくる」ことの重要性は高くなります。例えば、もし経営陣が「6か月」でのリリースを期待しているようであれば、まずは、その2分の1の「3か月」、あるいは3分の1の「2か月」で最初のものを作ってしまうべきでしょう。最初から期待どおりの「6か月」を目いっぱい使うつもりで始めてしまうと、その間に学ぶことも、学びを生かすことも難しくなり、結果的に失敗もしやすくなります。言い換えれば、「経営陣が期待している以上のプロダクトを、期待以上のスピードで見せていく」ことでしか、信頼は得られないとも言えます。
市谷：不思議なほどに、山崎さんと考えが一致するのですが、この期間の捉え方もとてつもなく重要ですね。所与の制約をゴールにまで持ってきてしまうと、学びとフィードバックを重ねる機会がなくなり、最初の目論見を越えられるようなものにはなかなかならない。私も、制約にきっちり合わせた全体プランニングを最初から取るのではなく、制約を満たしつつも試行錯誤ができる「余白」を作り出す考えを取ります。
この考えのヒントとなるが、エリヤフ・ゴールドラットのCCPM（Critical Chain Project Management）ですね。計画を立てる際に、各タスクを可能な限り短縮し、全体でのバッファを確保するという考え方を知ったのは、もうだいぶ昔になりますが、今でも有効ですね。プランニング上の「安全」を、一つ一つのタスクに織り込むのではなく、バッファとしてまとめることで、時間の使い方も機動的になる。あるタスクは、想定以上に早く終ることもあれば、別のタスクは想定よりもかかるなんてことは、よくあること。一つ一つで、あるかどうか分からない不確実性に対処しようとすると、かえって弾力性のある対応ができなくなってしまう。
山崎：CCPMは私も好きな考え方ですね。最近、プロダクト開発の課題として挙げられることが多い「MVP（Minimum Viable Product）が大きくなりすぎる問題」も、根本的な原因は同じだと思います。リリースまでの時間が延びれば延びるほど、経営陣の機能に対する期待も大きくなる。それがプレッシャーになって、熟練度の足りないプロダクトマネージャーは最初のリリースを、できるだけ機能を入れた大きなものにしたくなってしまう。そういう構造があるのではないでしょうか。
プロダクトマネージャーは、まず勇気を出して「半分の期間で、小さなものを作る」ことを実践してほしいですね。機能は後からいくらでも足せるわけですし、後半になって「とにかく最低限出せるものがある」という安心感は、学びを取り入れていくためにもプラスです。「速く作れば、速く学べる」というメリットを体験的に会得できると、チームとしてのレベルも上がりますよね。
市谷：そう、狙い自体は果たせるアウトプットがあることの安心感と言ったら、元の意味とは違う「心理的安全性」があると言えますね。少なくとも、目的を果たせるものはある。だからこそ、「ここで一旦ユーザーの反応をテストしてみよう」とか、「実験的な機能を作って試してみよう」とか、チャレンジングな判断も取れるようになる。また、想定外のことが起きて、リリース前の土壇場で慌ただしくなる、ということがなぜかよくありますよね。こうした事態を迎え撃つ気持ちが全く違ってきます。
しかし、「アジャイルとは速く作ること」というのはよく言われますが、「なぜ速く作るべきなのか」については、実践で理解している人がまだ少ないのかもしれませんね。それがアジャイルもどき、作る範囲をただ分割しただけの「分割ウォーターフォール」が増えてしまう理由のようにも思います。
山崎：Minecraftの開発者であるヘンリック・ニバーグ（Henrik Kniberg）氏が描いた、アジャイル業界で有名な絵があります。
市谷：ああ、ヘンリックのMVPを説明した絵ですね。
山崎：この絵は、アジャイル的なものづくりの進め方を非常によく表しているのですが、上のやり方が「分割ウォーターフォール」で、下のやり方が「本当のアジャイル」を示しています。アジャイルに取り組むほとんどの人は、下の正しいやり方で作りたいと思っているはずなのですが、最終的に「自動車」を完成させるために、最初に「スケードボード」を作るべきという感覚は、体験を通じてでなければ、本質として理解しづらいのかもしれません。
――その本質をチームが理解していくために、有効なやり方はあるのでしょうか。
山崎：とにかく「刻む」ことを徹底してやっていくしかないような気がします。特にエンジニアの場合、多くの人は「どうせ作るなら、しっかり作りたい」という思いが強いと思うのです。特に、ちゃんとしたエンジニアほど、後々の保守運用のことなども視野に入れて、最初からきっちり作りたいと思いがちなのですね。プロダクトマネージャーとしては、彼らに「はじめからしっかり作る」というマインドを捨ててもらうところから始めることが必要だと思います。
私はよく「最初のバージョンは、今から1週間で作ろう」といって、メンバーにあきれられています。もちろん、それでできるものは、無茶苦茶なものなのですが、一旦それでいいんです。時間に余裕があると、みんな大きなものを作ろうとしてしまいますから。
「最初のバージョンは捨てるつもりで作る。そこから得た学びを通じて、よりちゃんとしたものを作っていく」という気概、文化のようなものをチームの中に醸成していくことが必要ではないでしょうか。
市谷：組織の中に、そうした文化を作っていくのが、アジャイルの「真髄」ともいうべきであり、一番難しいところかもしれないです。「考えきってから、作る」から「形にしてみて、それから考える」へのパラダイムシフトと言えますね。そういう見方がある、そういう考え方を取ってもよいんだ、という示唆がなければ、なかなか自力では変わりにくいと思います。例えば、山崎さんのような方がチーフの立場にいて、現場に適時適切なフィードバックがある環境は理想ですね。チーフを置くのか、メンターを置くのか、いずれにしても、異なる見方が得られる環境を作っていく必要があると思います。
そして、そうした環境から、また見方を他のメンバーに伝えていく役割、プロダクトマネージャーが出てくるのを期待する。チームや会社にそうした文化を作っていけるようなプロダクトマネージャーは、どうすれば育っていくと思われますか。
山崎：アジャイルを使いこなしてものづくりができるプロダクトマネージャーを、いかに育成するかというのは難しいテーマですね。今のところ、決定版となるような方法論もないように思います。ただ、プロダクトマネージャー自身が成長していくためにも「学べる環境」が必要ということは言えると思います。
また、チームがプロダクトマネージャーを育てるという側面もあることを考えると、やはり社内の「文化」は大切でしょうね。エンジニア、デザイナー、QA、プロダクトマネージャーといった、ものを作る組織の中心にプロダクト思考を置くことで、そうした環境が人を育てていくわけです。何もないところに「文化」を作るのには大変なパワーが必要ですが、逆に、一度それが出来上がってしまえば、今度は「文化」が組織の動き方をオートパイロットしてくれるという点で、取り組む価値はあると思います。
