「開発プロセス」タグの記事が6件件あります

はじめに​

私は普段、システム開発の仕事をしています。その一方で、新卒採用ワーキングの一員としても活動してきました。どんな人を採用するのかを皆で話し合い、採用サイトをメンテナンスし、選考を進める。そんな役回りです。

そしてもう一つ。以前は、プライバシーマークの運用担当でもありました（今は情報セキュリティの管理の仕組み（ISMS）へ一本化するのに合わせて、認定を返上しています）。

採用活動が一段落した日、振り返りのために採用サイトからデータを出しました。その画面を見て、私の手は止まりました。

「このデータ、このまま使っていいんだっけ」

採用担当の私が「振り返りたい」と言い、個人情報の担当だった私が「待て」と言う。一人で会議が始まってしまいました（；^ω^）

この記事は、AIを使って何を作ったかより前の話です。その会議がどう決着して、なぜ道具を作ることになったのかを書いてみます。

結論だけほしい方はこちらの振り返りをご確認ください。

なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトではありません。実際の採用活動で運用するかどうかは未定です。

今回の対象読者​

• 開発者が、何を考えてものを作っているのか知りたい方
• AIを使った開発が、実際にはどんなところから始まるのか気になる方

今回は技術やAIへの指示の出し方は扱いません。作る前に、何を決めたのかという話です。

まず結論​

道具を作る前に、私が決めなければいけなかったことは二つでした。

• あとで何を振り返りたいのか
• 応募者から預かった情報をどう扱うのか

AIに相談したのは、その後です。何を作るか、何を守るか。この最初の判断だけは、人がやるしかありませんでした。

振り返りたいのに、材料が揃わない​

まず、採用担当の私の言い分です。

見たかったのは、「参加したイベントは応募につながったのか」「どの経路から来た方が選考を進んだのか」。こういうことを確かめて、次の活動を少しでも良くしたいわけです。

ところが、採用サイトから出てくるデータは、その問いにそのまま答えられる形ではありませんでした。必要な項目が分かれていたり、記録の仕方が途中で変わっていたり。

記録が残っていることと、振り返りに使えることは、別でした。

本来は活動を始める前に、「終わったあとに何を確かめたいか」を決めて、そのための記録を残しておくべきでした。毎年やっているのに、毎年ここで困っている。我ながらどうなんだという話です。

個人情報の扱いを、道具づくりでも確認する​

次に、個人情報の担当だった私の言い分です。

採用で扱うのは、応募者から預かった個人情報です。「あとで使うかもしれないから残しておこう」ができません。何のために預かるのか、いつまで扱うのかを、最初に決めておく必要があります。

それに、振り返りで見たいのは一人ひとりの名前ではありません。活動全体の傾向や、次に変えられそうなところです。

どの情報を記録するのか。何のために使うのか。誰が見られるのか。いつまで持つのか。この四つは、道具を作る段階から同時に考えるべきことでした。

まず、道具の役割を言葉にする​

会議の決着はこうです。振り返りに使える形で、最初から記録を残していけばいい。

そこで最初に考えたのは、画面の見た目や機能の数ではなく、この道具で何をしたいのかをできるだけ短い言葉にすることでした。

採用活動の進み具合を見られること。そして、活動が終わったあとに、次へ生かすための記録を残せること。この二つに絞りました。

連絡の機能も、通知も、分析の画面も思いつきました。でも全部やろうとすると、たぶん何も終わりません。

実務では、目的と守るものを先に決める​

仕事で何かを作るときも、「何のためか」と「何を守るか」を先に確認しておくと、途中で迷いにくくなります。

作り始めてからは、細かい判断が次々に出てきます。そのたびに立ち止まっていたら進みません。先に決めておいた二つが、そのときの物差しになりました。

これは、AIに手伝ってもらう場合でも変わりません。むしろ任せる範囲が広がるほど、最初に決めたことが効いてきます。

AIに相談したのは、そのあと​

ここまで決めてから、AIに相談を始めました。

最初から「採用管理ツールを作って」と頼んだわけではありません。自分が考えた目的や、守りたいことを伝えながら、必要な機能や進め方を一緒に整理していきました。

AIがいることで、考えを言葉にしたり、案を比較したりする作業は、はっきり進めやすくなりました。

