Slide 1

Slide 1 text

定義のない仕事 nrs

Slide 2

Slide 2 text

2 初代大吉祥寺.pmベストスピーカーです!

Slide 3

Slide 3 text

2025年の今

Slide 4

Slide 4 text

4 Profile nrs(成瀬 允宣) @nrslib コドモンのCTO 好きなアーキテクチャはMVPとCQRS+ESです 趣味:カンファレンス講演 学生支援 小学校支援 写真

Slide 5

Slide 5 text

5 ● 一般的なルートは? ○ プログラマ→紆余曲折マネジャーとかいろいろ→CTO ■ このルートはスタートアップからいつのまにかなってたり ● 私のルートは ○ プログラマ→CTO ■ Simple よくあるキャリアではあるけども……

Slide 6

Slide 6 text

6 ● 貴重な経験をしている ○ コンテキストゼロからはじめるCTO ○ 開発組織だけでも100名に届くかというところ ● だれに? ○ CTOになった人 ○ CTOを目指す人 ○ CTOを迎える人 ○ 定義のない仕事に立ち向かう人々=人類!! 「2025年の今」伝えたいこと

Slide 7

Slide 7 text

VUCAの時代だ!

Slide 8

Slide 8 text

8 ● V:Volatility(変動) ● U:Uncertainty(不確実) ● C:Complexity(複雑) ● A:Ambiguity(曖昧) 定義がしづらい世の中だ

Slide 9

Slide 9 text

9 ● コードを書くことの相対的価値の低下 ○ 情報の共有によりハードルの低下 ○ AI 周辺技術やツールの目覚しい進化 ● ビジネスサイクルの高速化 ○ MVPを一週間で作れる時代 ○ 保守性ではなく破棄性が求められる可能性 ● ユーザーとの距離の短縮 ○ 反応を見ながら価値を届ける これまで通りの仕事の仕方が通用しないかも

Slide 10

Slide 10 text

10 ● 定義のない仕事は誰にでも訪れる ○ 訪れるパターン ■ あいまいな依頼 ■ 突発的な問題 ■ 機会から始まる ■ 定義がないことに気づいた ○ 定義のない仕事に向き合う頻度とスピードは上がった ○ 定義のある仕事の競争相手は AI そんな時代では

Slide 11

Slide 11 text

CTOの仕事って?

Slide 12

Slide 12 text

12 ● コードを ○ 書く? ○ 書かない? ● 得意領域は ○ 技術寄り? ○ マネジメント寄り? ● エディタは ○ Vim? ○ Emacs? あなたが思い浮かべたCTOは

Slide 13

Slide 13 text

13 ● どんなしごとをするかは以下の変数あたり ○ 組織のフェーズ ○ 組織の規模 ○ 組織の課題 ○ 事業特性 ○ 経営チームの構成 CTOのしごとは千差万別

Slide 14

Slide 14 text

14 ● なわけない ○ マネジメントは SIer 時代以来やってない ■ リーダーシップとマネジメントは別物←! ○ 直近のロールはスタッフエンジニア ■ 組織横断的な課題に明け暮れる毎日 ○ 対するコドモンは300名を超える組織 ■ 開発組織は100名に手が届くかぐらい ○ CTO自体新設 ■ つまり前例なし 順風満帆?

Slide 15

Slide 15 text

やってよかったこと

Slide 16

Slide 16 text

16 ● 初期はギャップに葛藤しがち ○ 自分は貢献できていない(自分目線)と思いがち ○ ひとつでもわかりやすいことをやれると安定する ○ たとえば nrs の場合だと登壇 得意なことをインスタントにやる

Slide 17

Slide 17 text

17 ● 開発組織に受け入れられていると感じるならば見の姿勢をやめるときかも ○ CTOとして迎え入れられたのは理由がある ○ 必要以上に恐れなくていい ○ むしろぶつかりあったほうがいいことも ■ 雨降って地固まる ■ 艱難汝を玉にす ■ : 見の姿勢をやめる

Slide 18

Slide 18 text

18 ● 開発メンバー ○ オフィスアワー ○ イベントストーミング ● 開発メンバー以外 ○ 業務のことを聞きに行く ■ FS ■ CSX ○ CTOランチ ■ #CTOは財布 対話する

Slide 19

Slide 19 text

