「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を読んで

書籍

正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

TL;DR

• 不確実性の高い中でのプロダクトづくりには共創によるプロダクトづくり(プロダクト作りの民主化)の開発スタイルが求められる。
• 心理的負荷がかかる時(わからないことが発生した時/境界線の越境時など)の乗り越え方/対処の仕方が書かれている。
• 仮説検証⇒アジャイル開発の流れで開発する上での作業の流れ、ポイントが書かれている。

この本を選んだ理由

• とても感銘を受けた「カイゼン・ジャーニー」の著者の方が書かれた本のため。
  • 「カイゼン・ジャーニー」の感想はこちら

印象に残った点

プロダクト作りが上手くいかないのは何故か?を説明している

• プロセスや技術が進歩してもプロダクトを作る苦悩は劇的に変わっていない
  • 確かに不思議だと思う。エンジニアとして技術の進歩をキャッチアップするだけでは意味がないということだろう。
• プロダクト/作り手(役割/経験/働き方)の多様性が不確実性を生んでいる
• これまでの不確実性を抑え込む戦い方は下記3点
  • 要件定義によって確実性を下げる
  • 合意を重視する
  • 合意形成を遵守する
    • 今の自開発組織はやっと(？)↑の形になりつつある。ただ、それでは上手くイカンということが分かるのはまだ先になりそう。

ユーザストーリーマッピングの要点が書かれている

• ユーザストーリーマッピングはMVPの特定だけではなく、その過程を参加者で作り上げることで文脈を理解する機会でもある。
  • 今の組織は分業化されていて、文脈まで意識できていない。個人的には文脈を理解する活動をすべきだと思っていたので納得感がある。

境界線の認識によりプロダクトづくりが上手く行かない

• プロダクトオーナーと開発チームにミッションの境界線(自分達の役割は作るところまで)の認識がある限り、プロダクトづくりはそれ以上進展しない。
  • 痛いところをつかれた。境界線があるところには同じ問題があるなぁ。と感じている。自分達の役割を意識しながらも視座を1つ高く持ち、役割の越境をすることを意識したい。

プロダクトオーナーの役割は主に3つある

• 「方向性の番人(なぜこのプロジェクトを作るのか)」「仮説の番人(プロダクトの世界観を実現するために何を備えるのか)」「プロダクトを形にするために必要な運用スキルと知識」
  • プロダクトオーナーの求められる役割は幅広く、一人で全てカバーするのは難しい。プロダクトオーナーの強みを活かし、他の役割を他のメンバーでカバーすると良い。
  • なるほど。強みを活かし柔軟に対応するのか。プロダクトオーナーが役割を完璧にこなすことが目的ではない。プロダクトを早くユーザに届けるために最適な役割分担も必要だということだろう。

プロダクト作りの民主化

• 独裁的に基準を決めるとボトルネックになり、多様性が生まれない。
  • 独裁的に物事を決められるほど全てを把握できるようなスーパーマンは少なくとも周りにはいないと思うし、そのような人を求めるのは現実的ではないと感じる。
  • 民主的に物事を決めるには話し合いの労力がかかると思うが、納得感のあるプロダクト作りには欠かせないのではと感じている。

セットベースかポイントベースかの選択はプロダクト作りの状況によって異なる。

• プロダクト作りの状況に応じて適宜セットベースかポイントベースかの選択をする必要がある。決め打ちしてしまうこと自体がリーンの原則に反する。 -プロダクトの特性を考えないで手段を決め打ちすると無駄な作業が発生するということか。

仮説キャンバスの読み方がかかれている

• 仮設キャンバスでは仮説の一本線で構想の筋の良さを判断する
  • 課題→代替手段→不満→提案価値→実現手段という一本線の観点でみること。
    • なるほど、そうやって読むことで構想の筋の良さを確認できるのか。

手段に恋してはならない。忠誠を誓う先はあくまで目的である。

• 引き出しを増やす学習は日常的にすべきだが、その引き出しに振り回されては本末転倒ということ。
  • 手段に恋しがちな自分には非常に胸に刺さる。なにを達成するための手段なのか？を常に考えたい。

仮説には種類がある

• 課題仮設、ソリューション仮設、インターフェース仮設の3種類
  • それぞれ本質、実態、形態にあたる
• 代謝建築論によると、人が対象を認識/理解するプロセスは形態→実態→本質という流れだが、構築のプロセスは本質→実態→形態という順に構想する考え。
  • 認識/理解と構築の流れは逆だと覚えておきたい。

仮説検証型のアジャイル開発は精度と頻度の戦略が大事

• 場面に応じ頻度から精度重視への切り替えをする
• どの仮説が確からしいか見立てがついていない状況であれば精度を求めず頻度で学びを得るアプローチをとる
• ユーザからインタビューやハリボテてで得られるものが想像による感想の段階になったら精度をあげる
• 頻度と精度のトレードオフをどのように進めていくかを可視化し、関係者に見える化する
• 利用の現場にチームで出て、イメージを作り手に宿す
  • 言語化された文書だけではその内容以上のものは作れないし、ユーザーストーリーを使いPOと会話で補完してもPOの言語化された内容以上のものは作れない
  • イメージを作り手にを宿すことでアジリティが増す。

わからないことをあえて増やす

• わからないということもわかると同様に「情報」である
• ただわからない状況は気持ち悪さがあり、安易な判断や同調圧力、確証バイアスに負けてしまう
  • 気持ち悪く感じるのはよくわかる。ただ、わからないことも「情報」であるとポジティブに捉えていけば気持ちの持ち方も変わると思った。

越境のためのコマンド

• 越境のためのコマンドとは上上下下左右左右過去未来と視座を上げたり下げたり、視野を広げたり、時間軸を変えたりと視座や視野の切り替えのためのフレーム
  • コナミコマンドを取り入れた面白い考え!

問いと向き合い続ける共創によるプロダクトづくりになる

• 「役割を中心とした調整によるプロダクトづくり」から「問いと向き合い続ける共創によるプロダクトづくり」へ移っていくはず。
  • そうあって欲しい。

今後

• 次はテック系から少し離れる方向の本を読んでみよう。