ただ、何を記録するのか。何のために使うのか。個人情報をどう扱うのか。こうしたことは、AIに任せる判断ではありませんでした。

AIは、考えを形にするための相談相手でした。何を作るかを決めるのは、私の仕事でした。

まとめ​

AIを使った開発でも、最初に決めるべきことは変わりません。

• 何のために作るのか
• あとで何を確かめたいのか
• どの情報を、どのように扱うのか

次回は、こうして決めたことをもとに、AIとどのように小さく作り始めたのかを書いてみます。

なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。

このシリーズの他の記事​

• 第1回 採用とPマークの経験をつなげてみた
• 第2回 先が見通せないのでミニ版作ってみた
• 第3回 答えが出るまで、先に進まないことにした
• 第4回 「見せない」機能を作り込んだ
• 第5回 「出来ました」を、事情を知らない相手に確かめてもらった
• 第6回 作り終えてから、やり方を振り返ってみた

新卒採用の振り返りをきっかけに、進捗を管理しながら、次につながる記録も残せる道具を 作ろうと思いました。その経緯は第1回に書いています。

そこから、何を記録するのか、誰が見られるのか、いつまで持つのかを一つずつ決め、 設計としてまとめました。どう決めていったかは、第3回と第4回で書きます。

設計の上では、作るものの全体像が見える状態になりました。 次は、それを動くものにする番です。

ところが、そこで手が止まりました。しばらく、着手できずにいました。

今回は、そのときの話です。

結論だけほしい方はこちらの第６回の振り返りをご確認ください。

なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトでは ありません。実際の採用活動で運用するかどうかは未定です。

今回の対象読者​

• 開発者が、何を考えてものを作っているのか知りたい方
• AIを使った開発が、実際にはどんなところから始まるのか気になる方

開発の手順や道具の紹介はしません。進め方の話になります。

まず結論​

先が見通せなかったので、小さい版を先に作ってみました。

作るのにかかった時間は測れました。でも、いちばん大きかったのはその数字ではありません。

出来上がったものを確かめる中で、自分が見落としていた観点に気づけたことです。

小さい版を作るのは、一見遠回りに見えるかもしれません。それでも、確認して初めて気づけたことの方が大きかった。これが正直な実感です。

「どれくらいかかるか、まったく想像がつかない」​

本命のツールは、設計まで終わっていました。何を作るか、どんな画面が要るか、どんなデータを持つか。紙の上では一通り決まっています。

次は、それを実際に動くものにする番です。

ここで手が止まりました。この時点で、画面は20以上ありました。従来の開発なら、感覚として12〜13人月ほどの規模に見えます。

ただ、この規模のものをAIに手伝ってもらいながら作るのは、自分にとって初めてです。今回のやり方で、実際にどれくらいの時間がかかるのかは、まったく見当がつきませんでした。

従来の感覚で「12〜13人月ほど」と思っていても、根拠なしに「これくらいです」とは言いたくない。実際の業務では、見積もりには根拠が必要ですから。

そのまま、しばらく手をつけられずにいました。

ミニ版を作ってみた​

考えた末に決めたのが、小さい版を先に作ってみることでした。

機能をぐっと絞って、本命とは別に、小さなツールを作る。それにどれくらいかかったかが分かれば、少なくとも本命を考えるための手がかりにはなるかもしれません。

このとき最初に書いたメモは、4行だけでした。

# 目的

- 小さなプロダクトを作りたい。
- 今考えているのは

新卒採用、応募者のステータス管理ツール

これだけです。あとは、AIに手伝ってもらいながら進めました。設計を書いて、作る順番を決めて、実際に作って、直す。ひとつずつ進んでいきます。

夕方に書き始めて、翌朝には一通り動く状態になりました。

一晩で動いた。確認して分かったこと​

時間にすると約12時間でした。

ただ、この数字には但し書きが要ります。最初の4行のメモを書き始めてから、翌朝に一通り動く状態になるまでの経過時間です。実装だけの時間ではありませんし、寝てましたし(笑)。ずっと手を動かしていたわけでもありません。

それでも、正直に言えば驚きました。

AIに作ってもらった設計書を一通り確認し終えて、気づきました。

「これ、個人情報の目で見ていないな」

