IT Analysis & Auditing

エンタープライズ技術における深刻な問題のほとんどは、同じ静かな誤りから始まります。誰かが、すでに古くなった、不完全な、あるいは単に誤ったIT環境の姿をもとに行動を起こしてしまうのです。移行プロジェクトは現実をもはや反映していない図面をもとにスコープが定められ、統合プログラムは誰も文書化していなかった基幹システムの存在を後から発見します。本稿では、分析と監査を文書化作業としてではなく、診断の技として捉えます。主張よりも証拠を重んじ、症状と原因を切り離すことを強く求めます。両者を取り違えた代償は、後になって、本番環境で、大規模に支払われることになるからです。

What Nashua offers hereあなたのIT環境が実際にどのようなものであるか、そして何をする必要があるかの両方を確立するエンゲージメント。これにより、変更は証拠と、よく整えられたバックログをもとにスコープが定められます。See the engagements

誰も全体像を把握していないIT環境

ほとんどのエンタープライズIT環境について不都合な真実を言えば、何が存在し、それらがどうつながり、なぜそのように振る舞うのかを正確に把握している人物は誰一人おらず、多くの場合、正確に記述した文書も存在しないということです。システムは、買収、組織再編、緊急の応急対応、そして本来の意図を理解していた技術者の退職を経て、数十年にわたり積み重なっていきます。地図は、もし存在するとしても、実際の地形から着実に乖離していきます。残されるのは断片的な視点の集まりです。三年前には正確だった構成管理データベース、運用を記述するためではなくプロジェクトの承認を得るために描かれたアーキテクチャ図、そして数少ない長年の在籍スタッフが非公式に抱える膨大な暗黙知です。

このことが今、いっそう重要になっているのには、事情が大きく先鋭化したという理由があります。IT環境はかつてないほど相互依存を強めており、クラウドサービス、オンプレミスのレガシー、software as a service、そして統合ミドルウェアが、組織やベンダーの境界を越える流れのなかに織り込まれています。データ、レジリエンス、サプライチェーンをめぐる規制上の要求は厳格化しており、何を稼働させ、どのように統制しているかを証明できることは、もはや任意ではありません。そして変化の速さゆえに変革プログラムは絶え間なく立ち上げられ、そのそれぞれが正確な基準状態に依存した意思決定を下します。基準状態が誤っていれば、プログラムはその誤りを引き継ぎ、増幅させます。したがって、ありのままの真実を確立することは予備的な整理作業ではありません。それは、後に続くあらゆる意思決定にとって最も重大な入力なのです。

アセスメントと監査は同じ専門領域ではない

アセスメントと監査という言葉は、日常的な会話では互換的に使われますが、これらを同義語として扱うことが最初の誤りです。両者は異なる問いに答え、異なる証明の基準に従い、異なる種類の確信を生み出します。アセスメントは診断的で、将来に目を向けます。IT環境の真の状態は何か、リスクと技術的負債はどこに存在するか、そして何を変えるべきかを問います。それは、根拠に基づく判断や、不完全な証拠の行間を読むこと、そして所見を熟慮された専門的見解として表現することを厭いません。その成果は、理解と進むべき方向です。

監査は評価的で、証拠に基づきます。IT環境を、定められた標準、統制フレームワーク、ポリシー、ライセンス契約、あるいは規制上の義務に照らして測定し、適合性を証明できるかどうかを問います。その通貨は、異議申し立てにも耐えうる証拠です。実際にあるがままの構成、統制が発動したことを証明するログ、誰が変更を承認したかを示す記録です。監査は、次に何が起こるべきかにははるかに関心が薄く、何が真実であるかについて何を証明できるかに、はるかに強い関心を寄せます。二つの領域は補完的であり、しばしば並行して進められますが、両者を混同すると脆弱な仕事になります。監査を装ったアセスメントは、裏付けられない主張をします。アセスメントを装った監査は、適合性を健全性と取り違え、チェックリストのあらゆる項目に印をつけながら、その端で静かに崩れていくIT環境を見過ごします。自分がどの問いに答えているのかを知り、その問いが要求する証明の基準に自らを律すること、それがこの技の土台です。

