日本企業をビルドトラップの底無し沼から救うために!!(『プロダクトマネジメント』を読んで)

はじめに

• 「様々な部門にアジャイル開発を広げたいが、開発部門にしかアジャイル開発を導入できない」
• 「決められたロードマップに従うだけで、スクラムチームにプロダクトに対する決定権がない」

大企業や、従来型企業でスクラムを推進する方々からよく聞く悩みだ。

この状況でも、初めのうちは、チームプレーによる仕事スタイルの転換やふりかえりなど、開発チームに楽しい日々が訪れる。
けれども、残念ながらそんな楽しい日々は長く続かない。
ユーザーや機能の背景が見えないまま、機能リリースを急かされている内に、だんだんと「自分達は檻の中で必死に走り続けるハムスターじゃないか!?」と思えてくるからだ。
そして何より悲惨なのは、誰も使わない機能が、リリースされ続けることにある。

プロダクトビジョンを自分で決めたいと言い続けていますが、許可されていません。マネージャーは私にソリューションを渡し続けます。何か別のことを提案するたびに、拒否されます。スクラムを始めたとき、スクラムチームは自律的であるべきと言われました。現状はまったく自律的ではありません。(『プロダクトマネジメント』より引用)

*1

『プロダクトマネジメント』について

今回取り上げる『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』は、この問題の構造と、実際にどのように仕事のやり方を変えるべきかが、極めて明快に示されている本である。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

著者によれば、「はじめに」で触れた問題は、組織がビルドトラップに陥った結果だという。
そしてビルドトラップとは、以下の状況のことだ。

ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況です。

ビルドトラップは、軽快な言葉の響きに反して、実際には多くの組織がどっぷりと漬かっている底無し沼のような状況を指す。
そしてそれは最悪の場合、組織全体の崩壊までに追い込む「死に至る病」なのだ。

ビルドトラップに陥る原因

本書で最も印象的だったのは、組織がビルドトラップに陥る原因がこれ以上ないほど明確に描かれていることだ。
著者によれば、組織がビルドトラップに陥る原因は以下のようなものがある。*2

• マインドセット: 経営層のビジョン、戦略の不在。組織全体のプロダクトリリースの目的化
• 組織構造: 企画部門とビジネス部門の縦割り化。「ラボ」という名の予算や権限の不十分な譲渡
• 予算編成: 年次計画に基づき、使い切らなければならない予算
• 報酬制度: 従業員の成果指標は、リリースした機能数
• 人材: プロダクトマネージャーのスキルセットの認識やトレーニング不足
• 文化: 失敗が許されない、「心理的安全性」が低い文化

私の言葉で言い換えれば、要するに、「不確実な顧客に向き合う」よりも、「プロダクトや機能をリリースする」ことに組織の目的を限定させた方が、あらゆる意味で圧倒的に楽なのだ。

前者より後者の方が、組織編成も、マネージメントも、オペレーションのマニュアル化も、人事評価も、圧倒的にやりやすいだけではなく、組織全体として「一生懸命頑張っている」という心理的充足感も得られやすい。
一方、前者は、組織編成やマニュアル化もやりづらいだけではなく、不確実で気まぐれな顧客の声に絶えず向き合う結果、「ある日突然仕事がなくなる」という不安にも晒されやすくなる。

『みんなでアジャイル』に引用されている、心理学者のヴァージニア・サティアの言葉は象徴的だ。

ほとんどの人は、不確実性の悲惨さよりも、不幸の確かさを好む

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

どう仕事を変えていくべきか

著者は、マーケットリーという架空の会社のコーチングを通して、戦略やビジョンの策定からプロダクトマネージャーの役割の定義、プロダクトマネジメントプロセスの導入に至るまで、どのように組織がビルドトラップから抜け出し「プロダクト主導組織」に変革していくかを本書で丁寧に記述している。
詳しい内容は本書に直接あたっていただくとして、ここでは印象に残ったことと感想を挙げてみたい。

プロダクトマネージャーの役割

本書では「悪いプロダクトマネージャーの典型」として、顧客からの要望をただ聞いて伝えるだけの「ウェイター」、スティーブ・ジョブスよろしく一方的にチームに自分のビジョンを押しつける「ミニCEO」が挙げられている。
どのタイプも一緒に働いたことがあるため、該当の章は苦笑しながら読んでいた。
プロダクトマネジメントは高度に専門的なスキルだが、多くの人にとって学ぶ機会はなく、それゆえトレーニングの必要がある、という著者の主張には、100%共感だ。

