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

by konifar

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

©2024 Kyash Inc. 小西裕介 (こにふぁー / @konifar) [Kyash とわたし] ● 株式会社 Kyash で 8年くらい Fintech のプロダクトを作っています ● 直近4年くらいはマネジメントの役割を担っています ● 日々学んだことをブログに書き残したりしています [プロジェクトマネジメントとわたし] ● プレイヤーとしてはプロジェクトのリードをすることが多かった ● マネジメントの役割を担ってから、「プロジェクトとしてやらねばならないことと開発観点でやらなければならないことをどう両立させるか」に頭を使うことがしばしばあった 4 よろしくお願いしますﾀﾉｼｲ!

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

©2024 Kyash Inc. 9 Kyash でも発生していた所属事業部ごとの目標に資するプロジェクトが優先され、これらの “タネ" となる声が放置されがち。常態化すると、声が上がることもなくなってしまう。ウォレット事業部月のアクティブユーザー数、決済金額をKPIとして置き、 2025年6月には Visaタッチ決済機能を必ずリリースしたい ● 「トランザクション数が増える前に、ウォレットや履歴画面のパフォーマンスを改善しておきたいな」 ● 「決済まわりの調査で時間かかる作りになっている部分を今改修しておいたほうがよさそう」 ● 「来年の監査までに構成を変更しておくと将来にわたって開発効率をかなり上げられそう」ﾖｸﾅｲ!

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

©2024 Kyash Inc. 12 両立のためのステップ 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 1. 何が問題かを見極めて言語化し、 2. いつまでに何をやるべきかを提案。 3. ヨシやるぞと決めて、 4. 決めたらやりきる。考える “時間軸” のすり合わせはこのステップの一部でしかない。どちらかというと、両立が難しく感じる原因は 1. 問題の理解の不足であることが多い。ﾀﾞｲｼﾞ!

Slide 13

Slide 13 text

©2024 Kyash Inc. 13 両立の “コツ” はない ● 銀の弾丸はない。画一的な基準をもって機械的に判断できるものではなく、決断が必要 ● 誰かがやると決めないと絶対に進まない ● やるならちゃんと時間をとって計画しないと進まない ● 決めたら振り返りをしながらやりきるのみやると決めて、時間をとって計画し、やりきるのみ https://speakerdeck.com/soudai/aim-for-the-goal

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

©2024 Kyash Inc. 16 “コツ" はないが、抑えておくとよいポイントはいくつかある今まで何度もうまくいかなかった経験をしてきて、失敗パターンや抑えるべきポイントがあるように思う。「うまくいかないけどどうしたらいいかわからない」という人に向けて、自分の N=1 の意見を10個ピックアップしてみる。何かしら前に進められるきっかけになったら嬉しい。 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 1．オーナーを明確にする 2. 状況の把握 / 相談 / 意思決定のフローを作る 3. 事業計画を理解する 4．意思決定者を明確にする 5. 経営の関心事に紐づけて話す 6. 意思をもって伝える 7. 検証期間を提案する 8. 一時的なプロジェクトチームを作る 9. 地に足をつけた専任チームを作る 10. 完遂まで定期的に状況報告する

Slide 17

Slide 17 text

©2024 Kyash Inc. 17 ● 整理して前に進めていくのはとても難しく、オーナーをただ1人に決めないと進まない ● 「進んでいなかったらこの人の責任」と言える状態を作る ○ しんどく感じるが、これがオーナーシップを持つということ ○ あくまで推進のオーナーで、「やりきる」責任は全員にある ● CTOやVPoE、EM の役割を定義しているなら、オーナーの責務も持たせるのがいいと思う ○ ただし、共同で進めるとかはダメ。オーナーは1人に決めること 1. オーナーを明確にする 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂ﾀﾉﾝﾀﾞ!

Slide 18

Slide 18 text

©2024 Kyash Inc. 18 ● エンジニア個々人が感じている課題を吸い上げ整理する ○ 1on1、チーム定例、オフィスでの雑談など ● 長期的な目線で物事を考える責務を持つ人への相談のフローを作る ○ 意思決定の前段階で、ドラフトの相談ができる場を作っておくとよい ■ Kyash の場合、経営会議とは別で経営メンバーも含めて気軽に議題を上げられる定例を用意している。 (正直今はエンジニア個々人から議題が上がることは少なく、自分が取りまとめて上げている) ● 正式な意思決定の場を明確にする ○ なんとなく立ち話で決まってログも残らないという状態にならないようにすること ○ 小さな組織であっても、ここはちゃんと設計しておいたほうがよい 2. 状況の把握 / 相談 / 意思決定のフローを作る 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂

Slide 19

Slide 19 text

©2024 Kyash Inc. 19 ● エンジニアリングの問題は、半年以上を見据えて取り組むことも多い ● 半年以上の計画を理解しないと、「なぜ今やるか」、「今やらないとどうなるか」を整理できない ● 中期経営計画や事業計画は、長いタイムスパンで考えられているのでこれを理解する ○ たとえば、いつどのくらいの事業規模を目指しているかから、想定するべきトランザクション数や運用負荷などを予想できる ○ 「なんとなくいつか問題になりそう」くらいの理解レベルで提案に進むと、すり合わせが難しいように感じてしまう。これはただ事業計画とアラインした問題の深堀りが足りないだけ 3. 事業計画を理解する 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 “時間軸" のすり合わせはココ

Slide 20

Slide 20 text

©2024 Kyash Inc. 20 ● 最終的に誰がどう決めるのかを明確にしておかないと進まない ○ 具体的には、組織図、職務権限規程、意思決定の会議体あたりも参照して決めること ● オーナーと同じく、意思決定者はただ一人に決めるべき ○ 提案はボトムアップでもよいが、決定と実行はトップダウンで号令をかけるほうが早い 4. 意思決定者を明確にする 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂

