定義のない仕事 / 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/

Transcript

1. 定義のない仕事 nrs
2. 2 初代大吉祥寺.pmベストスピーカーです！
3. 2025年の今
4. 4 Profile nrs（成瀬 允宣） @nrslib コドモンのCTO 好きなアーキテクチャはMVPとCQRS+ESです 趣味：カンファレンス講演 学生支援 小学校支援 写真
5. 5 • 一般的なルートは？ ◦ プログラマ→紆余曲折マネジャーとかいろいろ→CTO ▪ このルートはスタートアップからいつのまにかなってたり • 私のルートは ◦ プログラマ→CTO ▪ Simple よくあるキャリアではあるけども……
6. 6 • 貴重な経験をしている ◦ コンテキストゼロからはじめるCTO ◦ 開発組織だけでも100名に届くかというところ • だれに？ ◦ CTOになった人 ◦ CTOを目指す人 ◦ CTOを迎える人 ◦ 定義のない仕事に立ち向かう人々＝人類！！ 「2025年の今」伝えたいこと
7. VUCAの時代だ！
8. 8 • V：Volatility（変動） • U：Uncertainty（不確実） • C：Complexity（複雑） • A：Ambiguity（曖昧） 定義がしづらい世の中だ
9. 9 • コードを書くことの相対的価値の低下 ◦ 情報の共有によりハードルの低下 ◦ AI 周辺技術やツールの目覚しい進化 • ビジネスサイクルの高速化 ◦ MVPを一週間で作れる時代 ◦ 保守性ではなく破棄性が求められる可能性 • ユーザーとの距離の短縮 ◦ 反応を見ながら価値を届ける これまで通りの仕事の仕方が通用しないかも
10. 10 • 定義のない仕事は誰にでも訪れる ◦ 訪れるパターン ▪ あいまいな依頼 ▪ 突発的な問題 ▪ 機会から始まる ▪ 定義がないことに気づいた ◦ 定義のない仕事に向き合う頻度とスピードは上がった ◦ 定義のある仕事の競争相手は AI そんな時代では
11. CTOの仕事って？
12. 12 • コードを ◦ 書く？ ◦ 書かない？ • 得意領域は ◦ 技術寄り？ ◦ マネジメント寄り？ • エディタは ◦ Vim？ ◦ Emacs？ あなたが思い浮かべたCTOは
13. 13 • どんなしごとをするかは以下の変数あたり ◦ 組織のフェーズ ◦ 組織の規模 ◦ 組織の課題 ◦ 事業特性 ◦ 経営チームの構成 CTOのしごとは千差万別
14. 14 • なわけない ◦ マネジメントは SIer 時代以来やってない ▪ リーダーシップとマネジメントは別物←！ ◦ 直近のロールはスタッフエンジニア ▪ 組織横断的な課題に明け暮れる毎日 ◦ 対するコドモンは300名を超える組織 ▪ 開発組織は100名に手が届くかぐらい ◦ CTO自体新設 ▪ つまり前例なし 順風満帆？
15. やってよかったこと
16. 16 • 初期はギャップに葛藤しがち ◦ 自分は貢献できていない（自分目線）と思いがち ◦ ひとつでもわかりやすいことをやれると安定する ◦ たとえば nrs の場合だと登壇 得意なことをインスタントにやる
17. 17 • 開発組織に受け入れられていると感じるならば見の姿勢をやめるときかも ◦ CTOとして迎え入れられたのは理由がある ◦ 必要以上に恐れなくていい ◦ むしろぶつかりあったほうがいいことも ▪ 雨降って地固まる ▪ 艱難汝を玉にす ▪ ： 見の姿勢をやめる
18. 18 • 開発メンバー ◦ オフィスアワー ◦ イベントストーミング • 開発メンバー以外 ◦ 業務のことを聞きに行く ▪ FS ▪ CSX ◦ CTOランチ ▪ #CTOは財布 対話する
19. 19 • 参加しなくていいものを相談しながら決めること ◦ 互いにどこまで関わるかが決まっていない ▪ レポートラインなので「とりあえず」のノリでインビテーション • 自分もわからないので言われるがままに参加 • いつの間にか身動き取れなくなる ◦ 中長期のことを考えるには時間が必要 ▪ 細切れ時間では何も考えられない ▪ 説明する資料作りも進まない スケジュールの整理
20. 20 • 互いの期待値のすり合わせ ◦ ドラッカー風エクササイズっぽいのを企画してくれた ◦ 知ってもらってるというのは重要 その一部→ 得意不得意の可視化
21. 21 • 精神が回復するんじゃぁ ◦ コードを書く＝活力 ◦ ペアプロで設計議論 ◦ イベントストーミング ▪ システム解像度アップ ▪ 同時にコミュニケーション 成果物の一部→ 現場で協働
22. 22 • 精神が回復するんじゃぁ・その２ ◦ 単純に貢献できることへの喜び ◦ サーヴァントスピリット • とはいえコードを愚直に書いてる暇はない ◦ バイブコーディング ▪ いい時代になりましたね ▪ 30分のミーティングを25分に ▪ 1時間のミーティングを55分に CEOの願いを叶える
23. 23 • ミーティングしながらコードが書ける ◦ 当初「美味しいところをAIにもってかれて、つまらないところだけ残 った」 ◦ 今「つまらないところをAIに渡して楽しいところやってる」 バイブコーディング最高
24. 24 ゼロイチは自分で
25. # EventStorming図からCQRS/Event Sourcingコード実装へのプロンプト ## 概要 このドキュメントは、EventStorming図を解析し、既存のCQRS/Event SourcingアーキテクチャパターンとAxon Frameworkを使用してコードを実装するための指示を定義します。 ## EventStorming要素の解釈ルール ### 1. イベント（オレンジ色の付箋） - **定義**: システムで発生した事実を過去形で表現 - **実装**: Axonのイベントクラスとして実装（CartEventインターフェースを実装） - **例**: 「カートに商品が追加された」→ CartItemAddedEvent クラス ### 2. コマンド（青色の付箋） - **定義**: システムに対する命令・意図 - **ルール**: コマンドが空白の場合、イベントの現在形をコマンドとする - **実装**: Axonのコマンドクラスとして実装（@TargetAggregateIdentifierを含む） - **例**: - 空白の場合: 「商品がカートに追加された」→「商品をカートに追加する」→ AddCartItemCommand - 「商品がカートから削除された」→「商品をカートから削除する」→ RemoveCartItemCommand
26. ## 実装手順 ### 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 # クエリサービス
27. ### 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リポジトリ
28. ### 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 }
31. 31 • ゼロイチは任せない ◦ ソフトウェア設計の深めの知見が必要なところは AI は苦手 • AI に再現するための情報をファイル（①）に書き出させる • ①を読み込ませながらコードを書かせる ◦ ブラッシュアップを手動でやるか AI にやらせるかは都度判断 ◦ ブラッシュアップした内容から①の更新要否を判断 ▪ ①の更新を手動でやるか AI で行うかは都度判断 自分なりの AI 活用バイブル
32. 32 • 栄養失調にお気をつけください コードからしか得られない栄養はある
33. 33 • 理論から学べる ◦ フレームワークとその活用方法の体得 ◦ マネジメントスキルのティーチング能力向上 • ケーススタディで実践できる ◦ 思考の瞬発力アップ 対価：毎週10時間ぐらいを捧ぐ 成果：きっとこれから実感 ビジネススクールに通う
34. 34 • 組織も本人もまずはここに注力するべく尽力する ◦ 組織は本人がバリューを発揮できるように支援する ◦ 本人はバリューを発揮するために障害排除を求める • 重要なのは、その人本来の強みを出すこと ◦ 強みのない部分でのバリュー発揮は実感が伴わない ◦ CTOとしてのバリューと思っているところとの合致が必要 • すべての特効薬 ◦ しかし最初はもっとも得難いものかもしれない ◦ そのバリューに明確な定義はないのだから バリューを発揮する
35. 時間を戻せるならやらないこと
36. 36 • 時間が足りない ◦ 全員と会話したいのは本音 ◦ 緊急性の考慮ができない ▪ 「CTOと話したいけど1on1が3ヶ月後かぁ」 手当たり次第に1on1を企画
37. 37 • 課題解決思考を一度棚上げする ◦ 「課題がきたから解決しなくちゃ！」は悪手 ▪ 一呼吸置いて考える ◦ ただ単に「誰がやるか」の定義のない仕事である可能性がある ▪ ひとまず相談 CTOがやるっぽいことを率先してやる
38. さっさとやればよかったなぁ
39. 39 • 定例を並べて週に何時間ミーティングをしているかを可視化する ◦ 「え？ 週に◯時間もミーティング参加してるの！？」 ◦ 「これ、整理したいんだけどアドバイスくれない？」って聞ける スケジュールのスプシ管理
40. 40 • 重要なのは as-is ◦ 自然と開発組織の考え方や開発組織の課題をキャッチアップする ◦ 分析、方針、行動指針の軸で考える ◦ 方針がない＝〇〇しないという戦略 エンジニアリング戦略の文書化
41. ここまでのことでわかること
42. 42 • 岡目八目 ◦ 第三者のほうが的確に判断できる ▪ その組織のコンテキストがある ▪ 他者視点でのCTOへの期待値 定義がないことを自己解釈で定義するのが悪手
43. [CTOになった人／CTOを目指す人／CTOを迎え入れる人]たちに 必要なナレッジ
44. 44 • すべてを抱え込まない ◦ 渡されたボールはあなたがもつべきでない可能性がある ▪ 開発者のマインドだと課題解決思考になりがち ▪ 全体感から対応すべきか移譲すべきかを考慮する • 自分の得意苦手を可視化する ◦ 採用観点では育成が難しい／機会がないスキルを求めるのが定石 ▪ その苦手は育成可能なものか？ ▪ その苦手は自分がこなすことを求められているか？ CTOになった人
45. 45 • 目指すCTOを定義する ◦ 組織の規模やフェーズで千差万別 ◦ 一般的に規模が大きくなればなるほどマネジメントの要素が強くなる ▪ あなたの強みはどこにある？ ▪ あなたは何に楽しみを覚える？ ▪ あなたは何がしたい？ • リーダーシップとマネジメントは補完関係にあるが異なるもの ◦ リーダーシップは変化に対処する力 ◦ マネジメントは複雑な状況に対応する力 CTOを目指す人
46. 46 • 期待値を可視化する ◦ 組織の思い、個人の思い、本人の思い、すべてちょっとズレてるはず ▪ 我々は可視化しないとわかりあえない • 本人のバリューを発揮できる場とプロセスを用意する ◦ CTOに限らない話だが手掛ける範囲の関係上難しいテーマ ▪ 取り組む範囲としてどうしても長期になりがち ▪ 結果はかなりあとになる ◦ バリューを発揮できても本人の自覚がないことがある ▪ 強みのない（と思ってる）ところだとピンとこない CTOを迎え入れる人
47. 47 • 定義すること ◦ 形にすること ▪ 頭の中の定義は存在しないのと同じ ▪ パロールとエクリチュールではエクリチュールが根源的 ◦ そしてそれを互いに確認しあうこと ▪ それは経営チームかもしれない ▪ それは開発チームかもしれない ▪ それは仲間かもしれない 定義のない仕事をこなすコツ
48. ここで一句
49. 49 ! " # $ % 得 % ' ( 栄 養 代 , - . /
50. 真面目な一句
51. 51 霧 1 % 2 地 図 1 % 描 6 7 余 白 $ 1
52. 52 余 白 : ; 筆 取 ( 仲 間 待 A B C ;