「運用ゲンジン」が提供する「運用設計のポイントと管理ドキュメント」

【第6回】 いいシステム作りには互いの得意分野での協力と情報共有が欠かせない

概要

2005年10月から2006年3月に、システム管理者の会サイトの前進である”カイゼン活かす”サイトに掲載され、その後も根強い利用がある「運用規約、運用設計書」の筆者である「運用ゲンジン」ことITシステム運用コンサルタント沢田典夫氏のコーナーが復活します。今回は、より具体的な内容で運用設計のポイント、運用の管理項目とプロセス、運用設計基準書内容等について、テンプレートを多数公開していただきます。
皆さんの運用カイゼンにお役立てください。

目次
人材は人財
開発から運用
変更管理

 

人材は人財

家に帰ってテレビを付けると、真っ先に聞こえて来るのは暗い話ばかりで、明日はわが身かと見ていても辛くなる今日この頃です。
そんな時世でか、このコラムの出だしも毎回ため息混じりの話題になってしまっていますが、みなさんは暗い話題の多い中でも頑張って運用されていることかと思います。
 
「100年に一度の世界同時不況」と言われるほどの不景気は止まることを知らず、むしろ底に向かってさらに加速している感があります。  企業の生き残りをかけ、人員削減は千から万単位の数値が飛び交い、不況のすごさを物語っています。
アメリカから発信された不況の波は輸出依存度の高い日本を直撃し、日本が回復するにはアメリカが立ち直らなければならない構造不況では、景気が好転するまでにはまだ二・三年はかかると専門家のキツイ言葉・・・・(泣)
 
企業が生き残るために人員削減は最終手段だとは思いますが、同時に企業が長年培ってきたスキルという大きな財産も失います。
特に技術や職人で成り立ってる企業にとって人は財産であり、回復するまでの間、あるいは回復後の活力となる人財を手放すことなく
いかに耐えいかに活かすかが企業の生き残りのためにも大きな鍵となりますが、現実は厳しく今回の不況は相当深刻なようです。
是非このコラムが続いている間に景気が少しでも回復してくれたらと祈るばかりです。
 
この世界的な不況の中でみなさんの会社や部署でもいろんな影響が出てきていることと思いますが、特に運用はマニュアル類や指示書などのドキュメントによる作業が中心ですが、同時に技術や職人で成り立ってる部署でもあり、日常的なルール、過去の経緯や経験、また、それらを継承しながら運用を維持するためには、マニュアルやドキュメント以上に人のスキルは重要な財産となります。
 
そういったスキルをいくらマニュアルやドキュメント化しても日常作業の中では埋もれ、引継ぎがあるにしても運用管理者や担当者が変わった途端過去の経緯や経験値は薄れ、当初の理由のある決め事の意味は引き継がれず、次第に過去からこうだったに変わり、多くは維持するために決められた通りに運用してるというのが現実ではないでしょうか?
ITILなどと照らし合わせるとドキュメントでは表しきれない意味、また、過去の経緯や経験が必要な運用は余り好ましくありませんが、 そういったスキルはこれからの運用、あるいはこれからの人材育成や生きた運用にはむしろ必要なことだと思います。
 
さてさて、愚痴や不景気な話はこれぐらいにして本題に入りましょう。 今回はみなさんも日ごろ頭を痛めてる「開発から運用」、「変更管理」について触れてみましょう。
 

開発から運用

「開発から運用」と聞けばみなさんは何をイメージするでしょうか?
運用引継ぎや移行、受け入れ、また、突然やってくる運用の準備や訓練・周知が間に合わない、複雑・煩雑な運用、変更できないままバタバタ、といったような声が聞こえてきそうですが、この開発から運用では以前から比べたらだいぶ改善はされてきてはいるものの、まだまだ多くの運用の共通の悩みなんだと思います。
 
開発はサービス開始に向けてシステムを開発し運用に引き渡す役割ですが、運用に引き渡し安定稼動させるためには多くの準備が必要になります。  また、準備にしても開発されるシステムによっても様々であり、限られた時間で準備が間に合わず条件付きでのサービス開始や、本番が開始されてからも準備に追われることもしばしばあるかと思います。短時間で準備を行うことでバタバタしたり、また、確認も疎かになってつまらないトラブルを招いたりと、いつになってもこの移行時期は運用にとって嫌なもんです。
 
こういった問題はどちらかというと運用設計がされていない情報部門に多く、作られたシステムを運用に引き継ぐという移行の方法を取ってるところに多く見受けられます。確かにシステムは開発が作り、運用が作られたシステムの運用を行う役割ですが、前回も話した通りシステムの運用はみんなで作りあげるものです。システムを作るには開発目線でのシステム作りと運用目線での運用設計(掲載資料①【運用設計の領域】参照)の両方が合わさって始めてシステム機能を発揮します。
 
