事業部のプロジェクト進行と開発チームの改善の “時間軸" のすり合わせ

Backlog World 2025
https://jbuginfo.backlog.com/backlogworld2025/

Transcript

1. ©2024 Kyash Inc. ©2024 Kyash Inc. 事業部のプロジェクト進行と開発チームの 改善の “時間軸" のすり合わせ Backlog World 2025 2025/11/29 (土) Kyash Inc. VPoE @konifar
2. ©2024 Kyash Inc. 今日のテーマ 2 https://jbuginfo.backlog.com/backlogworld2025/
3. ©2024 Kyash Inc. テーマを少し変えます 3 ｺﾞﾒﾝﾅｻｲ! 事業部のプロジェクト進行と開発チームの改善の “時間軸" のすり合わせ 事業部のプロジェクト進行と開発チームの改善の 両立 〜問題の理解 ･ 提案 ・ 合意 ・ 覚悟〜 考えを整理している中で、 「時間軸 のすり合わせは別に大した問題じゃ ない」 と気づいてしまった
4. ©2024 Kyash Inc. 小西 裕介 (こにふぁー / @konifar) [Kyash と わたし] • 株式会社 Kyash で 8年くらい Fintech のプロダクトを作っています • 直近4年くらいはマネジメントの役割を担っています • 日々学んだことをブログに書き残したりしています [プロジェクトマネジメント と わたし] • プレイヤーとしてはプロジェクトのリードをすることが多かった • マネジメントの役割を担ってから、 「プロジェクトとしてやらねばならないことと開発観点でやらなけ ればならないことをどう両立させるか」 に頭を使うことがしばしばあった 4 よろしくお願いします ﾀﾉｼｲ!
5. ©2024 Kyash Inc. 5 目 次 1. プロジェクト進行と開発チーム改善とは？ 2. 両立のための考え方 3. 抑えておくとよい10のポイント Table of contents
6. ©2024 Kyash Inc. ©2024 Kyash Inc. 1. プロジェクト進行と開発チーム改善とは？ 6 6
7. ©2024 Kyash Inc. 7 たとえばこういう状態 ① • 事業計画の達成に向けて、 開発もギリギリな状況 • 「このままだとまずい」 というシステム上の課題をなんとなく感じつつも、 優先順位は上がらず 後回しが常態化し “いったん" が永遠に続いていく 「今はいったん事業に集中しましょう」 ﾂﾗｲﾈ!
8. ©2024 Kyash Inc. 8 たとえばこういう状態 ② • システム上やらないといけないことを細かいタスクとして整理し、プロジェクトの隙間時間を使って エンジニアが取っていける状態に • 実際には隙間時間が偶発的にできることは少なく、 できたとしても隙間でできる粒度の小さなも ののみが対応され本当に取り組むべき大きな問題が放置されがち 「隙間時間に少しずつやっていこう」
9. ©2024 Kyash Inc. 9 Kyash でも発生していた 所属事業部ごとの目標に資するプロジェクトが優先され、これらの “タネ" となる声が放置されがち。 常態化すると、声が上がることもなくなってしまう。 ウォレット 事業部 月のアクティブユーザー数、決済金額をKPIとして置き、 2025年6月には Visaタッチ決済機能を必ずリリースしたい • 「トランザクション数が増える前に、ウォレットや履歴画面のパフォーマンスを改善しておきたいな」 • 「決済まわりの調査で時間かかる作りになっている部分を今改修しておいたほうがよさそう」 • 「来年の監査までに構成を変更しておくと将来にわたって開発効率をかなり上げられそう」 ﾖｸﾅｲ!
10. ©2024 Kyash Inc. ©2024 Kyash Inc. 2. 両立のための考え方 10 10
11. ©2024 Kyash Inc. 11 事業部のプロジェクト進行と開発チームの改善の “時間軸" のすり合わせ 事業部のプロジェクト進行と開発チームの改善の 両立 〜問題の理解 ･ 提案 ・ 合意 ・ 覚悟〜 考えを整理している中で、 「時間軸 のすり合わせは別に大した問題じゃ ない」 と気づいてしまった (再掲) テーマを少し変えます ｺﾞﾒﾝﾅｻｲ!
12. ©2024 Kyash Inc. 12 両立のためのステップ 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 1. 何が問題かを見極めて言語化し、 2. いつまでに何をやるべきかを提案。 3. ヨシやるぞと決めて、 4. 決めたらやりきる。 考える “時間軸” のすり合わせはこのステップの一部でしかない。 どちらかというと、両立が難しく感じる原因は 1. 問題の理解 の不足 であることが多い。 ﾀﾞｲｼﾞ!
13. ©2024 Kyash Inc. 13 両立の “コツ” はない • 銀の弾丸はない。 画一的な基準をもって機械的に判断できるものではなく、 決断が必要 • 誰かがやると決めないと絶対に進まない • やるならちゃんと時間をとって計画しないと進まない • 決めたら振り返りをしながらやりきるのみ やると決めて、 時間をとって計画し、 やりきるのみ https://speakerdeck.com/soudai/aim-for-the-goal
14. ©2024 Kyash Inc. “ ” 14 それができれば 苦労はしねェ !!! 聞こえる心の声
15. ©2024 Kyash Inc. ©2024 Kyash Inc. 3．抑えておくとよい10のポイント 15 15
16. ©2024 Kyash Inc. 16 “コツ" はないが、抑えておくとよいポイントはいくつかある 今まで何度もうまくいかなかった経験をしてきて、 失敗パターンや抑えるべきポイントがあるように思う。 「うまくいかないけどどうしたらいいかわからない」 という人に向けて、 自分の N=1 の意見 を10個ピック アップしてみる。 何かしら前に進められるきっかけになったら嬉しい。 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 1． オーナーを明確にする 2. 状況の把握 / 相談 / 意思決定のフローを作る 3. 事業計画を理解する 4． 意思決定者を明確にする 5. 経営の関心事に紐づけて話す 6. 意思をもって伝える 7. 検証期間を提案する 8. 一時的なプロジェクトチームを作る 9. 地に足をつけた専任チームを作る 10. 完遂まで定期的に状況報告する
17. ©2024 Kyash Inc. 17 • 整理して前に進めていくのはとても難しく、 オーナーをただ1人に決めないと進まない • 「進んでいなかったらこの人の責任」 と言える状態を作る ◦ しんどく感じるが、 これがオーナーシップを持つということ ◦ あくまで推進のオーナーで、 「やりきる」 責任は全員にある • CTOやVPoE、EM の役割を定義しているなら、 オーナーの責務も持たせるのがいいと思う ◦ ただし、 共同で進めるとかはダメ。 オーナーは1人に決めること 1. オーナーを明確にする 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 ﾀﾉﾝﾀﾞ!
18. ©2024 Kyash Inc. 18 • エンジニア個々人が感じている課題を吸い上げ整理する ◦ 1on1、 チーム定例、 オフィスでの雑談 など • 長期的な目線で物事を考える責務を持つ人への相談のフローを作る ◦ 意思決定の前段階で、 ドラフトの相談ができる場を作っておくとよい ▪ Kyash の場合、 経営会議とは別で経営メンバーも含めて気軽に議題を上げられる定例 を用意している。 (正直今はエンジニア個々人から議題が上がることは少なく、 自分が取りまとめて上げている) • 正式な意思決定の場を明確にする ◦ なんとなく立ち話で決まってログも残らないという状態にならないようにすること ◦ 小さな組織であっても、ここはちゃんと設計しておいたほうがよい 2. 状況の把握 / 相談 / 意思決定のフローを作る 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂
19. ©2024 Kyash Inc. 19 • エンジニアリングの問題は、半年以上を見据えて取り組むことも多い • 半年以上の計画を理解しないと、 「なぜ今やるか」、 「今やらないとどうなるか」 を整理できない • 中期経営計画や事業計画は、 長いタイムスパンで考えられているのでこれを理解する ◦ たとえば、 いつどのくらいの事業規模を目指しているかから、 想定するべきトランザクション 数や運用負荷などを予想できる ◦ 「なんとなくいつか問題になりそう」 くらいの理解レベルで提案に進むと、 すり合わせが難し いように感じてしまう。 これはただ事業計画とアラインした問題の深堀りが足りないだけ 3. 事業計画を理解する 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 “時間軸" のすり合わせ はココ
20. ©2024 Kyash Inc. 20 • 最終的に誰がどう決めるのかを明確にしておかないと進まない ◦ 具体的には、 組織図、 職務権限規程、 意思決定の会議体あたりも参照して決めること • オーナーと同じく、 意思決定者はただ一人に決めるべき ◦ 提案はボトムアップでもよいが、 決定と実行はトップダウンで号令をかけるほうが早い 4. 意思決定者を明確にする 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂
21. ©2024 Kyash Inc. 21 • リスク / 収益性 / コスト あたりと関連づけて説明する ◦ ある程度の投資が必要な大きさの提案の場合、 そのほうが実施の合意の議論がしやすい ◦ たとえばサービスの冗長化構成に問題があるという話であれば、 事業継続リスクとして話すこ とでリスク管理観点での意思決定軸も含めて検討できる • “技術的負債" という言葉は使わない ◦ エンジニアの中でも認識を揃えにくい言葉をあえて使う必要はない ◦ 変にメタファーを使わず、 問題をそのまま問題として理解してもらって合意するほうがいい • 時間軸を明確にする ◦ いつ時点を想定した提案かの認識を揃えられれば、 あとは優先順位の考え方の議論になる 5. 経営の関心事に紐づけて話す 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂
22. ©2024 Kyash Inc. 22 • 機械的な判断ではなく、 決断しなければならない ◦ 生産性指標や不具合検出率、 インシデント分析など、 議論のための定量的な判断材料は揃え られるが、 材料のひとつでしかない ◦ 可視化できること自体はよいものの、 機械的に判断はできないので常に決断と正解にする覚 悟が問われると思っておくこと • エンジニアのオーナーとして、 「これを今やるべきだ」、 「これを今やらせてほしい」 という意思を持 ち、 スタンスをとって伝えることが大事 6. 意思をもって伝える 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂
23. ©2024 Kyash Inc. 23 • やってみないとわからない VS どれくらいかかるかわからないと意思決定できない問題 • まず意思決定のための検証期間を取るという提案をするとよい ◦ 自分の感覚では、 3日くらいもらえればある程度のことはそれなりに解像度を高められるので はないかと思う • 『ソフトウェア見積もり』 の ターゲット、見積もり、コミットメント の概念の共通認識を揃えておくとさ らによいかもしれない ◦ https://www.amazon.co.jp/dp/B00KR96M6K 7. 検証期間を提案する 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂
24. ©2024 Kyash Inc. 24 • コスト削減など、 ある程度時間をとってやりきれば成果が出ることが見えていて積み上げで効いて くるようなものは、 タスクフォース的にプロジェクトを組んでやりきるとよい • Kyash ではコスト改善weekを2週間実施し、 当月に130万円、 翌月にさらに120万円の改善を したケースがあった 8. 一時的なプロジェクトチームを作る 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 https://speakerdeck.com/konifar/sahaiharumotoxia-tenoensiniarinkumanesimento?slide=15
25. ©2024 Kyash Inc. 25 • 大きな問題の解決を進めるなら、 兼務や片手間では完遂しにくい ◦ 過去に週に半日ずつやる、 四半期に5日まとめて取る など色々な方法を試してみたが、 「そ の範囲でできることをやろう」 という感じになってしまう ◦ 兼務や片手間では、 解決の落とし所が小さくまとまっていったり歪なものになったりしがち • マネジメントの意思決定として、 専任チームを作って集中できる状態を作る ◦ Kyash では決済の専任チームを作り、 決済の安定化やオペレーション負荷低減のための取り 組みを継続的に担っていけるようにした 9. 地に足をつけた専任チームを作る 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂
26. ©2024 Kyash Inc. 26 • 覚悟とは、 宣言して実行責任と説明責任を果たし続けること • 何かあった時に説明する、 ではなく定期的に説明しなければならない場を用意したほうが完遂の可 能性、スピード、質がぐんと上がる ◦ なんだかんだ 「チョット億劫で嫌だな」 と感じるようなプレッシャーが大事。 にんげんだもの • 報告の責務は 『1. オーナーを明確にする』 で明確にしたオーナーが持つのがよい ◦ 分担することもできなくはないが、 推進役と分けないほうがやりやすいとは思う 10. 完遂まで定期的に状況報告する 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 ｶﾞﾝﾊﾞﾛｳ!!
27. ©2024 Kyash Inc. ©2024 Kyash Inc. 今日伝えたかったこと 27 27
28. ©2024 Kyash Inc. 28 事業部のプロジェクト進行と開発チームの改善の “時間軸" のすり合わせ 事業部のプロジェクト進行と開発チームの改善の 両立 〜問題の理解 ･ 提案 ・ 合意 ・ 覚悟〜 考えを整理している中で、 「時間軸 のすり合わせは別に大した問題じゃ ない」 と気づいてしまった (再掲) テーマを少し変えます ｺﾞﾒﾝﾅｻｲ!
29. ©2024 Kyash Inc. 29 問題を正しく理解することが一番大事 • 「なんとなくいつか問題になりそう」 という理解レベルで進めようとすると、 意思決定のための合 意形成が難しいように感じてしまう ◦ 実際にはそれ以前に問題の深堀りが足りていないだけであることが多い • 銀の弾丸はない。 画一的な基準をもって機械的に判断できるものではなく、 都度決断が必要 • 推進の “コツ" もない。 推進のオーナーをただ一人に決め、 問題を正しく理解し、 やるかどうかの 意思決定をしてやりきるのみ。 そういうもの やると決めて、 時間をとって計画し、 やりきるのみ ｶﾞﾝﾊﾞﾛｳ!!
30. ©2024 Kyash Inc. ©2024 Kyash Inc. 30 30 ありがとうございました！
31. ©2024 Kyash Inc. 31 参考記事・資料・本 • 仕事を前に進めるためのコツ - 判断と決断と共有 : soudai=san ◦ https://speakerdeck.com/soudai/aim-for-the-goal ◦ 仕事を前に進めていくために大事なマインドセットや振る舞いが詰まった素晴らしい資料 ◦ 中盤に判断と決断の違いについて書かれている部分が端的に噛み砕かれていてとてもよい • ソフトウェア見積もり　人月の暗黙知を解き明かす : Steve MacConell (著) ◦ https://www.amazon.co.jp/dp/B00KR96M6K ◦ 見積もりを切り口に幅広く説明をした素晴らしい古典 ◦ ここで定義された 見積もり、 ターゲット、 コミットメント の3つはチームの共通言語として非常に有用 ｱﾘｶﾞﾄｳ!