FOLIO で フロントエンドチームリーダー 兼 プロジェクトマネージャー (PJM) をしている @pika_shi です．PJM としては，おまかせ投資 を今年の春から見ていて，11 月にようやくローンチしました．

フロントエンドとプロジェクトというと，性質の違う 2 つのものを見ていると思われるかもしれません．自分も当初はそう思っていたのですが，時が経つにつれ，プロジェクトマネージャーの責務は BFF のアナロジーで考えられる ことに気づきました．今回はその話について書いてみようと思います．

BFF (Backends for Frontends)

はじめに，BFF について軽くふれておきます．FOLIO のシステムは 20~30 のマイクロサービスで構成されており，その前段に，これらをクライアントに適した形でアグリゲートする BFF を置いています．現在，Web 用の BFF と，iOS/Android アプリ用の BFF の 2 つがあります．

BFF はそれぞれフロントエンドチームとアプリチームで開発しています．バックエンドチームと独立して開発を進めることできるため，UI マターの機能変更に柔軟かつスピーディに対応することができています．

プロジェクトマネージャーにおける BFF との共通点

次に，先程の図の BFF の部分に PJM，マイクロサービスの部分に社内の各セクションをマッピングしてみました．これは FOLIO における一般的なプロジェクトマネジメント体制であり，同一の構造をしていることが分かります．

このように対比させることで，システム設計において重要なポイントを，プロジェクトマネジメント体制においても重要なポイントとして浮かび上がらせることができます．ここでは，その中から 分割統治，統一的なインタフェース，全体最適化 の 3 つについて書いてみようと思います．

① 分割統治

システムが小さい時は，モノリシックな構成でスピーディに開発を進められます．しかし，システムが大規模になってくると，その複雑さに引きずれて，徐々に変化に対応するのが難しくなってきます．それを因数分解するアプローチとして，マイクロサービスアーキテクチャがあります．

プロジェクトについても同様で，メンバー数が少ない場合は，上図のようなモノリシックな体制でスピーディに進められます．例えば少人数のスタートアップだと，必要に応じてその場で全員で合意形成をしながら進めるのが効率的なのは明らかです．

しかし，ステークホルダが増えてくると，会議の調整や意思決定のプロセスが必要になってきて，コミュニケーションがどんどん非効率になってきます．なので，適切なサイズにチームを分割し，結合度を下げていく 必要があります．

そこで，どのように分割するかを考える必要が出てきますが，重要なのは，マイクロサービスの考え方と同じく，独立性の高さに基づいてチームを区切り，それぞれで最適なプロセスを形成することです．そして，それぞれのチームでの意思決定を PJM がアグリゲートしていきます．

ただ，独立性の高いチームを切り出すといっても，100% 独立にすることはできませんし，プロジェクトのフェーズによっても結合度は変わってきます．なので，チーム間で発生しているコミュニケーション (⇢) に関しても，PJM はトラッキングしておく必要があり，それが頻発しているようであれば，随時区切り方を見直し，⇢ をミニマイズし続ける必要があります．

② 統一的なインタフェース

マイクロサービスアーキテクチャのメリットとして，サービスごとに技術選定や運用体制を独立させられることが挙げられます．そして BFF が，それらをアグリゲートした上で，プロダクトに最適なインタフェースにコンバートして返します．

これは，ステークホルダが多様なプロジェクト体制においても同様の考え方が適用できます．チーム内では各々最適なプロセスで進めてもらうことでスピード感を保ち，かつ最終的な仕様などのプロジェクトとしてのアウトプットに関しては，PJM が統一的なインタフェースで管理することで，プロジェクト外のステークホルダの体験を保ち続けることができます．

FOLIO では，金融出身の方が多いチームと Web 出身の方が多いチームで慣習が結構違ったりするため，無理にプロジェクト全体で標準化するよりも，上記のように PJM がアグリゲートする体制の方がスピーディに進めることができるように感じています．このパターンは，組織パターン の 4.1.22 「誰か 1 人を犠牲にする」で取り上げられています．

③ 全体最適化

マイクロサービスアーキテクチャでは，ボトルネックなサービスに全体のレイテンシが引きづられてしまいます．なので，サービスごとに検証をおこなうことでボトルネックを特定し，解消していく必要があります．

プロジェクトでも同様で，ボトルネックなプロセスがリリース日にダイレクトな影響を与えるため，それを見極めるためにクリティカルパスを明らかにしていく必要があります．そして，そのプロセスのコミュニケーション等を最適化することが，全体最適 (リリース日のミニマイズ) につながります．

そして PJM は，ボトルネックなプロセスの最適化にリソースを割くことができるためのバッファを常に持っておくべき だと感じています．各フェーズで，ボトルネックになっているプロセスに直接入っていき，うまくトリアージすることが，結果としてプロジェクト全体の炎上を防ぐことになります．

ただ，それでキャパオーバーになって PJM 自体がボトルネックになってしまうと本末転倒です．それはちょうど，BFF がビジネスロジックを持ちすぎてボトルネックになってしまう問題と似ています．なので，リソースの ● % をトリアージに使うなどと，あらかじめ決めておくのがよいと思います．

以上，プロジェクト体制とシステム構成を対比させることで，プロジェクトマネージャーとして重要なポイントを浮かび上がらせてみました．

エンジニアからのマネジメントキャリアパスは，ネガティブなコンテキストで語られることも多いですが，組織体制的なアーキテクチャもシステムアーキテクチャも，根本にある考え方は共通するものが多いので，このようにアナロジーで考えると入っていきやすいです．

この記事は FOLIO Advent Calendar 2018 19 日目の記事でした．明日は FOLIO が誇る CDO @hajipion の記事です．