構想、要件定義、PoC、実装、運用まで
一気通貫で支援します。
強みは、クライアントの課題を聞き取り、業務の流れを整理し、必要な機能へ分解し、実際に動くシステムとして完成させられることです。AIを活用しながら、企画や要件をドキュメント化し、タスクに分解し、コードへ落とし込み、実装結果を再びドキュメントへ還元します。
AI-DDDの開発プロセス詳細
ヒアリングから要件定義まで、各工程でAIとドキュメントを活用しながら開発を前へ進めます。
ヒアリング 60〜90分
会話を録音させていただきます。AI議事録と構造化データとして保存します。
開発環境構築 1分
プロジェクトディレクトリの作成。VS Code上で、CodexとClaude Codeを使ったドキュメント作成ができる準備をします。
要求整理 30分
字おこしした議事録をもとに、NotebookLMでデータを構造化します。全体のスライド、議事録としての再生成、論点ごとのレポート、インフォグラフィックを生成し、要求へ整理します。スライドやインフォグラフィックは認識あわせとして利用します。
要件定義 第一版作成 2時間
要求を実現するために必要となるシステム構成を考慮しながら機能要件だけでなく、さまざまな視点でドキュメントを作成します。
要件定義が終わった時点で、PoC開発、MVP開発、フェーズNの開発計画ができている状態を目指します。
実例:ec-plus1プロジェクトのドキュメント一覧
| ドキュメント名 | ファイル |
|---|---|
| ドキュメント一覧 | docs/README.md |
| プロダクト概要 | docs/product-overview.md |
| ECサイトとフリマサイトの差分整理 | docs/ec-vs-flea-market-spec.md |
| 機能一覧 | docs/feature-list.md |
| MVPタスク一覧と実行計画 | docs/mvp-task-plan.md |
| Post-MVP計画 | docs/post-mvp-plan.md |
| 画面 / 導線仕様 | docs/screen-flow-spec.md |
| ヘルプ仕様 | docs/help-spec.md |
| ヘルプ記事下書き | docs/help-article-drafts.md |
| 権限仕様 | docs/authorization-spec.md |
| 注文 / 決済フロー仕様 | docs/order-payment-spec.md |
| 結合テスト仕様 | docs/integration-test-spec.md |
| 運用手順 | docs/operations-runbook.md |
| 商品モデル定義 | docs/product-model-spec.md |
| 売上・入金運用仕様 | docs/sales-operations-spec.md |
| 監査ログ仕様 | docs/audit-log-spec.md |
| 非機能要件 | docs/non-functional-requirements.md |
| データアーキテクチャ設計 | docs/data-architecture-spec.md |
| 外部連携仕様 | docs/integration-spec.md |
| テスト方針 | docs/test-strategy.md |
| リリース手順 | docs/release-checklist.md |
| ルーティング責任マップ | docs/routing-responsibility-map.md |
| 次フェーズ設計方針 | docs/next-phase-design-spec.md |
| デプロイ / インフラ設計書 | docs/deployment-spec.md |
| 監視アラート定義書 | docs/monitoring-spec.md |
| データ移行手順書 | docs/data-migration-guide.md |
| 新業種サイト セットアップガイド | docs/new-site-setup.md |
| 未実装領域のクリティカル分析 | docs/unimplemented-critical-analysis.md |
| 残存課題および次フェーズ検討事項集約レポート | docs/remaining-issues-next-phase-report.md |
| 次フェーズ実装バックログ | docs/next-phase-backlog.md |
| GitHub Issue 草案 | docs/github-issue-seeds.md |
| GitHub Epic 草案 | docs/github-epic-seeds.md |
| チケット管理運用ガイド | docs/ticket-management-policy.md |
| GitHub Projects カラム設計 | docs/github-projects-configuration.md |
| GitHub Projects 初期投入計画 | docs/github-projects-seeding-plan.md |
| GitHub運用のあるべき姿 | docs/github-operating-model.md |
| ec-plus1 戦略チェックリスト 2026 | docs/ec-strategy-checklist-2026.md |
設計 2時間
要件を元に、データ構造の設計、全体の共通部分の切り分けなど、機能一覧・画面一覧・共通API・データベース構造などに物理的に分けられるように設計します。
データ構造の設計
- どんなテーブルが必要か(例:users, orders, products)
- テーブル同士の関係(1対多、多対多など)
- 各カラムの型・制約
画面・機能の切り分け
- どの画面が存在するか一覧にする
- 画面ごとにどのAPIが必要かを決める
- 管理画面・フロント・APIなど物理的な分離
共通部分の特定
- 認証・権限まわりはどこで管理するか
- 複数機能で使い回せるコンポーネントは何か
- ミドルウェアやサービス層に何を置くか
コードを書く前に、何をどこに置くかを決める作業です。これをやらないと、実装が進むにつれて矛盾や重複が出てきます。
開発環境構築2 15分
Dockerコンテナ / Git / GitHub連携を構築します。
GitHub Issue登録 5分
いよいよコード生成。そのまえに、要件をタスクとしてIssueに分解し、GitHubへ登録してもらいます。実装はIssue単位で進めます。
プログラム開発 プロジェクトの工数により異なる
Claude Code・Codex を使い分けてプログラムコードを生成します。Issue単位にプログラム作成・ユニットテストまでを実施します。
動作確認によるバグ修正
できあがった部分から動作確認をしながら、問題があればPRとして登録します。
ドキュメント反映
1日の最後に、修正を反映したうえで問題なければ、修正内容をすべてドキュメントへ反映してもらいます。READMEへの進捗更新、各ドキュメントの変更点など、常に最新の状態を維持します。
日々のルーティン
「今の状況を教えて」と聞くと、ドキュメントの進捗・直近のcommit/push・Issueの解決状況などを報告してくれます。そして「次はこのタスクをやるのがおすすめです」と提案してくれます。それに対して「はい」と答えるだけで開発が前へ進みます。
得意なこと
単なる開発担当ではなく、課題解決人として、課題整理から実装・運用までをつなぐ実務型の開発支援を行うことができます。いかにして実現するかを考え抜きます。
要件定義・業務整理
漠然とした相談であっても、現在の状況をもとに業務フロー、画面、データ、機能単位へ整理します。
PoC推進
コンテナ環境で小さく試して、実現性・効果・課題を早期に確認します。特にローカルAIの検証や、AIに関わる実装技術、PostgreSQLを使ったpgvectorでのベクトル意味の近似値検証などを得意としています。
実装力
サーバサイドはLaravelを中心に、管理機能やAPI提供を担います。フロントは簡易的な画面であればBladeですが、機能的要件が高い場合にはReact・React/Next.js・Vue.jsなどのフロントエンド開発実装も可能です。サーバ構築からアプリケーションまで実装します。
AI活用
Claude・ChatGPT・Geminiなどの生成AIを、開発・業務改善・文書解析・設計支援に実践的に組み込みます。AIに何ができるかではなく、どう使えば現場で動くかを軸に実装します。ローカルLLMの構築から、RAG・ベクトル検索・プロンプト設計まで、AI活用の実務経験が強みです。
AIネイティブ・ドキュメント駆動開発
AI-DDD
AIを活用し、要件定義・設計・実装・運用を分断せず、一つの循環として回す開発プロセスです。打ち合わせ内容や既存ドキュメントを構造化し、仕様・タスク・コードへ変換。さらに実装結果をドキュメントへ還元し、常に最新の状態を維持します。
抽出・蒸留
議事録、要望、既存資料を整理し、開発に使える構造化ドキュメントへ変換します。
研磨・分解
AIとの対話で仕様の矛盾や抜けを洗い出し、GitHub Issueなどの実装タスクへ分解します。
自律実装・検証
Claude Code、Docker、テスト環境を活用し、実装と検証を繰り返して品質を高めます。
AIには、コードを生成してもらうだけでなく、
テスト検証、ドキュメント反映を徹底する。
開発を常に前へ進められる状態をつくる。
コード生成
要件・仕様をもとにAIが実装を担当。人間は判断と設計に集中します。
テスト検証
生成したコードをAIが自律的に検証。不整合や抜けを早期に発見します。
ドキュメント反映
実装結果をドキュメントへ還元。次の開発が常に最新の情報から始まります。
よくある質問
PoC(Proof of Concept)は「これは実現できるか?」を確かめるものです。精度・技術的な実現性・業務への組み込み可能性を小さく試します。捨てることが前提です。
MVP(Minimum Viable Product)は「最小限でも実際に使えるプロダクト」を作るものです。ユーザーに届けてフィードバックを得ることが目的で、捨てません。
開発の流れとしては、PoCで実現性を確認してからMVPを作るという順番が自然です。
PoCとは、本開発前に小さく試す検証フェーズです。
Proof of Conceptの略で、「本当に実現できるか」「効果が出そうか」を小さく確認するための取り組みです。
いきなり大きく開発するのではなく、最小限のデータ・画面・機能で実現性を確認します。
PoCで確認すること
PoCの目的は、作り込むことではありません。本開発へ進めるべきかを判断するための材料を作ることです。
PoCの具体例
PDF議事録解析AI
PDF数本を対象に、発言者・課題・答弁・成果を抽出できるか検証します。
社内文書検索AI
既存資料を取り込み、質問に対して正しい根拠付き回答が返せるか確認します。
業務システム試作
登録・検索・一覧・詳細など、業務フローの一部だけを先に作って確認します。
EC・注文管理
商品、カート、注文、管理画面の最小フローを通して、運用可能性を確認します。
AIチャットボット
問い合わせ履歴やFAQをもとに、回答品質・運用負荷・改善余地を検証します。
マッチング・検索機能
条件検索、推薦、比較など、サービスの核になる機能を小さく試作します。
技術と事業の両方を見ながら、実装まで進める。
20歳の頃にC言語とUNIX環境で開発を学び、LSI開発企業への出向でエンジニアリング系の開発を学び、その後30代は大規模開発案件のプロジェクトマネージャーを経験。2005年に株式会社iPLUS ONEを設立し、WEBアプリケーションの受託開発を中心にやってきました。現在はAIを最大限活かした開発プロセスAI-DDDを実証実験中です。
事業を前に進める、7つの基盤
実際に設計・開発・運用まで手がけたプロダクトです。
ECサイト基盤
売る仕組みを、すぐ始められる
出店から決済、売上管理までを一気通貫で支えるEC基盤
見積もり基盤
提案スピードを、仕組みで引き上げる
見積作成からPDF化までをスマートに回せる基盤
入札サイト
比較・選定を仕組みで整える
複数業者から同一フォーマットで見積を集め、比較検討しやすくした入札サイト
コミュニティ基盤
人が集まり、関係が育つ
発信・参加・交流を生み出し続けるコミュニティ基盤
マッチング基盤
人と仕事、人と募集をなめらかにつなぐ
求人や応募導線を扱いやすくするマッチング基盤
不動産物件サイト構築基盤
物件情報を見やすく、問い合わせまで一体設計
物件情報を見やすく整理し、掲載から問い合わせ導線までを一体で設計できる基盤
予約システム基盤
来店や面談、各種申込の受付をわかりやすく整理
登録から完了導線までをスムーズにつなぐ予約システム基盤
AI活用やWebシステム開発を、小さく試すところから始められます。
課題整理、PoC、要件定義、実装、運用まで、現実的な進め方で支援します。