技術と合意形成、
両方に責任を持つ。

手が回らない改善を、自分で引き受ける

人手やスキルが足りず、負担が残っているのに改善に手をつけられない。そういう状況を見つけると、必要な仕事を自分で引き受けます。相手と話し合いながら、プロジェクトの進め方を整え、業務を支えるソフトウェアを実装する。二つの現場で続けてきたのは、その繰り返しです。「手を動かす」という価値観は、この繰り返しと重なります。

ツールを渡すだけでは届かない：相手の事情から考える

精和工業所では、利用者が自立して開発できるようにするという導入の狙いを、十分には実現できませんでした。適性や時間の制約もあり、ツールを渡せば誰もが使いこなせるわけではありません。

AIを日常的に使っている私自身にも、AIと会話しながら進める形にはいまだ馴染みにくさがあります。だからこそ、使わない人の姿勢だけに原因を求めず、何が妨げになっているのかを知るところから始めるようにしています。導入したものを使ってもらった後に、利用者の仕事の流れを聞き直すのもそのためです。「誰かをおとしめない」「分断を煽らない」という価値観は、この姿勢と重なります。

慣れた進め方では合意できない：情報を開き、進め方を見直す

PMとしては、自分が慣れた進め方に頼った結果、合意形成に失敗した経験があります。その後は、相手方PMと事前に進め方を合わせ、確認対象、未決事項、予定と実績を共有する方法へ改めました。関係者が同じ情報を見て、次の判断をできる状態をつくることを重視しています。

自分のやり方を正解と決めつけず、実際に起きたことから学び直す。判断の前提を共有し、相手と一緒に進め方をつくる。「オープンにする」「何事も決めつけない」という価値観は、この経験と重なります。

これまでの取り組みを、行政・政治の改善へ

正社員と副業のそれぞれで、自分が担ってきたミッションを果たしつつあると感じています。その中で、これまでの経験を活かして新たな道に進みたいという気持ちが芽生えました。もともと関心のあった行政・公共の領域で、困りごとを見つけ、自ら手を動かす姿勢を活かして働きたいと考えています。

テクノロジーによって政治を透明にし、人々が参加しやすくする。チームみらいが掲げるこの方向性を、私は、現場の改善を積み重ねて社会の仕組みを変えていく取り組みだと受け止めています。困りごとに気づいたところから、自分の手で改善を始める。その姿勢に、自分の仕事との接点を感じています。

募集をXで見てすぐに応募へ動き始めたのは、自分が気にし続けてきたことと、チームみらいの価値観がつながると感じたからです。PMとリードエンジニアとして培った、相手との合意形成を担い、自ら実装して改善を進める力で貢献したいと考えています。

Digeon：人手も型もない状態から、開発とプロジェクト運営の標準化を担う

参画した当初は、人手が足りず、日々の案件を進めるだけで手いっぱいの状況でした。プロジェクトの進め方も体系化しきれておらず、目の前の開発を担いながら、案件を継続して進められる仕組みを整える必要がありました。その状況を見過ごせず、PMとリードエンジニアの両方を担い、開発とプロジェクト運営の標準化に取り組んできました。

標準化した進め方の中身は、02 / オープン・コミュニケーションへ

精和工業所：担い手のいない改善を、副業として続ける

システムやソフトウェアに詳しい人が少なく、業務で使うソフトウェアの改善を進める担い手がいませんでした。負担が残っているのに、改善に手をつけられない。その状況も見過ごせず、正社員としての在籍後も、副業として支援を続けています。

手を動かした先で学んだこと

既存の基幹システムで扱えない工程管理を、RPAを使って自ら実装しました。管理工数は減らせた一方で、利用者が自立して開発できる状態をつくることはできませんでした。この経験が、上に書いた「相手の事情から考える」という姿勢の出発点になっています。

実装から工数削減までの詳細は、10 / 仮説検証の経験へ

共有するのは、合意・未決・予定と実績のずれ

合意事項、未決事項、予定と実績のずれを整理し、何が終わり、何が残り、どこに相談が必要なのかを、顧客と開発チームが同じ形で見られるようにします。

