チームの開発スキルは現実の世界の変化に先行しなければばらない

チームの技術スキルは現実の世界の変 化より先行しなければならない

お前、誰よ？

このLTに至った経緯 増田さん(ドメイン駆動設計、アーキテクチャの達人)と市谷さん (仮説検証型アジャイルの達人)の対談の中での増田さんの言葉が 今日のLTのタイトルです。

この言葉を聞いて、どうしてもこの言葉でLTしてみた くなっちゃったんで話します。 本来、このタイトルで登壇が許されるのは、それこそ 増田さん、市谷さん、t_wadaさん、ミノ駆動さんのよ うなソフトウェア開発の達人の方々がするべきだと思 いますが、私が話します。 そして、そんな私の無謀な発表を許してくれる、「俺 の勉強会」の懐の深さに感謝です。

というわけで、本編に入ります

AIで“作れる”が増えた結果、運用と判断が 追いつかない。便利になったはずなのに、 なぜ現場は苦しいままなのか？

よくあるパターン① 開発の速度が上がるほど、運用・レビュー・意 思決定がボトルネックになる

よくあるパターン② 競合追従で変更が積み上がり、技術負債と 調整コストが増える

課題の本質 変化に対する追従では永遠に後手に回る

今日の提案 変化に先行できる「3層の技術スキル」を チームで手に入れる

なぜ追従が辛くなるのか？原因は“同じプロダ クトに複数の期待が同時に乗る”ことです

変化の根源はソフトウェアの「期待の多様さ」 ステークホルダー毎に期待することが異なる 経営者・・・事業成果、コスト削減、競合に対する優位性 利用者・・・便利な機能、使いやすさ、反応の早さ 開発者・・・保守性、拡張性、技術負債の返済 運用者・・・安定性、監視性、セキュリティ それぞれが「正しい期待」を持っていて、互いに矛盾する 期待が増えるほど“正解”は一つではなくなり、トレードオフ判 断と調整が増える。結果、優先順位が揺れて“変更”が常態化す る。

AIによって変化は加速する AIで「学習ループが回りすぎる」ことで変化が加速 • AIで作る→試す が速くなる（試作が増える） • 試せるから意見が増える（要望・改善点が増える） • 意見が増えるから仕様が揺れる（優先順位が動く） • 仕様が揺れるからまた試作（ループが加速） 変化が“イベント”じゃなく“平常運転”になる

変化とどう向き合うか？ 「変化」を避けるものとして受動的に捉えるとリスク になる。しかし「変化」を先に掴んで能動的に動けば、 チャンスに変えられる。

変化を先に掴むには？ 変化に先行できる技術スキルを身に着ける必要がある。

変化に先行するための３層の技術スキル キー概念 目的 必要スキル 観察・理解 ドメインリテラ シー 現実の変化を “技術以前” ドメイン分析力 の段階で正しく理解する システム思考 仮説検証力 観察・ヒアリング技術 設計・表現 モデリング能力 現実を抽象化し、変化を モデリングスキル(DDD) 吸収しやすい形に「モデ 抽象化・分割スキル ル化」する アーキテクチャ設計 パターン知識 実装・適応 適応能力 設計を現実に反映し、変 TDD 化を受け入れやすいコー CI/CD・自動テスト ドを保つ リファクタリング DevOps・IaC

この3層の技術スキルで欠けているもの があると現実の変化に対応できない

だから、個人ではなくチームで手に入れる

3層の技術スキルをチームで担う 担当・中心人物 役割 観察・理解 プロダクトマネジャー 現実世界の変化（市場・業務・顧客行動）を UXリサーチャー いち早く察知し、「何が・なぜ変わったのか」 ドメインエキスパート という問いに変換する 設計・表現 テックリード アーキテクト シニアエンジニア 現実の変化を設計上のモデルや責務分離に落 とし込み、ドメインモデルやサービス設計を 通じて、変化を局所化できる構造をつくる 実装・適応 開発エンジニア QAエンジニア DevOpsエンジニア 設計されたモデルを安全・迅速に実装・デプ ロイし、変更を安全に検証し、品質を担保す る

まとめ • 変化は期待の多様さから生まれ、AIで加速した • その変化を能動的に動けばチャンスにできる • そのためにチームで3層の技術スキルを身に着けよう

受け身の変化はリスク。しかし、チームで 取りに行けばチャンスになる。