「運用設計は開発作業が終わってから」では遅い？
例えばIaCの導入プロジェクトを例に挙げると、プロジェクト開始時にデプロイ後の運用を想定した検討を疎かにしていると、やがては本来の利用目的よりIaCの導入自体が目的化してしまい、いつの間にか「単純なデプロイ作業だけでなく、細かなエラー対応や複雑なコード解析まですべてをIaCで網羅しなければならない」と誰もが思い込むようになる。そうやって最終的に出来上がった仕組みは極めて複雑かつ属人性の高いものになり、結局徐々に使われなくなっていく。
こうした事態を防ぐには、プロジェクト開始時に運用設計書をきちんと作成し、IaCの導入で目指すことや運用の責任範囲などを「共通ゴール」としてあらかじめ定めるとともに、その具体的な「開発方法」と「運用方法」を定めて開発・運用双方の共通認識としてしっかり共有しておく。これにより「せっかく入れたのに利用されないIaC」が生まれることを阻止できる。
またシステムを新たに追加開発するようなケースでは、あらかじめ運用設計を行っていないとシステムを追加するごとに新たな運用プロセスが生み出されることになり、システムの数が増えるに従って運用の複雑化や属人化も増していってしまう。そこであらかじめ全社共通の運用ポリシーを策定し、システムを追加する際にはそのポリシーに沿った運用設計を行うことで、システムがどれだけ増えても標準化されたプロセスに沿って効率的に運用できるようになる。
加えて最近では、オンプレミスシステムのクラウド移行に伴い運用設計を見直すケースも増えているという。
「クラウドに移行した後も『運用設計は現行踏襲で問題ない』と考えている方が意外と多いようですが、これは絶対にお勧めできません。オンプレミスとクラウドはプラットフォームの特質が根本的に異なるため、その差異を埋めるために運用設計もあらためて検討し直す必要があります」
なお運用設計と聞くと、これまでは「運用部門が利用するもの」という先入観から「開発作業が終わってから検討するもの」というイメージが強かったかもしれない。しかしこれまで見てきたように、本来の目的は開発と運用とで共通の地図を共有するためのものであり、従って開発作業が始まる前のプロジェクト初期段階で着手するべきものだと三好氏は強調する。
「開発が始まる前に運用設計に着手し、プロジェクトを通じて開発と運用が共通の地図を共有することで両者が協力し合う気運や文化が生まれ、ひいてはIaCやDevOpsといった取り組みも初めて実効性を帯びるようになります。こうした取り組みを全社で進めることで大幅なコスト削減が可能になり、最終的には企業の成長そのものにつながることを、より多くの方々に理解していただければ幸いです」
運用設計で"差"がつくクラウド化の本当のコストとは/運用設計チェックリスト付き
クラウド移行を成功に導くのは容易ではなく、コストダウンや運用生産性の向上を見込んで取り組んだにも関わらず、結果的には情報システム部門の稼働やコストを圧迫してしまうことも少なくありません。
インフォメーション・ディベロプメントの資料では、クラウド移行におけるよくある失敗事例を紹介しながら、運用設計の重要性と、クラウド移行によってコスト・手間を減らし、情報システム部門の生産性と企業のIT競争力を向上するための対策を解説しています。
