現行踏襲の更改案件を始める前に考えるべきこと
現行踏襲の危険性については昔から指摘されているようですが、実際にインフラ運用の現場で更改案件PMOを経験して身に染みて感じたので、どのようにして現行踏襲プロジェクトが発生するのか、沼にはまらないためには何を考えればよいのかを書きます。
現行踏襲の更改案件で何が起こるか
更改案件は、現在動いているシステムの何らかの要素がそのままでは運用が続けられない状態になることで始まります。例えば、OSのサポート期限が切れた、ミドルウェア・ソフトウェアがEOSLを迎えた、トランザクションが増えあるバッチ処理が後続処理開始までに終わらなくなった、など。
この事実が発覚すると、更改案件が立ち上がり、要件定義が行われます。この際に出てくるのが、「現行踏襲」です。例えばOSのサポート期限が切れたことがきっかけで案件が始まったときの要件定義として、「〇〇システムのサーバのOSを最新バージョンにアップデートする。リソースや導入ミドルウェア、OS設定は現行踏襲とする」というようなことが書かれます。
プロジェクトが始まると、現行踏襲を行うため、まずは現行の調査を行います。ここで、現行の設計書・パラメータシートが最新化されていない（そもそも誰もどこにあるか知らない）ことが発覚します。また、現行の明確な運用者が存在しない（誰にも運用されておらず無人化している）ことが発覚します。（参考↓）
ようやく「現行」が明らかになってくると、今度は現行構築時の欠陥が見えてきます。開発・ステージング環境のサーバリソースが現場の判断で削られて構築されている、障害発生時の運用フローが定義されていない、など。これはメンバーによってエスカレーションされるか、テクニカルレビュー、設計レビュー、などのレビューのタイミングでツッコミを受けることで発覚します。「障害発生時の運用フローは？」「なんでWindowsなの？RHELの仮想サーバなら追加のライセンスいらないよね？」「ハードウェアリソースの根拠は？」
当然これらに対応する工数は積まれていないため、結果としてプロジェクトは設計フェーズに突き返され延伸するか、発覚した問題たちを申し送り事項ということにして、何とか構築しリリースするしかありません。
上記はあくまで私の経験にすぎませんが、実際に多くの現場で同じようなことが起こっているはずです。ここからは案件開始前にどんなことを考えるべきだったのかを反省とともに振り返ります。
考えるべきこと そもそも現行って何？
その「現行」はどこかに文書化されているでしょうか。初期構築時にSIerから納品された設計書・パラメータシートが化石化していないでしょうか。先月の障害で緊急でミドルウェアをバージョンアップしたこと、ネットワーク更改によってIPアドレスが変更されたことはドキュメントに反映されているでしょうか。私がかかわった案件では、現行設計書は存在しましたが、その後の現地調査によって、実際に動いているサーバと設計書には乖離があることが発覚し、結局リバースで再度設計書を修正することになりました。「現行」が何を指すかを誰も明確に説明できない、または現行調査のための十分な工数が積まれていない案件は危険であると言えます。
考えるべきこと その現行って本当に踏襲していいの？
現行が明らかになったとして、それはそのまま踏襲すべきものでしょうか。行の時点で設計が設計が甘い箇所がないでしょうか。当時と比べて求められるセキュリティレベルが上がっていないでしょうか。前述の通り、更改案件は、現在動いているシステムの何らかの要素がそのままでは運用が続けられない状態になることで始まりますが、そのきっけかとなった要素以外もシステムが動き続ける間に変化しています。何年も動いているシステムならなおさら、現行構築時点の要件が今でも変わらない要素のほうが少ないでしょう。これらを見逃して案件を始めてしまうと、案件開始後に追加要件が次々と出てきてしまい、スケジュール内に対応できなくなります。
なぜ現行踏襲の更改案件が横行するか
現行踏襲は局所最適な戦略だと言えます。まず、更改案件は当たり前を維持するための活動であり、単なるコストとして捉えらることが多いです。そのため、短期的な視点で見れば、きっかけとなった要素だけを修正してそのまま動き続けるのであれば、それが一番好ましいのです。プロジェクトリーダ・マネージャとしても、早くコストをかけずに終わらせ、自身の評価に繋がる重要な案件に時間を使いたいのです。そのため、長期的な視点で考え、きちんとシステムを設計し直そうという意識が働きにくいといえます。
また、現行踏襲は案件を受注するSIerにとってもメリットがあります。SIerは案件受注前に可能な限り不確実性を減らしておきたいと考えます。こうしたSIerにとって、要件に書かれた「現行踏襲」は現行調査や設計見直しに対する不確実性から目をつむる格好の免罪符なのです。案件開始後に現行踏襲の是非に対してツッコミを受けても、発注側の責任にすることができます。また、仮に炎上・延伸したとしても、追加費用をもらってプロジェクトを進めればよいだけで、痛みはありません。その案件だけの短期的な視点で見れば、SIerとしては現行踏襲の危険性を理解していても、それを指摘するメリットがないのです。
おわりに
現行踏襲は局所最適な戦略ではありますが、全体的、長期的な最適にはならないと思います。プロジェクトを立ち上げる側は更改をコストではなく投資と捉え今後の何年もの運用に耐えられるものを作り直す気持ちで始めるべきですし、受注するSIerはあるべき方向を示し長期的な信頼関係を築くことを目指すべきだと思います。
この記事を書きながら調べていたところ、何年も前から多くの人が同じことを指摘をしていました。多くの人が現行踏襲の危険性を知って、そこに巻き込まれ病んでいく現場の人が減ることを願います。
この記事が気に入ったらサポートをしてみませんか？