多くのプロダクト関連の文章は、最良の教訓は規模、資金、そして十分なリソースを持つチームから得られるものだと前提としている。

私はそうは思わない。

私が得てきた、最も実用的なプロダクトの教訓のいくつかは、失敗の余地がほとんどない環境で構築する中で得たものだった。限られた予算。動く締切。至るところにある手作業。そして、順序を誤るとすぐに結果が表れる状況。

それが、私がナイジェリアの大学管理プラットフォームに関わっていた環境だった。

そこでは、優先順位を一つ落とすだけで四半期が少し弱くなる、あるいは機能の提供が遅れる、といった話ではなかった。入学対応が時間内に処理されなければ、学生は席を失う可能性があった。授業料の回収が適切に設計されていなければ、収益は抜け落ちた。レポーティングを後から付け足せば、経営層は部分的な可視性しかない状態で意思決定を迫られた。

そしてCOVIDが対面運営を混乱させたとき、本当の試験はプラットフォームが洗練されているかどうかではなかった。機関を維持できるよう、十分に速く拡張できるかどうかだった。

その経験から、CAPEモデルが生まれた。Crisis-first prioritisation（危機優先の優先順位付け）、Architecture as incentive（インセンティブとしてのアーキテクチャ）、Parallel data infrastructure（並行したデータ基盤）、Extensibility by design（設計による拡張性）である。

これは万能の方法でも、完璧な公式でもない。CAPEは、圧力下で働くチームにとって、完璧な計画を持つことよりも、正しい順序で意思決定することのほうが重要だという現実的なアプローチだ。

C – 危機優先の優先順位付け

多くのチームは、価値と工数に基づいて優先順位をつけていると主張する。それはある程度までは有効だ。しかし、未解決の失敗が一つあるだけで他のすべてが無意味になる場合、そのロジックは崩れ始める。

それが入学対応の現実だった。

当時、新入生のオンボーディングはほとんど手作業だった。学生は紙の申請書、点在する確認作業、そしてほぼすべての段階で職員の支援を通じて入学・登録を進めなければならなかった。遠方から来る学生もおり、多くが厳しい締切に直面していた。システムがその負荷に耐えられなければ、学生は取り残される。だからオンボーディングが最初だった。

それはプラットフォームで最も革新的だったからではない。ロードマップ上で最も見栄えがよかったからでもない。最大の失敗点だったからだ。そのプロセスが壊れれば、残りのプラットフォームは意味をなさなかった。

これがCAPEの第一原則だ。最大の機会から始めてはいけない。すぐに直さなければ最も大きな損害を生む失敗から始めるべきだ。

言うのは簡単だ。だが、実際にその場にいると、簡単には感じられない。特に利害関係者の要求が分散しているとき、チームは目に見える複数のニーズに努力を分けたくなるものだ。しかし制約下では、注意を分散することが、回避の言い換えになり得る。見た目はバランスが取れているように見えるが、通常は提供力を弱める。

制約は、より不快な問いを突きつけた。最初に一つだけをきちんと解決するなら、それは何であるべきか。

その問いは、より十分に資金がある環境でも依然として重要だ。それに誠実に答えるチームほど、より強い最初のリリースを作る傾向がある。そうでないチームは、しばしばロードマップが広がり、土台が弱い状態に陥る。

最初のリリースが最もコストの高い失敗を安定化できないなら、それはおそらく間違った最初のリリースだ。

A – インセンティブとしてのアーキテクチャ

大学が抱えていた最も根強い問題の一つは、授業料未納だった。これは大きな設計上の欠陥だった。

支払いを学業の流れとは別の事務作業として扱うのではなく、私たちはそれを構造に組み込んだ。支払いが登録を可能にし、登録が試験受験資格を可能にする。支払いがなければ、進行しない。

シンプルだが、負荷を支える設計だった。

その決定によって、プラットフォームのロジックは変わった。人々に遵守を促すことから、システムの論理フローへと焦点が移った。この違いは、多くのチームが考える以上に重要だ。