進め方そのものを、最初に合意する

キックオフ後に何をどのように進めるかは、キックオフの前に相手方PMと合意しておきます（プレキックオフ）。合わせるのは、ヒアリングすべきタイトルの全量と、確認セッションを組めるペースの2点です。要件定義の初期に現行業務の詳細は分かりませんが、何を確認する必要があるかの一覧なら、早い段階で顧客と合わせられるからです。

時間が足りない、日程を組めない、確認項目が増えた。こうした変化を、合意した対象・ペースとの差分として扱えるようにするための進め方です。

計画と実績を、同じ図で見続ける

計画を立てた後は、その全体像を共有し続ける必要があります。そこで、AsIsの確認、ToBeの検討、議論、合意といった大きな作業を、看板のように一覧できるアプローチ図にします。図には完了・予定・必達期限を追記し、定例で前週からの変化を確認します。経過した時間に対してどれだけ作業が残っているかを顧客と開発側が同じ図で確かめ、遅れや未決事項があれば、その場で次の動きや必要な判断を話し合います。

未知があることも、管理の前提にする

この方法は、まだ把握できていないことが後から明らかになる前提で組み立てています。まず双方が今決められる範囲を出し切り、確認対象・セッション計画・アプローチ図という管理できる形にする。そのうえで、実測や新たな発見に応じて更新していきます。

数百万円から億単位まで、規模を問わず合意形成を担ってきた

大小さまざまなプロジェクトを経験し、規模を問わず、一貫して顧客との合意形成とプロジェクトマネジメントを担ってきました。自ら開発する比重は案件によって変わりますが、関係者と認識をそろえ、プロジェクトを前に進める役割は変わりません。

失敗した案件：アジャイル的な進め方のまま、ウォーターフォール型の契約に臨んだ

この進め方が定まるまでには、失敗した案件があります。それ以前の私は、アジャイル的に動きながら要件を具体化していく進め方を多く採っていました。ところが、ウォーターフォール型の契約を前提とする案件では、顧客が判断・合意するための説明や筋道を十分に整えられず、合意形成に失敗しました。

次の案件から：確認対象を合意し、実測から計画をつくる

次の案件からは、プレキックオフで確認対象の全量とセッションのペースを合意し、次の3ステップで計画を組み立てて、アプローチ図で共有しながら進めるようにしました。

1. 対象を揃える。 ヒアリングすべきタイトルを一覧にし、確認する範囲を顧客と合意する。
2. ボリュームを測る。 セッションを実施し、1項目にかかる時間や確認量を把握する。
3. 先を予測する。 残項目のボリュームとセッションを組めるペースから、今後の進捗を見積もり、計画と優先順位を組み立てる。

結果：経験の浅いPMも、根拠を持って交渉できるようになった

AIによって実装は進めやすくなりましたが、認識のずれや調整の難しさが表れるのは、今も要件定義だと感じています。AsIsの全量とアプローチ図を運用することで、この時期に何が決まり、何が残り、どこに調整が必要かを、見通しよく共有できるようになりました。

特に大きかったのは、経験の浅いPMが相手の要求をそのまま受け入れてしまう場面が、ほとんど見られなくなったことです。会話の材料が整理されていれば、その要求が既存の合意や計画にどう影響するかを示し、何を調整すべきかを話し合えます。個人の交渉経験に頼る部分を減らし、共有した情報を根拠に対話できる状態をつくりました。

接続権限と人員配置を踏まえ、インフラ構築も引き受ける

外部エンジニアと進める案件では、顧客インフラへの接続を原則として正社員に限定していました。他の正社員が別案件を担当している時期には、私がインフラの設計・構築を引き受けることが多くありました。

担当者の途中離脱で残った仕事を引き継ぐ

動画解析アプリケーションの開発では、担当者の途中離脱で残ったコアロジックとインフラを引き継ぎ、納品まで進めました。

引き継ぎから納品までの詳細は、11 / ラストマンシップへ

増員できない制約の中で、実現手段まで自分で用意する