このツールが扱うのは応募者の情報です。預かったものを、いつまで持って、どうやって消すのか。誰が何を見られるのか。そういう観点で設計書を読み直すと、書かれていないことがありました。

思い返すと、そうなる頼み方をしていました。最初の4行のメモにも、そのあとの依頼にも、個人情報を守るという言葉は入っていなかったのです。

そこで、個人情報保護の観点だけでレビューをかけました。すると、重要度の高い指摘が6件出てきました。たとえば、

• 登録した応募者の情報を削除する機能がない
• 誰がいつ何をしたのかの記録が残らない

指摘の内容は、どちらも最初のメモや、そのあとの依頼に入っていなかったことです。だから、読んだときには「それはそうだ」と思いました。

そして、この気づきも修正も、さきほどの12時間の中の出来事です。記録を見ると、レビューをかけたのが夜の19時すぎ。削除する機能を入れたのが19時52分、操作の記録を残すようにしたのが19時58分でした。気づいたその晩に直しています。

ミニ版で得たもの​

ミニ版を作った最初の目的は、AIに手伝ってもらいながら作ると、どれくらいの時間がかかるのかを確かめることでした。

約12時間という記録は残りました。本命を考えるための、参考になる数字が得られました。

機能の数も、扱う情報も違うので、単純に比べることはできません。それでも、最初に考えていた12〜13人月という見立てに対して、大きく見積もっても当初の1/3程度には収まりそうです。これは重要な発見でした。

もう一つ得られたのは、最初の依頼に何を書くかで、確認できることも変わるという実感です。

今回のメモや依頼には、個人情報をどう扱うのかが入っていませんでした。そのため、削除の方法や操作の記録といったことも、設計を作った段階では見えていませんでした。

個人情報保護の観点で確認して初めて、その抜けに気づけました。

ミニ版を作って得たもののうち、いちばん大きかったのは、何を作るかだけでなく、何を守るか、どの観点で確かめるかも、最初に言葉にする必要があると分かったことです。

つまずきポイント​

出てきた設計書は、体裁が整っていました。見出しが並び、項目も揃っています。

そのため、読んだときの私には、書かれていないことよりも、書かれていることのほうが目に入っていました。

個人情報のことが気になったのは偶然です。そこで個人情報保護の観点から確認して、初めて抜けが見えました。

設計書が整っていることと、必要な観点で確認できていることは別でした。

実務ではどう考えるか​

やったことのない作業に、どれくらい時間がかかるか。正確に読める人はいないと思います。

そんなときは、全体を当てずっぽうで見積もる前に、一部だけ先にやってみるという進め方があります。進めてみて実際にかかった時間や、途中で詰まったところを確認し、見積もりを修正するわけです。私の場合もそうでした。

小さく試した結果を、そのまま全体に当てはめられるとは限りません。それでも、見積もりの根拠が増え、精度を上げることはできます。

見積もりに根拠を持たせることは、利益を確保することにも、無理な計画からメンバーを守ることにもつながります。だから私は、見積もりにはできるだけ根拠を持たせたいと思っています。

もうひとつ、AIに手伝ってもらって作ったものを確認するときは、どの観点で確かめるかを、AIに任せず自分で決める必要があると感じました。

今回でいえば、個人情報の観点です。仕事によっては、安全性かもしれませんし、費用かもしれません。

観点を決めないまま確認すると、今回の私のように、体裁の整った設計書を見て安心してしまうかもしれません。

まとめ​

• 設計ができても、AIに手伝ってもらってこの規模のものを作る時間は見通せなかったため、機能を絞ったミニ版を先に作った
• ミニ版は約12時間で一通り動いた。ただし、最初のメモからレビュー・修正までを含む経過時間であり、実装だけの時間ではない
• 成果物を確認する中で、個人情報の観点が抜けていると気づき、再レビューで重要度の高い指摘が6件見つかった
• 速く作れたこと以上に、何を守り、どの観点で確かめるかを最初に言葉にする必要があると分かった

次回から、本命ツールの作成に入ります。まずは、作る前の準備の話です。

今回、決めていないことを聞いても、AIは答えを返してくれました。便利な反面、そのまま進めると、自分では決めた覚えのないことまで決まっていきます。

次回は、その特性をどう扱ったかを書きます。

なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。

次に試してほしいこと​

やったことのない作業を頼まれたときに、全部をやる前に一部だけ試して時間を測る、という方法もあります。見積もりの材料が増えます。

このシリーズの他の記事​

• 第1回 採用とPマークの経験をつなげてみた
• 第2回 先が見通せないのでミニ版作ってみた
• 第3回 答えが出るまで、先に進まないことにした
• 第4回 「見せない」機能を作り込んだ
• 第5回 「出来ました」を、事情を知らない相手に確かめてもらった
• 第6回 作り終えてから、やり方を振り返ってみた

はじめに​

前回、実装にどれくらいかかるかを見通すために、機能を絞ったミニ版を作りました。

そこで得た手がかりをもとに、今度は本命の新卒採用ツールを作り始めました。

作り始めると、決めていないことが次々に出てきます。この画面は誰が見るのか。どの情報をいつまで持つのか。そういうことです。

まだ決めていないことにも、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つを書き残していたので、あとから理由をたどれて助かりました。

質問を溜めておいて、一度にまとめて相談する進め方もあります。相手の時間を細切れにせず、自分も待つ間に進められる作業を見つけやすくなります。

まとめ​

• 決めていないことにも案が返ってきて、そのまま決定として流れていきそうになった
• わからないことは表に残し、人が答えるまでは決まった扱いにしないことにした
• 問いごとに、誰が答えるか、決めた日、根拠を残すことで、設計までの経路をたどれるようになった
• 未決だからすべてを止めるのではなく、その答えに依存する工程だけを止めた

次回は、設計をいろいろな立場から見直した話を書きます。立場の違う視点を用意すると、自分だけでは見落としていたことが見えてきました。

なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。

次に試してほしいこと​

いま進めている作業で、まだ決まっていないことを書き出し、誰に聞けば答えが出るかを並べる方法もあります。

このシリーズの他の記事​

• 第1回 採用とPマークの経験をつなげてみた
• 第2回 先が見通せないのでミニ版作ってみた
• 第3回 答えが出るまで、先に進まないことにした
• 第4回 「見せない」機能を作り込んだ
• 第5回 「出来ました」を、事情を知らない相手に確かめてもらった
• 第6回 作り終えてから、やり方を振り返ってみた

はじめに​

就職活動で会社に提出した自分の情報が、そのあとどう扱われているか。私は作る側として、そこを決める立場になりました。

新卒採用の進捗を管理するツールを、AIに手伝ってもらいながら作っています。扱うのは応募者から預かった情報です。

前回は、決めていないことを表に出し、人が答えるまでは決定として扱わない進め方を書きました。今回は、その次に行った設計の見直しの話です。

今回は、その中であえて見せないことにした話です。機能を増やすのではなく、減らす判断をしたところを書きます。

法律の解説はしません。あくまで、自分のツールでどう決めたかという話です。

結論だけほしい方はこちらの第６回の振り返りをご確認ください。

なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトではありません。実際の採用活動で運用するかどうかは未定です。

今回の対象読者​

• 開発者が、何を考えてものを作っているのか知りたい方
• AIを使った開発が、実際にはどんなところから始まるのか気になる方

まず結論​

この個人開発では、登録済みの採用担当者・面接担当者なら、PCから応募者の情報を見られる形にしました。選考の基準を担当者どうしで揃えたかったので、見える範囲は分けていません。

ただし、スマートフォンからは応募者の基本情報を出さないことにしました。スマートフォンでできるのは、申し送りを読むことと書き足すことだけです。ただし、申し送りをたどるために氏名は表示しますし、申し送りの中身にも個人情報が入ることがあります。見える情報をゼロにしたわけではありません。

便利さを削るこの判断は、私が思いついたものではありません。立場を変えたレビューの指摘から出てきました。

1人で作っていると、自分の穴は見えない​

自分で作ったものを、私は自分の見方でしか見られませんでした。

チームで作っていれば、別の人が別の角度から見てくれます。今回は1人だったので、それがありません。私が見落としたものは、そのまま残ります。

そこで、レビューする立場を用意しました。

複数の立場からダメ出ししてもらった​

1人の目だけで読むと、見えるのは自分が気にしているところに偏ります。そこで、役割の異なる立場を用意し、それぞれの目線で要求をまとめた文書を読み直しました。