行動に関する多くのプロダクト判断は、いまだにメッセージングの問題として扱われている。しかし、その行動が事業上重要であるなら、アーキテクチャは説得以上の役割を果たすことが多い。

私が「インセンティブとしてのアーキテクチャ」と言うのは、そういう意味だ。正しい行動がシーケンスの中に組み込まれるようにシステムを設計すること。

その依存関係をプラットフォームに組み込んだ後、料金遵守は大きく改善した。だが、より大きな教訓は、もしプロダクトが特定の行動に依存するのであれば、その負荷の一部をアーキテクチャが担うべきだということだった。

行動が重要なら、リマインダーを追加する前に、選択の余地を取り除くべきだ。

P – 並行したデータ基盤

ここで多くのプロダクトは経営層を失望させる。ワークフローは機能し、ユーザーは作業を終え、取引も通る。しかし、組織は実際に何が起きているのかを把握できないままだ。

ここでも同じ状況だった。利害関係者はプロセス全体の統合された視点を持っていなかった。

納期圧力の下では、先にワークフローを出し、レポーティングは後回しにするのは簡単だ。効率的に見える。しかし実際にはそうではない。生じる死角のコストは、節約できた時間よりも大きい。

そこで私たちは、ワークフローと並行してレポーティングを構築した。

それによって意思決定が変わった。経営層は収益状況をより明確に把握できた。プログラムやレベル別の登録状況を確認できた。支払いと入学のパターンが、運用上の問題として固定化する前に、どのように変化しているかを見られた。

これがCAPEの第三原則だ。ワークフローが運用上重要であるなら、分析上も同時に重要であるべきだ。

稼働中に適切に観測できないプロダクトは、二次的なリスクを生む。意思決定が、現在の証拠ではなく遅延した仮定に基づいて行われ始める。するとチームは、本来最初から設計に組み込むべきだった可視性を補うために、何か月も費やすことになる。

計測機能のないワークフローは、運用上は生きていても、戦略上は盲目だ。

ワークフローと可視化モデルは一緒に作るべきだ。後でダッシュボードを約束するからといって、経営層に目隠しのまま操縦させてはいけない。

E – 設計による拡張性

時間が経つにつれて、私たちは堅牢な機能を備えたプラットフォームを作り続け、入学、授業料支払い、登録、試験、成績証明書といった大学の主要業務を扱えるところまで到達した。

その後、COVIDが起きた。

ほとんど一夜にして、すべてが変わった。学生が学んでいないのであれば、登録、試験、授業料などの懸念はその時点で二次的なものになったからだ。私たちの関心は、対面授業と運営が止まったときに、プラットフォームが十分な速さで適応し、運用を維持できるかどうかに移った。

プラットフォームは入学、授業料支払い、試験、成績証明書を支援していたが、学習機能はなかった。そのギャップが焦点になった。問いは即座に生じた。学習機能をゼロから作るのか、それともLMSを迅速に統合して大学を維持するのか。

学生は自宅にいた。授業は止まっていた。収益は落ちていた。必要だったのは完璧な答えではない。最も早く実行可能な答えだった。

私たちが統合を選んだのは、以前のアーキテクチャ上の選択があったからだ。十分なモジュール性を持って構築していたため、新しい機能を吸収しても、すべてを作り直す必要がなかった。無限の柔軟性ではない。次の一手を可能にするのに十分な開放性である。

それが実務上の拡張性だ。

あらゆる将来に備えることではない。そうすると過剰設計になる。設計による拡張性とは、次の現実的な変化に対応できる余地を残しつつ、変化のたびに中核を作り直さなくて済むようにすることだ。

これは、プロダクトチームが拡張性を、必要になるその日まで任意のものとして扱いがちだから重要だ。その時には、すでにコストが高くつく。

LMS統合は4か月で完了した。学業の継続性は回復した。収益も同じサイクル内で大きく回復した。だが、より大きな教訓はアーキテクチャに関するものだった。外的ショックを乗り越えるシステムは、それを予測できたシステムとは限らない。変化に対応できるよう、硬直的に作られすぎていなかったシステムだ。

あらゆる可能性ではなく、次の現実的な課題に備えて作るべきだ。

