業務システムの開発と、そのシステム運用について２年ほど携わった経験を振り返っての所感。きちんとウラを取ったものではなく、個人的な考えをまとめたドラフトなので、間違っているかもしれない。

なんで、こんな事を考えるようになったかと言うと、本物のミッションクリティカルなシステムについて、たまたま開発と運用の両方をPLとして主管する期間があり、いわゆる想定外の事象（考慮漏れ）と、人為ミスを繰り返してきた過程で、これは実は思想的な問題があるのではないかな、と思った次第。レベル分けすると、以下のような壁で分断されているように思うところである。

想定外の事象　>>>(あり得ない壁)>>> 想定内の稀な事象(一部手運用だが検証済の手順有り) >>>(コストの壁)>>> 想定内の事象(システムが自動リカバリする) >>>(運用と開発の思想の壁)>>> 要求された開発要件にあるエラー処理

※(2011/12/31追記)
ミッションクリティカルにもいろいろあって、止まると自社の業務が停止して、株価に影響が出るとか、最悪つぶれるというものも該当すると思うけれど、ここで言っているものとは違う。社会インフラの一部としての情報システムが停止した場合、社会生活に大きなインパクトがあり、そういった分野では、出来る・出来ないが問題ではなく、常に低リスクを選択しなければならない、というところです。


業務システム開発と運用とは本質的に思想が異なる件についての考察（ドラフト 2011.12.30）

【システム開発】

（思想）
開発は「プロジェクト」つまり、リリース・納品という明確なゴールが存在する。

（基本形）
開発要件を期限内に満たしてリリースするために最善を尽くす。
最善は尽くすけれども、バグを0にすることが不可能であるということと同様に、開発の途上、リリース後に想定外の事象が出るのは当然のこととして考えている。


（非機能要件）
明確に要求仕様で提示されれば、それを満たす要件定義を行うが、要求が無いところに要件はなるべく増やさない（∵やることを増やしたくないので）。

（商用機の取り扱い）
運用中は基本的にＮＧ、運用側の要請が無い限り開発は手出し無用。
ただし、停止を伴うような大規模リリースは開発サイドで主管する。




【システム運用】

（思想）
運用は「プロジェクト」ではなく、ゴールは存在しない。常に改善あるのみ。

（基本形）
安定運行が第一優先。
何事も問題を起こさないために何が出来るか、想定外を想定内に収めるためには何ができるかを考えている。
→そのためには、初めて実行するコマンド、手作業は絶対NG（どうしても必要なときにでも、必ず手順を明らかにして、検証を行った後に実施。）


（非機能要件）
安定運行のために、（レスポンス性能、データ保存期間、状態監視、障害時対応フローなどなど）非機能要件の洗い出しと設計（マニュアル化）を必要とする。開発が意識しない（≒やりたがらない）事項についても注意喚起を行う。



（商用機の取り扱い）
運行業務の主管として、運用作業手順に従った操作を行う。
人為ミス防止への取り組みは重要なテーマ。