大変だけどやりがいのあった運用時代

私がIT業界に入ったのは2006年のことでした。

特別やりたいこともなくこの業界に入ったので、なんとなくぼんやり「システムエンジニアってプログラムとか書くんだろうなー」と思っていたら、アサインされた案件はバリバリの運用案件でした。

当時は「Linux？ なにそれ？ 食べられるの？」という状態だったのですが、最初にアサインされた運用現場はほとんどの作業が自動化されていて、残業もなく人間関係もよく、聞いたらなんでも教えてもらえるし、新人エンジニアにとっては楽園のような場所でした。

しばらく楽園で過ごしたあと、PC管理を行っているチームに欠員が出たのでそこへ異動することになりました。そこはアサインされた人がどんどん辞めていくという噂の悪名高きチームでした。

このチームで本当に覚えておかなければならないルールは2つだけ。

• ルール1：絶対にミスをするな
• ルール2：絶対にルール1を忘れるな

アメリカの投資家ウォーレン・バフェットの名言のようなルールが制定されたチームで、私は6年間運用の厳しさを学びながら育ちました。PC管理はミスをすると即座にユーザー影響が出てしまうので、厳しい規律も仕方がないことでした。

• 作業は事前に確認しておく
• 関連するドキュメントは読んでおく
• 質問は聞く前にまとめておく
• 一度言われたことは必ず覚える

エンジニアとしての基本はこのチームで叩き込んでもらいました。

厳しいチームでしたが、一通り作業ができるようになってくると色々なことが目につくようになってきます。

• 目的が不明な作業が多い
• 準備のための準備資料作成が多い
• マクロを組んだらミスがなくなるのに手作業でコマンドを打っている作業がある

チーム内での地位と発言権を得てきた私は、それらの作業を廃止、効率化していきました。ミスを少なくして、やることをやってできるだけ早く帰る。それが当時の私のモチベーションでした。

PC管理の仕事はユーザーとやり取りが多く、すべてのユーザーとITシステムの窓口的な部署でもありました。責任も大きいですが、お客様から直接感謝されることも多く、厳しいながらもやりがいのある仕事でした。

後悔の残るシステム更改運用受け入れ担当時代

ある程度チームの稼働が落ち着いてきたころ、システム更改の運用受け入れを担当することになりました。

構築チームからポツリポツリと用途不明の手順書が五月雨で送りつ送りつけられてきます。手順書の総量がどれぐらいなのか。その手順書がいつ、何の目的で利用するのかの説明は一切ありません。当時の会話を思い出してみると……、

こちらが何を聞いても、一事が万事この調子です。その後、スケジュールに押し切られる形でシステムはリリースされ、現場は火の海となりました。

• 鳴りやまない監視アラーム……
• 対処方法のわからない障害……
• 使い道のわからない体裁だけ整った手順書の数々……
• 右往左往する運用メンバーと構築メンバー……

結局、運用が安定するまで半年以上の期間がかかりました。

その頃は「運用設計」という言葉も概念もまだ浸透しておらず、残業によるマンパワーで運用を安定稼働させるしか術はありませんでした。

（この時にこの本があったら、どれだけ指標になったかと今なら思います⁠）⁠。

運用を取り入れた設計構築へのチャレンジ

この経験から、運用が大変な理由の諸悪の根源はシステムリリース時にあると考え始めました。いま思えば、初めに入った楽園のような現場は、目的のはっきりした手順書しかなく、トラブル時の連絡先も明確でした。“⁠楽園システム⁠”の導入当時の話を聞いたところ、運用をやったことのある方がシステム設計をしたとの話でした。

「これは、システム構築の時から運用を考えておかないといけないのでは？」

私の目的は「やることをやってできるだけ早く帰る」ことから、「⁠運用を取り入れた設計構築をする」というものに変わりました。

目的が変わったので、運用現場からインフラ構築へのキャリアチェンジを図ります。

このキャリアチェンジは構築の経験がまったくない私には苦難の道でした。

経験のなさをフォローするために有用そうな資格は根こそぎ取得し、無事に構築案件に参画したのですが勝手がわからずに四苦八苦。

それでも徐々に構築の勘所もつかんでいきます。

• 運用は「使うこと」
• 構築は「組み立てること」
• 設計は「組み立てるための設計図を書くこと」

そんな簡単なことが腑に落ちるまでに2年の歳月がかかりました。

