エンタープライズプラットフォームの開発には何が必要なのか?
この記事は10Xアドベントカレンダー2023の23日目の記事になります。
昨日は坂本さん(@kazu0620)による、もし過去に帰れるならもっと早く導入したかった開発の取り組みでした。
はじめに
こんにちは、10Xでエンジニアリング本部の本部長を努めているkosako(@aki85135)です。
まもなく10Xに入社してから一年が経とうとしていますが、最近改めてエンタープライズ領域の難しさとともにプラットフォームを作ることの難しさを実感しております。
最近では面接等で事業の面白さだけではなく難しさやそもそもなぜ難しいのかといったお話をさせていただく機会も多く、改めて言語化を試みてみたものをまとめてみることにしました。
エンタープライズ・プラットフォーム
10Xが提供しているStailerはネットスーパーのためのプラットフォームですが、利益構造や立ち上げ、運営に相応のコストがかかることから現在は規模の大きいエンタープライズのパートナー様が中心となっています。
エンタープライズ・プラットフォームという定義については、CEOであるyamottyの記事を参照してください。
ここでエンタープライズとプラットフォームの特性をシステム面・開発面から考えてみます。
エンタープライズの特性
エンタープライズは、その巨大さと複雑さから多くの特有の特性を持っていると言えます。
顧客も組織も非常に巨大なため、ステークホルダーが多いだけでなく多様でもあります。これは意思決定を複雑にすることになり、その難しさに直結します。
既存の様々な資産があり、まるっと任せたり、入れ替えたりすることの難易度が高くなります。
既存のシステムや仕組みがある場合、これを変更するにはシステムだけではなくオペレーションを含めて影響範囲が広くなることもあり個別の要求がどうしても多くなり対応する必要性が出てきます。
多くのSaasでは成長の鍵としてエンプラ攻略を掲げていますが、システム的にはここに大きなギャップが出ることは想像に難くありません。
プラットフォームの特性
プラットフォームをシステム面から見たときにどのような特性があるのかを考えてみます。
よくあるのがプラットフォームの上に色々乗せられることで、AppStoreやAWSといったプラットフォームの上にアプリやサービスを展開するイメージがあります。
しかしよく考えると、上に何かを乗せられるだけでは不十分ではないでしょうか?
上に乗せるということは、乗せられるものに対して制約を与えることになります。その制約次第で表現できるもの、作れるものの範囲が決まるわけですがそもそも好き好んで制約を受け入れる人はいません。基本的に制約とは渋々受け入れることが多いものです。
つまりプラットフォームに乗っかってもらい、制約を受け入れてもらうためにはそれ以上の多大なメリットが存在する必要があるのです。
実際単一でそのように振る舞えているプラットフォームは少なく、実際にはプラットフォーム同士が絡み合ってシステムやサービスが出来上がっていることのほうが多いのではないでしょうか。
性質の異なるプラットフォーム同士が絡み合い相互補完することでお互いのビジネスも補完し合う関係になれることが重要ではないかと思います。
必要なシステム特性
エンタープライズの特性とプラットフォームの特性を兼ね備えたシステムを構築しようとした場合その開発は非常に難易度が高くなります。
エンタープライズの規模と要求の高さをクリアしつつ、プラットフォームとしての拡張性、柔軟性、カスタマイズ容易性を両立させる必要があります。
両立させるためには個別の要求に応えつつ、コストも抑えながらスピードも上げていく必要が出てきます(だいぶ無茶なことを言ってますが)。
両立させようとした場合、ユーザーニーズに単純に応えることは出来ません。こういった機能がほしいといったニーズに応え続けると機能は個別化し、汎用性が低くなりシステム全体の保守性が下がっていくことになります。
この問題を解決するためには、十分に抽象化された小さなプロダクト郡(機能郡)が必要になってきます。
これは巨大なモノリシックなシステムではなく、小さく有機的に連携するシステムとなることを意味します。
小さくシンプルなシステムを組み合わせて一つのシステムにすることで、外部のシステムとも連携しやすくなるはずです。
開発組織の考察
小さく十分に抽象化されたシンプルなシステムを組み合わせて一つのシステムにする。というのは言葉にするのは簡単ですが、非常に難易度が高いです。
十分に抽象化という部分も肝で、抽象化しすぎると自由度が高すぎて逆に使いにくく効率の悪い仕組みになってしまう可能性もあります。しかも、十分な抽象化のレベルは事業の状況によって変動するのです。
したがって最初から正解があるわけでもなく、ある時点での正解が正解であり続ける保証もないのです。
そのようなエンタープライズ・プラットフォームを開発運用するためにはどのような開発組織、戦略が必要になるのでしょうか?
そもそもプラットフォームは長期的なものです。
自分たちだけの都合でサービスの仕様を変更したり、終了させたりすることが難しいものになります。
サービスの種類によってある程度の違いはあるのでしょうが、10年20年といったタイムスパンで考える必要があります。動いているだけならなんとかなるでしょうが、セキュリティや連携しているサービスへの対応も含めてとなるとそう簡単ではありません。
コンウェイの法則では、組織がシステム開発を行う際、その組織のコミュニケーション構造と同じ構造の設計を行ってしまうとなっています。
ここから作りたいシステムにあった組織の構造にすればよいというのが逆コンウェイの法則です。
したがって、エンタープライズ・プラットフォームを開発するにはドメインを深く理解した小さなチームが長期に渡ってコミットしなければ難しいであろうと考えられます。
そして、その小さなチームには理解したドメインを十分に抽象化するだけの能力が必要で、そのようなチームが複数いなければいけません。
このような背景もあり、10Xでは今年4月に ドメインベースの開発体制への移行 を行っています。
終わりに
10Xが挑んでいるエンタープライズ・プラットフォームという領域は非常に複雑でまだまだ正解は見えていません。
特定の技術や機能によって一気に攻略できるものではなく、地道にビジネス、ソフトウェア、組織を改善していくことで漸進的に進めるしかありません。
ですが、正しくソフトウェアを作ることが複利的に大きな価値を生み出せる希少な機会であり、この課題に対して正面から取り組めていることは非常に楽しいし面白いと感じています。
10Xではメンバーを募集しています！採用ページもぜひご覧ください。 明日はエンジニアの石田さん(@wapa5pow)が記事を公開する予定です。お楽しみに！
この記事が気に入ったらサポートをしてみませんか？