開発生産性を鈍化させる問題を 正しく捉えるアプローチ

Transcript

1. Sansan株式会社 部署 名前 開発⽣産性を鈍化させる問題を 正しく捉えるアプローチ Sansan技術本部 Sansan技術本部 Bill One Engineering Unit 川元 謙治
2. 写真が入ります 川元 謙治 Sansan株式会社 技術本部 Bill One Engineering Unit SIerやパッケージ開発会社での経験を経て、2022 年にSansanへ中途⼊社。 Sansan株式会社ではWebアプリケーション開発エ ンジニアとしてキャリアをスタートし、現在は Bill Oneの受領グループのエンジニアリングマネジ ャーとして、 Bill One 全体の開発⽣産性向上に向 き合っている。
3. アジェンダ - 拡⼤組織の中で問題を正しく捉えることの重要性 > エンジニア組織の成⻑ > 拡⼤組織の中でアジリティを維持するためには > 組織全体での改善で成果を最⼤化するためには - 問題を正しく捉えるアプローチ > 問題解決のステップ > ケーススタディ - まとめ
4. 拡⼤組織の中で 問題を正しく捉えることの重要性
5. エンジニア組織の成⻑ プロダクト成⻑とともに急拡⼤中 国内SaaSにおいて類を⾒ない速度で成⻑
6. 拡⼤組織の中でアジリティを維持するためには チームでの改善 - スクラム開発によって⾃発的に改善が進む - ⼀⽅でチームを超えた⾮連続な問題にはオーナーシップを持ちにくい - 特性として出した成果の影響範囲を広げるコストの不確実性が⾼い 組織全体での改善 - チームを超えた組織全体へレバレッジの効いた改善が進む - ⼀⽅で抽象度の⾼い問題が多く、論点を捉えにくい - 特性として出した成果が直接的に組織全体に最⼤化しやすい
7. 拡⼤組織の中でアジリティを維持するためには チームでの改善 - スクラム開発によって、ある⼀定⾃発的に改善が進む - ⼀⽅でチームを超えた⾮連続な問題にはオーナーシップを持ちにくい - 特性として出した成果の影響範囲を広げるコストの不確実性が⾼い 組織全体での改善(今⽇する話はこちら) - チームを超えた組織全体へレバレッジの効いた改善が進む - ⼀⽅で抽象度の⾼い問題が多く、論点を捉えにくい - 特性として出した成果が直接的に組織全体に最⼤化しやすい
8. 組織全体での改善で成果を最⼤化するためには - 「解くべき問題」のことを論点と呼んでおり、その解くべき問題を定 義するプロセスを論点思考と呼ぶ - あなたがいま解いている問題、これから解こうとしている問題は正し いのだろうか。正しく設定されているだろうか。残念ながら、それは いつも正しいとはかぎらない。そして問いの設定を間違えていたら、 その問いを解いても成果は得られない。 - 最初に論点設定を間違えると、間違った問題に取り組むことになるの で、その後の問題解決の作業をいくら正しくやったところで意味のあ る結果は⽣まれない。 出典: 内⽥ 和成 「論点思考」 その問題を解けば開発⽣産性は向上するのだろうか？？
9. 組織全体での改善で成果を最⼤化するためには 問題を正しく捉える論点思考が超重要
10. 問題を正しく捉えるアプローチ
11. 問題解決のステップ 1. 論点候補を拾い出す 2. 論点を絞り込む 3. 全体像を確認し、論点を確定する 論点思考のステップを利⽤して解くべき問題設定からアプローチしていきます 組織全体でイベント(MTG)最適化を⾏ったケースで流れを⾒てみましょう ※ ミーティングやスクラムイベントなどを広義でイベントと表現しています。以降のページではイベントで表記を統⼀します。 ※ 出典: 内⽥ 和成 「論点思考」
12. ケース: イベント最適化 1. 論点を拾い出す = 会話を通じた定性的なアプローチ 1on1(個⼈) - 最近開発時間があまり取れてないかも？ - 期末期初の時期的な要因？ - 最近スイッチングコストが⾼い気がする？ ふりかえり(チーム) - 全体イベントやスクラムイベントが多く感じる？ - イベントとイベントの隙間がコマ切れで集中できてない？ - ⾃⾝の都合の良いタイミングで情報にキャッチアップしたいが、 同期的コミュニケーションが多い？
13. ケース: イベント最適化 2-1. 論点を絞り込む = 解ける確率の低い論点は捨てる 例えば時期的な要因 - 「解決できるか？」にこだわって考える - 評価や採⽤時期など企業レベルでの繁忙期はどの企業でも存在する - 部⾨レベルで解決できるか？ - ⾃部⾨が優先度⾼く取り組む問題なのか？ 「解ける確率も優先度も低いので早めに論点から除外しよう」
14. ケース: イベント最適化 2-2. 論点を絞り込む = エビデンスを基にして可能な限り定量的なアプローチ ⼯数分析 - 全体⼯数割合に対して、イベント⼯数割合が増えて、開発⼯数割合が相 対的に減少し始めている イベントの時間割を作成して可視化 - 各種イベントが意図せずいくつも点在している 同期⾮同期コミュニケーションの使い分け状況確認 - 必須任意参加が曖昧なミーティングが多いため同期的に参加している - ⾮同期で情報にキャッチアップする術が無いまたは乏しい
15. ケース: イベント最適化 3. 全体像を確認し、論点を確定する = 分析結果をフィードバックして確証を得る 開発時間が取れていない - ⼯数分析結果から事実として開発⼯数割合が減少傾向であった スイッチングコストが⾼い - イベントの時間割確認結果から意図せずイベントが点在していた - イベント内容の分析結果から必須/任意参加が曖昧だった - イベント内容の分析結果から情報のキャッチアップ⽅法が同期コミュニケー ション前提のイベントが多かった
16. ケース: イベント最適化 論点１：イベント増加に伴い、開発時間が減少し、進捗影響が出ている 論点２：スイッチングコストが⾼いため、フロー状態を保てず効率が悪い 分析結果をフィードバックして確証を得られたことから論点を以下２点に確定
17. ケース: イベント最適化 分析結果をフィードバックして確証を得られたことから論点を以下２点に確定 論点１：イベント増加に伴い、開発時間が減少し、進捗影響が出ている 論点２：スイッチングコストが高いため、フロー状態を保てず効率が悪い (point) - 周りに分析結果をフィードバックした際に、やっぱりか！なるほ どね！の様なリアクションが得られればOK - 「イベント増加」といった事象で捉えるのではなく、その事象に よってどういった問題があるのかといった表現で確定させること
18. ケース: イベント最適化 論点に応じた改善策を実施 論点１：イベント増加に伴い、開発時間が減少し、進捗影響が出ている - 毎週⽔曜⽇を組織全体でNo Meeting Dayに設定 - 形骸化したイベントを廃⽌し、定例会の頻度を⾒直し 論点２：スイッチングコストが⾼いため、フロー状態を保てず効率が悪い - 意図せず点在していたイベント時間割を全体的に⾒直し - イベントや役割別に参加必須/任意を明確化 - 任意イベントについては⾃⾝のタイミングで録画でキャッチアップ
19. 改善結果はどうなったか 論点設定〜改善実施期間 開発時間割合が増加し、スイッチングコストが削減されたことで 開発⽣産性指標の⼀つであるPBI(プロダクトバックログ)の完了数が持ち直し増加 (イベント最適化１ヶ⽉後のアンケート結果) No Meeting Dayを今後も継続したいか？ 継続して欲しいが92.1% スイッチングコスト削減されたか？ 削減・軽減されたが半数以上
20. まとめ
21. まとめ - 組織は⽣き物なので、論点は常に移り変わっていく - 「チームでの改善」と「組織全体での改善」の縦横両軸の特性を⽣かした 改善が重要 - 雑談レベルの定性的なインプットからエビデンスを基にした定量的な論点 の絞り込みに繋げていくことが重要 - 解くべき問題を正しく捉え、解いた先に意味のある結果(成果)を⽣み出す ことが重要