運用にノウハウを引き継げ

　開発と運用のスキマを埋める―。このことが大事なのは、ITエンジニアの皆さんなら分かるはず。開発したシステムについては、開発に携わった当事者である開発チームが一番よく理解している。その開発チームが責任を持って、運用チームに対する新システムの引き継ぎをしないと、運用後に問題が発生する可能性が高くなる。

　ところが、開発プロジェクトを率いるリーダーにとって、運用チームへのノウハウの引き継ぎは極めて難しい。時間がない中で障害の種類を洗い出し、対策を検討する必要がある。障害が発生しないように品質を高めてきた開発チームにとって、障害を想定するという自己矛盾さえある。運用チームが迷わないようにドキュメントを整備するのも大変だ。そもそも開発チームは他の作業に対して受け身であり、無関心になりやすい。今回は、そんな状況に対するルールである「運用にノウハウを引き継げ」について紹介しよう。

障害が発生するも運用チームは対応できず

　運用チームへの引き継ぎで難しいのは、どこまでやればよいのかである。システムの各機能や操作方法まで説明していたらきりがない。明確な答えはないが、筆者は「障害への準備」だと考えている。システムの停止は業務の停止に直結する。だからこそ、障害への対策を開発チームがどこまで主体的に考え、それを運用チームに引き継げるかが大きなテーマとなる。

　過去の例を挙げよう。ある開発プロジェクトにおいて、利用者が中心となるユーザーテストが始まっていた。このシステムは、開発期間中とても忙しく、メンバーらはひとまず自分たちの作業を終えたことで安心していた。システムの品質に自信も持っていた。

　ユーザーテスト中の利用者からの問い合わせもなかった。筆者らは、リリースに向けた引き継ぎに着手。といっても、プロジェクトの終盤は多くのメンバーがいなくなるもの。限られたメンバーで、バックアップやシステムの停止/起動の方法など、最低限の内容を短時間で引き継いだ。

　その数週間後、いよいよシステムが稼働した。ところが、稼働してすぐにシステム障害が発生。業務をそれ以上進めることができなくなった。

　筆者ら残ったメンバーが原因を調べると、新システムと別のシステムを連携させる処理でトラブルが発生していた。筆者は急いで両方のシステムを運用するチームに原因究明と復旧を依頼した。しかし、運用チームには新システムで収集したログを分析し、原因を突き止める力がなかった。連携先システムについても理解が乏しかった。

　復旧できない。筆者らは、仕様書という仕様書を引っ張り出して原因究明に当たった。しかし、他システムとの連携部分に関する記述はほとんど見当たらない。現場で場当たり的な開発を進めた結果だろう。仮説と検証の繰り返しで、手探りの原因究明となった。

　既に別のプロジェクトに参加している旧メンバーにも協力を求めた。その結果、原因は筆者らが開発したシステムではなく、連携先のシステムにあることが分かった。その後、連携先のシステムを担当した開発会社に連絡し、バグを修正してもらった。

ノウハウ継承できず 「訓練不足」が露呈

　筆者らが開発したシステムには問題はなかった。だが、結果的にシステムの利用者に迷惑をかけてしまった。今回の反省すべき点は、障害が発生した場合に備えた準備、特に訓練ができていなかったことにある。運用フェーズに入れば、体制は大きく変わる。それまでに開発メンバーに蓄積されたノウハウを、残る運用チームに継承しなくてはならなかった。

　具体的には、障害が発生したときに、どの部分の何を確認するかを示すドキュメントを整備すべきだった。今回の例では、想定する障害には他のシステムとの連携部分を含める必要がある。そしてプロジェクトの後半では、障害を想定した定期的な訓練や、日頃の作業の中での障害テストを実施すべきだった。ログ解析を含んだ障害訓練、他のシステムと連携させたテストなどだ。

　こうした訓練を、開発チームは担当外と考えやすい。だが、これを人ごとと考えてはいけない。障害対応を中心とした運用ノウハウを、開発チームが責任を持って引き継がなければ、結局、システム障害は止められない。