全力Spec

成果物

要望を提示するだけOK

エンジニアでなくても仕様は書けます

お預かりするのは、要望を書いた文章と参考資料だけです。そこから下の10種を、上流から順に作ります。エンジニアが白紙から書き起こす工程が、出来上がったものを読んで直す工程に変わります。

要件定義書

機能要件・非機能要件の整理。すべての出発点。

機能仕様書

機能ごとの詳細と、画面・テーブル・APIの対応表。

DBテーブル設計書

テーブル定義、列、型、制約。

API設計書

エンドポイント、リクエスト／レスポンス。

画面一覧

画面IDと画面名の台帳。

画面仕様書

画面ごとの表示項目・操作・遷移。

画面遷移図

フローチャート形式で生成し、ブラウザ上で描画。

画面構成図

HTML DSLのワイヤーフレーム。

システムテスト仕様書

機能単位の検証項目。

DL時に結果記入欄を付与

シナリオテスト仕様書

業務の流れに沿った通しテスト。

DL時に結果記入欄を付与

生成順

適当な順番で作っているのではありません。上流の文書を材料にして下流を作るため、生成順は依存関係そのものです。タイルの左肩の番号が、この依存の段です。同じ番号の文書は並行して作られます。前提が揃っていない文書は生成できません。

ダウンロードは Markdown / PDF / Excel。ある時点の10文書をまとめてZIPで取得することもできます。

確認の手段

実物で合意形成

まだ言葉や文章で合意形成していますか？

文章の設計書だけを見せられても、思っていたものと合っているかは分かりません。画面を見ながらであれば、どこが違うのかをその場で指さして言えます。画面遷移図を見ながら「この導線、逆では」。画面構成図を見ながら「この項目が足りない」。実装が始まる前に潰せます。

「思っていたのと違う」が出る時期が、変わります

言葉で合意しても、認識のズレは残ります。それが表に出るのは、たいてい実装が進んだあとです。画面を見て合意しておくと、その確認が打ち合わせの段階に前倒しになります。

概念図

直すコストは、工程が進むほど跳ね上がります。仕様書を読んで気づけなかったことも、画面を見れば「ここは違う」と言えます。専門知識は要りません。使う場面を思い浮かべながら見れば十分です。

初回打ち合わせ

要望を直接イメージに

打ち合わせの中で画面イメージを出せていますか？

持ち帰って数週間後に見せる、ではありません。画面のつながり方と、各画面の見た目までをその場で作って、一緒に見ながら直せます。

概念図

画面遷移図

どの画面からどこへ行けるかの全体像。画面をクリックすると、その画面に関係する説明だけを取り出して表示できます。

PCタブレットスマートフォン

画面構成図

1画面ずつの項目とボタンの配置。PC・タブレット・スマートフォンの切り替えも見られます。

生成が終わった時点で、ブラウザ上にそのまま表示されます。

実測

画面イメージはその場で

まだ画面をツールで書いていますか？

52:49画面遷移図要望を話しはじめてから

84:25画面構成図続けて、画面ごとの配置まで

108:31設計書10種すべて要件定義から、テスト仕様書まで

あるプロジェクト1件での実測です（分：秒）。所要時間は処理の混み具合で変わります。短くなることも、当日中に出ないこともあります。詳しくは最後の「世の中に万能はありません」をご覧ください。

品質

成果物同士のトレーサビリティ

一貫性を正確に保てていますか？

手戻りの元になるのは、1冊の中の誤りより、文書をまたいだ食い違いです。画面仕様書が使うと書いたテーブルが、DB設計書に無い。機能仕様書が参照するAPIが、API設計書に無い。1冊ずつ読んでいる限り見つかりません。

1要件との整合要件定義書機能仕様書

2設計の整合機能仕様書DBテーブル設計書API設計書

3詳細設計の整合画面一覧画面仕様書画面構成図DBテーブル設計書API設計書

4システムテストの整合画面一覧機能仕様書システムテスト仕様書

5シナリオテストの整合シナリオテスト仕様書画面遷移図画面仕様書

機械的に判定できるものはAIを使わずに確かめます。同じ文書なら、何度実行しても同じ結果になります。

確かめられなかった範囲は「検査不能」として件数つきで表示します。黙って除外すると、確かめていない範囲が「問題0件」に紛れてしまうためです。

修正

最小限の変更

意図した部分だけを直します

指摘が見つかったとき、文書全体をAIに書き直させると、直したかった箇所と一緒に、合意済みの記述も静かに変わってしまいます。指摘のあった箇所だけを作り直し、残りはそのまま使います。

概念図

文書全体を作り直す場合 88項目

1. 目的

2. 利用者

3. 入力項目

4. 画面遷移

5. 権限

6. エラー時

7. 保存先

8. 通知

