TechとPoemeの間

Qiita に書かないエンジニア業の話

FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬

この記事は何

昨日， Engineering Manager Advent Calendar 2018 にて 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間 という記事を公開しました．その記事の続編かつ実践編として，本記事では， FOLIO が2017年から2018年にかけてどのようにエンジニア組織を形成し，課題を抱え，その解決のためにどのようなアプローチを取ってきて，更にその後どのような課題に取り組もうとしているかを紹介しようと思います．自分が FOLIO に入社するよりも前の頃の話も多く含まれていますので，その点はご留意ください．

この記事は, FOLIO Advent Calendar 2018 14日目の記事です．

adventar.org

βリリースまで: 職能組織

FOLIO がサービスのβリリースを目指していた頃，FOLIO で開発中の「プロダクト」と呼ばれるものは「国内株によるテーマ投資」ひとつしかありませんでした．*1 そして，当時のプロダクト開発を行う組織は「フロントエンドエンジニア」「バックエンドエンジニア」「インフラエンジニア」などといった職能による区切りのみがあったそうです．

自分は当時の組織を直接見ていたのではないのですが，どちらかといえば，フルスタックにスキルを持つタイプのメンバーよりは，自分の得意分野に深い知見を持っていたメンバーの方が多かったために，このような配置になっていたのかなと想像しています．一般的にはコミュニケーションのオーバーヘッドや局所最適を引き起こすとされる職能ベースの組織ですが，βリリースの後も長くに渡ってサービスを支えるソースコードやシステムの基礎を高いクオリティで作りあげるという点ではメリットがあったのかなと理解しています．

プロジェクト体制

FOLIO のテーマ投資プロダクトは，2017年7月のβリリースまでは漕ぎ着けたものの、まだまだ足りていない機能が山のようにあるような状態でした．この頃になると，足元にある課題を着実にひとつずつ解決していくためのプロジェクト制が明確に組織の中に組み込まれるようになり，職能ベースのチームを保ちつつも職能を横断したプロジェクトベースの組織が複数組成されるようになりました．

「プロジェクト」という単位が明確に組織の形に落とし込まれることで，当然ながらその時々でどのような目標を持ったプロジェクトが存在するのかがわかるようになります．(逆に言うと，それよりも前はこういったことも上手く開発プロセスの中で管理できていなかったというわけなのですが…)

進行中のプロジェクトが扱っている開発中の仕様のドキュメントや，プロジェクトのスコープや課題の一覧をまとめるpj-doc と呼ばれるプラクティスが社内で確立したり，開発ボリュームの見積もりについても様々な失敗を経験しながら知見を溜め続けるなど，特にここ1年で組織全体的にプロジェクト運営の練度が上がったかなぁという実感があります．

www.slideshare.net

組織組成においてプロジェクト色が強くなることで起きた問題

プロジェクトベースでエンジニアリング組織を運営することで，ビジネス展開を行う上でのプロダクトの課題は着実に解決されるようになってきました．一方で，ほぼすべての開発をプロジェクトという体制で行うようになったことで出会う成長痛もありました．ちょうど，自分が FOLIO に入ってミドルマネジメントに関わるようになったのが，これらの問題に直面している頃でした．

マイクロサービスのオーナーシップの不明瞭さ

FOLIO のバックエンドシステムは23個*2のマイクロサービスからできています．1つのプロジェクトですべてのマイクロサービスに手が入ることは基本的になく，プロジェクトごとに大きく開発が必要になるサービスは異なります．プロジェクトが終わればそのプロジェクトのメンバーは他のプロジェクトに取り組みます．しかし，プロジェクトが変われば全然違うマイクロサービスを触らなければいけないことも珍しくありません．

一般的にマイクロサービスアーキテクチャというと，組織がドメイン境界に応じて細かく分かれており，それと同じようにシステムもドメイン境界で分かれているようになるような形を取ります．しかし，FOLIO の場合はシステムこそマイクロサービス的に細かく分かれていたものの，それを作る開発チームはどちらかといえばモノリシックにできているような状況でした．

