Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら...
Search
KAKEHASHI
PRO
October 09, 2024
Technology
5
2.8k
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
エンジニア組織の成果を伝えたい!経営層や非エンジニア組織との会話、どうしてる?
https://d-plus.connpass.com/event/331345/
での登壇資料です
KAKEHASHI
PRO
October 09, 2024
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
人はなぜISUCONに夢中になるのか
kakehashi
PRO
6
1.6k
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
530
アジャイルチームが変化し続けるための組織文化とマネジメント・アプローチ / Agile management that enables ever-changing teams
kakehashi
PRO
3
4.2k
チームが毎日小さな変化と適応を続けたら1年間でスケール可能なアジャイルチームができた話 / Building a Scalable Agile Team
kakehashi
PRO
3
370
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
kakehashi
PRO
11
1.9k
KAKEHASHI Company Deck / Company Deck
kakehashi
PRO
4
1.7k
アジャイルチームがらしさを発揮するための目標づくり / Making the goal and enabling the team
kakehashi
PRO
4
970
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
PRO
1
960
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
PRO
2
340
Other Decks in Technology
See All in Technology
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
960
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
190
ハッキングの世界に迫る~攻撃者の思考で考えるセキュリティ~
nomizone
13
5.2k
君も受託系GISエンジニアにならないか
sudataka
2
430
現場で役立つAPIデザイン
nagix
33
12k
モノレポ開発のエラー、誰が見る?Datadog で実現する適切なトリアージとエスカレーション
biwashi
6
800
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.4k
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
260
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
270
滅・サービスクラス🔥 / Destruction Service Class
sinsoku
6
1.6k
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
2
1.5k
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
120
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
182
22k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Navigating Team Friction
lara
183
15k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
How STYLIGHT went responsive
nonsquared
98
5.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Transcript
日本の医療体験を、しなやかに。 © KAKEHASHI Inc. 2024/10/09 エンジニア組織の成果を伝えたい!経営層や非エンジニア組織との会話、どうしてる? 株式会社 カケハシ 松本 明紘
見えづらい活動の成果の伝え方は日頃からめちゃ くちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ
自己紹介 もっち(@mottyzzz) 松本 明紘 株式会社 カケハシ(2023年2月〜) • AI在庫管理、新規事業 • バックエンドに軸足を置くテックリード
最近 • 仕事中も歩くようにしたことで 運動の習慣ができてきた
日本の医療体験を、 しなやかに。 カケハシは、調剤薬局DXを入り口に 日本の医療システムの再構築を目指す ヘルステックスタートアップ
カケハシの5つのプロダクト 2024年9月でリリース三周年 🎉🎉🎉
<本日のテーマ> エンジニア組織の成果を伝えたい! 経営層や非エンジニア組織との会話、 どうしてる?
とある成果の共有の1シーン エンジニア 誰か 事業課題とサービス(運用)課題の不一致 ずっと手作業だった運用を自動化し て、40時間/月の作業時間をゼロにし ました! それによって、大きくコスト削減でき ました!🎉🎉🎉 いまは売上向上のための
事業スケールの方が大事 だから、他のことに時間 使ってほしかったなあ。 いいね あれ、あんまり 喜んでもらえな かったな、、、
事前にお互いの持つ課題への共感ができていたら エンジニア 誰か 事業課題とサービス(運用)課題の一致 ずっと手作業だった運用を自動化し て、40時間/月の作業時間をゼロにし ました! それによって、機能開発に当てられる 時間が増えました!🎉🎉🎉 いま新規ユーザーの獲得のための機能
追加をどんどんやっていきたかったか ら、とても助かります!!!!
課題への共感
課題への共感 • 成果を伝えるということ以前に「課題への共感」を大事に している • 「課題への共感」=「課題を自分ごととして受け止めても らえている状態」 • 成果が上手に伝わるとき=課題への共感が得られていて、 それが解決できたとき
課題への共感 • 認知 → 理解 → 納得 → 共感 ◦
理解や納得はもちろん大事で、論理性や定量化は必要 ◦ 共感には関係性やストーリーテリングも大事になってくる。一緒に働い ている感覚、同じ方向を向いて進んでいるという実感できる状態 ◦ 共感までしてもらえると、その人自身が他にも広げてくれる ◦ 特に大きな組織になればなるほど、同じ課題や成果を他の人が説明しな ければいけないシーンが出てくる ◦ エンジニアも技術課題を共感してもらうために、また、組織課題や事業 課題に共感するために一歩踏み出す必要がある
AI在庫管理の主なコミュニケーションパス ドメインリード エンジニアリング マネージャ ソフトウェアエンジニア プロダクトマネージャ デザイナー CTO カスタマーサクセス 経営陣
色んな視点での課題 ドメインリード エンジニアリング マネージャ ソフトウェアエンジニア プロダクトマネージャ デザイナー CTO カスタマーサクセス プロダクトの
技術課題 組織課題 プロダクト 課題 ユーザー 課題 顧客課題 事業課題 プロダクト間をまたがった 技術課題 エンジニア全体の 組織課題 経営課題 開発プロセ スの課題 サービス 課題 経営陣
「課題への共感」づくりのための取り組み 1. コンテキストを合わせる ◦ お互いの視点での課題が変換できるようにしていく 2. ロールを超えた関係性の醸成 ◦ 相手を知り、お互いの仕事に興味を持つ ◦
お互いが大事にしていることを知る 3. 課題の分かりやすさを向上させていく ◦ とはいえ、課題の認知・理解・納得も大事であるため、影響範囲 や影響度なども整理するのも大事
1.コンテキストを合わせる
職能チームからマトリックス型チームへの変換 [参考]https://speakerdeck.com/kakehashi/streamlining-product-validation-in-growth-phase • 技術課題の解決も機能開発と同じ土俵で実施判断する • 開発ロードマップも一緒に見ることでの将来の技術課題の早期発見
見えづらい技術課題の取り組みを 全体ミーティングで紹介 • 技術的負債を本棚で例えたり • ライブラリアップデートを 車のメンテナンスに例えたり • 一般的な話もする
2.ロールを超えた関係性の醸成
バックエンドとフロントエンドとデザイナーの 苦しみを共有する会 デザイナー ソフトウェアエンジニア • 開発の難易度をラフに早めに確認 現状、設定項目も各機能の画面内 に配置しているものが多い。画面 内の情報過多になっていくので、 設定画面を作りたいが開発観点だ
と何か困りますか? 遅いAPIの速度改善をSQLのチューニングや 処理の改善で進めてきたけどこれ以上は難 しくなってきました。 画面のこの部分のフィルタ条件、こんな風 に変えるのって難しいですかね?
バックエンドとフロントエンドとデザイナーの 苦しみを共有する会 デザイナー ソフトウェアエンジニア • 開発のよりより進め方の確認や、困っていること(苦しみ)の共有 デザインの確認は開発着手したタ イミングで見せた方がいい?あま り早いとそれはそれでコスト上 がっちゃいますかね?
XX在庫金額とかYY在庫金額とか本 当難しい。
カスタマーサクセスとエンジニアの 温度感を合わせて行く会 カスタマーサクセス ソフトウェアエンジニア • 働く上で普段考えていることの確認 開発側の人々って、普段プロダク ト開発に対してどういう風に考え てるんだろうなとか気になってた りします。
ユーザーからよく問い合わせが来るものでAI在 庫管理では対応できないものとして割り切って いる内容があれば聞いてみたいですmm (もしか すると簡単に解決できるものがあるかもしれな いので)
カスタマーサクセスとエンジニアの 温度感を合わせて行く会 カスタマーサクセス ソフトウェアエンジニア • プロダクトをよりよくしていくためには何ができそうかの会話 どういう情報を渡したら実装が早くなるとか ありますか? (背景として、開発しなければいけない機能が 沢山ある中で、よりスピーディーに開発を進
めるために必要な情報などがないかを知りた い) お客様はXXX機能を使いこなせてますか? 割と実装が複雑なため、お客様が使いこな せなさそうと感じています。
3.課題の分かりやすさを向上させていく
「空雨傘」による技術的負債の整理 • 「空雨傘」のフレームワーク ◦ 空:空が曇っている(事実) ◦ 雨が降りそうだ(解釈や見解) ◦ 傘を持っていこう(判断と行動) 空
backendではこれまでAPIのテストはMedium Testを中心に作成してきた。CI/CDでのテスト実行時間が 10分以 上かかっている。 雨 (技術課題)待ち時間が長くなることで生産性が遅くなっている。機能追加の継続とテストの拡充の中で、さらにテ スト時間やCI/CDの時間が増えていってしまう。 (開発プロセスの課題)その結果、バグの発見までの時間や、障害対応時の hotfixまでの時間も長くなってしま う。 (ユーザー課題)復旧時間に時間がかかることで軽微な修正であったとしてもユーザーが利用できない時間が長 くなっていってしまう。復旧時間が長くなると影響を受けるユーザーも多くなってしまう。 傘 細かな分岐や仕様の網羅的な確認はテスト時間の短い Small Testに分解していく。 それによりMedium Testの 数を減らし、テスト時間やCI/CDの時間を減らしていく
データ分析による解釈の精度を高める
リスクアセスメントにより、優先度を定量化する [参考]https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20230707.pdf
まとめ • 成果が伝わりやすい状態を作るために「課題への共感」を 大事にしている ◦ コンテキストを合わせて課題をお互いの視点に変換できるように する ◦ ロールを超えた関係性を醸成し、お互いの仕事に興味を持つ ◦
そういった関係に甘えず、技術課題自体を分かりやすくすること も忘れずに取り組んでいる • そんなに上手に進まないシーンももちろんあるので、都度 悩みながらも会話しながら進めている