Slide 1

Slide 1 text

Scrum Fest Sendai 2026 ・ 2026.07.11 人を動かすのは、 時間ではなく納得感。 〜 新任EMが入社3ヶ月で、組織を2回変えた話 〜 篠塚 翔平 ShinoP / しのぴー 株式会社カケハシ | Engineering Manager X @marupopu

Slide 2

Slide 2 text

観察 2〜3ヶ月って、 本当に必要? © KAKEHASHI Inc. All Rights Reserved. 2

Slide 3

Slide 3 text

導入 ── 「観察期間」という常識 こんな経験、ありませんか? 理想に向かって組織を動かそうとしたとき—— 想いはあるのに、なぜか響かない。 丁寧に説明しているのに、行動につながらない。 © KAKEHASHI Inc. All Rights Reserved. 3

Slide 4

Slide 4 text

導入 ── こんな経験、ありませんか? 想いはあるのに、届かない こうしたい 提案したのに、 なぜか響かない 想いはあるのに、納得してもらうまでに時間がかかる。 こうすべき 説明しても 「なぜ?」と返される Howを丁寧に説明しても「なぜそれを?」 と問い返される。 © KAKEHASHI Inc. All Rights Reserved. 4

Slide 5

Slide 5 text

導入 ── 現状を把握せずに働きかける時の罠 共通するのは、現状把握の欠落 Will 先行 現状を把握せずに提案し 「なぜ?」 が伝わらない やりたいことが先に立ち、背景の共有が置き去りに。 How 先行 方法論が先行し、現状に適さないやり方 を提案 「スクラム的にはこう」と、手法が現状より先に来る。 © KAKEHASHI Inc. All Rights Reserved. 5

Slide 6

Slide 6 text

導入 ── 「観察期間」という常識 「観察が大事」と、繰り返し語られる “ 最初の2〜3ヶ月は 観察に徹せよ ” “ 最初の90日は 観察期間 ” ── マネジメント関連の書籍やコミュニティで、繰り返し語られる ── © KAKEHASHI Inc. All Rights Reserved. 6

Slide 7

Slide 7 text

現実は…… 常に観察に時間をかけられる状況 とは限らない © KAKEHASHI Inc. All Rights Reserved. 7

Slide 8

Slide 8 text

導入 ── 私が直面した状況 「観察に徹する」が、許されなかった 01 前任EMが退職 即キャッチアップ 02 経営からは結果を 求められる 03 メンバーは困っている 04 観察の余裕はない © KAKEHASHI Inc. All Rights Reserved. 8

Slide 9

Slide 9 text

観察 2〜3ヶ月って、 本当に必要? 「観察」は大事。だが、それは “時間軸” で語るべきものなのか? © KAKEHASHI Inc. All Rights Reserved. 9

Slide 10

Slide 10 text

自己紹介 PROFILE 篠塚 翔平 ShinoP / しのぴー @marupopu 略歴 Web制作会社 Engineer / Scrum Master SI企業 Engineer / Scrum Master タイミー Scrum Master / Agile Coach / EM カケハシ EM(2026.2〜) 活動 Scrum Fest Sendai 登壇(2023〜2026) 東北IT物産展 in 岩手 登壇(2025) 盛岡スクラム 運営 © KAKEHASHI Inc. All Rights Reserved. 10

Slide 11

Slide 11 text

本日話すこと 入社3ヶ月で、組織を2回変えた話 01 アンチパターンが、なぜ前進できたのか 「観察期間」の常識に反する行動が、ハレーションなく着地した理由。 02 そこから抽出した、3つのピース 再現性のある観点として持ち帰れるかたちに。 03 信頼と納得感は別物、そして繋がっている 今日の核となる気づき。 © KAKEHASHI Inc. All Rights Reserved. 11

Slide 12

Slide 12 text

AGENDA 目次 01 導入 02 ベース信頼はどう作ったか 03 入社3ヶ月、再度の組織変更 04 揃えた3つのピース 05 「信頼」と「納得感」は別のもの 06 まとめ 07 最後に 12 © KAKEHASHI Inc. All Rights Reserved.