最初に用意したのは、次の7つです。

それぞれの立場を想定して、AIに要求をまとめた文書を読ませました。どの立場を用意するかを決めたのは、私です。

この7つから、56件の指摘が出ました。

その後、最初の7つだけでは十分に見られていない観点があると考え、4つの立場を足しました。個人情報保護・法務の担当、攻撃する側から見るセキュリティの担当、採用の責任者、リリース後に問い合わせを受ける保守の担当です。

足した4つは、要求の文書を最初から最後まで読み直しました。28件の指摘が出て、そのうち「これは見過ごせない」と判断したものが5件ありました。

1つの指摘が、機能になるまで​

「見せない」という判断がどう決まったのか、順を追って書きます。

① 指摘　使う側の担当と品質の担当から、「スマートフォン対応の範囲が、文書の中で一貫していない」と指摘が出ました。「申し送りを中心に対応する」とだけ書いてあって、応募者の基本情報まで見えるのかどうかが読み取れない、と。

② 課題にする　これを1行の問いとして起票しました。「今すぐ答えが要る」という印をつけています。

③ 決める　その日のうちに、私が決めました。スマートフォンでできるのは、申し送りの閲覧と追記だけ。応募者の基本情報の閲覧は含めない。登録も編集も取り込みも、PCからだけにする。

④ 文書と実装に落ちる　決めた内容は要求の文書に書かれ、設計に降り、最後は実装になりました。ツールには46の業務処理があります。スマートフォンから許可するのは6つ、サーバー側で拒否するのは37です。残り3つはログインより前の処理で、端末を判定する段階に入る前なので対象外になります。

指摘から実装まで、4段階あります。回りくどく見えるかもしれません。ただ、この段階があったので、今回の仕様変更は、どの指摘から来たのかを記録からたどれるようになりました。

決めたあとに、意味が追加された​

面白かったのは、このあとです。

3週間後、追加した個人情報保護・法務の立場から、別の指摘が出ました。「多要素認証を使わない前提なのに、スマートフォンから個人情報を含む申し送りを扱うリスクへの手当てが示されていない」。

パスワードだけで入れる作りなので、パスワードが漏れたらどうするのか、という指摘です。

ここで新しい機能は作りませんでした。すでに決めていた「スマートフォンからは申し送りだけ」という制限を、その手当てとして位置づけることにしたのです。端末の種類を判定できる範囲では、万一パスワードが漏れても、スマートフォンとして判定したアクセスで届く範囲は、申し送りまでになります。ただし、この判定そのものに限界があることが、あとで分かります。

「偽装できると分かったうえで」採った方法​

きれいな話ばかりではありません。

テストの設計をしている段階で、食い違いが見つかりました。非機能の文書には「スマートフォンの認証情報では応募者情報に到達できない」と書いてあるのに、設計のほうは画面の出し分けしかしていなかったのです。

そこでまた1行の問いが立ち、私が決め直しました。採ったのは、ブラウザが送ってくる端末の種類を見て、サーバー側で断る方法です。

ただ、この端末の種類は、利用する側で偽装できます。 端末の種類だけでは、応募者情報への到達を確実に止められません。

それを理解したうえで採用しました。効果が限定的であることは理解しつつ、何もしない理由にはならないと考え、指摘されたリスクは次のバージョンで対応する旨記録することにしました。

残ったリスクは、残ったものとして対応する旨を記録しました。「対策しました」で終わらせないことが、このときの線引きでした。

ほかにも「わざわざ不便にした」ところ​

同じような判断が、ほかにもあります。

氏名や連絡先などは、復元できない値に置き換えます。 保持期間を過ぎた記録そのものを消すのではなく、個人が分かる項目を置き換える、というやり方です。このとき、元に戻す操作をそもそも作りませんでした。「戻せる」ということは「残っている」ということだからです。

操作の記録に、氏名やメールアドレスを残しません。 誰がいつ何をしたかは記録します。ただし、操作の対象になった応募者は、氏名やメールアドレスではなく内部番号で記録します。氏名まで記録すると、せっかく置き換えた情報が記録のほうに残ってしまいます。

その操作記録を見る画面やAPIも、作りませんでした。 閲覧のための機能を増やすこと自体が、情報に届く経路を増やすからです。

