「順序を守る」「分からないことを認める」「自走を設計する」。プロジェクトの現場で、これらの原則がどう機能しているか。
インシデント対応でも開発支援でも、「急いでいるから」という理由でステップを飛ばす誘惑は常にあります。経営者は早く結論がほしい。投資家は早く成果がほしい。しかし、open brain は順序を守ることにこだわります。
フォレンジックであれば、証拠保全の前に封じ込めを急ぐと、重要な証拠が失われる。AI導入であれば、データの棚卸しの前にツールを選定すると、後から大幅な手戻りが生じる。
正しい順序を守ることが、結果として最短の解決につながる。これは現場で何度も確認してきた事実です。
クライアントが最も不安になるのは、「何が起きているか分からない」状態です。そのとき、専門家として最もやってはいけないのは、分かっていないのに分かったふりをすることです。
open brain では、「分かっていること」と「まだ分かっていないこと」を常に明確に分けて共有します。中間報告では、事実と推測を混ぜない。仮説を立てるときは、それが仮説であることを明示する。
すべてのプロジェクトのゴールは、「open brain がいなくても回る状態」をつくることです。フォレンジックであれば再発防止体制の構築、CTO代行であれば意思決定プロセスの文書化と引き継ぎ、開発支援であれば運用ランブックの整備。
外部パートナーへの依存は、短期的にはクライアントにとって楽ですが、長期的にはリスクです。だからこそ、プロジェクトの初日から「終わり方」を設計することを徹底しています。
「このプロジェクトは、何が達成されたら完了か」「引き継ぎ後にクライアントが自分で判断できる状態とは何か」——これを最初に定義し、そこに向かって進む。自走の設計は、支援の質そのものです。