Slide 13

Slide 13 text

ベース信頼 ── 言葉の定義 「ベース信頼」とは LV.0 信頼ゼロ 何者かわからない LV.1 ベース信頼 少なくとも味方だ LV.2 深い信頼 この人に任せよう 信頼ゼロの状態から、まず「仲間だ」と思ってもらうまでの話 © KAKEHASHI Inc. All Rights Reserved. 13

Slide 14

Slide 14 text

Chapter 2 ・ ベース信頼 ベース信頼を構築する、 ための前提 © KAKEHASHI Inc. All Rights Reserved. 14

Slide 15

Slide 15 text

信頼されたければ まず自分から信頼する © KAKEHASHI Inc. All Rights Reserved. 15

Slide 16

Slide 16 text

ベース信頼 ── 私が直面した状況 何が、起きたか © KAKEHASHI Inc. All Rights Reserved. 17 2月 入社 3月 1回目の組織変更 & インシデント祭 4–5月 2回目の組織変動 主要メンバー(キーマン)が新規プロダクトへ異動

Slide 17

Slide 17 text

ベース信頼を、どう作ったか ① 入社3週間で大鉈を振った話 ▶ ② インシデント統率者の話 © KAKEHASHI Inc. All Rights Reserved. 16

Slide 18

Slide 18 text

ベース信頼 ── 私が直面した状況 じっくり観察に徹している 場合では、なかった 前任EMの退職・引き継ぎ。 チーム・組織・プロダクトをキャッチアップ中に、チーム数変更とインシデント祭が、次々と押し寄せた。 © KAKEHASHI Inc. All Rights Reserved. 18

Slide 19

Slide 19 text

入社3週間で大鉈を振った話 Before ── 入社直後は 3チーム エンジニア約 20名のプロダクトチーム / 3チーム(約 7名) チーム A 7 名 チーム B 7 名 チーム C 6 名 新任EM「しのぴー」として、このプロダクトチームにJoinした © KAKEHASHI Inc. All Rights Reserved. 19

Slide 20

Slide 20 text

入社3週間で大鉈を振った話 1on1で見えた、チームの課題 しのぴー 今感じている課題って、何があるかな? チームリーダー 合意形成に時間がかかってるんですよね……人数が多くて、意見がまとまらなくて。 エンジニア もっと少人数でやれると、スピードが出ると思うんです。 コミュニケーションパスが複雑化していることは、明白だった。 © KAKEHASHI Inc. All Rights Reserved. 20

Slide 21

Slide 21 text

入社3週間で大鉈を振った話 入社前の、CTOとの会話 しのぴー AI時代において、チームのサイズ感ってどう考えますか? CTO 今の5〜6人というサイズ感より、小さくなると考えているよ。 しのぴー わかる! 同じ気持ちです。 © KAKEHASHI Inc. All Rights Reserved. 21

Slide 22

Slide 22 text

入社3週間で大鉈を振った話 2つの見立てが、重なった チームの声 「合意形成に時間がかかる」コミュニケーションパスが複雑で、やりづらさを感じている。 しのぴー & CTO の見立て AI時代、チームはコンパクト化すべき。少人数 × AI活用の方向性で合意。 → 4チーム目を組成する 少人数 × AI活用へ © KAKEHASHI Inc. All Rights Reserved. 22

Slide 23

Slide 23 text

これは、アンチパターン ではないのか? © KAKEHASHI Inc. All Rights Reserved. 23

Slide 24

Slide 24 text

入社3週間で大鉈を振った話 でも、揃っていたものがあった 課題の共通認識 チームの「困っている」と、自分の見立てが一致していた。 経営との合意 CTOと「少人数 × AI活用」の方向性で同意していた。 前進の 条件が揃った 困りごとの解決策と方向性が重 なった 困っていることの解決策と、今後の方向性が重なっていた。 © KAKEHASHI Inc. All Rights Reserved. 24 →

Slide 25

Slide 25 text

