🆓
freee × OPTiM 100名規模のプロダクト開発 〜品質とチーム力の高め方〜 レポート
公開
2025-04-14
更新
2025-04-14
文章量
約5087字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
はじめに
2025年2月18日、「freee × OPTiM 100名規模のプロダクト開発 〜品質とチーム力の高め方〜」が開催されました。モバイルデバイス管理（MDM）サービス「OPTiM Biz」を提供する株式会社オプティムと、会計サービス「freee会計」を提供するフリー株式会社が、互いに100名規模の開発組織をどのようにまとめ、品質とチーム力を高めているかを語り合う貴重な機会でした。本記事では、イベント全体の模様をレポートいたします。
イベントの概要
本イベントの大きなテーマは「大規模チームだからこそ求められる品質担保と、チーム全体の連携・コミュニケーションをどう構築しているか」。オプティムとフリー、ふたつの開発現場での実際の取り組みが、具体的かつ熱量高く共有されました。前半は各社が運営しているプロダクト概要や品質担保の工夫、後半はパネルディスカッション形式で、組織規模が大きいからこそ直面する課題や実践事例が率直に語られています。 本レポートでは、当日のセッション内容とQ&Aでの議論を交えながら順を追ってご紹介します。
Session 1: OPTiM Biz 〜MDMサービスの巨大さと特殊さに負けない開発体制と品質プロセス〜
MDMサービス「OPTiM Biz」の概要
株式会社オプティムは、AI・IoT・クラウドを活用したさまざまな事業を展開する企業です。その中でも「OPTiM Biz」は、モバイル端末やPCを安全に管理し、遠隔からのアップデートや問題解決を行うサービスとして14年連続シェアNo.1（※発表当時）を誇ります。サービス規模が拡大するにつれ、開発チームも100名規模となり、保守開発や新機能追加のたびに大きな影響範囲が生まれます。
チームコミュニケーションの工夫
OPTiM Bizの開発組織は複数チームから成り、協力会社も含めると相当な人数にのぼります。そのため「誰に聞けばよいかわからない」という問題が起こりがちです。これを解決するために、Slackに「Biz質問箱」を設置し、質問する人も答える人も気軽にやりとりできる仕組みを導入したそうです。回答率は9割以上とのことで、まさに“答えの出る掲示板”のように機能しているのが印象的でした。さらに、回答者にはタコスの絵文字で感謝のリアクションをする文化があり、チームを超えた連帯感の醸成にもつながっているようです。
また、リリースタスクの管理表を「Power Automate」と「Slack通知」で連携し、自動的に期限切れ・当日対応タスクを毎日リマインドするという事例も紹介されました。担当者が全体リマインドに費やす手間を大幅に減らすことができたそうで、ツールと運用ルールの組み合わせで課題をうまく解消している印象を受けます。
品質担保のポイント：レビュー会の活用
OPTiM Bizでは 「レビュー会」 というクオリティゲートを設け、要件定義・設計・実装・テストといった工程ごとに、マネージャー・企画担当・テクニカルサポート担当が集まって内容をチェックします。これは 「プロセス品質」を高める取り組み として位置づけられ、作業プロセスのレビューを入念に行うことで、後工程で発生する問題や認識ずれを極力減らしています。
当初から掲げている参加三ヶ条として、
あいまいにしない、はっきりさせる
担当者任せにしない、チーム全体で確認する
手抜きをしない、最後までやり切る
というシンプルだが意外と徹底が難しい原則を掲げ、これをメンバー全員が意識することで品質を担保しているそうです。
自動テストの現状と課題
OPTiM Bizは、クライアントサイド（Android/iOS/Windows）とサーバーサイドの両面で非常に複雑な検証が必要です。特にMDM特有の遠隔ワイプ機能などは、テスト端末自体が消去されるため「自動化が難しい」状況が多々あるとのこと。物理的にラズベリーパイで端末をタップする試みなども行ったものの、機種ごとにUIが異なるため汎用化が困難で、いまだに人力テストが必要な領域が残っています。
一方、サーバーサイドの単体テストはカバレッジ90％超を維持しており、さらにテスト実行の並列化やランチャブルなどの仕組みを活用して実行時間を削減する取り組みも続けられているとのこと。クライアント側のテスト自動化は課題はあるものの、じわじわと整備を進めているそうです。
Session 2: freee会計 〜Railsアップデート戦略とQAの舞台裏〜
freee会計の開発チームとRailsアップデート
フリー株式会社では、会計・給与・申告など多角的にクラウドERPを提供していますが、やはり主力のひとつは「freee会計」。10年以上続くプロダクトであり、テーブル数800超・モデル数900弱・コントローラー数1300超という、Railsアプリケーションとしては相当な大規模システムです。加えて複数のマイクロサービスやモバイルアプリからも参照があるため、Railsアップデートがサービス全体に及ぼす影響は非常に大きいといいます。
この大規模さを支えるのが、「バックエンド委員会」という組織横断チームです。RailsやRuby、ライブラリのバージョンアップをはじめ、フリー会計全体の技術的負債と向き合う専門チームとして機能しているそうです。
「リスク洗い出し会」でのQA連携
大規模な変更を進める際には、ただコードを書き換えるだけではなく、 「どこにリスクがあるか」 を早期に見極めることが重要です。freee会計では、QAチームとエンジニアが合同で「リスク洗い出し会」を実施し、予想される不具合や影響範囲を参加者全員で洗い出します。
加えて、 「1Page TestPlan」 というフォーマットを使い、重要なテスト項目を1ページに凝縮。チーム全体の認識を揃えることで、高速かつ確実に要点を検証できるようにしているとのことです。また、案件によっては 「ぽちぽち会」 と呼ばれる画面共有形式でのテスト会も開催し、皆で一緒にUIを操作してリスクを洗い出すなど、QAプロセスを柔軟にアレンジしている点が印象的でした。
具体的なQAアプローチ
本セッション後半では、とくにRailsアップデート時のQA対応が深堀りされました。「Railsアップデートは開発規模が大きいほど重たい」という課題に対し、以下の工夫が挙げられました。
担当者選定 バックエンド委員会が中心となり「この人ならRailsバージョンアップの負債を解消できる」というメンバーをアサイン。基本は有志の手挙げ制だが、要所は専門知識のある人をピンポイントで起用している。
事前の情報収集と段階的リリース Rails公式ドキュメントやコミュニティ情報を早めに調査し、関連ライブラリのアップデートなどを小出しにリリース。ビッグバン的にまとめてリリースしないのがポイント。
QAリソースの効率化 リスクの高い箇所を優先テストし、重篤度が低い箇所は探索的テストやぽちぽち会でカバー。リリース時期を他の大型フロント改修と合わせ、まとめてQAを実施する工夫も取り入れている。
結果として、以前は1ヶ月近くかかっていた大規模リグレッションテストが、10日前後で終わったケースもあったそうです。重度リスクを見極める仕組み、そしてスピード感をもってタスクをアサインできる体制が、全体のQA負荷を大幅に削減しているように感じました。
パネルディスカッション
後半は、OPTiM・freee双方からQAとエンジニア計4名が登壇し、大規模組織の品質向上とチーム連携にまつわる本音トークが展開されました。
QAの立ち位置
OPTiMでは、専門の「QA組織」を設けず、各開発チームに検証担当者をアサインするスタイルが特徴的です。ドメイン知識を活かした素早い判断とテスト設計が可能になる一方、QA同士のナレッジ共有にはチームを横断する仕組みが求められるとのこと。
一方、freeeではプロダクトによってはQAがスクラムチームに常駐し、また別のプロダクトでは“依頼型”のQA支援を行うなど多様なパターンが存在するそうです。「品質を守る人」という意識で動いており、ドメイン知識の深いQAほど開発との連携がスムーズになるという指摘がありました。
大きな変更をどう進めるか
Railsのように、大部分に影響が及ぶバージョンアップでは、 「先導するチームが必要」 という点で両社一致していました。OPTiMの場合は、専任チームを立ててバージョンアップに集中し、他チームが抱える新機能開発ともタスクを調整するやり方。freeeの場合は、バックエンド委員会が全社横断で負債解消を牽引し、テストの後ろ支えは各チームやQAが受け持つ形です。いずれにせよ、広範囲な変更において「誰が決め、誰がやるか」の明確化がカギになっているようです。
100名規模だからこそ必要な視点
パネルディスカッションで特に印象的だったキーワードが「自分ごと化」です。大人数になるほど「他の誰かがやってくれるだろう」が起きやすいものですが、品質の責任をチーム全員が共有しないと、結果的に開発スピードが落ち、リスクも増大します。リードするチームがいても、最終的には 「みんなで品質を守っていく」 意識が重要なのだと感じました。
Q&Aピックアップ
イベント終盤のQ&Aセクションでは、多数の質問が寄せられました。特に注目を集めたのは以下のようなトピックです。
「QAコストとリターンのバランス」 リスクをどの程度排除するか、どこまでテストするかは常に悩みのタネ。OPTiMは一連のレビュー会でフェーズごとに精査し、freeeは機能の重篤度やリスクレベルを決めてから対応深度をコントロールしているそうです。
「QA業務におけるAI活用」 大きなフレームワークはまだないものの、各社試験的にLLMを使ったテスト観点の洗い出しや要件整理を行っているようです。「最終的なレビューは人間がやるが、観点漏れを補うには有用」といった意見が多く聞かれました。
「レイルズアップデートという技術的負債への向き合い方」 フリーはバックエンド委員会を要にして、負債解消のロードマップを組み込む文化があるとのこと。OPTiMは専任チームを置き、定期的にまとめて片付ける方式。いずれも“先にやるべき大仕事”という認識で取り組んでいる様子がうかがえました。
全体を踏まえた感想
ふたつの企業がそれぞれに大規模開発を推進する中で、 「早期にリスクを見極め、コミュニケーションを円滑化し、プロセス品質を高めていく」 という共通した努力を強く感じました。大人数であるがゆえの情報伝達ミスや、誰も手を挙げないまま先延ばしになるリファクタリング課題など、組織が大きくなるほど問題も複雑になります。それに対して、スラックなどのツール活用はもちろん、レビュー会やリスク洗い出し会といった“人が集まり意見を交わす場”をしっかり設けることがカギになっているようです。
また、単純に「テストを増やして品質を高める」という発想ではなく、 「どんなプロセスで、誰と、いつの段階でチェックするか」 を明確に設計している点が印象に残りました。QA担当をプロダクトチームに分散配置するか、それとも専任チームとして独立させるか。Railsアップデートのような技術的課題をどの組織が先導するか。大規模ならではの最適解を探り続ける姿勢は、他の企業にとっても大いに参考になるはずです。
本イベントは、開発者だけでなく、QA、マネージャー、企画担当など幅広い参加者が「自社に合った品質向上策はなにか」を見つめ直す良い機会だったと思います。OPTiMとfreeeの事例には、社内体制・コミュニケーション・技術的負債への向き合い方など、いずれの組織にも活かせる示唆が多分に詰まっていました。大規模開発だからこそ必要な「プロセス品質」と「自分ごと化」の両立。その実践に向けて、今後も多くの知見が共有されることを期待します。
以上が「freee × OPTiM 100名規模のプロダクト開発 〜品質とチーム力の高め方〜」のレポートです。参加者の皆さま、そして登壇者の皆さま、本当にありがとうございました。今後もこうしたイベントを通じて、大規模開発ならではの課題や解決策が共有されていくことを楽しみにしています。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