予算の制約から人を増やせない状況で、顧客が求めるUXを従来の開発方法で実現するには人手が足りませんでした。そこで自らモックアップとPoCを作り、実現できると判断したうえで顧客に提案し、本番リリースまで進めています。足りないのが人手だと分かっている状況で、待つのではなく、実現できる手段のほうを自分で用意しました。

PoCから提案・実装までの詳細は、08 / 越境した職務経験へ

失敗と評価した取り組みを、立場が変わっても直し続ける

精和工業所でのi-Reporterの導入は、一定の利用水準までは引き上げたものの、全体としては失敗だったと捉えています。正社員としての在籍を終えた後も、副業として業務アプリの開発を支援し、全面的な置き換えまで進めました。自分が失敗と評価した結果に対して、立場が変わっても手を引かずに向き合っています。

置き換えの進め方は、10 / 仮説検証の経験へ

設計と納品に責任を持つから、技術を学ぶ

これまで、PMとしてプロジェクトを進めると同時に、リードエンジニアとしてシステムの設計にも責任を負ってきました。納品するシステムに責任を持つ以上、技術的な判断の根拠や、問題が起きる仕組みを自分自身で理解する必要があります。そのため、案件で必要になった技術はその都度学び、設計や実装の判断に結びつけてきました。

解決すべき問題から入り、その手段を学ぶ

先に学びたい技術があるわけではありません。解決しなければならない問題がまずあり、その手段として必要な技術を学んでいくスタイルがほとんどです。日頃も、個人で開発しているアプリのアーキテクチャやBeyondCorpの導入設計など、目の前の課題を起点に、AIとの壁打ちを通じて理解を深めています。

政治・政策も、同じように深める

政治・政策の知識は、これから深めていく段階です。国会答弁や討論番組、チームみらいの動画などを通じて論点に触れながら学んでいます。この領域でも、担当する問題を解くために必要な知識の補充に責任を持ち、判断と行動に必要なところまで理解を深めます。

得意でなかったアルゴリズムとインフラを引き継ぎ、納品する

動画解析アプリケーションの開発で、不具合の残るコアロジックとインフラを引き継いだときも、当時は得意分野ではなかったアルゴリズムやインフラを、AIを活用しながら学び直して納品まで進めました。知識が足りないところから始めても、理解を深めて実際の問題に対処しきる。その姿勢が表れた経験です。

引き継ぎの経緯は、11 / ラストマンシップへ

モデルの進化に合わせて、確認方法そのものを学び直す

AIを使った開発では、モデルが進化して任せられる範囲が広がるたびに、確認方法そのものを学び直し、設計規則とCIへ落とし込んできました。

設計規則とCIの詳細は、13 / 生成AIを活用した開発へ

役割の割り振りだけでは、埋まらない部分が残る

さまざまな背景や強みを持つメンバーと仕事をする中で、チームの能力のバランスは案件ごとに大きく変わってきました。成功に必要な力が欠けていれば、その不足を残したままにはできません。一方で、一人ひとりに得意なことや適性があり、役割を割り振り直すだけですべてを補えるわけでもありません。

自分が水になり、そのとき最も価値のある役割を担う

そこで私は、自分が水になるように動いてきました。岩、石、砂が詰まった箱に注ぐ水のように、メンバーの強みを活かしたうえで残る隙間を、自分が形を変えて埋める。その時々でチームが必要としている役割を担うことが、自分にできる最大の付加価値だと思っています。

そのとき最も価値を発揮できる役割を担えることには、自然と喜びを感じます。だから、PM、設計、実装のどこに力を注ぐかを案件ごとに変え、チームに足りない役割を自分が引き受けてきました。

習熟度を踏まえ、開発の途中で役割を組み直す

PMと開発のどちらに比重を置くかは、チームの構成に応じて変えています。外部エンジニアと進めた案件では、開発が進むにつれ、使用言語への習熟度を踏まえて役割を組み直す必要が出てきました。

その方は自社開発のデータ分析プロダクトの出身で、腰を据えて設計し、じっくり開発を進める仕事に向いていました。そこで、コアロジックの設計とSQLを中心とする開発を担当してもらいました。一方、マスタ管理のように実装方針がすでに決まっている基本機能は、その方に新たな学習コストをかけてもらうより、慣れている私が素早く実装する方が早いと判断しました。