こうなることで，コードを書く上でも「将来的に誰がこのコードを触るかわからないから」と，無難なコードであったり設計をすることしかできなくなります．また，特定のマイクロサービスにオーナーシップを持つメンバーが明確でないため，コードベース上の技術的負債の管理にオーナーシップを持つメンバーがいないという問題にも悩まされました．*3*4

社歴が長かったり，いろいろなマイクロサービスの基礎を作ったりしてきた特定の詳しい人に負担が集中するようなことも当然発生しており，持続可能なプロダクト開発を実現するためには何らかの手を打たなければなぁ，と考えざるを得ない状況でした．

作って終わりではない「プロダクト」

「証券会社を支えるシステム」と一口に言っても，それを構成する各パーツひとつひとつが既存の証券会社では一つの部署になるほどに巨大であり，また複雑です．FOLIO はそんな証券会社をゼロから証券会社を作るという特性上，常に足りていない機能を作ることに奔走しています．一方で，スタートアップとして事業やプロダクトを成長させるという観点では，本来は KPI と常に戦い続け，その KPI に沿って何を作るかを決めるという判断の軸も間違いなく必要でしょう．

狩野モデル - Wikipedia という製品品質モデルがあります．顧客がサービスやプロダクトに対して求める品質を5つにカテゴライズしたもので，その中でも特に「当たり前品質」という，あって当然だと顧客が認知していて，欠けていれば不満に思う品質と，欠けていても特に何とも思われないが，充たされていると顧客が喜ぶ品質という対象的な2つの品質があります．

証券会社としての「当たり前品質」は，要件が比較的明確でありながらもひとつひとつが巨大であり，これらを満たしてゆくためにはプロジェクトベースの組織は有効でした．一方で，これまでに前例のないようなターゲティングの取り方や金融商品の魅せ方をする FOLIO が「魅力的品質」を伸ばしてゆくためには，そもそもどのような施策に効果があるかもわからず，大きな機能追加も細かい改善も必要になるし，もっと経験主義的に問題発見と解決をする必要があるよね，という課題感はなんとなく社内に漂っていました．このまま，何かプロダクトに手を入れるときに必ず「プロジェクト」という形を立ち上げなければならない組織では，プロダクト開発の中で充分な機動力が得られないのではないか，という課題意識が浮かび上がってきました．

実際，今年の前半には，LINE 上でのテーマ投資を可能にする LINE スマート投資 向けの機能開発プロジェクトと，投資一任型による分散投資ロボアドバイザーである おまかせ投資 リリースに向けた開発プロジェクトという2つの巨大な新規開発プロジェクトにほとんどの開発リソースを集中させており，テーマ投資単体での，商品の魅せ方や取引体験の向上といったプロダクトの進化に力を割くことが難しかった時期もありました．

ウェブサービスと証券システム, または SoE と SoR

FOLIO では，口座開設を希望されるお客様が提出してくださった書類を審査する業務や，お客様からのお問い合わせにメールや電話でお答えするカスタマーサービス，お客様にお選びいただくテーマやテーマを構成する銘柄の選定，入稿を行う業務や，そのテーマの紹介文を編集し，その文言のコンプライアンスチェックを行う業務など，様々な業務フローが存在します．

これらの業務をサポートするための社内向けウェブアプリは，かつては単純に「管理画面」と呼ばれていました．しかし，これは単純に「管理画面」なのではなく，その奥にあるのは証券会社のバックオフィスシステムであり，お客様に提示するサービスと同等かそれ以上に重要なシステムであるという意識やモチベーションを会社全体で共有するため，これらのバックオフィス系証券システムを指す概念として「PORT」という名前がつけられました．

これらの経緯は，昨年の Advent Calendar にて公開された記事でも取り上げられています ．自分が FOLIO に入社したのは「PORT」という言葉が生み出されてからかなり経った頃でしたが，実際に入社してみて，名前を付けることがもたらす，作る人と使う人が持つシステムへの愛着を強く実感したのを覚えています．

