見出し画像

『アジャイルなプロダクトづくり』を読んで印象に残った10のこと

先月発売された市谷さんの新刊のこちらを読み終えたので、印象に残った10のことを書き残しておきたいと思います

どんな本か

まずどんな本かというと、価値探索型のプロダクト開発のはじめ方について書かれていて、現場のストーリーをベースにしながら以下2つの問いに向き合い乗り越える方法について記載されている本になります。

  • プロダクトづくりにおける成果とは何か

  • 誰にとってのどんなことが価値になりうるのか

印象に残った10のこと

①チームを変えるのはユーザー

冒頭のストーリーにて、問題を抱えるチームの状況をみてコーチが言い放った一言。

「自分たち自身では買われないなら、チームの外から力を借りる。もっともチームを揺さぶるのはマネージャでもリーダーでもない。ユーザだ。」

第2章 最後に、ユーザーと対話したのはいつだった?

まさにその通りなのかと思う。マネージャやリーダーから言うとどうしても指示と捉えられてしまい、受け身のメンバーがでてきてしまったりすると思うので、自律的なチームをつくるのにはこういった方法が有効なのだと感じた。

②ファイブフィンガー3問題

「ファイブフィンガー3が続くということは、安定しているんじゃない。むしろ何の成長もしていないということだ。

第3章 僕らはそもそもチームになっているのか?

まさにこのファイブフィンガー3問題は実際にやってみたときに起きた事象で、メンバーがこの指標について快く思ってなかったときに発生したりしたので、変化がない指標についても注意が必要だということをあらためて認識することができた。

③KPIはゴールではない

KPI自体はゴールではない。ゴールにどうすればたどり着けるか、その切り口を定量的に表現したものがKPIにあたる。KPIをゴールにしている時点で、このチームには目指すものがない。

第3章 僕らはそもそもチームになっているのか?

これは以下の本でもあったメトリクスの話になると出てくる「グッドハードの法則」のことだと思うが、指標はあくまでも計測するための指標であって、指標を計測する目的をちゃんと意識、周知することの重要性を改めて再認識することができた。

④「スケジュール」と「進め方仮説」の違い

価値探索型のプロダクト開発において大事なのは「スケジュール」ではなく、「進め方仮説」という話。両者の違いは以下のようなものになる

スケジュール:
期日までに行うべきタスクや作成するべき成果物の順番と締切を示す

進め方仮説 :
どこに向かって(目標)何に取り組んでいくか、進め方の順番を示す

第5章 不確実なプロダクトづくりをさらに難しくする3つの罠

これは別の書籍でも目にした「計画つくりは大事だが、計画は役に立たない」といった話にも近いと感じた。アジャイルソフトウェア開発宣言にもあるように、やはり重要なのは「計画に従うことよりも、変化への対応」ということなのだと思う。

⑤プロダクトづくりで最初に行うこと

プロダクトづくりで最初に行うことが、仮説キャンバスで仮説を立てること。これを作成することで、「自分たちが何をわかっていないかをわかる」ということに焦点を置くことに価値があるというもの。

仮説キャンバス

1枚に情報を集約することで全体を俯瞰して把握することができると同時に、関係者へのスムーズな状況共有や各要素の繋がりについての検証をすることができると思うのでぜひ試してみようと思う。

⑥CPFとPSFの言語化

よく耳にするCPF(Customer Problem Fit)とPSF(Problem Solution Fit)を言語化したもの。3文字の英語はつい意味を見失いがちなので、こういった言語化は有難いと感じた。

CPFの言語化:
想定顧客は、(アーリーアダプターを特定する条件)といった状況にあるため課題として、(顕在課題、潜在課題)を抱えている

PSFの言語化:
想定顧客が抱えている(顕在課題、潜在課題)を、私たちが提供するソリューションによって(提供価値)の状況にする

第6章 誰かの間と経験と勢いではなく、仮説検証を拠りどころにする

⑦検証キャンバスというもの

「何を学ぶか」という言語化、および検証の方針を端的にまとめるための手段が「検証キャンバス」というもので、主に以下の要素の記載を行なっていくものになる。

・何を検証すべきなのか(Why)
・どのように検証するのか(How)
・検証して何を学んだか(What)

「仮説キャンバス」同様に1枚のキャンバスに集約することで、検証すべきものの全体像が一目で把握でき関係者との認識合わせに役立ちスムーズなコミュニケーションに繋がると感じたので、こちらも試してみようと思う。

⑧スプリントゼロでやること

スプリントゼロでやるべきことは、特定されたMVPをもとに「プロダクト全体で考えること」と、「スプリント単位で考えること」を分けることで、主には以下のようなものが該当するという話

・(初期の)プロダクトバックログ積み上げ
 ・方式検討や全体に関係する設計
 ・環境整備

・チームビルディング
 ・開発プロセスの認識合わせ

第8章 学びを最大限活かして、世界観を問いかける「スプリントゼロの概要」

スプリントゼロでやることは抽象度が高いけど、こういったカテゴリがあるとやることを整理するのに非常に役立つと感じた。

⑨プロダクトづくりの段取り

スプリントゼロでどこまで決めるかは「プロダクトの複雑さ」「チーム練度」によって変わってくるというもの。

■チーム練度が高いチーム
▽プロダクトの複雑さが低い場合:
 事前の段取りは詳細に不要
▽プロダクトの複雑さが高い場合:
 どの程度段取りを行うかはチーム自身で決める

■チーム練度が低いチーム
▽プロダクトの複雑さが低い場合:
 事前の段取りは事細かくは必要ないが、チームが結果を出すまでに時間を要するため期間に余裕を持たせることが大事
▽プロダクトの複雑さが高い場合:
 事前の段取りが詳細に必要なため、時間がかかることを前提にする

同じプロダクトをつくる上でもチーム練度によって考慮する点が異なるというのがアジャイルの特徴のひとつだなと感じた。

⑩プロダクトレビューについて

スプリントレビューは基本的に当該スプリントにおけるアウトプットへのフィードバックが中心になる為、2〜3スプリントこなしてまとまったアウトプットが得られたところで、プロダクトにおける「利用体験全体」をレビュー対象とするというもの。

半年くらいの期間をかけての案件をハイブリッドアジャイルで開発する場合は上記のような状況が生まれやすいので、意識しながらやっていこうと改めて感じた。

まとめ

ちょうど既存プロダクトの開発チームの問題や新規のプロダクト開発をしていくタイミングだったので実際に業務に活かせそうな話がたくさんあり、非常に参考になった。上記での気付きを開発メンバーにも共有しながら、アジャイルな価値探索型のプロダクトづくりをしていきたいと思う。

いいなと思ったら応援しよう!

この記事が参加している募集