運用にノウハウを引き継げ - 大森久永のリーダーの流儀：ITpro（情報元のブックマーク数）
開発プロジェクトから運用プロジェクトへの引き継ぎって、結構大変ですよね。。。
ところが、開発プロジェクトを率いるリーダーにとって、運用チームへのノウハウの引き継ぎは極めて難しい。時間がない中で障害の種類を洗い出し、対策を検討する必要がある。障害が発生しないように品質を高めてきた開発チームにとって、障害を想定するという自己矛盾さえある。運用チームが迷わないようにドキュメントを整備するのも大変だ。そもそも開発チームは他の作業に対して受け身であり、無関心になりやすい。今回は、そんな状況に対するルールである「運用にノウハウを引き継げ」について紹介しよう。
運用にノウハウを引き継げ | 日経 xTECH（クロステック）
そうか、作る側は仕様に従って正しく作ったとしても、連携先がある場合、そっちのバグがろう呈するという可能性もあるのか！
その数週間後、いよいよシステムが稼働した。ところが、稼働してすぐにシステム障害が発生。業務をそれ以上進めることができなくなった。
運用にノウハウを引き継げ | 日経 xTECH（クロステック）
筆者ら残ったメンバーが原因を調べると、新システムと別のシステムを連携させる処理でトラブルが発生していた。筆者は急いで両方のシステムを運用するチームに原因究明と復旧を依頼した。しかし、運用チームには新システムで収集したログを分析し、原因を突き止める力がなかった。連携先システムについても理解が乏しかった。
復旧できない。筆者らは、仕様書という仕様書を引っ張り出して原因究明に当たった。しかし、他システムとの連携部分に関する記述はほとんど見当たらない。現場で場当たり的な開発を進めた結果だろう。仮説と検証の繰り返しで、手探りの原因究明となった。
既に別のプロジェクトに参加している旧メンバーにも協力を求めた。その結果、原因は筆者らが開発したシステムではなく、連携先のシステムにあることが分かった。その後、連携先のシステムを担当した開発会社に連絡し、バグを修正してもらった。
