旺盛な学習意欲で自らのスキルや知見に磨きをかけ続けているGunosyのエンジニアメンバー。業務内外問わずさまざまな学びの機会がありますが、なかでも隔週で実施されている『はにびぶ』は、チームの垣根を超えて知識や情報をシェアしたり、失敗やしくじりから改善のヒントを得たり…と毎回盛り上がっています。そんな『はにびぶ』がオフラインで開催される運びに。さっそく現地に潜り込んでみました！
当日は会場に用意した椅子が足りなくなるほどの盛況ぶり。テクノロジー本部の各チームに新規事業開発室も加わり、20名以上が顔を揃えました。司会はマネージャーの鈴木さん。冒頭に今回のテーマを発表します。
さらに『はにびぶ』の名称の由来の説明も。実はかの名言「愚者“は”経験“に”学“び”、賢者は歴史に学“ぶ”」から来ています。まさしく他チームの発表から学びを得て、自らの改善のインスピレーションにつなげよう、という会の目的にピッタリの名前です。
前半はトップバッターを第1プロダクトが務め、続いてAds、第2プロダクト、第3プロダクトチームの順に発表しました。
Gunosyアプリの開発を担当する第1プロダクトの発表は『Kotlin マルチプラットフォーム(KMP)で始めるクロスプラットフォーム開発』で、小野さんが登壇しました。GunosyではiOSとAndroidでそれぞれネイティブ開発を行っており、双方の開発効率化が課題となっていました。そこで小野さんのチームは、Kotlinを使って実装を共通化できるKMP技術の導入に取り組み、API通信部分の共通化を進めました。この結果、両プラットフォームにまたがる開発効率を向上させる仕組みが構築され、今後の開発速度向上という価値が得られました、と発表をまとめます。
広告サービスの企画開発と運用を手掛けるAdsは『サーキットブレーカーの導入について』平尾さんが壇上に立ちます。従来のシステムでは、サーバーへの大量リクエストによる過負荷がサービス全体のダウンを引き起こすリスクがあり、また監視体制の不足から対策が難しいという課題がありました。そこでチームは、新たにメトリクス監視を可能にした上でサーキットブレーカーの導入を推進。実装中の技術的な壁に対しては、Claude（生成AI）を活用して効率的に解決策を見つけ出しました。これにより、サービス全体の安定性を高めるという直接的な価値に加え、生成AIを用いて旧来の課題を迅速に解決するという、新たな開発プロセスを確立することができました。ただしまだまだ課題はあり、特に設定値チューニングの難しさについては今後もチーム内で模索していくとのことでした。
続いてグノシーのサーバサイド開発や各種管理画面の開発まで手掛ける第2プロダクトから今井さんが『dripmanの紹介』をテーマに取り上げました。dripmanとはLLMを活用して記事の特徴を抽出するシステムです。プッシュ運用工数が多くかかっているという課題解決のために開発されました。今井さんは開発の背景からアーキテクチャ、管理画面の紹介、さらにはLLMのレートリミット管理や特徴抽出データを活用したプッシュ運用などを説明。
今後もいろいろと開発を加えていきたい、と今井さん。プレビュー機能やredashを挟まずにプッシュ記事の選定から送信までを管理画面上で完結させる機能など、展望を語ります。現状はグノシーだけですがゆくゆくはメディア横断の可能性も期待できるとのことでした。
前半のトリを務めるのはauサービスTodayのサーバサイド開発全般を主に手掛ける第3プロダクト。Claude Codeを取り上げて小泉さんがプレゼンテーションします。『GitHub Copilotより普通にClaude Codeが好き』というタイトルに会場から小さな笑いが。全てのエンジニアに共通する「日々の開発効率をいかにして最大化するか」という普遍的な課題を背景に、内容はかなりきっちりと作り込まれており、Claude Codeの良さ、Agentic Coding ツールのベストプラクティス、Claude Codeを使うにあたっての工夫点など、実践的なものばかりです。
普段からClaude Codeを使い倒して、いいところもそうでないところも知り尽くした小泉さん。その上で使い方を工夫すれば開発効率が2～3倍にも上がっていく可能性を感じているようです。結論として「Claude Codeは良いぞ！」と、その偏愛ぶりを惜しげもなく披露して幕を閉じました。
発表後には司会の鈴木さんから質問を促すのですが、毎回熱のこもったコメントやこうするともっといいのでは？といった提案が飛び出すことも。エンジニアといえども自らの専門領域以外に踏み込むのは簡単ではないはず。にも関わらず専門性の枠を超え、本質的な問題提起を積極的に行うあたり、さすがGunosyテクノロジー本部の面々です。
休憩中はお菓子を食べながらの雑談。しかし実はこの雑談が大事なんです、と鈴木さん。「発表時の質問よりさらに踏み込んだ質問や、実はちょっと聞きづらかったような内容の相談なども交わせるところがオフラインの良さ」だそうです。
さて後半はML、新規、QA、R&Dの順にプレゼンテーション。トップバッターのMLチームからは『auShortの推薦モデルを改善して視聴時間が向上した話』を大城さんから発表していただきました。auShortとはKDDIのショート動画アプリ。推薦システムはGunosyが作った「Oreo」というモデルがバックエンドで走っています。発表はこの「Oreo」を改善することで視聴時間を伸ばすことに成功した、という内容です。
ユーザーの視聴時間向上という課題に対し、粘り強い仮説検証と改善実験を重ね、視聴時間を10％向上させるという大きな価値を生み出しました。最も印象的だったのは、大城さんが振り返りの中でGunosy Prideの一節を引用し「逆境に熱狂していた」と語ったことです。困難なプロセスさえも楽しむその姿勢は、Gunosyのエンジニアカルチャーをまさに体現していました。
新規事業開発室の発表は井口さん。テーマは『LLMを使ったIR Hubファイル翻訳での苦労』です。翻訳ロジックの経緯として最初のフェーズは翻訳特化APIとして「Amazon Translate」で初期実装、続いて「Google Translate」によって翻訳モデルの精度向上に取り組んできました。そして現在は第2フェーズで、LLMを活用して翻訳精度を向上させているとのこと。Claude 3.5とGeminiをマルチモーダルで使っているそうです。
翻訳品質向上のためにLLMを導入したものの、その出力が不安定で、特にフォーマット指示に使うJSON modeが壊れやすいという技術的な課題に直面していました。チームはAPIをただ利用するだけでなく、この不安定さを解消するために安定化のための仕組み「Super LLM Client」を自前で開発するというアプローチを取りました。これにより、翻訳品質が劇的に向上しただけでなく、新しい技術の課題を自社の工夫で乗り越えるという貴重なノウハウが組織に蓄積される価値も生まれました、として発表を終えました。
品質改善活動を推進するQAチームは『やってみて、やめてみて、続けているバグ分析共有会の話』を田中さんがプレゼンテーション。バグ分析共有会をやる目的として「品質の可視化」と「品質の向上」をあげ、感覚値ではなく事実ベースに基づいて品質を可視化し、価値ある情報を提供していくと説明しました。
分析共有会の中でやってみたことだけでなく、やめてみたことも改善のひとつと捉えて、続けるだけが正解じゃなかった取り組みにも言及。気付いたこととしては一般論にとらわれずチームやプロダクトにあったやり方を見極めていく、「試して、測って、調整する」サイクルを重視し、成功体験だけでなく「効果がなかったのでやめてみたこと」もオープンに共有する取り組みを続け、形式ではなく「うちのチームにとって意味があるのか？」という視点を大事にしたい、と田中さん。会場のエンジニアたちも大きくうなずく場面の多い発表でした。
さてラストは社内DXの推進も担うR&Dチームです。「不具合事例から学んだ教訓」として『広告審査DXで仕様の認識ズレが起きていた話』を森田さんから発表してもらいました。広告審査の効率化・標準化をサポートするシステムはまだまだ発展途上。エンジニアリング的な問題も含めてさまざまな課題が山積しているとのこと。その中で審査の効率化のための要望をいただいたんだそうです。
そこで発生した仕様の認識ズレが、審査でついたコメントが同じ商品の審査にもかかわらず消えてしまう、といったバグを発生させることに。もちろんこの不具合を教訓とするべく、原因を分析。最終的にユーザーにとって大きな変化がある仕様はユーザー側から見て何が変わるのか、まで完全に認識を共有した上で決定する、という学びを得ました。もちろんその後の対策も徹底され、同様のミスは起きていません。仕様の確認不足、情報共有の不足という基本的な原因抽出は他のチームにも有効な教訓として響いたのではないでしょうか。
すべての発表の後に行われる座談会ですが、今回は「フィッシュボウル」というディスカッションスタイルを導入。輪になってディスカッション参加者と観察者にわかれますが、観察者は自由に席を移動でき、いつでも議論に参加可能という特徴があります。
ディスカッションテーマは『開発プロセスにおける生成AIの活用』『品質担保とレビュー・技術選定』『チームワークとコミュニケーション』。やはりいちばんの盛り上がりを見せたのは新規開発と既存プロダクトにおけるAI活用の違いです。新規開発においては、技術選定からタスク分解、モック作成まで「最初から最後まで使える」と非常に効果的であるという声が上がりました。あるエンジニアは、Geminiでリサーチとタスク分解を行い、効率的に実装を進めるフローを共有しました。
一方で、10年以上の歴史を持つアプリなど既存プロダクトでは事情が異なります。古いコードや複雑な仕様が絡むため「全体設計のようなマクロな部分で使うと、的を射た答えがもらえない」という課題が指摘されました。そのため、関数作成のようなミクロな範囲にスコープを絞って活用するのが現実的だといいます。
ハルシネーションという課題はありつつも、それを前提に対話しながら修正していくスタイルは、人間との共同作業と変わらないとの意見も聞かれました。プロダクトの特性や開発フェーズに応じて、エンジニアたちが生成AIとの最適な付き合い方を模索している様子がうかがえる、非常に興味深いディスカッションでした。
まさしく参加者が入れ代わり立ち代わり。ひと言物申す、といった方もいれば、なぜか外野席に移ったのに発言を差し込む猛者もいて、笑いありうなづきありの時間となりました。最後には冒頭から会を傍観していたテクノロジー本部、副本部長の小澤さんまで中央席にひっぱり出され、これからのエンジニアに必要なスキルについて意見を交わしました。
みなさんのコメントに共通していたのは、LLMを盲信しない姿勢です。「自分がコントロールできないことは任せない」「最終的な意思決定と責任は人間が持つ」という意見が挙がり、的確に指示を出すための「国語力」や基礎的な技術力の重要性が強調されました。
一方で「既存のやり方に固執せず、変化に対応し続ける柔軟性」や「リスキリングしていく姿勢」こそが重要だという声も上がりました。LLMによって可能になる新しいシステムを自由に発想する力が、今後の強みになるというのです。
LLMの手綱をしっかりと握りつつも、その可能性を最大限に引き出すための柔軟な思考。この両輪をいかにして回していくか。エンジニア一人ひとりの主体性がこれまで以上に問われる時代になることを予感させる熱い議論でした。
最後は参加者みんなで集合写真。チームは違えど息のあったところを見せてくれました。そして場所を変えた懇親会でもこの熱量はキープされたようで、参加者にとってはオンラインでは得難い時間となりました。
gunosiru