プロダクト開発における「アーキテクチャ」と「組織構造」の重要性
こんにちは。エンジニアをしています福田です。
ここ最近、すごくいい学びや経験を得られたなと感じたので、メモがわりに書いていきたいと思います。
はじめに
まえがき
起業時の反省からプログラミング学習を始めてから3年、エンジニア歴が2年を超えEM（エンジニアリングマネジメント）の領域も増えてきました。その中で、ソフトウェア業界で戦っていく際の「アーキテクチャ」と「開発組織体制」の重要性を感じるようになってきました。
今、自分が感じていることを、振り返りも兼ねて記載していければと思います。（もし読者がいればですが）拙い文章ですが、何卒よろしくお願いいたします。
前提条件
今回の自分の考え方が当てはまる場合と、当てはまらない場合があると思っています。
当てはまるのは、
という場合かなと思ってます。
逆に
- 個人開発である場合
- toCである場合
- 売り切り・受託開発である場合
- スモールビジネスである場合
は当てはまりにくいのかなと思っています。
当てはまらないケースに関しても、いつか学びを得れたタイミングで、備忘録書ければいいなと思います。
なぜ「アーキテクチャ」と「組織構造」が重要なのか
プロダクト開発の出発点
まず前提として、一般的な組織にとっての「プロダクト開発の目的」ですが、これは「組織に与える利益向上」になると考えています。なぜならば、ここでいう一般的な組織とは「営利活動を行うことを目的とした集団」であり、その集団がプロダクトを作成する目的は、営業利益を拡大することに他ならないはずだからです。
この前提を踏まえると、プロダクト開発を始める上で、最も大きな指標は「そのプロダクトのコンテキストにおける市場規模」となるとはずです。組織戦略として、ニッチなニーズを選択したり、ローカライズを行うことはあったとしても、ターゲットとする市場規模の大きさは必ず意識するはずです。
またプロダクトとは、本質的には「顧客課題を解くためのツール」になります。ソフトウェア業界に限らず、この世の全てのプロダクトは、この一点に抽象化できると思います。
つまり「プロダクト開発」とは「いかに大きな市場を選び、どのようなアプローチで顧客課題を解決していくのか」を組織として行なっていくことになり、これが、あらゆるプロダクト開発において、まず初めに考えるべき出発点となると思います。
ソフトウェア業界における、先行者優位の不確かさ
前章では
- 良い市場を選ぶことができる選定眼
- 顧客課題へのアプローチ方法
が重要な指数となると述べました。が、個人的には上記2点はそんなに重要ではないと思っています。ここまで書いていて、何を言っているんだとなる気がしますが、少なくとも個人的には、最重要ポイントだとは思っていません。
なぜならば、上記2点は「やって当たり前」のことで、かつ「その時点での成績評価」でしかないからです。
今のソフトウェア業界において、最も重要なのは
- 市場の動向に応じて、ピボットできること
- 顧客課題に対してのアプローチを、いかに早く提供できるか
だと思います。
技術進歩や顧客を取り巻く環境が劇的に変わり続けている現代では、プロダクトは、一度選ばれて終わりではなく、選び続けられる必要があり、そのために変化をし続けなければいけません。これを意識した結果が、様々な企業のSaaSへの転換のはずです。
またブルーオーシャンで規模が大きい市場などは、一過性のものでしかなく、必ず時間経過とともに、競合がひしめくレッドオーシャンとなります。ソフトウェア業界ではそれはより顕著であり、先行者優位性が働く状況は、限りなくレアとなります。
このことからも、未開拓の市場を自力で開拓する必要がある「先行者」に関しては、むしろ不利になりやすく、先行者の動向を学習した後に、開拓コスト無しで参入してくる「後発者」の方が有利になるケースが増えていると思っています。
高い不確実性に対して、何を武器にすべきか
以上のことから、 ソフトウェア業界において、利益向上を行い続ける方法、つまり他者に対してのMoat（参入障壁）を作る唯一の方法は
- （他者比較で）市場の動向に応じて、いかに柔軟にプロダクトの方向性を変えられるか
- （他者比較で）変化し続ける顧客課題に応じて、いかに早く最適なアプローチを提供できるか
になると考えています。
つまり、抽象的かつ不確実性が高い未来に対して、
- 小回りが効く組織構造
- 変化に強いアーキテクチャ
を意識し、維持・運用し続けることが、プロダクト開発の最も重要なポイントであると、自分は考えています。
「アーキテクチャ」と「組織構造」の関連性
組織構造からアーキテクチャを逆算する
ソフトウェアとしてのプロダクト開発時の、個人的アンチパターンとして「アーキテクチャから組織構造を決定する」があると思っています。既存のシステム構成や、サービス粒度,プロダクトの拡大予想図から、アサインやエンジニア採用をおこなったりする方法ですが、これは個人的にはアンチパターンだと考えています。
なぜならば、
- プロダクト開発には、特定のゴールはなく、ゴール自体が変わり続ける。
- プロダクトのアウトプットであるプログラムは、人が作成している。つまりプロダクト開発スピードを向上させるには、純粋に人が増えなければいけないフェーズがくる。
- 人がマイクロマネジメントできる人数は限界がある。かつ、人間が把握し管理し続けられるコードベースの量も限界がある。
- アーキテクチャとは、責任領域を分けることであり、組織構造によって最適解は変わっていく。
と思っているからです。
これを意識せずに、アーキテクチャから逆算して組織作りをすると、
- 把握すべきコードベースが異常に大きくなりすぎたり、小さくなりすぎる
- チームメンバーが多くなりすぎたり、少なくなりすぎる
などと言った状況が発生してしまいます。
プロダクトとはあくまで「その時点での価値提供手段」であり、生存戦略としてより重視すべきなのは「明日以降に、より良いアプローチを提供し続けられるかどうか」のはずです、つまり、アーキテクチャから逆算しる考え方では、本来目指すべき高いスループットを出せる組織（肌感も含みますが、大体1チーム5〜7人まで）を維持することができなくなってしまいます。
まとめると、
- 1チーム5〜7人を上限とした上で、それが複数連携する組織とする。
- 各チームごとにマイクロサービスを持ち、マイクロサービス毎の連携は、インターフェースを経由して行われる。
- 各チームは担当マイクロサービスに対して、インターフェースを担保する責任を持つが、内部の実装に関しては各チームに一任する。
- 特定のマイクロサービスに関して、責任領域が増えていった場合には、インターフェースを担保したまま、内部的に分割をする。（マイクロサービスを更にマイクロサービス化する）
という順番で組織構成〜アーキテクチャを選択していくべきだと思います。
具体的には、下記のような兆候が出ている場合は、アーキテクチャを見直し、マイクロサービス化を行うべきだと思います。
- 同一のコードを管理しているメンバーが8人以上になっている。
- 新メンバーへのオンボーディングに時間がかかりすぎている。
- テストケースが非常に多く、時間がかかりすぎている。
立ち上げ直後も、リリースの早さではなく、改善の速さを意識する
立ち上げ直後のプロダクトの場合、開発者が1人や数人の場合がほとんどだと思います。その際「まだまだ人数が少ないので、スピードを最優先しアーキテクチャは意識しない」というのもアンチパターンだと思っています。
なぜなら、そもそも仮説検証に関しては、
- 多くの顧客にヒアリングを行う
- モックを作成し、顧客がお金を払ってくれるかどうか検証する
など、コーディングを行う前に実施できることが無数にあり、コーディングをする時には「PMFさせるまで改善し続ける覚悟と、それを実行できる組織とアーキテクチャ」を意識する必要性があると思っているからです。
もちろんMVPを完成させるスピードも重要だと思います。が、スピードまでの早さを意識するのであれば、むしろコーディング着手前の施策をより深く実施する方が、総じて早くなると思うので、やはりコーディング着手時にはアーキテクチャはかなり意識すべきだと思います。
常に「この機能を将来的に捨てられるのか」を意識して実装する
立ち上げ初期〜PMFまでで、特に意識すべきこととして「今日実装した機能は、明日不要になるかも」という部分だと思っています。
スタートアップの初期フェーズでは、リソースが限られているため、より多くの顧客が抱えているより汎用的かつ抽象的な課題のみに的を絞る必要があります。ですので組織全体として「無ければいけない」本当に必要な機能のみを実装し「あったらいいかも」といったToMuchな機能は実装しないことが求められます。
しかし、現実的には、実装前に全てを検証しきることは難しく「やっぱりいらなかったな」という機能が散見される場合が、数多くあると思います。
この「やっぱりいらなかったな」という機能を捨てられるようにしておくことが、立ち上げ直後〜PMFまでのアーキテクチャとして、特に意識すべき部分だと思っています。ニーズが少ないにもかかわらず、一部のユーザーのためにメンテナンスをし続けなければならないコストを、いかにローコストで削除できるかどうかは、プロダクトの推進力を失わないための、非常に重要なポイントだと思います。
これはコードや設計レベルでもそうですが、契約や規約レベルでも意識すべきなので、立ち上げ初期に注視することが、後々の動きやすさに関わってくると思っています。
具体例でいくと
- 新規機能は必ずβ版とし、廃止決定を自社内のみで意思決定できるようにしておく
- 既存のDBテーブルには、β版側へのリレーション情報を極力持たせないようにする。（β版に非依存な形を保つ）
- DRY原則を無視してでも、β版機能に関わるコードは、既存コードと切り離す
などがあるかと思っています。
どこまで逆算する必要があるのか
マイクロサービスを始めるタイミング
「アーキテクチャ」と「組織構造」に
