RSGT2020で何を学びたかった／学べたか ～ 全参加セッションレポート
参加できなかった同僚＆自分のために、キーノート以外で参加した全セッションの記録や感想をまとめました。RSGTには初参加だったのですが、面白そうなセッションが多く、迷ったら「普段自分が（主に業務で）携わることが少ない領域や経験について知れそうか？」という基準で選びました。
Day1(2020-01-08)
Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術
https://slide.meguro.ryuzee.com/slides/100
Agile Studio Fukui でも、時折お客様からアジャイルコーチっぽいふるまいを期待されることが多いのですが、業務・サービスとしては積極的に扱っていないため、本業の方はどんなこと考えているのか？を知りたくて参加しました。
アジャイルコーチと言っても、コーチングだけでなく、顧客の結果と、顧客の育成に対する責任度合いによって、「カウンセラー・オブザーバー・技術アドバイザー」などなど複数の役割を期待され、それに応じて考えることもやることも変わる、という整理（スライド12枚目）が特にわかりやすかったです。今後アジャイルコーチがいる現場を支援する際の参考にもなります。
Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？
受託開発の場合でも、アジャイルなプロジェクトではPOはお客様が担当することになります（現実的な理由でPOの代理を置くことも多いですが）。そこで発生しがちな困りごととして、POがOutcomeでの優先度付けをしてくれない（する方法がわからない）というものがあります。
このセッションで一番参考にしたいのは、Outcomeを「ダイヤ」という仮想的な価値で表現する運用事例です。ストーリーと同じように、相対的に価値（売り上げだったり、削減できるコストだったり）を、ざっくりと見積もることで、優先度付けに利用しているとのこと。見えるようにする、数えられるようにすることって、大切ですね。
Ikuo Suyama - 見積りしないスクラム / NoEstimates Scrum
Scrumを回せるようになっても、見積もりについては悩むことが多いです。特に規模が大きなプロジェクトの場合、その扱いについて混乱する現場があります。十分にバックログがリファインメントされてない状態での見積もりをすべて捨ててやり直したり。
NoEstimate という考え方・やり方があることは聞いていたのですが、その具体的な事例とのことでとても参考になりました。スプリント（1Week）に収まるようにストーリーを分割（バックログリファインメント）することによって、見積もりの目的を代替えするのですね。見積もりを避けるのではなく、見積もりを数値で出してしまうことを避けている。うちの現場でも取り入れてみたいアイディアですし、見積もりの手法について、もっと掘り下げて考えてみたくなりました。
Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education
Agile Studio Fukui でもモブプロを推進していて、大きなディスプレイを常備したモブプロ専用のスペースがいくつもあります。ただ、まだモブプロを好まない人がいることも事実です（100％モブを目指しているわけではありませんが）。
このセッションでは、ABC分析など行動分析学の知見と、大学での授業を通じた経験を共有してもらいました。初めて知ったのですが、行動を強化する「好子」と、行動を弱める「嫌子」という考え方で分析をするそうです。ちょっとうまくいってないぞ、とチームを眺める時、参考になる切り口です。
Hiroyuki Ito／伊藤 宏幸 / 高橋 勲 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術
LINEでのSET（Software Enginer in Test ：テスト自動化技術でプロダクト開発チームのテストとプロセス改善をリードするエンジニア）チームの事例で、これも受託の自分たちにはあまり縁がない分野です。
特に参考になるのは、チーム力強化のやり方。チームに入った新人と中途のオンボーディングのために、ラーニングセッション（業務時間中の勉強）を1日30分から60分と決めてやっていること。しかも全部モブプログラミングで。
さらに、（ビジネス立ち上げではなく）技術的課題の発見・解決、つまり改善のための実験として1Weekレビューのデザインスプリントを継続的に行っているとも。うちはここまで徹底できていないなぁ、と刺激になりました。
Mitsuyuki Shiiba - テックリードは未来の話をしよう (Tech Lead in Scrum)
Scrumの役割として規定こそされてはいないものの、現実には重要な役割となるテックリード。うちにも、テックリードという呼び方はしないものの、実質的にそのような動きを期待するメンバーが何人かいるなぁ、と思い受講しました。
テックリートは何をすべき？というようなノウハウ話ではなく、テックリードの存在意義、組織における役割、チームの成長を支えることで未来を作っているんだ、という哲学です。個人的に参考にしたいと思ったのは、コーディング・レビュー・アーキテクチャ・技術選定などなど非常に多くあるやっていること、すべきことを「チームのために渡していきたいこと」と「チームのために引き受けたいこと」とに未来を見越して峻別し考えられていることです。これは、テックリードだけでなく、あらゆるリーダー役にとって意義あることです。
Day2(2020-01-09)
Mitsuo Hangai - 大企業の縦割り組織の中でProduct Discovery Teamを作ってサービスをリリース出来た話
大企業、しかも、楽天市場というても大きなプロダクト開発での事例とのことで、普段そのような規模の開発に携わることが少ない自分として興味深く参加させてもらいました。
縦割り組織での問題をクリアするために、事業・デザイン・開発それぞれの組織からスキルを持った人を集めチーム（Product Discovery Team）を作り仮説検証から始めたとのこと。実際の店舗を対象に超具体的にペルソナ設定し、カスタマージャーニーマップ作り、ペーパープロトタイプしそれを動画撮影、店舗向けカンファレンスでガチフィードバックをもらう・・。普段自分たちがなかなか実地経験できない領域での生々しい事例であり、参考になります。
Tomoharu Nagasawa - Going Agile with Tools - たまにはツールの話もしようぜ
アジャイル開発は身近ですが、普段はその現場で利用するツールについてあまりじっくり考える機会がないため、良い機会だと思い参加させてもらいました。
のっけから「ツールが使いこなせないのは、チームが機能してないからです」とのお言葉。ほんと、これって真実だと思います。すなわち、「問題から目をそらしている」「共通認識が持てていない」「他人事になっている」。
実際、ツール選びはチームの関心毎になりがちですが、人によって思いというか熱さが違うことが良くあります。他人事になることで上手に使いこなせず生産性が下がったりする。アイディア⇒バックログ⇒コード⇒ビルド⇒ステージング⇒本番といったモノや情報の流れ（⇒の部分）に注目することで、いかにやりたいことを加速できるか考えること重要。このアドバイスを肝に銘じたいです。
Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方
リアル軍隊（韓国軍）での従軍経験から、Scrumチームと軍隊の関連性について語るセッション。この内容はおそらく日本で他で聞くことはできないでしょう。軍隊生活や徴兵制度の一端を知ることもでき、すごく興味深かったです。
軍隊でのバックログは「体力の改善（フィジカル強化）」の優先度が高いとのこと。なるほど。そして、コミュニケーションのために、頻繁にプランニングやレトロスペクティブを行う。なるほど。基本月曜から木曜までトレーニング（途中点呼が挟まる）し、金曜日には評価、それでだめだったら、土日をつぶして追加のトレーニング！。なるほど、ハードだ。
軍隊では、上下（士官と兵士）での意思疎通が非常に重要なので、複数回層で1 on 1を実施したり、上官の上官に訴える仕組み（心の手紙）もあるとのこと。また、チームとしての幸福度を高めるために、頻繁に懇親イベントがあるそう。また、評価はチーム単位で行われることもScrumな組織との類似性が見られますし、取り入れられそうな活動も多そうです。
Matteo Carella - ORGANIC agility®: an evolutionary approach to organizational resilience
グローバルにアジャイルコーチングのサービスを展開しているAgile42社の組織変革に対するアプローチとのことで、普段海外のコンセプトに直接触れる機会もすくないこともあり参加してみました。
「オーガニックアジリティ」という枠組みでは、組織文化と多様性を保ったままの一貫性、顧客とその価値創造にフォーカスすること、小さく実験すること、フローの最適化など、やはり時流をとらえられたアプローチであることが理解できました。
一般に欧米の方はフレームを定義したり形式知化するのが上手だといわれていますが、それを実感できた気がします。
Day3(2020-01-10)
Open Space Technology
あれほど大人数でのOSTを体験するのは初めてで、壮観でした。全部で3セッション行われたのですが、やはりというか、チーム・組織・リーダーシップ・マネジメントに関連するテーマに誘引されました。
プロコーチなど、慣れている方が多いのでしょうか、意見交換／議論も心地よく進み、自分にとって良いヒントを得ることができました。模造紙とポストイットを自在に使って議論をグラフィカルに描き見える化していく（ファシグラ）のは強力なスキルですね。
最後に
あらためまして、各セッションのスピーカーの方々、ありがとうございました。良い刺激をいただきました。また、いろいろお話できて楽しかったです。今後とも、よろしくお願いいたします。
※ 自分のセッションおよびキーノート含む全体的な感想は↓よりどうぞ。
「組織かチームか」自分のメンタルモデルを再発見できた ～ RSGT2020に参加して
まずは素晴らしいイベントを企画・運営してくださったスタッフの皆様、私の発表に参加してくださった方、その後さまざまな形でフィードバックをくださった方、懇親やOST等様々な機会でつながりお話をしてくださった方々、ありがとうございます。
三日間、自分の発表以外も可能な限りセッションに参加し、Scrum・アジャイルコミュニティの「今この時」を浴びることができました。特に、人と組織・マインドセットやメンタルモデルについて、全体を通して多く語られていたように思えます。
個人の想いからScrumをスタートしチームに広め、組織レベルにスケールし、そして今は新たなチャレンジをしている高橋さん。マネージャをアジャイルなマインドセットに変えていくが「誰もおいていかない！」というSahotaさん。十牛図を引き合いに、Scrumはプロダクトでなく組織やプロセスを構築するフレームワークであり、自分が腹落ちしていることが真実でありガイドブック通りに正しいかどうかではないとCoplienさん。
いずれもそれぞれの経験を踏まえた深みがあり、禅と同じでアジャイルマインドの習得に終わりはないことを改めて感じます。
自分の発表もメンタルモデルと組織との関係性がテーマの一つでした。自分の失敗談を通じたメンタルモデルのアップデートについて話をしたのですが、こうして今、イベント全体を通じて流れたテーマにじっくり思いをはせると、自分の思考の癖・メンタルモデルについて、さらに新しい発見ができたように思います。
ミトコンドリアのメタファが示しているように、自分はやはり「組織という入れ物」から思考や行動をスタートするメンタルモデルを持っているようです。入れ物に対して、中身である自分やチームがどう影響を与えていくか、いかに良い入れ物にするか？が出発点でありゴールになっています。
しかし、世には、組織という入れ物を超えて活動している及部さんのチームもあるし、入れ物の容量を気にせずフラクタルに拡張し超個体を目指すきょんさんのチームもあります。まさに「守破離」であり、大きな変わり目というか時代性を感じます。
自分は少し古いのかもしれない。でも、メンタルモデルに良し悪しはなく、どれが正しいかではない。Copeも言っていたとおりまさに、"It is NOT Good, It is NOT Bad. It is about where you are." なのですね。
今回浴びた刺激は、きっと私に良い影響を与えてくれるとの確信があります。気づきと自己アップデートの機会をもらえるのがコミュニティイベントの良さだし、そのような気づきを得られるからこそ、RSGTはこれほど人気があり、長く続くコミュニティイベントなのだろうと思います。
日本企業もやれるはず ～ Scrum Interaction 2019 に参加して
スポンサーの役得として、Scrum Interaction 2019 に参加させてもらいました。詳しい内容は平鍋さんのブログを読んでいただくとして、私は自分なりの感想をまとめます。
野中先生＆サザーランド博士お二人のお話が生で聞ける！というプレミア感はもちろんなのですが、今の自分の立場だったり個人的な問題意識にマッチした内容で、本当に参加して良かった。今回はスポンサーの特典でしたが、自分でお金を払ってでもあの場にいる価値はあったと思います。
「エンパシー」による統一感
まず、野中先生からの強いメッセージである、共感（エンパシー）の重要性が、サザーランド博士だけでなく、他の講演者の方のメッセージにも随所にシンクロされ、全体的なテーマが自然に統一されていく感がありました。
平鍋さんが野中さんの代理として会場からの質問に答えるコーナーが面白かったです。笑いの取り方も乗り移ったかのような、これぞまさにエンパシーのなせる技かと。
黒船としての海外事例
今回、事例はすべて海外の方による海外企業のものでした。内容的にはソフトウェア開発やプロジェクトに閉じたものではなく、組織変革に関するもので、大企業における組織的な取組においては、海外がはるか先に行っていることを思い知ります。
3M、ING（オランダの銀行）、コカ・コーラ、MSDヘルスケアと、いずれも大規模な組織における事例であり、それを、（ある意味では）Scrum発祥の地である日本で聞くことになるわけですね。
これを今回主催者が狙ったかどうかは定かではありませんが、「日本の組織だからなぁ」という言い訳はもうできない状況に置かれている昨今、これらの事例が健全なショックを与えてくれます。
次は日本のアジャイルトランスフォーメーション事例を
私が「うっ」と思った一つは、MSDヘルスケアのフレイザー・ウッド氏によるアジャイルトランスフォーメーションのチェックリストでした。
- リーダーシップがトレーニングを受けている（＋現場を訪れている）
- 「変化のストーリー」と「状況に応じた価値」を組織と協力して生み出している
- 「アジャイルチャンピオン」を自ら選択している
- トランスフォーメーションの範囲が定義されている
- 初期のアジャイルスケーリングモデルが選択されている
- ベンチマークを測定している
- セルフサービスのアジャイルトレーニングが設けられている
- アジャイルコーチが採用されている
- トランスフォーメーションのバックログが共同で作成されている
- 「パイオニアチーム」が価値を提供している
アジャイル受託で売ってる会社なつもりだったのですが、自分の会社がまだまだスケールできていません。特に2番、4番、6番、9番が弱いことを自覚しています。お客様を巻き込んだプロジェクトレベルでのトランスフォーメーション（＝お客様のチームをアジャイルに）は事例がありますが、自分の組織をアジャイルにできているかというと、まだやれることは多いです。
私は、適材適所でウォーターフォールなプロセスも利用すれば良い派です。ただ、会社組織をアジャイルにトランスフォーメーションするのと、開発プロセスとしてウォーターフォールを採用すべきかどうかは、別の次元で考えないと、思考停止に陥るというか。中途半端に良いとこどりしようと考えるのは甘いですね。
3Mの事例でみんなが笑った、「私はScrumが好きです。本当に重要なプロダクト以外では」という、とある役員の言葉は、実は、あちこちの組織の状況をリアルに表しているんじゃないかと思っています。
平鍋さんは、「来年も Scurm Interaction やりたい！」とおっしゃっていました。そして、「難しいですが、やりがいあるじゃないですか！早く日本の事例を作りたい」とも。次は日本の組織の変革事例も見てみたいし、自分もそれに関われるよう、トランスフォーメーションのバックログを作っていきます。
Scrumのリズムで進行するイベントは良き
最後にイベント全体としての感想です。
まず、運営もスムースで機器などのトラブルもなく、気持ち良く参加できました。講演それぞれをバックログに見立てDoneにしていく、Scrum的な演出で進めるのも、このスタイルに慣れている自分にとっては落ち着きました。
講演の合間にテーブルごとのグループで会話し、ふせんを使いながら講演内容についての意見交換をしたのですが、その際の「Learn（もっと学びたいこと）レーン」の内容を Scrum＠Scale のように集約しつつエスカレーションし、まとめて講師陣にQAする、という流れも新鮮でした（ちなみにレーンは他に、「Learned（学んだこと）」「Idea（持って帰ってやってみたいこと）」）。
個人的には、講義の間の会話時間を、あと1分から2分ぐらいもらえると良かったです。ふせんを貼ったけど、それについて会話できない、というシチュエーションが何回かありました。
ただ、あまり間延びするのも良くないでしょうし、イベントとしてのリズム感としては、 いい感じでした。
スタッフの皆様、お疲れさまでした。ありがとうございます！
ビジネスアナリストというキャリアパス
今から20年くらい前。私が駆け出しのころは、エンジニアはプログラマーから始まってシステムエンジニア（SE）にキャリアアップするものだ、と教えられていました。プログラムばっか書いているようでは一人前ではない、と。
いまではご承知のように、すっかりこの構図は逆転していて、プログラミングができないとエンジニアとしての市場価値が上がりません。アジャイル手法も含めたモダン開発やDXと呼ばれるような領域では特にそうです。
当然、私も自社のエンジニアの技術転換を進めたり、技術転換を教育サービスとして他社に展開しようとしているわけですが、一方、業務知識や業務理解能力を活かし、要件定義やシステム企画にやりがいを感じている人も一定数いて、そのような人のキャリアパスをどうしたもんかな、と少しもやもやしています。
そんな時出合ったのが、アジャイルスタジオ福井に見学いただいたことをきっかけにコラボイベントもさせていただいた、エル・ティー・エスの山本さんと大井さんの書かれた「Process Visionary デジタル時代のプロセス変革リーダー」です。
Process Visionary デジタル時代のプロセス変革リーダー
- 作者: 山本政樹,大井悠
- 出版社/メーカー: プレジデント社
- 発売日: 2019/09/27
- メディア: 単行本
- この商品を含むブログを見る
ビジネスアナリストという職種は耳になじみがないかもしれませんが、私たちエンジニアがイメージしやすいのは、お客様側の立場でRFPの作成を支援したり、要件を取りまとめたり、変更管理をする役割です。アジャイル開発であれば、プロダクトオーナーをサポートする役割で同じチームのメンバーになる可能性もあります。
これは私も意外だったのですが、最近のビジネスアナリストは、プロダクトオーナーをサポートする役割を担うことも多いとのことです。著者の山本さんに伺うと、やはりプロダクトオーナーは忙しかったり、システム化するにあたっての知識が不足しがちなので、そのあたりを補う役割となるそうです。Scrumで言うところのリファインメントを担当するイメージですね。
もう一つ身近に感じたのが、ビジネスアナリストの基礎スキルであるビジネスモデリングについて。BPMNなどの記法を駆使して現状業務を整理したり、あるべき姿を描いたりします。このような図はSE時代に私も書いていたので親近感が。
また、以下も本書からの引用で、「ビジネスアナリストが果たす役割」なのですが、日本でビジネスアナリストという職種の方がまだ少なくて欧米ほど認知されないのは、システム開発を外注化し、これらの役割の一部をベンダーSEが肩代わりしてきた歴史と無関係ではない気がしています。
- 客観的な立場で業務・サービスの問題分析を行う
- 多くの関係者からあがる要求をまとめ、新たなビジネスプロセスを設計する
- ソリューションを開発するエンジニアに要求を伝え、要求通りのソリューションとなっているか検証する
- 取り組みに関係する部門・組織のコミュニケーションハブとなり、関係者の協力体制を構築する
しかし、日本においても、DXを成し遂げるためのシステムやサービス開発で内製化が主流になりつつあるのと同じ理由で、ビジネスプロセスマネジメントの変革を継続的に行っていくために、ビジネスアナリストという仕事も内製化され、専門職としてより認知されていくのではないか、とも思えます。
そのような将来像を考えるとき、私のようなベンダーの立場であっても、プログラマー以外のキャリアパスとして、ビジネスアナリストという職種がぐっと現実味を帯びるように感じました。
ここまでの書きっぷりだと、ビジネスアナリストは要件定義などの上流担当SEとほぼ同じ仕事なのか？と勘違いされてしまいそうなのですが、実際にはそう単純なものではないようです（IT部門に所属する「ビジネスシステムアナリスト」やビジネス部門に所属する「ファンクショナルアナリスト」、さらに、それらのステップアップ先であり、全社横断的な変革を担当する「エンタープライズビジネスアナリスト」等に分かれるとのこと）。
本書には、業績を担うオペレーション人材と、変革を担うビジネスアナリストとを対比する一節があり、オペレーション人材が足元の業績を維持拡大する役割であることに対し、（変革をミッションとするエンタープライズビジネスアナリストに限らず）ビジネスアナリストは長期的な組織の競争力を強化する役割であることを強調されています。
変革のためには、顧客や組織に対してもノーを突き付ける必要があるタフな仕事ですが、そのやりがいや面白みも大きいでしょう。
本書は、ビジネスアナリストという仕事の解説にとどまらず、日本における事例やヨーロッパにおける育成法についても解説されています。ベンダーの立場で要件定義を担当されている方や、エンジニアのキャリアパスとして、プログラマ以外の専門職に関心を持たれている方にもお勧めできます。「自分のやってることってビジネスアナリストの仕事じゃない？」という気づきが得られることは、価値があると思います。
幸福度ナンバーワンのアジャイル ～ Agile Japan 2019 福井サテライト
告知です。
Agile Japan 2019 の福井サテライトを福井の永和システムマネジメントで11月23日に開催します！
基調講演のビデオを観たり、平鍋さんの話を聞いたり、Agile Japan の公募セッションでウォーターフォールからアジャイルへの転換過程を発表してくれた本人たちの再演を味わったり、他にも参加型のコンテンツを企画しています。
今回のイベントは、Agile Japan 公募セッションで講演したメンバーが中心となって企画を進めています。「幸福度ナンバーワンのアジャイル」というテーマ。幸福度の追求はスクラムマスターの仕事に通じるものがありますし、何よりも福井らしくて良いですね（福井県はさる調査によると幸福度ナンバーワンなんですって）、私もお気に入りです。
そんな福井サテライト。目玉の一つは「参加型コンテンツ」です。アジャイルスタジオ福井の設備をフルに活かした、他では味わえない、幸福度の高いコンテンツになるべくスタッフは知恵を絞っています。情報は適宜アップデートしますのでチェックしてください。
（それ以外の地域の方も大歓迎ですが）北陸のエンジニアおよびアジャイルに関心のある方、11月23日（土）にお会いしましょう！
ザッソウと鶏と卵。『ザッソウ 結果を出すチームの習慣』を読んで。
久々のエントリとなります。（いつも再開するときは倉貫さんの本の感想になってるなぁ…）
仕事に関わる様々を聖域なく見直すだけでなく、ザクザクとなくしてきた倉貫さんの最新刊は、ホウレンソウからザッソウへの誘いです。
ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」
- 作者: 倉貫義人
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2019/08/31
- メディア: 単行本
- この商品を含むブログを見る
「仕事の基本はホウレンソウだ」。私も20年以上前、当時の上司からなんども聞かされてましたし、新人教育の教本にも書いてありました（数年後、もしかしたら私も後輩に対して使っていたかもしれません）。
仕事において、報告・連絡・相談それぞれが大切なことは否定しませんが、「仕事の基本はホウレンソウだ」とは、手垢がついてて2019年に口にしたいフレーズではありませんね。
特に私も属しているIT業界では、ワークスタイルやカルチャーがずいぶん変容してきました。アジャイル開発に本格的に取り組むことによるチームワークと自己組織化重視の姿勢。よりフラットな組織構造。リモートワークなど多様な働き方の許容。まさに倉貫さんとソニックガーデンが率先して実現してきたスタイルですが、なるほど、そのような会社にホウレンソウは似合いませんね。
私が「ザッソウ」が良いなぁと思ったのは、「納品をなくしたり」「管理をゼロにする」より、手軽に、今すぐ、自分から始められること。逆説的に言えば、倉貫さんも本書でザッソウせよと指示するほど無意味なことはないとおっしゃっている通り、組織的に大々的に導入していくものではないんですよね。マネージャが意識してザッソウを続け、その姿をチームや組織のメンバーに見せることで、ザッソウすることに対するしきいを下げ、「ザッソウミーム」を増殖させていくほうが、多分うまくいきそう。
鶏と卵的な話で、（フラットで自己組織的な）モダンチックな組織だからザッソウできるんじゃない？、と思われる方もいらっしゃるかもしれませんが、私は、規律あるリーダーシップが存在する組織であれば、どのような構造やワークスタイルの組織でもザッソウを広めることはできると考えます。
ここでの「規律あるリーダーシップ」とは、「組織を維持発展することに真剣な人」ぐらいの意味合いで使いました。階層的で縦割りが強い組織であったり、変革のスピードがゆっくりであったとしても、そこで働く人があきらめず問題を解決するという意識があれば、ザッソウは根付き、結果は出ると信じます。
これは、実際に私の周りにいる人を見てそう感じたからなのですが、、ここまで書いてきて、「もしかして規律あるリーダーシップはザッソウ的な行動が育んだのでは？」という質問に答えられない自分に気が付きました…。
いつまでも鶏と卵に振り回されず、自分から始めないとダメですね（笑）。
本書を、皆さんの身の回りにいる、リーダーシップを持った人と一緒に読むことをお勧めします。それこそ、「ちょっといい？ザッソウ本読んだ？」というザッソウを開始する良いきっかけになるでしょう。
書評。『正しいものを正しくつくる』を読んで顧客との共創に向け腹をくくる
著者の市谷さんがあとがきに書いているように、「正しいものを正しくつくる」は、プロダクトをアジャイルにつくるということに関する、市谷さんのここ5年を中心とした実践に基づく、まさしく冒険の記録です。
本書は入門書ではありませんが、経験の浅いスクラムマスターにとっては、第2章「プロジェクトをアジャイルにつくる」・第3章「不確実性への適応」は、Scrumというフレームワークの良いリファレンス実装として役立つでしょう。特に期待マネジメントや余白（バッファ）調整について詳しく、アジャイル開発になんらかの形でかかわるマネージャにとっても面白いはずです（個人的に「広さでコミットし深さで調整するプランニング」が気にいりました。とてもわかりやすくバランス感覚のあるスコープ調整のガイドとして有用です）。
プロダクトを成功させる＝アウトプットだけでなくアウトカムを出す、には「正しいもの」が何であるか、価値はどこにあるかを探索する必要があります。第4章「アジャイル開発は2度失敗する」・第5章「仮説検証型アジャイル開発」は、プロダクトオーナーはもちろん、POをサポートするスクラムマスターやチームメンバーも是非読んでおきたい内容です。もちろん、「正しくないものを正しく作ってしまった」経験のある私にはとても刺さりました。うん。やっぱりユーザーインタビューのような軽い検証を複数回行うべきだったな。。
本書の全編に横たわるメッセージは、「壁を超えること・壊すこと」。
私もプロダクトのPOをしていた時、チームとの間に壁がなかったかと問われると自信がありません。第6章「ともにつくる」は、そんな、何かとしんどいPOの機能を代行する「プロダクトオーナー代行」が印象に残ります。
アジャイルスタジオ福井でのリモート開発でも、お客様のシャドーとしてPO代行を置くことがあります。ただ、その際でもPO代行はあくまで「仕様ホルダー」としての役割に徹するのですが、本書では、一部の意思決定にまで踏み込んだPO代行について提案しており興味深い。曰く「プロダクトオーナーなる唯一絶対の存在の民主化」。まさにアジャイルを越える挑戦であり、 ユニークです。らしいな、と思いました。
5年前の私は、社命でそれまでの事業部を離れ、各部署から集まった有志と事業検討の横断プロジェクトを始めました。その中の一人が市谷さんで、仲間と一緒に新しい受託開発の形について様々な検討をして一区切りついた後、旅立ち、開発とビジネスの境目を越境し、活躍の場をどんどんと広げています。本書は、そんな市谷さんの知見を惜しみない勢いで言語化した、（現時点での）集大成とも言えるでしょう。
前回のブログでも軽く吐露したのですが、受託開発を生業とする私にとっても、「アジャイルのその先」は常に頭から離れないテーマで、顧客と開発者の垣根がない共創世界をどうやってWin-Winの形で実現するかが優先課題となっています。
本書は、そんな私にとっては、先に越境した先輩からの道しるべのように読めました。市谷さん、ありがとうございます。