19 ● 参加しなくていいものを相談しながら決めること ○ 互いにどこまで関わるかが決まっていない ■ レポートラインなので「とりあえず」のノリでインビテーション ● 自分もわからないので言われるがままに参加 ● いつの間にか身動き取れなくなる ○ 中長期のことを考えるには時間が必要 ■ 細切れ時間では何も考えられない ■ 説明する資料作りも進まない スケジュールの整理

Slide 20

Slide 20 text

20 ● 互いの期待値のすり合わせ ○ ドラッカー風エクササイズっぽいのを企画してくれた ○ 知ってもらってるというのは重要 その一部→ 得意不得意の可視化

Slide 21

Slide 21 text

21 ● 精神が回復するんじゃぁ ○ コードを書く=活力 ○ ペアプロで設計議論 ○ イベントストーミング ■ システム解像度アップ ■ 同時にコミュニケーション 成果物の一部→ 現場で協働

Slide 22

Slide 22 text

22 ● 精神が回復するんじゃぁ・その2 ○ 単純に貢献できることへの喜び ○ サーヴァントスピリット ● とはいえコードを愚直に書いてる暇はない ○ バイブコーディング ■ いい時代になりましたね ■ 30分のミーティングを25分に ■ 1時間のミーティングを55分に CEOの願いを叶える

Slide 23

Slide 23 text

23 ● ミーティングしながらコードが書ける ○ 当初「美味しいところをAIにもってかれて、つまらないところだけ残 った」 ○ 今「つまらないところをAIに渡して楽しいところやってる」 バイブコーディング最高

Slide 24

Slide 24 text

24 ゼロイチは自分で

Slide 25

Slide 25 text

# EventStorming図からCQRS/Event Sourcingコード実装へのプロンプト ## 概要 このドキュメントは、EventStorming図を解析し、既存のCQRS/Event SourcingアーキテクチャパターンとAxon Frameworkを使用してコードを実装するための指示を定義します。 ## EventStorming要素の解釈ルール ### 1. イベント(オレンジ色の付箋) - **定義**: システムで発生した事実を過去形で表現 - **実装**: Axonのイベントクラスとして実装(CartEventインターフェースを実装) - **例**: 「カートに商品が追加された」→ CartItemAddedEvent クラス ### 2. コマンド(青色の付箋) - **定義**: システムに対する命令・意図 - **ルール**: コマンドが空白の場合、イベントの現在形をコマンドとする - **実装**: Axonのコマンドクラスとして実装(@TargetAggregateIdentifierを含む) - **例**: - 空白の場合: 「商品がカートに追加された」→「商品をカートに追加する」→ AddCartItemCommand - 「商品がカートから削除された」→「商品をカートから削除する」→ RemoveCartItemCommand

Slide 26

Slide 26 text

## 実装手順 ### 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 # クエリサービス

Slide 27

Slide 27 text

### 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リポジトリ

Slide 28

Slide 28 text

### 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 }

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

31 ● ゼロイチは任せない ○ ソフトウェア設計の深めの知見が必要なところは AI は苦手 ● AI に再現するための情報をファイル(①)に書き出させる ● ①を読み込ませながらコードを書かせる ○ ブラッシュアップを手動でやるか AI にやらせるかは都度判断 ○ ブラッシュアップした内容から①の更新要否を判断 ■ ①の更新を手動でやるか AI で行うかは都度判断 自分なりの AI 活用バイブル

Slide 32

Slide 32 text

32 ● 栄養失調にお気をつけください コードからしか得られない栄養はある

Slide 33

Slide 33 text

33 ● 理論から学べる ○ フレームワークとその活用方法の体得 ○ マネジメントスキルのティーチング能力向上 ● ケーススタディで実践できる ○ 思考の瞬発力アップ 対価:毎週10時間ぐらいを捧ぐ 成果:きっとこれから実感 ビジネススクールに通う

Slide 34

Slide 34 text

34 ● 組織も本人もまずはここに注力するべく尽力する ○ 組織は本人がバリューを発揮できるように支援する ○ 本人はバリューを発揮するために障害排除を求める ● 重要なのは、その人本来の強みを出すこと ○ 強みのない部分でのバリュー発揮は実感が伴わない ○ CTOとしてのバリューと思っているところとの合致が必要 ● すべての特効薬 ○ しかし最初はもっとも得難いものかもしれない ○ そのバリューに明確な定義はないのだから バリューを発揮する