ほか80項目

直したい3件のために、無関係な85件が静かに変わる。

このプロダクト 88項目

1. 目的

2. 利用者

3. 入力項目

4. 画面遷移

5. 権限

6. エラー時

7. 保存先

8. 通知

ほか80項目

3件だけを作り直し、85件は一字一句そのまま。修正後、機械的に再検査。

修正対象の項目意図せず書き換わった項目そのまま保持された項目

作り直す範囲が狭いぶん、AIに処理させる量も少なくて済みます。文書全体を生成し直すより、必要な箇所だけを作り直すほうが効率が良いということです。

版はすべて残ります。上書きはしないので、いつでも前の版と見比べて、必要なら戻せます。

進行管理

管理者を解放する

要件管理、構成管理、まだ人で行っていますか？

設計工程の管理は、大きく「調整」「確認」「判断」の3つに分かれます。このうち前の2つは、この仕組みで解決します。

概念図

管理の中身仕組みが持つ人が持つ

調整順番を決める・前提を見る・担当を割り振る

確認進み具合を追う・最新版を把握する・指摘を仕分ける終わったかを見に行く

判断いつ始めるか・どこで止めるか・どれを確定版にするか

割合ではなく、担い手の内訳です。「確認」だけが両方にまたがります。

要らなくなる確認

次どれやればいい？前提そろってる？これ誰がレビューする？どれが最新版？

概念図 / 実画面ではありません

社内販売管理システム　/　ドキュメント生成

ドキュメント種別	状態	前提
要件定義書	あり	生成対象外
機能仕様書	あり
DBテーブル設計書	あり
API設計書	未作成
画面一覧	未作成
画面仕様書	未作成	前提の API設計書が未作成です
画面遷移図	未作成	前提の画面仕様書が未作成です
画面構成図	未作成	前提の画面仕様書が未作成です
システムテスト仕様書	未作成	前提の画面一覧が未作成です
シナリオテスト仕様書	未作成	前提の画面遷移図が未作成です

※生成は非同期で実行されます。生成中も画面操作は継続できます。生成を開始

前提が揃っていない文書は、そもそも選べません。押せない理由は「前提の API設計書が未作成です」のように、不足している文書名で表示されます。

どの文書が何を前提にするかは、システムで決めてあります。担当者ごとに解釈が違う、ということが起きません。

残るもの

人の価値を最大化

判断は、あえて残しています

調整と確認を引き取っても、意思決定は人の仕事として残ります。これは機能が足りないからではなく、そう設計しているからです。理由も含めてお伝えします。

残る会話

これで確定でいい？そろそろ止める？誰がこの版に責任を持つ？

人が受け持つこと	なぜ仕組みに渡していないか	実際の運用
いつ始めるか	作成・確認・修正はそれぞれ費用が発生するため、意図的につないでいません。作ったら勝手に確認まで走る、という作りにはしていません	担当の方が画面から実行します
どこで止めるか	指摘が0件になるまで繰り返す作りにしていません。どこまで直すかは、納期と品質のバランスをとる業務判断です	指摘の残り件数を見ながら、打ち切りを決めていただきます
どれを確定版にするか	版はすべて残す作りで、上書きしません。どれを正とするかを自動で決めると、意図しない版が確定してしまいます	名前をつけて固定でき、必要ならその時点に戻せます
自動で直せない指摘への対応	確認できなかった箇所や、根拠が示せない指摘は、思い込みで書き換えないようにしています	件数と理由が表示されるので、内容を見て対応していただきます
体制と権限の決め方	1つのプロジェクトに1人の持ち主という作りで、複数人で権限を分ける仕組みがありません	チームで使う場合の運用ルールは、別途決めていただく必要があります

置き換えたのは段取りと状態の把握であって、意思決定ではありません。そこは人の仕事として残しています。

はじめる前に

世の中に万能はありません

正直にお伝えします

所要時間と運用の制約処理はAI側の順番待ちに並ぶため、所要時間をこちらで決めることはできません。混み合っていると、最大24時間かかることがあります（実測でも同じ量の処理が15分で終わったときと、9時間31分かかったときがありました）。
また、確かめる工程は10種すべてが揃ってから実行できます。完了を知らせる通知はありませんので、終わったかどうかは画面を開いて確認していただきます。1つのプロジェクトに1人の持ち主という作りのため、複数人で権限を分ける仕組みもありません。

実際の動きを見たい

要望を話すところから画面が出てくるまでを、実際のプロジェクトでご覧いただけます。お手元の要望でお試しいただくことも可能です。

デモのお申し込み先は配布時にお伝えします

導入を検討したい

想定するプロジェクト規模での費用感、運用体制、既存の設計プロセスへの組み込み方をご相談ください。

問い合わせ先は配布時にお伝えします