見出し画像

「右手に「正しいものを正しくつくる」、左手に「組織を芯からアジャイルにする」（右手編）」参加メモ

ぐんちゃ

イベントページ

資料

もしアップされたらここに貼る

右手編（正しいものを正しくつくる）メモ

 「正しいものを正しくつくる」とは

  • 世界の中で「整合を取る」こと

  • 左（整合されるもの、整合先）と右（整合するもの）の一致をつくること

  • 左と右の一致によって、はじめて「価値」が生まれる

    • 整合すべきことが「仕様」と「ソフトウェア」の一致だとしたら、創出される価値とは「仕様どおりに動くソフトウェア」

仮説検証をなぜ重視するか、仮説キャンバスとは

  • ソフトウェアとプロダクトは違う

  • 役割、前提として必要なもの、順番、担い手などが異なる

  • 整合先が「はっきりとしていない」ならそもそもその特定から始める必要がある

  • 整合先（左側）の解像度を上げる価値探索に出よう

  • さまざまな角度（観点）から光をあてて、少しずつ見えるようにしてい（解像度を上げる）

    • 「価値自体と価値になる条件」「価値にならない条件」この両者の「見分け」をつけられるようにする

  • 最小限の観点で本質を見分けられるか

    • だからこそ、仮説検証を重視する

  • 「か-かた-かたち」で見る

    • か：本質
      かた：実体
      かたち：現象

    • 実現のプロセスは、上記を↓の順で
      理解のプロセスは、上記を↑の順で

  • 見るべき対象・状況に「光」を当てて可視化する手段が「仮説キャンバス」

仮説検証の型、モヤミ

  • 「仮説キャンバス」で「か-かた-かたち」の整合を取る

  • 「仮説キャンバス」で「か-かた-かたち」を導く

    • か：課題
      かた：機能
      かたち：形態

  • 仮説立案の型

    • 順光型：観点を順に確かめていく、正攻法だが、「課題がAなら解決策は自ずとB」といったように「自ずの仮説」組みがち

    • 逆光型：「ありえない」「できなそう」から始める。ある程度「逆光型」を進めていき知識量を増やすことで逆効果説を思いつける

  • 「仮説」が立ったら「検証」する

    • 仮説の「確らしさ」を得るための活動＝「仮説検証」

  • 仮説検証で確かめる「整合」＝fit

    • Problem-Solution-Fit

      • 「か-かた-かたち」の一致をインタビューやプロトタイプ、MVPなどにより検証する

    • Product-Market-Fit

      • 期待するビジネス規模に到達するために、チャネルや利用体験向上に関する検証を行う

  • 「fit」の言語化を行う

    • できなければ、何を目指しているのか、達成しているのかさえも判らない

  • fitの仮説検証を「段階的」に進める

  • CPF（Context-Problem-Fit）はどう考える？

  • 左（仮説）を考える中で直面する最大のモヤミ、仮説の

    • 解像度が足りない（浅い）

    • 切実さが足りない（弱い）

    • 展望が足りない（薄い）

  • 解像度が足りない（浅い）

    • 状況のイメージがついていないから

    • 「ナラティブ・プロトタイピング」を用いる

  • 切実さが足りない（弱い）

    • 相対的な影響を受けるから

    • 状況仮説下の「他の課題との比較」を取る

  • 展望が足りない（薄い）

    • 仮説を前提にした展開がないから

    • 「仮説をひらく」（仮説の展開マッピング）

  • 左側（仮説、整合先）が整ったら、右側（プロダクト、整合元）に着手する

MVPがもたらす「デッドエンド」ルートを回避しよう

  • 「MVP」とは学習手段である

    • あくまで左側の仮説の検証ため、学ぶために適用する手段

    • 必ずしもソフトウェアを作って検証するとは限らない

  • 「MVP」と「価値提供」を区別する

    • 実際にはMVPをソフトウェアとして実現することが多い

    • 「動くモノ」が具体化することで、なし崩し的に検証→仮説検証を行ってしまうことがある

    • すると、左右の整合が取れず、邪悪な展開になる

  • 「MVP」vs「MKP」

    • 検証・学習手段と、価値提供の手段を常に見分けること。ソフトウェア的には同一でも、果たす役割としては異なる

    • 「MVP」Minimum Variable Product 検証・学習手段

    • 「MKP」Most knowledgeable Product 価値提供の手段

    • MVP→MKPの転換でSPFを用いる

