こんにちは、オプティマインドの採用担当です。

本記事では採用を担当している私が、オプティマインドの「開発体制」を解説したいと思います。アルゴリズム、データ分析やWebアプリケーションを組み合わせて成り立つオプティマインドのサービスの裏側では、どのようなチームがあり、活動しているのか紹介していきたいと思います。

こんな方に読んで欲しいと思っています。
・オプティマインドの開発チームの全体像を知りたい。
・どのような開発体制を目指しているのか興味がある。
・チーム組成に対する考え方を整理したい。

現在の開発体制・開発チームについて

走行データ学習型配車システム『Loogia(ルージア)』というサービスを展開しているオプティマインドでは、以下のような開発体制を敷いています。

現在は6つのチームから構成されており、それぞれの役割について簡単に説明します。

① SAチーム 計画作成フェーズ
　どの車両にどの荷物を割り当て、どの順番に配れば最も効率が良いかという「配車計画」を作成するチームです。何かしらの「機能」を持つ訳ではなく、配車担当者(ドライバー)の配車業務を楽にするということがミッションになります。

② SA(※1)チーム 計画実行フェーズ
①のチームで作成した計画の実行をサポートするのがこのチームです。運行管理者がドライバー業務をしっかりと管理でき、スムーズに実行できるようにプロダクトを磨きます。

③ CSs(※2)最適化チーム
配車計画や実行において、より最適性を突き詰めるのがこのチームです。例えばある評価指標において、100件の荷物を5台で配るよりも、4台で配れた方が優れているのであれば少ない台数で100件をこなせるように最適化を行います。

④ CSs(※2)経路探索チーム
信頼できる2点間の移動経路と所要時間を、精度高く高速で算出するのがこのチームです。数万通りの経路から算出する必要があるので、アルゴリズムに対する深い知見やそれを動かすインフラ・サーバーに関する高い知識が求められます。

⑤ データ基盤チーム
「この道は狭すぎる」「この道の制限速度は時速30km」といった、経路探索をする上で必要な道路情報や状況を整理するのがこのチームの役割です。経路探索チームにとって価値のあるものを生成するという責務を担っています。

⑥ DevOpsチーム
他チームの連携が円滑に行われるように微調整を行ったり、障害を解決したりと、運用面での負荷を最小限に抑える役割を担います。

※1　stream aligned の略　
※2　complicated sub-systemの略
「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」という書籍から引用

また、チームの構成メンバーにも型があり、以下のような成り立ちます。このような分け方をすることでチーム毎に異なる、見るべき「ユーザー」や「時間軸」に対応できるようにしています。
・組織を見る人
・技術でリーダーシップを取る人
・プロダクトの方向性を考える人
・デザインを考える人
・ソフト開発をする人

開発組織における「チーム」とは何か？

オプティマインドの開発組織では、「チーム」をこのように捉えています。

引用：（R・ダンバー著「友達の数は何人?―ダンバー数とつながりの進化心理学」
ベンチャーに立ちはだかる「人数の壁」〜その真の原因と対策〜 Vol.2

その理由は大きく分けて3つ。
　まず1つ目は、働くメンバー間で深い信頼関係を築くためです。
　組織は規模が大きくなるにつれて人間関係性が複雑になり、深い信頼関係を結べなくなる可能性があります。そのため、各々がモチベーション高く効率的に働けるように、最適な人数を配置しています。

次に2つ目は、小さく早くつくるためです。
　変化が早い世界についていくためには、開発にもスピードが求められます。自分たちが作った機能を、正しく利用できる状態でユーザーに素早く届ける。サービスの不具合や障害を素早く検知して対処する。それを組織で恒常的に実現できなければ、事業成長の機会を逃してしまう可能性が高いです。

最後に3つ目は、認知的負荷を最適な状態にするためです。
　あれもこれも考えなればいけない状態では、それぞれの理解が浅くなり、より良いプロダクト作りができなってしまいます。そのため、チームの「認知的負荷」の限界を考慮することで、チームが所属するドメイン知識を効率的に獲得できるようにしています。

実際に『Loogia』の開発においては、経路探索アルゴリズムや最適化アルゴリズムといった専門性が高いチームを明確に切り分けています。他チームはアルゴリズムチームが持つノウハウやサービスを、必要に応じて社内で利用するようなイメージです。例えば計画作成を行うSAチームは、最適化アルゴリズムを思考する業務を依頼し認知的負荷を軽減することで、本来のミッション遂行にフォーカスできます。

引用：コンウェイの法則と逆コンウェイの法則から組織構造を考える

現在の開発体制に至るまで

以前の開発体制においては、ドメイン知識の獲得がとても難しい状況にありました。不具合対応やリリースの負荷がどんどん溜まっていき、開発に時間が取れなくなるのに加え、様々な業務への理解も同時並行で進めていかなければなりません。つまり、プロダクトのカバー範囲が広すぎるが故に、認知的負荷がチームメンバーの限界を超えていた訳です。

そうなると、「何のためにこの機能を作るのか」「それが出来上がるとユーザーにどんな良い影響があるのか」の解像度が低い状態で開発に着手する状況になります。ただ言われたものを仕様通りに作るといった作業的な仕事が増え、課題や改善点を「自分ゴト」と捉えることが困難になってしまうのです。

また、日々の意思決定においても認知的負荷がありました。1つのチームで異なる2つのニーズを捉え、解決すべき優先順位を考えなければならないなど、とにかく同時に解かないといけない連立方程式の数が多すぎるような状態になっていたのです。

そこで、目的意識を持って組織を作る必要性を感じ、チームの規模や役割をしっかりと考えるようになりました。現在の体制になって数ヶ月ではありますが、「なぜ分けるべきなのか」がチームの中で共有され、それぞれの役割が明確に定義されるようになってきています。

実際に、現在の開発体制においてはユーザーとの距離がとても近いです。「自分たちが作るものがどう使われるのか」を高い解像度を持って日々開発ができ、そこにやりがいを感じているメンバーが多いのも事実です。

今後の開発体制について

ドメイン知識を高いレベルで獲得した開発メンバーがいる小さなチームで、小さく素早くプロダクトを作ってリリースする。このサイクルを生み出せるチームをたくさん作ることを今後の目標としています。100人200人の大規模な組織になったとしても、こういった考えを維持しながら、挑戦し続けることが事業の成長に繋がると信じています。

オプティマインドでは「多様性が進んだ世の中でも、全ての人に物が届く世界を持続可能にする」という物流業界の壮大な社会課題を解決すべく、一緒に働く仲間を大募集中です。少しでも興味が湧いた方はカジュアル面談も大歓迎ですので、気軽にお声がけください。

エンジニア領域の募集職種
●ソフトウェアエンジニア
●Androidアプリエンジニア
●組合せ最適化アルゴリズムエンジニア
●経路探索アルゴリズムエンジニア
●バックエンドエンジニア
●インフラエンジニア
●UXUIデザイナー
●VPoE

ビジネス領域の募集職種
●セールスコンサルタント
●オペレーションコンサルタント
●Bizdev

『オプティマインドってどんな会社？』については、こちらから