業務分析と技術分析は異なるレンズである

ここまで述べてきたことはすべて技術分析です。すなわち、実際に構築され現に振る舞っているシステムを、規律をもって読み解くことです。それは我々が持っているものについて何が真実かという問いに答えます。それは不可欠であり、しかし仕事の半分にすぎません。もう半分は業務分析であり、組織はそのシステムに実際に何をさせる必要があるのかという別の問いに答え、別個の技能の体系に依拠します。両者は補完的であり、よくある誤りは一方に予算をつけ、もう一方はひとりでに実現されると思い込むことです。技術分析のみからスコープを定めた変更は、既存のものをより現代的な部品で作り直すだけで、そもそもそれが存在すべきかを問うことがありません。業務分析のみからスコープを定めた変更は、何が実現可能かを左右する制約や負債に目を向けないまま、真空のなかで必要性を規定します。真摯な分析は、この二つのレンズを同時に持ち続けます。

要件は業務分析の中核であり、それは決してぼかしてはならない種類に分かれます。機能要件は、システムが何をしなければならないか、すなわちユーザーや他のシステムが観察できる振る舞いを記述します。非機能要件は、それをどれだけうまく行わなければならないか、すなわちその振る舞いが実際に使えるものになるかどうかを決める品質を記述します。負荷下での性能と応答、可用性とレジリエンス、セキュリティとプライバシー、拡張性、アクセシビリティ、そしてシステムが満たすべき規制上の義務です。技術要件と制約は、解決策が立脚すべき地盤、稼働すべきプラットフォーム、統合すべきシステム、そして遵守すべき標準を記述します。プロジェクトは、見落とされた機能よりも、なおざりにされた非機能要件や技術要件によってはるかに頻繁に失敗します。機能は目に見え、求められるのに対し、品質は当然のものとみなされ、本番環境で壊れるまで沈黙しているからです。

述べられた要望から必要性を切り離すことこそ、アナリストの真の技です。ステークホルダーは、すでに解決策を念頭に置いて現れ、それを要件として述べます。訓練を積んでいない対応は、それをそのまま書き留めることです。規律ある対応は、その根底にある必要性、すなわち提案された解決策が達成しようとしていた成果を掘り起こすことです。より優れた、より安価な選択肢が姿を現すのは、たいてい必要性のレベルにおいてだからです。これは妨害ではありません。求められたものを作ることと、望まれていたものを作ることの違いであり、両者は誰もが認めたがるよりもはるかに頻繁に別物なのです。

分析の対象:プロセス、情報、そしてシステム

要件は宙に浮いているわけではありません。それはそれ自体が分析に値する二つのものの上に成り立っており、そして三つ目のものが我々をIT環境へと連れ戻します。

プロセスと workflow の分析は、それを担う人とシステムを横断して、作業が実際にどのように、一つひとつの段階を経て流れるのか、そしてどこで滞留し、後戻りし、あるいは誰も認めたがらない表計算ソフトに静かに依存しているのかを問います。ほとんどの要件は、実のところプロセスについての言明であり、その背後にあるプロセスを踏まえずに集められた要件は、熟慮された設計ではなく、歴史の偶然を自動化してしまいがちです。手順書が主張するとおりではなく、あるがままの実際の workflow を描き出すことこそ、最も価値ある所見と最大の簡素化がしばしば発見される場所です。

データと情報の分析は、別の一連の問いを立てます。組織はどのような情報を保持しているのか、それは本当は何を意味するのか、どこに由来しどのように流れるのか、そしてそれは信頼できるのか。それは、概念データモデルと論理データモデルの作業であり、それぞれが顧客や製品とは何かをすでに知っていると思い込んでいた部門どうしのあいだで合意された定義の作業であり、品質と来歴についての率直な評価の作業です。システムは結局のところ、情報を移動させ変換するための機械であり、データを後回しに扱う分析は、その情報がすでに抱えるあらゆる曖昧さと重複を引き継いでしまいます。