入社3週間で大鉈を振った話 泥臭く、対話した しのぴー いきなり組織をいじるのはアンチパターンなんだけど…… みんなのやりづらさを解消したくて、AI活用前提に4チーム目を作りたい。どうかな? メンバー いいね、やってみよう! AI時代にコンパクトになるのは頷ける。 PdM AI推進、やっていきたいです! © KAKEHASHI Inc. All Rights Reserved. 25

Slide 26

Slide 26 text

入社3週間で大鉈を振った話 After ── 4チーム × 少人数へ 4チーム(約 5名)へ再編 + 補填施策 チーム A 5 名 チーム B 5 名 チーム C 5 名 チーム D 5 名 想定デメリット ドメイン知識の分散/チーム間の分断 顧客への価値提供が滞る恐れ。 補填する施策 チーム間を繋ぐ横断ロールを配置 AI活用を推進するグループを新設。 © KAKEHASHI Inc. All Rights Reserved. 26

Slide 27

Slide 27 text

入社3週間で大鉈を振った話 ── 結果 理想の形へ、確かな一歩 大きなハレーションは、なかった コミュニケーションしやすくなった チームからのフィードバック。 少人数 × AI 体制へ前進 顧客に価値を早く届ける その理想に向かって。 © KAKEHASHI Inc. All Rights Reserved. 27

Slide 28

Slide 28 text

入社3週間で大鉈を振った話 ── 学び 日が浅くても、動ける条件 LEARNING Whyの解像度 目指す組織の形を、自分の言葉で語れる状態にしておく。 LEARNING 課題の共通認識 チームと自分の「困っている」を、一致させる。 © KAKEHASHI Inc. All Rights Reserved. 28

Slide 29

Slide 29 text

ベース信頼を、どう作ったか ① 入社3週間で大鉈を振った話 ✓ ② インシデント統率者の話 ▶ © KAKEHASHI Inc. All Rights Reserved. 29

Slide 30

Slide 30 text

© KAKEHASHI Inc. All Rights Reserved. 29 引用:https://speakerdeck.com/kakehashi/more-incident-reports?slide=17

Slide 31

Slide 31 text

インシデント統率者の話 3月、多数のインシデントが発生し祭状態に... 「インシデント統率者はEMの役割」と引き継いだが、やったことはない 重大なもの、過去バグの顕在化…… インシデントレベルも、バラバラ © KAKEHASHI Inc. All Rights Reserved. 30

Slide 32

Slide 32 text

エンジニア 「しのぴーさん! インシデントです!」 ── ナンダッテ- © KAKEHASHI Inc. All Rights Reserved. 31

Slide 33

Slide 33 text

やっていくしかない。 とにかく 打席に立つ © KAKEHASHI Inc. All Rights Reserved. 32

Slide 34

Slide 34 text

インシデント統率者の話 前任EMが担っていた統率者を、 キャッチアップ未完了ながら 自ら、打席に立つことを選んだ。 上司に頼る選択肢もあったが、自分で動くことを選んだ。 © KAKEHASHI Inc. All Rights Reserved. 33

Slide 35

Slide 35 text

インシデント統率者の話 初回は、統率者の動きごとみんなに頼った しのぴー システムもステークホルダーも、まだ何もわからないので……助けてください! エンジニア 原因はここ、影響範囲はこの範囲です。 PdM 関係者はここ、まず○○さんに連絡を。 CS 顧客への一次連絡は、こちらで対応します。 © KAKEHASHI Inc. All Rights Reserved. 34

Slide 36

Slide 36 text

インシデント統率者の話 1件やって、型が見えた 01 原因調査 エンジニアに最優先で依頼 → 02 影響範囲特定 範囲を切り分け → 03 暫定対応 顧客連絡はCS / サポート → 04 恒久対応 障害報はスペシャリストと 土台にあったのは、前職の経験・障害対応の型・メンバーへの信頼 © KAKEHASHI Inc. All Rights Reserved. 35

Slide 37

Slide 37 text