どれも、あれば便利なものです。便利さを削った分の理由を、記録に残すようにしました。

つまずきポイント​

正直に書いておくと、指摘を受けても変えなかったものもあります。

置き換えたあとも、残る項目があります。郵便番号、性別、出身校、卒業年度、国籍などです。個人情報保護・法務の立場からは、「これらの組み合わせによって、統計的に個人が再識別されうる」という指摘が出ていました。

それでも、分析に使うために郵便番号は7桁のまま残す判断をしました。リスクがあると分かったうえで、受け入れたということです。その経緯も記録に残しています。

便利さと安全のどちらも満たす正解を、私は見つけられませんでした。できたのは、どこで線を引いたかを説明できるようにしておくことです。

実務ではどう考えるか​

私にとって指摘は、否定というより、自分では見直せないところを見直してもらう手続きでした。

とはいえ、自分の作ったものに指摘が来ると、身構えます。私もそうでした。立場を分けておくと、少し受け止めやすくなりました。「個人情報保護の担当として見ると」という前置きがあるだけで、人への評価ではなく、成果物への指摘として読めるからです。

自分の作ったものを、立場を1つ変えて読み返す。そういう方法もあります。レポートでも、資料でも、同じことができます。

まとめ​

• 1人で作っていたので、自分の見落としに気づけなかった。だから立場を分けてレビューした
• 7つの立場から始めて、あとから4つ足した。足した4つから、見過ごせない指摘が5件出た
• 1つの指摘が、課題になり、要求になり、実装になった。スマートフォンから実行できる処理は、46のうち6つだけ
• 効き目が限られると分かったうえで採った対策もある。残ったリスクは残ったものとして書いた
• 指摘を受けても変えなかったものもある。大事なのは、どこで線を引いたかを説明できること

次回は、作り終えたあとの話を書きます。「できました」と言った本人ではなく、事情を知らない相手に確かめてもらう仕組みで、私自身の取りこぼしが見つかった、という話です。

なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。

次に試してほしいこと​

自分の作ったものを、立場を1つ変えて読み返す、という方法があります。「使う人だったら」「あとで直す人だったら」と決めてから読むと、同じ文章が違って見えることがあります。

このシリーズの他の記事​

• 第1回 採用とPマークの経験をつなげてみた
• 第2回 先が見通せないのでミニ版作ってみた
• 第3回 答えが出るまで、先に進まないことにした
• 第4回 「見せない」機能を作り込んだ
• 第5回 「出来ました」を、事情を知らない相手に確かめてもらった
• 第6回 作り終えてから、やり方を振り返ってみた

はじめに​

「できました」と言われたとき、それをどう扱うか。

新卒採用の進捗を管理するツールを、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つ目の条件があったことで、実行ログと報告書を突き合わせ、差し戻す根拠にできました。

何かを提出する前に、「これができていれば完了」という条件を先に書いておく。そういう進め方もあります。自分で書いた条件でも、あとから自分を助けてくれます。

まとめ​

• 作った担当は、自分の完了を宣言できないことにした
• 確かめる担当には、成果物・完了条件・根拠になる記録を渡し、作業中のやりとりは渡さない
• 飛ばしたテストを合格と数えた報告書が、差し戻された
• 報告してきた側は正しかった。判断せずに流したのは中継役の私だった
• 今回の差し戻しは、仕組みが働いた結果だった

次回は、このシリーズの最後です。ここまで「確認が大事」と書いてきましたが、その結果どうなったか。書類が増えすぎて、自分で読み切れなくなった話を書きます。

なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。

次に試してほしいこと​

何かを提出する前に、「これができていれば完了」という条件を先に書いておく、という方法があります。提出したあとで、自分の書いた条件と突き合わせてみると、抜けが見えることがあります。

このシリーズの他の記事​

• 第1回 採用とPマークの経験をつなげてみた
• 第2回 先が見通せないのでミニ版作ってみた
• 第3回 答えが出るまで、先に進まないことにした
• 第4回 「見せない」機能を作り込んだ
• 第5回 「出来ました」を、事情を知らない相手に確かめてもらった
• 第6回 作り終えてから、やり方を振り返ってみた

はじめに​

