今回は「カイゼン・ジャーニー」を要約していきます。開発現場におけるプログラマー組織およびプロジェクトマネジメント・プロダクトマネジメントの要諦をストーリー形式で学ぶことの出来る本です。「越境」をキーワードとして「個人で越境する」⇒「チーム（社内）で越境する」⇒「チーム（社内外問わず）で越境する」というテーマ立てで様々なフレームワークの解説と改善活動の一連の流れについて言及した本です。
「カイゼン・ジャーニー」
■ジャンル：IT・経営組織
■読破難易度：低（平易な言葉と豊富な図解がなされており、プログラミング・PM未経験でもわかるような構成になっています。）
■対象者
・個人・組織のPDCAサイクルを回す方法論について興味関心のある方
・コトマネジメントと組織マネジメントの両立に関する理論を学びたい方
・プロダクトマネジメント・プロジェクトマネジメントに従事する方全般
■参考文献
■プロダクトマネジメントのすべて
■要約≪プロダクトマネジメントのすべて 前編≫ - 雑感 (hatenablog.com)
■要約≪プロダクトマネジメントのすべて（後編）≫ - 雑感 (hatenablog.com)
■エンジニアリング組織論への招待
■要約≪エンジニアリング組織論への招待≫ - 雑感 (hatenablog.com)
■ザ・ゴール
■要約≪ザ・ゴール≫ - 雑感 (hatenablog.com)
■要約≪クリティカルチェーン≫ - 雑感 (hatenablog.com)
【要約】
■スクラム開発とは
・スクラム開発は下記5つのパーツで構成される開発形式とされます。
1）スプリント（繰り返される開発期間）
2）スプリントプランニング（スプリントで行うことの計画）
3）デイリースクラム（日々の進捗や優先順位を確認するワーク）
4）スプリントレビュー（作成物をレビューしてフィードバックをもらう）
5）スプリントレトロスペクティブ（プロセスを検査し、時に根本的なやり方を変える振り返り）
スプリントは透明性担保と品質検査を徹底して経験から学びPDCAを回していくアジャイル開発の手法で、計画をそのまま突き進むウォーターフォール開発とは違います。スクラム開発は「相互学習」・「PDCAサイクルを回し続ける」を前提にした開発手法とされ、各工程のデリバリーで用いられます。
■プロダクト開発組織及びプロジェクト組織運営の要諦について
・「われわれはなぜここにいるのかという組織目的から方針の骨子を組み立てるを徹底する」のがプロジェクト・プロダクト開発の基本で、これは営業組織などの戦略策定プロセスと類似します。プロダクト開発においてはスクラムマスターがこの手の役割を担うもので、担う上ではファシリテーションや構造化スキルが急所とされます。コトマネジメントの世界における各論のエッセンスとして「会話ログを残す」・「タスクやビジョンを常に可視化し暗黙知・属人化を回避する」・「価値基準・行動規範から一貫したストーリーのある意思決定を「し続ける」」などがあります。
・開発組織のマネジメントにおいては優先度が低くなりがちな「組織コミュニケーション総量の担保」は危機回避のための重要な技法です。特定個人のオーバーワーク・業務遅延・認識ずれは意図せず発生するものであり、それを先んじてシステムで対策をうち、プロダクト・プロジェクトの生産性を最大化するように人資源を「やり繰り」するのは重要な仕事です。
■プロダクト開発における思考プロセスとステークホルダーマネジメント
・「社外や専門性の異なる社内メンバーと協業して高い成果を目指す」という性質はプロダクト開発・プロジェクトにつきものです。ステークホルダーが増減する度に面倒なようでもプロダクト・プロジェクトビジョン・価値基準の言語化・共通認識化⇒イシュー・優先順位のすり合わせを行い、「アップデートし続ける」ことが協業促進の最短ルートとされます。そのコミュニケーション設計と構造化がPdM・PjMの重要な役割となります。
・プロダクトやプロジェクトの重要事項を規定する上ではお金や労力を割いてでも解決したい問題は何か？という視点で物事を着想・判断「し続ける」ことが基本となります。その上では、「人間は感情や物理的な課題を解決する為にサービスやジョブを買う」というジョブ理論はエンジニアリングの世界において有用な考え方と言えます。「仮説キャンパスを埋める」・「Whyから始める」といった思考の基本スタンスやリーンキャンパス・ビジネスモデルキャンパスなどの初期仮説設計のためのフレームワークを用いて合意形成・実行していくのが実際となります。
■ユーザーストーリーマッピング・MVP開発・ユーザーヒアリング
・「顧客が解決したいことは何で、それはどんな顧客体験を伴うものか」というストーリーメイキングすることがユーザーストーリーマッピングです。これはマーケティングの世界でいう所のカスタマー・ジャーニーマップを描いて仮説構築・可視化するプロセスと似ています。「ユーザーストーリーに照らして、最低限の仕様だけで開発・仮説検証しながら各論を整えていく開発形式」がMVP開発とされます。MVP開発においては一連の導線を設計し、顧客課題の真因を特定し、優先順位付けしていくという形で運用されます。大事なのは「ユーザーがお金を払ってでも解決したい課題かどうか？」という観点でこれがプロダクトがビジネスとして市場が成立するかの判断軸となります。
・プロダクト開発・プロジェクト運営において、仮説の解像度を高める為にユーザーヒアリングを行い、「仮説の確からしさ担保」や「視点の発想や転換を刺激し生産性・品質を高めること」を目指します。尚、インタビューの際は「期待のある答えをしようとするインタビュイー」が必ず存在するので、「推測と事実・行動を分けてヒアリングしていく」のが必要なプロセスとなります。
【所感】
・「コト」に対峙するプロダクト開発の世界においても組織の生産性を最大化させるための方法論は「ヒト」を起点としたものが多いというのは大きな発見でした。ビジョンやスコープ・イシューを定め、合意形成・アップデート「し続ける」プロセスのリードにより組織の生産性を最大化させて成果を出すことがPdM・PjMの重要な役割であるということは普遍的であることも再確認でき、勉強になりました。
・エンジニアリング業務については構造化・論証スキル・不確実性に対峙するスタンスなどソフトスキルや数的な知識や経験を必要とすることは本書からも明らかでした。自分自身が「短期の時間軸で具体的な課題解決・成果の総量にコミットする」職業倫理で業務に従事することに慣れ親しんできたあまり、プロダクト/プロジェクトマネジメントにおいて「お作法の違い」によるスコープや優先順位・仕立ての筋悪さを痛感する場面が多い中で、非常に示唆に富んだ内容が多かったと感じた本でした。培った「組織マネジメント」の引き出しや視点は有用ではあるものの、あくまで「コト」に向き合う世界なので、共通言語は「コト」であり、各論や人の感情を意識してイシューではないので捨てる勇気（それが期待役割や成果の為の最短ルート・イシューになるので）がスキルとして必要と理解しました。慣れの問題に感じるので、開発業務や○○マネジメントにおける正統派の理論に忠実に実践していくことで早く自分も本書のようにバリューのあるPdM・PjMを努めたいと感じる次第でした。
以上となります！
