モチベーション

約半年ほど「アーキテクチャの改善」というテーマで探索的に行動してきた。公私共に一定の時間を割いて学びながら、検証しながら考えを理解し、成果を作ってきている。まだ理解しきれているとは言い難いが、いくつかの考えがつながって見え始めてきており、今時点での考えを整理するためにコンセプト化を試みる。ここで触れる内容は一般論を参考にしながら自論を展開したものであり、何かの正しさを保証するものではない。考えは今後も変化するもので、一時的なスナップショットという位置付け。

不確実で掴みどころのないテーマに対して、持ちうるリソースの中から考えを提示しイシューを見極め、適切なアプローチを選択して解決に動く。アクションの中で見つかる気づきと事実を元に考えにフィードバックをかけて、より良い答えを見出す。そんな不確実な課題を解く際に必要とされる、コンセプチュアルスキルを試す意図もある。

コンセプト概観

モジュール・ファースト

• モジュールで構成されるプロダクト。およびモノリスからモジュールプロダクトに進化させる取り組み
• プロダクトと組織のスケーラビリティとアジリティを獲得するチャレンジと捉えられる
• プラクティスとしてはアーキテクチャパターンのモジュラモノリスへの移行
• 一般論で言われる保守性の向上を目指すだけでではなく、拡張性を得ることも目指す
• モジュール化は事業機会の適応に向けた布石、最終的にはプラットフォーム化に向かう
• 半年の模索を経て2023/01時点でのモジュール化のアプローチコンセプトを定義する
• このコンセプトは今後も変わりうる、成果を保証するものではない
• 何を考えて、どこに向かって、どういった成果を作ろうとしているのかを示す

成長サイクルとドライバー

• 事業はパートナーモデルを採用している
• パートナーの成長が自社の成長に跳ね返る特徴があり、健全な意思決定に至りやすい
• 成長サイクルを回すドライバー(原動力)は2つある、事業成長と事業機会
• 事業成長は価値を広く高頻度に届けることを目指す、最終的にGMVで測ることができる
• 事業機会はプロダクトをマーケットに投下することで、エントリー数とその質で測ることができる

因数分解で見えてくるセンターピン

• 事業成長と事業機会という2つのドライバーに対して影響を与える変数は多くある
• グロース目線では新規獲得戦略、運用戦略目線ではキャパシティ、BizDev目線では新規開発
• プロダクト目線のスコープで見ると、アーキテクチャ特性が最も影響を及ぼしていると考える
• 事業成長はアジリティ、事業機会はスケーラビリティ
• 事業成長はアジリティが重要、なぜなら仮説検証が成長を引き上げる改善の根幹であるから
• 事業機会はスケーラビリティが重要、なぜなら機会に適応することでマーケットが広がるから
• アジリティは事業機会にも影響する、なぜならマーケットへの投下速度を規定する特性でもあるから
• 事業を大きく成長させるには2つの性質を獲得し、維持することが何よりも重要
• アジリティはメタ特性と呼ばれる概念で、サブセットの特性 (保守性, テスト容易性, デプロイ容易性) を揃えると得られる
• スケーラビリティもメタ特性で、サブセットの特性 (変更容易性, モジュール性, 再利用性) を揃えると得られる
• 2つの特性を因数分解すると共通の特性 (変更容易性, モジュール性, 再利用性) に行き着く
• 3つの共通した特性群には順序効果の特徴があり、変更容易性を得ることがモジュール性を得る機会につながり、モジュール性を得ることが再利用性を得る機会につながる
• 変更が容易でモジュールとして扱うことができ、再利用可能な状態は、保守性と拡張性が得られていると言える
• 保守性と拡張性に点線が結ばれている。これらは変更という観点では同じだが、向き先が内部最適化(修正)なのか、外部最適化(拡張)なのかで意味が違うということを示している
• 変更容易性が2つのドライバー(= 特性)に共通で影響を及ぼせる変数、つまりはセンターピン
• 変更容易性の獲得には、サブセットの特性 (理解性, 複雑性, 堅牢性) を揃える必要がある
• 理解性はコードや仕様の理解のしやすさ、複雑性はコードや仕様の複雑さ、堅牢性は変更や運用に対するバグ混入のしにくさ、障害発生のしにくさ
• 変更容易性のサブセットにまで因数分解すると具体成果の特性に近づく。これらに対してアプローチすることで望む成果を作る
• ソフトウェアアーキテクチャが縦軸に存在するのは企業成長という成功に対してソフトウェアの成功の観点からブレイクダウンするイメージから
• ソフトウェアデザインが横軸に存在するのはアーキテクチャ特性に対して向き合うイメージから