プロダクトマネジメントプロセス

本書の素晴らしい所は、顧客への早期検証による学習の重要性や様々な方法が紹介されている一方で、学習をスキップすべきケースも併せて紹介していることだ。

ECサイトの購入ページが良い例です。ほかのEC企業向けにこの機能を売り込むつもりがないなら、ここですべての時間を費やすべきではありません。このソリューションに関してはすでに多くの実験が行われていて、それを活用すればいいのです。

今まで『リーン・スタートアップ』片手にあらゆることを顧客相手に検証したがり、他社製品を「パクる」ことに対して後めたさを覚えるプロダクトマネージャーと数多く出会ってきたが、これからは本書を勧めてみたいと思う。*3

どうやって、経営層やビジネス部門をアジャイル開発に巻き込むか?

さて、「はじめに」の悩みに戻れば、組織がビルドトラップから抜け出すためには、経営層やビジネス部門を巻き込まなければならないのは明白です。
本書では、CTOが問題を認識し、組織の全面的な変革を決意することから始まりますが、実際には、一番難しいのがここではないかと感じています。
どうやって、経営層やビジネス部門をアジャイル開発に巻き込むか?
ここからは、本書で示されるヒントや、私なりの経験則を伝えて、ブログを終わりたいと思います。

「アウトカム(成果)に着目したコミュニケーション」

まず、明日から私たち現場がすぐに出来ることとして、本書の「アウトカムに着目したコミュニケーション」はかなり有効だと感じています。
スプリントレビューをはじめ、あらゆる場面でビジネス部門に、アウトカムに着目したコミュニケーションを仕掛けていくこと。
具体的には、たとえば以下のような質問をしていくのが効果的だと感じます。
「これは本当に顧客が使うのでしょうか?」
「誰を対象とした機能でしょうか?」
「こないだリリースした機能は、どれくらい利用されていますか?」
ビジネス部門の方は(本来は)このような話題に興味があるため、乗っかってくれる確率は高いです。*4

日本の大企業や従来型企業では「役員」を攻める

私は日本企業がビルドトラップに陥る原因の一つとして、ビジネス部門と開発部門の分離が大きいと考えています。
しかし、両部門の部長にいくらビルドトラップを訴えても、与えられたノルマをこなすことに精一杯な彼/彼女らにその声を響かせることは難しい。
攻めるべきは「役員クラス」です。
具体的には、以下のような解決策が考えられます。

• 仕事で成果を積み重ね、「信頼貯金」を貯める
• 役員やマネージャーにアジャイル開発のトレーニングを実施する
• 役員にアポイントメントを取り、現状の問題と解決策をプレゼンする
• 上記のためにコンサルタントやアジャイルコーチを雇う

とはいえ 、「それが出来たら苦労しないよ.....」という声が聞こえてきそうです。
確かに、上記を現場が実行するのは、なかなかは難しいのが現実。

そのため、現時点でのベストな解決策は、役員に本書を読んでもらう事ではないでしょうか。
さぁ......勇気を振り絞って役員に本書を渡してみましょう!!

おわりに

企業がビルドトラップから抜け出すためには、現場だけではなく経営層やマネージャーが本書を読むことが極めて重要だと思います。
それくらい素晴らしい本でした!
日本企業がビルドトラップから抜け出すために、アジャイル開発の効果を最大化するために、是非ご一読してご自分の会社の経営層にも是非オススメしてみてください!

本書を頂いたRyuzeeさん、そして最後までお読みいただき、ありがとうございました!!

*1:特に断りがなければ、本ブログの引用はすべて『プロダクトマネジメント』から

*2:これは、組織がビルドトラップに陥る原因が無数の網目のように張り巡らせれており、大企業や従来型企業以外のスタートアップ等の企業も、組織拡大等のちょっとしたきっかけであっという間にビルドトラップに陥る事を示している

*3:文脈が違うので一概に比較できないものの、過去のベストプラクティスや資産等の活用は、エンジニアの方が遥かに進んでいると感じている

*4:組織を変えることについては、『Fearless Change』も参照

Fearless Change