TechとPoemeの間

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

『ライティングソフトウェア』システムアーキテクトの新しい "Must Read"

ライティングソフトウェア | Juval Loewy, 株式会社ロングテール 長尾高弘 |本 | 通販 | Amazon を読んだ。とても良かったのでメモ。

「システムデザイン」と「プロジェクトデザイン」

本書は、システムアーキテクトの責務を「システムデザイン」のみならず「プロジェクトデザイン」までと論じているのが特徴だ。全体のページの 1/3 が前者、2/3 が後者を占めている。
システムアーキテクトがプロジェクトデザイン (プロジェクトマネジメントではない) までを責務とするべき理由は、本書の第6章で述べられている。マズローの欲求階層説を引き合いに出しつつ、システム開発プロジェクトに於いて、システムデザインの健全性の土台にはプロジェクトが時間、人的資源、リスク管理の観点で健全であるという説明は納得度が高かった。プロジェクトを構成する工程の依存関係やリスクの評価、工程を圧縮する判断はアーキテクチャを始めとする技術的判断が根拠となるため、アーキテクトの果たす役割が重要となる。

根拠のあるプロジェクトコミュニケーション

本書で紹介されている「工期・コスト・リスク」のトレードオフ上の選択肢を複数提示するプロジェクトデザインの方法は非常に具体的だ。
本書に書かれているようなことを意識せずに10年近くこの業界で生活していた自分に強い危機感を覚えつつ、今後の仕事の引き出しにしっかり加えたいと思った。 一方で、この書籍に記載されているシステム構築の前提は「プロジェクト型の開発」であり、いわゆる仮説検証によるプロダクト価値探求を行うプロダクト開発の考え方とは異なるので、自分の置かれている仕事のコンテキストで適切な適用ができるように取り組みたい。


もうちょっと詳しい読書メモ、考えたことなどは適宜更新していきたいので、以下の Scrapbox に。

scrapbox.io

絵に描いた餅のままでは実現できないので、小さく切って1列に並べる

ソフトウェアを作るチームは、要求をインプットとして、実装した機能をアウトプットする 変換器 だと捉えることができる。

f:id:mura-_-mi:20201209233752p:plain

こんなすごいものを作りたい!と、大きな絵 (まさに "Big Picture") を描いたとする。

https://1.bp.blogspot.com/-11IY8US22b8/XXXOmmFKlRI/AAAAAAABUwI/q0vKcClXCAYAp2vvTMgZHwk7HUMKoq84QCLcBGAs/s1600/kotowaza_enikaitamochi_man.png

この理想を、そのままソフトウェアを作るチームという変換器に突っ込もうとすると

f:id:mura-_-mi:20201209233952p:plain

チームはその "大きすぎる" 絵を受け止めることは出来ない。なので、

https://4.bp.blogspot.com/-ahPTU-go-1w/VMIvV5tXOXI/AAAAAAAAq7E/jOEKRp4T1RY/s800/cooking08_kakugiri.png

大きな要求は細かくする。

f:id:mura-_-mi:20201209234347p:plain

しかし、細かくした要求を無闇矢鱈にチームに詰め込もうとすると

f:id:mura-_-mi:20201209234426p:plain

要求たちはチームの入り口で詰まってしまって、チームはやはり受け止めることが出来ない。

f:id:mura-_-mi:20201209234519p:plain

細かくした要求は、明確な意図を持って取り組むべき順番を明らかにし、1列に並べてチームに与え続けるべきである。


というのはメタファーなんだけど。スクラムでは Product Backlog というものがこの「1列に並べた要求」に当たる。スクラムガイドでは、Product Backlog のアイテムがどんな属性を持つべきかは規定していないが、「順番に並べられた」ものであることは明白に規定している。

『アジャイルエンタープライズ』という書籍では、「エンタープライズアイディアパイプライン」の上で、企業活動を記録し、披露し、洗練し、実現し、リリースしよう、と述べている。これも「パイプライン」であり、列に並べられて逐次的に処理されていくという形状をしている。

アジャイルエンタープライズ (Object Oriented SELECTION)

アジャイルエンタープライズ (Object Oriented SELECTION)

  • 作者:Mario E. Moreira
  • 発売日: 2018/03/19
  • メディア: 単行本(ソフトカバー)