CAPEが価値を持つのは、響きがよいからではない。順序が機能するからだ。

急成長するプロダクトは、それぞれ独自の入学対応版に直面する。最初に解決しなければ、ロードマップ全体を沈める単一の失敗点であり、それ以降は比較すれば交渉可能なものになる。収益に直結する行動を持つプロダクトは、それぞれ独自の支払いゲート版に直面する。事業が依存するものを、アーキテクチャに組み込むか、延々とリマインダーで追い続けるかのどちらかだ。

どのチームも、それぞれのレポーティング問題に直面する。ワークフローの提供を優先して可視性が後回しになり、経営層が盲目のままになる。そして、すべてのプロダクトはやがて、それぞれのCOVIDに出会う。誰も想定していなかったショックが、作ったものがしなやかに曲がるのか、それとも壊れるのかを試す。

だからこそ、CAPEは他の状況にも適用できる。制約は本質的には予算の話ではない。何が真実でなければならないのかと、どこまで誤ってよいのか、その比率の問題だ。その比率は、厳しい資金調達ラウンド、厳格な規制期限、少人数の社内ツールチーム、あるいは6か月分のランウェイで動くスタートアップに現れる。圧力は違っても、必要な規律は同じだ。

正直に言えば、実際に適用するのが最も難しい原則は、インセンティブとしてのアーキテクチャだ。危機優先の優先順位付けは、最初に一度決めること。拡張性は、時間をかけて基準に組み込める習慣だ。インセンティブとしてのアーキテクチャは、もっと難しいことを求める。下流で軽く促したりキャンペーンで解決したりするのではなく、プロダクト自体の中で行動を譲れないものにするだけの確信だ。

それは、ユーザーから選択肢を取り上げるよりも、やさしく頼むほうが簡単だと考える利害関係者との間で、難しい会話になる。また、「とりあえずリマインダーを追加しよう」というほうが楽に聞こえるため、デザインレビューで薄められやすい原則でもある。だが、たいていの場合、それが正解ではない。

すでにラゴスで、西アフリカで、そして「やり方を変える予算はなかった」が売り文句ではなく火曜日の現実である市場で、スリムに構築しているのであれば、制約が良いものだと言うつもりはない。そんなことは、あなた自身がすでに知っている。

私が言いたいのは、もっと限定的で、そしておそらくもっと役に立つことだ。制約だけでは規律は生まれない。生まれるのは圧力だ。その圧力をどう扱うかは別の問いであり、現実の制約下で構築しながら順序を誤ることは十分にあり得る。なぜなら、スリムなチーム向けに出回っている助言の多くは、スリムなチームのために書かれたものではないからだ。余裕のある人たちが、余裕のある人たちのために書いたものだ。

「早く出して、コンプライアンスは後で」は、悪い助言ではない。後で発生するコストを負担できる人向けの助言だ。資金調達の予定がないまま同じ判断を先送りすれば、後でというのはたいてい二度と来ない。あるいは、その判断を最初に下していればかからなかった10倍のコストを伴う緊急対応を意味する。

この文章で先送りされたあらゆる判断――支払いを任意として扱うこと、レポーティングを後回しにすること、拡張性に必要なモジュール性を省くこと――は、まさにこの種の借り物の助言だ。遅延のコストを吸収するための後の予算が存在しないと分かるまでは、効率的に見える。

CAPEは、期限に追われる中で多くの人が偶然学ぶことを、意図的に言語化しようとした私なりの試みだ。制約が人格を育てるという主張ではない。出荷する前に、その順序の判断が本当に自分たちの貸借対照表に合っているのか、それとも他人のものにしか通用しない判断を静かに借りていないかを確認する方法だ。

その規律は、制約が和らいだ後でも持ち続ける価値がある。多くの人は、やっとこの考え方をやめるために制約から逃れたいわけではない。資金がついても、ここまで連れてきてくれた勘を失うことが目的ではない。

関連記事: FUTAが元卒業生のサイバーセキュリティ起業家を表彰、大学が画期的な国際コンピューティング会議を開催