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
gen
February 10, 2025
Technology
0
12
開発生産性を鈍化させる問題を 正しく捉えるアプローチ
gen
February 10, 2025
Tweet
Share
More Decks by gen
See All by gen
Four keys改善の 取り組み事例紹介
gen87mugi
0
11
可視化から始める 開発生産性向上の取り組み
gen87mugi
0
19
Other Decks in Technology
See All in Technology
Ask! NIKKEIの運用基盤と改善に向けた取り組み / NIKKEI TECH TALK #30
kaitomajima
1
370
プロダクト観点で考えるデータ基盤の育成戦略 / Growth Strategy of Data Analytics Platforms from a Product Perspective
yamamotoyuta
0
420
High Performance PHP
cmuench
0
120
Active Directory の保護
eurekaberry
6
3.5k
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
1
500
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
120
Grid表示のレイアウトで Flow layoutsを使う
cffyoha
1
160
20250208_OpenAIDeepResearchがやばいという話
doradora09
PRO
0
140
自動と手動の両輪で開発するデータクレンジング
estie
2
170
talk_about_wasmwasi
junkishigaki
0
100
A Hidden Pitfall of K8s DNS with Spring Webflux
musaprg
0
220
ろう・難聴者のコミュニケーションを円滑化する取り組み
chiemi627
0
120
Featured
See All Featured
How GitHub (no longer) Works
holman
313
140k
The World Runs on Bad Software
bkeepers
PRO
67
11k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Building an army of robots
kneath
302
45k
Embracing the Ebb and Flow
colly
84
4.6k
Building Your Own Lightsaber
phodgson
104
6.2k
Designing Experiences People Love
moore
139
23k
Faster Mobile Websites
deanohume
306
31k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Fireside Chat
paigeccino
34
3.2k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
20
2.4k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Transcript
Sansan株式会社 部署 名前 開発⽣産性を鈍化させる問題を 正しく捉えるアプローチ Sansan技術本部 Sansan技術本部 Bill One Engineering
Unit 川元 謙治
写真が入ります 川元 謙治 Sansan株式会社 技術本部 Bill One Engineering Unit SIerやパッケージ開発会社での経験を経て、2022
年にSansanへ中途⼊社。 Sansan株式会社ではWebアプリケーション開発エ ンジニアとしてキャリアをスタートし、現在は Bill Oneの受領グループのエンジニアリングマネジ ャーとして、 Bill One 全体の開発⽣産性向上に向 き合っている。
アジェンダ - 拡⼤組織の中で問題を正しく捉えることの重要性 > エンジニア組織の成⻑ > 拡⼤組織の中でアジリティを維持するためには > 組織全体での改善で成果を最⼤化するためには -
問題を正しく捉えるアプローチ > 問題解決のステップ > ケーススタディ - まとめ
拡⼤組織の中で 問題を正しく捉えることの重要性
エンジニア組織の成⻑ プロダクト成⻑とともに急拡⼤中 国内SaaSにおいて類を⾒ない速度で成⻑
拡⼤組織の中でアジリティを維持するためには チームでの改善 - スクラム開発によって⾃発的に改善が進む - ⼀⽅でチームを超えた⾮連続な問題にはオーナーシップを持ちにくい - 特性として出した成果の影響範囲を広げるコストの不確実性が⾼い 組織全体での改善 -
チームを超えた組織全体へレバレッジの効いた改善が進む - ⼀⽅で抽象度の⾼い問題が多く、論点を捉えにくい - 特性として出した成果が直接的に組織全体に最⼤化しやすい
拡⼤組織の中でアジリティを維持するためには チームでの改善 - スクラム開発によって、ある⼀定⾃発的に改善が進む - ⼀⽅でチームを超えた⾮連続な問題にはオーナーシップを持ちにくい - 特性として出した成果の影響範囲を広げるコストの不確実性が⾼い 組織全体での改善(今⽇する話はこちら) -
チームを超えた組織全体へレバレッジの効いた改善が進む - ⼀⽅で抽象度の⾼い問題が多く、論点を捉えにくい - 特性として出した成果が直接的に組織全体に最⼤化しやすい
組織全体での改善で成果を最⼤化するためには - 「解くべき問題」のことを論点と呼んでおり、その解くべき問題を定 義するプロセスを論点思考と呼ぶ - あなたがいま解いている問題、これから解こうとしている問題は正し いのだろうか。正しく設定されているだろうか。残念ながら、それは いつも正しいとはかぎらない。そして問いの設定を間違えていたら、 その問いを解いても成果は得られない。 -
最初に論点設定を間違えると、間違った問題に取り組むことになるの で、その後の問題解決の作業をいくら正しくやったところで意味のあ る結果は⽣まれない。 出典: 内⽥ 和成 「論点思考」 その問題を解けば開発⽣産性は向上するのだろうか??
組織全体での改善で成果を最⼤化するためには 問題を正しく捉える論点思考が超重要
問題を正しく捉えるアプローチ
問題解決のステップ 1. 論点候補を拾い出す 2. 論点を絞り込む 3. 全体像を確認し、論点を確定する 論点思考のステップを利⽤して解くべき問題設定からアプローチしていきます 組織全体でイベント(MTG)最適化を⾏ったケースで流れを⾒てみましょう ※
ミーティングやスクラムイベントなどを広義でイベントと表現しています。以降のページではイベントで表記を統⼀します。 ※ 出典: 内⽥ 和成 「論点思考」
ケース: イベント最適化 1. 論点を拾い出す = 会話を通じた定性的なアプローチ 1on1(個⼈) - 最近開発時間があまり取れてないかも? -
期末期初の時期的な要因? - 最近スイッチングコストが⾼い気がする? ふりかえり(チーム) - 全体イベントやスクラムイベントが多く感じる? - イベントとイベントの隙間がコマ切れで集中できてない? - ⾃⾝の都合の良いタイミングで情報にキャッチアップしたいが、 同期的コミュニケーションが多い?
ケース: イベント最適化 2-1. 論点を絞り込む = 解ける確率の低い論点は捨てる 例えば時期的な要因 - 「解決できるか?」にこだわって考える -
評価や採⽤時期など企業レベルでの繁忙期はどの企業でも存在する - 部⾨レベルで解決できるか? - ⾃部⾨が優先度⾼く取り組む問題なのか? 「解ける確率も優先度も低いので早めに論点から除外しよう」
ケース: イベント最適化 2-2. 論点を絞り込む = エビデンスを基にして可能な限り定量的なアプローチ ⼯数分析 - 全体⼯数割合に対して、イベント⼯数割合が増えて、開発⼯数割合が相 対的に減少し始めている
イベントの時間割を作成して可視化 - 各種イベントが意図せずいくつも点在している 同期⾮同期コミュニケーションの使い分け状況確認 - 必須任意参加が曖昧なミーティングが多いため同期的に参加している - ⾮同期で情報にキャッチアップする術が無いまたは乏しい
ケース: イベント最適化 3. 全体像を確認し、論点を確定する = 分析結果をフィードバックして確証を得る 開発時間が取れていない - ⼯数分析結果から事実として開発⼯数割合が減少傾向であった スイッチングコストが⾼い
- イベントの時間割確認結果から意図せずイベントが点在していた - イベント内容の分析結果から必須/任意参加が曖昧だった - イベント内容の分析結果から情報のキャッチアップ⽅法が同期コミュニケー ション前提のイベントが多かった
ケース: イベント最適化 論点1:イベント増加に伴い、開発時間が減少し、進捗影響が出ている 論点2:スイッチングコストが⾼いため、フロー状態を保てず効率が悪い 分析結果をフィードバックして確証を得られたことから論点を以下2点に確定
ケース: イベント最適化 分析結果をフィードバックして確証を得られたことから論点を以下2点に確定 論点1:イベント増加に伴い、開発時間が減少し、進捗影響が出ている 論点2:スイッチングコストが高いため、フロー状態を保てず効率が悪い (point) - 周りに分析結果をフィードバックした際に、やっぱりか!なるほ どね!の様なリアクションが得られればOK -
「イベント増加」といった事象で捉えるのではなく、その事象に よってどういった問題があるのかといった表現で確定させること
ケース: イベント最適化 論点に応じた改善策を実施 論点1:イベント増加に伴い、開発時間が減少し、進捗影響が出ている - 毎週⽔曜⽇を組織全体でNo Meeting Dayに設定 - 形骸化したイベントを廃⽌し、定例会の頻度を⾒直し
論点2:スイッチングコストが⾼いため、フロー状態を保てず効率が悪い - 意図せず点在していたイベント時間割を全体的に⾒直し - イベントや役割別に参加必須/任意を明確化 - 任意イベントについては⾃⾝のタイミングで録画でキャッチアップ
改善結果はどうなったか 論点設定〜改善実施期間 開発時間割合が増加し、スイッチングコストが削減されたことで 開発⽣産性指標の⼀つであるPBI(プロダクトバックログ)の完了数が持ち直し増加 (イベント最適化1ヶ⽉後のアンケート結果) No Meeting Dayを今後も継続したいか? 継続して欲しいが92.1% スイッチングコスト削減されたか?
削減・軽減されたが半数以上
まとめ
まとめ - 組織は⽣き物なので、論点は常に移り変わっていく - 「チームでの改善」と「組織全体での改善」の縦横両軸の特性を⽣かした 改善が重要 - 雑談レベルの定性的なインプットからエビデンスを基にした定量的な論点 の絞り込みに繋げていくことが重要 -
解くべき問題を正しく捉え、解いた先に意味のある結果(成果)を⽣み出す ことが重要
None