新卒採用の進捗を管理するツールを、AIに手伝ってもらいながら作りました。システム開発における一般的な手順を一通り通し、完成までたどり着きました。

ここまでの回では、確認の仕組みについて書いてきました。決まっていないことは表に出す。いろいろな立場から見直す。終わったかどうかは別の人が確かめる。

その結果どうなったかを、今回は正直に書きます。一言でいうと

書類が増えすぎて、自分で読み切れなくなりました！

なお、ここで紹介するツールは個人開発として作ったものであり、当社のプロダクトではありません。実際の採用活動で運用するかどうかは未定です。

今回の対象読者​

• 開発者が、何を考えてものを作っているのか知りたい方
• AIを使った開発が、実際にはどんなところから始まるのか気になる方

手順の解説ではなく、振り返りと直し方の話になります。

まず結論​

確認を大事にするためにルールを作った結果、成果物が自分で確認し切れない量になりました。

そこで、ここまで使ってきた、AI向けの開発フローそのものを見直しました。人が承認する対象を、分厚い文書そのものから「前回から何が変わったか」の要約へ変え、数えたり突き合わせたりできることはスクリプトに任せることにしました。

作り終えた。そして、書類の山が残った​

全部の工程を通し終わったのが、作り始めてから約1か月後でした。

そのとき手元に残っていた主な文書です。

表にない文書も含めると、全部で1.2MBほど、行数にすると8,000行を超えます。ボリューム的に言うと５０万文字、ググると１ＭＢで小説１冊あるんですって（笑）

自分で決めたルールなのに、読み切れなくなるとかダサいなー（；^ω^）

しかも・・・１名＋ＡＩでこのボリュームですからねー２名以上のチームだったら概要設計フェーズでパンクするでしょうね。

当時の記録には、「成果物は人がチェックできる量を超えており、AIが読み切る上限にも達している」との指摘が残っています。ただ、後半（AIが読み切る上限）については、いつ、何が起きたという記録が残っていません。確かなのは、私が読み切れなくなっていたことです。

手元にあるのは５０万文字の成果物です。ここから原因を分析し対策を立案していきます。

原因分析：なぜ増えたのか​

原因を4つに整理しました。

① 同じ決定を、何度も書いていた　1つ決めると、その内容がいくつもの文書に書きこむ仕組みになっていました。調べてみたら、6つの決定が、18の文書に165か所書かれていました。同じ内容を何度も書かないためのルールは組み込んでいました。しかし、守られているか確かめる仕組みがありませんでした（AIがルールを無視している可能性が高いと感じ、調査しましたが記録からは断定できませんでした）。

② 決まるまでの経緯が、文書の本文に混ざっていた　課題の番号、「保留」「解決済み」といった状態の言葉、長い改訂の履歴。こういうものが、成果物の本文に積み上がりました。

③ 1つの工程を、1つの大きなファイルにまとめていた　ＡＩに依頼する際は、機能ごとに分けて依頼してますが、概要設計書、詳細設計書はそれぞれ１つにまとめていました。書くほうも読むほうも、毎回全体を相手にすることになります。

④ 「ここまで書けば完了」の上限がなかった　完了の条件は「実装で迷わない粒度」でした。よーく考えてみると、このルールは書き足す方向にしか働きません。足りなければ不合格になりますが、多すぎても不合格にはならないからです。

そして！対策！

対策１：承認するものを「文書」から「変化」に変えた​

いちばん大きく変えたのは、承認の単位です。

これまでは、分厚い文書そのものを私が読んで承認していました。これを、前回承認したときからの追加・変更・削除と、まだ決まっていないことをまとめた要約で承認する形に変えました。

文書はこれからも作ります。ただ、承認の場で中心に見るものを、文書全体から「何が変わったか」へ変える、ということです。

この変更に合わせて、文書の作り方と確かめ方も変えました。

そして読む単位を小さくし確認できる状態を保つために、300kb近くになった詳細設計書は、共通部分と機能ごとのファイルに分けることにしました。ファイルの大きさにも目安を置くようにし、超えた場合はアラートを出すようにしました。

対策２：文書の食い違いを、スクリプトで見つけるようにした​

