経験を生かして新卒採用ツールを作ってみた（6） ～作り終えてから、やり方を振り返ってみた～
はじめに
新卒採用の進捗を管理するツールを、AIに手伝ってもらいながら作りました。システム開発における一般的な手順を一通り通し、完成までたどり着きました。
ここまでの回では、確認の仕組みについて書いてきました。決まっていないことは表に出す。いろいろな立場から見直す。終わったかどうかは別の人が確かめる。
その結果どうなったかを、今回は正直に書きます。一言でいうと
書類が増えすぎて、自分で読み切れなくなりました！
なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトではありません。実際の採用活動で運用するかどうかは未定です。
今回の対象読者
- 開発者が、何を考えてものを作っているのか知りたい方
- AIを使った開発が、実際にはどんなところから始まるのか気になる方
手順の解説ではなく、振り返りと直し方の話になります。
まず結論
確認を大事にするためにルールを作った結果、成果物が自分で確認し切れない量になりました。
そこで、ここまで使ってきた、AI向けの開発フローそのものを見直しました。人が承認する対象を、分厚い文書そのものから「前回から何が変わったか」の要約へ変え、数えたり突き合わせたりできることはスクリプトに任せることにしました。
作り終えた。そして、書類の山が残った
全部の工程を通し終わったのが、作り始めてから約1か月後でした。
そのとき手元に残っていた主な文書です。
| 文書 | サイズ |
|---|---|
| 詳細設計書 | 293KB |
| 単体テスト仕様書 | 191KB |
| 課題管理表 | 183KB |
| 非機能要件書 | 134KB |
| 概要設計書 | 104KB |
| 結合テスト仕様書 | 101KB |
表にない文書も含めると、全部で1.2MBほど、行数にすると8,000行を超えます。ボリューム的に言うと５０万文字、ググると１ＭＢで小説１冊あるんですって（笑）
自分で決めたルールなのに、読み切れなくなるとかダサいなー（；^ω^）
しかも・・・１名＋ＡＩでこのボリュームですからねー２名以上のチームだったら概要設計フェーズでパンクするでしょうね。
当時の記録には、「成果物は人がチェックできる量を超えており、AIが読み切る上限にも達している」との指摘が残っています。ただ、後半（AIが読み切る上限）については、いつ、何が起きたという記録が残っていません。確かなのは、私が読み切れなくなっていたことです。
手元にあるのは５０万文字の成果物です。ここから原因を分析し対策を立案していきます。
原因分析：なぜ増えたのか
原因を4つに整理しました。
① 同じ決定を、何度も書いていた 1つ決めると、その内容がいくつもの文書に書きこむ仕組みになっていました。調べてみたら、6つの決定が、18の文書に165か所書かれていました。同じ内容を何度も書かないためのルールは組み込んでいました。しかし、守られているか確かめる仕組みがありませんでした（AIがルールを無視している可能性が高いと感じ、調査しましたが記録からは断定できませんでした）。
② 決まるまでの経緯が、文書の本文に混ざっていた 課題の番号、「保留」「解決済み」といった状態の言葉、長い改訂の履歴。こういうものが、成果物の本文に積み上がりました。
③ 1つの工程を、1つの大きなファイルにまとめていた ＡＩに依頼する際は、機能ごとに分けて依頼してますが、概要設計書、詳細設計書はそれぞれ１つにまとめていました。書くほうも読むほうも、毎回全体を相手にすることになります。
④ 「ここまで書けば完了」の上限がなかった 完了の条件は「実装で迷わない粒度」でした。よーく考えてみると、このルールは書き足す方向にしか働きません。足りなければ不合格になりますが、多すぎても不合格にはならないからです。
そして！対策！
対策１：承認するものを「文書」から「変化」に変えた
いちばん大きく変えたのは、承認の単位です。
これまでは、分厚い文書そのものを私が読んで承認していました。これを、前回承認したときからの追加・変更・削除と、まだ決まっていないことをまとめた要約で承認する形に変えました。
文書はこれからも作ります。ただ、承認の場で中心に見るものを、文書全体から「何が変わったか」へ変える、ということです。
この変更に合わせて、文書の作り方と確かめ方も変えました。
| 以前 | 改善後 |
|---|---|
| 同じ決定を複数の文書へ書く | 決定一覧を1か所に置き、文書には決定番号を残す |
| 分厚い文書全体を承認する | 追加・変更・削除、未決事項、検査結果の要約を承認する |
| 経緯や履歴が本文へ追記する | 経緯は決定一覧と課題管理表へ分ける |
| 文書どうしの食い違いを目検とAIで探す | 決定番号と値をスクリプトで照合する |
| 文書を順番に読んで確認する | HTML化した承認資料から、決定・文書・該当箇所へリンクでたどる |
そして読む単位を小さくし確認できる状態を保つために、300kb近くになった詳細設計書は、共通部分と機能ごとのファイルに分けることにしました。ファイルの大きさにも目安を置くようにし、超えた場合はアラートを出すようにしました。
対策２：文書の食い違いを、スクリプトで見つけるようにした
今回の進め方では、「決めたことが下流の文書にも反映されているか」を、私やAIが文書を読んで確かめていました。改善後は、成果物の構造化に取り組み、決定事項は仕様決定番号を振ったうえで「決定一覧.md」へ、ほかの文書は本文中に仕様決定番号と改訂番号を添えるようにしました。
例えば「実装言語はpythonとする」という仕様を決めたときは、設計書に
実装言語はpythonとする（D-001:r1）
と記載します。そして、決定一覧（新設）と改訂記録一覧（新設）に以下の通り記載しておきます
決定一覧
| 仕様決定番号 | 決定 | 種別 | 値 | 許容表記 | 改訂 | 状態 | 検索語 |
|---|---|---|---|---|---|---|---|
| D-001 | 実装言語 | 値 | Python 3 | Python3;python3 | r1 | 有効 | Python;実装言語 |
改訂記録
| 仕様決定番号 | 改訂 | 日付 | 内容 | 根拠の課題 | 利用者の発言 |
|---|---|---|---|---|---|
| D-001 | r1 | 2026-09-19 | 実装言語は Python 3 とする | STEP2 要求整理 質問1 | Python 3で進めてください |
と記載しておきます。最新の仕様は決定一覧に、経緯と履歴は改訂記録に分けて記載することで重複を防ぎ仕様から設計をたどれるようにしました。
こうしたことで、どの文書のどこで使われているかを、スクリプトで追えるようになりました。
その結果、決定一覧と文書の値が合っているか、必要な文書に決定番号が現れているか、参照先のファイルや節が存在するかを確認できます。
人やAIが文書を読み比べて数える代わりに、数える、突き合わせる、存在を確認するといった作業をスクリプト＋ＡＩに任せられるようになりました。
対策3：HTMLとリンクで、必要な場所までたどれるようにした
決定を1か所に集めても、承認するときにその決定や文書の該当箇所まで戻れなければ、確認しやすくなったとは言えません。
そこで、承認資料はHTMLで作ることにしました。要約にある決定番号、文書名、節番号から、それぞれの該当箇所へリンクでたどれるようにします。
同じ決定を各文書に書き写すのではなく、決定一覧を正本にして、必要なところから参照する形にしました。文書全体を読み直さなくても、気になった決定や根拠へ戻れるようになりました。
改善した進め方を、小さく試した
改訂した進め方は、引数の合計を出す小さなコマンドラインプログラムを作る案件で、最初から最後まで試しました。
承認では、文書全体ではなく変更の要約を読む形にできました。決定は一覧に集め、決定番号の食い違いや、参照先の誤りをスクリプトで見つけられるようにもなりました。
特に重かった後半の確認は、１／３まで減りました。確認する内容を減らしたのではなく、直前の工程から変わっていないものを繰り返し読まないようにした結果です。
今回の検証だけで、どんな案件にも使える進め方になったとは言えません。それでも、人が読むところと、機械が確かめるところを分けることで、確認できる量に近づける手がかりは得られました。
実務ではどう考えるか
手順は、使ってみてから直すところが見えてくるものだと感じました。
今回、直す場所を決められたのは、文書の量、同じ決定が書かれた回数、確認表の行数、テストの結果が記録に残っていたからでした。感覚だけだと、「なんとなく大変だった」で終わっていたと思います。
私の場合は、作り終えたあとに一度立ち止まり、改善した手順を小さな案件で試す形にしました。それでも新しい問題は出てきます。だから次の案件でも、成果物の量や確認にかかった時間を測り、また見直すつもりです。
まとめ
- 確認を大事にした結果、成果物が自分で読み切れない量になった
- 原因は、決定の書き写し、経緯の混入、大きな1ファイル、完了条件に上限がないことだった
- 承認の対象を文書全体から「前回からの変化」の要約へ変え、数えられる確認は機械に任せる形にした
- 小さな検証用の案件でも、１／３まで減らせた
- 改訂後の進め方が大きな案件でも働くかは、次のプロダクトで確かめる
このシリーズは今回で終わりです。全6回、AIに任せる部分と、人が決める部分をどう分けたかを書いてきました。任せる範囲が広がるほど、人が決めるルールと確認が効いてくる、というのが一貫した実感です。
なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。
次に試してほしいこと
自分の作業手順を1つ選んで「やめてもよいこと」を探す、という方法があります。増やすより難しいのですが、そのぶん効きます。