事業の形に介在し、価値提供を最速化するアーキテクチャチームの野望

はじめに

前前回のブログの後編を書かずに野望記事を書いている、アーキテクチャチームの野呂です。

この流れで、アーキテクチャチームの、というよりは僕の野望について語らせていただきたいと思います。

アーキテクチャチームの野望

ニーリーの開発組織のテーマは「価値を最速で実現する」だと思っています。それは、ニーリーのミッションである「社会の解像度を上げる」と、Valuesである「今、“いいもの”を作る」を体現し、T2D3を超えるハイグロースを実現するのに必要だからです。
T2D3を超える、というのは決して夢物語ではなく、今まさに、それを超えるスピードで事業は成長しています。

そのため、僕の野望はそのまま「価値を最速で実現できるアーキテクチャを作り、維持し続けること」です。

野望と呼ぶには地味に聞こえますが実態は非常に難しく、ほとんど「この世界のすべての答えを知る」と同義な、やや現実離れした内容だと自分自身は思っています。
しかし野望と呼ぶからにはなんとかして実現したい。

ここからは、何がそんなに難しいのか、そしてチームとしてそれをどのように実現しようとしているのかを書いていきたいと思います。

価値を最速で実現できるアーキテクチャとは？

価値を最速で実現できるアーキテクチャとは何なのか？ちゃんと考えようとすると何か1つ正解のある問いではないことがすぐにわかります。

価値の定義と最速の定義は「携わる人数」「事業の狙いや目的」「期待されるプロダクトの生存期間」「利益の期待値」「組織のフェーズ」などありとあらゆる現実世界の事情に左右されます。

つまりそれは可能な限りのトレードオフを考慮した結果、狙った期間でもっともプロダクトの価値が高くなることが期待されるアーキテクチャというようなニュアンスを含んでいることになります。

正確にその意味を考えるためには「可能な限りのトレードオフ」や「狙った期間」について具体的に考えていく必要がありそうです。

狙った期間と狙える期間

「期間」もトレードオフの一種ですが、その他の条件に比べてそれ自体が他のトレードオフの影響を大きく受けます。

たとえば、それが最初のプロダクトで、会社のキャッシュフローに余裕がない状態である場合、その期間を10年に設定することはできません。5年も普通は難しいでしょう。頑張って3年、現実的には1年くらいが限界ではないでしょうか。

「1年で価値が最大化する」を条件に考えると、少なくともその半分の期間で何かしら動くものが世に出ている必要がありそうです。そうなってくると、もう選択の余地はあまりありません。その時参加しているメンバーが一番慣れた方法で、一番お金がかからない方法でやるだけです。

もちろん先に実現方法を決めておいて、それが可能なメンバーを集めることもできますが、その意思決定は普通その実現方法を決めたメンバーが一番慣れた方法だということになるでしょう。

例えばニーリーでは、パークダイレクトを世に出す際に、オフショアでの開発を選択しました。
その際、その会社が最も得意とする言語、フレームワークを使って「最速」で作ってもらえるように依頼しています。結果として今日本ではあまり一般的でない技術スタックで開発されたものになりましたが、この場合はそれで正解だと考えています。

しかしこれが、ある程度収益を上げている既存プロダクトの機能やそれ自体の刷新になると話が大きく変わってきます。価値が最大化される期間が半年や1年では困るでしょうし、メンバーもたくさん参画していることが予想されます。

仮にその期間を5年としましょう。そのプロダクト自体はもう価値を生み出しているので、それが完成するまでの期間よりも、その5年のあいだ問題が起きにくいことが期待されるでしょう。

この「問題が起きない」には「スケーラビリティ」や「不具合の少なさ」「拡張が素早くできる」などが含まれています。

例えば、パークダイレクトは今、マーケットにほぼフィットしたといっていいフェーズに入っています。このプロダクトが、後1年や2年で消えてなくなることはないと断言できる段階です。

そこで、この先5年〜10年を見据えて、アーキテクチャの見直しと改修を行なっています。それは「少人数での超高速開発」ではなく「ある程度の人数が安定して開発」するための改修です。その辺りのお話はこちらのスライドに詳しいので、興味を持っていただけた方は是非ご一読ください。

こんなふうに、単純に「期間」だけを比較しようにも、その他の多くの事情がまとわりついてきます。

できる限りのトレードオフ

では、期間以外のトレードオフについて考えてみます。

何人くらい開発に参加するのか？
何チームくらい組織できるのか？
どのくらいのパフォーマンスが期待されるか？
どのくらいの回数機能追加が見込まれるか？
どのくらい複雑になることが想定されるか？
どのくらいのデータの整合性が求められるか？

基本的に要求が高くなるほど重厚で抽象的なアーキテクチャになっていきます。
逆に要求が低ければナイーブな実装でもその期間を耐え切ることができるでしょう。