性質を獲得するためのアプローチ

• 理解性を上げて、複雑性を下げて、堅牢性を持たせる
• あらゆる手段が考えられる中で主要な9つのアプローチがある
• アプローチを踏まえて具体的にやりたいこと
• 1.リファクタリングとマイグレーションを重ねて、モジュール化を推進する
• 2.規約と方針を定義し、適応度関数を用いて自律的に標準化が進む状態を実現する
• 3.モジュール開発推進と組織構造が一致し、独立して成果を追求できる状態を実現する
• アプローチは主体成果、標準/仕組み、影響に分類することができる。この分類によって、アプローチ自体が組織の考え (Value) の側面を受けていることがわかる
• 大上段の方針は中央集権的に決める。最終的な意思決定は責任と権限を持つ者が情報を整理して行う。決定の背景や根拠は全てオープンにし、説明責任を果たすことで、健全な偏りと牽制を生み、良い意思決定がなされる確率が高い状態をつくる
• 意見や提案はオープンに受け付ける。叩き台を作る人が偉い、自律駆動で動くことを推奨し賞賛する。ただし議論は公平に行う
• 言語化することにこだわる。言葉で考えを示すことを諦めない。わからない理由を言葉にする、良い理由を言葉にする、正しい理由を言葉にする。対話と議論の中で答えを見つけていく

以下は付随して考えたこと。

バンドル / アンバンドル / リバンドル

• 現在のプロダクトはバンドルプロダクトである
• 事業立ち上げに必要な機能が全てバンドリングされており、バンドリングされてあるからこそ価値が生まれているし、そうすべきだったからバンドルを意図して作られた
• バンドル化されていたから売れた、実現できた体験があった、技術的なMoatも生まれた
• 作り上げてきた中で見えてきた開発トレードオフもあった。複雑性、密結合、低凝集性
• バンドルプロダクトの延長線でも一定の成功は実現できるが、マーケットの要求に応え続けてこそ成長し続けられる。スタートアップとして進むなら成長可能性を取るのが当然の考え
• バンドル化してあるプロダクトをドメイン単位でモジュールとしてアンバンドルする
• システム観点ではモジュール化、プロダクト観点ではアンバンドル化と表現する
• アンバンドルしたからといって、バンドル時の価値を失うわけではない。バンドル価値を持ちつつ、アンバンドル後の価値を享受する。それはプロダクトの並行改善、モジュール提供、リバンドル
• モジュールとして独立できれば改善のしやすさが上がるためにプロダクトの並行改善が可能になる。モジュール単位でのプロダクト提供も可能になるはず。モジュールを組み合わせて新たなプロダクトをリバンドルとして構築することもできるかもしれない

コンパウンドスタートアップ

• 独立したプロダクトを複数立ち上げてスケールを目指すスタートアップの新潮流
• 1つのプロダクトに集中しろという定説に対する逆説
• 1.独立したプロダクトの近隣ドメインで新プロダクトを立ち上げ、連携で価値をつくる
• 2.既にあるプロダクト資産を転用する形で、異なるドメインでプロダクトをつくる
• メタ的な価値である”連携”をネットワーク効果として味方につけていく攻め方
• 技術的難易度は非常に高い(技術意思決定が非常に難しい)が、不可能な戦い方ではない
• 技術の進歩 (クラウドネイティブ, 標準化) や人材の成熟 (2~3周目の開発経験) が実現可能要因として大きい
• 事業性質が合えば飛躍する可能性が大きくある。合わせて人材の高度化がより進む