技術とシステムの分析がこの組を締めくくり、ここで我々は先に述べたIT環境のアセスメントと監査に立ち返ります。実現可能性、統合、既存アーキテクチャの制約、そしてあらゆる解決策を形づくることになる負債です。これらの形態を別々に名づける狙いは、一つで足りるところに四つのエンゲージメントを売りつけることではありません。それぞれが異なる技能を用い、異なる問いに答えるということ、そして分析という実践の値打ちは、まさに、ある問題が実際にどの分析を必要としているかを見極め、要件、プロセス、情報、そしてシステムが、孤立して集められて手遅れに縫い合わされるのではなく、互いに情報を与え合うように順序立てることにあるのです。

これらの形態はすべて、戦略的かつ業務的な側面から深く技術的な側面に至るまで、我々が分析として提供するものの一部です。あるエンゲージメントはそのうちの一つだけを必要とするかもしれず、あるいはそのすべてを協調させて必要とするかもしれません。そして良い分析の最初の一手は、どれが必要かを見極めることなのです。

One analysispracticeBusiness requirementsUser stories and backlogProcess and workflowData and informationTechnical and system
The forms of analysis Nashua offers, from business requirements through process and information to the technical system, sequenced so each informs the others.

主張よりも証拠を

良い診断を統べる原則は、証拠が主張に勝るということです。自らのシステムを本当に理解していると心底信じている人々の自信に満ちた主張であっても、例外ではありません。これは同僚に対する冷笑ではありません。技術環境についての人間の説明が体系的に信頼できないという認識です。それは不誠実さによるのではなく、知識のありふれた劣化によるものです。人は、システムを設計されたとおりに、あるいは最後に理解したとおりに、あるいはそうあってほしいと願うとおりに説明します。意図されたデータフローは報告しても、二年ものあいだ静かに本番トラフィックを担ってきた緊急の回避策には触れません。インタビューだけに依拠する診断は、こうした歪みのすべてを引き継ぎます。

したがって証拠に基づく分析は、三角測量を行います。人々が語ることを集め、それを成果物が宣言する内容と、稼働中のシステムが実際に行うことに照らして検証します。構成ファイル、infrastructure-as-code の定義、デプロイメントマニフェスト、ネットワークルール、データベーススキーマ、そしてアクセスポリシーは、IT環境がそれ自身について記した記録であり、古びていることはあっても、会話よりは記憶違いが起こりにくいものです。振る舞いはさらに正直です。テレメトリ、トラフィックキャプチャ、依存関係のトレース、ログ量、そしてリソース消費は、何が本当に使われているのか、何が何と通信しているのか、そして真の負荷と真の脆弱性がどこにあるのかを明らかにします。この三つの情報源が一致すれば、確信は高まります。食い違えば、その食い違い自体が一つの所見であり、たいていはそのエンゲージメントで最も価値ある所見です。信念と宣言と振る舞いのあいだの乖離こそ、隠れたリスクと文書化されていない依存関係が潜む場所だからです。実務家の務めは、証拠をそれ自体のために集めることではなく、これらの矛盾を、擁護しうる現実の説明へと解きほぐすことです。

InventoryEvidenceDiagnosisRecommendation
Diagnosis moves from gathered evidence to a defensible account of the IT landscape before any change is proposed.

成果物と振る舞いからアーキテクチャを読み解く

