経験を生かして新卒採用ツールを作ってみた（5） ～「出来ました」を、事情を知らない相手に確かめてもらった～
はじめに
「できました」と言われたとき、それをどう扱うか。
新卒採用の進捗を管理するツールを、AIに手伝ってもらいながら作りました。作業を頼めば、たいてい「完了しました」と返ってきます。
ただ、終わったかどうかを、作った本人が決めてよいのか。ここは決めておく必要がありました。今回は、その仕組みの話です。そして、その仕組みが私自身の取りこぼしを見つけた日の話です。
結論だけほしい方はこちらの第６回の振り返りをご確認ください。
なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトではありません。実際の採用活動で運用するかどうかは未定です。
今回の対象読者
- 開発者が、何を考えてものを作っているのか知りたい方
- AIを使った開発が、実際にはどんなところから始まるのか気になる方
開発の手順そのものの解説ではなく、確認の仕方の話になります。
まず結論
作った担当は、自分の完了を宣言できない。 これを決め事にしました。
判定するのは、作業の経緯を知らない別の担当です。渡すのは、出来上がったもの、「何ができていれば完了か」という条件、そして確認に必要な記録。渡さないのは、作業中のやりとりです。
この仕組みは、実際に私の取りこぼしを見つけました。
「できました」を信じてよいか
自分で作ったものを自分で確認すると、私は甘くなります。
疑っているという話ではありません。経緯を知っているからです。ここは事情があってこうした、ここは仕方がなかった。そういう背景が頭にあると、「まあ大丈夫だろう」のほうへ寄っていきます。
AIに任せた作業でも、 作る役と、確かめる役を分けました。
確かめる人には、事情を渡さない
確かめる担当に渡すのは、次のものです。
- 出来上がった成果物（ファイルの場所と版）
- 「これができていれば完了」という条件
- 作業の証拠になる記録（テストの実行ログ、手で確認した記録など）
- 決まったことの一覧（決めていないことを1行ずつ書き出した、あの表です）
渡さないのは、作業中の会話です。どういう事情でそうなったのか、どこで苦労したのか。そういうものは一切渡しません。
根拠がないまま判定させる、という意味ではありません。**根拠は渡す。事情は渡さない。**この区別が要です。
作った側と確かめる側を分けたのは、同じ担当が作って、自分で合格としないためです。
確かめる役には、書き込む権限も与えていません。判定を返すだけです。
実際に起きたこと：合格と数えてはいけないものがあった
最後の工程で、この仕組みが働きました。
画面を通した通しのテストを進めていたときです。ある確認項目を、3種類のブラウザで自動的に試すようにしていました。
① 実装した担当が、1つだけ飛ばした 3種類のうち1つでは、当時は確認を実行できませんでした。そこで、その1つは飛ばす設定にしました。そのうえで、「これを受け入れ確認に回すかどうかは、判断してほしい」と報告してきました。判断を求めてきていた、ということです。
② 私が、決まったことのように扱った ここで私が、その判断をしませんでした。確認したつもりで、「受け入れ確認に送りました」と、もう決まった話として扱ってしまったのです。作業の記録には「受入テスト送り」と書き、次の担当への依頼文では、そのまま「合格」と書いてしまいました。
③ 報告書に、合格として数えられた 依頼文にそう書いてあるので、報告書ではその項目が合格として集計されました。合格44件のうちの1件です。
④ 差し戻された 最後の確認で、経緯を渡されていない担当が、実行ログと決まったことの記録を突き合わせました。ログには「1件飛ばした」と残っている。一方、それを受け入れ確認に回すという決定はどこにもない。そこで「合格と数える根拠がない」として、差し戻されました。
判定を始めたのが11時20分、差し戻しの票が出たのが11時23分でした。
取りこぼしたのは、AIではなく私だった
この一件を、あとから自分で整理し直しました。
実装した担当は、正しく報告していました。「判断してほしい」と書いてありました。飛ばしたことも隠していません。
落としたのは、中継していた私です。判断が要るものを、判断せずに、決まったものとして次へ流しました。
しかも、そのあとの調査で、もっと恥ずかしいことが分かりました。「この環境では確認できない」という前提自体が間違っていたのです。やり方を変えれば、3種類すべてで確認できました。実際にやってみたら、全部通りました。差し戻し票が出てから17分後のことです。 差し戻しは1回で済みました。調査結果を受けて仕様とテストを見直し、3種類すべてで確認し直しました。その結果を報告書と、決まったことの記録に反映しました。
ゲートで落ちるのは、失敗ではありません。仕組みが働いた証拠だと考えるようにしています。
つまずきポイント
決定のない「飛ばした」は「合格」ではありません。
その時点では、その環境で確認できない制約だと考えられていました。
それでも、確認の範囲を狭める判断には、決定が要ります。技術的にどう見えるかと、それを決めてよいかどうかは、別の話です。
私はすべての事情を知っていたので、決定の根拠を確認せずに通してしまいました。
そしてもう1つ。確認する人が事情を知りすぎていると、この種の見落としは通ってしまいます。
実務ではどう考えるか
作る人と確かめる人を分けるのは、役職の上下の話ではありません。役割の分離です。偉い人が確認する、という話ではなく、作っていない人が確認する、という話です。
そのために要るのが、完了の条件を先に決めておくことでした。今回の最後の工程では、こういう条件を事前に文字にしていました（全部で4つあるうち、この話に関わる3つを挙げます）。
- すべての確認項目が実施済みであること。ただし決定により範囲外とされたものは、課題管理表で解決済みかつ根拠に利用者の回答があるうえで、その決定どおりに報告書で区分されていること
- 加工していない実行ログがあり、報告書の判定と一致すること
- 報告書の判定と集計が、証拠・仕様書の期待結果・決まったことの記録と矛盾しないこと（実施していない項目を合格と書いていないこと）
1つ目と3つ目の条件があったことで、実行ログと報告書を突き合わせ、差し戻す根拠にできました。
何かを提出する前に、「これができていれば完了」という条件を先に書いておく。そういう進め方もあります。自分で書いた条件でも、あとから自分を助けてくれます。
まとめ
- 作った担当は、自分の完了を宣言できないことにした
- 確かめる担当には、成果物・完了条件・根拠になる記録を渡し、作業中のやりとりは渡さない
- 飛ばしたテストを合格と数えた報告書が、差し戻された
- 報告してきた側は正しかった。判断せずに流したのは中継役の私だった
- 今回の差し戻しは、仕組みが働いた結果だった
次回は、このシリーズの最後です。ここまで「確認が大事」と書いてきましたが、その結果どうなったか。書類が増えすぎて、自分で読み切れなくなった話を書きます。
なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。
次に試してほしいこと
何かを提出する前に、「これができていれば完了」という条件を先に書いておく、という方法があります。提出したあとで、自分の書いた条件と突き合わせてみると、抜けが見えることがあります。