この「一列に並べる」という作業は強い意思決定なので、スクラムではプロダクトオーナーは1人にする、とか、プロダクトオーナーチームには Chief を置く、というのが定石になっている。委員会制による合議だと、"Big Picture" は広げるだけ広げることができるが、意思を持って「どの順に攻めてゆくか」という優先度決めは急激に難しくなる。

とりあえず 2020年版の Scrum Guide を読んだのでざっくり感想

www.scrumguides.org

  • Product Goal という新要素。3つの作成物である Product Backlog, Sprint Backlog, Increment にそれぞれ Product Goal, Sprint Goal, Definition of Done という "Commitment" を設けようという話。
    • Product を構築する上で、そのプロダクトをなぜ作るのかを意識しないことってそんなに無いとは思う。
    • けれども、Product Goal が Product Backlog に記載されていることで、「なんとなくこの Product Backlog Item をやりたい」という寄り道をせず、Product Goal の達成のために何をするかに思考を集中させるのだよ、という矯正ができるのは良さそう。
    • 実際、いい感じに Scrum の Sprint がワークしてるな、と思うのは、チームが Sprint Goal と Definition of Done を意識して動いてるときなので、Product Backlog にもその仕組を作りたくなる気持ちはとてもわかるし、実際にそうやって仕事をしている側面は多分にあるよね、というのは再確認。
    • しかし、Definition of Done の "相方" である "Acceptance Criteria" については、2017年にあった「完成を確認するテスト記述」という言葉すらなくなったのか、というのは意外。
  • 冒頭セクションの「スクラムの中核をなす設計や思想を曲げたり、要素の一部を抜かしたり、スクラムのルールを遵守しないことで、問題が起きたり、得られる効果が限定されたりする。それを通じてスクラムが無用の長物だと言われる」という記述。
    • いわゆる「AKB48前田敦子」問題。スクラムを曲解したチームが悪いのに、スクラム自体が悪者にされる現象は、何度か目撃したことがある。
    • なんでこの文言をここに書いたんだろう。スクラムが考案から30年経ち、メジャーになって、上述のような経緯でスクラム嫌いな人も一定存在することを念頭に、その人達をスクラムガイドに引き込むためのアプローチを考えたのかな?
    • 実際、自分もスクラムアレルギーのある人にはこういう話をするなぁ、と思う。
  • Sprint Planning が明確に3ステップに記述されるようになり、従前のステップの前に「スプリントゴールを明確にする」が入った。
    • とても良い。
    • やはりスプリントゴールの有無でチームの生産性は圧倒的に変わる。個人的にも最近の仕事でとても実感している。
  • Sprint Review の記述がとてもシンプルになった
    • これまで「単なるステータスミーティングではない」と書かれていたのが「これは単に新機能プレゼンをするだけじゃない」と書かれたのは印象的。 官僚的なソフトウェア開発からの脱却ではなく、"Broken Scrum" や "なんちゃってアジャイル" からの脱却がスクラムガイドの念頭に置かれるようになったのかな?とエスパー邪推。
  • 「一般的には、チームは小さい方がコミュニケーションを上手にできて生産性も高い」「より短いスプリントは学習サイクルや、費用や労力に対するリスクの軽減に役立つ」という点は明確に書かれている点
    • 全体的に抽象的に書かれている中で、この記述は結構鮮明だな
    • 流石に1ヶ月のスプリントを回すチームってそんなに聞かないけど、「1週間か2週間か」に迷うチームはよくある。 (自分のチームも最初はそうだった)
    • 実際にリモートで仕事するときって10人のチームは結構しんどいよね、というのも実感ある。 (この話はまたどこかで)

お酒飲みながら読んだのでハチャメチャだったら許してください。

ちょうど、2週間前から同僚の数名を対象に「スクラムガイドを音読する会」を実施していたので、2017年版のスクラムガイドも比較的鮮明に記憶に残っていて、Diff が取りやすかったです。

「玉子屋」の動画から見る「リーン」や「フロー効率性」

職場にてメンバーの持ち回りでやってる勉強会があるのだけど、自分の番が回ってきたので、かつての職場でやったように フロー効率性とかリーンの話を取り上げた。かつてはホワイトボードを使っていたけど、再現性と今後の内容のアップデートを出来るようにスライドを作った。2年前よりも内容についてしっくりと来ているなぁと実感出来ている自分がいた。 docs.google.com

