狩野モデル - Wikipedia という製品品質モデルがあります.顧客がサービスやプロダクトに対して求める品質を5つにカテゴライズしたもので,その中でも特に「当たり前品質」という,あって当然だと顧客が認知していて,欠けていれば不満に思う品質と,欠けていても特に何とも思われないが,充たされていると顧客が喜ぶ品質という対象的な2つの品質があります.
もちろん,「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 でのセッションでもご紹介した以下の図から,そんなドメイン境界を垣間見ることができます.*5FOLIO と PORT という二分はこの図には現れていませんが,各サブドメインが必要に応じて社内向けに特有の機能を提供しましょう,という意識は今でも健在です.
本稿は,10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています.私が今の仕事のコンテキストで特に意識しているトピックやセオリーを,エンジニアリング組織構築に馴染みの無い人へ動機なども含めて説明することを主眼に記述しています.*1 この記事の内容は所属する企業の公式見解ではなく,個人的に仕事をする上で大事にしていることにとどまっていることにだけご留意ください.
例えば上述の図の場合,赤い ☆ の部分に属しているプロダクト A のエンジニアは,プロダクトAのマネージャーとエンジニア組織のマネージャーの両方から評価や指示を受けたりしますが,マネージャー同士の評価や指示が矛盾したときにはどうすればよいかはどう判断すればよいでしょうか?また,メンバーの配置はどちらのマネージャーが主導権を握ればよいでしょうか?決まりが明確になければ社内政治や縄張り争いのようなものに発展してしまうのも想像に難くありません.
System of Record (SoR) とは,出来事が正しく起きることを保証し,起きた出来事を正確に記録し管理するためのシステムを言います.
金銭管理や,法令や規制に基づいた報告義務のあるようなドメインなどがこれに当たります.
SoE と比べれば,情報の取りこぼしやシステムダウンはより致命的であり,リスクを抑えて安定稼働することが求められます.
事前に要件を明確化してコーナーケースなどを慎重に考慮することが求められるので,いくら「アジャイルなソフトウェア開発」を標榜しても,大きな設計を洗い出し*5,正しくシステムが稼働するかの検証にも力を入れる必要があるでしょう.
バイモーダル戦略
SoE / SoR の特性を理解し,開発するプロダクトや,システムを構成する全体の中でも特定のエリアの性格に対応したチーム構成やプロセス設計などのアプローチを取る戦略を「バイモーダル戦略」といいます.比較的大規模なシステムを開発するとき,そのシステムの中にも SoE の特性を持つ部分と SoR の特性を持つ部分があるので,そのことを自覚しましょう,という話です.