[CLONE]「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論-

会社として正式にはこちらで公開しています。同じものです。
https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023

Transcript

1. 「エセ⾃⼰組織化」症候群から脱却し、 約束を守るプロフェッショナルな アジャイルチームになるには -アジャイル時代のマネジメント進化論- Visionalグループ 株式会社ビズリーチ プロダクト組織開発本部 プロセス改善部 ⾼橋裕之 内藤靖⼦
2. 2 本コンテンツの⽬的 本⽇お伝えしたいこと Learning Outcome エグゼクティブ、マネジャーの⽅へ • プロダクト開発チームの「内側」で起きやすい事象 • ビジネス(事業)とものづくりの相関関係 • チームのエンゲージメントは⾼いのに成果が出ていない エンジニアチームはなぜ⽣まれるか 1. ⾃⼰紹介 2. 株式会社ビズリーチ紹介 3. 「エセ⾃⼰組織化」症候群とは何か 4. 処⽅箋 5. ビズリーチのSODA構想とは 6. 今後の展望 アジェンダ プロダクト開発者・エンジニアの⽅へ • プロダクト開発チームの「外側」で起きていること • スクラム以前に理解しなければならないエンジニアの仕事の幅広さ • 個の⼒よりチームとしてのパフォーマンスが重要な本当の理由
3. 3 ビズリーチ・ジャーニー JJUG CCC 2022 Fall (2022/11/27) DevOpsDays Tokyo2022 (2022/4/21) 本⽇発表するのはこれらの続編です
4. 4 ⾃⼰紹介 受託プロジェクトを数多く経験後フリーランスを経て、1996年、⽇⽴通信システム株式会社(現・ ⽇⽴情報通信エンジニアリング)に⼊社。交換機やIP機器の開発に従事。2002年、ソニーデジタル ネットワークアプリケーションズ株式会社に⼊社。コンシューマ向けカメラ開発や全社プロセス改 善に従事。2013年、ウイングアーク１ｓｔ株式会社に⼊社。2018年から品質管理部部⻑ 兼 製品品 質管理責任者 兼 OSS管理責任者に就任。2021年7⽉、株式会社ビズリーチに⼊社。2021年11⽉か ら部⻑に就任。 Certified ScrumMaster® Advanced Certified ScrumMaster® Certified Scrum Product Owner® Certified Scrum Professional® - ScrumMaster Certified Scrum Professional® - Product Owner Certified Agile Leadership I Mobius Outcome Delivery Certified Practitioner Management 3.0 licensed facilitator. ⾼橋 裕之（Hiroyuki TAKAHASHI） 趣味 ⼭、海、⼩説、漫画、映画、ランニング 経歴
5. 5 ⾃⼰紹介 2000年、キヤノンソフトウェア株式会社(現・キヤノンITソリューションズ株式会社)に⼊社。プリ ンタドライバ開発に従事。2008年、ソニーデジタルネットワークアプリケーションズ株式会社に ⼊社。コンシューマ向けハンディカム開発や携帯型⾳楽プレイヤー開発、プロセス改善に従事。 2015年、ウイングアーク１ｓｔ株式会社に⼊社し、プロセス改善に従事。2021年8⽉、株式会社ビ ズリーチに⼊社し、ソフトウェアプロセス改善グループの⽴ち上げを⾏う。 Advanced Certified ScrumMaster® Certified Scrum Product Owner® 内藤 靖⼦（Yasuko NAITO） 趣味 コストコ、ねこ、ファスティング、昼寝 経歴
6. 株式会社ビズリーチ紹介 6
7. 会社概要 株式会社ビズリーチ / BizReach, Inc. 創業 ：2009年4⽉ 代表者 ：株式会社ビズリーチ 代表取締役社⻑ 酒井 哲也 グループ従業員数：1,821名（2022年7⽉末時点） 拠点 ：東京、⼤阪、名古屋、福岡、静岡、広島 資本⾦ ：1億3,000万円 事業内容：HR Techのプラットフォーム・SaaS事業
8. Visionalグループミッション
9. 株式会社ビズリーチ ミッション
10. 株式会社ビズリーチ サービス⼀覧 即戦力人材と企業をつなぐ 転職サイト OB/OG訪問 ネットワークサービス 人材管理クラウド 採用管理クラウド クラウド勤怠管理システム 経費精算システム
11. 「エセ⾃⼰組織化」症候群とは何か 11
12. 12 「⾃⼰組織化」という⽂⾔の消滅 •⽐較的初期※1のスクラムガイドから「⾃⼰組織化」という⾔葉は使われてきた。 •例えば「スクラムガイド2017年10⽉版」では以下のように説明されている(⼀部)。 •しかし、最新※2の「スクラムガイド2020年11⽉版」で「⾃⼰組織化」という⾔葉 が消える。何が起きたのだろうか。 “スクラムチームは⾃⼰組織化されており、機能横断的である。⾃⼰組織化チームは、作 業を成し遂げるための最善の策を、チーム外からの指⽰ではなく、⾃分たちで選択する。 機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能⼒を持っている。” ※1 Scrumの元となった⽵内弘⾼⽒、野中郁⼆郎⽒の論⽂「The New New Product Development Game」に⾃⼰組織化は登場しており、スクラムガイド2009年5⽉版以降で使われてきた。 ※2 2023年1⽉11⽇現在 “開発チームには、以下のような特徴がある。 • ⾃⼰組織化されている。プロダクトバックログをリリース判断可能な機能のインクリ メントに変える⽅法は、誰も（スクラムマスターでさえも）教えてくれない。 • (以降、略)”
13. 13 「⾃⼰組織化」という⽂⾔の消滅 •InfoQ 2020/12/24 の記事 •スクラムガイド 2020の変更点: Ken Schwaber⽒とJeff Sutherland⽒とのQ＆A (参考) Ben Linders InfoQ ”Changes in the 2020 Scrum Guide: Q&A with Ken Schwaber and Jeff Sutherland” 2020-12 https://www.infoq.com/articles/changes-2020-Scrum-guide/ (参照 2023-1-10)
14. 14 「⾃⼰組織化」という⽂⾔の消滅 •InfoQ 2020/12/24 の記事 •スクラムガイド 2020の変更点: Ken Schwaber⽒とJeff Sutherland⽒とのQ＆A “Sutherland⽒: 2020年版スクラムガイドは、より短く、より焦点を 絞り、One Teamを掲げています。3つの成果物をコミットメントで ⽬標に結びつけることに加え、業界の最⼤の課題である「リードし ないサーバントリーダー」と「⾃⼰組織化した開発者が好き勝⼿ やってコミットメントを守らない」という2つの課題に取り組みまし た。” (参考) Ben Linders InfoQ ”Changes in the 2020 Scrum Guide: Q&A with Ken Schwaber and Jeff Sutherland” 2020-12 https://www.infoq.com/articles/changes-2020-Scrum-guide/ (参照 2023-1-10)
15. 15 とあるプロダクト開発で… ねぇ、◯◯の機能って 3⽉のリリースに乗 るっていってたよね？ ⼊ってなくない？ あぁ、アレはボクたち 開発チームのスプリン トプランニングで⼊ら なかったんだ。 ええっ！ お客様、あの機能ずっーと 待ってるんだぞ！ 3⽉には必ず！ってお伝え しちゃってるんだよ〜！ 他のPBIを優先させ たしね。アレは3⽉ リリースからはド ロップさせてもらっ たよ
16. 16 とあるプロダクト開発で… そんなわけで、私た ちのチームは今回余 裕があったので例の 新税率対応画⾯の実 装を終えたわ ちょ待てよ！ 俺たちバックエンドチー ムは聞いてないぞ！ キミらだけ出来てどーす んだよ！ スプリントプランニングどお りなんだから仕⽅ないじゃな い、私たちのチームは⾃律性 が⼤事なのよ！
17. 17 とあるプロダクト開発で… one for all, all for one !!
18. 18 「⾃⼰組織化」という⽂⾔の消滅 “Autonomous, self-organizing teams are often understood as a core aspect of Agile. They hold the promise of unlocking people and giving them an environment where they can show up at their best and achieve the extraordinary. Yet, they donʼt work. Or more accurately, it is very very difficult to get them working well.” “⾃律的で⾃⼰組織化されたチームは、しばしばアジャイル の中核的な側⾯として理解されています。このチームは、 ⼈々を解放し、彼らがベストを尽くし、並外れたことを達成 できるような環境を提供することを約束するものです。しか し、それはうまくいきません。 もっと正確に⾔うと、うま く機能させるのが⾮常に難しいのです。” （参考）マイケル K サホタ(Michael K Sahota). ” Autonomous, Self-Organizing Teams Donʼt Work”. SHIFT314 Change Reality. 2021-03, https://shift314.com/autonomous-self-organizing-teams-dont-work/, (参照 2023-1-10) “Number one, when you tell a team that theyʼre autonomous, theyʼll believe you. Theyʼll think theyʼre autonomous and theyʼll make decision after decision after decision ‒ eventually, theyʼll hit what we call the “invisible electric fence.” That is, theyʼll discover that they actually werenʼt allowed to make the decision. ” “第⼀に、チームに「⾃分たちは⾃律している」と⾔えば、 彼らはそれを信じます。 そして、⾃分たちが⾃律している と思い込み、次々と決断を下していきます。やがて、私たち が「⾒えない電気柵」と呼んでいるものに突き当たりま す 。つまり、⾃分たちにはその決断をする権限がないこと に気づくのです。” マイケル K サホタ(Michael K Sahota).
19. 19 「⾃⼰組織化」という⽂⾔の消滅 •InfoQ 2020/12/24 の記事 •スクラムガイド 2020の変更点: Ken Schwaber⽒とJeff Sutherland⽒とのQ＆A “Sutherland⽒: 2020年版スクラムガイドは、より短く、より焦点を 絞り、One Teamを掲げています。3つの成果物をコミットメントで ⽬標に結びつけることに加え、業界の最⼤の課題である「リードし ないサーバントリーダー」と「⾃⼰組織化した開発者が好き勝⼿ やってコミットメントを守らない」という2つの課題に取り組みまし た。” “⾃⼰組織化(Self-organization)とは、複雑系理論(Complex Systems Theory)の概念で知的システムがゴールを達成するために⾃⼰組織化 する、といったものです。そこで私たちは、チームが「⾃⼰組織 化」という⾔葉を盾に、あらゆるコミットメントを回避することを 避けるために「⾃⼰管理」という⾔葉を使うようになりました。 チームは、ゴールを達成するためのコミットメントを実現するため に⾃⼰管理するのです。” (参考) Ben Linders InfoQ ”Changes in the 2020 Scrum Guide: Q&A with Ken Schwaber and Jeff Sutherland” 2020-12 https://www.infoq.com/articles/changes-2020-Scrum-guide/ (参照 2023-1-10)
20. 20 「エセ⾃⼰組織化」症候群 俺たち ⾃⼰組織化 してる Goals (⽬的) おーい 「やりたいことだけやりたがるエンジニア」 「⾃⼰組織化を盾に約束を守らないチーム」 「待てど暮らせど成果がでないチーム」 どうやら、世界中のあちこちで起きていた症状
21. 21 「エセ⾃⼰組織化」症候群 俺たち ⾃⼰組織化 してる Goals (⽬的) おーい 真の⽬的を忘れ、⾃分たちは「⾃律している」 と思い込み次々と決断してしまう状態を 「エセ⾃⼰組織化」症候群と名付けた。 「やりたいことだけやりたがるエンジニア」 「⾃⼰組織化を盾に約束を守らないチーム」 「待てど暮らせど成果がでないチーム」 どうやら、世界中のあちこちで起きていた症状
22. 22 本来の「⾃⼰組織化(Self-organization)」とは？ “⼀⾒、複雑で無秩序な系において、⾃律的に形成される秩序だったパターン。いずれも外部からの意図的な制御なし に、基本的な物理法則に則って時間的・空間的秩序が形成され、また、維持される。ベナール対流、結晶成⻑、ベロ ウソフジャボチンスキー反応、⼼筋の律動、ニューラルネットワークの構築をはじめ、物理学、化学、⽣物学、情報 科学など、幅広い分野で⾒いだされ、いわゆる複雑系に現れる特徴の⼀つに挙げられる。⾃発的秩序形成。” 出典：デジタル⼤辞泉（⼩学館） “無秩序に向かう⾃然界の流れ(熱⼒学第2法則)に逆らい、系がエネルギーを取り込みながら⾃分を組織だて、秩序を⽣ むこと。結晶の⽣成や化学反応のリズムなどさまざまな場⾯でみられ、体表の模様づくりなど⽣物界でも⽬⽴つ。系 を形づくる要素同⼠の働き合いが鍵を握る。カオスなどと並んで複雑系科学の主役。ナノテクノロジーに利⽤して量 ⼦点(量⼦ドット)をつくる試みなどもある。” 出典：知恵蔵（朝⽇新聞出版）
23. 23 本来の「⾃⼰組織化(Self-organization)」とは？ Alexey Kljatov, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0> Mikkabie, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0> TANAKA Juuyoh (⽥中⼗洋), CC BY 2.0 <https://creativecommons.org/licenses/by/2.0> 雪の結晶 みそ汁の中の模様 イワシの群れの動き
24. 24 本来の「⾃⼰組織化(Self-organization)」とは？ “「⾃⼰組織化」とは「ランダムになろうとする⼒に、 秩序化しようとする⼒が打ち勝つこと」である。” （参考）都甲 潔. 林 健司. 江崎 秀. ⾃⼰組織化とは何か―⽣物の形やリズムが⽣まれる原理を探る. 講談社, 1999, 241p. ランダム 秩序 ⾮線形性 エントロピー⼤ 平衡系（静的） ⾮平衡系（動的） 雪の結晶、⽣体膜、リポソーム、 ⼈⼯味細胞膜、(将来の) 分⼦素⼦、 マイクロマシン リズム、パターン、カオス 協同現象 (相転移)
25. 25 何をすればよいか？ “We want teams that, instead of optimizing locally, optimize for the whole organization. They understand theyʼre part of the larger fabric of the organization. They understand that they need to get their own work done and play nicely with others to make sure that the organization is successful.” “私たちは、局所的に最適化するのではなく、組織全体のた めに最適化するチームを求めています。彼らは、⾃分たちが 組織という⼤きな構造物の⼀部であることを理解していま す。組織の成功のためには、⾃分の仕事をきちんとこなし、 他の⼈とうまく付き合う必要があることを理解しているので す。” （参考）マイケル K サホタ(Michael K Sahota). ” Autonomous, Self-Organizing Teams Donʼt Work”. SHIFT314 Change Reality. 2021-03, https://shift314.com/autonomous-self-organizing-teams-dont-work/, (参照 2023-1-10) “Instead of self-organizing (or self-managing) teams, what we actually want are responsible teams. Responsible teams make good decisions and function in a healthy way within the larger organizational ecosystem. The question is, “How do we get responsible teams?” Well, it turns out responsible teams come from responsible people. Really, the whole journey to self- managing is about helping people become more responsible for their behavior and their choices, or in our version of “Teal”: acting like an adult.” マイケル K サホタ(Michael K Sahota).
26. チーム全体のマネジメント向上 処⽅箋 26
27. 27 何をすればよいか？ 俺たち ⾃⼰組織化 してる Goals (⽬的) おーい （参考）マイケル K サホタ(Michael K Sahota). ” Autonomous, Self-Organizing Teams Donʼt Work”. SHIFT314 Change Reality. 2021-03, https://shift314.com/autonomous-self-organizing-teams-dont-work/, (参照 2023-1-10) “アジャイルとは、実は反復的かつ漸進的である ことを意味します。⼤規模で有害な変更を⾏うの ではなく、反復的かつ漸進的に⾃⼰組織化に向け て動き始めてはどうだろうか。” マイケル K サホタ(Michael K Sahota) 「やりたいことだけやりたがるエンジニア」 「⾃⼰組織化を盾に約束を守らないチーム」 「待てど暮らせど成果がでないチーム」 どうやら、世界中のあちこちで起きていた症状
28. 28 何をすればよいか？ コミットメント 責任感のあるチーム作り （参考）マイケル K サホタ(Michael K Sahota). ” Autonomous, Self-Organizing Teams Donʼt Work”. SHIFT314 Change Reality. 2021-03, https://shift314.com/autonomous-self-organizing-teams-dont-work/, (参照 2023-1-10) “⾃律的な⾃⼰組織化チーム ”という⾔葉を捨て、 “相互に関連した責任感のあるチーム ”を⽬指す。 Goals (⽬的) “アジャイルとは、実は反復的かつ漸進的である ことを意味します。⼤規模で有害な変更を⾏うの ではなく、反復的かつ漸進的に⾃⼰組織化に向け て動き始めてはどうだろうか。” マイケル K サホタ(Michael K Sahota)
29. 29 反復的かつ漸進的にチェンジマネジメント 進化 TEAL GREEN ORANGE AMBER RED 進化型 • 個々が意思決定 • 全体性を重視 • ⽬的が進化する 進化型 • 平等と多様性を重視 • ボトムアップの意思決定 • ⽂化重視の組織 達成型 • 権威や伝統への批判 • 効率的で複雑な階層 • 多国籍企業 順応型 • 集団の規範がすべて • ⼤規模な階層組織 • 協会や軍隊 衝動型 • ⾃我(エゴ)の確率 • 恐怖による統治 • マフィアやギャング Frederic Lalouxの組織モデル 権⼒の共有 • ⾮集中ネットワーク • ⾃⼰管理(self-management) • 後発性・全体性 ⼈々 • ⽬的 • バリュー • エンパワーメント 達成 • イノベーション • 説明責任 • 能⼒主義 権⼒と組織構造 • 権威 • 公式の役職 • ヒエラルキー • 安定したプロセス サホタ⽂化モデル こ の レ ベ ル の 組 織 が ア ジ + イ ル に 取 り 組 む と ﹁ ⽂ 化 的 負 債 ﹂ が ⼭ 積 み に な り や す い まずは、私たちの「組織⽂化」がどのあたりか を認識することから始める。 「ティール組織」で有名なラルー組織モデルに 照らし合わせれば、レッドやアンバー、オレン ジの組織に対してアジャイル⽂化を根付かせる のは難しそうなのがわかる。 私たちは過去に組織⽂化を無視してスクラムを 導⼊しようとしても組織課題、⾔い換えれば 「⽂化的負債」が⼭積みとなる経験をした。 （参考）マイケル K サホタ(Michael K Sahota). ”Are You Using The Right Culture Model?”. SHIFT314 Change Reality. 2019-2, https://shift314.com/are-you-using-the-right-culture-model/, (参照 2023-1-10)
30. 30 反復的かつ漸進的にチェンジマネジメント 認識（安全性と信頼） エンゲージメントとアウトカム （参考）マイケル K サホタ(Michael K Sahota). ”Are You Using The Right Culture Model?”. SHIFT314 Change Reality. 2019-2, https://shift314.com/are-you-using-the-right-culture-model/, (参照 2023-1-10)
31. 31 反復的かつ漸進的にチェンジマネジメント 認識（安全性と信頼） エンゲージメントとアウトカム （参考）マイケル K サホタ(Michael K Sahota). ”Are You Using The Right Culture Model?”. SHIFT314 Change Reality. 2019-2, https://shift314.com/are-you-using-the-right-culture-model/, (参照 2023-1-10)
32. 32 何をすればよいか？ “We want teams that, instead of optimizing locally, optimize for the whole organization. They understand theyʼre part of the larger fabric of the organization. They understand that they need to get their own work done and play nicely with others to make sure that the organization is successful.” “私たちは、局所的に最適化するのではなく、組織全体のた めに最適化するチームを求めています。彼らは、⾃分たちが 組織という⼤きな構造物の⼀部であることを理解していま す。組織の成功のためには、⾃分の仕事をきちんとこなし、 他の⼈とうまく付き合う必要があることを理解しているので す。” （参考）マイケル K サホタ(Michael K Sahota). ” Autonomous, Self-Organizing Teams Donʼt Work”. SHIFT314 Change Reality. 2021-03, https://shift314.com/autonomous-self-organizing-teams-dont-work/, (参照 2023-1-10) “Instead of self-organizing (or self-managing) teams, what we actually want are responsible teams. Responsible teams make good decisions and function in a healthy way within the larger organizational ecosystem. The question is, “How do we get responsible teams?” Well, it turns out responsible teams come from responsible people. Really, the whole journey to self- managing is about helping people become more responsible for their behavior and their choices, or in our version of “Teal”: acting like an adult.” “⾃⼰組織化（または⾃⼰管理）するチームではなく、私た ちが実際に望んでいるのは、責任感のあるチームです。 責 任感のあるチームは、より⼤きな組織のエコシステムの中 で、適切な意思決定を⾏い、健全に機能することができるの です。問題は、「どうしたら責任あるチームができるのか」 ということです。それは、責任あるチームは責任ある⼈から ⽣まれるということです。つまり、⾃⼰管理への道のりは、 ⼈々が⾃分の⾏動や選択にもっと責任を持てるようにするこ と、つまり、私たちなりの「ティール」、⼤⼈のように振る 舞うことを⽀援することなのです。” マイケル K サホタ(Michael K Sahota).
33. 33 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 ⾃⼰管理(self-management) 反復的かつ漸進的に エセ⾃⼰組織化
34. 34 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 チームの最適化 ⾃⼰管理(self-management) 反復的かつ漸進的に
35. 35 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 チームの最適化 問題そのものより、チームに取り組む ü 問題や機会に直⾯したら、最初のステップは、 適切なチームを適所に置いて問題に取り組むことだ。 （参考）エリック・シュミット. ジョナサン・ローゼンバーグ. アラン・イーグル. 櫻井 祐⼦ (翻訳). 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え. ダイヤモンド者, 2019/11/14, p.165 ⾃⼰管理(self-management) 反復的かつ漸進的に
36. 36 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 チームの最適化 問題そのものより、チームに取り組む ü 問題や機会に直⾯したら、最初のステップは、 適切なチームを適所に置いて問題に取り組むことだ。 （参考）エリック・シュミット. ジョナサン・ローゼンバーグ. アラン・イーグル. 櫻井 祐⼦ (翻訳). 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え. ダイヤモンド者, 2019/11/14, p.165 ビル・キャンベルが⼈に求めた4つの資質 ⾃⼰管理(self-management) 【知性】【勤勉】【誠実】【グリット】 コーチャブルな資質 反復的かつ漸進的に
37. 37 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 チームの最適化 問題そのものより、チームに取り組む ü 問題や機会に直⾯したら、最初のステップは、 適切なチームを適所に置いて問題に取り組むことだ。 （参考）エリック・シュミット. ジョナサン・ローゼンバーグ. アラン・イーグル. 櫻井 祐⼦ (翻訳). 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え. ダイヤモンド者, 2019/11/14, p.165 ビル・キャンベルが⼈に求めた4つの資質 ⾃⼰管理(self-management) 【知性】【勤勉】【誠実】【グリット】 反対に最も嫌った相⼿ 【学ぶことをやめた⼈たち】 コーチャブルな資質 反復的かつ漸進的に
38. 38 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 ⾃⼰管理(self-management) “スクラムにおける⾃⼰組織の最⼩ 限の表現で、スプリント内の作業 の進め⽅を決めるのはスクラム チームだけであるとするもの。” “外部からの作業計画や指⽰を 受けることなく、⼈々が問題 や課題のために組織的なグ ループを形成するプロセス。” （参考）ギュンター・ヴァーヘイエン(Gunther Verheyen). ” Scrum Glossary”. Ullizee-Inc. https://guntherverheyen.com/scrum-glossary/, (参照 2023-1-10) チームの最適化 “スクラムチームは機能横断型 で、各スプリントで価値を⽣ み出すために必要なすべての スキルを備えている。” (スクラムガイド2020) 反復的かつ漸進的に
39. 39 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 ⾃⼰管理(self-management) “スクラムにおける⾃⼰組織の最⼩ 限の表現で、スプリント内の作業 の進め⽅を決めるのはスクラム チームだけであるとするもの。” “外部からの作業計画や指⽰を 受けることなく、⼈々が問題 や課題のために組織的なグ ループを形成するプロセス。” （参考）ギュンター・ヴァーヘイエン(Gunther Verheyen). ” Scrum Glossary”. Ullizee-Inc. https://guntherverheyen.com/scrum-glossary/, (参照 2023-1-10) チームの最適化 “スクラムチームは機能横断型 で、各スプリントで価値を⽣ み出すために必要なすべての スキルを備えている。” (スクラムガイド2020) チームは⾃分たちの仕事（仕事の内容、実⾏時期、達成⽅ 法)について「進め⽅を決める」スキルを⾝に着けているこ とが前提条件。 反復的かつ漸進的に
40. 40 反復的かつ漸進的にチェンジマネジメント ⾃⼰組織化 ⾃⼰管理(self-management) “スクラムにおける⾃⼰組織の最⼩ 限の表現で、スプリント内の作業 の進め⽅を決めるのはスクラム チームだけであるとするもの。” “外部からの作業計画や指⽰を 受けることなく、⼈々が問題 や課題のために組織的なグ ループを形成するプロセス。” （参考）ギュンター・ヴァーヘイエン(Gunther Verheyen). ” Scrum Glossary”. Ullizee-Inc. https://guntherverheyen.com/scrum-glossary/, (参照 2023-1-10) チームの最適化 “スクラムチームは機能横断型 で、各スプリントで価値を⽣ み出すために必要なすべての スキルを備えている。” (スクラムガイド2020) チームは⾃分たちの仕事（仕事の内容、実⾏時期、達成⽅ 法)について「進め⽅を決める」スキルを⾝に着けているこ とが前提条件。 つまり「マネジメント」⼒が⼤切 反復的かつ漸進的に
41. 41 「マネジメント」⼒の⼤切さ Google re:Work より: “Google はこれまで、マネジメント業務の⼤切さを必 ずしも正当に評価してきたわけではありません。2002 年、すべてのマネージャーを廃⽌して管理職のいない 組織にするという「実験」を⾏いました。しかし、こ の実験は失敗に終わりました。2008 年には、調査チー ムが、マネージャーは重要な存在ではないという⼀部 の意⾒を証明しようと試みますが、すぐにまったくの 正反対であることがわかりました。 つまり、マネージャーはきわめて重要な存在だったの です。” （参考）Google. ”マネージャー”. Google re:Work. https://rework.withgoogle.com/jp/subjects/managers, (参照 2023-1-10)
42. 42 「マネジメント」⼒の⼤切さ Google re:Work より: “Google はこれまで、マネジメント業務の⼤切さを必 ずしも正当に評価してきたわけではありません。2002 年、すべてのマネージャーを廃⽌して管理職のいない 組織にするという「実験」を⾏いました。しかし、こ の実験は失敗に終わりました。2008 年には、調査チー ムが、マネージャーは重要な存在ではないという⼀部 の意⾒を証明しようと試みますが、すぐにまったくの 正反対であることがわかりました。 つまり、マネージャーはきわめて重要な存在だったの です。” （参考）Google. ”マネージャー”. Google re:Work. https://rework.withgoogle.com/jp/subjects/managers, (参照 2023-1-10) この話にはエピソードがある
43. 43 「マネジメント」⼒の⼤切さ “「ここにはマネジャーを置かないとダメだ」 ラリーは答えにつまった。ちょうどマネジャーを全廃したばかりで、彼は 結構満⾜していたのだった。(後略) ⼆⼈はどちらも譲らず、しばらく堂々めぐりの議論を続けた。とうとうビ ルはラリーの流儀にならって、それならエンジニアに直接聞いてみればいい と⾔った。(中略)ビルはその⼀⼈に、マネジャーがほしいかと訪ねた。 ええ、という返事だった。 なぜだ？ 「何かを学ばせてくれる⼈や、議論に決着をつけてくれる⼈が必要だから」 その⽇彼らは数⼈のソフトウェアエンジニアと話したが、答えはほとんど同 じだった。” （参考）エリック・シュミット. ジョナサン・ローゼンバーグ. アラン・イーグル. 櫻井 祐⼦ (翻訳). 1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え. ダイヤモンド者, 2019/11/14, p.63
44. 44 「マネジメント」⼒の⼤切さ プロダクト開発チーム マネジメント プロダクト開発チームは、あらゆる側⾯の「マネジメント」に包まれて成⻑する 注）マネジメントとは、マネジャーがメンバーに対して⾏う指⽰・命令のことではない
45. 45 「マネジメント」⼒の⼤切さ 相互に関連した 責任感のあるチーム マネジメント スケ ジュール ⼈ (メン バー) 予算 プロセス フロー プロダク トリリー ス 法令遵守 品質 製造 リソース (⼈以外) 権限移譲 複雑な問題に 対応できる ケイパビリティ 能⼒開発 注）マネジメントとは、マネジャーがメンバーに対して⾏う指⽰・命令のことではない コンフリ クト リスク ⾃⼰組織化 チームの最適化 ⾃⼰管理(self-management) 反復的かつ漸進的に ⽂化
46. 46 「マネジメント」⼒の⼤切さ ⾃⼰組織化 チームの最適化 ⾃⼰管理(self-management) 反復的かつ漸進的に ⽂化 戦略 戦術 ⬅⽬に⾒える ⬅⽬に⾒えない “The only thing of real importance that leaders do is to create and manage culture. If you do not manage culture, it manages you, and you may not even be aware of the extent to which this is happening.” “リーダーにとって本当に重要なことは、⽂化を創造 し、管理することです。もし、あなたが⽂化を管理し なければ、⽂化があなたを管理することになります。” エドガー・H・シャイン（Edgar H. Schein） （参考）Edgar H. Schein. Organizational Culture and Leadership, 1985, p.20
47. 47 Sahota Culture Model （参考）マイケル K サホタ(Michael K Sahota). ”Are You Using The Right Culture Model?”. SHIFT314 Change Reality. 2019-2, https://shift314.com/are-you-using-the-right-culture-model/, (参照 2023-1-10) Sahota Culture Model は、⽂化を形成する 「関連した要素」が何かを認識できる。 真ん中より下の「構造」だけに焦点をあてる ことは罠である。 重要なのは上の「認識（またはマインドセッ ト）」に焦点を当てチェンジマネジメントす ることである。
48. 48 Sahota Culture Model 組織の パーパス 認識（マインドセットや⼈々の⾏動） 組織⽂化 アイディンティティ バリュー 信念 ⾏動 組織構造 システム フィードバック ロール プロセス 意思決定 給料 暗黙のルールと 規範 安全？ 信頼？ 価値？ ⼈々？ 構造 ポリシー Sahota Culture Model は、⽂化を形成する 「関連した要素」が何かを認識できる。 真ん中より下の「構造」だけに焦点をあてる ことは罠である。 重要なのは上の「認識（またはマインドセッ ト）」に焦点を当てチェンジマネジメントす ることである。 （参考）マイケル K サホタ(Michael K Sahota). ”Are You Using The Right Culture Model?”. SHIFT314 Change Reality. 2019-2, https://shift314.com/are-you-using-the-right-culture-model/, (参照 2023-1-10)
49. 49 Sahota Culture Model 組織⽂化を成⻑させるステップ 1. 成⻑への意欲 • 「変化を起こしたい」という強い衝動 • コッターの変⾰の8段階のプロセスは成⻑を阻害 2. 既存の⽂化を理解する • ⽂化≒「私たちの⾏動指針」 3. ⽔平線に星をつくる（ゴールを設定する） • ⾃分たちがどんな会社になりたいかケーススタディや事例をみる • ただし構造はコピーしないこと • ⾃分だけの道を探す 4. ⽂化をローカルで育てる • ⽂化はチーム、部⾨、場所によって異なる • 組織間の衝突を減らすことがコツ 5. リーダーは最初に⾏く • ⽂化の変⾰は委任できない • リーダーが新しい働き⽅で⾏動することが必要 6. リーダーシップの育成が必要 • リーダーが組織の成⻑限界である • リーダーを育てないと組織も育たない （参考）マイケル K サホタ(Michael K Sahota). ” How To Change Your Organizational Culture”. SHIFT314 Change Reality. 2018-7, https://shift314.com/change-organizational-culture/, (参照 2023-1-10) 組織の パーパス 認識（マインドセットや⼈々の⾏動） 組織⽂化 アイディンティティ バリュー 信念 ⾏動 組織構造 システム フィードバック ロール プロセス 意思決定 給料 暗黙のルールと 規範 安全？ 信頼？ 価値？ ⼈々？ 構造 ポリシー
50. 50 Sahota Culture Model 組織⽂化を成⻑させるステップ 1. 成⻑への意欲 • 「変化を起こしたい」という強い衝動 • コッターの変⾰の8段階のプロセスは成⻑を阻害 2. 既存の⽂化を理解する • ⽂化≒「私たちの⾏動指針」 3. ⽔平線に星をつくる（ゴールを設定する） • ⾃分たちがどんな会社になりたいかケーススタディや事例をみる • ただし構造はコピーしないこと • ⾃分だけの道を探す 4. ⽂化をローカルで育てる • ⽂化はチーム、部⾨、場所によって異なる • 組織間の衝突を減らすことがコツ 5. リーダーは最初に⾏く • ⽂化の変⾰は委任できない • リーダーが新しい働き⽅で⾏動することが必要 6. リーダーシップの育成が必要 • リーダーが組織の成⻑限界である • リーダーを育てないと組織も育たない （参考）マイケル K サホタ(Michael K Sahota). ” How To Change Your Organizational Culture”. SHIFT314 Change Reality. 2018-7, https://shift314.com/change-organizational-culture/, (参照 2023-1-10) 組織の パーパス 認識（マインドセットや⼈々の⾏動） 組織⽂化 アイディンティティ バリュー 信念 ⾏動 組織構造 システム フィードバック ロール プロセス 意思決定 給料 暗黙のルールと 規範 安全？ 信頼？ 価値？ ⼈々？ 構造 ポリシー
51. 51 リーダーシップの育成が必要 “発注先の能⼒は、発注元の能⼒を超えられない” 清⽔吉男 “A key lesson in my career is that the Leader is the Limit for Growth. I notice that to create high performance organizational systems, leaders needed to develop themselves as human beings. They needed to grow into the kind of leaders we see in high performance environments. ” “私のキャリアにおいて重要な教訓は、「リーダーは成⻑ の限界である」ということです。⾼い成果を⽣み出す組 織システムを構築するためには、リーダー⾃⾝が⼈間と して成⻑する必要があることに気づかされました。⾼い パフォーマンスを発揮できるようなリーダーへと成⻑す る必要があったのです。” マイケル K サホタ(Michael K Sahota). （参考）マイケル K サホタ(Michael K Sahota). ”How To Change Your Organizational Culture”. SHIFT314 Change Reality. 2018-7, https://shift314.com/change-organizational-culture/, (参照 2023-1-10) マイケル K サホタ(Michael K Sahota). ”Leader is the Limit for Growth”. SHIFT314 Change Reality. 2016-7, https://shift314.com/leader-is-the-limit/, (参照 2023-1-10) リーダーを育てないと組織も育たない
52. エビデンスベースの計器⾶⾏ 処⽅箋 52
53. 53 プロダクト開発チームのゴール Goals プロダクト開発チームのゴールってなに？
54. 54 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 PO SM 開発者
55. 55 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 プロダクト・サービス提供 開発者 PO SM
56. 56 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 プロダクト・サービス提供 開発者 PO SM
57. 57 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 プロダクト・サービス提供 信頼・対価(売上) 開発者 PO SM
58. 58 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 プロダクト・サービス提供 信頼・対価(売上) 開発者 PO SM
59. 59 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 プロダクト・サービス提供 信頼・対価(売上) 開発者 PO SM
60. 60 プロダクト開発チームのゴール プロダクト開発チーム Goals 顧客 プロダクト・サービス提供 信頼・対価(売上) プロダクトの⼒でお客 さまにベネフィットを 届ける 開発者 PO SM
61. 61 ゴールに向けた⾃⼰管理(self-management) （参考） https://bizhint.jp/keyword/108652 •明確なゴールとその達成に必要な「具体的な⾏動」への落とし込みが必要 •具体的な⾏動をMORSの法則に基づいて点検してみる •Measurable ＝計測できる （数値化など前後を⽐較して効果を計測できる） •Observable ＝観察できる （⾏動による変化を客観的に⾒られる） •Reliable ＝信頼できる （確かなものとして信じられる） •Specific ＝明確化された （はっきりしていて間違いや疑問の余地がない） プロダクト開発チーム 顧客 プロダクト・サービス提供 信頼・対価(売上) ⾃⼰管理(self-management) Goals
62. 62 ゴールに向けた⾃⼰管理(self-management) （参考） https://bizhint.jp/keyword/108652 •明確なゴールとその達成に必要な「具体的な⾏動」への落とし込みが必要 •具体的な⾏動をMORSの法則に基づいて点検してみる •Measurable ＝計測できる （数値化など前後を⽐較して効果を計測できる） •Observable ＝観察できる （⾏動による変化を客観的に⾒られる） •Reliable ＝信頼できる （確かなものとして信じられる） •Specific ＝明確化された （はっきりしていて間違いや疑問の余地がない） プロダクト開発チーム 顧客 プロダクト・サービス提供 信頼・対価(売上) ⾃⼰管理(self-management) Goals
63. 63 計測の重要性：Opinion vs Fact（意⾒か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意⾒） 設計 デプロイ 仮説を実装 する 仮説を動か す 結果を 検証する 仮説 対策の仮説 を⽴てる 計測 (参考) 吉⽻⿓太郎 ”Effective DevOps” p.32 2018-04 https://slide.meguro.ryuzee.com/slides/94 (参照 2023-1-10) 仮説を⽴てるには、 計測データを検証す る必要がある。
64. 64 Accelerate •原書は「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 •2018年3⽉出版、⽇本語版は2018年11⽉に出版。 （2023年2024年1⽉、第2版が出そう?） •迅速かつ⾼品質なデリバリを実施している組織とそうでない組織の違いに関する 研究結果をまとめている。 IUUQTCPPLJNQSFTTDPKQCPPLT IUUQTXXXPSFJMMZDPNMJCSBSZWJFXBDDFMFSBUF
65. 65 Accelerate •2018年よりGoogle Cloudと共同で実施しており、毎年調査レポート（State of DevOps）を公表している。 （参考）Google Cloud. ”2022 年の Accelerate State of DevOps Report を発表: セキュリティに焦点”. Google Cloud blog. 2022-10, https://cloud.google.com/blog/ja/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out, (参照 2023-1-10)
66. 66 Accelerate •2018年よりGoogle Cloudと共同で実施しており、毎年調査レポート（State of DevOps）を公表している。 （参考）Google Cloud. ”2022 年の Accelerate State of DevOps Report を発表: セキュリティに焦点”. Google Cloud blog. 2022-10, https://cloud.google.com/blog/ja/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out, (参照 2023-1-10) https://engineering.visional.inc/blog/463/four-keys-consideration-part1/ https://engineering.visional.inc/blog/469/four-keys-consideration-part2/ 弊社チームで State of DevOps 2022(昨年10⽉公開) に関する調査と議論を⾏った内容をブログ公開して います。良かったらお⽬通しください。
67. 67 Accelerate •Four Keys とは DORA社(現Google)が直近6年間の研究から導いた 開発チームのパフォーマンス指標 •アジャイルでもウォーターフォールでも計測可能 リードタイム コードがコミットされてか ら本番環境で正常に実⾏さ れるまでの時間 デプロイ頻度 コードを本番環境にデプロ イまたはエンドユーザーに リリースした頻度 平均サービス 回復時間(MTRS) サービスインシデント または不具合が発⽣したと きにサービスの復元にどれ くらいの時間がかかるか 変更失敗率 本番環境に変更を加えた、 またはユーザーへのリリー スを実施した結果サービス が低下し、その後修正を⾏ う必要が⽣じた割合
68. 68 Accelerate “⽣産性”に代わる開発チームのパフォーマンス計測を ソフトウェア開発の“⽣産性”指標の難しさ 「書いたコードの量」が ⽣産性とは限らない 「ベロシティ(速度)」は ⽣産性とは限らない 「リソース効率(利⽤率)」が ⽣産性とは限らない 品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率
69. 69 Accelerate リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率 Four Keys ケイパビリティ 統計的相関 （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)
70. 70 Accelerate （参考） https://bizhint.jp/keyword/108652 プロダクト開発チーム 顧客 プロダクト・サービス提供 信頼・対価(売上) ⾃⼰管理(self-management) Goals
71. 71 Accelerate （参考） https://bizhint.jp/keyword/108652 プロダクト開発チーム ⾃⼰管理(self-management)
72. 72 Accelerate 相関関係
73. 顧客 プロダクト・サービス提供 信頼・対価(売上) 73 Accelerate プロダクト開発チーム ⾃⼰管理(self-management) プロダクト開発チームの“現在の姿” としてパフォーマンスが⾒えてくる
74. 顧客 プロダクト・サービス提供 信頼・対価(売上) 74 Accelerate プロダクト開発チーム プロダクトのアウトカムや品質の定量的計測を中⼼とした 「市場価値」（＝アウトカム）も計測したい ⾃⼰管理(self-management)
75. 75 エビデンスベースドマネジメント（EBM） •エビデンスベースドマネジメントは、Scrum.org、Professional Scrum Trainer の コミュニティ、Ken Schwaber、Christina Schwaberによって共同開発された。 •価値を俊敏に、計測・管理・改善するためのフレームワーク (参考)Scrum.org ”Evidence-Based Management Guide” https://www.scrum.org/resources/evidence-based-management-guide (参照 2023-1-10)
76. 76 エビデンスベースドマネジメント（EBM） 市場に出すまでの時間（反応性） (T2M: Time to Market) 新しい能⼒、サービス、製品を迅速 に提供する能⼒ イノベーションの能⼒（効果性） (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能⼒を提供 する能⼒ 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値
77. 77 EBMの重要価値指標（KVM）の例 KVM Measuring 従業員1⼈あたりの収益 この⽐率（総収益 / 従業員数）は業界内の主要な競争 指標である。業界によって⼤きく異なる。 プロダクトコスト⽐率 計測対象のプロダクトやシステムにかかる総費⽤およ びコスト。運⽤コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役⽴つ感情分析の⼀種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役⽴つ感情分析の⼀種。 顧客使⽤指標 機能別の利⽤状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使⽤時間が、期待と⼀致しているかを 確認する。 現在の価値（CV） 未実現の価値（UV） KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客（ユーザー）満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド（統合されてテストされたもの）の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり（継続的、⽇次、週次、⽉次、四半期ごとなど）のリ リース回数。これは、新規的で競争⼒のあるプロダクトにおいて、顧 客を満⾜させるために必要な時間を評価するのに役⽴つ。 リリースの安定期間 開発者がリリースの準備ができたと⾔ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役⽴つ。 平均修復時間 エラーが発⾒されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着⼿してから実際にリリースするまでの時間。組織が 顧客にリーチするための能⼒を計測するのに役⽴つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は⼤きく異なる。顧客満⾜度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実⾏されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ （またはリリース）する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可⽤性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利⽤を学習するまでにかかる時間。 障害物除去時間 障害物が発⽣してから解決さるまでの平均時間。リードタイムや従業 員満⾜度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間（T2M） KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労⼒やコストを、すべてのプロダ クトに費やした労⼒やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。⼀ 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労⼒を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発⽣す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を⽣み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役⽴つ。 プロダクト（コー ド）のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン（または種類）の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適⽤するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の⼈を助けるために中 断された時間がある。問題の規模を把握するのに役⽴ つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を⾏う必 要が⽣じた割合（例: ホットフィックス、ロールバック、パッチ）。 Four Keysのひとつ。 イノベーションの能⼒（A2I） (参考) Scrum.org ⻑沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)
78. 78 9 ways to fail with KPIs 9 WAYS TO FAIL WITH KPIS Supporting Agile Adoption (Bjarte Bogsnes, Claudia Melo, Esther Derby, Kati Vilkki, Michael Sahota) ! Organizations often use Key Performance Indicators (KPI’s) and metrics in dysfunctional ways, which result into gaming, reduced performance, undesired behaviors and focusing on unimportant things. The most common traps we have seen organization and managers falling into are listed below: TRAP COUNTER MEASURE / WHAT TO DO INSTEAD! 1) Losing sight of purpose: The real purpose of the KPI is forgotten. Improving the KPI becomes the purpose and the perspective becomes too mechanical and narrow. Purpose: Always connect and communicate the purpose together with the KPI, because it encourages people not only to understand, but also question the goals behind the KPI. Actions: Identify what actions that are being taken to reach the goal / meet the purpose. 2) KPI becomes a target: KPI’s and metrics are seen as only thing that matters. Challenge KPI: Systematically challenge the measurement, both the KPI and the value. When targets are associated with KPI, the more absolute the targets are, the more you need to challenge the measurement. For example: ! What is measurement not picking up? ! Is this KPI really taking us forward the goal/purpose? 3) Measuring the wrong thing: organizations measure only what is easy for them to measure. If something can’t be measured (e.g. productivity in SW development), other metrics are used to replace it (e.g. lines of code) Do not measure things that do not matter: Einstein said: “Not everything that can be counted counts; not everything that counts can be counted.” Measuring the wrong thing can be more harmful than not measuring anything, especially if there is a target attached to the KPI. If you can’t measure what you really want to measure, drop the KPI. Focus on the purpose, actions, and observations ! What does success look like? ! How do we know if we have succeeded? 4) Lagging Indicators: organizations use only/ mostly lagging indicators; we are only measuring the past, not present and we can’t take corrective action based on them. Leading Indicators: Use leading indicators that are early indicators of what will move us towards our goal. (e.g. measure queue length for goal of reducing cycle time). Ask “what actions can we take based on this KPI? Who will act?”? 5) Targets for all KPI’s: When there is always a target connected to a KPI it is likely we have returned to management by numbers and are allowing KPI’s to divert us from actual goals. Tracking Trends: Use KPIs as data to improve the system, and look at trends rather than just one point or an absolute number. “If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached. If you have not a stable system, then there is again no point in setting a goal. There is no way to know what the system will produce: it has no capability.” - W. Edwards Deming 6) Same KPI for all levels. Cascading targets and KPI’s Translate KPI: Translate the targets and KPI’s so people define their own KPI’s for improvement. ! What do we need to focus on to contribute the bigger goal? ! How do we know we have succeeded / contributed?” 7) Same KPIs for all phases of product life cycle. Using the same KPIs to manage products in early market and mainstream Life-cycle sensitive KPI’s: Understand what KPIs are most relevant at each phase of product life-cycle. 8) Aggregating metrics to bigger organizational unit. E.g. calculating averages over teams. Look at Details: Ask “who needs to take action to fix this” and measure at that level; do not aggregate upwards. Use KPI’s as indicators to GO & SEE and look deeper. 9) Relying on KPIs to drive people’s motivation. E.g. Establishing KPIs with aggressive targets hoping to create a challenge for people. KPIs to support intrinsic motivation. Engaged people are driven by intrinsic motivation: doing something purposeful, having autonomy and striving for mastery. KPIs can provide direction and feedback, but not motivation . However, allow people to define success criteria for themselves. ! Further reading: Daniel H. Pink (2009). Drive: The Surprising Truth About What Motivates Us. Riverhead Hardcover. Pat Kua (2013): An Appropriate Use of Metrics. Robert D. Austin (1996). Measuring and Managing Performance in Organizations. Dorset House Publishing. 1. ⽬的を⾒失う：KPIの真の⽬的が忘れ去られている。KPIを改善することが⽬ 的になり、視点が機械的で狭くなりすぎてしまう。 2. KPIが⽬標になる：KPIや指標だけが重要と考えてしまう。 3. 間違ったものを測定する：組織は、⾃分たちにとって測定しやすいものだけを 測定する。測定できないもの（例：ソフトウェア開発の⽣産性）は、他の測定 基準で代⽤する（例：コード⾏数など）。 4. 遅⾏指標：組織は遅⾏指標のみ／ほとんどを使⽤している。現在ではなく過去 を測定しているだけであり、それに基づいて是正措置を取ることはできない。 5. すべてのKPIに⽬標を設定する：KPIに常に⽬標が設定されている場合、私た ちは数字による管理に戻り、KPIが実際の⽬標から⽬をそらすことを許してい る可能性があります。 6. すべてのレベルで同じKPI：カスケードした⽬標とKPIを使っている 7. 製品ライフサイクルの全フェーズで同じKPIを使⽤する：初期市場と主⼒製品 で同じKPIを使⽤して製品を管理すること。 8. より⼤きな組織単位に指標を集計する：（例：チームごとの平均を計算する） 9. KPIに依存することで、⼈々のモチベーションを⾼める：例）積極的な⽬標値 を設定し、チャレンジ精神旺盛な⼈材を育成する。 こういった罠にハマらないよう注意したい。 （参考）Bjarte Bogsnes, Claudia Melo, Esther Derby, Kati Vilkki, Michael Sahota. “9 WAYS TO FAIL WITH KPIS - Agile Alliance”. Agile Alliance, https://www.agilealliance.org/wp-content/uploads/2018/07/How-to-use-KPI_June2014_pretty.pdf, (参照 2023-1-10)
79. イヌワシのような視座をもつ 処⽅箋 79
80. 80 イヌワシのような視座をもつ Juan Lacruz, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0> イヌワシ： 視⼒は⼈間の8倍。1km以上先の獲物を⾒分けるこ とができる。数千mもの⾼度で⾶翔しながら、草 原を⾛るノウサギを⾒分け、正確に捕えることが できる。 （参考）公益財団法⼈⽇本⾃然保護協会. ”遠くまで⾒通せる視⼒”. イヌワシタイムズ. 2019-2, https://www.nacsj.or.jp/inuwashi-times/遠くまで⾒通せる視⼒, (参照 2023-1-10)
81. 81 イヌワシのような視座をもつ （参考）Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Professional, 2000/1/1, p.56 • ものごとのゴールにはレベルがある • ゴールレベルを上げるには「なぜ？」と問いかけることで⾒つかる • 反対にゴールレベルを下げるには「どのように？」と問いかける （写真）Richard Bartz, Munich aka Makro Freak, CC BY-SA 2.5 <https://creativecommons.org/licenses/by-sa/2.5>, via Wikimedia Commons
82. 82 イヌワシのような視座をもつ （参考）Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Professional, 2000/1/1, p.56 • ものごとのゴールにはレベルがある • ゴールレベルを上げるには「なぜ？」と問いかけることで⾒つかる • 反対にゴールレベルを下げるには「どのように？」と問いかける （写真）Richard Bartz, Munich aka Makro Freak, CC BY-SA 2.5 <https://creativecommons.org/licenses/by-sa/2.5>, via Wikimedia Commons
83. 83 イヌワシのような視座をもつ 解像度が⾼い 解像度が低い Photo by Hiroyuki TAKAHASHI Photo by Hiroyuki TAKAHASHI 視座が⾼くても、解像度が低くては意味がない
84. 84 イヌワシのような視座をもつ 深さ 広さ 構造 時間 解像度の4つの視点 解像度を上げるための3つの基本姿勢 情報 思考 ⾏動 粘り強さ 型 （参考）⾺⽥ 隆明. 解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と⾏動法. 英治出版, 2022/11/19, 352p 解像度が⾼い 解像度が低い Photo by Hiroyuki TAKAHASHI Photo by Hiroyuki TAKAHASHI
85. 85 イヌワシのような視座をもつ （参考）Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Professional, 2000/1/1, p.56 （写真）Richard Bartz, Munich aka Makro Freak, CC BY-SA 2.5 <https://creativecommons.org/licenses/by-sa/2.5>, via Wikimedia Commons 深さ 広さ 構造 時間 ﹁ 解 像 度 が 低 い 場 合 ︑ 基 本 的 に は 深 さ が ⾜ り な い ﹂ （参考）⾺⽥ 隆明. 解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と⾏動法. 英治出版, 2022/11/19, 352p
86. 86 イヌワシのような視座をもつ 深さ 広さ 構造 時間 （参考）⾺⽥ 隆明. 解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と⾏動法. 英治出版, 2022/11/19, 352p 型1 ⾔語化して現状を把握する 型2 サーベイをする 型3 インタビューをする 型4 現場に没⼊する 型5 個に迫る 型6 Why so?を繰り返して、 事実から洞察を導く 型7 習慣的に⾔語化する 型8 ⾔葉や概念、知識を増やす 型9 コミュニティで深掘りを加速する 型10 プレスリリースを書いてみる 型11 ⾏動可能な単位までHowを問う 型12 専⾨性を磨いて、新たな解決策 に気づく 型13 ⼿で考える 型14 体で考える 型15 前提を疑う 型16 視座を変える 型17 体験する 型18 ⼈と話す 型19 あらためて深める場所を決める 型20 使える道具を増やす 型21 外部資源を獲得する前提で広げる 型22 探索に資源を割り当てる 型23 解決策の真の意味を考える 型24 分ける 型25 ⽐べる 型26 関係づける 型27 省く 型28 質問をする 型29 構造のパターンを知る 型30 解決する範囲を決める 型31 構造のパターンに当てはめる 型32 新しい組み合わせを⽣み出す 型33 要素間の相性を考える 型34 捨てることで独⾃性を出す 型35 制約を意識する 型36 他システムとの連携を考える 型37 意図していなかったシステムの ふるまいに対処する 型38 ストーリーを描く 型39 雑な構造から描きはじめる 型40 変化を⾒る 型41 プロセスやステップを⾒る 型42 流れを⾒る 型43 歴史を振り返る 型44 最適なステップを⾒出す 型45 シミュレーションする 型46 好循環を作り出す 型47 ⻑期の視点で考えて、時間を 味⽅につける 型48 アジリティと学ぶ⼒を⾼める 型
87. 87 Playbook •視座を上げたり、解像度を⾼めるために、型の実践例や型そのものを集め今より もっと経験を積み豊かな知識を得ることをバックアップする •そこで、組織メンバーが誰でも閲覧できる「Playbook」を作成する アメリカンフットボールでは事前に相⼿チームの作戦を想定し、それにあった作戦ができるよう にプレイブックを作成していきます。それらは⼀⼈ひとりの動きが細かく記されており、相⼿の 出⽅次第ではオーディブルやオプションを使うなどといったことも決められています。 (参考) 本村 恭平 ”フラッグフットボールのブレーブックはなぜ作っておくべきなのか” 2017-6 https://qboekendorp.hatenablog.com/entry/flagfootball-premake (参照2023-1-10)
88. 88 マネジメントガイドライン •価値の創造からデリバリーまでをマネジメントする •PMBOK 第7版では「デリバリーを守るためのマネジメント」から「価値を届けるためのマネジ メント」に変様した。このようにプロジェクトマネジメントはアジャイル化しており、アジャイ ルなプロジェクトマネジメントをプロダクトフェーズに合わせとりこめるようガイドラインを作 る。 •PRINCE2 を参考にし、事業計画⽴案フェーズや作ったプロダクトのベネフィットを向上させ事 業の価値を創造するフェーズをマネジメントするための事業マネジメントガイドラインを作る。 プロダクト開発チーム 顧客 プロダクト・サービス提供 信頼・対価(売上) プロジェクトマネジメント
89. 89 SECIモデル •組織が持つ暗黙知を表層化させSECIモデル実装する。 •Playbookを中⼼に暗黙知だけでなく社内外で取り組まれているグッドプラクティ スをガイドライン化し蓄積・引⽤できるようにする
90. ビズリーチのSODA構想とは 90
91. 91 ビズリーチのSODA構想とは プロダクト開発チーム マネジメント プロダクト開発チームは、あらゆる側⾯の「マネジメント」に包まれて成⻑する 注）マネジメントとは、マネジャーがメンバーに対して⾏う指⽰・命令のことではない
92. 92 ビズリーチのSODA構想とは プロダクト開発チーム プロダクトマネジメント プロダクト品質マネジメント プロセス改善マネジメント プロダクト組織マネジメント （事業経営） プロジェクト マネジメント
93. 93 ビズリーチのSODA構想とは •“相互に関連した責任感のあるチーム ”を組織に「実装」するうえで必要なマネジ メント関連のナレッジ・スキル体系・フレームワークなどを集め組織への実装イ メージを「設計」しメタ的なアーキテクチャを作成した。 •これを Software Outcome Delivery Architecture (SODA) と名付けました。
94. 94 ビズリーチのSODA構想とは ⾃組織を視座⾼く点検するためのアーキテクチャ。 ⾜りない機能を実装したり、学習計画を⽴てることができる。
95. Software Outcome Delivery Architecture(SODA): prototype
96. Software Outcome Delivery Architecture(SODA): prototype
104. 104 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成⻑する組織を⽬指す。 プロダクトに関するナレッジベースを作成しSECIモデルを作る プロダクト開発チームのファクトデータを⾒える化する すべてのプロダクトにFour keysの計測を定着させ、改善サイクルを作る プロダクトごとに重要な品質指標を⾒極めフィードバックプロセスを増やし、 プロダクト品質を向上させる プロダクトごとにアウトカム指標を⾒極め、計測する
106. Software Outcome Delivery Architecture(SODA): prototype
107. 今後の展望 107
108. 今後の展望 売上、利益などの お⾦を中⼼とした指標 プロダクトがお客様のやりたいこ とに付加価値を付けているか？ （顧客アウトカム） 相関関係 時間 予算 品質 スコープ プロダクト マネジメント状況の ⾒える化 SODAで状況把握や課題発⾒を助け、事業の成⻑とプロダクト開発の相関関係を⾒いだす
109. 109 今後の展望 材料 状況把握 課題発⾒ 守・安定しているか 攻・もっとよくできないか • 期初の計画との差分がない • KPIが想定範囲内で推移している • 問題に気づく • 課題を⾒つける • 改善の⼿がかりを⾒つける ベース情報 • 事業の状況を把握できる • プロダクト組織の状態 現在の価値 （CV: Current Value） 未実現の価値 （UV: Unrealized Value） • 現在、顧客やユーザーに提供された価値 SODAで状況把握や課題発⾒を助け、事業の成⻑とプロダクト開発の相関関係を⾒いだす イノベーションの能⼒ (A2I: Ability to Innovate) 市場に出すまでの時間 (T2M: Time-to-Market) • 顧客やユーザーの潜在的なニーズをすべて満 たすことによって実現しうる価値 • 顧客やユーザーのニーズにより良く応えられ るような新しい能⼒を提供する能⼒ • 新しい能⼒、サービス、製品を迅速に提供す る能⼒ • CVが低い＝投資価値あり • CVが⾼い＆市場独占＝投資価値なし＝放っ ておいても儲かる • A2Iが低い＝顧客の要望に応えるのが遅い • T2Mが低い＝実験スピードが遅いのでライバ ルに出し抜かれる • UVとCVにまだまだギャップがある＝現在の 体験と顧客の期待とに差がある 例
110. 今後の展望 組織・個⼈ 事業指標（プロダクト健康状態を除く） プロダクト状況 • 4keys ◦ リードタイム ◦ デプロイ頻度 ◦ 平均サービス回復時間(MTRS) ◦ 変更失敗率 • 障害情報 ◦ システムの運⽤状況 ◦ インシデントとその対応履歴 • 固定費 ◦ サーバー費⽤などの固定費 • ロードマップ ◦ ロードマップ ◦ マイルストーン ◦ スケジュール進捗と進捗理由 • プロジェクト ◦ 参加メンバー ◦ ⼈件費 ◦ 経費 ◦ 成果 • プロダクトごとの重要指標 ◦ 問い合わせ数、新規契約数、継続契約数、解約率 ◦ 売上、利⽤社数 ◦ 求職者登録数、レジュメ充⾜率、ハンドシェイク ◦ アプリログイン数 • 市場占有率 • 顧客満⾜度 • ブランド認知 外部の事業影響因⼦ • 有効求⼈倍率 など • 基本属性 ◦ 年齢 ◦ 男⼥⽐ ◦ ⼊社経緯 ◦ DiSC • 能⼒ ◦ 能⼒スコア(グレード) ◦ 社内アワード個⼈賞の割合 ◦ 外部発表の数 ◦ 採⽤枠の進捗 • 組織 ◦ 組織図 ◦ プロジェクト参加メンバー ◦ ⼈件費 • マネジメント ◦ マネジメント⽐率 ◦ マネジメント⼈数(ひとりのマネージャーが管 理している⼈数) • コンディション ◦ コンディションサーベイ ◦ V-BASE，e-NPS ◦ 退職率、休職率、勤怠の乱れ ◦ 副業状況 適切な⼈員配置ができているか 売上や利⽤社数などの重要指標は想定内か プロダクト開発は適正に進んでいるか 主に 組織開発部⾨ が収集 主に 各事業の営業/マーケ企画部⾨ が収集 主に プロセス改善部 が収集 事業指標に関係する要素はどうか これらを⼀覧・関連づけて表⽰できるBIツールを順次提供
111. 111 今後の展望 •エビデンスベースドマネジメント（EBM） 市場に出すまでの時間（反応性） (T2M: Time to Market) 新しい能⼒、サービス、製品を迅速 に提供する能⼒ イノベーションの能⼒（効果性） (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能⼒を提供 する能⼒ 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値
112. Software Outcome Delivery Architecture(SODA): prototype
113. Software Outcome Delivery Architecture(SODA): BizReach ver.
114. テーラリング Software Outcome Delivery Architecture(SODA): BizReach ver. 深さ 広さ 構造 時間 型
115. Software Outcome Delivery Architecture(SODA): BizReach ver.
124. Software Outcome Delivery Architecture(SODA): BizReach ver.
125. Software Outcome Delivery Architecture(SODA): BizReach ver. 市場に出すまでの時間（反応性） (T2M: Time-to-Market) 新しい能⼒、サービス、製品を迅速 に提供する能⼒ イノベーションの能⼒（効果性） (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能⼒を提供 する能⼒ 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値
126. 注）数値はダミーです
127. 127 SODAを⽤いた「計器⾶⾏」を実現する
128. 128 Visional バリュー มΘΓଓ͚ΔͨΊʹɺֶͼଓ͚Δ ͓٬༷ͷຊ࣭త՝୊ղܾ ͦͷߦಈͰɺϒϨΠΫεϧʔ ࣄۀͮ͘Γ͸ɺ஥ؒͮ͘Γ Ձ஋͋Δ͜ͱΛɺਖ਼͘͠΍Ζ͏ Ұ౓͖Γͷਓੜɺ͔ͤͬ͘Կ͔ʹऔΓ૊ΉͳΒɺ ୭ʹͰ΋ڳΛுͬͯ఻͑ΒΕΔ࢓ࣄΛ͠Α͏ɻ ͓٬༷ɺגओɺࣾ಺֎ͷ஥ؒɺՈ଒ɺͦͯࣗ͠෼ɻ ؔΘΔ͢΂ͯͷਓ͕޾ͤʹͳΔࣄۀΛ૑Δɻ ͜ͷࢥ͍Λৗʹ๨Εͣɺ ͜Ε͔Β΋ಓͷਅΜதΛಊʑͱಥ͖ਐ΋͏ɻ มԽ͠ଓ͚Δ࣌୅ͰɺԿ͔Λม͍͑ͨͱࢥ͏ͷͳΒɺ ࣗ෼ࣗ਎͕Ұ൪มΘ͍ͬͯ͜͏ɻ ֶͼ͸มΘΔ͜ͱΛޙԡͯ͘͠͠ΕΔɻ มΘΓଓ͚Δ͜ͱ͸೉͘͠ɺ࣌ʹ͍͚ۤ͠ΕͲɺ ͋ͳͨͷࢹ໺ͱՄೳੑΛ޿͛ɺ ݁Ռͱͯ͠ਓੜͷ޾ͤ΁ͱͭͳ͕͍ͬͯ͘ɻ Ϣʔβʔͱ͍͏ݴ༿΋ؚΊɺ ҰਓҰਓ͕༗ػతͳ৺Λ࣋ͭʮ͓٬༷ʯͰ͋Δͱఆٛ͠ɺ ͓٬༷ͷମݧΛৗʹ૝૾͠ͳ͕Βɺ ຊ࣭తͳ՝୊ΛҾ͖ग़͠ɺൈຊతʹղܾ͠Α͏ɻ ͦΕ͕ͦ͜ظ଴Ҏ্ͷ੒Ռ΍඼࣭ɺ ͻ͍ͯ͸ࢲ͕ͨͪड͚औΔରՁͱͳΔͷ͔ͩΒɻ ୭͔ͷओମੑʹཔΔ͜ͱͳ͘ɺ ࣗΒ͕ࣄۀ΍αʔϏεͷΦʔφʔγοϓΛ࣋ͬͯ ߟ͑ɺൃݴ͠ɺߦಈ͍ͯ͜͠͏ɻ ͦ͏͢Ε͹ ɺ୹ظతͳ੒ՌͷͨΊʹ ௕ظతͳՁ஋Λ٘ਜ਼ʹ͢Δ͜ͱ΋ͳ͍ɻ ͍·ࣗ෼ʹͰ͖Δ͜ͱΛߟ͑ɺ࠷ॳͷҰาΛ౿Έग़͠ɺ ҰਓҰਓ͕ϒϨΠΫεϧʔ͍ͯ͜͠͏ɻ ࣄۀͮ͘Γʹ͓͍ͯɺ ҰਓͷྗͰ੒͠਱͛ΒΕΔ͜ͱʹ͸ݶք͕͋Δɻ ͔ͩΒͦ͜ɺࢤΛԕྀͳ͘ൃ৴͠ɺ஥ؒΛݟ͚ͭɺ ͲΜͲΜר͖ࠐΜͰ͍͘͜ͱʹΑͬͯɺ ૝૾΋Ͱ͖ͳ͍΄Ͳͷେ͖ͳਪਐྗΛੜΈग़ͦ͏ɻ ͦͯ͠ɺ࠷ߴͷ஥ؒͱྺ࢙Λ૑Ζ͏ɻ 01 02 03 04 05
129. 129 SODAで強いチームづくりを！ プロダクトの⼒で、お客さまにベネフィットを！
130. 130 BlogとTwitterで発信中！ Blog https://engineering.visional.inc/blog/ Visionalグループで働くエンジニアの技術的な取り組みや、イベント・登壇情報などをお届けします。 Twitter @VISIONAL_ENG
131. 131 本⽇の資料を Speaker Deck で公開しています！ https://speakerdeck.com/visional_engineering_and_design 7JTJPOBM
     &OHJOFFSJOH
     ＆ %FTJHO