正しくつくる

  • ということで「正しくつくる」

    • MVPベースでの構築か、MKP観点での構築かを選び、右側をつくる

    • 左側との整合を取りながら右側をつくる

    • プロダクトを作るときの左側は、ユーザー

  • POがユーザーの代弁者になる

    • ユーザーでありPOが整合先となる

    • 仮説検証を行ってきたからこそ、ユーザーを憑依させられて整合が取れているかどうかを担える

  • スプリントレビューでの論点2つ

    • ①「左側（仮説、整合先）」に合致する「右側（プロダクト、整合元）」となるためのフィードバック

    • ②「左側」自体へのフィードバック

  • 時間とともに現れる「変化」にも整合する

    • 左にも右にもポジ、ネガ、両方の変化があり、どちらかの変化により不整合が生じる

    • 時間に伴う変化も見逃さないプロダクトマネジメントが不可欠

  • ユーザー、プロダクト、チームの健全性を保つ

    • 価値創出を持続するために必要

    • 3者の健全性を保つ運営が前提

    • チームの状態をファイブフィンガーやふりかえりで検知する

  • これらは新規事業に限った話ではない

    • 新規事業は新たに整合先と整合元を作る

    • 既存事業は整合できているのかを捉え直す

  • 「右側」からの発見や導きもある

    • 右側から新たな仮説の発見や考えに至ることがある

  • あえて左右の「不整合」をつくることが可能性にもつながる

  • 整合を取る先が広がるほど難易度が上がる

    • 上司、評価、組織

    • そもそも、全てとの整合を取ることが成功とは限らない

「正しいものを正しくつくる」とは？知行合一とは？

  • 「正しいものを正しくつくる」

    • 世の中にあるはずの「正解」を見つけてきて「回答」することではない

    • 自分たち自身で正解となりうる「整合先」自体を見出し、適した「整合元」を作り出すこと

    • さらに、時間とともに現れる変化を捉え、「整合」を維持する

    • その為には自分たち自身の「健全性」をも整合する必要がある

  • 知行同一

    • 「知は行の始なり、行は知の成るなり」知ることは行為の始めであり、行為は知ることの完成である

    • 「知る」ことと「行う」ことは分離不可能であり、行動を伴わない知識とは、「知らない」と同様であるとされる

    • 「左」と「右」で「整合を取る」とは「知行同一」が意図することと、整合するものと言える

    • みなさんのチームや組織では、正しいものを正しくつくれていますか

正しいものを正しくつくる部

  • イベントの際のmiroから申し込みができる

  • 部活のようにやりたい

感想

  • 左（仮説）を考える中で直面する最大のモヤミのところや、時間とともに現れる「変化」にも整合する必要があるという話、『解像度を上げる』と何か重なる部分がある気がしながら聞いていた

    • 『解像度を上げる』では「深さ・広さ・構造・時間」の4視点で解像度を上げていく

    • モヤミをクリアにするにもそれらの視点なども役立って、それらの視点で見ていくための手段は色々あるんだろうな〜と思いながら聞いていた

  • 「今向き合っているものの左がなにで右がなにで、それらは整合が取れているんだっけ」「今何のために何をしているんだっけ、今どうなっているんだっけ」を普段の仕事の中でも意識してみようと思った

    • 正しいものをつくれているか、正しくつくれているか

    • 恐らく今の自分はQAとして整合への意識が弱いことがあって、それゆえ仕様の妥当性がもしいまいちだったとしても気付くのに時間がかかる（または気付けない）気がする

    • 「左側」に合致する「右側」になるためには？そもそもの「左側」自体は？時間とともに変わったことは？などの視点をひとまず持ってみながらミーティングにのぞんでみよう

左手の申し込み

こちらから


この記事が気に入ったらサポートをしてみませんか？