【2020年】コロナ：アーキテクチャ価値の発見

教育を通して未来を進化させるEdtechスタートアップ

鵜飼：atama plus株式会社のリードソフトウェアアーキテクトとして、プロダクト全体のアーキテクチャ戦略策定や設計に従事している鵜飼一平と申します。

atama plusは「教育に、人に、社会に、次の可能性を。」をミッションに掲げているEdtechスタートアップです。学習を個別最適化するAI教材「atama＋」を全国で4,000以上の塾に提供しています。

本日は「アーキテクトの誕生とこれから ー スタートアップ7年の成長と痛み」と題して、atama plusの歴史を振り返ります。

変化のきっかけはコロナ禍

鵜飼：まずは、2020年からお話しします。当時の「atama＋」は、iPadやAndroidのアプリを塾のタブレットにインストールしていただいて学習を提供するサービスでした。しかし、2020年1月からのコロナ禍を機に、塾や予備校での学習が難しくなるかもしれない、という説が浮上しました。もしそれが現実になれば、サービスを提供できなくなります。

解決策として社内で話し合ったところ「自宅学習に対応する」という案が出ました。そこから開発に着手して、発案から1週間後の2020年2月25日にWeb版サービスの臨時提供を開始することができました。

なぜ、このようなスピード感でWeb版を開発することができたのか。

創業時の技術選定を振り返ると、スタートアップでネイティブアプリを開発するのは大変だろうという考えから、CordovaとIonicを組み合わせていました。Cordovaとは、Webの技術でネイティブアプリが作れるものです。ネイティブアプリとして配信し、WebView内でSPAが動きます。IonicはネイティブアプリのUIを再現してくれるものです。 「atama＋」の中身がSPAで、S3に上げてCloudFrontを立ててドメインを割り当てればWeb版が動かせるという状況だったため、発案から1週間というスピード感を実現できたのです。エンジニアとしてはスマホサイズの対応が大変だったくらいで、塾の皆様や弊社のビジネスチームの対応力がすごかったと記憶しています。

結果として、緊急事態宣言が出たのが4月7日で、その時点ではWeb版を500教室で既に導入いただいておりました。社会の変化に対応できたことが、会社を大きく成長させる一つのきっかけになったのではないかと考えています。

2020年の学び「アーキテクチャには価値がある」

鵜飼：「どうしたら塾のタブレットで使うアプリを明日から生徒が自宅のPCで使えるようにできるのか？」という問いの答え合わせは「変化に適応するにはまだ見ぬ将来の問いに答えておく必要がある」です。

アーキテクチャとは未知の問いに答えておけるものであり、3年目のスタートアップが突然の変化に対応できたのは、アーキテクチャのおかげです。2020年は、アーキテクチャにはとても価値があるのだと学びました。

【2021年】プロダクト多角化：アーキテクチャに向き合う

別プロダクト開発を機にアーキテクチャの課題を発見

鵜飼：2021年に突入して「atama＋」とは別の学習プロダクトを作りたいというアイデアが出ました。プロダクトが違えば「ユーザーモデル」や「カリキュラム」などの仕様は異なります。しかし「学習」の技術資産（コンテンツ、アルゴリズム、学習画面、学習データ）はコアな価値として共通で使用したいという話になったのです。

そこで、まずは「atama＋」の学習体験を切り出しました。

鵜飼：サーバー側については、モジュールをレイヤー状に管理していて依存の方向が一方向に揃った状態で管理していたため、学習コア層のモジュールを再利用できました。

鵜飼：一方でフロントエンドでは、アプリはプレゼンテーション層として割り切っていて、ユーザーモデルや認証機能が密結合していました。

そのまま使うのは難しく、いったんフォークして作ったのですが、泥団子とまでは言わずとも団子のような状態でした。

別プロダクトと共通で使えないということは、変化に適応できないとも言えます。「これはやばい」と思い、代表との1on1でアーキテクチャを改善したいと相談した結果、学習基盤構築タスクフォースを組むことになりました。

タスクフォースのゴールは、会社のコア資産である学習機能をいろいろなプロダクトから使えるようにすることです。

ゴールに向けて最初に取り組んだのは、学習基盤を括り出す作業です。まずは学習機能を分離分割してライブラリとしてパッケージ化。そして、フォークして作った別プロダクトの一部をサンプルとして取り込み、学習基盤だけで別プロダクトが作れる状態を担保しました。

鵜飼：大規模なリファクタやリアーキテクティングを行ったことで、保守性が上がるといった副次効果もありました。

2021年の学び「答え合わせから学ぶことが大事」

鵜飼：「既存の技術資産を生かして別の学習プロダクトを作れるか？」という問いの答え合わせは「選択肢を残すことが、将来の可能性を拡げる。ソフトウェアの構造を整えなければ、技術資産の価値は目減りする」です。

2020年にアーキテクチャの価値を学んでいたからこそ、私たちはソフトウェアの構造が抱えるリスクに気がつくことができました。2021年はソフトウェアの構造と向き合って多くの知識と経験が得られましたし、答え合わせから学ぶことが一番大事だと実感した1年でした。

