ハッカソンでのアイデアを元に開発された新機能！？〜「AIレビュー機能」に関わったメンバーによる座談会〜
LAPRASでは6/28に「AIレビュー」の機能をリリースしました。ITエンジニアの技術記事を5点満点で採点し、評価コメントを生成する機能は、エンジニアの皆様にも好評をいただいております。
実はこの機能はGW明けに社内で実施された「ハッカソン（一定の期間でサービス開発を行い結果を競うイベント）」がきっかけで生まれた機能ということで、今回はハッカソンチームのメンバーと、その後の開発を担当したメンバーに座談会形式で当時を振り返って、話をしてもらいました。
Salesメンバーのアイデアから出発したハッカソン
ーまずは、ハッカソンでアイデアを出したチームに話を聞いてみました。
登場メンバー（座談会なので社内での呼称をそのまま採用しています）
⚫︎エンジニア・naga3
⚫︎ユーザーサポート・本庄さん
⚫︎セールス・池ちゃん
池ちゃん：実は最初はハッカソン大会に出るのを迷っていて、エンジニアでもない私なんかが出て良いんだろうか…という不安を抱えていました。その不安を会社のSlackに書いてみたら、エンジニアのkotoneさんが1on1で一緒にアイデアを整理してくれて、背中を押される形でハッカソン大会に出てみることにしました。
本庄さん：まずは運営サイドが用意したFigmaでアイデア出しをしました。そのアイデアを精査する中で「ハッカソンだから、完成させないといけないよね」という観点で、池ちゃんのアイデアが一番実現の可能性があり、かつ完成後に実際にプロダクトにも組み込める可能性も高いと思われたので、ハッカソンでやるならこのアイデアだという話になり、池ちゃんのアイデアにしました。
池ちゃん：当時は私が「スカウトメールを書くのに、エンジニアのアウトプットを読み解くのが大変」だという採用担当の方の負担を減らしたいという気持ちがあり、当初のアイデアでは「エンジニアの方のアウトプットを読み解く採用担当の方向けに、アウトプットのレベルや価値がわかりやすくする」というものでした。
本庄さん：最初の池ちゃんのアイデアは「１つの記事からエンジニアのスキルを評価する」というスコープだったのですが、１つの記事でエンジニアの方のスキルや能力を総合的に評価をするのは難しいので、１つ１つの記事自体を、複数の観点で評価するというスコープに絞り込みました。
池ちゃん：その後、本当に今回のハッカソンの3日間で作れるものかを検証するためにnaga3にお願いして実際にChatGPTを触ってもらい、その画面を見ながら「あ！行けそう！」という実感を得られたので、そのテーマで進むことにしました。
非エンジニアメンバーでプロンプト開発に挑戦
naga3：1日目にテーマが決まって、各個人でタスクを持ち帰ることになり、自分がフロントの部分を開発して、ChatGPTのプロンプト開発は本庄さんと池ちゃんにお願いすることになりました。
池ちゃん：当時はLLMについてあまり理解しておらず、「プロンプト開発」という単語も知らなかったので、メモに「日本語のセットを用意」って書いてありますね…笑
本庄さん：プロンプトはかなり試行錯誤しました。記事が長かったのでそこの処理をどうするかだったり、入力内容が同じでも違う結論が返ってくるのをどうするかであったり、通常の業務の間に時間を作っては、池ちゃんとそれぞれ試行錯誤を繰り返しました。
池ちゃん：プロンプト開発はある程度本庄さんが土台を作ってくれて、その後にアレンジを加えていったのですが、非エンジニアでも土台があれば開発ができることはLLMの凄さだと思いました。一方で、土台のプロンプトから作るのは、まだ難しいんだなというのも実感しました。
本庄さん：LLMではそれなりの答えが返ってきてしまうが故に、自分でも正解がわからない「記事の評価」の「確からしさ」をどう評価するのかという、"品質保証"の難しさを感じました。また、普通のソフトウェア開発と違って、プロンプトによっては急に今まで出来ていたことができなくなったりして、築き上げたものが失われるのはプロンプト開発の辛い点だと思いました。
naga3：自分はプロンプト開発を２人に任せて、デモ用のプロダクト側の開発を進めていました。本当はChatGPTとAPIで接続しようと思っていたのですが、真面目に作るとハッカソンの期間内に作り終わらないと判断して、ダミーのセットを作って進めたのが結果として良かったと思います。やっぱり、ハッカソンは完成することが大事なので。
池ちゃん：一晩明けた時に、デモ環境でLappleくん（LAPRAS内のキャラクター）にnaga3によってアニメーションがついていて、正直LLMの中身よりそのアニメーションのインパクトでハッカソンに勝てたんじゃないかと思いました笑
本庄さん：あれはインパクト凄かったですね笑
ハッカソンを通して味わえたもの
naga3：この3人は業務で普段関わらないメンバーなので、新鮮で楽しかったですし、エンジニアではない2人が最後の最後までプロンプトの改善に取り組んでくれて、頼もしかったですね。
池ちゃん：私も同じで、普段関わらない違う３人で取り組むのがとにかく新鮮で楽しかったです。また、自分がやりたいことを本庄さんが要件に落とし込んでnaga3が開発してくれて、自分がやりたいことを精一杯伝えれば、技術的なところはチームの他のメンバーがカバーしてくれる関係性が、本当にありがたかったです。
本庄さん：今回3日しか期間がなかったのですが、短期間でどんどん機能が出来ていくのはすごく楽しかったです。普段ビジネスサイドだと、改善案を出すことはあっても、０からものづくりを経験することはないので、改めてプロダクト開発は面白いと思いました。
池ちゃん：あとは、最終的にリリース後にユーザーさんが喜ぶ声を聞けたことはとても嬉しかったですね。また、開発の大変さを知ったが故に、あんなに安定したものを作れる開発チームとR&Dチームに尊敬の念を抱きました。ハッカソンがなければ、このような機会もなかったと思うので、ハッカソンを企画してくれたR＆Dチームには感謝しています。
ハッカソンのアイデアを受けてからのAIレビュー機能の開発
ーハッカソンのアイデアを受けて、実際に開発したメンバーにも話を聞いてみました。
登場メンバー（座談会なので社内での呼称をそのまま採用しています）
⚫︎R&Dチームマネージャー兼PdM・nunukiさん
⚫︎開発チームエンジニア・naga3
⚫︎開発チームエンジニア・deugiさん
nunuki：今回ハッカソンを企画した目的は、社内のメンバーに対して、従来のAI開発のイメージを払拭してもらい、LLMで"できること"の解像度を上げてもらうことで、事業開発のアイデアを社内でより気軽に話せるようになることだったので、Aチームのようにポジティブなリアクションがもらえるのは、企画したR＆Dチームとしても嬉しいですね。
ハッカソンによって技術的な可能性は見えたので、ハッカソンで得られた知見を参考にしながらも、機能の位置付けやUXを整理して、１から設計し直しました。開発体制としては、LAPRASのサービス開発を行う開発チームと、LLMのプロンプティングなどAI開発を行うR＆Dチームで分担して行いました。
nunuki：当初は採用担当の方向けの機能を想定していましたが、ユーザーの方が自分に対するレビューに納得してくれていないと、それを勝手にLAPRASが採用担当の方に見せる訳にはいかないという観点もあり、どういう形でリリースするのかは社内で再度検討しました。
一方で、社内のエンジニアから「これはエンジニアが自分で見る方が面白いのではないか？」「アウトプットのモチベーション維持に使えそう」という意見もあったことから、最終的にエンジニアの方が自分のアウトプットをレビューできる機能として、開発を進めました。
naga3：実際の開発期間は1ヶ月くらいだったので、LLMがあるとこんなに早く開発が進むというのは衝撃的な体験でした。また、自分は開発チームとしてフロントの部分を作ったのですが、同時にR＆Dチームがプロンプトを精密に作ってくれたことにより、ハッカソンの時に絵を描いてはいたものの作りきれなかった部分が、しっかりと実装されているのは感動しました。
deugi：LLMを使って、開発チームとR&Dチームが共同で開発するのは初めてだったので、開発チームでは機能を作るだけではなく、インフラ周りも含めた全レイヤーを触る必要があったので、そこはチャレンジングで面白かったです。一方で、SRチームやR&Dチームとそれぞれコミュニケーションを取る必要があるため、そこは普段の開発より大変な点でもありつつ、楽しい点でもありました。
nunuki：R＆DチームはAIレビューのエンジン部分の開発を担当しましたが、LLMを使うことで、1つのプロンプトでスコアの数値だけでなく「レビューコメント」も同時に出力できるようになったことは大きいです。さらに面白いことに、スコアの数値だけを出力するよりも、数値の根拠としてレビューコメントも一緒に出力させた方が、スコアの数値が正確になることもわかりました。従来のAIの常識では、スコアの数値よりもコメントを出力する方が遥かに難しいため、AI開発者としては「まずは簡単なスコアを出力するところから」と考えてしまいがちですが、この結果はこれまでの常識を大きく覆すものでした。LLMを用いた開発では、これまでのAIの常識を手放す「アンラーン」が重要であると実感した瞬間でした。
その点、「従来の常識」を持たない本庄さんや池ちゃんがハッカソンでスコア・コメント同時出力の可能性を示してくれたことで、R&Dチームとしても従来の常識をアンラーンすることができたのではないかと思います。
deugi：R&Dが提供するライブラリのインターフェースが最初からしっかり決められていて、そこは変わらずにバージョンがどんどん上がっていくので、ライブラリを使う開発チームとしては心配せずに開発ができたのは非常に良かったです。
naga3：今回はSRチームにもかなりインフラ周りで協力してもらったのですが、そこでもそれぞれの責任範囲がしっかりしていたので、開発チームとしては助かりましたね。
R&Dチームとの交流で開発チームが得たもの
nunuki：開発チームでは、普段の開発からプロジェクト全体のタスクの依存関係の図をFigma（FigJam）上で作るようにしていたので、R&Dチーム側のタスクもその図に埋め込んで進めました。AIを用いた開発は不確定性が大きく、Redmine のようなプロジェクト管理ツールではタスクや依存関係の変更に追従しづらいため、フリーハンドで描けるFigJamでのタスク管理は重宝しました。
一方で、フリーハンドのタスク依存図はメンテしなければすぐに破綻したり陳腐化してしまうため、同期でのコミュニケーションを重視し、毎朝の定例で依存関係や順番を全員で見直しつつ進めました。結果としては、過去の開発と比べても両チームの連携がスムーズに進み、1ヶ月という短い間での機能開発に繋がったのではないかと思います。
deugi：R&Dチームが使っている「Design Doc」が非常に良くて、これは開発チームでも真似したいと思いました。
nunuki：R&Dは少人数でやっているので、Design Docに、プロジェクトの情報を全て集約するようにしています。プロジェクトの初めに背景やスコープやメトリクスを記入し、フェーズに分けて開発の目標や進捗や成果を記入し、プロジェクトの情報が全てこのドキュメントを見ればわかるように情報を集約して管理していますね。
deugi：開発チームではFigmaの図やGitHubのissueでタスクを管理しているのですが、時間が経つと情報が分散して振り返りがしづらいという問題があるので、デザインドックで一枚のドキュメントにまとめておけば、後からでも見返しやすくて良いなと思いました。
nunuki：スコアやコメントの客観性や納得感については、かなり力を入れて開発した部分で、リリース前に実際に何人かのユーザーの方に作ったものを見て感想をいただいて、修正を細かに繰り返していました。そのような前提があったので、実際にリリースして、ユーザーの方から割とポジティブな感想が多かったのには安堵しました。
deugi：SNSでユーザーの方の声を見ていて、かなりポジティブな反応が多くて、ユーザーの方に求められた機能を出せたのではないかと思い、そこは非常に嬉しかったです。
naga3：AIから評価されることに対してポジティブな評価が多く、AIが受け入れられる時代に変わったんだなと思いました。今後もユーザーの方に喜んでいただけるような、機能が出せるように頑張ります。
nunuki：ハッカソンでのアイデアがあってこそ、短期間での開発ができたので、ハッカソンのメンバーには本当に感謝しています！！
今回は、AIレビューのアイデア〜開発までに、関わったメンバーに座談会形式で話を伺いました。社内のハッカソン大会から、色々な人の思いを載せて作られた新規機能、ぜひまだ未体験の方がいたら、ぜひ体験してみてください。
LAPRASでは今後も発信を続けていくので、ぜひnoteやX（旧Twitter）のアカウントをフォローいただけると幸いです。
＜この記事を読んだ方へのおすすめ記事＞
＜LAPRASのその他のサービス紹介＞