ここで大切なのは「わからないことに備えすぎない」ことだと思っています。
僕の好きなジョークリポジトリに「Fizz BuzzEnterpriseEdition」というのがあり、これはFizzBuzzを重厚長大なエンタープライズ向けのアーキテクチャで大まじめに実装しています。まだわかってもいない変化や複雑さに過度に備えるとこういうことになってしまいます。

しかし、当然ですがわかっていることが多ければ、その分適切に備えることができます。

「わかっていることが多い」とは、どういう状態なのか？

まず、未来予知はできません。
そもそも、未来は選択によって分岐するので、たとえ精度100%の未来予知ができても問題は解決しません。

それ以前に、実際には「本来ならその時点でわかっていること」も我々は多くの場合わかっておらず、その上「わかっていないことすらわかっていない」状態であることがほとんどです。

そのため、常に「何がわかっていないか」を把握しようとし続け、そしてそれを分かるためのアクションを起こし続ける必要があります。

わかりやすい例として最初に期間のお話をしましたが、「どうして」その期間で開発する必要があるのかは、自分で知ろうとしない限りは「要求」や「要件」として勝手に降ってくることはあまりないでしょう。

また、開発者が考える「今後の展開」と経営層が考える「今後の展開」が奇跡的に一致することも、「開発者が考える利用者のペイン」と「実際の利用者のペイン」が運命的に同じであることも、普通はあまりないと思っています。

僕がこの手の難しさと対峙するとき、いつも「開放/閉鎖原則」を連想します。

ソフトウェア要素（クラス、モジュール、関数など）は、拡張に対しては開いており、修正に対しては閉じているべきである（wikipediaより）

ご存じの通りSOLID原則のうちの一つのシンプルな原則ですが、裏表のように2つの顔があります。

この原則が守られているかどうかで拡張性が大きく変わる
この原則を厳密に守るためには、今後どのように拡張され、どのように修正されるかを知っている必要がある

そのためにも、少しでもたくさんのことを「わかっている」状態にする必要があります。では、どうすれば「わかっている」と言えるのでしょうか？

どのように実現しようとしているか

ここまで、地味で当たり前のように見える野望の何が難しいのかについて書いてきました。

ソフトウェアのアーキテクチャについて考えることは、それ自体が直接価値を生み出す営みではありません。しかし、価値を生み出すタイミングや価値を生み出すスピード、事業としての選択肢の増減に関わる重要なファクターです。

ここまで主張してきたように、何か1つ正解のある問いではありません。しかし、正解に近づくための方法は1つだけだと思っています。

それは「事業全体の状況や目指す場所を把握し続ける」ことです。それこそが、すなわち「わかっていることを増やす」と同義だと考えます。

特に、マルチプロダクトが進みそれぞれのプロダクト同士がシナジーを持つこれからのニーリーは、プロダクトが局所最適に陥らないようにアーキテクチャで工夫する必要があります。そのためにも、アーキテクチャチームは、全てのプロダクトの事業構造と、その事業構造がソフトウェアに要求すること、今後それらの事業がどのように変化しようとしているか、そして実際のソフトウェアの構造を把握し続ける必要があります。
具体的に、今アーキテクチャチームで取り組んでいることを、事業の状況と絡めながら紹介したいと思います。

実際に取り組んでいること

顧客基盤

プラットフォーム開発チームの野望でも触れられていますが、今ニーリーではマルチプロダクト化が凄まじい勢いで進んでいます。

そのため、これまでは1つのサービスの中でしか使われていなかった「顧客」という概念を、複数のサービスから参照できるようにする必要があります。

最初は「顧客なんて大体形決まってるし、ドメインロジックみたいなものも少なそうだし、単純にCRUD作って終わりじゃない？」くらいに考えていたのですが、実際作り始めてみるとやはり以下のような問題がたくさん出てきました。少し例を挙げます。

一般的には顧客の情報として含むべきではないが、顧客に付随して参照できることが求められ、今見えている全てのサービスで利用されることがわかっている項目を保持するべきか、別サービスを立てるべきか
「すでにローンチされているサービスA」と「構想段階のサービスC」では確実に利用するが、「すでにローンチされているサービスB」では絶対に利用しないことがわかっている情報を含めるべきか

これらは要するに、以下のような問題です。

無限の工数と時間があれば理想的な答えがあるが、実際には工数と時間は有限
どこまでの妥協がもっともペインとスピードのバランスがよくなるか
（無限に考えられ続けてしまうので）どこで考えるのをやめるか

チームでは、以下のようにバランスを取ろうとしています。

理想的な形にできる余地（＝変更可能性）を作っておくが、最初から理想は目指さない
後戻りができない問題を潰したら、後はひたすら走る

「後戻りができない問題」や「理想的な形」は「今見えている範囲で」であることに注意が必要で、「わかっていること」が減るとその分視界も減ります。視界が狭くなると、同じだけの時間をかけてもアウトプットが悪くなります。例えば、1でサービスCの構想を知らなければ考慮することすらできなくなります。ゾッとしますね。