Slide 35

Slide 35 text

時間を戻せるならやらないこと

Slide 36

Slide 36 text

36 ● 時間が足りない ○ 全員と会話したいのは本音 ○ 緊急性の考慮ができない ■ 「CTOと話したいけど1on1が3ヶ月後かぁ」 手当たり次第に1on1を企画

Slide 37

Slide 37 text

37 ● 課題解決思考を一度棚上げする ○ 「課題がきたから解決しなくちゃ!」は悪手 ■ 一呼吸置いて考える ○ ただ単に「誰がやるか」の定義のない仕事である可能性がある ■ ひとまず相談 CTOがやるっぽいことを率先してやる

Slide 38

Slide 38 text

さっさとやればよかったなぁ

Slide 39

Slide 39 text

39 ● 定例を並べて週に何時間ミーティングをしているかを可視化する ○ 「え? 週に◯時間もミーティング参加してるの!?」 ○ 「これ、整理したいんだけどアドバイスくれない?」って聞ける スケジュールのスプシ管理

Slide 40

Slide 40 text

40 ● 重要なのは as-is ○ 自然と開発組織の考え方や開発組織の課題をキャッチアップする ○ 分析、方針、行動指針の軸で考える ○ 方針がない=〇〇しないという戦略 エンジニアリング戦略の文書化

Slide 41

Slide 41 text

ここまでのことでわかること

Slide 42

Slide 42 text

42 ● 岡目八目 ○ 第三者のほうが的確に判断できる ■ その組織のコンテキストがある ■ 他者視点でのCTOへの期待値 定義がないことを自己解釈で定義するのが悪手

Slide 43

Slide 43 text

[CTOになった人/CTOを目指す人/CTOを迎え入れる人]たちに 必要なナレッジ

Slide 44

Slide 44 text

44 ● すべてを抱え込まない ○ 渡されたボールはあなたがもつべきでない可能性がある ■ 開発者のマインドだと課題解決思考になりがち ■ 全体感から対応すべきか移譲すべきかを考慮する ● 自分の得意苦手を可視化する ○ 採用観点では育成が難しい/機会がないスキルを求めるのが定石 ■ その苦手は育成可能なものか? ■ その苦手は自分がこなすことを求められているか? CTOになった人

Slide 45

Slide 45 text

45 ● 目指すCTOを定義する ○ 組織の規模やフェーズで千差万別 ○ 一般的に規模が大きくなればなるほどマネジメントの要素が強くなる ■ あなたの強みはどこにある? ■ あなたは何に楽しみを覚える? ■ あなたは何がしたい? ● リーダーシップとマネジメントは補完関係にあるが異なるもの ○ リーダーシップは変化に対処する力 ○ マネジメントは複雑な状況に対応する力 CTOを目指す人

Slide 46

Slide 46 text

46 ● 期待値を可視化する ○ 組織の思い、個人の思い、本人の思い、すべてちょっとズレてるはず ■ 我々は可視化しないとわかりあえない ● 本人のバリューを発揮できる場とプロセスを用意する ○ CTOに限らない話だが手掛ける範囲の関係上難しいテーマ ■ 取り組む範囲としてどうしても長期になりがち ■ 結果はかなりあとになる ○ バリューを発揮できても本人の自覚がないことがある ■ 強みのない(と思ってる)ところだとピンとこない CTOを迎え入れる人

Slide 47

Slide 47 text

47 ● 定義すること ○ 形にすること ■ 頭の中の定義は存在しないのと同じ ■ パロールとエクリチュールではエクリチュールが根源的 ○ そしてそれを互いに確認しあうこと ■ それは経営チームかもしれない ■ それは開発チームかもしれない ■ それは仲間かもしれない 定義のない仕事をこなすコツ

Slide 48

Slide 48 text

ここで一句

Slide 49

Slide 49 text

49 ! " # $ % 得 % ' ( 栄 養 代 , - . /

Slide 50

Slide 50 text

真面目な一句

Slide 51

Slide 51 text

51 霧 1 % 2 地 図 1 % 描 6 7 余 白 $ 1

Slide 52

Slide 52 text

52 余 白 : ; 筆 取 ( 仲 間 待 A B C ;