原稿検査工数の約7割を削減！ディップ初の自社開発AI「KENSER」チームにインタビュー
DXを推し進めるディップで初の自社AI開発を進め、求人原稿の審査を効率化する社内システム「KENSER（ケンサー）」を開発する藤本さん、土屋さん、若泉さん、坂井さんの4人にチームビルディングやプロジェクトの管理のコツ、目指したい未来を聞いてみました。
自社開発AI「KENSER」で求人原稿の表記検査を効率化
小島：KENSERとはどのようなシステムなのでしょうか？
藤本：KENSERは「求人原稿の検査AI」です。ディップではバイトルなど様々な求人メディアをもっているのですが、それぞれの求人原稿の表記検査（最低賃金のチェックや差別表記等が適正かどうかの検査）があります。この検査は広告審査室という部署が担っているのですが、古いシステムを使っていたため検査に時間がかかっていたり、違反の抽出漏れが多いという問題点もあったものの、改善が難しく何年も手付かずの状態でした。
そこで機械学習やデータ処理（自然言語処理など）を用いて、審査室の工数削減と未知の違反を見つけられるツールを作るため、KENSERの開発が始まりました。KENSERは求人原稿データをアップロードしてボタンを押すと、検査結果のファイルを返すツールで、人間でしか判断できないものは審査室がチェックし、本当にNGな求人原稿を修正依頼するフローになっています。
小島：具体的にはどれくらいの工数を削減できたんですか？
藤本：バイトルやバイトルNEXTでは、旧システムの処理時間が270分かかっていたところから23分への大幅削減を達成し、検査全体の工数は約70%の削減ができました。KENSERを使うことで、人の目でチェックしなければならないデータ量も半分ほどになり工数を減らせただけでなく、以前は見逃されていた違反も抽出できるようになりました。
無数にある求人原稿の判定を行う難しさ
小島：求人原稿を検査するシステムを開発する上で課題はどのようなものがありますか？
土屋：現在の判定ロジックで取りこぼしている違反を抽出しようと思うと、たくさんの壁がありました。具体的には、1つのNGワードを検出できるようにしようとすると不要なデータも多く出力してしまうトレードオフが発生してしまったり、無理に工数を削減しようとすると取りこぼしが多くなってしまったりするといった問題です。また、日本語は1つの意味を表現するのに複数の書き方がある言語です。よって、判定しなければならないテキストは何千何万通りもあるため、表記ゆれなどさまざまな可能性を考えてシステムを作っていかなければなりません。上記に加え、企画を立てる過程で審査室からヒアリングした要望をそのまま受け取るのではなく、法律やディップの編集ルールに照らし合わせ、本質的な課題を見つけて解決することを意識しました。
KENSERの多様なチームメンバー
小島：プロジェクトチームにはどのような方がいるのでしょうか？
藤本：社内の全媒体に関わる重要なプロジェクトですが、正社員4人+業務委託2人で進めています。一人一人が違うスキルを持っていて、それぞれが強みを活かして仕事をしています。
土屋（PdM・UXリサーチャー）：元審査室所属で、ドメイン知識と業務改善の経験を活かす業務ハッカー
藤本（PO・スクラムマスター、PdM）：AI周辺の技術知識と企画開発の経験を活かすマルチプレーヤー
若泉（バックエンドエンジニア） ：詳細設計から実装・提案をこなす開発リーダー
坂井（開発PM・インフラエンジニア）：テスト・インフラなどの開発知識を活かすチームのディフェンダー
小島：企画者とエンジニアが同じチームで開発できることはメリットが大きそうですね！逆に課題もあるのでしょうか？
土屋：KENSERのように判定ロジックの精度が肝となるシステムは、PdM（企画者）が新しい機能を考えても実現性がわかりません。例えば、あるパターンのテキストを違反として抽出したいとなった際に、理論的に実現可能か、処理時間に問題は出てこないかなど、PdMとエンジニアの両方の視点がないと仕様が決めきれないといった課題も抱えていました。
「チームメンバーがお互いになりきる」チーム全員でシステム開発していくための工夫
小島：そのような課題を乗り越えるために開発においてはどのように工夫されているんでしょうか？
若泉：僕たちエンジニアと企画者の全員で開発を進める工夫として、広告審査業務の知識に合わせてシステムを開発するということを心がけています。専門的には「ドメイン駆動開発」と呼ばれているものです。
PdMとエンジニアのコミュニケーションが難しいという課題はどのチームにも起こることだと思います。ドメイン駆動開発はその解決策の一つであり、広告審査業務の中の判定ロジック概念をFigmaで図に表し、それをそのままコードで表現することで、その概念図が共通の言語としてPdM・エンジニア間のコミュニケーションが取れるようになります。
小島：共通言語があることで、具体的にどういうメリットがあるのですか？
若泉: Figmaにシステム全体の概念図が書かれており、それを見ることで、コードを読まなくても視覚的にKENSERの大体の動きを理解することができます。そして、広告審査のルールを記述する部分をコード上ではなく、ロジックシート(csvファイル)として外から指示できるようにしているので、PdMが出力ファイルを見て、ロジックシートを触ることでロジックをチューニングすることができます。このように、チーム全体でロジックを試行錯誤できる体制となっています。
小島：全員で協力する体制ができているんですね！他に使っているツールはありますか？
若泉：ツールは基本、Figma(FigJam)とNotionを使っています。Notionにドキュメントとバックログがあり、みんなで管理しています。Figmaはアイデア出しホワイトボードとして使ったり、図示した方がわかりやすい設計を書いて使ったりしています。
また、プロジェクトの立ち上げ時にチームで作成したインセプションデッキ（プロジェクトのビジョンや方向性を示した、意思決定に用いるフォーマット）があるため、やることとやらないことが明確化され、PdMとエンジニアが同じゴールに向かっていくことができます。ミーティングでは、まずNotionをみんなで見ながらタスク確認をして、詳細設計について話すときは図示されているFigmaを確認します。仕様が誰にでもわかる形で置いてあることで、それぞれメリットがあり、会話のきっかけにもなっています。
小島：なるほど、ツールをうまく使ってドキュメントを残しているのですね！チームビルディングの側面ではどうでしょうか？
坂井：私たちが所属する組織は、基本的にフルリモートの人が多く、このチームも対面で全員集まったことが実はないんです。ですが、結構密にコミュニケーションを取れていると思います。ミーティングが頻繁にあるわけではないですが、社内で契約している音声チャットツールで会議のない時間でも話しかけて簡単な問題は解決してしまうこともあります。そのため限られたミーティングの時間には本当に必要な議題について話しやすい体制ができていると思います。すぐに相談できる雰囲気なので、決定までの時間が短縮でき、スピーディーに実装を進められます。
坂井：あとはチームメンバー各々が「お互いになりきる」ことを意識していますね。
小島：お互いがお互いになりきる……これはどういうことでしょうか？
坂井：本当にPdMがエンジニアになるといった意味ではないですが、チームの全員がロジックをわかる状態にすることで、みんなで意見を出して情報共有できるのでプロジェクトをスムーズに進められています。共通言語である概念図のおかげで、PdMは詳細設計にも意見を出せるので、エラーやロジックのミスが出たときに、どこを直せばいいかすぐわかるのが良いところだと思います。逆に、エンジニアは仕様ができるまで何も動かないなんてことはないですし、全員でプロジェクトを進める、という感覚が浸透しています。すぐ試してすぐフィードバックするのでストレスも少ないです。
API化して全社へ。パワーアップしていくKENSERの今後の展開
小島：最後にKENSERの今後の展開を教えてください！
藤本：今は審査室向けの業務効率化ツールとなっていますが、ここでチューニングされたロジックを、求人を作成するツールにAPIとして組み込むことで、原稿作成者がリアルタイムに検査結果が確認できる機能を開発する予定です。そうすることで求人数の増加や、新たなサービスにも対応することができます。なので、今のKENSERは審査室の業務を改善しつつも、会社全体からすると投資期間とも言えますね。
小島：ますます正確な求人原稿作成がしやすいシステムになっていきそうですね！今後どのような人がチームに入ってほしい！というのはありますか？
藤本：原稿作成をする管理画面へのロジック搭載や他の検査もやっていく中でプロジェクトが大きくなっていくので、リーダーシップを持ってプロジェクトを進めてくれるPjM（プロジェクトマネージャー）からエンジニアまで、また、求人原稿に一家言ある人やデータサイエンスがわかるけど企画もやりたい人など幅広く募集しています。たくさんの意見を検討しながら改善していくので、多様な視点で様々な可能性を考えられる人や疑問を恐れず言ってくれる人はとても活躍できると思います。
小島：ありがとうございました！