アーキテクチャがきれいに手渡されることはめったにありません。多くの場合、それは再構築されなければならず、それが残した痕跡から推論されなければなりません。野外の地質学者が、設計者の青写真からではなく、露出した地層から地形を読み解くのと同じようにです。成果物が最初の地層です。ソースリポジトリは構造、結合、そしてコードベースの形を明らかにし、そのコミット履歴は、どのコンポーネントが絶えず変化し、どれが何年も凍結され、どこに変化が集中しているかを明らかにします。ビルドとデプロイメントのパイプラインは、何が一緒に出荷されるか、したがって論理図が何を主張しようと実際には何が結合しているかという、真のトポロジーを露わにします。インフラストラクチャの定義は意図された実行環境を示し、インベントリとスキャンによって発見される実際の実行環境は、意図と運用のあいだの乖離を示します。そしてその隔たりこそ、しばしば興味深い問題が潜む場所です。

振る舞いはより深い地層であり、そこで推論されたアーキテクチャが確認されるか覆されるかします。観察されたトラフィックと分散トレースから構築された依存関係マッピングは、真のコールグラフを示し、そこには意外な辺も含まれます。トランザクションデータベースに直接手を伸ばすレポーティングジョブ、いまだにリクエストを受け取っている非推奨のサービス、重要な流れが静かに依存しているサードパーティのエンドポイントです。データフロー分析は境界を越えて情報を追跡し、しばしば重複、文書化されていない複製、そしていかなるガバナンス記録も捉えていなかった来歴を明らかにします。このすべてにおける規律は、偶発的なものを本質的なものから区別することです。あらゆる依存関係が意図的なわけではなく、あらゆる結合が必要なわけでもありません。アーキテクチャをうまく読み解くことの一部は、どの構造が真の設計意図を表し、どれが圧力のもとで下された場当たり的な決定の傷跡であるかを見分けることです。再構築された姿は常に一つの仮説として保持され、新たな証拠に照らして検証され、振る舞いがその筋書きと矛盾するときには執着なく修正されなければなりません。

症状を原因から切り離す

分析における最も高くつく失敗は、因果推論の失敗であり、それらはいくつかの見分けやすいパターンの周りに群がります。症状への固執が最もありふれています。すなわち、なぜ痛むのかを問うことなく、痛むものすべてを列挙する診断です。遅い応答時間、繰り返す障害、そして増大するコストは症状であり、容量を追加したりタイムアウトを厳しくしたりして直接それらに対処すると、痛みは和らぐかもしれませんが、その根底にある病理、すなわち構造的なボトルネックや拡張性の乏しい設計は、そっくりそのまま無傷で残り、別の場所で再び現れます。良い診断は、対処すれば症状の一群がまとめて解消されるような原因に到達するまで、なぜと問い続けます。

ツール崇拝とは、スキャン製品の出力が診断であるという思い込みです。自動化された探索、脆弱性スキャナー、そして依存関係アナライザーは、大規模に証拠を集めるうえで不可欠ですが、それらが生み出すのは所見であって理解ではありません。汎用的な重大度スコアで順位づけされた二千件の脆弱性のリストは、解釈を待つデータであって、結論ではありません。ツールの順位を優先順位として扱うことは、このIT環境で実際に何が重要かを決める文脈を無視することです。結論ありきのスコープ設定はより静かな危険です。すでに下された決定を裏づけるように分析を組み立てることで、アセスメントは正当化の作業となり、望ましい答えを複雑にしかねない証拠は決して集められません。精密さの演出は誘惑的な最後の罠です。測定可能でつまらないものに膨大な厳密さを注ぎ込む一方で、真に重大な構造的リスクは、定量化しにくいがゆえに、表計算にきれいに収まらないという理由で吟味されないままになります。これらの失敗のいずれもが、それ自体の根本原因を共有しています。すなわち、診断が完了する前に処方が到来すること、そして分析が、誰かがすでに売りつけたいと思っていた治療法に合わせて、こっそりと曲げられることです。

Nashua のIT環境への取り組み

