開発プロジェクトと運用フェーズ　～　稼働後の炎上を起こさないために

「みずほ銀行システム統合、苦闘の19年史」は悲しい気持ちにさせます。
ブラックボックスから脱却し重厚長大な仕組みを疎結合で作り上げた新システムは、従来に比べて運用コストが低くスピード感を持って改修できるようになったと力強く書かれているのに、稼働後にシステム障害が多発したことで社長と頭取の引責辞任が決定してしまいました。
どんなプロジェクトでも本番稼働を無事に終えた開発PMは、やり遂げた思いでほっとしているはずです。みずほ銀行の件は、企業文化が大きく関係しているとはいえ、システムを完成させても運用のことを十分に考えていなければ稼働後に炎上してしまう良い題材になるでしょう。

１．運用コスト削減の呪縛

システム刷新のメリットに必ず上がるのが、運用コストの削減です。
ダウンサイジングという名目で刷新しても現行システムから機能数に変わりがなければ、運用コストが大きく下がるとは到底思えません。類似システムや重複機能が全く同じであれば集約によって減るかもしれませんが、微妙に違えば本数は減っても処理分岐が増えるだけなので、やはり運用コストが大きく下がるとは思えません。密結合を疎結合にしたところで全体的に見ればシステム規模に変わりがないにもかかわらず、劇的なコスト削減をシステム開発の計画時点で謳い、運用フェーズに入ったとたんに安堵とともに急激に体制を変えることは危険な行為です。
運用フェーズをリッチな体制で提案すると、開発時には「リスク対策はどうなっているのか？」と口うるさく言ってきたクライアントが、「自分で作ったシステムの品質に自信がないのか？」と言い出し、リスクを顧みずにコスト削減を全うしようとする姿勢には驚かされます。数年も前の開発計画時のコスト削減目標を何が何でも実現しようとする姿勢は立派ですが、これこそが呪縛です。
実績重視で新しいものには慎重な日本の大企業が、システム刷新においては新しくなった瞬間に慎重さよりもコスト削減を優先するのは謎でしかありません。

２．開発時に考えておく稼働後のこと３つ

開発体制から運用保守体制へどのようにシフトしていくか、これは結構な難題です。
みずほ銀行のシステム障害でも運用保守体制が薄かったことが問題視されていますが、人数もさることながら、開発担当者をどれだけ、いつまで維持しておくかは非常に悩ましいです。特に開発ベンダーから運用保守ベンダーに切り替わる場合は、調整も含めてなおさら難しくなります。
本番リリース後にどのような障害が発生するか予測はつきませんし、稼働後の改善要望もどれだけ挙がるかわかりません。瑕疵担保責任があるため開発ベンダーが運用のことを全く考えずに無責任にモノ作りをするとは考えにくいですが、稼働後の体制や進め方までを真剣に考えているかというと、それは疑問です。
プライムベンダーは管理だけを担い、モノ作りはサブコンの技術者が行う開発プロジェクトでは、中身に詳しい技術者が散散ばらばらになってしまうため稼働後の障害に即時対応することは困難です。また運用ベンダーの一部のキーパーソンが開発プロジェクトの終盤に参画して、システムの作りを完全に理解するというのも無理な話です。稼働後に炎上しないためには、開発PMが開発プロジェクト中に稼働後の体制や運用計画を考えておくべきです。

①候補者の選定
ウォーターフォール型のプロジェクトでは、開発工程をピークに徐々に要員数が減っていきます。要員計画の中で誰を終盤まで引っ張るか、ひいては稼働後いつまで維持するかを考えなければいけません。理想は技術力の高いフルスタックエンジニアですが、技術力がある人は単価も高く運用よりも新規開発を好む傾向があるため難しいです。稼働中のシステムに手を入れるので仕事が手堅く、フットワークよく動け、安定志向だけど向上心と伸び代のある若手が良いです。こんな人はまずいませんが、開発工程の要員ピーク時にキラリと光る候補人材を見つけ、打診しておくことが大切です。

