メインコンテンツまでスキップ

経験を生かして新卒採用ツールを作ってみた(4) ~「見せない」機能を作り込んだ~

鶴田
ディアシステム(株)開発一部第2課

はじめに​

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

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

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

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

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

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

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

今回の対象読者​

  • 開発者が、何を考えてものを作っているのか知りたい方
  • 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つ変えて読み返す、という方法があります。「使う人だったら」「あとで直す人だったら」と決めてから読むと、同じ文章が違って見えることがあります。

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

未経験から始める
システムエンジニア

一生モノのITスキルを身につけよう

あなたの経験とスキルを
ディアシステムで発揮してください!