作るものの価値を、
最後まで見失わないために。
Valuecraft は、数多くの業務システム導入をリードしてきたデジタルバリューコンサルティングが、その現場のノウハウを体系化したシステム構築の方法論です。 AI 駆動を前提に、ドキュメントを AI への指示書であり評価の基準と位置づけて磨き上げます。そこに書く「何が価値か」を決めるのは人であり、その一線が速さと確かさを両立させます。
Valuecraft は、
2 つの手法でできています
既存システムを読み解く「AI 駆動システム解析」と、新しいものを作る「AI 駆動システム開発」。両方を必ず通るわけではなく、案件の入口で決まります。
AI 駆動システム解析（価値駆動解析）Value Analysis Research
既存システムのソースコードと業務データを解析し、何を残し、何を捨て、何を新しく作るかを判断できる状態にします。調べること自体が目的ではありません。業務のどこに価値があり、何を継承すべきかを見極めるための工程です。
AI 駆動システム開発（価値駆動開発）Value-Driven Development
顧客にとっての価値を判断基準の最上位に置き、その価値がブレないように開発を進めます。中心にあるのはドキュメントで、要求も仕様も判断の経緯もそこに集約し、実装と検証はそこから導きます。確認開発と本格開発の 2 段で構成されます。
既存システムの刷新なら解析から、新規開発なら開発から入ります。解析で得た「判断できる状態」を土台に、次に何を作るかを企画し、開発へ進みます。
全体を漏れなく押さえる解析と、
目的に沿って詳細を詰める解析。
AI 駆動システム解析も、2 つのステップでできています。前半は基礎数値を確定させて全体の地図を作り、機能詳細をどうまとめるかの方針まで示します。後半は「何のためにまとめるのか」を定めたうえで、その方針に沿って詳細を書ききります。
全体俯瞰
全体を漏れなく押さえる
画面数・機能数・オブジェクト数といった基礎数値を最初に確定させ、その一覧を網羅させます。調べる範囲を AI の判断に委ねると抜けが出るため、順序を逆にしてリストに対象を決めさせます。
そのうえで全体像をまとめたドキュメントを作り、機能詳細をどうまとめるかの方針まで示します。
詳細分析
目的に沿って詳細を詰める
何のために情報をまとめるのかを、先に定めます。目的が決まらないまま詳細に入ると、量は増えても判断には使えない資料になるからです。
定めた目的と、全体俯瞰で示した方針に沿って機能詳細をドキュメントにまとめ、何を残し、何を捨て、何を新しく作るかを判断できる状態まで持っていきます。
どちらのステップでも、推測は書きません
解析が明らかにするのは、現状がどうであるかです。推測や見込みが混ざると、後の判断がどこまで事実に基づくものか分からなくなります。だから「読み取れないことは書かない」「実装から確認できることだけを書く」を定め、事実と解釈を分けて記述します。
解析の成果は、そのまま次のシステムの設計にはなりません
現行システムの設計をそのまま書き起こしても、次のシステムにはなりません。アーキテクチャの考え方も、採用する技術の設計思想も、そして業務にとっての価値そのものも、当時とは変わっているからです。過去の資産を未来にどう活かすか。その企画とコンセプト設計は、経験を積んだ人が担います。解析はその判断を支える土台であって、答えそのものではありません。
要求を明確にする開発と、
仕様どおりに完成させる開発。
AI 駆動システム開発は、この 2 つのフェーズでできています。前半は動くものを作りながら要求を掘り起こし、それを AI が正しく実装できる記述に落としきるところまでを担います。後半は、その仕様どおりであることを確かめながら完成させます。
確認開発
要求を明確にし、記述しきる
要求は、聞き取っただけでは確定しません。だから動くものを作って確かめます。画面サンプルで業務の流れを見るのか、最小構成の試作で通しで回すのか、技術検証で精度を測るのか。いずれもここでのコードは問いを解くための道具であり、既定で捨てます。
確かめた結果は、その場で記述に落とします。このフェーズが担うのは、要件を曖昧さなく書ききることです。要件が固まるのを待てば進まず、未決を確定として書けば AI が誤って実装します。その両立をここで扱いきります。
本格開発
仕様どおりに完成させ、届ける
要求はすでに書ききられています。ここでのコードは成果物であり、ドキュメントとの一致で品質を測ります。「仕様にあって実装にない」は検証エージェントが自動で検出し、内容の妥当性は AI が一次レビューしたうえで、人が最終的に判断します。
ここに「分からないもの」は持ち込みません。機能を満たすだけでなく、インフラやセキュリティといった非機能要件まで作り込み、セキュリティ診断や性能テストで確かめます。リリースやマニュアルの整備まで含め、実運用に耐える状態にするのがこのフェーズの範囲です。
仕様確定で見るのは、このドキュメントだけで作れる状態かどうかです
判定の対象は進捗ではありません。書かれている内容だけで実装に進めるか、読む人によって解釈が割れる箇所が残っていないか。通過すればこのドキュメントは、本格開発での実装の指示であると同時に、出来上がったものを測る基準にもなります。通過条件はチェック形式で定義してあり、埋まっていなければ先へは進みません。
解析も開発も、
AI エージェントの連携で進みます。
実行・評価・管理の三役に分かれたエージェントが、互いの成果を受け渡しながら自律的にサイクルを回します。人は方針を与え、要所で判断します。
実行エージェント
適切な方法で確実に遂行します。膨大な対象を、決められた手順で漏れなく処理しきることが役割です。
評価エージェント要
成果物を、複数の専門家視点に分かれてレビューします。単一の視点では見落とす欠陥を、視点の多様性で捕まえます。
管理・調整エージェント
評価の結果を受け取り、何をどの順で直すかを判断して実行に戻します。進捗とタスクを管理し、人に確認すべき点を明示するのもこの役割です。
重要なのは、評価の結果が次の実行を駆動しつづけることです
評価を出しっぱなしにすると、指摘は溜まるだけで成果物は変わりません。管理・調整エージェントが指摘を仕分け、優先度をつけ、実行への具体的な指示に変換してループを回します。さらに、同じ指摘が繰り返し出るなら手順や記載フォーマット自体を見直し、次のサイクルに反映します。個別の修正で終わらせないための仕組みです。
方法論と、ツールの関係
kachimi は Valuecraft の考え方を土台に生まれたツールです。ただし、両者は一体のものではありません。
Valuecraft は、kachimi がなくても実践できます
Valuecraft が定めるのは、進め方の規律と、それを AI と協働で回すための仕組み一式です。フェーズの区切り方、ドキュメントの書き方、エージェントの組み方までを含みますが、いずれも特定の製品を前提にしていません。kachimi は、その実践をチームで回しやすくするための選択肢のひとつです。
kachimi は、他の進め方でも使えます
kachimi が扱うのは、資料を読み解き、ドキュメントとして形にし、レビューを経て確定させるという案件の営みそのものです。フェーズの区切り方や承認の段数はプロジェクトごとに定義できるため、社内標準や既存のプロセスに合わせて運用できます。
そのうえで、組み合わせると最も噛み合います
kachimi は Valuecraft の実践で必要になったものから作られています。フェーズの明示や仕様確定の判定、ドキュメントを正本として扱う運用は、そのまま機能します。方法論から入っても、ツールから入っても構いません。
進め方から、ご相談ください
方法論の導入だけでも、ツールの導入だけでも構いません。案件の状況と、いまお使いの進め方をうかがったうえで、どこから手を入れるとよいかをご提案します。