目次

運用設計の不在が生む悲劇

｢開発｣と｢運用｣が分断。そして、運用設計が抜け落ちる

運用をデザインする。そのための6つのポイント

開発と運用の壁。これがさまざまな問題を生む。開発担当者は運用を考えずにシステムをリリースし、足りない部分は｢運用でカバー｣の一言で運用担当者にナントカさせようとする。そして、たいてい火を吹く。なぜなら、リリース間際に対処しようとしても付け焼き刃の属人的な対応しかできないからだ。この状況、運用も開発も、何よりシステムを使う顧客やユーザも幸せにしない。運用をデザインしよう。この連載では、運用を主体的にデザインし、価値あるITサービスを提供できる人材になるための視点や行動を考えます。

1.運用設計の不在が生む悲劇

運用を考慮せずにリリースして、火を吹くサービス。ITに限った話ではありません。

｢新しい飲食店。オープンしたは良いけれど、駐車場待ちの長蛇のクルマ列。お客さんからも近隣住民からもクレームの嵐｣
｢新たにリリースした会員サービス。解約手続きが不明で、お客さんもオペレーターも困惑｣
｢百貨店の会員情報。結婚して姓が変わったのだが、手続きが定められていなくて変更不能。新規会員登録扱い。せっかくためたポイントも失効｣
｢電子マネーサービス。各種手続きは、すべて紙ベースで非効率極まりなし｣

このような、運用を考慮していないが故のクレーム、トラブル、非効率は世の中に散見されます。
なぜこのような悲劇がうまれるのか？
ひとえに、｢開発｣と｢運用｣の分断にあると考えることができます。

2.｢開発｣と｢運用｣が分断。そして、運用設計が抜け落ちる

この図を見てください。（クリックして拡大）

いわゆる、ウォーターフォール型における一般的な開発と運用の流れと責任範囲をイメージ図にしてみました。先のような非ITの業務でたとえるなら｢開発｣｢運用｣を｢立ち上げ｣｢運営｣と読み替えることができるかもしれませんね。

開発担当者は構想、要件定義などの上流工程を担います。その際、PMBOK（R)を代表とするフレームワークに沿ってプロジェクトマネジメントが行われるでしょう。運用はいわば後工程。ITIL（R)などのITサービスマネジメントのフレームワークに沿って日々の運用業務を遂行します。
運用設計は、この2つを橋渡しする大事なフェーズです。
さて、ここで皆さんに質問です。あなたのゲンバでは運用設計は運用／開発のいずれが担当するか決まっていますか？ 運用設計を行うためのフレームワークはありますか？

｢どちらがやるか、ケースバイケースです｣
｢一応、開発チームが設計書らしきものを作ってくれますが、抜け漏れだらけです｣
｢いつもリリース間際になって、『運用でカバーして』って言われて開発から押し付けられます｣
｢運用項目は、経験者の勘で決めていますね｣

率直に言って、運用設計はグレーゾーンになりやすい。
開発と運用のはざまにあって、役割分担が決められていなかったり、無理やり運用に押し付けられたり、挙げ句の果てにはたまたま気づいた人による｢球拾い｣レベルでしか行われない。当然、組織のナレッジとしてやり方が共有されない。加えて、PMBOK(R)やITIL(R)のようなマネジメントフレームワークでも十分にカバーされておらず、設計項目や観点が属人的になりがちな弱点があります。これでは、良いサービスは作れないし守れません。

3.運用をデザインする。そのための6つのポイント

とかく行き当たりばったりになりがちな運用設計。そろそろ、ノウハウ化すべき時ではないでしょうか？
本連載では運用をデザインするための観点や知見を私たちなりに体系化していきたいと考えます。

ポイントは6つです。（クリックして拡大）

この6つの観点を持って行動できる人材は、運用を主体的にデザインすることができます。かつ、ITサービスおよび運用組織そのものの価値を高めることができます。
次回、（1）業務運用／システム運用定義を解説します。

運用をデザインできる人材は、これからの時代、間違いなく価値ある人材として活躍の場が広がります。

目指せ、運用デザイナー！