残る実装は自分が引き受け、完成まで進める

私はマスタ管理基盤とUI/UX全般を担い、この分担で完成まで進めました。すでに持っている強みを活かせる仕事と、習熟しているから速く進められる仕事を分ける。そうやってチーム全体で完成までの道筋を組み立てています。

3人を中心とする体制で、複数案件を回す

Digeon参画当初は、社長・CTO・私の3人を中心に、外注やアルバイトのメンバーと仕事を進める体制でした。複数案件への人員配置を考えながら、自分自身もマネジメントと開発のどちらに比重を置くかを調整し、受託開発を担ってきました。

案件ごとの学びを、PMの型として整理する

その中で取り組んだのが、PMの進め方の標準化です。案件規模や顧客の違い、そして合意形成に失敗した経験から得た学びを、プレキックオフ、AsIsの全量管理、アプローチ図の運用といった型に整理してきました。

標準化した進め方の中身は、02 / オープン・コミュニケーションへ

一貫して担当した案件

2022年9月〜2023年1月の案件ではデザイン以外のすべてを一貫して担い、外部エンジニアと分担を組み直した案件では、マスタ管理基盤とUI/UX全般を自ら実装しました。

分担を組み替えた事例は、05 / 柔軟性へ

画面からデータのライフサイクルまで

実装してきた範囲は、基本的な登録・参照・更新・削除の画面とAPIから、監査帳票向けの大規模なSQLまでに及びます。例えば基幹システムの開発では、業務上の事象から売上データを生成し、入金管理に至るまで、業務データのライフサイクル全体を扱う実装と、それを支えるDB設計を担いました。

AWS上の実行環境まで

インフラでは、AWSのECS・RDS・S3・CloudFrontを組み合わせ、APIとSPAで構成する環境を構築しています。

規模に応じて、担当の比重を変える

約300万円規模では、顧客折衝から開発までを一人で完了しました。数千万円規模を含むチーム開発では、メンバーの適性に応じて役割を組み替えながら、自らも実装を担いました。約2億円規模では、技術面の責任を持ちつつ、顧客との合意形成により大きな比重を置いています。規模が変わるたびに、必要な説明や合意のつくり方を学び、進め方を更新してきました。

役割を組み替えて完成させた事例は、05 / 柔軟性へ

2〜8名のチームで、設計の肝と顧客折衝を担う

チームは案件により2〜8名で、人数が多い場合はアルバイトを含むこともありました。私は一貫してPM兼リードエンジニアを務め、設計の中核はほぼ必ず自分で担当しています。そのうえで直接手を動かす範囲は案件によって異なり、バックエンドの設計・コーディングから、インフラの設計・構築にまで及びます。

顧客折衝の約9割は自ら担い、仕様の相談、問題のヒアリング、スケジュール調整、要求のすり合わせを行ってきました。

増員できない条件で、AIによる実現可能性を検証して提案する

当時最大規模の案件を含む3案件を並行していた時期は、予算の制約から人を増やせない状況でした。一方で、顧客が求めるUXを従来の開発方法で実現するには、明らかに人手が足りませんでした。

そこで、運転手・車両・積荷注文をドラッグ＆ドロップで操作できるモックアップをFigma Makeで作成し、CodexのWeb版でAPI連携と改善まで進められることを確認しました。数時間のPoCで、求められたUXにフロントエンドの技術的なボトルネックはないと判断し、そのモックをそのまま顧客に提案しました。事前に聞いていた顧客のイメージとも合致し、実装を進めて本番リリースまで到達しています。

設計の大部分を自ら担っていたため、その意図を実装へ直接つなげられました。AIを活用しながら開発を進め、3案件の並行開発を乗り切っています。

AIを開発に組み込んだ経緯は、13 / 生成AIを活用した開発へ

案件を回しながら、その外側にも手を入れる