インシデント統率者の話 終盤は、仲間との連携が阿吽の呼吸に しのぴー まずは影響範囲と原因究明のチームに分かれて動いてください。 どんなお問い合わせが来てますか? サポートデスク 現在〇件のお問い合わせで、限定的です! PdM / CS 顧客向け障害報の準備をします! © KAKEHASHI Inc. All Rights Reserved. 36 エンジニア #〇〇のプルリクが怪しいので調べます!

Slide 38

Slide 38 text

インシデント統率者の話 ── 結果 メンバーに、助けられた 顧客が困る状況を、迅速に脱した 情報連携も意思決定も、速く 終盤は、迅速に解消できるように。 何よりも、メンバーに助けられた 仲間との連携で乗り越えた。 © KAKEHASHI Inc. All Rights Reserved. 37

Slide 39

Slide 39 text

インシデント統率者の話 打席に立てた、理由 01 経験値 前職での、ハードな経験 修羅場をくぐった経験が、判断の土台になった。 02 仲間への信頼 必ず助けてくれる、という確信 プロダクトに真摯な人ばかり。 顧客が困れば動くと確信した。 © KAKEHASHI Inc. All Rights Reserved. 38

Slide 40

Slide 40 text

インシデント統率者の話 ── 学び 経験は、引き出しになる LEARNING 解決策の引き出し 過去の経験ストックから、打ち手を即座に取り出す。 © KAKEHASHI Inc. All Rights Reserved. 39

Slide 41

Slide 41 text

ベース信頼を、どう作ったか 課題を解決する姿勢と打席に立つ姿が伝わり 「しのぴーは仲間だ」が生まれた 信頼ゼロではなくなった。ここから、動き始める。 © KAKEHASHI Inc. All Rights Reserved. 40

Slide 42

Slide 42 text

AGENDA 目次 01 導入 02 ベース信頼はどう作ったか 03 入社3ヶ月、再度の組織変更 04 揃えた3つのピース 05 「信頼」と「納得感」は別のもの 06 まとめ 07 最後に 12 © KAKEHASHI Inc. All Rights Reserved.

Slide 43

Slide 43 text

2回目の組織変更 わずか3ヶ月で、再びの変動 © KAKEHASHI Inc. All Rights Reserved. 42 2月 入社 3月 1回目の組織変更 & インシデント祭 4–5月 2回目の組織変動 主要メンバー(キーマン)が新規プロダクトへ異動

Slide 44

Slide 44 text

会社 「新しい事業を立ち上げます! 各プロダクトから アベンジャーズ を集めます!」 ── ナンダッテ- © KAKEHASHI Inc. All Rights Reserved. 43

Slide 45

Slide 45 text

2回目の組織変更 Before ── 機能開発 + SRE(24名) 機能開発チーム(約 20名) ・ EM チーム A 5 名 チーム B 5 名 チーム C 5 名 チーム D 5 名 SREチーム ・ EM SRE 4 名 © KAKEHASHI Inc. All Rights Reserved. 44

Slide 46

Slide 46 text

2回目の組織変更 キーマンが抜け、危機的状況 01 主要メンバー 3名 の離脱 エース級と、ドメイン知識を持つ メンバーが戦略的な配置転換。 02 残ったチームの戦力低下 ドメイン知識の喪失 モチベへの影響、1名の退職。 03 ビジネス要求は止まらない 開発のペースを落とすわけには いかない。 © KAKEHASHI Inc. All Rights Reserved. 45

Slide 47

Slide 47 text

2回目の組織変更 ── 取った行動 ① Whyの解像度を、どう上げたか 納得するまで、聞いた CTOやPLに今後の事業戦略や「なぜ今、新規プロダクト が必要なのか」を納得するまで聞いた。 → 自分の言葉へ、昇華 自分の言葉とWill を上乗せして昇華させた。 © KAKEHASHI Inc. All Rights Reserved. 46

Slide 48

Slide 48 text

