「壊れない設計」は、先に将来を当てることではない
FDEとは、企業の現場に深く入り込み、業務システムやAI活用ツール、社内向けのナレッジベース(組織の知識や情報をまとめて検索・活用できるようにした仕組み)を、顧客と一緒に設計・実装する役割を指す言葉です。この仕事でよく語られるのが「壊れない設計」という目標です。ただし、これは将来起きることをすべて言い当てて、あらかじめ機能を作り込んでおくという意味ではありません。
システムの世界でよく使われる「レジリエンス」という考え方があります。これは、悪い条件やストレス、想定外の出来事を予測し、耐え、そこから回復し、さらに適応していく能力のことです。つまり「壊れない」とは、変化が一切起きないことではなく、変化が起きたときに立ち直れる状態を保つことに近い意味を持ちます。
私たちは、企業のシステムやアプリ、ナレッジベースを構築するとき、この考え方を強く意識してきました。プロトタイプ、つまり試作段階のものは短期間で作れても、実際の業務で安定して使い続けられる状態に持っていくには、関わる変数の多さに応じた地道な調整が欠かせません。この調整の積み重ねこそが、変化に耐える設計の実態だと感じています。不確実性を理由にあらゆる将来ケースを先回りして実装するのではなく、変化が起きたときにどこを直せばよいか、誰がその判断を下すのかを、あらかじめ追える状態にしておくことが出発点になります。
FDEの事業理解は、要件収集ではなく設計制約の翻訳である
FDEに事業理解が必要だとよく言われますが、それは営業のための補助知識という意味ではありません。企業のシステムやアプリ、ナレッジベースを作るとき、今後の事業展開のなかで壊れないように設計する必要があります。そのために、ビジネスに対する知見や経験が求められるのは、事業を知らなければ、長期的に、そして変化に耐えられる設計をすることができないからです。
システムやサービスの設計を扱う国際的な枠組みでも、設計の対象は技術そのものだけでなく、企業やサービス、事業領域全体を含むとされ、関係者が何を重視しているかを扱う必要があるとされています。同様に、アーキテクチャ開発の方法論では、事業要件や財務・組織上の制約を設計の入力情報として扱い、各段階でそれらに照らして検証を重ねる、反復的な活動として位置づけられています。
こうした考え方を踏まえると、事業理解とは、今ある業務フローを聞き取ることだけを指すのではありません。今後変わり得る事業の前提、絶対に崩してはいけないデータの正本(情報の正しい原本、どこを見れば最新かつ正しい情報かがわかる基準点)、そして事業や組織の範囲が広がったときに誰が責任を持って変更を判断するのかを区別し、それらを設計上の制約へ翻訳する作業だと私たちは考えています。要件定義が完了したかどうかは、機能の一覧が埋まったかどうかではなく、事業の変化を設計上の制約として言語化できたかどうかで確かめるべきです。
現在の業務を固定化すると、役割の重複が後から統合負債になる
FDEの役割のひとつに、内製ツールの立ち位置を管理することがあります。ナレッジベースと連動する社内ツールやアプリケーションを内製していく際、誰がどの立ち位置のツールを作っているのかをFDEが把握し、全体を設計したうえで、役割が重ならないように調整する必要があります。役割が重複すると、後からそれらを統合する作業が非常に面倒になるためです。
これは、複数の部署やツールがデータやナレッジを横断的に検索・活用できる基盤を整える発想とも重なります。社内のデータとナレッジをエージェント(自動でタスクをこなすAIの仕組み)が横断的に探し、活用できるナレッジベースをAPI(異なるシステム同士がデータをやり取りするための窓口)でつなぎ、各部署がそのデータをもとにツールを開発していく、という統合された仕組みが求められます。
しかし、こうした基盤づくりを進める前に確認すべきことがあります。それは、複数のツールや部署が参照・更新する情報のうち、どれが正本なのか、その更新権限を誰が持ち、情報の食い違いが起きたときに誰が最終判断を下すのかという点です。この境界を曖昧にしたまま「とりあえず今の業務を自動化する」形でツールを増やしていくと、利用部署や機能が増えるたびに、後から役割を整理し直す負担が積み上がっていきます。変化への備えとして最初に必要なのは、万能な共通基盤を先に完成させることではなく、どのデータを正本とし、各ツールが何を担わないかという、最小限の境界を先に決めておくことだと私たちは考えています。
設計前に確認する三つの問い
不確実性に対して抽象的な仕組みを増やすほど、後から手を入れにくくなることがあります。私たちは、将来を完全に見通すことよりも、変更が起きたときにそれを判断できる材料と担当を残しておくことを優先すべきだと考えています。そのために、設計に着手する前、次の三つの問いを確認することを提案します。
- この半年から一年の間に変わり得る事業の前提は何か。その変化の兆候を誰が確認し、いつ設計を見直すのか。
- 複数のツールや部署が参照・更新する情報の正本はどこにあるか。その更新権限を誰が持ち、情報が食い違ったときの決定者は誰か。
- 利用する部署や機能、連携先が増えたとき、どの境界を越える変更が必要になるか。その変更の責任を誰が引き受けるのか。
これらは、特定の企業で実際に決められた手順というより、設計に着手する前の点検項目として使えるチェックリストです。すべてに明確な答えが出なくてもかまいません。むしろ、答えられない箇所を「未確定の設計リスク」として明示しておくこと自体が、後から壊れにくい仕組みを作る助けになります。
不確実な未来に備えて、最初からあらゆる場面を想定した汎用的な仕組みを作るべきだ、という考え方もあります。ただ、汎用化は判断そのものを先送りにしてしまうことがあります。今の時点で確定している正本や権限、責任の所在をまず明らかにし、まだ確定していない前提については、見直す条件とあわせて残しておくほうが、過剰な作り込みを避けながら変化に対応しやすくなると私たちは考えています。
事業を知るFDEは、未来を約束するのではなく変更を扱えるようにする
信頼できるシステムを作る工学の考え方では、要求分析から設計、検証、リスク管理までを、対象の目的や規模、置かれている段階を問わず、ライフサイクル全体を通じた活動として扱います。FDEに求められる役割も、これと近いところにあると私たちは感じています。
FDEの責任は、事業の将来を正確に言い当てることではありません。何が変わってよく、何を守るべきで、変化が起きたときに誰がその判断を引き受けるのかを、実装に着手する前に見える形にしておくことにあります。次に要件定義を進める際は、機能の一覧づくりに入る前に、今回挙げた三つの問いに答えてみてください。そして、答えられなかった部分を、隠すのではなく「未確定の設計リスク」として残しておくこと。それが、事業を理解したうえで変化に耐える設計へとつながる、地道だけれど確実な一歩になるはずです。
