OODAループに基づく、NASの共有フォルダアクセス不調の対応

　OODAループに基づく、NASの共有フォルダアクセス不調の対応（以下、本対応といいます）です。
設置したNASが共有フォルダアクセス不調になる原因はネットワークの問題であったりPCが問題であったりと、画一的ではなく、原因も様々です。また、症状がランダムで発生するため、トライアンドエラーで実行した処置の効果が分かりにくく様子見⇒再対応を繰り返し、対応が長引く傾向があります。
　この対応には、応急処置的なスポットでの対応ではなく時系列を意識した線的な対応を要します。同じく長期化しやすいネット遅延のような症状の対応のように、必要な情報の入手及び判断を適時・適切に実施する必要があります。
　しかし、これらの対応は作業者のスキルや経験に多分に作用されます。
　今回は作業の標準化も視野に入れ、OODAループという現場対応でよく利用されるフレームワークを理解の補助線として、この対応を検討します。

  OODAループは、 Observe（観察）、Orient（状況判断、方向づけ）、Decide（意思決定）、Act（行動）の4つのフェーズの頭文字を取った対応手順です。
　OODAループでは、各フェーズを「観察」⇒「状況判断」⇒「意思決定」⇒「行動」と順に対応を進め、さらに最後の「行動」の結果を踏まえ再度「観察」のフェーズに移ります。
　観察によってデータを収集し、状況判断によりデータを分析し情報化します。さらに、分析した情報を基に意思決定し、行動を実施します。
　このOODAループは、長期、通常は年単位で展開されるPDCAサイクルよりも短いサイクルで利用します。それはOODAループでは、様々な変数、特に時間経過によって意味が変化するような情報を処理できるように最適化されているからです。つまり、現場により近い思考方法と言えます。

　では、具体的なOODAループを基にした本対応を検討します。
Observe（観察）
　観察ではサンプル及びデータを収集します。
　入電では「不調」と表現されている症状が、どのような頻度で、どのような操作によるものか、いつからか、等を確認します。
　本対応では、顧客の感じているフラストレーションを改善可能なように具体的な数値化する作業と考えれば、どのようなデータを収集すべきかが分かりやすいと思います。
　「顧客の感じている」と表現している通り、本対応の症状を作業者が確認することは稀です。このため、顧客及び担当者に症状発生の際にメモを残す、など、データ収集に協力を要請することも、実施するべきです。
　このデータは特にフラストレーションの数値化に役立ちます。それはどの程度減少が抑えられれば改善傾向が見えるのか、といったように明確に改善指標として有効だからです。
　ただし、依頼する顧客側は「余計な作業」を強いることになるので、この点を配慮し、可能であれば実施し、かつ収集期間はできるだけ短くするようにします。
　また、フラストレーション自体もデータとして扱うべきです。このデータは、特に時間経過によって悪化する変数だからです。ただし、数値化は難しいので、あくまで検討に入れる、くらいの感覚で問題はありません。

Orient（状況判断、方向づけ）
　収集したデータを分析し、傾向を探って情報化します。
　例えば、前工程で症状発生した時間が確認できたら、その時間をフォーカスします。NASのファイルアクセスログや、その時間のシステムリソースなどを確認します。
　この場合、複数の発生時間に共通している事象を特定することが重要です。特定のクライアントがアクセスしていないか？発生時間に偏向はないか？NASのCPUなどの異常はないか？といったような観点でデータを確認していきます。
　これらは、ログが採取できる機器が多ければ多いほど精度の高いものとなります。必要に応じてミラーポートを持ったL2スイッチによるパケットキャプチャなども用意します。一つの機器から採取したログのみよりも、複数の機器から採取したログにより得られたデータから結び付けられる状況の方が情報としての証拠能力が高くなります。
　ただし、OODAループでは、即応が重要なので、準備が必要ならば次回のループに回す場合もあります。
　いくつか、現場で確認できた具体例を挙げます。
・VPN越しに特定PCが動画ファイルを利用した結果、特定ユーザーの特定ファイルアクセス時にNASのCPUが高負荷の時間が増加した。
・RPAを利用した結果、不調時間が多発するようになった。
・無線機器のエラーパケットが不自然に多い。
　共通した事象が、次工程である意思決定に結び付く情報となります。

Decide（意思決定）
　この工程では逐次投入ではなく最大投入が望ましいとされます。
　例えば、状況判断において、NASに明確にエラーは出ていないが、機器自身に問題がありそう、と判断した場合、再起動が選択肢として勘案されます。しかし、手段として選択するのは再起動するならついでにファームアップを実施する（結果的に再起動もする）方策が望ましいです。
　これは、状況は常に変化すること、特に顧客感情という変数は常に悪化していることから、根本原因を探る精緻なトライアンドエラーは無駄な手数を増やすだけとも言えるからです。
　他には、RPAやバックアップといった特定のPCの操作が問題ありそう、と判断したなら、どのように停止するか、その影響はどのようなものかも勘案します。

Act（行動）
　前工程で決定した方策の実行段階です。
　この段階では、方策が実行されるため、実行環境において影響が大きいことに注意をすべきです。
　仮説の検証のフェーズとなりますが、次回のループにおけるデータともなります。この仮説がクリティカルに改善しない場合でも、その影響が多少なりあることも意識し、直った直っていない、という単純な判断基準ではなく、設定した改善基準において、どのような影響があったかを観察できるようにしておくことが重要です。

　以上のように、OODAループはおおまかな流れとして、データ収集⇒情報化⇒仮説⇒検証を繰り返すフレームワークとなります。二回目のループでは、一回目に検討した仮説はなくなるため、打つ手が限られてくることになります。
　一番重要なのは、二回目以降もループは回る点です。回数を重ねることは打つ手が限られてくることになりますが、打開策なしではないと捉えることが最も重要です。
　視点を変える、例えば事務所内（ローカル内）のネットワークから外部ネットワークに広げたり、あるいは利用者のパーソナリティのプロファイルも必要になる場合もあります。
　自身が実施した方策もまた、次ループのObserve（観察）の対象となります。状態をらせん状に繰り広げていくような思考の様式をOODAループは実行できます。
　
　OODAループは、適時・適切な対応を要請されるシビアな現場、また何度対応しても改善しない、本対応を含む高難易度の障害対応において非常に有効なフレームワークとなります。
　それは、徒労に終わる手戻りではありません。
　ともすれば学習性無力感が引き起こされるような状況でも、思考停止で留まるのではなく、勇気を持って、さらに進んで対応する一助になると思われます。
　以上となります。