ドーモ、読者のミナ=サン。LayerX Fintech事業部（三井物産デジタル・アセットマネジメントに出向）の鈴木（@ken5scal）です。 今回は、業務における「コンテクストを読む」ということについて、ちょっと真面目に考えてみた話を書いてみます。
みなさんは、何かしらの内容をがんばって伝えようとした相手にポカンとされたことはありませんか？わたしは無数にあります。 例えば、ELDEN RING NIGHTREIGNの深き夜深度３における追跡者はアーツゲージを回すか通常攻撃１段目を盛るビルドにするかを相談するとき... ね？みなさん、とポカンとされたでしょう。悲しい。
せっかく自身の目指す目的を達成しようとしているのに、「ごめん、どゆコンテクスト？」とそもそも話に戻されてしまうのは辛いものです。
とはいえ、実際に通じてないことは素直に受け止める必要があります。では、コンテクストとは何でしょうか。 私見ですが「コンテクストを踏まえる」という言葉は、目標設定をするタイミングや、その振り返り、そして評価される時期に聞きがちです。 当社もそういう時期ですので、ここは１つ、このコンテクストとやらが何者かをわたしなりに書いてみようとおもいます。
コンテクストとは何か
Weblio辞書 - contextによると「コンテクスト（Context）」は前後関係、文脈、脈絡、コンテキスト、状況、環境（※）を指すようです。
これを実務的な文脈（そうコンテクスト）にすると、主に次のように分類できるかと思います。
- 外的な状況: 外部規制、業界・他社の動向・トレンド、VCが注目している領域
- 組織・チームの状況: 自社のミッション、チームの方針、他部署の動き、人事異動、自社の決算情報
- 技術・業務の背景: 過去の設計思想、現在のルールの存在理由、仕様の詳細
つまり、今フォーカスしたい情報の周辺情報を処理することがコンテクストを踏まえるということです。 この、フォーカスの焦点から距離が遠い情報ほどハイコンテクストになり、それを下にした対応は俯瞰的になります。 具体的な例で考えてみましょう。
例えば、Fintech事業部のコーポレートシステムで「新しいセキュリティツールを導入したい」という話になったとします。 ある程度のコンテクスト範囲ですと「このツールは技術的に優れている」、「コストは月額○○円」、「導入すればセキュリティが向上する」ということになるでしょう。 ここまでケアできること自体は素晴らしいことです。 ただ、更にハイなコンテクストも踏まえると、金融庁のサイバーセキュリティガイドラインで求められている要件を満たしているか、運用するなら権限分掌的にどの部とするのが適切か、グループ会社全体のセキュリティポリシーとの整合性はどうか、監査法人の指摘事項への対応になっているか、チームのスキルセットで運用できるか、既存のSIEMやデータ基盤との連携はどうかといった疑問にも答えられるようになります。
私見ですが、より影響範囲の広いお仕事をしたい場合、ハイコンテクストの把握を必要とするケースが多いように思えます。 影響範囲が広いだけに、最初から関連する制約や要件を把握し手戻りリスクを減らしつつ、単一の観点ではなく複数の観点から総合的な判断の精度を高め、他部署や外部の制約を持つ関係者との調整がスムーズにする必要性があるからです。
わたしの所属する金融領域では、技術的な優位性だけでなく、規制対応、ガバナンス、コンプライアンスといった複数の軸での評価が求められるため、ハイコンテクストな理解はあればあるほどよいです。 一方、専門性をより発揮し、「深い」仕事をしたい場合はその限りではないです。
どうコンテクストを集めるか
ふたつの収集場面があると思います。 瞬発的に集める場合と、継続的に集める場合です。
瞬発的にコンテクストを集める必要性に駆られる場面としては、これも突発的なコミュニケーションに多くあるように感じます。 例えば「xxxさんに〇〇システムの△△権限が欲しい」みたいな問合せ時などです。 こういった問合せをうけたときに、そのまま実行してしまい、「やっぱりこれも必要でした」とか「それやっちゃあかんやつ」みたいなことを言われたことはないでしょうか（もちろん、あります）。 本来であれば、業務の確認から始まり、内部の権限分掌規程をもとにした依頼の妥当性、既存のシステム構成との比較等をしたうえで、行動に移すべきでしょう。
継続的にコンテクストを集める場面としては、日常的な情報収集活動が中心になります。金融庁の新たなガイドラインや規制変更の情報収集、業界他社のセキュリティインシデント事例の分析、三井物産グループ全体の戦略や方針の変化といった組織・業界の動向把握から、セキュリティツールの新機能やアップデート情報、クラウドプロバイダー（AWS、Azure等）の新サービス、オープンソースプロジェクトの動向といった技術トレンドの追跡、そして他部署のプロジェクト状況や課題、チームメンバーのスキルアップ状況、予算やリソース配分の変化といった内部情報の収集まで、幅広い範囲にわたります。
わたしの場合、金融庁の公式サイト、AWSのブログ、セキュリティ関連のニュースサイトを毎日チェックしたり、他部署の定例議事録を見たり、社内Slackでの投稿を横目で見たり、キーマンの議事録や立ち話を聞いたり、セキュリティエンジニアの勉強会やカンファレンスに参加したり、過去のプロジェクトの失敗事例や成功事例を文書化してパターンを把握したりといった方法で継続的にコンテクストを集めています。
特に重要なのは、「なぜそのルールが存在するのか」を理解することです。 単に「ルールだから」ではなく、その背景にある制約や過去の経験を理解することで、新しい状況でも適切な判断ができるようになります。 例えば、権限管理のルールが複雑になっている背景には、過去のセキュリティインシデントや監査法人の指摘があったり、既存システムの制約があったりするわけです。 こういった背景を理解しておくと、新しいシステムを設計する際にも「なぜこのルールが必要なのか」を説明でき、より説得力のある提案ができるようになります。
コンテクストを作る側になることの価値
コンテクストを読むだけでなく、コンテクストを作る側になることで、より大きな価値を生み出すことができます。文脈を作ってリードするとプロジェクトがよりスムーズに進み、技術選定の議論では「なぜこの技術を選ぶべきか」の背景を整理し関係者に共有することで意思決定が早くなり、セキュリティ要件の明確化では規制要件やリスクを整理し具体的な実装方針を示すことで開発チームの迷いを減らせ、他部署との調整では互いの制約や要件を整理しWin-Winの解決策を提案できるようになります。
コンテクストを作る側になると、新しいルールやポリシーの策定にも貢献できます。 これにより、過去の事例を踏まえてより効率的なプロセスを提案し、組織の成長に合わせた適切なガバナンス体制を設計することが可能になります。 特に重要なのは、ルールやポリシーを作ることで、チーム全体にコンテクストを与えられることです。曖昧な境界線をなくすことで、「この場合はどうすればいいんだろう？」「この判断は誰がするべき？」「この責任はどこにある？」といった迷いや混乱を減らせます。 例えば、権限管理のポリシーを明確にすることで、新しいシステムの権限設計時に迷うことがなくなり、セキュリティ要件のガイドラインを作ることで、開発チームが「どの程度のセキュリティレベルを求められているか」を明確に理解できるようになります。
もちろん、コンテクストを共有することは忘れずに。 いくら良いコンテクストを作っても、関係者に共有されなければ意味がありません。 重要な判断や背景は必ず文書に残し、プロジェクトの進捗と合わせて背景情報も定期的に共有し、一方的な情報提供ではなく双方向の対話を通じて理解を深めていくことが重要です。
まとめ
コンテクストを読むことは、単なる「空気を読む」ことではありません。組織の方向性、制約、価値観を理解し、それに基づいて適切な判断や行動を取ることです。 そして、コンテクストを作る側になることで、チーム全体の生産性を向上させ、より良い意思決定を促すことができます。 特に、異なる組織や部門間での協働が増えている現代では、コンテクストを理解し、共有する能力は、エンジニアにとっても必須のスキルだと思います。 みなさんも、日々の業務で「なぜ？」を意識して、コンテクストを読み、作る側になってみるのも一興かもしれません。
LayerX Fintech事業部では、セキュリティとガバナンスを両立させながら、革新的な金融サービスを開発しています。興味を持っていただけた方は、ぜひOpenDoorやXアカウント（@ken5scal）のDMまでお気軽にご連絡ください。 また、私といっしょにELDEN RING NIGHTREIGNの深き夜に潜ってくれる方も募集しています。当方、追跡者、守護者、鉄の目、レディ、隠者、復讐者いけます。
