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
10
開発生産性を鈍化させる問題を 正しく捉えるアプローチ
gen
February 10, 2025
Tweet
Share
More Decks by gen
See All by gen
Four keys改善の 取り組み事例紹介
gen87mugi
0
10
可視化から始める 開発生産性向上の取り組み
gen87mugi
0
17
Other Decks in Technology
See All in Technology
『AWS Distinguished Engineerに学ぶ リトライの技術』 #ARC403/Marc Brooker on Try again: The tools and techniques behind resilient systems
quiver
0
110
Amazon Location Serviceを使ってラーメンマップを作る
ryder472
2
180
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
2
420
バクラクの組織とアーキテクチャ(要約)2025/01版
shkomine
13
3.3k
Oracle Cloud Infrastructure:2025年1月度サービス・アップデート
oracle4engineer
PRO
0
410
Creative Pair
kawaguti
PRO
1
150
君はPostScriptなウィンドウシステム 「NeWS」をご存知か?/sunnews
koyhoge
0
620
ゆもつよがこの30年間自ら経験してきたQA、テストの歴史と未来
ymty
3
580
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
360
ソフトウェア開発現代史:製造業とソフトウェアは本当に共存できていたのか?品質とスピードを問い直す
takabow
15
5.8k
CNAPPから考えるAWSガバナンスの実践と最適化
nrinetcom
PRO
1
410
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Site-Speed That Sticks
csswizardry
3
320
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
How to Ace a Technical Interview
jacobian
276
23k
Optimising Largest Contentful Paint
csswizardry
33
3.1k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Building an army of robots
kneath
302
45k
Building Adaptive Systems
keathley
39
2.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
20
2.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
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