Nashua は分析と監査を、変更を売り込むための前置きとしてではなく、意図的で証拠主導の実践として扱います。エンゲージメントは、問いを精確に定めることから始まります。アセスメントと監査は異なる作業を要求し、どちらが求められているのかを明確にすることが、演習全体が脆弱な一般論へと漂流するのを防ぐからです。そこから先、その手法は体系的に三角測量されます。ステークホルダーが説明することは、意図と経緯の情報源として捉えられ尊重されたうえで、成果物が宣言する内容と、そして安全に集められるかぎりにおいて、稼働中の環境が実際に行うことに照らされます。構成、コード構造、インフラストラクチャの定義、テレメトリ、そして依存関係の振る舞いが一緒に読み解かれ、それらのあいだの矛盾は、覆い隠されるのではなく追究されます。それらの矛盾こそ、基幹を支える意外な事実が潜む場所だからです。

Nashua がもたらす規律は因果的であって、単なる列挙ではありません。所見は、汎用的な重大度の数値で並べられた二千件の未分化な問題のリストとして提供されることはありません。それらは原因ごとに整理され、IT環境の構造的な病理が名づけられ、それが生み出す症状から切り離され、技術的負債は、その生の件数ではなく、それが抱えるリスクと、対処することが生み出すてこの効果によって特徴づけられます。Nashua はまた、確信の度合いについても率直です。証拠が強固なところでは、所見は明快に述べられます。姿が推論や、完全には検証できなかった記録に依拠しているところでは、その不確実さは、偽りの精密さの背後に隠されるのではなく、明示されます。まだ分かっていないことについての正直な説明は、後に誤りと判明する自信に満ちた説明よりも、意思決定者にとって有用だからです。その成果物は、擁護しうる診断です。すなわち、変革、統合、あるいは是正のプログラムが、隠れた誤りを引き継ぐことなくその上に築くことのできる、IT環境の真の状態です。

Nashua が違いを生み出すところ

Nashua が生み出す違いは、診断と処方を本来あるべき順序に保つ規律であり、そしてそれが不都合なときでもその一線を守り抜く独立性です。多くの分析は、証拠が集められる前に推奨が決まっている当事者によって実施されるため、診断は、意識的であれ無意識的であれ、はじめから提案されることになっていた変更を正当化するように形づくられます。Nashua の価値は、そのIT環境についての説明が、都合のよいものではなく真実であるように築かれていることであり、それこそが、後に続く意思決定にとって健全な土台となる理由です。基準状態が正直であれば、何を移行し、何を退役させ、何をそのままにし、何をまず是正するかという、あらゆる下流の選択が、本番環境で破綻する思い込みではなく、堅固な地盤の上に立ちます。

さらに、この仕事が前提としてよいことを変える実践上の帰結があります。エンゲージメントが、まだ存在しない機能を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要がありません。enterprise platform は、エージェンティック・エンジニアリング によって、ほとんどあらゆる機能を速いペースで受け入れられるように作られています。必要なものが平易な言葉で記述され、すばやく生成されますが、常に確固たるアーキテクチャ原則のもとで、そして厳格な品質保証のもとで行われるため、速さがまとまり、セキュリティ、あるいは統制を犠牲にすることは決してありません。その効果は、単に便利であるにとどまらず、戦略的です。それは内製か購入かの境界線を動かし、選択肢を安価に保ち、戦略が棚にあったものに合わせて曲げられるのではなく、アーキテクチャが戦略に従うことを可能にします。

これらをまとめて支えているのは、診断と、その後に続くすべてとのあいだの連続性です。ファイルされて忘れられるアセスメントは、それが置き換えた文書と同じ速さで劣化します。Nashua の実践は、確立された真の状態を、時とともにアーキテクチャ、セキュリティ、そして運用上の意思決定に情報を与える生きた参照として扱うこと、そして証拠、論拠、そして確信の度合いを透明に保ち、他の人々がその仕事に異議を唱え、拡張し、依拠できるようにすることです。厳密な診断、因果の正直さ、そして持続する追跡のこの組み合わせこそ、分析が報告書であることをやめ、真の優位性となる場所です。組織はついに、自らが実際に持っているIT環境を知り、希望ではなく確信をもってそれを変えられるようになるのです。