Upgrade to Pro — share decks privately, control downloads, hide ads and more …

定義のない仕事 / Undefined Work

Avatar for nrs nrs
September 06, 2025

定義のない仕事 / Undefined Work

大吉祥寺.pm における発表資料です。
CTOというロールになってからの七転八倒のお話です。

https://fortee.jp/dai-kichijojipm-2025/proposal/7a49d7e1-b75f-4bad-b144-d62957ce9edf

# URL
YouTube: https://www.youtube.com/c/narusemi
HomePage: https://nrslib.com
Twitter: https://twitter.com/nrslib
Instagram: https://www.instagram.com/nrslib/

Avatar for nrs

nrs

September 06, 2025
Tweet

More Decks by nrs

Other Decks in Business

Transcript

  1. 6 • 貴重な経験をしている ◦ コンテキストゼロからはじめるCTO ◦ 開発組織だけでも100名に届くかというところ • だれに? ◦

    CTOになった人 ◦ CTOを目指す人 ◦ CTOを迎える人 ◦ 定義のない仕事に立ち向かう人々=人類!! 「2025年の今」伝えたいこと
  2. 9 • コードを書くことの相対的価値の低下 ◦ 情報の共有によりハードルの低下 ◦ AI 周辺技術やツールの目覚しい進化 • ビジネスサイクルの高速化

    ◦ MVPを一週間で作れる時代 ◦ 保守性ではなく破棄性が求められる可能性 • ユーザーとの距離の短縮 ◦ 反応を見ながら価値を届ける これまで通りの仕事の仕方が通用しないかも
  3. 10 • 定義のない仕事は誰にでも訪れる ◦ 訪れるパターン ▪ あいまいな依頼 ▪ 突発的な問題 ▪

    機会から始まる ▪ 定義がないことに気づいた ◦ 定義のない仕事に向き合う頻度とスピードは上がった ◦ 定義のある仕事の競争相手は AI そんな時代では
  4. 12 • コードを ◦ 書く? ◦ 書かない? • 得意領域は ◦

    技術寄り? ◦ マネジメント寄り? • エディタは ◦ Vim? ◦ Emacs? あなたが思い浮かべたCTOは
  5. 14 • なわけない ◦ マネジメントは SIer 時代以来やってない ▪ リーダーシップとマネジメントは別物←! ◦

    直近のロールはスタッフエンジニア ▪ 組織横断的な課題に明け暮れる毎日 ◦ 対するコドモンは300名を超える組織 ▪ 開発組織は100名に手が届くかぐらい ◦ CTO自体新設 ▪ つまり前例なし 順風満帆?
  6. 18 • 開発メンバー ◦ オフィスアワー ◦ イベントストーミング • 開発メンバー以外 ◦

    業務のことを聞きに行く ▪ FS ▪ CSX ◦ CTOランチ ▪ #CTOは財布 対話する
  7. 19 • 参加しなくていいものを相談しながら決めること ◦ 互いにどこまで関わるかが決まっていない ▪ レポートラインなので「とりあえず」のノリでインビテーション • 自分もわからないので言われるがままに参加 •

    いつの間にか身動き取れなくなる ◦ 中長期のことを考えるには時間が必要 ▪ 細切れ時間では何も考えられない ▪ 説明する資料作りも進まない スケジュールの整理
  8. 21 • 精神が回復するんじゃぁ ◦ コードを書く=活力 ◦ ペアプロで設計議論 ◦ イベントストーミング ▪

    システム解像度アップ ▪ 同時にコミュニケーション 成果物の一部→ 現場で協働
  9. 22 • 精神が回復するんじゃぁ・その2 ◦ 単純に貢献できることへの喜び ◦ サーヴァントスピリット • とはいえコードを愚直に書いてる暇はない ◦

    バイブコーディング ▪ いい時代になりましたね ▪ 30分のミーティングを25分に ▪ 1時間のミーティングを55分に CEOの願いを叶える
  10. # EventStorming図からCQRS/Event Sourcingコード実装へのプロンプト ## 概要 このドキュメントは、EventStorming図を解析し、既存のCQRS/Event SourcingアーキテクチャパターンとAxon Frameworkを使用してコードを実装するための指示を定義します。 ## EventStorming要素の解釈ルール

    ### 1. イベント(オレンジ色の付箋) - **定義**: システムで発生した事実を過去形で表現 - **実装**: Axonのイベントクラスとして実装(CartEventインターフェースを実装) - **例**: 「カートに商品が追加された」→ CartItemAddedEvent クラス ### 2. コマンド(青色の付箋) - **定義**: システムに対する命令・意図 - **ルール**: コマンドが空白の場合、イベントの現在形をコマンドとする - **実装**: Axonのコマンドクラスとして実装(@TargetAggregateIdentifierを含む) - **例**: - 空白の場合: 「商品がカートに追加された」→「商品をカートに追加する」→ AddCartItemCommand - 「商品がカートから削除された」→「商品をカートから削除する」→ RemoveCartItemCommand
  11. ## 実装手順 ### Step 1: EventStorming図の解析 1. 図内のすべての付箋を色別に分類 2. 付箋間の矢印・フローを把握

    3. 空白のコマンドはイベントから生成 4. 集約が不明な場合はイベントから推測 ### Step 2: CQRS/Event Sourcingモデルの定義 1. モジュール構造の作成 ``` modules/cart/ ├── domain/ │ └── models/ │ └── cart/ │ └── Cart.kt # ドメインモデル ├── application/ │ ├── CartProjection.kt # イベントハンドラー(リードモデル更新) │ ├── CartQueries.kt # クエリハンドラー │ └── CartQueryService.kt # クエリサービス
  12. ### Step 3: 各層の実装 #### Adaptor層(Axonアグリゲート) - **CartAggregateAdaptor.kt**: コマンドとイベントのハンドリング -

    **CartCommands.kt**: コマンドクラスの定義 - **CartEvents.kt**: イベントクラスの定義 #### Domain層 - **Cart.kt**: ビジネスロジックとドメインルール - **重要**: ドメインモデルには識別子(ID)のみを保持し、その他のフィールドは持たない - ドメインモデルはイベント生成とビジネスロジックの実行に特化 - 状態の詳細はリードモデル(JPAエンティティ)で管理 #### Application層 - **CartProjection.kt**: イベントハンドラー(リードモデルの更新) - **CartQueries.kt**: クエリクラスとハンドラー - **CartQueryService.kt**: クエリ実行サービス #### Infrastructure層 - **CartDataModel.kt**: JPAエンティティ(リードモデル) - **CartDataModelRepository.kt**: Spring Data JPAリポジトリ
  13. ### Step 4: 実装例 ```kotlin // コマンドクラス (adaptor/cart/CartCommands.kt) data class

    AddCartItemCommand( @TargetAggregateIdenWfier val accountId: String, val photoId: String, val quanWty: Int ) data class RemoveCartItemCommand( @TargetAggregateIdenWfier val accountId: String, val photoId: String ) // イベントクラス (adaptor/cart/CartEvents.kt) interface CartEvent { val accountId: String }
  14. 31 • ゼロイチは任せない ◦ ソフトウェア設計の深めの知見が必要なところは AI は苦手 • AI に再現するための情報をファイル(①)に書き出させる

    • ①を読み込ませながらコードを書かせる ◦ ブラッシュアップを手動でやるか AI にやらせるかは都度判断 ◦ ブラッシュアップした内容から①の更新要否を判断 ▪ ①の更新を手動でやるか AI で行うかは都度判断 自分なりの AI 活用バイブル
  15. 33 • 理論から学べる ◦ フレームワークとその活用方法の体得 ◦ マネジメントスキルのティーチング能力向上 • ケーススタディで実践できる ◦

    思考の瞬発力アップ 対価:毎週10時間ぐらいを捧ぐ 成果:きっとこれから実感 ビジネススクールに通う
  16. 34 • 組織も本人もまずはここに注力するべく尽力する ◦ 組織は本人がバリューを発揮できるように支援する ◦ 本人はバリューを発揮するために障害排除を求める • 重要なのは、その人本来の強みを出すこと ◦

    強みのない部分でのバリュー発揮は実感が伴わない ◦ CTOとしてのバリューと思っているところとの合致が必要 • すべての特効薬 ◦ しかし最初はもっとも得難いものかもしれない ◦ そのバリューに明確な定義はないのだから バリューを発揮する
  17. 44 • すべてを抱え込まない ◦ 渡されたボールはあなたがもつべきでない可能性がある ▪ 開発者のマインドだと課題解決思考になりがち ▪ 全体感から対応すべきか移譲すべきかを考慮する •

    自分の得意苦手を可視化する ◦ 採用観点では育成が難しい/機会がないスキルを求めるのが定石 ▪ その苦手は育成可能なものか? ▪ その苦手は自分がこなすことを求められているか? CTOになった人
  18. 45 • 目指すCTOを定義する ◦ 組織の規模やフェーズで千差万別 ◦ 一般的に規模が大きくなればなるほどマネジメントの要素が強くなる ▪ あなたの強みはどこにある? ▪

    あなたは何に楽しみを覚える? ▪ あなたは何がしたい? • リーダーシップとマネジメントは補完関係にあるが異なるもの ◦ リーダーシップは変化に対処する力 ◦ マネジメントは複雑な状況に対応する力 CTOを目指す人
  19. 46 • 期待値を可視化する ◦ 組織の思い、個人の思い、本人の思い、すべてちょっとズレてるはず ▪ 我々は可視化しないとわかりあえない • 本人のバリューを発揮できる場とプロセスを用意する ◦

    CTOに限らない話だが手掛ける範囲の関係上難しいテーマ ▪ 取り組む範囲としてどうしても長期になりがち ▪ 結果はかなりあとになる ◦ バリューを発揮できても本人の自覚がないことがある ▪ 強みのない(と思ってる)ところだとピンとこない CTOを迎え入れる人
  20. 47 • 定義すること ◦ 形にすること ▪ 頭の中の定義は存在しないのと同じ ▪ パロールとエクリチュールではエクリチュールが根源的 ◦

    そしてそれを互いに確認しあうこと ▪ それは経営チームかもしれない ▪ それは開発チームかもしれない ▪ それは仲間かもしれない 定義のない仕事をこなすコツ
  21. 49 ! " # $ % 得 % ' (

    栄 養 代 , - . /