はじめに

こんにちは。株式会社SHIFTで日々ITプロジェクトに参画して楽しく仕事をしております、小島です！

今回は私が複数のEOL更改案件(サポート終了期限「End of Life」に伴うシステム更改案件)にてPMOとして担当した時の学びについてご紹介します！

よく聞く「現行踏襲」という甘い言葉

システムの要件定義や設計を進める際、よく「現行踏襲」という言葉を耳にしませんか？

既存の仕様をそのまま引き継ぐことで工数も把握しやすく、リスクも抑えられる場合があり、特にEOL更改においては既存のままで良いよね？とよく使われがちなこの言葉ですが、実はそこに大きな落とし穴が潜んでいるかもしれません。

今回は、ある通信テストで起きたエラーとそこから発覚した根本的な問題を例として、現行踏襲の危うさと、再発防止のためのポイントについて解説していきます！

きっかけはある通信エラーから

あるシステムで通信テストを行ったところ、エラーが発生しました。
そのため調査を行ったところ、デフォルトであるポートを使用していたことが判明しました。

そのポートは脆弱性が高いため、現在ではセキュリティ面から見ると問題のあるポートでした。
では、なぜそのポートが使われ続けていたのか？

原因を深堀してみると、これまで要件定義や設計局面で「現行踏襲」として過去の仕様を引き継いでいたことが原因であったことが分かったのです。

つまり、「昔からこのままで問題なかった」という認識でそのままにしており、昨今のセキュリティ面での改善から漏れてしまっていたという事だったのです。

過去に問題なかった＝現在も問題ないとは限らない

本件については、今後のEOL更改案件で再発しないようにするため、要件定義や設計段階では現行踏襲とする前に特にセキュリティ面で問題がないのか等、確認するようチェックシートの改善を行い対処することに決まりました。

日々システムに対する考え方は変わっていきます。
今回はセキュリティ面での話でしたが、他にもシステムの効率化等で現行踏襲ではいけない場合もあることでしょう。

また、「現行踏襲」という言葉だけが開発チーム内に浸透し、その部分を深く調べることなくスルーされていくようになってしまうことも危険です。
「前からこれで動いていた」という認識だけが優先され、潜在的な不具合や脆弱性を見逃してしまう恐れもあります。

理由が不明確なまま放置していないか？

そのため、「現行踏襲」と判断した項目こそ、あえて疑問を投げかけるべきポイントとも言えます。

なぜ現行踏襲にしたんだっけ？妥当性はどういうものだった？となぜなぜ分析をしていくことが大事だと分かります。
もし、現行踏襲の理由が不明確なままプロジェクトが進んでしまうと、いざ問題が起きた際に根本原因が分からなくなる恐れがあります。
また、担当者交代時の引き継ぎをした際にも大きな影響が出てしまいます。

そのため今回の事例のように、局面ごとにチェックリストなどを設け、そこで現行踏襲についても妥当性が説明できるようにするよう気付きを与えることも大事でしょう。

レビュー体制は充分だったか？

必ずしも現行踏襲＝悪いことではありませんが、今回のような問題が起きないためにも、現行踏襲とする理由もチェックできるように、要件定義書や設計書のレビュー時点から体制を整えておく必要があります。

レビュー担当者が現行との変化点だけでなく、現行の流用部分についても「本当にそのままでよかったのだろうか？」と疑問を持ちながらレビュを行えるようにする意識が必要です。

また、レビュー時には直近で社内で問題に上がっていたセキュリティ関連の脆弱性の話や、システム上の懸念点などがなかったか、それが今回のプロジェクトに関わらないか？等、常にアンテナを張り巡らせて考える必要があります。

テスト段階でカバーできなかったか？

万が一要件定義や設計段階で見逃してしまったとしても、後続のテストで発覚できる場合もあります。

そのため、テストケースやテスト計画書作成時にも、現行との変化点におけるテスト観点だけでなく、改めて現行踏襲としている部分についてもテストすべきかどうか見直してみることも大事と言えます。

まとめ

過去に決められた設計をそのまま現行踏襲すると、今回のようにセキュリティの問題を抱えたシステムを運用し続けるリスクが高まってしまいます。

要件定義や設計段階で「本当にこれでいいのか？」と疑いを持つ姿勢が、プロジェクト成功への大きなカギとなります。

• 現行踏襲とした理由について、明確に言えるのか？

• 要件定義書や設計書のレビュー時、現行との変化点だけに注目しすぎていないか？

• テスト計画は充分に練られているのか？

これらのような意識づけをするだけでも、よりプロジェクトの成功率が上がると言えるでしょう。

プロジェクトは常に工数やスケジュールに追われるため、少しでも現行踏襲で済むならそれに越したことはない、とどうしても思ってしまう部分もあります。

しかし、今回の事例のように、現行踏襲にしていた背景を見逃して問題が発生してしまうとかえってそのリカバリの工数を割くことになり、スケジュールも切迫してしまいます。

「急いては事を仕損じる」とありますが、現行踏襲にしようとする部分こそ、落ち着いてしっかりと確認する工程が必要なんですね。

✅SHIFTへのお問合せはお気軽に

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/

PHOTO：UnsplashのChristian Wiediger