はじめに
「AIがコードを書く時代、エンジニアの価値はどこにあるのか」
私は銀行のIT部門で部長をしており、開発現場へのAI導入を推進しております。AIツールを使えば使うほど、コーディング自体の価値が相対的に下がっていくのを肌で感じています。
「コーディングはAI。人間はアーキテクチャを担当する」
アーキテクチャの選択は状況に応じた判断が必要です。可用性を高めればコストが上がる。スケーラビリティを重視すれば複雑性が増す。このトレードオフを文脈に応じて判断する能力は、AIには代替できません。
そういった状況の中、週末のんびりアーキテクチャに関する本を読んでいて、アーキテクチャ・カタについて興味を持ちました。
アーキテクチャ・カタとは何か
あまり聞きなれない言葉かもしれません。「カタ（型）」は日本の武道から来ています。空手の型のように、決まった動きを繰り返し練習することで、実戦でも迷わず動けるようになる。ソフトウェアのアーキテクチャ・カタも同じ発想です。
Ted Newardというソフトウェアアーキテクトはこう問いかけています。
「優れたアーキテクトを育てたいなら、アーキテクトにアーキテクチャを設計させるしかない。しかしキャリアの中でアーキテクチャを設計する機会が6回にも満たないとしたら、どうやって腕を磨けばいいのか？」
医師は手術前にシミュレーターで練習します。パイロットはフライトシミュレーターで訓練します。でもエンジニアがアーキテクチャを練習する場はほとんどありませんでした。
アーキテクチャ・カタはこの問いに答えるために生まれた演習手法です。架空のプロジェクトを題材に、グループで設計判断を練習します。正解はなく、「なぜその判断をしたか」を説明できるかどうかが重要です。
O'Reillyも定期的にコンペを開催しており、ThoughtWorksも採用評価に使っているほど、海外では浸透しています。
私は今回これを新卒研修に取り入れようと考えました。
なぜ新卒研修に取り入れたかったか
うちのチームに入ってくる新卒は優秀です。情報系学部出身でコードも書けます。でも一つ気になることがありました。
「なぜその設計にしたのか」を説明できない。
実装は書けても、「なぜこのアーキテクチャを選んだか」「何を捨てたか」「どんなリスクがあるか」を言語化できない。これはコードが書けるかどうかとは別の能力です。
AIツールが普及するほど、この差が広がると思っています。AIはコードを生成できますが、「このシステムに今何が必要か」の判断はできません。その判断を担えるエンジニアを育てる必要があると感じ、「アーキテクチャ・カタ」アプリを作りました。
アプリの機能
アプリのURL：https://architecture-kata-public.vercel.app/
ワークの流れ
グループ（3〜5人）で以下のステップを進めます。
Step 1：メンバー名入力
参加コードでセッションに参加し、グループメンバーの名前を入力します。
Step 2：要件確認
お題に対して「確認したいこと」を質問形式で入力し、想定される回答も自分たちで書きます。本来のカタでは「顧客（モデレーター）に質問する」フェーズですが、「何を確認すべきか考える」こと自体が学習になるため、自己完結型にしました。
Step 3：アーキテクチャ特性を選ぶ
12種類の特性カードから最大3つを選び、優先順位と理由を入力します。選ばなかった特性とその理由（トレードオフ）も記録します。
可用性 / スケーラビリティ / パフォーマンス / セキュリティ /
保守性 / テスト容易性 / デプロイ容易性 / 信頼性 /
拡張性 / 監視容易性 / コスト効率 / 監査可能性
Step 4：システムコンポーネントを選ぶ
選んだ特性を実現するために必要なコンポーネントをカテゴリ別に選択します。
フロントエンド / バックエンド / データ管理 / インフラ / 外部連携
Step 5：確認・提出
入力内容を確認して提出。発表用サマリーが生成されます。
ファシリテーター機能
- セッション作成・参加コード発行
- グループの提出状況をリアルタイムで確認
- タイマー機能（フェーズごとの時間管理）
お題（現在5問）
| 難易度 | タイトル |
|---|---|
| easy | 社内昼食注文システム |
| medium | ECサイトのフラッシュセール |
| medium | デジタルバンクの送金機能 |
| hard | 病院の患者モニタリングシステム |
| hard | 全国規模の宅配追跡システム |
技術スタック
| 項目 | 技術 |
|---|---|
| フレームワーク | Next.js 14（App Router） |
| スタイリング | Tailwind CSS |
| データベース | Supabase（PostgreSQL） |
| ホスティング | Vercel |
| 言語 | TypeScript |
シンプルさを優先しました。認証なし・リアルタイムなし・AIなし。MVPとして動くものを最短で作ることを重視しています。
Claude Codeでの開発体験
このアプリはClaude Codeを使って開発しました。
開発の進め方は、機能ごとにMarkdownで指示書を作り、Claude Codeに渡すというスタイルです。DB設計・画面設計・実装手順をMDにまとめて「このとおりに実装してください」と指示するだけで、骨格は一気に動きました。
特に良かったのは複雑さのコントロールです。最初に作った指示書は8テーブル・7画面・認証あり・リアルタイムありの複雑な設計でした。「これは複雑すぎないか」と自問して4テーブル・5画面・認証なしに削ぎ落としてから指示を出したところ、2時間で動くものができました。
AIに指示する前に「何を作るか」を明確にする設計力が問われますが、まさにアーキテクチャ思考の実践でもありました。
作ってみて気づいたこと
アーキテクチャ・カタの認知度は日本でかなり低い
海外ではO'ReillyやThoughtWorksが積極的に活用していますが、日本語の記事はほぼありません。「アーキテクチャ・カタ」という言葉自体を知らないエンジニアが多いのが現状です。
「捨てた特性と理由」を書かせるのが一番効く
何を選んだかより、何を捨てたかを言語化させることでトレードオフの思考が鍛えられます。「なぜ可用性より保守性を優先したのか」を説明できるエンジニアは、設計の議論でも同じことができます。
正解がない問いに向き合う経験が少ない
新卒研修でありがちなのは「正解のある問題を解く」演習です。アーキテクチャ・カタは正解がなく、「説明できるかどうか」が評価基準になります。この経験が実務でのアーキテクチャ議論に直結します。
今後の予定
- アーキテクチャスタイルの選択（モノリス・マイクロサービスなど）
- モジュール設計方針の選択（結合度・凝集度の観点）
- Gemini APIによるAIフィードバック機能
- グループ間の回答比較画面
- ファシリテーターによるステップON/OFF機能
社内研修で使いながら改善を続け、いずれIT企業向けのSaaSとして展開したいと考えています。
おわりに
AIがコードを書く時代に、エンジニアの価値はどこにあるか。「トレードオフを判断し、説明できること」です。これはアーキテクチャ思考そのものです。
このアプリが、その力を鍛える場の一つになれば嬉しいです。フィードバックや「こんなお題が欲しい」というリクエストもお待ちしています。
👉 アプリはこちら：https://architecture-kata-public.vercel.app/
参考
- Architectural Katas（Ted Neward公式）
- Fundamentals of Software Architecture（Neal Ford・Mark Richards著、O'Reilly）