②マルチプレイヤーの育成
フロントエンドの技術者を確保していても、バックエンドの障害が発生するかもしれないし、他システム連携機能の大幅な改修案件がくるかもしれません。改修のタイミングで必要なスキルを持つ技術者を探していてはタイムリーな対応は困難ですし、クリティカルな障害であれば収束どころか被害が拡大してしまいます。稼働後にどんな案件が来ても対応できるマルチプレイヤーを育てることと全ての領域を効率的にカバーできるフォーメーションを考えておくことは開発PMの仕事のひとつです。

③運用体制の仮想プラン
本番稼働後の障害発生数や改善要望の数を予測することは困難です。だからといっていつまでも出たとこ勝負では、運用コスト削減の見通しもつかず、そのうちプレッシャーに負けて有無を言わさず体制を縮小しないといけなくなってしまいます。そうならないために障害発生数や改善要望数の規模感によってどういった体制をとるか、稼働後のリッチな体制からケースに応じてスリム化していく仮想プランを稼働前にクライアントと握っておくことが必要です。

３．運用フェーズを円滑に進めるために

最近はチェンジリクエストという言葉をあまり聞かなくなりましたが、業界によっては今でも使っているのでしょうか。
さて、運用フェーズでは障害対応だけでなく、予算の関係でリリース後に先送りした要件や使っていく中で挙がった改善要望、関連システムの変更に伴う改修など継続的にシステムに手を入れていきます。これまでウォーターフォール型で進めてきたプロジェクトは、各工程をそれなりの期間で順序立てて進めてきたやり方から比較的短い期間で細かい案件を同時並行的に捌いていくやり方に変化します。改善要望の対応をしている最中に障害が発生すれば障害対応を優先的に差し込むという開発プロジェクトとは異なる難しさもあり、初期の運用フェーズには高度な推進力が求められます。

１．できれば契約は準委任で
改善要望の対応を行う場合、たいてい保守契約とは別に個別に契約を締結します。クライアントによっては、特に購買部門が厳しい企業ではいちいち請負契約を求めてきますが、優先度の高い案件がくれば差し替えて推進するといった柔軟な対応が求められるため請負契約では困難です。準委任契約にすると責任の所在が不明確になるから困ると言うクライアントとの攻防戦が始まってしまったら、タイムリーさと責任を天秤にかけて判断してもらうしかありません。一定数の改善要望は必ずあると想定して、可能であれば毎月固定の工数を保守契約に含めるか、準委任で別途契約を締結しておくやり方が合理的です。

２．マイナーチェンジサイクル
障害にはスピーディーな対応が求められますが、改善要望には多少の余裕はあります。とはいえ案件が上がってきた都度、見積りをして契約を締結して、必要に応じて技術者を追加していたら時間も手間もかかり非効率です。自動車やスマホなどの製品と同じようにモデルチェンジサイクルをある程度定めてしまうのが良いです。例えば、年4回3ヶ月単位にマイナーバージョンアップすると決めて、次のサイクルに入る前に案件リストから対象を絞って対応していく進め方が効率的です。

３．納期コントールが出来ない案件はしばらく断る
改善要望の中でも他システムの改修に伴う対応や新たな目玉施策の導入などは、リリース時期が明確に決められて納期をずらせない案件となります。
こういった案件を進めている時に大規模な障害が発生すると、ずらせない納期を死守するための案件推進と障害対応とを並行して共に全力で進めるといった苦しい事態になります。ある程度システムが安定稼働するまでは、納期コントールが出来ない改善要望は極力受けないと導入前にクライアントと握っておくことが出来たら幸いです。

４．まとめ

開発プロジェクトから運用フェーズへの切り替えは、画像が徐々に変化するアハ体験のように、あるいは操縦が上手な機長によるソフトランディングのように変化に気が付かないくらいがちょうど良いのかもしれません。
稼働後の炎上を無くすためには、クライアントは自らの呪縛を解き、開発ベンダーは稼働後のことを考える、双方の変化が必要だと思います。
みずほ銀行の件をきっかけに運用フェーズの重要性について、開発ベンダーとクライアント企業の理解が進むことを願いたいです。