2回目の組織変更 ── 取った行動 ② その結果、語れる構造になった MISSION 日本の医療体験を しなやかにする → STRATEGY マルチプロダクト戦略 新規にリソース集中 → DECISION 新規プロダクトへの リソース配置転換 → MY ROLE 自分の言葉で 語れる まで高める 経営判断を「上からの命令」ではなく、「自分の言葉で納得できるもの」に変えた。 © KAKEHASHI Inc. All Rights Reserved. 47

Slide 49

Slide 49 text

2回目の組織変更 ── 取った行動 ② メリデメと選択肢を提示し、対話した しのぴー 〇〇な背景で変化が起きようとしていて、今のチームに△△の影響がある。 対応のために××な戦略を取ろうと思うけど、どうかな……? エンジニア それはやっていくしかないですね! 一緒に考えましょう! チームリーダー なるほど……例えば◻◻のようにするのは? △△の影響をもう少し詳しく知りたいです! © KAKEHASHI Inc. All Rights Reserved. 48

Slide 50

Slide 50 text

2回目の組織変更 ── 取った行動 ③ 計画を透明化する 2〜3日ごとに更新 組織計画を都度アップデートし続けた。 グダグダや葛藤も見せた 未完成の状態も、そのまま共有した。 メンバーに1on1でFBをもらう 対話しながら、計画を磨いていった。 完璧な計画ではなく、「一緒に作っている」感覚を共有した。 © KAKEHASHI Inc. All Rights Reserved. 49

Slide 51

Slide 51 text

2回目の組織変更 After ── Musubi開発チームへ統合 機能開発( 20名)+ SRE(4名)を統合 → 2コンセプト × 5チーム チーム A 4 名 チーム B 4 名 チーム C 4 名 チーム D 4 名 SRE 4 名 横断施策 Team Lead 登用 | MTG体系の見直し(ALL系 + コンセプト別)| Tech Lead 配置 © KAKEHASHI Inc. All Rights Reserved. 50

Slide 52

Slide 52 text

2回目の組織変更 ── 具体例 Before ── いま 会議体が、散在していた 同期MTGが週内に分散 まとまった開発時間が取りにくい After ── これから 水・木に、同期を集約 同期は水・木にまとめる 月・火・金はまとまった開発時間に © KAKEHASHI Inc. All Rights Reserved. 51

Slide 53

Slide 53 text

2回目の組織変更 ── 結果 前を向いて、次のフェーズへ 大きなハレーションは、なかった デモチには、繋がらなかった メンバーが前を向いて進んだ。 納得感と信頼関係を築けていた 新体制で、動き始めた。 © KAKEHASHI Inc. All Rights Reserved. 52

Slide 54

Slide 54 text

2回目の組織変更 ── 学び 経営判断を、自分の言葉で © KAKEHASHI Inc. All Rights Reserved. 53 LEARNING Whyの解像度 今後の組織の目指していく形を、自分の言葉で語る

Slide 55

Slide 55 text

AGENDA 目次 01 導入 02 ベース信頼はどう作ったか 03 入社3ヶ月、再度の組織変更 04 揃えた3つのピース 05 「信頼」と「納得感」は別のもの 06 まとめ 07 最後に 12 © KAKEHASHI Inc. All Rights Reserved.

Slide 56

Slide 56 text

信頼されたければ まず自分から信頼する © KAKEHASHI Inc. All Rights Reserved. 55

Slide 57

Slide 57 text

揃えた3つのピース 揃えるべき、3つのピース Piece 1 Whyの解像度 ミッションから紐解いて 経営判断を自分の言葉で。 Piece 2 解決策の引き出し 経験ストックから 打ち手を即座に。 Piece 3 課題の共通認識 チームと自分の「困っている」を 一致させる。 © KAKEHASHI Inc. All Rights Reserved. 56

Slide 58

Slide 58 text

Piece 1 ── Whyの解像度 Piece 1 01 Whyの 解像度 DEFINITION ── 定義 ミッションから紐解いて、経営判断を 自分の言葉で語れる状態。 Whyを語れない人は、Howでしか説得できない。 チーム数変更では今後の形を、2回目はミッション→戦略→判断を自分の言葉で語った。 © KAKEHASHI Inc. All Rights Reserved. 57