今回の進め方では、「決めたことが下流の文書にも反映されているか」を、私やAIが文書を読んで確かめていました。改善後は、成果物の構造化に取り組み、決定事項は仕様決定番号を振ったうえで「決定一覧.md」へ、ほかの文書は本文中に仕様決定番号と改訂番号を添えるようにしました。

例えば「実装言語はpythonとする」という仕様を決めたときは、設計書に

実装言語はpythonとする（D-001:r1）

と記載します。そして、決定一覧（新設）と改訂記録一覧（新設）に以下の通り記載しておきます

決定一覧

改訂記録

と記載しておきます。最新の仕様は決定一覧に、経緯と履歴は改訂記録に分けて記載することで重複を防ぎ仕様から設計をたどれるようにしました。

こうしたことで、どの文書のどこで使われているかを、スクリプトで追えるようになりました。

その結果、決定一覧と文書の値が合っているか、必要な文書に決定番号が現れているか、参照先のファイルや節が存在するかを確認できます。

人やAIが文書を読み比べて数える代わりに、数える、突き合わせる、存在を確認するといった作業をスクリプト＋ＡＩに任せられるようになりました。

対策3：HTMLとリンクで、必要な場所までたどれるようにした​

決定を1か所に集めても、承認するときにその決定や文書の該当箇所まで戻れなければ、確認しやすくなったとは言えません。

そこで、承認資料はHTMLで作ることにしました。要約にある決定番号、文書名、節番号から、それぞれの該当箇所へリンクでたどれるようにします。

同じ決定を各文書に書き写すのではなく、決定一覧を正本にして、必要なところから参照する形にしました。文書全体を読み直さなくても、気になった決定や根拠へ戻れるようになりました。

改善した進め方を、小さく試した​

改訂した進め方は、引数の合計を出す小さなコマンドラインプログラムを作る案件で、最初から最後まで試しました。

承認では、文書全体ではなく変更の要約を読む形にできました。決定は一覧に集め、決定番号の食い違いや、参照先の誤りをスクリプトで見つけられるようにもなりました。

特に重かった後半の確認は、１／３まで減りました。確認する内容を減らしたのではなく、直前の工程から変わっていないものを繰り返し読まないようにした結果です。

今回の検証だけで、どんな案件にも使える進め方になったとは言えません。それでも、人が読むところと、機械が確かめるところを分けることで、確認できる量に近づける手がかりは得られました。

実務ではどう考えるか​

手順は、使ってみてから直すところが見えてくるものだと感じました。

今回、直す場所を決められたのは、文書の量、同じ決定が書かれた回数、確認表の行数、テストの結果が記録に残っていたからでした。感覚だけだと、「なんとなく大変だった」で終わっていたと思います。

私の場合は、作り終えたあとに一度立ち止まり、改善した手順を小さな案件で試す形にしました。それでも新しい問題は出てきます。だから次の案件でも、成果物の量や確認にかかった時間を測り、また見直すつもりです。

まとめ​

• 確認を大事にした結果、成果物が自分で読み切れない量になった
• 原因は、決定の書き写し、経緯の混入、大きな1ファイル、完了条件に上限がないことだった
• 承認の対象を文書全体から「前回からの変化」の要約へ変え、数えられる確認は機械に任せる形にした
• 小さな検証用の案件でも、１／３まで減らせた
• 改訂後の進め方が大きな案件でも働くかは、次のプロダクトで確かめる

このシリーズは今回で終わりです。全6回、AIに任せる部分と、人が決める部分をどう分けたかを書いてきました。任せる範囲が広がるほど、人が決めるルールと確認が効いてくる、というのが一貫した実感です。

なお、このツールは会社のプロダクトではありません。自分の手で一通り作ってみるための個人開発です。実際の採用活動で運用するかどうかは未定です。

次に試してほしいこと​

自分の作業手順を1つ選んで「やめてもよいこと」を探す、という方法があります。増やすより難しいのですが、そのぶん効きます。

このシリーズの他の記事​

• 第1回 採用とPマークの経験をつなげてみた
• 第2回 先が見通せないのでミニ版作ってみた
• 第3回 答えが出るまで、先に進まないことにした
• 第4回 「見せない」機能を作り込んだ
• 第5回 「出来ました」を、事情を知らない相手に確かめてもらった
• 第6回 作り終えてから、やり方を振り返ってみた