f:id:mura-_-mi:20181209183703p:plain
PORT と FOLIO の関係 (2017年に描かれたもの)

もちろん，「FOLIO」というお客様向けのプロダクトと，それを支える業務システムである「PORT」という分類の背景には， System of Engagement (SoE) と System of Record (SoR) によるバイモーダル戦略 があったわけです．

しかし，今年の1月~3月ごろにかけて， FOLIO と PORT で開発チームを分けたり，開発サイクルを分けてみるという試みをしたのですが，結論から言うとうまくいきませんでした．ホットで巨大なプロジェクトが立ち上がり「PORT というプロダクトの開発」にリソースが割けなくなったという不可抗力の事情もありましたが，お客様の個人情報を取り扱う API や， FOLIO でお客様にご提示するテーマ一覧を CRUD する API などを始めとする多くのコンポーネントを FOLIO と PORT の両方が参照しており，既存のシステムを簡単には二分できないという，より本質的な課題にも直面しました．

バックエンドエンジニアのサブグループ化

ここまでで，「プロジェクトベースの組織が主になれば組織の顔ぶれは安定しない」という問題と，「SoE と SoR によるバイモーダル戦略を用いてシステム全体を二分しようとしても綺麗な境界を引くことはできない」という問題に直面したわけですが，特にこの影響を受けていたのばバックエンドシステムエンジニアたちでした．今年の10月の時点でバックエンドエンジニアは16人いたのですが，この人数は "Stable Team" として運営するのには多すぎるし，バックエンドシステムの守備範囲の広さを考えても，「全員で全部のシステムを理解する」ことは難しいと言わざるを得ませんでした．

そこで着目したのは，別段新しいことではなく，「ドメイン境界に向き合う」ということでした．Scala 関西 Summit 2018 でのセッションでもご紹介した以下の図から，そんなドメイン境界を垣間見ることができます．*5 FOLIO と PORT という二分はこの図には現れていませんが，各サブドメインが必要に応じて社内向けに特有の機能を提供しましょう，という意識は今でも健在です．

このようなドメイン境界の整理ができれば，あとは「逆コンウェイ戦略」に則ってバックエンドエンジニアのサブグループをつくっていきます．人数とマイクロサービス数を勘案して，4~8ほどのマイクロサービスを担当する3~6人ほどのチームがいくつか立ち上がりました．そして，このサブグループごとにプロジェクトに取り組むようにしつつ，プロジェクトの粒度にならない開発も合わせて行うように仕事の進め方を変えていきました．

サブグループにチーム意識を植え付けることで，技術的な負債や課題，運用上のトイルに対しても個人でではなくチームで立ち向かう意識が出てきたり，ドメインモデリングを行うワークショップを行って知識共有をするチームが現れたりと，良い副作用も見受けられるようになってきました．

複数プロダクト時代へ

当初は「国内株によるテーマ投資」のプロダクトのみを展開していた FOLIO でしたが，LINE スマート投資 を10月に，「おまかせ投資」 を11月にリリースし，複数のお客様向けプロダクトを展開してゆくフェーズに突入しました．

更に，今年の11月に行われた LINE Fintech Conference にて発表された LINE スマート投資上でのワンコイン投資プロダクトなどを始めとして，これからも多数の投資プロダクトの展開を予定しています．

プロダクトが違えば技術的な特性も違うし，ビジネスモデルや追うべき KPI も異なります．これまでだと一つのプロダクトを進化させるために組織全体でどのプロジェクトから順番に取り組むか？という考え方で組織運営ができましたが，複数のプロダクトがある中で一つの優先度にすべてを落とし込むことも難しくなってきました．

職能組織の限界

同時に，職能組織の限界も見えてきました．職能チームの中でも担当しているプロダクトやサブドメインが違っていたり，職能は異なるが同じプロダクトに関わっているメンバーの間でのコミュニケーションオーバーヘッドが目につくケースも増えてきました．