Slide 21

Slide 21 text

©2024 Kyash Inc. 21 ● リスク / 収益性 / コストあたりと関連づけて説明する ○ ある程度の投資が必要な大きさの提案の場合、そのほうが実施の合意の議論がしやすい ○ たとえばサービスの冗長化構成に問題があるという話であれば、事業継続リスクとして話すことでリスク管理観点での意思決定軸も含めて検討できる ● “技術的負債" という言葉は使わない ○ エンジニアの中でも認識を揃えにくい言葉をあえて使う必要はない ○ 変にメタファーを使わず、問題をそのまま問題として理解してもらって合意するほうがいい ● 時間軸を明確にする ○ いつ時点を想定した提案かの認識を揃えられれば、あとは優先順位の考え方の議論になる 5. 経営の関心事に紐づけて話す 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂

Slide 22

Slide 22 text

©2024 Kyash Inc. 22 ● 機械的な判断ではなく、決断しなければならない ○ 生産性指標や不具合検出率、インシデント分析など、議論のための定量的な判断材料は揃えられるが、材料のひとつでしかない ○ 可視化できること自体はよいものの、機械的に判断はできないので常に決断と正解にする覚悟が問われると思っておくこと ● エンジニアのオーナーとして、「これを今やるべきだ」、「これを今やらせてほしい」という意思を持ち、スタンスをとって伝えることが大事 6. 意思をもって伝える 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂

Slide 23

Slide 23 text

©2024 Kyash Inc. 23 ● やってみないとわからない VS どれくらいかかるかわからないと意思決定できない問題 ● まず意思決定のための検証期間を取るという提案をするとよい ○ 自分の感覚では、 3日くらいもらえればある程度のことはそれなりに解像度を高められるのではないかと思う ● 『ソフトウェア見積もり』のターゲット、見積もり、コミットメントの概念の共通認識を揃えておくとさらによいかもしれない ○ https://www.amazon.co.jp/dp/B00KR96M6K 7. 検証期間を提案する 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂

Slide 24

Slide 24 text

©2024 Kyash Inc. 24 ● コスト削減など、ある程度時間をとってやりきれば成果が出ることが見えていて積み上げで効いてくるようなものは、タスクフォース的にプロジェクトを組んでやりきるとよい ● Kyash ではコスト改善weekを2週間実施し、当月に130万円、翌月にさらに120万円の改善をしたケースがあった 8. 一時的なプロジェクトチームを作る 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂 https://speakerdeck.com/konifar/sahaiharumotoxia-tenoensiniarinkumanesimento?slide=15

Slide 25

Slide 25 text

©2024 Kyash Inc. 25 ● 大きな問題の解決を進めるなら、兼務や片手間では完遂しにくい ○ 過去に週に半日ずつやる、四半期に5日まとめて取るなど色々な方法を試してみたが、「その範囲でできることをやろう」という感じになってしまう ○ 兼務や片手間では、解決の落とし所が小さくまとまっていったり歪なものになったりしがち ● マネジメントの意思決定として、専任チームを作って集中できる状態を作る ○ Kyash では決済の専任チームを作り、決済の安定化やオペレーション負荷低減のための取り組みを継続的に担っていけるようにした 9. 地に足をつけた専任チームを作る 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂

Slide 26

Slide 26 text

©2024 Kyash Inc. 26 ● 覚悟とは、宣言して実行責任と説明責任を果たし続けること ● 何かあった時に説明する、ではなく定期的に説明しなければならない場を用意したほうが完遂の可能性、スピード、質がぐんと上がる ○ なんだかんだ「チョット億劫で嫌だな」と感じるようなプレッシャーが大事。にんげんだもの ● 報告の責務は『1. オーナーを明確にする』で明確にしたオーナーが持つのがよい ○ 分担することもできなくはないが、推進役と分けないほうがやりやすいとは思う 10. 完遂まで定期的に状況報告する 1. 問題の理解 2. 解決策の提案 3. 実施の合意 4. 覚悟と完遂ｶﾞﾝﾊﾞﾛｳ!!

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

©2024 Kyash Inc. 29 問題を正しく理解することが一番大事 ● 「なんとなくいつか問題になりそう」という理解レベルで進めようとすると、意思決定のための合意形成が難しいように感じてしまう ○ 実際にはそれ以前に問題の深堀りが足りていないだけであることが多い ● 銀の弾丸はない。画一的な基準をもって機械的に判断できるものではなく、都度決断が必要 ● 推進の “コツ" もない。推進のオーナーをただ一人に決め、問題を正しく理解し、やるかどうかの意思決定をしてやりきるのみ。そういうものやると決めて、時間をとって計画し、やりきるのみｶﾞﾝﾊﾞﾛｳ!!

Slide 30

Slide 30 text

Slide 31

Slide 31 text

©2024 Kyash Inc. 31 参考記事・資料・本 ● 仕事を前に進めるためのコツ - 判断と決断と共有 : soudai=san ○ https://speakerdeck.com/soudai/aim-for-the-goal ○ 仕事を前に進めていくために大事なマインドセットや振る舞いが詰まった素晴らしい資料 ○ 中盤に判断と決断の違いについて書かれている部分が端的に噛み砕かれていてとてもよい ● ソフトウェア見積もり　人月の暗黙知を解き明かす : Steve MacConell (著) ○ https://www.amazon.co.jp/dp/B00KR96M6K ○ 見積もりを切り口に幅広く説明をした素晴らしい古典 ○ ここで定義された見積もり、ターゲット、コミットメントの3つはチームの共通言語として非常に有用ｱﾘｶﾞﾄｳ!