本連載「企業セキュリティの歩き方」では、セキュリティ業界を取り巻く現状や課題、問題点をひもときながら、サイバーセキュリティを向上させていくための視点やヒントを提示する。
「運用でカバー」は開発部門でも他人事ではなかった
前回は、「運用でカバー」という魔法の言葉が生まれた理由として、この言葉がIT業界の開発至上主義的な伝統に基づく構造的な問題であることを説明した。今回は、その「運用でカバー」するという構造が、開発部門から運用部門への単純な押し付け合いではないことについて記したい。
「運用でカバー」するという状況は、システム開発部門が一方的な加害者であり、システム運用部門が一方的な被害者のように映るかもしれない。しかし、実際はそのような単純な構図ではなく、むしろ場合によってはシステム開発者の方が被害者という面も少なからずある。しかも、”瞬間最大風速”的な被害はシステム開発部門の方が大きい。その結果として発生するのが、土日休みの返上、家に帰ることも満足にできない過酷な長時間労働である。このようなシステム開発プロジェクトは、一般に「デスマーチ（プロジェクト）」と言われる。
デスマーチとは、元々は戦争時の捕虜の扱いを表す言葉だ。「敵である捕虜は死亡しても構わない」という前提に立った、健康維持などを省みない捕虜を連れての無慈悲な行軍（死の行軍）を指している。自社の重要なメンバー（人財などと呼ぶこともある）を、このような捕虜の扱いに例えるとは、なんともひどい話である。しかしながら、このような過酷な環境のプロジェクトは決して特殊な例ではない。もちろん、現在ではそのような環境が当然のように見なされていた10～20年前と異なり、絶対数はかなり減っている。それでも根絶された訳ではなく、システムの納品期限が重なる年度末などでは特にめずらしくない。
プロジェクトでデスマーチが発生すると、「スケジュールが足りない」「工数が足りない」「人手が足りない」というように、さまざまなリソースが不足する。そして、デスマーチにおいて最も大きなインパクトは、要求仕様の度重なる変更だ。これによって、何度も前提条件が覆される。その結果、作業が完成に近づいているのかも分からないような状況に陥り、先の見えない真っ暗闇の中で過酷な長時間労働を続けることとなる。
このようなデスマーチが発生する原因には、実は「運用でカバー」と表現されるものと同じものが根底にある。「運用でカバー」は、本来なら開発フェーズで定義し、対処をしておかないといけない仕様面での不備を、システムの利用が開始された運用フェーズに先送りすることで発生する。これによって後工程の運用現場が、想定外の例外処理に対処しなければならず疲弊してしまうのだ。
デスマーチは、さらに上位の要件定義（および基本設計フェーズ）での不備が、開発現場に押し付けられる構造である。実は開発部門も、本来は要件定義フェーズでやるべきだった不備を詳細設計や開発フェーズの「実装でカバー」しているのだ。つまり、開発部門は一方的な加害者ではなく充分に被害者と言われてよい状況であり、そこでもカバーし切れないものが、「運用でカバー」をしなければならない状況に陥っただけというケースも多い。結局、要件定義フェーズで機能や性能要件のみではなく、運用フェーズに負担をかけないことなどを考慮できない場合、その問題の先送りを繰り返す多層構造になってしまう。
多層構造でのカバー