また，フロントエンドエンジニアがバックエンドに転身したり，バックエンドエンジニアがデータ分析系のエンジニアに転身したりというケースも増えてきました．

例えばフロントエンドからバックエンドエンジニアに転身したメンバーは，バックエンドのチームにいるから Web サイトのコードに手を加えてはいけないというルールは設けていませんし，むしろ一つのプロダクトをフロントエンドからバックエンドまで一貫して触れるようになったほうがメリットは大きいはずです．

組織上の異動は伴わずとも，既存の職能の境界にとらわれずに仕事をしたい！という意思を表明してくれるメンバーも増えてきており，ボトムアップの方向からも「職能の軸からプロダクトの軸へ」という機運が高まってきたのかなという実感があります．

プロダクト組織へ

ここまでの流れなどを踏まえて，職能を越えて「プロダクト」という軸で組織の編み直しをしようとしているのが今のフェーズです．

組織の編み直しをする際には，いきなりすべての既存の枠組みをなくすことはできず，どう上手に「過渡期」を作るかが重要になると考えています．一方で，いつまでも過渡期をダラダラと続けていても良いことはないので，どこかに思い切りの良さも必要になってくるわけで，そのバランス感には常に頭を悩ませています．

これまではProduct Manager という役割を担って仕事をしているメンバーはおらず，経営レイヤで事業やプロダクトの重要な意思決定を行ってきたのが実情です．今後はプロダクト軸でシステム面・ビジネス面の課題を整理しつつ，KPI 達成をミッションとするようなロールを担うメンバーを設けられるようにするべく，経営メンバーまで巻き込みながらいろいろな準備をしているところです．

まとめ

今年のはじめに50人ほどだった FOLIO のメンバーは，今や100人に迫る大所帯になりました．本稿でも触れたように，今年1年だけでもプロダクトの展開など組織を取り巻く状況は大きく変わってきました．今年1年を振り返りながら本稿を書き，その時々の事情に合わせて適切なアクションを取った組織運営をすることが大事だな，と改めて思いました．

2019年も，この流れでプロダクトもエンジニアリングもすいすいと進化していけるような組織にできるように頑張っていきたいと考えています．

明日の FOLIO Advent Calendar 2018 - Adventar は， ふじたく (@magie_pooh) | Twitter さんです．弊社の Android アプリは Google Playベストオブ2018 で隠れた名作部門賞大賞を受賞したのですが，この Android アプリ開発の中心にいたのが ふじたく さんです．開発開始からリリースまでの長きにわたるストーリー，今から楽しみです！

*1:実際には，この頃からロボアドバイザープロダクトのローンチまで構想がありました

*2:2018年12月上旬時点の数字です．この問題が顕在化してきたときは20弱くらいだったと記憶しています．

*3:後からコードを触ることになるメンバーのためにユビキタス言語を wiki に残すような取り組みも始まったのですが，やはりコードを説明するドキュメントは腐りやすいので，できれば組織の安定で解決したい問題だと考えています．

*4:FOLIO のバックエンドシステムは大半が Scala で書かれており，アプリケーションのレイヤ分けと，ドメインレイヤにおける知識の型情報による表現でキャッチアップを用意にする取り組みは効果的だったかなと考えています．こういった取り組みは Scala でつくる証券会社とスタートアップ / Securities and Startup with Scala - Speaker Deck にて紹介しています．

*5:説明の簡略化のために，FOLIO 単体のテーマ投資に限って配置を書いたり，一部のマイクロサービスを省いたり，実は1つのマイクロサービスの中に含まれてしまっているのだけどこの図の上では独立しているように書いていたり，逆に複数のマイクロサービスから成立しているけれどもドメイン境界としては1つにまとまるので図の上では1つにしたりという，図を描く上での "お化粧" が多く施されている点にはご留意いただきたいです