【2022年】継続改善：人・チームに向き合う

Kibanチーム誕生とともに新たな課題も発生

鵜飼：2022年はアーキテクチャを継続的に改善することを目的として、学習基盤を再利用可能にするために集まったタスクフォースのメンバーをKibanチームとしました。Kibanチームのミッションは「ソフトウェア構造を見直す技術資産を構築する」です。

ただ、しばらくしてから他の開発チームの関係性が課題となりました。

鵜飼：このような状態を解決するには、Kibanチームの存在意義を理解してもらわなくてはいけません。そこで、Kibanチームのチームミッションを考え直すことにしました。

チームで話し合い、出てきたのが「設計のスペシャリスト集団」「ソフトウェア構造の進化をリード」「各開発チームの活動をサポート」といったワードです。

これらのワードを見て「ソフトウェアだけではなくソフトウェアを作る人とも向き合う必要がある」と気がつくことができました。

それをきっかけに、チームとして二つのアプローチを取りました。一つ目は「気軽にコード相談タイム」です。

鵜飼：弊社はチームがたくさんありますので、チームをまたいで相談しやすいように、相談できる時間を週次で確保しました。それにより、設計相談はもちろん、方針の相談やセカンドオピニオン的にコードレビューして欲しいという依頼が来るようになりました。

もう一つは「Clean Architectureワークショップ」です。迷ったときに立ち返れるような共通の価値観を醸成し、ソフトウェア設計の意味を各自が理解して考えられるようにすることが目的でした。

鵜飼：二つのアプローチを通して「Kibanチーム＝設計のスペシャリスト」と認識されるようになり、他のメンバーからの相談を受けたり、設計を一緒に考えられるようになったのは大きな成果だったと思います。

2022年の学び「アーキテクチャを作る中心はアーキテクト」

鵜飼：この問いに対する答え合わせは「ソフトウェアの構造と向き合ったエンジニアリングのチームが『ソフトウェア設計のスペシャリスト集団』を自負するチームになった」です。人と向き合うことで、『アーキテクト』の前身となる組織ができました。

他のエンジニアを巻き込み、みんなでアーキテクチャを作る。その中心になるのがアーキテクトである、と学びました。

【2023年】事業多角化：組織構造に向き合う

複数事業をどのように成長させるのか？

鵜飼：2023年より、直営のオンライン塾から「atama＋」を届けるといったこともしています。

オンライン塾を立ち上げると決まった時、「複数事業をどのように成長させるのか？」という課題がありました。経営側からは「迅速な意思決定ができるように事業部制にしてはどうか？」という案が出たのですが、検証段階でプロダクト側は限界がきていたのも事実でした。

鵜飼：そもそも、一つのプロダクトを複数の事業に展開するとなると、新規事業と既存事業のニーズがコンフリクトします。B2B事業においては、顧客にオペレーションの変更をお願いする必要もありますし、調整が大変です。加えて、職種に関係なく考えることが増えてしまうため、全員の認知負荷が高い状態になってしまうのも課題でした。

とはいえ、新規事業を早く進めたい。ということで、ソフトウェア設計のスペシャリストであるKibanチームに「複数事業のプロダクトを複数の組織で作る場合、プロダクトはどんな設計だったり構造にすれば良いか？」「どうしたら複数の開発チームでうまく分担できるか？」といった相談が来ました。

ソフトウェアと開発組織の構造を一緒に設計する必要があると考え、いろいろと探して見つけたのが『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』です。 これはまさに私たちが求めていた解だと思い、チームトポロジーに沿って四つの作戦を立てました。

作戦①「バリューストリームに沿った組織」

鵜飼：チームトポロジーにはストリームアラインドチームという、価値を届ける仕事の流れに沿って働くチームが存在します。流れの中で他のチームに仕事を引き継がないのが特徴です。

弊社でいうと、二つの事業はそれぞれバリューストリームに当たります。塾向けのストリームとオンライン塾のストリーム、それぞれの価値をそれぞれの顧客に届けようと。

そこで一つ課題となったのが、学習については共通のコアバリューであったことです。

鵜飼：いろいろと考えた結果、学習体験も価値を届ける一つのバリューストリームとして、上図のような3本のストリームを想定することにしました。

作戦②「所有をベースにしたプロセス運用」

鵜飼：チームトポロジーには「ソフトウェアシステムのすべてのパーツのオーナーは単一のチームである必要がある。」という一文があります。オーナーシップがあることでドメインや実装の知見がたまっていきますし、コミュニケーションが明確になります。

そこには「所有していないコードは勝手に実装を変更しない」「他チームから利用されているコードは仕様を勝手に変更しない」といった所有の原則があります。

鵜飼：弊社の場合は、バリューストリームに沿った組織×3、プラットフォームを見る組織×1という形で振り分けて所有することとしました。

所有については、全部を全員で見るのをやめるという作戦を取りました。一見プロセスが煩雑になって手間が増えそうですが、認知負荷を下げつつ、本来必要なインタラクションを促すという目的がありました。

作戦③「プロダクトを分離」

