IT現場では既に稼働したITの面倒を見るため多忙なことが多いです。
多忙であるがゆえに、やるべきことができておらず、不十分な準備でまた作業を実施するようなことになってしまいます。
そしてまた不具合が起き、対応に追われ、やはり多忙となる、という悪循環を繰り返してしまうことがあります。
マネジメントとしては、このような事態はビジネスにも影響が出ますし、現場コストもかかってしまいますので避けたいです。
IT現場のマネジメントはまず現状を計画的にマネジメント状態にするところから始めます。
そうしないと、新しいことをするにも受け入れられないからです。さらには新たなことを行った後の新たな日常はなおさら受け入れられません。
よって、現日常の状態でのマネジメントがあり、次に新たなことを起こすプロジェクトのマネジメントを進め、そして新たな日常としてのマネジメントが始まる、という順序で全体像を説明していきます。
現日常の保守運用マネジメント
稼働・障害・保守マネジメント
ITが予定どおり稼働していなければ、ITを使った仕事ができなくなってしまいます。稼働という観点で重要度がものによって違ってきますが、重要度に応じたマネジメントをしていく必要があります。
監視などを通じてITの異常を検知し、タイムリーに適切な対処を行えるよう備えます。
障害発生時には、常に同じことが起きるわけではないのでマニュアルはなく、難易度は高いですが、適切な対処をマネジメントしていくことになります。
さらに、ITを安定的に稼働させるには、先回りした対処として予防保守作業を実施することもあります。その必要性も含めて日常よりマネジメントしていくことになります。
保守契約・ライセンス契約マネジメント
契約は更新タイミングや支払い方法などがものによって違いますので、注意してマネジメントしていく必要があります。
マネジメントされていないと、間違って契約が切れてしまったり、不必要なものが契約されていたりします。
ライセンスについては多大な賠償金を払うことになる可能性もありますし、期限が過ぎてITが突然止まることもありますので、ビジネスに影響を及ぼすことも考慮したマネジメントを行っていきます。
バージョンマネジメント
開発中のプログラムモジュールや設計書のバージョンを意識して作業することは、ITの現場では常識ですが、できていないことがあるのも常識です。
IT開発中は障害などによりイレギュラーな順序で機能をリリースする場面もあります。そのような際には注意してバージョンを見ていかないといけません。
バージョンのマネジメントはプログラムモジュールのイメージが多いかもしれませんが、そればかりではありません。最新が何かを認識していないと、あらゆる場面で不具合が発生します。
誤ったものを信じて仕事していたら、誤った結果になるのは当たり前ですし、誤ったものに対して変更したら、これもまた誤った結果になります。
すべてを最新に保つことは実は難しいことなので、マネジメントしていく必要があるということになります。
問い合わせマネジメント
ここでの問い合わせはいわゆるコールセンターのようなものを指しているわけではありません。
ITと言っても意味は広いですから、PCの使い方などの一般知識のようなことも含みますが、業務系ITの問い合わせとなると業務とIT両方の知識をもって、対応方法を答えなければいけなくなります。
よって問い合わせに答えるのは必ずしも専門スタッフとは限らず、普通に業務を行っている担当になることが多いです。
問い合わせはあらゆる角度からになりますので、実は工数が掛かっていることですが、あまりマネジメントできないのが実態です。
セキュリティマネジメント
セキュリティに関してはITとは切っても切れない関係にあります。特に近年ではその脅威が声高に叫ばれているのもあり、マネジメントしていかざるを得ません。
扱っているデータにもよりますが、重要度に応じて、技術面や管理面あるいは精神面での意識づけも含めたマネジメントを実施していくことになります。
変更要求案件マネジメント
変更要求案件という言い方は珍しいかもしれません。普段は改修案件や保守案件、もしくはただ単に案件と言うこともあるでしょう。
ここであえて変更要求案件と言ったのは、改修案件だけではなく、ITユーザとしてはもっと広い意味でのマネジメントが必要になるからです。
改修を加えるものだけが案件ではありません。データやマスタに変更を加えることもありますし、ITは何も変更がなくても業務を変更することもあります。
さらに、要求と言っているのは、要求から先に進まないこともあるからです。
保守運用統合マネジメント
ここまで現日常のマネジメントについて挙げてきましたが、これらはすべて一人で実行していることもあります。一つひとつが小さいことのこともありますが、切り口が多いので、それぞれ適切にマネジメントされていなければ、どこで大きな落とし穴に落ち、トラブルを招くかわかりません。
現状ITが稼働しているということは、安定して稼働すること以外に優先するものはありません。
しかし、何か手を加えるような事案は、様々な要因で起きます。
そこでやるべきことは統合的にマネジメントされていくべきです。マネジメント目線でも現場目線での漏れなく、重要性が認知され、次に実施すべきことが把握されていること、そして、誰がいつまでに実行するかが計画され共有されていることが重要です。
つまり、日常としてやるべきことが形式化、段階化、協業化され、さらに日常だけあって日々湧き上がっている事案を常に漏れなく加えていくことが習慣化されたマネジメントを実行していく、ということです。
新IT導入・システム開発プロジェクトマネジメント（非日常のマネジメント）
現日常の保守運用マネジメントにおける変更要求案件は、普通は日常運用の中での対応になってきますが、時に日常とは言えない大掛かりな案件が発生することがあります。
あるいは、事業の発展のためやIT側の老朽化などから新ITシステムの要求が出てきます。
そのような時は、日常に加えて、非日常のマネジメントが発生します。
一連のプロジェクトマネジメントとして概要を説明していきます。
構想・企画
新たなITの要求が発生したのに対し、どのようなものにしていくかを決めます。
構想においては目的を明確にし、何を実現するかを決めます。やることが比較的明確であればいいのですが、話が大きい場合は、様々な考慮すべき要素があり、目的を見失います。
議論の発散と収束により方向性を決めます。
さらに情報収集し、実現性のあるものかを確認していきます。そして、コストと実行計画を策定し、実行を決定します。
これらの活動は一連のマネジメントを行っていくことで、実行性のある段階まで持っていくことができるでしょう。
構想・企画そのものが、既に失敗に向かっている事例もありますので、注意していきたいものです。
提案・見積依頼
構想・企画段階においても、ITベンダーやITコンサルタントに支援を依頼することもありますが、ここでは新ITの構築において、ITベンダーに依頼することとします。
新ITについては、既存のサービス導入に事足りることもあるかもしれませんし、大幅にカスタマイズする必要があるかもしれまません。まずは、情報収集を行います。
情報提供を受けた上で、新ITの企画ができます。企画書に基づいて、実現方法とコストについてITベンダーに見積依頼を行います。
不確かなことに対して最も確かなものを選択するにあたっては、比較が必要です。よって、比較できる情報を集めつつ、最もよいものを選択し決定できるようマネジメントしていきます。
契約・交渉・合意
ITベンダーをどこかに決めた場合、契約により始めることになります。
契約の方法は、民法上の扱いによるものもありますし、一括で契約するのか、段階的な契約とするかといった取り決めも必要となります。
IT導入・システム開発においては、実現までの不確実な要素が多いため、金額面においても進め方においても様々な交渉要素があります。
交渉の上、合意に至るまで、スムーズに進めないとなかなかスタートできないということになります。構想・企画を進めながら契約についても計画し、マネジメントしていくことになります。
IT導入・システム開発プロジェクトマネジメント
ITプロジェクトマネジメントが始まったとして、大きな工程ごとにマネジメントすべき観点が異なってきます。
発注側ITユーザの目線からのプロジェクトマネジメントとなりますので、開発そのものよりもユーザとして重要な工程を中心として説明していきます。
要件定義・計画
要件定義は、どうしたいかという構想・企画段階での要求に対し、どういうものを構築するかという観点で明確にしていきます。
要件定義は、必ず不十分な点があると思って進めます。不十分さがコントロール範囲であることを目指します。
コントロール外のレベルで不十分だと、最悪頓挫となることもあると思って、重要な場面と認識して進めます。
何を構築するかという対象物が決まり、どう進めていくかという計画も策定します。
最終的に実現していくには、対象物がきちんと定義されていることも、計画の精度が高いことも両方大事です。
精度を高めていくために、マネジメントしていくことになります。
外部設計
主に見える部分の設計になります。エンドユーザのオペレーションそのものになりますので、エンドユーザを無視して進めることはできません。
エンドユーザが不特定多数な場合もあります。その際も、やることを決めなければ進めることはできません。
ここで決まったことはそのまま実現されるものですので、重要な場面であり、決定者にとっては軽く決められるものではありません。
よって、決定プロセスをマネジメントしていくことになります。
内部設計・開発・結合テスト
いわゆる開発の工程です。ITベンダーが決まった仕様に従って進めていくことになります。
全体を上流から下流に流れるウォーターフォールとして進めた場合、仕様が決まっているからそのとおり作られるのは当然のように考えられますが、そうならないのがITプロジェクトの難しいところです。
品質面においては検証結果が問題ないを確認するとともに、合目的性確認を常に行っていきます。
変更が必要であれば、変更マネジメントを行っていくことになります。
総合テスト
ウォーターフォールのいわゆるVモデルからすると、IT全体を繋げるため、要件定義や外部設計の裏返しとして、エンドユーザ観点として確認していく必要があります。
その意味において、ITユーザ側としても、仕上がり具合を評価するためのマネジメントを行っていきます。
受入テスト
総合テストについては、あくまでもテストの一環として扱っていて、ITベンダーに作業主体としての比重があることが多いですが、受入テストについては、ITユーザ主体となります。
主体ということは、計画し、計測の上評価し、最終確認をすることになります。ここで確認できなければ、そのまま新たな日常としての本番展開がされてしまいますので、重大な局面です。
よって、確認の段取りをマネジメントするとともに、確認途中で課題・問題が発生することも想定した計画にしてておきます。
利用準備・運用設計
エンドユーザに提供するにあたっては、それなりに準備が必要です。
最も想像がつきやすいものはマニュアルと教育です。
想像がつきやすいのは、ITベンダー目線ではよく出てくるからだと思います。
しかしITユーザ側としては、どちらかと言えばビジネスや業務あるいはサービスへの影響を踏まえてリリースを段取りするほうがより重要度が高いです。
ITの操作はその次に必要なことです。
また、ITを導入した後の運用も考えておく必要があります。
ITに関わる業務運用のこともありますし、ITとしての運用もあります。
運用テスト
運用テストは工程としては大きくとらえて、受入テストも含めて表現する場合もあるでしょうが、本来は別なものです。
運用テストは、ITユーザ側がリリースした後の運用を想定して、運用が想定どおりにできるか、問題がでないかという確認になります。
その前に運用設計が必要となりますが、設計どおりかを検証することになります。
運用設計は、ITの設計と同様不完全さもあり得ますので、実際のテストで検証していくということになります。
データ移行
データという言葉が出てきましたが、ITを動かすにあたってはデータがないと動きませんし、データはITユーザのものですから、まさにデータ移行したことで初めて、ITユーザのものになったということになります。
データだ正しくないと、当然機能が正しく動いても意味がありません。
現行ITから新ITへの切り替えという場合は、現行のデータを移行します。
基本的に別なITですので、データの中味は違うはずです。違うものに移行するのは、苦労を要する場合が多いです。
また、データはITユーザのものですので、ITベンダーは何もしないこともあります。この点は常に揉め事の種になります。
この内容の難しさと役割の不明確さにより失敗への向かうプロジェクトも多いため、特に重点を置いてマネジメントされるべきことです。
稼働・切り替え
本番稼働を迎えます。
切り替えるにあたっては、ある日リリースされ利用が開始されるわけですから、その日というのは、とてつもなく特別な日であるはずです。
切り替えにあたっては多くの準備と検証が必要になってきます。またやってしまうと引き返すこともできない可能性もありますから、もちろん計画しマネジメントしていく必要があるということです。
外注ベンダーマネジメント
契約にあたりITベンダーと契約する観点でのマネジメントを説明してきましたが、契約締結後についても継続してベンダーマネジメントを行っていきます。
ITベンダーは複数の中から最もよいと思われるところを選んだはずですが、完璧に進めてくれるとは限りません。
思ったことと違った場合においても、それが普通ですと言われれば、引き下がるしかありません。
しかし多くの場合、普通と言っているのはITベンダー側都合であり、ITユーザからすると普通ではないです。
ITユーザとして要求すべきことはできるようにするためにも、始めからマネジメントしていく姿勢が必要ということになります。
プロジェクト・保守運用統合マネジメント
プロジェクトマネジメントは一般的に多く普及していますので、世間的にはノウハウも蓄積されていると思います。しかし、ITスタッフの乏しいITユーザとしては、プロジェクトを理論どおり進めることは実際は困難です。
というのは、スタッフが限られているため、日常業務を行いながらプロジェクトも行うメンバが出てくるからです。
つまり、マネジメントすべき全体は、プロジェクトだけではくその他の業務も含めて行うということになります。これが、プロジェクトと保守運用における統合マネジメントです。
その他のハイレベルマネジメント
プロジェクトの難易度が高ければ、ここで説明してきたマネジメント以外にも、専門的にあるいは重点的にマネジメントしていくべきものがあります。
意思決定マネジメント、リソースマネジメント、リスクマネジメント、品質マネジメントといったものです。
新しい日常の保守運用マネジメント
ITプロジェクトの一連のイベントが完了すれば、新しい日常のマネジメントが開始されることになります。
新IT定着化フェーズマネジメント
新ITの切り替えが完了したとしても、大抵の場合はスムーズにいくとは限りません。課題・問題は大小はあると思いますが、必ず発生します。
ITの作り込みが多い場合は、バグが潜在していることもあります。エンドユーザが多い場合は、理解不足による業務遂行上の課題が出ることがあります。
使ったことがないもにに対しては、人は必ず抵抗がありますので、何かしらの課題・問題は出てくることになります。また、習熟の定着に時間がかかるものです。
よって、定着化のフェーズというものは予め見込んでおいたほうがいいですし、もちろん課題を潰せるような対応を計画し、マネジメントしていくことになります。
保守運用統合マネジメント
プロジェクト発足前にも登場した保守運用の統合マネジメントですが、新IT導入後も新たな統合マネジメントとして登場します。
まったく新たなITに入れ替わることもあるでしょうが、むしろそのようなことは少なく、それ以外のITが存在し、全体として保守運用が加わることのほうが多いのではないでしょうか。
そうであれば、まさにここでマネジメントを統合していくことになります。
ITユーザならではのマネジメント
日常とプロジェクトの両方で必要な場面が出てくるものではありますが、これまで説明してきたもの以外で、ユーザならではのマネジメント領域がまだあります。
オーナーマネジメント、エンドユーザマネジメント、データマネジメント、お詫びマネジメントといったものです。
マネジメントとは。まとめ
ITユーザの現場においては様々なマネジメントすべき領域があります。
企業の規模やITの規模にもよりますが、多かれ少なかれ何らかのマネジメントを行う必要があります。しかし、大企業においてもすべてマネジメントできているかは疑問です。
マネジメントしなくても特に問題が出ていないことももちろんたくさんあります。
マネジメントすることは工数もかかることもありますから、すべてをまじめにやり込む必要もないですが、どのようなことに着目すべきかは知っておいて損はないでしょう。
個々のマネジメント手法については、順次ご紹介していきます。
コメント