はじめに
こんにちは！ 株式会社BuySell Technologiesのテクノロジー戦略本部で24卒エンジニアをしている賀来と相曽です。
バイセルでは、入社後に毎年新卒エンジニアをチーム分けして「プロダクト開発研修」というものを行っています。
2024年は新卒エンジニアが8人おり、今回は2チームに分かれて開発しました。 この記事では、プロダクト開発研修とはどのような取り組みなのか、研修の中で各チームがそれぞれどんなプロダクトを開発したのかについて説明します。
プロダクト開発研修とは
まず、バイセルのテクノロジー戦略本部の新卒研修であるプロダクト開発研修について説明します。 新卒エンジニア研修というと、座学ばかりという印象を持たれる方が多いのではないでしょうか。 しかし、バイセルのプロダクト開発研修では、実際に手を動かして業務の課題解決や全社を巻き込んだ新たなプロジェクトの立ち上げを行っています。
プロダクト開発研修の目的は次の2点です。
1.ユーザの課題を解決するまでのプロセスを学ぶ
エンジニアの仕事は、技術の力でユーザーの課題を解決することです。ユーザーが抱える本質的な課題を発見し、どのような課題をどのようなプロダクトで解決するべきか、解決までのプロセスを理解することが大切です。
2.リーダーシップとチームワークの重要性を学ぶ
会社において仕事はチームで進めるものであり、一人で仕事はできません。チームの中でどのような役割分担をし、どのようなリーダーシップを発揮するべきか、そして協力して課題を解決する重要性を学びます。
プロダクト開発研修では、まず初めにテーマが与えられ、ゼロからアイデア出し、ユーザーヒアリング、要件定義、開発、ユーザーフィードバックの収集、それを受けての改善などを行います。 新卒でプロダクト開発を初期段階から経験したことのあるメンバーは少ないので、もちろん進めていく上で多くの先輩エンジニアから助言をもらいながら開発していきます。
また、テーマの深掘りや課題の発見はエンジニアだけで行うのではなく、バイセルグループ内の事業部のメンバーにヒアリングやアンケートで情報をもらいながら行っていきます。
さらに、期間内だけ取り組んで終わりではなく、最終発表でCTOから採用/不採用の判断が下されます。 採用されたプロダクトは、プロダクト開発研修期間の1ヶ月が終わった後もフィードバックをもらいながら開発が続いていきます。 「業務に活かせるものを作る」という目的と、作って終わりではなくそれがスタートラインであるというエンジニアとしての心構えを学べる内容となっています。
この記事を読むことで、バイセルで行う新卒エンジニア研修への理解を深め、バイセルが大切にするエンジニア像について知ってもらえれば幸いです。
Aチームの取り組みについて
Aチームは、社内の訪問買取音声をAIで文字起こしし、音声の振り返りを簡単に行えるようにするプロダクトを開発しました。
背景
今回発表されたテーマは「生成AIを用いて社内の困りごとを解決するサービスの開発」というものです。 かなり抽象的なテーマであったため、まず私たちは各事業部が抱えている課題について仮説を立てていきました。 入社後1週目に行われた全社研修で各事業部の説明はありましたが、具体的な業務内容やどんな課題を抱えているのかまでイメージしきれていない状況だったため、推測で課題を出すのに苦労しました。
ヒアリング
なんとか立てた仮説を元に各事業部へヒアリングを行っていきました。 その結果、私たちはイネーブルメント部という部署に注目しました。 イネーブルメント部は、訪問買取を行うフィールドセールス部の教育を担当しています。 イネーブルメント部の業務の1つとして、新卒社員や中途入社社員が訪問買取を行っている実際の音声をヒアリングし、改善点をフィードバックするということを行っています。
流れとしては以下のようなフローになります。
音声の長さにもよりますが、スプレッドシートにフィードバックを作成するまでに最低でも3時間ほどかかっており、1日で2人分のフィードバックが限界という状況でした。
主な課題としては以下の2点です。
- 1訪問の分析〜フィードバックの作成に時間がかかる
- フィードバックの作成者がスクショを渡すというコミュニケーションの非効率性
そこで私たちは、この作業を生成AIを使って効率化するプロダクトを開発できないかと考えました。 研修期間を考慮し、今回は「1訪問の分析〜フィードバックの作成に時間がかかる」という課題に絞って着目しました。
具体的にフィードバックの作成では、以下の2点に時間がかかっていました。
- 課題を抽出するために、音声を一度通しで聞く必要がある
- 課題の箇所を聞き直すために、任意の再生時間を探す必要がある
課題に対するアプローチ
分析からフィードバックまでにかかる時間を大幅に短縮するための手法として、以下の2点を考えました。
- 音声データを可視化する
- いつでもすぐに任意の場所を再生できる
プロダクトの処理の流れは以下のようになります。
音声データが可視化され、任意の場所から再生できることにより、大幅な時間削減が見込めるのではないかと考えました。
開発手法・技術選定
音声データの文字起こしと、文字起こししたデータの要約にはAIモデルが必要になります。
音声データの文字起こしサービスとしては、OSSとしてモデルのダウンロードが可能なOpenAI社のWhisperを採用しました。
Whisperのモデルとしては、tiny、small、medium、largeなど複数のモデルがあり、高精度になるほど音声解析に時間がかかります。 実際の音声で検証した結果としても、モデルによってかなり文字起こしの精度に差が出ました。 今回は音声の解析にリアルタイム性が求められていないため、解析時間よりも文字起こし精度の高さを優先して Faster-Whisper large-v3 を採用しました。 large-v3は2023年11月に公開されたモデルで、2024年5月時点では最も高い精度のWhisperモデルです。
文字起こししたデータを要約するために、会社で保有していたオンプレサーバーでローカルLLMを動かすという手法を取りました。本来なら高精度なOpenAI APIなどを使用したかったのですが、お客様と従業員の訪問買取音声を扱うため、セキュリティ面を考慮してローカルLLMを使用しました。 様々なローカルLLMモデルを検証しましたが、どれも満足のいくような精度は得られず、OpenAIをはじめとするクローズなAIモデルの精度の高さを実感しました。
結局ローカルLLMのモデルとしては、lightblue_suzume-llama-3-8B-japaneseを使用しました。 こちらは2024年4月18日に発表されたLlama3を日本語ファインチューニングしたモデルです。
その他の使用技術・インフラ構成は以下の通りです。
成果
実際の業務で使用してもらったわけではないので正確な数値はわかりませんが、デモを触ってもらった結果、以下のような効果が見込めるとイネーブルメント部からフィードバックをいただくことができました。
- ひとりあたりにかかるフィードバック作成の時間を50％から75％軽減
- それにより1日でフィードバックできる人数が2人から5人に増加
また、セールスイネーブルメント部の業務としては、週2日教育対象者の訪問買取に同行し、現場での教育も行っています。フィードバック時間の短縮により、同行機会の増加も見込めるとのことでした。
- フィードバック時間の効率化により同行日数を2日から3日に増加
- 同行により平均買い取り額が増加するため、その分会社の利益も増加
テクノロジー戦略本部への研修成果発表の結果、CTOからもプロダクト採用の判断をいただくことができました。
今回の研修を通して、オンプレサーバーでローカルLLMを動かす知見、2024年5月時点でのローカルLLMモデル、Whisperの文字起こし精度、チーム開発における立ち回りなど、様々な面で成長できました。
今後の展望
現在はテクノロジー戦略本部のマネージャーと導入先事業部の上長を交えて、実際のプロダクトとしての効果や今後の開発スケジュールなどを検討しています。
また、今回は1ヶ月という限られた期間だったため、開発速度を重視しましたが、プロダクトの拡張性も考慮し、インフラ構成や技術構成も見直しています。
AIモデルは日々進化しており、それに応じて私たちのプロダクトの品質も向上していくため、今後も生成AIについて日々キャッチアップしていきたいです。
Bチームの取り組みについて
Bチームは、バイセルのテックブログ執筆中にAIが校正を行い、修正案を提案することで執筆者とレビュアーの負荷を抑えるプロダクトを開発しました。
テーマの設定
私たちBチームは、研修の課題「生成AIを用いて社内の困りごとを解決するサービスの開発」の「生成AI」に注目しました。 そこでまずは、現時点でどのような生成AI技術やサービスが公開されているかの調査と、生成AIが何を得意としているかから考え始めました。 Aチームは各事業部が抱えている課題について仮説を立てるところから始めていたので、この時点ですでに異なるアプローチを取っていたことになります。
調査を始めると、文章生成AIや画像生成AIをはじめ、動画生成AI、音楽生成AI、3Dモデル生成AIなど、様々な種類があることに気付きます。 しかし、音楽生成AIや画像生成AIを使ってみたいなど技術優先で仮説を立てて事業部にヒアリングを行っても、実際には仮定していた困りごとが存在しなかったり、想定していたプロダクトでは使いものにならないことが分かりました。このように課題に即したプロダクトの案がなかなか定まらず、アイデア出しに難航しました。
別のアプローチとして、自分たちが今までに経験した小さな不満や困ったことについて話し合うことにしました。 するとチームメンバーが「テックブログを書くのにすごく時間がかかった」と発言しました。 彼はバイセルで内定者インターンとして昨年度からインターンをしており、過去にテックブログを執筆した経験がありました。
ヒアリング
バイセルには、テックブログの執筆をサポートするワーキンググループがあります。 このワーキンググループに所属する社員へヒアリングを行ったところ、以下のような課題があることがわかりました。
- 1記事のレビューに長いと2〜3時間かかってしまう
- ワーキンググループに関する業務で、本来のプロダクトチーム側の業務が圧迫されている
さらに詳細に聞くと、テックブログの原稿のレビューでは大きく2通りの読み方を繰り返し、何度も読み込むそうです。
- 話の流れに違和感がないか、ドメイン知識がない読者の方にも理解できるように説明に過不足がないかなどの校閲
- 原稿に誤字脱字や文法的な問題がないか確認する校正
2点目の校正は、細かく文章を確認する必要がある文字の間違い探しで、かなりの緊張感と集中力を要し、時間がかかってしまいます。 実際、ワーキンググループの社員も、校正のステップがなくなればレビューが格段にしやすくなると答えました。 そこで、私たちは校正業務に長い時間がかかり、レビュアーの負担が大きくなってしまうという課題を解決するためのプロダクトを開発することにしました。
開発手法・技術選定
私たちBチームは各メンバーの専門性に頼るのではなく、チーム全体で助け合いながら進めていけることに重点を置いていました。 そこで、個人が得意としているGoやRuby on Railsではなく、全員がある程度の知識を持っているJavaScriptでフロントエンドもバックエンドも実装することに決め、Next.jsを採用しました。
生成AIはChatGPTのgpt-3.5-turboを使用しています。
ClaudeやGemini、ChatGPTのgpt-4も検証しましたが、出力される結果に大きな差はなかったため、コストを考慮してgpt-3.5-turboを採用しました。
また、バイセルの事業にクリティカルなプロダクトではないため、少しは技術的な挑戦もしたいという理由から、バリデーションライブラリはValibotを選択しました。
課題に対するアプローチ
ChatGPTによって文章中の誤字脱字を検出し、修正案を提示するプロダクトを考えました。
検証段階ではテックブログの原稿を全てChatGPTに入力し、プロンプトエンジニアリングだけで対応しようと考えました。 しかし、入力する文章が長くなるほど出力される文章にブレが生じ、理想の出力が得られないことがわかりました。 そこで句点で文章を分割し、1文1文をChatGPTに投げる方法に切り替えました。
しかしまた、文章を文に分割してChatGPTに入力すると、リストやコードブロックでは不適切な修正が行われることがあります。 そこで、文の種類を識別するために以下の属性を定義し、各属性に対して校正するかしないかも含めてプロンプトを設定しました。
- 標準テキスト
- コメント
- コードブロック
- 数式
- ヘッダータグ
- リスト
- 番号付きリスト
- テーブル
- URL
- その他
成果
プロダクト
プロダクト名は執筆者に対して猫の手くらいささやかでもサポートができればという願いを込めて「CatManu(キャットマニュー)」に決めました。 "manu"は「手」という意味の接頭辞(prefix)です。 接頭辞が接尾辞のようにcatの後ろに置かれている点は、気付かなかったことにしてください！ このプロダクト名から想像を膨らませて、画面のデザインを進めていきました。
CatManuは以下のような画面です。 ユーザーは左側のエディタに原稿を入力し、「猫の手を借りる」ボタンを押下すると、文章の校正が始まります。
校正が行われると、ChatGPTが提案した文章が右側のエディタに表示され、自分の文章と生成された文章の比較が可能になります。
CatManuはエンジニアがメインターゲットのため、GitHubでよく見ているdiff画面に近づけました。
さらに、修正の提案を取り込みやすくするために、Grammarlyを参考にして画面右側にカードで表示しています。
また、画面右上の歯車ボタンを押下すると、プロンプト編集モーダルが表示されます。
猫らしく語尾に「にゃー」と付けてもらうなどのように、期待する文章が出力されるためプロンプトをカスタムすることも可能です。
実際に使ってもらったフィードバック
プロダクト研修中はテックブログの執筆タイミングと合わず、実際に執筆者とレビュアーから利用したフィードバックを受け取ることができませんでした。 しかし、研修後に実際に利用したフィードバックを得ることができました。
執筆者からのフィードバックは以下のようなものでした。
- 感想
- 変な指摘はあまりなく、指摘の大体は自分で読んでも間違っていた
- わざと口語的に書いてる部分とかも指摘されたが、変更を受け入れなければOKなのでほぼ問題ない
- レビューを出す前のセルフチェックの一部を代替してもらえた
- 時間の短縮はわずかだが、安心感を得られたことが大きい
- 質問と回答
- 質問1
- Q.1記事の執筆の中でCatManuを使用していた時間は？
- A.10~15分程度
- 質問2
- Q.CatManuに対して1記事あたり何円のように課金制にしても利用しますか？
- A.利用する
- 質問1
また、チームでも確認したところ、今回の記事の場合、CatManuが提案する修正の受け入れ割合は84.4%(161提案中136件)でした。個人的にはいい感じの精度なのではないかと感じています。
次に、レビュアーからのフィードバックは以下のようなものでした。
感想
- CatManuを使っていなかったら1時間かかっていたであろうレビューが30分ほどで終了した
- CatManuを利用することを前提に、社内のテックブログのレビュー体制を変えられるかもしれない
- 理想を言えば、自社内メンバーに対して尊敬語・謙譲語を使わないなどのブログ特有の言い回し、文章構成や内容についても踏み込んでほしい
質問と回答
- 質問1
- Q.レビューの精神的な負担は減りましたか？
- A.確実に減った
- 質問2
- Q.CatManu導入前と比べて、誤字脱字の指摘回数は減りましたか？
- A.CatManuによって執筆者本人が直すようになったため、如実に減った
- 質問3
- Q.CatManuを導入したことによって、レビューの質は向上しましたか？
- A.向上した
- 理由：これまでは指摘数が多くなりすぎるため諦めていた指摘もあった。しかし、誤字脱字の指摘がなくなったことにより、より全体の構成や内容についてのレビューをできるようになった。
- 質問1
以上のように全体的には執筆者とレビュアーのどちらからも好評を得ることができました。 プロダクト研修の課題である「社内で生じる困りごとを解決するサービスの開発」を行い、実際に利用者から喜んでいただけたので良かったと思います。
今後の展望
CTOから採択判定が出たものの、プロダクト研修期間中はCatManuに対する効果検証はインタビューから得た感覚的な効果でしか行われていませんでした。 そこで現在は新規機能の実装や改善タスクは極力行わず、実際にテックブログを執筆している社員にCatManuの利用をお願いし、効果検証を継続しています。 一定の効果が実証できれば、今後はテックブログだけでなく、バイセルのプレス記事や求人票など外部に公開する文書にも活用の幅を広げられるように開発を継続していきたいと考えています。
おわりに
この研修を通じて、入社して間もない時期にチームで1つのものを作り上げるという貴重な経験を得られたことは、大きな自信となりました。
さらに、時代に合わせた技術やトレンドを迅速にキャッチアップし、それらを活用して課題解決に取り組む経験を通じて、エンジニアとしての醍醐味を深く実感しています。
また、現在は研修が終了し、同期メンバーはそれぞれ別のプロジェクトチームに配属されています。 同期メンバーとの仲を深めるという意味でも、とても貴重で大切な時間となりました。
今後はこれらの経験を活かし、ユーザーに寄り添った開発を続けていきたいと考えています。
最後に、バイセルでは新卒エンジニアを随時募集しています。 興味のある方は、採用サイトをご覧ください！