Slide 59

Slide 59 text

Piece 1 ── Whyの解像度 今回、Whyをこう語った 2回目の組織変更で、ミッション→戦略→判断を自分の言葉で語った CTO・PLに「なぜ今この判断なのか」を納得するまで聞いた 聞いた内容に、自分のWillを上乗せして昇華させた Howの前に、経営レベルのWhyを提示した © KAKEHASHI Inc. All Rights Reserved. 58

Slide 60

Slide 60 text

Piece 2 ── 解決策の引き出し Piece 2 02 解決策の 引き出し DEFINITION ── 定義 過去の経験ストックから、複数の打ち手を 即座に出せる状態。 完璧な解は要らない。選択肢が複数出せれば十分。 インシデント統率も組織変更も、前職の経験から即座に打ち手を提示できた。 © KAKEHASHI Inc. All Rights Reserved. 59

Slide 61

Slide 61 text

Piece 2 ── 解決策の引き出し 今回、引き出しをこう使った インシデント統率で、前職の障害対応の型を即座に当てはめた 完璧な解ではなく、複数の選択肢を出して選んだ 前職・他現場で培った経験を、Whyを前提に持ち込んだ © KAKEHASHI Inc. All Rights Reserved. 60

Slide 62

Slide 62 text

Piece 3 ── 課題の共通認識 Piece 3 03 課題の 共通認識 DEFINITION ── 定義 チームと自分の「困っている」が 一致している状態。 自分だけが課題を見つけても、動けない。 1回目の組織変更は、チームの課題としのぴーの見立てが重なっていた。 © KAKEHASHI Inc. All Rights Reserved. 61

Slide 63

Slide 63 text

Piece 3 ── 課題の共通認識 今回、課題をこう揃えた 1on1で「合意形成に時間がかかる」という困りごとを徹底的に聞いた 「自分も同じ課題を感じている」と伝えた チームの困りごとと、自分の見立てを重ねた © KAKEHASHI Inc. All Rights Reserved. 62

Slide 64

Slide 64 text

AGENDA 目次 01 導入 02 ベース信頼はどう作ったか 03 入社3ヶ月、再度の組織変更 04 揃えた3つのピース 05 「信頼」と「納得感」は別のもの 06 まとめ 07 最後に 12 © KAKEHASHI Inc. All Rights Reserved.

Slide 65

Slide 65 text

信頼と納得感 「観察期間」の、正体 観察期間とは、 「ピースが揃うまでの時間」だった 時間軸は、目安にすぎない ピースが揃えば、時間軸は超えられる ピースが揃わなければ、何ヶ月かけても動けない © KAKEHASHI Inc. All Rights Reserved. 64

Slide 66

Slide 66 text

信頼と納得感 「信頼」と「納得感」は、別のもの 信頼 納得感 評価対象 人全体 判断ごと 成立 蓄積 瞬間 時間 かかる かからない 信頼が浅くても、納得感は生み出せる。 © KAKEHASHI Inc. All Rights Reserved. 65

Slide 67

Slide 67 text

信頼と納得感 だから、入社歴が浅くても動けた 信頼を時間をかけて 貯められる状況では なかった → でも、3つのピースは 揃えられた → 納得感が 生まれた → 人は、 動いた © KAKEHASHI Inc. All Rights Reserved. 66

Slide 68

Slide 68 text

信頼と納得感 納得感は、信頼への「入り口」 納得感は、信頼の「代替品」ではない。信頼への「入り口」である。 納得感 → 共創者として時間を 共有 → 結果が出る → 信頼 © KAKEHASHI Inc. All Rights Reserved. 67

Slide 69

Slide 69 text

信頼の手前に、 納得感がある © KAKEHASHI Inc. All Rights Reserved. 68

Slide 70

Slide 70 text

