会社の人がおすすめしていた正しいものを正しくつくるを読みました。その読書感想文です。
本書のざっくりとした主張としては、仮説検証を繰り返すことによって「正しいもの」つまりユーザーにとって価値のあるプロダクトを探索し、それを「正しく」つまり不確実性をコントロールしやすいようにアジャイルに作りましょうということ。特に後者のアジャイルな開発についてはフレームワークとしてスクラムが厚く紹介されています。また、帯に「あるいはアジャイルのその先について」とあるように、素朴にアジャイル開発を適用した際の困難とその対応策が議論されています。本書の貢献は特にこの「アジャイルのその先」についての議論でしょう。その中で、自分の体験とも絡む特に印象に残った議論を少し掘り下げます。
問題の出発点は、スクラムにおけるプロダクトオーナーに機能が集中しすぎており、そこに期待を押し込めて分断してしまってはチームのパフォーマンスが頭打ちになるというところです。その状況を乗り越えるためには、開発チームがプロダクトオーナーの世界に「越境」していく必要がある、そして越境のカオスをコントロールするためにプロダクトに関する共通理解を育てましょう、共通理解を作るための手段として仮説検証を繰り返すことが有効だろう、というように話が進みます。このストーリーにはかなり同意します。自分の日々の暮らしの中で、うまくいっていないこと、うまくいったことが綺麗に言語化されて、良い本を読んだなという感触があります。
まずPOと開発チームの分断には心当たりがあります。各々がまずはスクラムにおけるロールを理解し、それを実践しようとするフェーズにあるとき、この状態に陥りやすいのではないかと感じました。誰が何をするべきかを指差し確認して理解しようとする過程で、過剰なセクショナリズムが生まれがちなのだろうと思います。
この問題意識に対する「越境」という方針に大変強く同意します。この本で僕が一番好きな部分です。短いエンジニア経験の中でうまくいったなと思うプロジェクトでは、確かにこの「越境」がありました。POならこう考えるだろうなというように、POの考え方を自然にトレースするようになり、プロダクトのコアに関わる判断や提案をスムーズに行うことができたと感じる期間があります。まさに共通理解によって自己組織化された状態です。スクラムを次のレベルに進めたいと思った時、「越境」という標語はかなり使えそうだなと思います。
最後の共通理解を育てることについては様々な方法があると感じました。そもそも何が課題かわからない、どう解決したら良いかわからない、つまり「正しいもの」の部分が未達の状態で共通理解を育てるには、確かに本書で述べられている仮説検証のプロセスを共に行うのが有力な手段だと思います。一方で、「正しいもの」がある程度固まっている場合は、別なコミュニケーションがありえるでしょう。自分が体験したのは、POがプロダクトの設計理念やユーザー行動を饒舌に話してくれるというケースです。デイリースクラムなどで仕様の質問や確認をすると、必ず「なぜ」を一緒に話してくれました。「ここのユーザーさんは〇〇な傾向が強いから是非こうしたい」「サービスとして〇〇が大事だからここは絶対外したくない」と言った具合です。こういう問答を数ヶ月繰り返すと、少しずつPOの考え方が頭に染み込んできます。そうすると、POが普段言っていることと違う仕様を発見して改善提案をしたり、どうしてもスコープを減らす必要がある時に筋よく落とすタスクを提案したり、といった高度な判断ができるようになっていきました。本書で述べられている「越境」はもっと積極的なPOの世界への関与を述べていそうなので、自分の体験は少し弱いかもしれませんが、段階的な越境の手段としては有用ではないかと思います。
また、本書では「目的」つまり「なぜそれをやるのか」の部分をとても大事にしており、その点も最近の自分の考えと一致しています。自己組織化の鍵は「良い目的が良いアクションを引き出す」だと個人的に考えており、本書でもそれに沿った主張がいくつか見られました。共通理解に基づく越境は最たるものです。プロダクトの目的を深く理解することによって、POの世界へ越境するアクションが自然と起こる、という体験をしていきたいし作っていきたいですね。本書で厚く議論されている仮説検証のプロセスと、それをつくる側と連携させる部分については、まだ自分ごとに落とし込めていないので、そこをもっと掘り下げて越境のための道具を増やしていけたら良いなと思っています。