自分の受託プロジェクトを遂行することが、まず第一にありました。ただ、案件を回すだけでは、次の案件が同じ苦労を繰り返します。進め方が体系化されていない、人が足りない、使い回せる部品がない。そうした課題は案件の外側にあり、担う人もいませんでした。

進め方を残す：標準ドキュメントと、AIエージェントのSkill

案件ごとの学びを、その場限りにせず標準ドキュメントへ整備しました。さらに、同じ内容をAIエージェントに渡すSkillとしても用意しています。人が読んでたどれるだけでなく、AIにも同じ進め方を再現させるためです。

標準化した進め方の中身は、02 / オープン・コミュニケーションへ

体制をつくる：採用、予算管理、フリーランスの調達

正社員の採用活動、予算の管理、フリーランスの調達も担いました。人が足りないという課題に対して、開発で埋めるだけでなく、体制そのものを用意する側にも回っています。

つくる範囲を広げる：デザインから、コンポーネントとアーキテクチャまで

アプリケーションのデザイン、「積み木」と呼ぶコンポーネント群、バックエンドアーキテクチャの整備も引き受けました。案件ごとに一から作らず、次の案件が速く進む土台を残すための仕事です。

アーキテクチャと設計規則の詳細は、13 / 生成AIを活用した開発へ

ここで挙げた仕事の多くは、他の項目で具体的に書いています。

• PMの進め方の標準化：プレキックオフ、AsIsの全量管理、アプローチ図の運用 → 02 / オープン・コミュニケーション、06 / 実務経験
• バックエンドアーキテクチャと設計規則：domain・interactorの書き方と、それを保つ固有のCI → 13 / 生成AIを活用した開発
• チームの隙間に残る仕事：インフラの設計・構築や、途中離脱で残ったコアロジックの引き継ぎ → 03 / オーナーシップ、11 / ラストマンシップ
• 現場の業務そのものの改善：汎用フォームとRPAによる工程管理ツール → 10 / 仮説検証の経験

仮説：使うこと自体が難しく、基礎知識がない限りスケールしない

i-Reporterは一定の利用水準まで引き上げたものの、全体としては失敗だったと私は捉えています。利用者の動きを見て分かったのは、アプリケーションを利用すること自体の難しさでした。ソフトウェアの基礎知識がない限り、現場に広げてもスケールしない。そう考えたことが出発点です。

RPAを導入したときに、教育を通じて利用者自身が開発できる状態をつくれなかったことも、この見方につながっています。

解決案1：必要最低限だけ、汎用に実装する

汎用フォームは、入力と承認という最小の単位だけを汎用に実装しました。あらかじめ想定を広げて作り込むのではなく、まず現場で使える最小の形を出し、そこから個別の要件を見つけていく進め方です。

解決案2：利用結果をサポートし、業務フローの実態を俯瞰する

作って渡して終わりにはしません。使われた結果をサポートし、フォームの外側にどんな作業が残っているのかを見ます。業務フロー全体の実態を俯瞰したうえで、エンジニアリングで手を入れる範囲を決めます。

検証の結果：運用とアイディアが続いている

この2つを続けた結果、今も新しいフォームの運用が実施され、拡張するエンジニアリングのアイディアが尽きない流れになっています。

備品発注フォーム：相談から1週間で実装する

出発点は、備品発注フォームを作りたいという具体的な相談でした。ただ、今後ほかの業務でも入力と承認の仕組みが必要になると見込み、単発のフォームではなく、共通利用できるフリーフォーム機能として設計・実装しました。相談から実装までは1週間です。

入力と承認を抽象化した機能を使って、紙で回していた備品発注をフォームに置き換えました。当初の要望は満たし、利用者からも好意的な反応をもらいました。

導入後の仕事の順序を、あらためて聞き直す

そのうえで、導入後の仕事が実際にどんな順序になったのかをヒアリングしました。そこで分かったのは、発注対象が基幹システムのマスタで管理されていること、そして承認後の発注情報を基幹システムへ手入力する作業が残っていることでした。フォームを入れても、その外側には手つかずの仕事が残っていたのです。

前後の作業も含めて作り直し、手入力をなくす

