技術トレンドとヌーラボ
情報の透明性が高いヌーラボでは、プロダクトに対するエンジニアからの技術提案も盛んです。
これまでの提案から生まれた事例の一部を紹介します。
目次
自発的な提案を後押しする
ボトムアップの文化
ヌーラボの働き方はリモートワークをベースとしているため、基本的な業務はテキストコミュニケーションを通して進めます。そのため、チーム間のやりとりや情報はBacklog上やチャットにすべて公開され、誰でも見ることができます。こうした環境により、チームや部門で何か気になる動きがあれば、誰でも議論したり、改善に向けた提案を行ったりすることができます。
日々活発に議論が交わされますが、もちろん思いつきだけで提案が受け入れられるわけではありません。アーキテクチャに関する重要な意思決定については、妥当性や実現性があるかを判断するために、ADR（Architecture Decision Record）も整備しています。
提案から実現した例
生成AIを活用したチャットボット開発
エンジニアからは、技術トレンドを踏まえた提案や、機能改善の提案が活発に行われています。その中で、実際にプロジェクト化した例や、機能改善に至った例などを紹介します。
Backlogのサポートチームでは、日々多くの問い合わせ対応が行われています。「問い合わせてくるユーザーに合わせて自然な回答ができるチャットボットがあれば、サポートチームの負荷が下がるのでは？」そんなエンジニアの提案がきっかけとなり、2024年に生成AIを活用したチャットボットを導入する取り組みがスタートしました。
開発時のステップ
このチャットボットは、ユーザーからの問い合わせに対応し、適切な回答と関連するヘルプページのリンクを提示する仕組みを取り入れています。開発の第一段階として、以下のようなアプローチを取りました。
- Backlogヘルプセンターの全ページをスクレイピングし、不要な箇所を除去した約300ページのHTMLファイルを作成し、AWS S3に保存
- HTMLデータをKnowledge Base for AWS Bedrockを利用してOpenSearch Serverlessに登録
- TypetalkからAWS Lambdaを経由してAPIでAIに問い合わせて回答を得る
導入後のAIチームとの試行錯誤
導入当初、生成AIチャットボットには「回答と関連リンクが一致しない」「誤った回答が生成される」などの課題がありました。これらを解決するために、AIチームとエンジニアが協力しながら試行錯誤を重ねました。その結果、以下のような気づきが得られました。
- AIが活用できる情報を増やす
Backlogヘルプセンターの多くは画像や図が中心で、AIが活用できるテキスト情報が不足していました。そのため、回答精度が思うように上がらなかったのです。改善活動の結果、ヘルプセンターのテキストを増やす、画像や図を解析できる仕組みを導入するなどが有効という示唆を得られました。 - 誤答リスクへの工夫
AIが「もっともらしい嘘」をつくり出してしまうことも課題でした。これを完全に防ぐことは難しいものの、事前に読み込ませるシステムプロンプトの工夫や、類似性の高いドキュメントを抽出して推論に活用する手法、ドキュメントの定期的なメンテナンスが効果的な対策となる可能性があります。
さらなる実用化に向けて
生成AIチャットボットの改善により、回答精度は大幅に向上しました。これまで一致しなかった回答とリンクも、正確に結びつくようになり、ユーザーが必要な情報をスムーズに得られるようになりました。
ただし、画像情報の解析や誤った回答（ハルシネーション）の抑制など、さらなる課題も残されています。AIチャットボットは、カスタマーサポートの業務効率化と相性が良い技術です。引き続き改良を重ね、より正確で使いやすい仕組みを目指しています。
一人のエンジニアから
Backlogドキュメント機能が生まれるまで
2024年9月、Backlogに新たな「ドキュメント機能」が加わりました。この機能の開発は、実は一人のエンジニアの提案から始まったものです。
「こんなドキュメント管理があったらいいな」から始まった挑戦
プロジェクトのきっかけは、あるエンジニアが「Gitを活用したらドキュメント管理がもっと便利になるのでは」という発想を抱いたことでした。このアイデアを形にするため、個人プロジェクトとして「Monster Docs」というツールの開発がスタート。2017年5月には、Gitを基盤にしたドキュメント管理の試作品が完成し、プロジェクトとして動き出しました。
試作段階では、単なるドキュメント管理ツールでしたが、「リアルタイムで共同編集できる仕組みを加えたらさらに便利になる」という気づきから、後々大きなプロジェクトへと発展していきます。
技術の選択と方向転換
共同編集機能を実現するためには、データの整合性を保ちながらリアルタイムで複数人が編集できる技術が求められました。当初はOT（Operational Transformation）を採用しましたが、日本語の入力には課題が多く、CRDT（Conflict-free Replicated Data Type）への切り替えを決断。この転換により、日本語を含む多言語対応が実現し、編集体験も大幅に改善しました。
プロジェクトがBacklogの一部へ
開発途中、このドキュメントツールを独立したサービスとして提供するのではなく、Backlogの一部として組み込むという方針が採用されました。これは、「既存ユーザーにとって使いやすい形で提供すること」と「Backlogとの統合によりさらなる価値を生み出すこと」の双方を目指したことが大きな理由です。
この方針を実現するにあたり、既存ユーザーが馴染みのある環境で新機能を利用できるようにする一方、既存システムへの影響を最小限に抑えるための負荷試験やアーキテクチャの見直しも求められました。このプロセスに1年以上を費やし、最終的に安定した運用を実現しました。
一人のアイデアが生んだプロダクトの進化
Backlogドキュメント機能は、一人のエンジニアの発想から始まりました。小さなアイデアがチーム全体の協力によって形になり、最初の発案から7年116日という長い道のりを経て、ユーザーの手に届けられました。その背景には、共同編集技術の選定やシステム全体への統合といった課題を丁寧に乗り越えてきた開発チームの試行錯誤があります。
現在もBacklogドキュメント機能は進化を続けています。新しい機能の追加や改善を通じて、より便利で使いやすいツールを実現するために、これからもユーザーに価値ある機能を届けていきます。
パスキーの可能性を探る
エンジニアメンバーで挑んだパスキーハッカソン
2024年6月、ヌーラボのエンジニアチームはGoogle主催の「パスキーハッカソン」に参加しました。このイベントは、パスワードレス認証を実現する技術「パスキー」を活用し、1日で新しいプロトタイプを開発することを目的としたものです。
ヌーラボからは、「より多くのユーザーに安心してパスキーを使ってもらうためのアイデアを模索する」という目的のもと、所属や拠点の異なる6名のメンバーがチームを結成し挑みました。
短期間で成果を出すための前準備
イベントでは「1日をかけてパスキーを使った何かを制作する」という課題が出ました。限られた時間で成果を出すためには、事前準備と効率的な進め方が鍵となります。そこで、ハッカソンまでの約1カ月間、以下のような工夫を取り入れました。
- 課題の細分化
大きなテーマを細かいタスクに分割。複数のパスキーを管理しやすくする機能や、ユーザーが直感的に理解できるインターフェースの設計など、具体的な改善案を検討。 - 毎週30分のミーティングを実施
週1回30分の短いミーティングで進捗を共有。具体的な議論は必要に応じて少人数で実施し、その他のコミュニケーションはチャットでやり取りを行うなど、時間のやり繰りを工夫する。 - 専用開発環境の構築
業務環境に影響を与えないよう、プロダクション環境を複製した安全な実験環境を用意。リポジトリやデータベースをコピーし、自由に試行錯誤できる体制を整備した。
ハッカソンで生まれたプロトタイプ
パスキーハッカソン当日、普段は異なる拠点で働くメンバーがGoogleオフィスに集まりました。福岡や京都から参加したメンバーは、ヌーラボの「コミュニティ活動支援制度」を活用して移動費を気にせず参加できたことも心強いポイントです。
事前準備をしっかり進めてきたおかげで、チームは当日、細かな調整やアイデアのブラッシュアップに集中することができました。以下は完成したプロトタイプの一例です。
| タイトル | 概要 |
|---|---|
| パスキーカードの実装 | FIDO AllianceのUXガイドラインで提示されていた、「パスキーカード」を実装しました。目に見えないパスキーというものを、目に見えるカードの形で表現しようという試みです。 |
| デバイス紛失への備え | これまでのユーザーは瞬く間にデバイスを紛失して、アカウントを使えなくしていました。そこで自力復旧を目的としたアクションを促し、登録後の体験を整えました。 |
| 漏洩したパスワードを削除してパスキーをオススメする | パスワード撲滅キャンペーンの第1弾としてセキュリティリスクがあるユーザーにアプローチします。漏洩したパスワードを削除してパスキーをオススメします。 |
ハッカソンを通じて得られたのは、技術的な発見だけではありません。ユーザーの視点に立つ重要性を改めて感じたり、短期間でチームとして効率的に動く方法を学べたりと、多くの気づきがありました。この学びは、日々の業務や開発プロセスにも生かされています。
エンジニア発案の実践演習
「アーキテクチャ・カタ」の取り組み
ヌーラボでは、エンジニア同士の学び合いや知識共有を目的に、読書会や勉強会を定期的に開催しています。その中から実践的な演習へと発展する取り組みもあります。今回紹介する「アーキテクチャ・カタ」は、Backlog課での「アーキテクチャの基礎」の読書会をきっかけに、有志のメンバーが主催したものです。
実践演習で鍛える設計力
「アーキテクチャ・カタ」は、実際のプロジェクトに近いシナリオを通じて、アーキテクチャ設計のスキルを磨く演習です。普段の業務ではシステム全体の設計に深く関わる機会が限られていますが、この演習では「ユーザー要件を正確に理解する力」や「柔軟で信頼性の高いシステムを設計する力」を実践的に学ぶことができます。
今回挑戦した課題は、「全国の店舗で顧客対応を行うITコンサルタント向けトラブル管理システムの設計」です。ユーザー視点を重視し、課題解決に向けた設計を模索する中で、個々の発想力やスキルが試されました。
3日間の取り組み
演習は「要件の確認」「アーキテクチャの設計」「振り返り」を3日間に分けて実施しました。
【1日目】要件の確認
まずは要件を読み解き、ユーザーの行動フローを整理しました。例えば、「トラブルを登録するのは顧客だけでなく、コールセンターや店舗スタッフも関与する」「登録されたチケットはコンサルタントに自動で割り当てられる」など、利用シーンをリアルにイメージすることから始めました。
【2日目】アーキテクチャの設計
次に行ったのが要件をもとにしたアーキテクチャの設計です。ここでは参加メンバーが2チームに分かれ設計を進めました。1チームの例ですが、「一部が壊れても全体が止まらない仕組み」や「高負荷時にも対応できる柔軟性」を重視し、以下のような設計課題に取り組みました。
- データベースやサービスを役割ごとに分離し、段階的な劣化を実現
- チケット登録や閲覧のプロセスがシステム全体に負担をかけない仕組みを導入
- 外部サービスを活用してコンサルタントのスケジュールやスキルを管理する構成を検討
【3日目】振り返り
最終日には、各チームが設計を発表し合い、互いのアイデアを共有しました。同じ課題に取り組んでも、チームごとに異なるアプローチが生まれた点も興味深いポイントです。ひとつのチームは外部サービスを活用して設計を簡略化し、もうひとつのチームは独自のスケジュール管理を組み込む構成を提案しました。このように異なる視点を比較することで、負荷管理や設計の柔軟性について新たな気づきを得ることができました。
演習を通じた学び
アーキテクチャ・カタでは、異なる視点やアプローチを共有し合い、チームで課題を解決する力を磨く貴重な機会となりました。ヌーラボでは、こうした実践的な場を今後も積極的に設けていき、エンジニアが互いに学び合いながら成長できる環境を目指していきます。