作られるシステムには必ず何かしらの運用がある以上運用視点での運用設計は必要ですし、システムが出来上がってから運用には間違えです。開発がシステムを作るシステム開発というものがありますが、運用も設計したり仕組み作りやいろいろなドキュメントの準備やそれを使っての訓練・周知があり、私はこれを運用開発と呼んでます。私が取ってる方法は掲載資料②【運用開発】参照)システムの設計段階から並行して運用設計や運用構築・準備を行い、移行は開発と運用の双方の協力で行う方法です。いいシステム作りが必ずできるはずですので、機会があれば小さいシステムで試してみてください。ただ、これを実施するに当たっては、開発工程への参画や運用開発を実施する要員の工数捻出、また、参画する要員のスキルアップなどが課題ですが、そのための体制作りは今後ますます必要になると思います。
掲載資料①
 
掲載資料②

変更管理

情報部門ではシステムの移行(リリース)同様、変更管理も重要なファクターの一つです。また、やるべき事は当然で一つ一つは簡単な事なのですが、情報部門にとっては何故か苦手な分野だとも言えます。何故だろうか?
 
ある文献では「変更管理」を次のように定義しています。(要約)
 
変更管理・・・・・・・全ての変更がコントロールされた方法で評価・認可・実装およびレビューされることを確実にする。

 

①変更の適用範囲が明確に定義され文書化されている

②事業利益をもたらす変更だけが認可される

③優先度及びリスクに基づき変更のスケジュールが立てられている

④変更実装時に構成に対する変更を検証できる

⑤変更を実装するための時間が監視され、必要な場合には改善される

⑥変更について次を行う方法を実証することができる

 ・変更を定期、記録、分類する

 ・サービス、顧客及びリリース計画に与えるインパクト、緊急度、コスト、利益、リスクに関して変更を評価

 ・失敗した場合、元に戻すか修正する

 ・文書化する

 ・変更の種類、規模及びリスクによって変更許可委員が変更を認可または却下する

 ・変更されるコンポーネントに責任を持つグループにおいて、指名されたオーナが変更を実装する

 ・テスト、検証及び最終承認する

 ・クローズしレビューする

 ・スケジュールを立て、監視し、報告する

 ・適切な場合はインシデント、問題、他の変更及び構成アイテムのレコードと関連付ける

法律的な表現でイメージしにくい感がありますが、概ね次のような表現になる。

 

予め変更するものが承認・計画化され、変更手順に基づきリハーサルを行い、変更内容の検証が行われる。
また、変更に失敗した場合には切り戻し手順に従いきり戻しが行える。
変更は変更の責任者が実施し検証を行い、変更作業が終了したらレビューを実施する。
変更作業と変更事項、また問題管理事項とリンクを取り、今後の変更作業時に役立てる。

となるが、どのくらいの情報部門がこの手順に沿って実践してるか、また、できるかは疑問だが、かなり簡略化した手順で実施してるのが実情だと思う。

何故苦手なのか、
問われてることはもっともなんですが、

開発・保守システムのリリースは別としても、保守が頻繁、トラブル時での緊急処置、復旧を優先、要員不足で別な変更管理専任者が置けない、多い例外条項の抜け道、テスト環境が十分でない、日常作業に追われ後回しでよいものが忘れて放置などが起因してるものと思いますが、そもそも環境も複雑になり変更するものも多く、どのような変更の時に何を変更し、他に何を同時に変更しなければならないのかが整理(リンク)されてないことが大きな原因だといえます。

ただ、変更作業内容によっては変更するものも異なることが多く、ケースを積み上げて地道にパターン化することが一番の近道だといえますが、まずは、変更ケースでの標準変更事項と、関連変更事項(選択)、変更事項一覧(選択)の申請・管理フォームを作り、関係者で変更作業承認・計画時に変更事項に漏れがないかの事前レビューができるものが必要で、その積み上げや分類により標準変更事項や関連変更作業の精度を上げることが大切ですが、問題は関係者の日ごろの意識や癖が何よりも重要になると思います。

 

この方法はかなり昔に私が実践してみましたが、変更事項に一通り目が通せるので、気付くことで漏れも少なくなり、スキルアップや品質向上にもかなり役立つものと思われます。

連載一覧

コメント

筆者紹介

沢田 典夫(さわだ のりお)

1951年生まれ。運用との出会いは某銀行でのオペレータに始まり、7年間富士通 フィールドSEとして多くのメインフレームの導入の企画提案、移行、OS試験、環 境設計や構築~チューニング、また業務システム開発などを手掛ける。また、某大手 トレーディングスタンプ会社で13年間、コンピュータの導入、業務システムの開発 (物流・販売・財務・経営)および運用を行い、この時に開発の標準化、自動運転環境構築、運用設計や運用改善、また、運用ツールの開発などを手掛け、運用の基盤を 確立する。その後BSP一期生として入社し、運用診断や運用企画、また、運用設計 を重視した運用ツールの導入などを行い、コンサル事業の基盤作りを行う。その後運用コンサルとして独立し、これまでの経験を生かし、運用する人の立場に立ち、ま た、運用改善は永遠のテーマを掲げ、16年間一匹狼で運用と向き合ってきました。

バックナンバー