前後の作業も含めた改善を再提案し、備品発注に特化したフォームとして実装し直しました。結果として、基幹システムへの発注データの手入力もなくなりました。まず1週間で相談に応える仕組みをつくり、使われ方を聞き直して次の改善につなげる。この2段階で、現場に合う形へ寄せていきました。

工程管理ツール：基幹システムに載らない業務を、RPAで実装する

リードタイムの短い製品には、基幹システムに載せられない工程管理が残っていました。管理者が手作業のExcelで回していた業務です。私はRPAをローコード開発ツールとして使い、Excel上の作業からその後のデータ管理までを1つにまとめた工程管理ツールを実装しました。

製品選定から、自分で実装まで

Automation Anywhereの選定は一人で担当しました。当時発売されたWeb版のオーケストレーターと、3台まで同一金額で利用できる契約条件に着目し、実行環境がPCに依存する他の候補製品と比較して、費用対効果の高い選択肢だと判断しました。

現場で起きた変化

手作業のExcel運用にかかる管理工数を、1日あたり約4時間削減しました。 あわせて、管理者が一人で22時まで残業していた状態から、17時の定時に退社できるようになったという変化もありました。

業務改善と、利用者の自立には別の難しさがあった

自分が実装することで管理工数は減らせました。一方、教育を通じて利用者自身が開発できる状態をつくることは、うまくいきませんでした。ローコードであっても、処理を考え、組み立てるというプログラミングの本質は残ります。適性や学習に使える時間などの条件によっては、自立した開発が成り立たない場合がある。そう学んだ経験です。

2名の離脱で残った仕事を、そのまま引き継ぐ

私はもともと、アプリケーション部分の担当でした。プロジェクトの途中で、私以外の正社員2名が離れることになり、不具合の残るコアロジックとインフラも私が引き継ぎました。

得意でなかった領域を、AIを使って納品まで進める

当時の私は、アルゴリズムもインフラも得意分野ではありませんでした。それでも、o3を活用しながら未知の技術的課題に向き合い、納品まで進めています。当時のAIの進歩に助けられた面は大きいと思っていますが、自分の担当範囲にとどまらず、残った仕事を引き受けて完了させた経験です。

責任を果たして、次の仕事へ進む

今回の転職も、いま担っている責任を果たす見通しが立ちつつあることが、応募に動き始めた理由の一つです。

業務の意味と実装が一致するかは、人が見届ける

生成AIでコードを書くことが容易になっても、日本語で説明した業務ルールが実際にはどの条件や処理になっているのかは、設計者が自分の目で確かめる必要があります。重要な機能には、その対応を確かめるべきコードが必ずあります。

読む量ではなく、読む場所を決める

読む量を増やす方向では、AIが生成するコードの量に追いつけません。そこで「読む量を増やす」のではなく、読むべき場所を決めて、そこだけは必ず読める状態を保つ方向で設計しました。

domainで判断を、interactorで手順を読む

GoのクリーンアーキテクチャとDDDを土台に、業務知識の置き場所と書き方を厳密に定めました。domain層へ知識・制約・判断を集め、interactor層にはユースケースの手順を記述する方針です。

interactorで処理の順序と呼び出される業務判断を追い、その判断の中身はdomainで確認する。外部I/Oや入力変換の細部に埋もれることなく、業務の意味をこの2層だけで読み取れるようにしています。目指したのは、コードをそのまま業務のドキュメントとしても読める状態です。

この読み方を維持するために、命名、分岐、入力境界、呼び出し方までを規則にし、固有のCIへ落とし込みました。CIで規則への適合を検査し、人は業務ルール自体が正しいかを読み、動作確認で実際の振る舞いを確かめる。それぞれが何を担保するのかを分けておくことで、AIが実装したコードでも設計意図との対応を追えるようにしています。

最適化してきたのは、書く速さではなく読む過程

私が最適化してきたのは、AIがコードを書く速さではなく、重要なコードを人が読み、判断する過程です。

設計の背景は、2026年2月に公開したGo・DDD・クリーンアーキテクチャについての記事でも説明しています。執筆当時のAI（GPT-5.2）を使って書いたもので、読みにくい箇所が残っている点はご容赦ください。記事の公開後、入力境界やinteractorの可読性については、さらに細かな規則とCIへ落とし込んでいます。