リーンを突き詰めた弁当屋玉子屋

最後に参考のページとしてリンク集を設けたのだけど、特に仕出し弁当屋玉子屋」の生産、配達プロセスはこのフロー効率性の観点から見るととても興味深いので紹介したい。 (テレビの動画のアップロードなので、もし削除されていたら検索してほしい)

www.youtube.com

いつの動画なのかわからないのだけど、玉子屋のビジネス成果として、この動画では以下のように紹介されている。

  • 1日の平均販売が6万食
  • 廃棄率0.1% (コンビニ平均は3%)
  • 原価率50%以上 (業界平均は言及されていないが、原価率の高さは販管費に無駄がないことを表す)

動画から読み取れるプロセス改善の工夫

リーンの原則から見ると、教科書的なアプローチを弁当の生産と配達という分野でどう適用しているかが伺い知れる。自分が解釈したのは以下のような点だ。

  • 1日のメニューを1種類に絞る (flow unit のばらつきを無くす)
  • ベルトコンベアを用いてラインの流れを一定にする。 (ステップごとのばらつきを抑制する)
  • ベルトコンベア内での作業内容が均一になるように材料配置のプロセスを分解する (ステップごとのばらつきを抑制する)
  • 曜日/天気等で需要を予測する。 (需要の予測可能性を上げる)
  • 10食以上の法人注文のみを受け付ける。 (需要の予測可能性を上げる)
  • 需要予測が立つことで、生産完了を待たずに配達便が出発できる (ステップ感の依存関係を断ち切る)
  • 注文数量確定後に追加製造、調整便を出す (供給の調整可能性を高める)
  • 作るだけでなく、顧客分析までをパイプラインに組み込む (なるべく広い全体最適を模索する)
  • 配送担当が市場調査担当 (聞き込み、食べ残し分析) を兼ねる (多能工化する)

こういうケーススタディというか、教科書と現実を繋ぎながら頭を使うのも大事だなーと思った。

自社イベント「Scramble!!」にて FOLIO のプロダクト開発について話しました #folioScramble

FOLIO では不定期で自社イベント「Scramble!」を開催しているのですが、昨日行った「Scramble! #3 FOLIO流 複雑なドメインとの戦い方」にて、「ありふれたもの、未だ見ぬもの: FOLIOプロダクト開発の現場から」というタイトルで 20min の発表を行いました。

タイトルはどう付けたら良いのか迷いに迷って変なものになってしまったのですが、要は「複雑なドメインの取っ掛かりの作り方っていくつかあると思うけど、コモディティであるものとオリジナリティのあるものに分けていい感じにアプローチしようよ」ということです。

後半の『どこにもない「テーマ投資」』のセクションでは、社内のメンバーがコラボレーションしている様子の写真も公開したのですが、こちらの写真は会場限定とさせてください。もし気になる方がいらっしゃったら、ぜひ弊社に遊びに来ていただけると嬉しいです。


およそ40人前後の方に来ていただいたのですが、中には以前証券会社で働いていらっしゃったり、現在進行系で金融系サービスのシステム開発に携わっている方もいらっしゃいました。

私のセッションでは、「すでに体系化された業界標準は正しく理解して実装する」「自分たちが作り出すオリジナリティは広い視野でコラボレーションしながら取り組む」という話をしたのですが、セッション終了後の懇親会では、この2つの見境をつけるのが難しいケースもあるよね、という話があり、興味深かったです。FOLIO のテーマ投資はわかりやすい独自性があるからこそ、この2つをそれぞれ意識することが出来るのかもしれません。


今回の Scramble は、テーマが「ドメインとの戦い方」と決まると同時に、「主軸は最近注目を浴び始めた Event Storming にしよう」という流れがありました。最近の FOLIOシステム開発は、プロダクトをそのものをチームと、プロダクトを横断した「基盤」を取り扱うチームに大きく分かれています。Event Storming について発表した奥田 (id:yoskhdia) や横田 (id:ihcomega) は顧客基盤という基盤系のチームに属しているので、もう1セッション、プロダクトチームの事例紹介をすることで聴衆の方々に FOLIO の取り組みを幅広く知っていただくことができたらな、というのが今回のイベントの全体像でした。