鵜飼：この作戦では、事業ごとにアプリを作成することにしました。具体的には、最初に枠だけを複製して、だんだん仕様が分岐する形を取りました。機能群についてはもともとあったものを利用して、カスタマイズを入れていく。カスタマイズ部分については、各事業で所有するという形です。

鵜飼：既存の機能群は既存事業のチームで保有するため、新規事業はそのまま利用するか、コピーして所有することが可能です。もしくは外からカスタマイズできるように変更させてもらうこともできます。弊社の場合は、カスタマイズできるように依頼するパターンが多かったと記憶しています。

作戦④「依存の方向をルール化」

鵜飼：最後は依存の方向をルール化しました。コードも組織も依存を一方向にすることで、循環依存を作らないようにする。表層から深層に依存する形に統一して、変化しやすいものから変化しにくいものに依存すると定めました。

鵜飼：新規事業は一番変化が激しいため、一番表層に位置づけられます。そうすると新規事業は他から依存されないため一番身軽ですし、既存事業は新規事業の変化に振り回されることがなくなります。一番コアな部分が重要な価値だということで、学習体験は深層に置いています。

コンウェイの法則を絡めて振り返る

鵜飼：四つの作戦について、コンウェイの法則を絡めて振り返ってみます。

前提として、我々はソフトウェアアーキテクトであるため、ソフトウェアの構造をアーキテクチャと呼んでいます。

鵜飼：ソフトウェアの構造（アーキテクチャ）は、事業の構造や開発組織の構造、コミュニケーション構造など、さまざまな構造に囲まれています。

コンウェイの法則によると、開発組織のコミュニケーション構造にソフトウェアの構造が一致すると言われています。つまりは、開発組織やコミュニケーションの構造によって、ソフトウェア構造が制限されてしまうと。

反対に、望むソフトウェア構造に組織構造を合わせる逆コンウェイ作戦と言われるものがあり、それに事業の構造を絡めて、事業、アーキテクチャ、プロセス、組織の順番に進めるBAPOモデル（Jan Bosch）というものもあります。

弊社では、それらを参考にしつつ、すべての構造をなるべく一致させることで認知負荷を減らすことを目標にしました。そのために行ったのが、先ほどご紹介した四つの作戦です。

鵜飼：具体的には、作戦①で事業構造に組織構造を合わせた上で、逆コンウェイに近い発想で学習体験を一つのバリューストリームにしました。

作戦②で所有をベースにしたプロセス運用でミュニケーション構造に反映させ、作戦③で事業構造に合わせたソフトウェア構造にしました。

最後に、作戦④でソフトウェアの構造を維持するためのルールをコミュニケーションに組み込みました。

コンウェイの法則で言われているように、ソフトウェアの構造にはさまざまな力学が働きます。そこに反対の力学を織り交ぜながら、すべての構造をうまく一致させるために、四つの作戦を実行したというわけです。

その結果、プロダクト×2、ストリーム×3の体制が出来上がりました。

鵜飼：各ストリームがそれぞれにプロダクト（アプリ）もしくは学習基盤を持ち、二つの事業に貢献しています。

この体制により、オンライン塾（新規事業）は新しい機能を大胆に追加できるようになりました。塾向け既存事業はオンライン塾からの影響を最小限にとどめながら顧客価値の最大化を図れますし、一体感を持った組織で「学習体験」というコアバリューを育てられるようになりました。これらを通して、事業構造の大きな変化に対応できたのではないかと考えています。

2023年の学び「ソフトウェア構造を考える＝アーキテクトにしかできない仕事」

鵜飼：この問いの答え合わせは二つあり、一つが「事業、組織、プロダクト、ソフトウェアの構造は連動する」です。二つ目は「ソフトウェア構造と向き合っても、ソフトウェアを開発するチームと向き合っても、それだけでは変化に適応できない」ということ。

ソフトウェア構造は、組織全体の構造の一つに過ぎませんし、エンジニアリングの枠を超えて、組織全体と一緒に考えていく必要があります。これこそ、アーキテクトにしかできない仕事だということを学びました。

学び、成長し続ける

鵜飼：atama plusの2020～2023年を振り返ってきました。

鵜飼：コロナ禍ではアーキテクチャの価値を実感できましたし、プロダクトの多角化に挑戦した2021年には、ソフトウェア構造を必死に改善したおかげで、さまざまな知識・経験を得られました。その次の2022年には設計のスペシャリストを自負するようになり、みんなでアーキテクチャを作ることができました。それらを経て、2023年には事業の変化と向き合い、アーキテクトの責任を実感できました。

私個人としてはエンジニアとして16年やってきたのですが、実は2024年10月からアーキテクトが主務になりました。16年目のジョブチェンジです。

これからどのような問いが来るのかはわかりませんし、アーキテクチャの答え合わせは、必ず後から来ます。だからこそ、「今」と「未来」に向き合い、来るべく問いに答え続ける必要があります。

アーキテクトもアーキテクチャも、スタートアップも、その時々のベストな解を出し続けて、答え合わせから学んでいく必要があるのだと思いました。

「アーキテクトも、アーキテクチャも、スタートアップも、学び、成長し続ける」ということで、本日の締めとさせていただきます。本日はご清聴ありがとうございました。