AGENDA 目次 01 導入 02 ベース信頼はどう作ったか 03 入社3ヶ月、再度の組織変更 04 揃えた3つのピース 05 「信頼」と「納得感」は別のもの 06 まとめ 07 最後に 12 © KAKEHASHI Inc. All Rights Reserved.

Slide 71

Slide 71 text

まとめ セオリー破りを、前進に変える条件 STEP 1 ベース信頼を作る まず自分から信頼する → STEP 2 3つのピースを揃える → STEP 3 納得感を生む → STEP 4 共に進み 信頼を得る © KAKEHASHI Inc. All Rights Reserved. 70

Slide 72

Slide 72 text

観察 2〜3ヶ月って、 本当に必要? 「観察」は大事。だが、それは “時間軸” で語るべきものなのか? © KAKEHASHI Inc. All Rights Reserved. 9

Slide 73

Slide 73 text

しのぴーの答え 重要なのは時間ではなく ピース © KAKEHASHI Inc. All Rights Reserved. 72

Slide 74

Slide 74 text

まとめ 揃えるべき、3つのピース Piece 1 Whyの解像度 ミッションから紐解いて 経営判断を自分の言葉で。 Piece 2 解決策の引き出し 経験ストックから 打ち手を即座に。 Piece 3 課題の共通認識 チームと自分の「困っている」を 一致させる。 © KAKEHASHI Inc. All Rights Reserved. 56

Slide 75

Slide 75 text

まとめ 持ち帰ってほしい、2つの言葉 01 納得感を生むのは、時間ではなくピース 02 信頼の手前に、納得感がある © KAKEHASHI Inc. All Rights Reserved. 74

Slide 76

Slide 76 text

AGENDA 目次 01 導入 02 ベース信頼はどう作ったか 03 入社3ヶ月、再度の組織変更 04 揃えた3つのピース 05 「信頼」と「納得感」は別のもの 06 まとめ 07 最後に 12 © KAKEHASHI Inc. All Rights Reserved.

Slide 77

Slide 77 text

最後に 助けとなった、組織の構造 カケハシのオープンな文化 メンバーの「一緒によくしていこう」のスタンス CTOとの対話 © KAKEHASHI Inc. All Rights Reserved. 76

Slide 78

Slide 78 text

最後に © KAKEHASHI Inc. All Rights Reserved.

Slide 79

Slide 79 text

メンバーから しのぴー への リアルなフィードバック © KAKEHASHI Inc. All Rights Reserved. 77

Slide 80

Slide 80 text

メンバーからのフィードバック ── 行動 打席に立つ姿は、こう伝わっていた 「何もわからない状態から、手段を 選ばずゴールをこじ開ける。そこに オーナーシップを感じた」 「オーナーシップを持つと具体まで 抱えがち。でも 具体はメンバーに 任せてくれる。そこが良い」 「逃げない 。大変そうな所、リスク のある所に、程よく現場に入ってく れる」 「あなたのためならやろうかな」と思える © KAKEHASHI Inc. All Rights Reserved. 78

Slide 81

Slide 81 text

メンバーからのフィードバック ── 納得感 なぜ、大きな変更でも受け入れられたのか 「起きたことに対し、いつも “こうなったからこうしたい” と Why と Will を提示してもらえた」 「大きな変更の前は個別の頭出しと全体共有がある。疑問 や反対を挟める “余白” がある」 「提案の軸が、いつも 顧客価値とチームの動きやすさ 。 だから多少大変でも受け入れやすい」 「“納得感を持ってもらった上で決めたい” という思いが 伝わる。だから、 納得できる 」 「伸び代は?」と聞くと ──個別での伸び代は正直思いつかない。 それよりもチームの課題についてもっと話してよりよくしていきたい © KAKEHASHI Inc. All Rights Reserved. 79

Slide 82

Slide 82 text

ありがとうございました! 人を動かすのは、時間ではなく、納得感 。 信頼の手前に、納得感がある。 株式会社カケハシ @kakehashi_dev | 医療体験をしなやかに ShinoP @marupopu | ご感想ぜひ! 盛岡スクラム ローカルコミュニティ運営中