セッション数の観点で Event Storming の間に挟まって自分のトークが浮いてしまうのではないかと心配もしていたのですが、蓋を開けると「いろんな立場の人で協力する」「新しい知識を作り出す」「知識の分散化に立ち向かう」など、共通して言及する問題意識も多く、1時間半にも満たないあっという間ではありましたが、FOLIO の今がリアルに伝わる会だったのではないかと思います。


そんな FOLIO では一緒に働く仲間を募集しております。また、Scramble には参加できなかったけどもっと詳しい話を聞きたい!という方もぜひ遊びに来てください。

hrmos.co

hrmos.co

hrmos.co

(他にもいろんな職種があるので 募集職種 | 株式会社FOLIO をチェック!)

ざーっと振り返る2018年

みんなが書いているから自分も書く

1月

前職で働いていたのだけど,12月の段階で後輩たちをはじめ,周囲には退職の意向は伝えていたので,ひたすら自分の知っている知識を伝授していた.1月にやったのか12月だったのか覚えていないけど,後輩2人と一緒になって スクラムガイド を全部音読したのは,学びも多かったし楽しかったなぁ.

その伝授の過程で教えたこととか,チームで編み出したやりかたとかブログにまとめてたりもした.この勉強会 あたりからアドテクスタジオ内のゼミのメンバーにも参加してもらったり,それがきっかけで他のプロダクトの勉強会に呼んでもらえたりした.


t-and-p.hatenablog.com アドテクスタジオは,どこもかしこも振り返りといえば KPT くらいの勢いだったのだけど,それに違和感を覚えていた自分が昨年末くらいから編み出していた名もなき手法*1をまとめてみたりもしていた.

ちょっと話が前後しちゃうのだけど,2月に FOLIO に入ってみたら,僕のブログを読んだバックエンドエンジニアのチームがすでにこの手法を取り入れていたり,最近はモバイルアプリを開発しているチームとかが使うようになって,普段あまり一緒に仕事しないメンバーから「あれってむらみんさんが考えたやつなんですか?」とか言われたりしたり,発信冥利に尽きるような反応もたくさんあった.


RSGT2018 行った.昨年は部分的にしか行かなかったけど,2日間どっぷり浸かれてよかった.

t-and-p.hatenablog.com


そういえばこの時期からホットヨガに通うようになった.ジム通い半年くらいしなくなってた頃だったのだけど,単に筋肉鍛えるだけでは出来ない動きもできるようになったなぁと今になると思う.

2月 ~ 3月

FOLIO に入った.今でも同じこと思っているけど,本当に周りのメンバーの知識のレベルとか高くて,いろいろ大変なことも多いけどめちゃ楽しく仕事してます.

入って2ヶ月くらいは,普通の開発仕事もしつつ,スクラムとかフロー効率とか「アジャイル」という文脈で出てくる知識の啓蒙とかも進めてた.

4月 ~ 8月

この時期は仕事が大変だったのでアウトプットほぼなし… 仕事何してたっけな… いろいろやってたけど正直あまり成果が出せなくてもどかしかった時期です.

そんな時期にインタビュー受けてました. press.forkwell.com

9月 ~ 12月

会社が新しいプロダクトのサービスを始めたり,いろんなステークホルダーとのコミュニケーションが絡まりきってて成果までのスループットが出てないなぁという課題に直面し始めてきて,それまでよりも大きな範囲の仕事をさせてもらえるようになった.それの話をまとめたのが今月の2本のブログです.種を撒いて成果が出るまでどれくらいの時間が必要かわからないけど,来年はこれの続きをちゃんと自慢できるようになりたいですねぇ.

t-and-p.hatenablog.com

t-and-p.hatenablog.com


あと,会社がスポンサーしたイベントでスポンサーセッションとして喋ってきました. 

speakerdeck.com

自分で CfP 出して登壇したのではないので,自分の実力じゃないわけだけど,それでもこういう経験させてもらってラッキーだったなぁという感想.もちろん,会社として技術的にどういう取り組みしているの?というのはもっと発信しなきゃいけないなぁとは思っているので,来年も続けていきたいというか,来年は自分で CfP 出して話したいですね.


ということで来年も頑張ろーっ.

*1:今でも名前がない

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つにしたりという,図を描く上での "お化粧" が多く施されている点にはご留意いただきたいです