そしてあらためて気がつきました。

「設計の時点で、あまりにも運用（使うこと）の設計図が決められていない」

その後、日々の案件をこなすなか、とあるプライベートクラウド設計構築案件に要件定義から運用引継ぎまでサブリーダーで参画する機会を得ました。

IT業界に入ってからすでに9年。ついに自分が経験してきたことを試すチャンスが来ました。

まず、要件定義時から運用チームに対して徹底的にヒアリングを行い、普段どのような運用をしているか調査しました。

その後、運用チームが使いやすい形のドキュメントを作成し、慣例的に作成しているだけの意味のないドキュメントは（合意のうえで）作成しないようにしました。

結果、プロジェクトは成功に終わり、お客様からも高い評価をいただくことになります。その中で一番評価をいただいたのが運用の部分でした。 実施したことは、運用（使うこと）のためにはあまりに当たり前のことでした。

• 運用作業の全量を可視化する（運用項目一覧）
• 情報の流れを関係者で合意しておく（運用フロー図）
• よく使う作業はしっかりと手順書を作成する（運用手順書）
• 運用上必要な情報は見やすくまとめておく（台帳一覧）
• トラブル時のサポート先を決めておく（保守情報一覧）

運用に必要なことを事前に決めておく。

これがすなわち「運用設計」だと気がつき、「⁠運用設計」がされていなくて困っている現場はたくさんあり、これを広めることは価値のあることなのだと痛感しました。

運用設計チームの設立

お客様から高い評価を頂いた「運用設計」ですが、この時点ではまだまだ粗削りでした。これをもっと洗練していく必要がある。

そう思った私は運用設計チームを作りました。

メンバーと共にシステム導入案件を行いながら勉強会を重ね、「⁠運用設計」の手法の確立とナレッジの蓄積を行いました。

勉強会の資料は300ページを超え、それを再編したものがKindleから出版した『みんなが知っておくべき運用設計のノウハウ（以下、Kindle本⁠）⁠』です。

Kindle本を出した後も、さまざまな反響と新たな発見が続きました。

その中でもっとも問題に感じたことは、それぞれの案件、いろいろな会社でみんなが口にしている「運用設計」のスコープがあまりにも違うことでした。

業務がうまく回ることを「運用設計」と呼んでいたり、監視やバックアップといった基盤の維持管理を「運用設計」と呼んでいたり、ITILに代表される運用管理のことを「運用設計」と呼んでいたり……。

これはもっと体系的に「運用設計」を言語化して、共通の考え方を世に広める必要があると考えました。

認識の違いを話し合うためには、まず指標となる考え方が必要です。

• Kindle本はノウハウをまとめただけなので指標には足りない
• 指標を作るためにも、これまでの経験をすべて詰め込んで書籍にまとめる

これは「日本中のシステム運用を今より良いものにしていく」ためにどうしても必要となります。

この瞬間に、私の目的が「日本中のシステム運用を今より良いものにしていく」となり、ようやく本書を書く覚悟が決まりました。

仕事をしながら書籍を書くことがどれほど大変なことかは、Kindle本を作った時に知っていました。

今回は分量も3倍以上ですし、書き上げるまでは過酷な日々が続くことが予想されました（そして、実際には想像よりもはるかに過酷でした⁠）⁠。

それでもなんとか書き上げることができたのは、運用設計チームメンバーと考えてきたことが「運用設計の一つの答えである」という確信があったからです。これが広く理解されることにより、少しはシステム運用の現場が良くなっていくと信じることができました。

日々変わり続ける運用設計の基礎に

この書籍には、私たちが現場で考えてきたことを余すことなく書いています。これが現時点で我々が考える運用設計のベストプラクティスです。

• 昔の私と同じように、運用現場でナレッジがなくて困っている方。
• システム導入時に運用設計をどのように行えばよいか困っている方。
• 誰かと運用について話すときに、スコープの違いで話がかみ合わなくて困っている方。

それらすべての人に有用に使っていただけるように、基礎となる考え方とやり方をまとめました。

そしてなぜ「現時点」かというと、運用設計、そして運用のベストプラクティスは日々アップデートされるべきだからです。

本書をきっかけに少しでも日本の運用が良くなり、新たなベストプラクティスを探して頂ける方が増えたのなら本書を書き上げた日々が報われます。