【第５回】社内インフラエンジニアのために（見直し）

前回：【第４回】社内インフラエンジニアのために（安定化）

お疲れ様です。
しらせです。

『社内インフラエンジニアのために』
第5回目となる今回は「見直し」についてです。

第4回で紹介した安定化でライフサイクルについて触れています。
ライフサイクルの終盤に差し掛かったシステムが、ヒアリングを通して当初の役割を果たしていないと判断されれば要件定義を１から実施して全く別のものに変えていくことも検討しなければなりません。

所謂「持続的イノベーション」とも呼ばれたりしますが、今でも十分効果が出ている場合には継続して価値を提供できるように同様の要件を満たせる新しいシステムへの乗り換え（リプレース）を検討します。

もくじ

利用実績・傾向把握

まずは今どうなっているかを正しく認識するところから始めます。
前回紹介した「モニタリング」や「ヒアリング」の結果をベースにして、リリース当初から利用実績や傾向を分析してどれくらいズレているのかを把握します。

今後の方針検討の材料にもなりますので、これまでに集めたモニタリングやヒアリングのデータは報告したから・分かったからといって捨ててしまわないようにしましょう。
これまでに蓄積してきた情報がここで役に立ちます！

例えば極端な例ですが以下のような考察をよくやっています。

1. 利用率はモニタリング結果からも伸びており、ヒアリングした結果も良好。
2. 最初の頃の要件に基づく利用はすでになく、全く別の使われ方をしている。
3. リリース当初は毎月数千ユーザーの利用があったが毎月数％ずつ減っており今は数える程しか使っていない。

１の例は、利用者が想定通りの利用の範囲で満足して使っており企画時から安定して稼働している状況です。
利便性や生産性は度外視に、法律や会社のポリシーで決められているような要件で利用されている場合はこれになりがちです。

２の例は、業務が変化して提供しているシステムの利用形態が変わってきている状況です。
計画時当初の要件からもはみ出していることが多く、まったく別のソリューションへの切り替えが有効である場合があります。

３の例は、ヒアリングの内容の以前の問題で、既に利用がなくなってきている状況です。
もはや利用されるケースが稀であれば、撤退（クローズ）も視野に検討します。

方針検討

前項の例を参考にして、次のライフサイクルにおける方針として「リプレース・切り替え・撤退」３つで検討していきます。
これがすべてではありませんが、結局は続けるのかやめるのかを決めなければいけません。
私がこの辺りを考える際には以下のようなイメージを常に頭に入れています。

【１：より安く、より安定して、より使いやすいシステムへリプレース】

• 実現できている機能はそのままで、当初の要件に沿って最新のシステムに入れ替えていきます。
• 実績をベースにしたサイジングや運用上の課題などを考慮できるとより良いシステムになります。
• 今のシステムよりも大きな規模で多機能になる事が多く、コスト面で安くなることは滅多にないのでメリットを伝えることが重要になります。

【２：新たな要件を充足できる新しいソリューションへの切り替え】

• 当初の要件を１から見直して新たな要件をベースに別のソリューションに切り替えていきます。
• 例えばオンプレミスからクラウドサービスへの移行など、環境が大きく変わることもあります。
• 切り替えに当たっては長い年月がかかることもあるため、移行計画が重要になります。
  ※次項「ソリューションの調査/検証（PoC）」で詳説。

【３：撤退（クローズ）】

• 業務がなくなったり他のツールへ分散したなどの理由で利用率が極端に下がった場合にはシステムをクローズして撤退します。
• まだ利用している人がいる場合は、個別で代案を用意するなどケアが必要になります。
• 撤退する際には撤退に至った経緯や判断したポイントを伝えるために、これまでのモニタリングやヒアリング内容を添えると納得が得られやすくなります。
• 今動いているシステムはいずれ停止する必要があるという点では項目１も２も撤退を含みます。

ソリューションの調査/検証（PoC）

前項２のように今の環境では要件を満たせない場合には別のソリューションへ切り替えを検討します。

ライフサイクルの終盤ぎりぎりで調査や検証を開始しても現環境のクローズに間に合いません。
あらかじめロードマップに新しいソリューションの調査検証時期をプロットしておきます。

調査検証結果が有用である場合は、計画のフェーズに戻って企画書からインフラ構築の流れが始まります。

見直しのフェーズは次のインフラ全体の方向性を左右します。
余裕を持って計画を立てていくことが重要です。

最近の傾向では「ちょっとだけ検証してみたい。」「どんなものなのかを触って確かめてみたい。」という漠然とした状態の検証やPoCは拒否されるケースが多い様子で、予算・導入時期・規模感・用途など細かく求められることも珍しくありません。
もちろん、メーカーも契約してもらい利益につなげることが目的ですので、検証環境をお借りする場合は検証の目的と検証項目や採用可否の判断基準などは揃えておき、終了後にはフィードバックをすることが重要です。

有用な製品・サービスであれば予算が許す範囲でスモールスタートで契約して試しに使ってしまう方が簡単かもしれません。
エンジニア視点としては「とにかく触らせろ！」「使わないとわからん！」という気持ちになりますが、対会社として見ればちゃんと説明責任を果たさないといけませんからね。

PoCに関しては以下の情報をよく見ていました。
特に、一番上の「PoC無茶ぶりつらい「PoC（概念検証）プロセス」の進め方とは？」はとても参考になります笑

（参考）

• PoC無茶ぶりつらい「PoC（概念検証）プロセス」の進め方とは？
• PoCの失敗・疲れを簡単に回避するチェックリスト【具体的手順】 - ITエンジニア ライフハック
• 4回目の実証はPoC4かPoC死か - note

見直しについては以上です。
次回は本シリーズ最後「クローズ」に関してです。

以上
おつかれさまでした。