経験を生かして新卒採用ツールを作ってみた（3） ～答えが出るまで、先に進まないことにした～
はじめに
前回、実装にどれくらいかかるかを見通すために、機能を絞ったミニ版を作りました。
そこで得た手がかりをもとに、今度は本命の新卒採用ツールを作り始めました。
作り始めると、決めていないことが次々に出てきます。この画面は誰が見るのか。どの情報をいつまで持つのか。そういうことです。
まだ決めていないことにも、AIは案を返してくれました。もっともらしい理由も添えられ、考える材料になります。
ただ、その案を採用するかどうかは、私が決めなければなりません。
その線引きをしないまま進めていたら、私が決めた覚えのないことが、決まったことになっていたと思います。今回は、それをどう扱ったかという話です。
結論だけほしい方はこちらの第６回の振り返りをご確認ください。
なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトではありません。実際の採用活動で運用するかどうかは未定です。
今回の対象読者
- 開発者が、何を考えてものを作っているのか知りたい方
- AIを使った開発が、実際にはどんなところから始まるのか気になる方
技術の詳しい話はしません。仕事の進め方の話になります。
まず結論
わからないことは、1行ずつ表に書き出しました。そして、人が答えるまでは、決まった扱いにしないことにしました。
ただし、全部を止めたわけではありません。止めたのは、その答えがないと着手できない作業です。答えに関係のない調査や整理は、先に進めました。
質問を残すことは、何もしないで答えを待つことではありません。決めた覚えのないことが、いつの間にか決定になるのを防ぐためでした。
決めた覚えのないことが、決まっていく
たとえば、「スマートフォンから、どこまで見せるか」という問いがありました。
スマートフォンにも対応することだけは決まっていました。ただ、何を表示してよいかは、まだ決まっていませんでした。これは、ツールを使う側である私が決めることです。
AIに相談すると、案が返ってきました。案が返ってくることも、案そのものも悪いわけではありません。
その案が設計書に書かれ、その設計書をもとに作られる。気づいたときには、「もうそう決まっている」状態になりかねません。
問題は、まだ決まっていない案が、いつの間にか決定事項として扱われてしまうことでした。
進め方そのものを、自分で作った
今回作るツールでは、AIへの頼み方だけでなく、進め方そのものを自分で決めました。自作の開発フローです。
決め事は4つあります。作るものの前提を1か所にまとめること。決まっていないことを表に出すこと。設計をいろいろな立場から見直すこと。そして、工程の区切りで本当に終わったかを確かめることです。
AIに上手に頼むための工夫というより、AIが間違えても気づけるようにするための決め事です。
3つ目は第4回、4つ目は第5回で書きます。この進め方そのものを見直した話は、第6回で書きます。今回は2つ目、決まっていないことを表に出す話です。
わからないことを、1行ずつ表に出す
決まっていないことは、1つの表に集めました。1行が1つの問いです。
書くのは、問いだけではありません。いまはどうなっているか。私はどうするのがよいと思うか。その理由は何か。そして、誰が答えるのかです。
この記事用に項目を絞ると、次のような1行になります。
| 問い | 答える人 | 答えが必要な段階 | 状態 |
|---|---|---|---|
| スマートフォンでの表示範囲 | 私（利用者） | 今すぐ | 決定済み |
答える人を書くことで、自分で決められることと、自分だけでは決められないことを分けられます。採用の業務としてどうするかは、使う側として私が答える必要がありました。
答えが出たら、決めた内容と、決めた日と、何を根拠に決めたかを同じ行に書き足します。行が埋まって初めて、その問いは片づいたことになります。
この表は、最後まで使いました。結果として、200行を超えました。
表の1行が、設計の中身になった
スマートフォンでの表示範囲は、開発の初日に立てた問いです。「今すぐ答えが要る」と印をつけ、その日のうちに私が答えました。
決めた内容は表に書かれ、日付と一緒に残ります。そこから先が、この表を作ってよかったと思えたところです。
その1行は、要求仕様の文書に書かれ、機能の一覧に載り、詳細設計までつながりました。
課題 I-12
→ 要求仕様 FR-36 / NFR-12
→ 機能一覧 F-32
→ 詳細設計
記号そのものが大事なのではありません。どの文書のどこが、どの問いから来たのかを、あとからたどれる状態にできたことが大事でした。
決めた中身の話は、第4回で書きます。ここで言いたいのは、1行の問いが、設計まで追える形で残ったということです。
答えを待つ間、どこまで進めてよいか
とはいえ、答えが出るまで全部止めていたら、何も進みません。
そこで、問いごとに「今すぐ」「実装開始まで」「テスト開始まで」という印をつけました。これは日付ではなく、どの工程に入るまでに答えが必要かを示す印です。
工程の入口では、その工程の前提になっている問いが片づいているかを確認しました。片づいていなければ、その工程には入りません。一方で、答えに関係のない調査や整理は進められます。
実際に、印を付け替えたこともあります。ある問いは最初、「実装開始までに答えが要る」としていました。作るコードがその答えに左右されないと分かり、「テスト開始まで」に変えました。
逆に、テストの仕様書を書き始める直前の確認で未決が残り、着手を見送ったこともあります。
止める・進めるの判断は、日付ではなく、その問いが何の前提になっているかで決めました。
つまずきポイント
この進め方には、はっきりした副作用がありました。
表が大きくなりすぎたのです。200行を超えた頃には、全体を読み返すのがつらくなっていました。疑問を書き出すことは役に立ちましたが、量をどう扱うかは別に考える必要がありました。この話は第6回で書きます。
実務ではどう考えるか
決まっていないことを抱えたまま進めると、あとで戻ることがあります。今回の開発でも、そう感じる場面がありました。
やりにくいのは、決まっていないことが、決まっているように見えてしまう場面です。誰かの提案が、いつの間にか決定として扱われることは、AIとのやり取りに限りません。
今回の私は、「これは誰が決めたことなのか」を書き残しました。決めた人、決めた日、その理由です。今回の開発では、この3つを書き残していたので、あとから理由をたどれて助かりました。
質問を溜めておいて、一度にまとめて相談する進め方もあります。相手の時間を細切れにせず、自分も待つ間に進められる作業を見つけやすくなります。
まとめ
- 決めていないことにも案が返ってきて、そのまま決定として流れていきそうになった
- わからないことは表に残し、人が答えるまでは決まった扱いにしないことにした
- 問いごとに、誰が答えるか、決めた日、根拠を残すことで、設計までの経路をたどれるようになった
- 未決だからすべてを止めるのではなく、その答えに依存する工程だけを止めた
次回は、設計をいろいろな立場から見直した話を書きます。立場の違う視点を用意すると、自分だけでは見落としていたことが見えてきました。
なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。
次に試してほしいこと
いま進めている作業で、まだ決まっていないことを書き出し、誰に聞けば答えが出るかを並べる方法もあります。