少数精鋭開発から大人数開発組織へどう移行するか？
最後に登壇したのはエンジニアの彌冨輝彦氏だ。少数精鋭開発から大人数開発組織へ移行するにあたり、同社が工夫していることについて発表した。オクトがスケールする組織体制をつくるために意識しているのは「開発イテレーションが小さく高速で進むこと」だという。しかし、メンバーが増え続ける組織において、その状態を保ち続けるのは容易ではない。
システムの規模が大きくなり依存関係が複雑になると、一人ひとりが処理できる業務範囲が限界を迎えるためバグ発生率が高くなる。また、ユーザーが増えてくると運用保守の負荷が増大する。
そうした課題を解決するために、大きくなった企業では各業務領域に専任の担当者を配置し、多人数の開発体制に移行するのが一般的だ。だが、その体制になった場合に、どうすれば開発スピードを落とさずにいられるのだろうか。
「各メンバーが別々のベクトルを向いて作業をしていると、それぞれの持つ良さを打ち消し合ってしまう可能性が生まれます。チーム全体として同じ方向性を向きながら、かつそれぞれのメンバーがオーナーシップを持って事業にコミットしていく体制を構築していかなければなりません」（彌冨氏）
組織をまとめる方法論として、彌冨氏は2つの手法を提示する。ひとつは各メンバーに裁量を持たせてチームが動いていく「ティール型組織」。もう一方はトップダウンで指示が行われ、それに従ってメンバーが動く「ピラミッド型組織」だ。
オクトでは「エンジニアにとって楽しい組織は、エンジニアがものづくりにコミットできるような体制。だからこそ、最小のマネジメントで自走できるようなチームを目指す」という考え方のもと、平常時はティール型の組織体制をとり、緊急時は障害に対してチームで一丸となって対処するためにピラミッド型の組織体制をとっている。
ティール型組織であるためには、メンバーが日頃から組織の存在目的を意識し、自己推進型のマインドを持って行動する必要がある。そのベクトルを示すため、オクトではメンバーが持つべき行動規範を下図のように定義している。
また、エンジニア組織構造を変更する際に意識していることもいくつかあるという。
1つ目はPull Requestの作成頻度だ。「人が増え活性化することで、開発が高速化してほしい」という考えのもと、この指標をチェックしている。2つ目はPull Requestの対象ファイル数。小さく開発イテレーションを回したいため、対象ファイル数は少なければ少ないほどいい。さらに、新規機能の開発にエンジニアが集中できる体制をつくりあげるため、臨時リリースやバグ発生の数をどう抑えていくかにも着目している。
セッションの最後に、オクトが目指す組織像について彌冨氏はこう語った。
「私たちは、各個人や各チームが自走しながら、目標に向かって動き続けられる体制を目指しています。それを実現するには、会社の各種制度を充実させていき、キャリアや働く環境の自由度を高める必要があるのです。その結果として、自己実現やチャレンジをしやすい状態が生まれていくでしょう。力をフルに発揮できるようになった各個人が、組織にきっと良い変化をもたらしてくれると考えています」（彌冨氏）
お問い合わせ
株式会社オクト
