関わる人すべてに成長機会を提供したい。オクトの目指す世界観
最初に登壇したのは、CTOの金近望氏だ。彼はまず株式会社オクトや「＆ANDPAD」が生まれたきっかけについて語った。出発点は、金近氏が代表の稲田氏と出会ったことにさかのぼる。金近氏が以前勤めていたITベンチャーに、稲田氏が仕事を発注したことがきっかけで2人は出会い意気投合。サービスを一緒につくることを決めたという。
だが本業を続けながら事業を立ち上げることは容易ではなく、なかなか思うように進まない。「時間が足りないのでは？」と考え、金近氏と稲田氏はシェアハウスをはじめる。だがそれでも時間は足りず、会社を辞めて起業にフルコミットすることを2人は決意した。
稲田氏の「今後はリフォーム市場が伸びる」というアイデアがきっかけとなり、建築・建設業界の課題を解決することにオクトはフォーカスしはじめる。同社が最初につくったのは「みんなのリフォーム」というポータルサイトだ。また、建築・建設業界には「業務が効率化されていない」「人手も足りていない」といった課題が山積みである。その課題を解決すべく生まれたのが「＆ANDPAD」なのだ。
「私たちの経験の積み重ねが、このサービスを生んだと思っています。オクトは建築・建設業界に携わるエンジニアを今後も増やして、関わる人すべてに成長機会を提供したい。これがオクトの目指す世界観です。成長できる構造とは何か、成長するための考え方とは何か。常に試行錯誤を続けています」（金近氏）
では、オクトはどのような組織を目指すことで「成長機会を提供できる企業」を実現しようとしているのだろうか。その鍵は、プロダクト＆組織の構造的マイクロ化とイノベーションループにある。
プロダクト＆組織の構造的マイクロ化とは、上図のような体制を構築することにより「成長するための構造」を生み出していくことを指す。また、イノベーションループとは「アウトプットのトライ＆エラーを積み重ねることで、イノベーションを起こす確率を上げるような行動をくり返していくこと」「他社のナレッジをそのまま適用せず、要素を因数分解することでその本質を理解して他の要素と組み合わせること」を意味している。
「最強のアプリ」を開発するために必要なことは？
次に登壇したのは、CMOの山下大輔氏だ。かつてオクトでは、Ruby on Railsを用いてモノリシックな構造のサービスをつくっていた。初期の頃はその状態でも不便を感じることはなかったそうだが、徐々にサービスの規模が大きくなり携わるエンジニアが増えてくると「同一のドメインを複数のエンジニアで開発するのが大変」という課題が発生してきたという。
その課題を解決するため、2018年後半からオクトは新しいアーキテクチャを取り入れた。Kubernetesを用いてDockerコンテナの環境を構築し、容易にサービスを増やしていけるような構造につくり変えていったのだ。
「これによって、新技術の導入コストが格段に下がりました。ユーザー体験を向上させたいと思ったときに、異なるコンテナの上でサービスを動かすことで、実験場として使えるような状態になるのです。安定的に技術的なチャレンジができる環境をつくっています」（山下氏）
こうしてエンジニアが「開発を楽しめる状態」になることで、大きなスキル向上が望める。その結果、個々のエンジニアが理想的な開発者に近づいていける。オクトが目指す理想的な開発者とは、要件定義やデザイン、実装、テスト、リリース、技術サポートなどサービスのライフサイクル全体にわたる問題を解決する「フルサイクル開発者」だ。
「一人ひとりが自分以外の力を頼らなくても、最強のアプリを自ら考えて開発できるようになることが、私たちの目標です。そういうメンバーが集まったチームが、最強のチームになると考えています」（山下氏）
少数精鋭開発から大人数開発組織へどう移行するか？
最後に登壇したのはエンジニアの彌冨輝彦氏だ。少数精鋭開発から大人数開発組織へ移行するにあたり、同社が工夫していることについて発表した。オクトがスケールする組織体制をつくるために意識しているのは「開発イテレーションが小さく高速で進むこと」だという。しかし、メンバーが増え続ける組織において、その状態を保ち続けるのは容易ではない。
システムの規模が大きくなり依存関係が複雑になると、一人ひとりが処理できる業務範囲が限界を迎えるためバグ発生率が高くなる。また、ユーザーが増えてくると運用保守の負荷が増大する。
そうした課題を解決するために、大きくなった企業では各業務領域に専任の担当者を配置し、多人数の開発体制に移行するのが一般的だ。だが、その体制になった場合に、どうすれば開発スピードを落とさずにいられるのだろうか。
「各メンバーが別々のベクトルを向いて作業をしていると、それぞれの持つ良さを打ち消し合ってしまう可能性が生まれます。チーム全体として同じ方向性を向きながら、かつそれぞれのメンバーがオーナーシップを持って事業にコミットしていく体制を構築していかなければなりません」（彌冨氏）
組織をまとめる方法論として、彌冨氏は2つの手法を提示する。ひとつは各メンバーに裁量を持たせてチームが動いていく「ティール型組織」。もう一方はトップダウンで指示が行われ、それに従ってメンバーが動く「ピラミッド型組織」だ。
オクトでは「エンジニアにとって楽しい組織は、エンジニアがものづくりにコミットできるような体制。だからこそ、最小のマネジメントで自走できるようなチームを目指す」という考え方のもと、平常時はティール型の組織体制をとり、緊急時は障害に対してチームで一丸となって対処するためにピラミッド型の組織体制をとっている。
ティール型組織であるためには、メンバーが日頃から組織の存在目的を意識し、自己推進型のマインドを持って行動する必要がある。そのベクトルを示すため、オクトではメンバーが持つべき行動規範を下図のように定義している。
また、エンジニア組織構造を変更する際に意識していることもいくつかあるという。
1つ目はPull Requestの作成頻度だ。「人が増え活性化することで、開発が高速化してほしい」という考えのもと、この指標をチェックしている。2つ目はPull Requestの対象ファイル数。小さく開発イテレーションを回したいため、対象ファイル数は少なければ少ないほどいい。さらに、新規機能の開発にエンジニアが集中できる体制をつくりあげるため、臨時リリースやバグ発生の数をどう抑えていくかにも着目している。
セッションの最後に、オクトが目指す組織像について彌冨氏はこう語った。
「私たちは、各個人や各チームが自走しながら、目標に向かって動き続けられる体制を目指しています。それを実現するには、会社の各種制度を充実させていき、キャリアや働く環境の自由度を高める必要があるのです。その結果として、自己実現やチャレンジをしやすい状態が生まれていくでしょう。力をフルに発揮できるようになった各個人が、組織にきっと良い変化をもたらしてくれると考えています」（彌冨氏）
お問い合わせ
株式会社オクト
