こんにちは！株式会社東京ファクトリーの執行役員CTOのIkawaと申します。

　東京ファクトリーでは製造業を中心としたお客様向けにSaaSプロダクト『Procceedクラウド』提供しています。この記事ではプロダクト開発の観点から東京ファクトリーがどのような会社かご紹介します。今回のテーマは「開発チームの再構築（チームの構成と兼務システム）」です。

背景

　東京ファクトリーでは、以前はプロダクトオーナーをハブとし、エンジニア個人単位で機能実装を行うスタイルで開発が行われてきました。フルタイムの開発メンバーも増え開発工数も多く確保できるようになってきたことから、より効果的に開発を進め、今後も組織をスケーラブルに拡大できるように開発チームの再構築をしようとしています。

　一般に、多くの企業で開発チームの分け方として、(i) 職能ごとのいわゆる縦割りの組織、(ii) クロスファンクショナルな職能横断型の組織、(iii)マトリクス型の組織、のどれか（やそれらを混合したもの）が採用されていると思います。東京ファクトリーの開発チームでも、(ii)のクロスファンクショナルチーム(CFT)でのスクラム開発を中心としつつ、(i)(iii)の要素も取り入れてチームを再構成しようとしています。

　この記事ではどのようなチームをどのような考えで作ろうとしているのかご紹介します。

要点

• 領域ごとにクロスファンクショナルなスクラムチームで開発チームを作ろうとしています
• チームの構成と、ナレッジの構成を同期させていて、ナレッジが職能ごとに分かれる部分では職能ごとのチームも活かしています
• 基本的に複数のチームやロールを兼務して働く仕組みを作ろうとしています

基本的な考え方 - 知識・目標・チームの構成の同期

今回チームを構成する上で最も重視したことは、組織が持つ知識構造（ = ナレッジをどのように整理するか）と目標（ = KPIやOKR）とチームの構成を一致させることです。

まず、うまく機能しているチーム・していないチームを分析し、

• 同じナレッジを共有する必要がある人々はチームとして協業する必要性が高く、ナレッジを共有しなくてよい人々は同じチームである必要性が少ない
• 担当するチームが決まっていない目標や指標はサイクルがまわらない
• 目標や指標に紐づかないナレッジはメンテナンスされず負の遺産になっていく

という仮説を立て、知識・目標・チームの構成を同期させることとしました。

知識体系の整備と分類

　上記の仮説に基いて、チームの構成を考えるために、まずナレッジの整理から行いました。これまでは様々なナレッジが社内のNotionに体系づけられずに散在していたのですが、それらを整備しました。目標・チームの設計にも合わせることも踏まえながら大きく分けていくと、以下のような構成になりました。

• (1)プロダクト開発の全体に関わるが、職能ごとに紐づけられる知識
• • (1a)プロダクトの価値自体を上げる・高く保つための知識
  • (1b)プロダクトに価値を実装する速度（ベロシティ）を上げる・高く保つための知識
  • (1c) その速度を長期的な観点で加速度的に上げる・高く保つための知識
    
• (2)職能を横断するが、プロダクトの特定の領域に紐づけられる知識

　これら(1a)を「Product」 (1b)を「Engineering」 (1c) を「Technology」(2)を「Delivery」と社内で呼ぶことにしました。また(1a)「Product」の一部や、(1b)「Engineering」の一部は(2)「Delivery」と関連していることが観察できました。

知識構造から目標設定への展開

　上記のように知識構造の分類すると、同じよう構造で目標もうまく階層化できそうです。まだ準備中の段階ですが、今後階層的なOKRを設定し、トップダウン・ボトムアップに目標をすり合わせながら運用していきたいと考えています。それぞれの領域での目標の例を考えてみると例えば以下のようになります。

• Product - プロダクトの価値例）NPSスコアがXX、システムに関する問い合わせ件数がn件/月、サービスレベルがXX%など
  
• Engineering - プロダクトに価値を実装する速度例）ストーリーポイントの消化数がXX/週、エンジニア採用がn人/月など
  
• Technology - 長期的な加速度例）AWSの勉強会を開いてインフラを触れる人をn人以上にする、XX%のチームにTDDを浸透させるなど
  
• Delivery - プロダクトの個別領域例）機能ごとの具体的なKR or KPI。Hoge機能の利用数がXX件/ユーザ数。
  

知識構造からチーム構成への展開

さて、ようやく本題のチーム構成についてです。

　チーム構成も知識構造・目標と同じように大きく4つ「Product・Engineering・Technology」と「Delivery」に分けて運用していくこととしました。イメージしやすいように一般的な職能を当てはめてみると以下のようなイメージです。（実際にはまだまだ人数が少ないため、各人が複数の役割をカバーしている状態です）

　このように分類すると、職能ごとのチーム（「Product・Engineering・Technology」）と領域ごとのチーム（「Delivery」）を知識や目標の構造と同期した形で構成することができました。知識の構造と同じく、「Product」の一部と「Engineering」の一部にまたがって、領域ごとに「Delivery」のチームが構成されます。

　一般にマトリクス型組織での検討事項として、2つのチームどちらを主とするか、というテーマがあります。弊社の場合、開発を担うソフトウェアエンジニアを例にとって見てみると、「Delivery」チームに所属しつつ、「Engineering」チームとしての職能ごとチームにも所属することになります。複数のチームに属することになりますが、「(A) 日頃の業務の中で活用し蓄積していくナレッジは「Delivery」であることが大半」であり、かつ「(B) より直接的に「Delivery」の目標にコミットしている」ことから、「Delivery」のチームを主体として活動することとしています。

チーム及び役割の兼務

　ここまで、現在構築しようとしているチームの構成について記載してきました。知識の構造から再整理することで、チームや職務の定義が以前より明確になったと感じています。一方で、このチームを実現するためにはまだまだ人数が足りないため、一人が複数のロールを担う必要があります。

　そこで現在「マルチジョブロールシステム」と名付けた仕組みを導入しようとしています。これは基本的に一人当たり複数のロールやチームを兼務してもらう仕組みです。（入社直後は主担当の1ロールのみ）

　開発を担うソフトウェアエンジニアの場合、主となるDelivery Teamでのロールが1つと、そのほかのロール2つの3兼務程度となります。稼働時間のうち、主となるロールでの仕事が60%〜80%、その他の仕事がそれぞれ10%〜20%を目安としています。

　働くメンバー側のメリットとして「プロダクトへのオーナーシップの醸成」「スキル・キャリアアップ」「飽きの防止」「（単純に）楽しい」があると考えており、会社側としても「知識の蓄積」「属人化の防止」「スペシャリストを専属で雇わなくてよい」といったねらいがあります。

担当するロールやチームについては、各人の得意なことやチャレンジしたいことを元になるべく希望に沿った形でアサインするようにしています。

開発チームメンバー募集中

東京ファクトリーの開発チームは発展途上で、これから開発チームを上記のように整理していって、改めてスタートを切る段階です。

• これから共にチームを作り上げたい
• スタートアップでのチーム作りを見てみたい
• 様々な役割を経験して成長したい
• もっと良い開発チーム構成の方法を教えてあげたい

など、少しでも興味があれば、ぜひ一度お話させてください！