- 目次
- 1. フレームワーク~それは「抜け漏れ」「意識違い」を防ぐ仕組み
- 2.私たちシステム管理者は多くのフレームワークを使って仕事をしている!
- 3. 運用管理のフレームワークを使いこなす
- 4. 開発メンバーは意外とできていない!
- 5.フレームワークがあればナレッジをためやすい
- 6.そろそろサービス志向にシフトしよう
「AI」「自動化」「少子高齢化」
変化の時代、私たちシステム管理者にもチャレンジと変化が求められています。
とはいえ、日々の通常業務に追われているだけでは、なかなかチャレンジも生まれない。変化のきっかけもない。
この連載では、主にヒューマンスキルを中心に、明日を生きるシステム管理者に求められるスキルとは何か? 日ごろの意識と行動をどう変えていったらよいか? をみなさんと一緒に考えます。
1. フレームワーク
~それは「抜け漏れ」「意識違い」を防ぐ仕組み
私たちシステム管理者の大きな強みの1つに、フレームワークを使いこなせるチカラがあります。
「え、日ごろフレームワークなんて意識したことない」
「ピンと来ない!」
と首をかしげたあなた。
実は、私たちは既に無意識のうちにフレームワークの中で仕事をしていて、フレームワークを駆使しているのです。
その前に、そもそもフレームワークとは何か? 少しお話しましょう。
フレームワークとは、ものごとを整理する上での、あるいは複数のメンバーで仕事を進める上での共通の枠組みです。
課題対策の検討会。メンバー各自、思いつきで意見や提言をしていただけでは、どうしても抜け漏れや穴が生じます。
定常業務。人によってバラバラの切り口や観点で業務を進めていては、やはり「ムリ」「ムダ」が生まれがち。属人化も進みます。
共通の枠組み、すなわちフレームワークに当てはめるだけで、観点の偏りや抜け漏れを防ぐ効果があります。
一般的に用いられるフレームワークを紹介しましょう。
(1)3C
Customer(市場)、Company(自社)、Competitor(競合他社)の頭文字をとったもの。
企業の製品やサービスの戦略、競合戦略を考えるとき、3Cに当てはめて考えると良いです。
(2)4P
マーケティングの基本フレームワーク。
Product(製品・商品)、Price(価格)、Promotion(販売促進/マーケティングコミュニケーション)、Place(流通)の頭文字。
(3)SWOT
Strength(強み)、Weakness(弱み)、Opportunity(機会)、Threat(脅威) の頭文字を組み合わせたもの。組織や製品・サービスの現状分析に役立ちます。
フレームワークは先人の知恵の塊。ひとまず、フレームワークにものごとを当てはめて考えてみるだけで、抜け漏れやメンバー間の意識の違いを防ぐ効果があります。
2.私たちシステム管理者は多くのフレームワークを使って仕事をしている!
実は、私たちシステム管理者は既に多くのフレームワークを駆使して仕事をしています。
(1)たとえばPMBOK®
いわずと知れた、プロジェクトマネジメントのフレームワーク。運用管理者、担当者であってもなんらかシステム開発に関わったことがあるでしょう。
構想からリリースまで。さらにはその後の振り返りと、プロジェクトの終結まで。システム開発のライフサイクルにおいてすべきことを網羅的に学ぶことができます。
(2)たとえばITIL®
ITサービスマネジメントのフレームワーク。
運用職種の人であれば、知らない人はいない業界のデファクトスタンダード(事実上の標準)。
(残念ながら開発や営業の認知度はまだまだ低いですが)
既にITILベースで運用管理体制を組んで、日々の運用業務を回している人も少なくないでしょう。
私たちの当たり前は、既にフレームワークで成り立っている。フレームワークの中で回っている。
そして、プロジェクトマネジメントもITサービスマネジメントも、何もシステム開発やシステム運用管理のためだけにあるものではありません。
非IT部門の業務課題や、サービス品質向上に役立つ汎用的な道具なのです。
いまいま「ITILを知らない」「ITILベースで運用していない」人は、これを機にITIL®の各プロセスと自分の運用業務を照らし合わせてみてください。「抜け」「漏れ」や脆弱さをチェックしてください。
自分の業務を、自分たちにしか分からない専門用語で、マニアックに語る。それには何の価値もありません。
(本連載の第2回「わかりやすく伝える力~明日のシステム管理者に求められる5つのスキル(1)」を読み返してみてください)
標準フレームワークで自分の業務を説明できる。それが、あなたの汎用力と生き残るチカラを高める第一歩です。
3. 運用管理のフレームワークを使いこなす
さらに深堀りしましょう。
私たち運用管理者が使いこなしているフレームワークにはどのようなものがあるでしょうか? 3つ例を示します。
- (1)インシデント管理・問題管理
- (2)変更管理
- (3)リリース管理
これら3つは、システム運用の生命線といっても過言ではないでしょう。
当たり前のシステムを、ユーザが当たり前に使えるように維持する。機能追加や構成要素の変更を、トラブルなく行うための管理。
しっかりとしたプロセスと手順を整えて、淡々と実行する。その設計スキルと実行スキル、および勘所はたとえオンプレミス型のシステムが消滅してクラウドに移行しようとも欠かせない宝です。
ところが…
4. 開発メンバーは意外とできていない!
開発の人に聞くと、結構これらの管理が杜撰。
運用フェーズのみならず、システムの開発フェーズでも上記3つの管理は大事です。
- ■開発時に発生したインシデントを管理して、開発フェーズで解決する/運用に引き継ぐ
- ■リリース時に発覚したインシデントを把握管理し、問題管理に移行して、次回リリースの品質向上につなげる
こういった有機的な取り組みが、システムの開発品質と運用品質の維持向上に欠かせない…はずなのですが、
まったく管理できていない!
「『インシデント管理』ですか? きちんとやっていますよ!」
と主張する開発の責任者。そうは言うものの、実態はそれらしき課題管理簿が一枚あるだけ。
- ■課題管理簿に記録しただけでおしまい
- ■開発メンバーだけで共有しておしまい(運用メンバーに申し送りされないことも…)
開発フェーズの、その場限りの情報共有くらいにしか使われていない。当然、運用メンバーにも引き継がれない。
そして、リリース間際になって、いつもあたふたする。迷惑をこうむるのは私たち運用の現場、そしてユーザー!
記録はあくまで、インシデント管理/問題管理プロセスの一部に過ぎません。
(運用管理者であればお分かりでしょう)
インシデントを分類して、初動を判断・実行して、エスカレーションして、根本原因分析して、対応検討して、変更の影響を調査して…このような一連の有機的なアクションにつなげてこそ意味がある。
また、インシデントの発生状況や傾向、クローズ状況などの測定と報告も欠かせません。
ただ書き出しただけの課題リストに何の意味があるでしょう?
開発メンバーだけで閉じたインシデント情報、問題情報にどんな価値があるでしょう?
開発フェーズで起こったインシデントであっても、ITサービスマネジメントのフレームワークでしっかり管理する。
変更管理、リリース管理、構成管理などの他のプロセスと有機的に連携させる。
それにより、開発も運用もプロアクティブな仕事ができ、かつよりよい品質のシステムを生むことができるのです。
そして、その流れをプロセスとして設計できるのはほかならぬシステム管理者の強みです。
5.フレームワークがあればナレッジをためやすい
このように、きちんとしたフレームワークに沿って業務を設計しておけば、ナレッジはたまりやすくなります。
ただなんとなく個人の思いつきやセンスで課題や問題を洗い出していても、それは組織の問題になりにくく、知見もたまりにくいです。
一方、インシデント管理、問題管理、リリース管理などの標準フレームワークに沿って管理していれば、そこに乗っかってくる情報やノウハウは蓄積、分析、比較しやすくなります。
- ■インシデントの発生傾向やクローズ率
- ■重大な問題に関する知見
- ■リリース品質、リリースのプロセスにおける運用者のノウハウ
ナレッジ管理というと、わざわざナレッジ管理のためのデータベースを作って、わざわざそこにノウハウを登録させて、わざわざ閲覧させる…ような大げさな取り組みを想像しがち(そして、なかなか定着しない)。
それよりも、日々の運用をフレームワークに沿ってしっかり設計し、自然の流れでナレッジがたまるようにするほうが効果的でしょう。
フレームワークは、組織のナレッジ蓄積と流通を促進する屋台骨でもあるのです。
6.そろそろサービス志向にシフトしよう
世の中、サービス志向に変わりつつあります。
これまでのオンプレミス型から、クラウド型へ。それに伴い、私たちシステム管理者も、運用エンジニアも意識を変えていかなければなりません。
長年磐石だった、金融機関のレガシーシステムの運用保守部隊とて、もはや安心してはいられません。”Fintech”の勢いは目を見張るものがあります。
金融システムのオープン化、共通サービス化の流れは間違いなく加速するでしょう。
井の中の蛙になっていてはいけない。
汎用的、標準的なフレームワークを積極的に身に着ける。実践する。フレームワークを駆使して、顧客のビジネスの課題を解決する、提案する、実践する。
これからのIT屋はそれができてなんぼです。
ありがたいことに、私たちはITIL®を筆頭とするサービスマネジメントのフレームワークに触れる機会に恵まれています。
ITIL®はサービスマネジメントの世界共通のフレームワーク。すなわち、きちんと学べばグローバルに通用する人材になり得るということです。
時代を見据え、汎用力あるシステム管理者、運用エンジニアを目指しましょう!
—
次回は5つのヒューマンスキルの4つ目、「関係構築力」を解説します。
自動化の流れに不安になりすぎる必要はありません。私たちシステム管理者ゆえの強みは間違いなくあります。
ただし、今までと同じやり方、昨日と同じ考え方では、間違いなく明日はないでしょう。
私たちの強みと脅威を冷静に見つめ、明日を生きる「システム管理者2.0」にバージョンアップしましょう!
コメント
投稿にはログインしてください