PoCから実装まで、AIを開発の実務に組み込む

3案件を並行していた時期には、Figma Makeでモックを作り、CodexのWeb版と組み合わせて実現可能性を検証しました。自ら設計した内容をそのまま実装へつなぎ、増員が難しい状況で開発を進めています。未知の技術領域を引き継いだ別案件では、o3を活用して納品まで到達しました。

この時期は、5月から翌年1月にかけて、自分一人で月あたり約300件、通算で3,000件規模のPRを作成しています。いずれも当時の概数です。

3案件を並行した経緯は、08 / 越境した職務経験へ

AIの進化に合わせて、確認方法も変えてきた

AIへの任せ方を広げるのに合わせて、確認方法も段階的に変えてきました。コードを読む範囲、設計の詳しさ、自動テスト、別のAIによるレビューと操作確認。この組み合わせを、新しいモデルが出るたびに組み替えています。

初期：難しいReactコンポーネントを、全コードレビューで確かめる

実装難度の高いReactコンポーネントをAIに実装させ、生成されたコードをすべて読み、妥当性を自分で評価しました。

中期：厳密な設計とレビューに、DBを通した自動テストを加える

設計を人が厳密に行い、AIのコーディング結果も厳密にレビューしました。さらに、DBまで通して確認する自動テストを導入し、コードの読み取りに加えて動作を検証するようにしました。

後期：重要なコードに読む範囲を絞り、別のAIでも確認する

設計の記述を簡略化する一方、重要なコードの可読性を保つCIを設け、人が読む範囲を絞りました。また、実装時のコンテキストを減らした別のAIにレビューや動作確認を任せるようにしました。

現在：実装の経緯を渡さず、業務シナリオから操作させる

現在は、実装時のコンテキストを渡していない別のAIエージェント（Astra）に業務上のシナリオだけを伝え、システムを実際に操作させています。網羅性と厳密性に注意するよう指示したうえで、その操作の様子は自分で見続けます。AIが明らかに迷ったところにだけ、必要な情報を補います。

業務シナリオによる操作確認に加えて、DBまで通す自動テストと、重要なdomain・interactorのコード確認も続けています。AIへの任せ方が変わっても、この3つは併用したままです。自動テストをいつ作成し、いつ実行するかは、今も運用を検討している段階です。

読み方を保つため、書き方をCIで検査する

domainとinteractorの読み方を継続して保つため、次の規則を固有のCIへ落とし込んでいます。

• 業務判断をdomainに集める。 知識を表す純粋関数と、可否・整合性を判定するpolicyを配置。外部I/Oを分離し、時刻などの環境依存値は引数で渡す。
• interactorでは、意味のある手順を読む。 業務分岐は名前付きのDecisionを介し、汎用的な動詞を避けて業務目的が分かる名前を付ける。値を返す呼び出しは意味の分かる変数で受け、使用箇所の近くに置く。
• 入力の解釈と制約をdomainの境界に閉じ込める。 interactorでのJSON復元・時刻の解釈・Value Objectの直接生成を制限し、用途の分かるdomain関数に集約する。
• 規則を自動検査につなげる。 interactorの構造・呼び出し・domain境界・可読性、repositoryの入力境界などをCIで検査。可読性の既存違反は記録し、新規・増加を検出しながら段階的に減らす仕組みを設ける。

// 更新処理の一部：業務固有の名称を一般化し、前後の処理を省略
if policyErr := record.EnsureTargetKind(current); policyErr != nil {
    return nil, policyErr
}
if policyErr := recordupdate.EnsureExpectedVersion(current, selector); policyErr != nil {
    return nil, policyErr
}
if policyErr := record.EnsureVersionEditable(current); policyErr != nil {
    return nil, policyErr
}

// domain：名称を一般化した掲載用の抜粋
func EnsureVersionEditable(header RecordHeader) error {
    if header.Status.Value() != recordvalue.StatusUnsubmitted {
        return ErrNotEditable
    }
    return nil
}