変更要求によって現行のITシステムに手を加えることは、保守の一部ではあります。
保守マネジメントでの説明の中では、変更要求によるものは別扱いとしていました。
変更の起因が変更要求によるものというだけで、予防保守や障害対応と現行ITに対して手を加えて、稼働させることに変わりはありません。
ここでは、変更要求によるものは、案件と取り扱います。
一つの案件すなわちプロジェクトとして扱います。
ただし、いわゆるプロジェクトマネジメントとは、また少し違った難しさを持ったものとなります。
変更要求とは
ここで言う変更とは、現行ITに対して何らかの変更を加えることとします。
ただし、ITそのもののから発生する要求、すなわち障害対応や予防保守対応ではなく、経営や事業部門ユーザから発生する要求を基本とします。
ITへの変更は事業や業務の変化により発生するものであり、ITのある意味進化を遂げる行為です。
ITが既存であり、それに対する変更であるがゆえに、現行を維持しつつ、ある時点より進化を加えるという計画を確実に立てて、実行していくことになります。
変更要求による案件をマネジメントすることとは
事業の中心にあるITであれば、変更要求は運用していく上で絶えず起きています。
一つの事業変化に対する要求が、複数のIT変更要求であることもありますし、複数の事業変化を結果的に一つの変更要求で対応するということもあります。
事業変化は様々な領域やレベルで起きているので、ITスタッフ側の都合では発生していません。
よって、一つひとつを案件として認識し、リスト化することで、確実に要求に応じるようマネジメントしていく必要があります。
もう1点マネジメントの観点があります。
それは、一つひとつの案件を実行するにあたって、プロジェクトマネジメントしていくということです。
プロジェクトマネジメントと言っても、変更のマネジメントは、ほんの小規模なマネジメントと思っていても、既存ITに手を加えることとなるため、安易な対応はできません。変更による影響を確実に見極めるという、計画が必要となるマネジメントとなります。
変更要求の種類
変更要求は、広範囲な切り口で発生します。ITの操作性改善といったオペレーションレベルのものもあれば、社会的な変化への対応を行うものもあります。
また、変更する対象はITと一言で言っても実際は、データ、プログラムもしくは設定内容といったものがあります。
変更起因による要求の分類
要求の分類は以下のとおりです。
社会レベルからの変更要求
社会からの要求というのは社会の変化への要求のことです。もっとも分かり易いのは法令対応です。消費税率対応などがそれに当たります。ただしそればかりではなく、働き方改革による就業状況分析対応といった、必ずしも法令ではないものも発生することはあります。
社外からの変更要求
社外とデータ連携している場合、顧客からの要求があった場合は、対応しないと取引できないこともあるため、必須の要求となります。EDIなどでデータ連携していなくても、請求書データの提供などのデータフォーマット変更要求といった対応も発生します。
経営レベルからの変更要求
経営レベルの変更要求は大掛かりなものとなります。M&Aによる経営統合によりITの統合を行うという最大級の変更要求は経営レベルのものです。
経営からの大掛かりな制度変更への対応といったものも変更要求としてあります。
事業レベルからの変更要求
経営レベルと事業レベルは場合によっては同じレベルになることもあるでしょう。
ここで、ある事業における事業戦略の変更により、ITでの取引条件の追加や変更、データ連携などが発生するようなケースを想定します。
事業レベルと言っても、機能レベルのものもあります。会計への変更要求や生産への変更要求と言ったケースもあります。
業務レベルからの変更要求
業務レベルというのは、ある一部の業務プロセスに対する変更を差します。
例えば、旅費精算方法の変更におり経費精算のIT変更に対応するといったものになります。
オペレーションレベルからの変更要求
オペレーションのレベルは最も分かり易いものとなります。
実際のITの操作や出力内容に関わるところであり、目に見える要求が出されます。
分かり易い要求ではありますが、表面的な難易度とIT内部の複雑度は一致しないこともあります。つまり、要求は簡単そうでも、実現は難しいというものもあるということです。
変更対象による要求の分類
要求に対して変更する対象はいわゆるプログラム変更だけではありません。
データへの変更要求
データに対する変更も変更要求の一つです。
一般的なITの操作では修正不可能という状態となってしまった時に、データを修正するという変更要求が発生することがあります。
しかし、直接修正すればいいという考えは安易であり、非常に危険です。
ITで処理されていることでデータは整合性が保たれています。直接修正するとデータ間の整合性が崩れて、不正なデータつまりは不正取引を生んでしまうことにもなりかねません。
プログラムへの変更要求
プログラムへの変更要求は最も想定しやすい変更要求でしょう。
しかし、プログラムへの変更は変更前までに処理してきたデータにも影響を及ぼす可能性もあり、難易度は高いです。
よって、慎重に進める必要があります。
設定への変更要求
設定というのは、パッケージソフトウェアやサービス、あるいはミドルウェアなどの設定の場合もあります。
様々な要求の切り口によって、結果頻繁に変えることのない設定レベルまでの変更が発生することもあります。
設定と言っているのは、いわゆる管理者権限のある者が設定するような内容のことです。
よってよく知っている上で対応しないと、最悪ITが止まってしまうような事態にもなりかねません。
変更要求リストのマネジメント手法
変更要求は大きなものから小さなものまで発生する可能性があります。
一度に行うとメンバのリソースが不足することもありますので、対応するメンバのリソースを考えながら実施状況をマネジメントしていきたいです。
そこでリスト化対応が必要となってきます。
変更要求案件の優先順位を決める
変更要求をリストアップしても、ただ並べられただけとなっています。
何から手を付けるべきなのか、決める必要があります。
実施するものなのか、はっきりしていないこともあるかもしれません。
そのようなものは、優先順位に考慮して、全体的な優先順位を決めていきます。
変更要求の効果測定を行う
変更要求は変更を実施した後は変更後に変わります。
変わったら何らか効果がもたらされるはずです。
効果は利益と捉えてもいいですが、単純な利益だけではなく、損失を回避するという意味での利益もあります。
単純に利益と言えば、売上が上がるか、費用が下がるという意味で利益となります。これについては比較的分かり易いです。
もう一つは、実施することで利益が上がるものではなくむしろ費用が発生することもあるが、しなければ損失を被るというものです。
法令対応や顧客対応などはそのようなものでしょう。
実施しなければならないものであるため、実施しないということはあり得ないのですが、効果を図る上では実施しなかった時の損失を考えることで測ることができます。
効果の金額を算出する
変更要求を実施したことにより、費用がどのくらい下げられるかは比較的算出しやすいと思います。
それはITが便利になることで工数が下がるというのは、比較的見えやすいからです。
売上のほうは、算出がやや難しいかもしれません。ITへの対応だけで売上につながるかどうかが不明なことが多いからです。
売上への寄与については、細分化して考える必要があります。
顧客との接点数、引き合い率、成約率等のアップとそれによる売上の増加額。
損失を回避する効果のほうは、損失想定額を算出します。
多くの場合は、損失額が大きすぎて実施しない選択はあり得ないとなりますが、時に実施しなくてもいいという結果にもなりますので、実施する前には確認すべきです。
損失度合いがケースによって変わってくることもあります。その際はケースごとの発生確率によって損失額を算出し、合計します。
利益においても損失においても、確率的な問題もあり、実際の算出は難しい面があります。しかし、おおよそであったとしても算出したほうが、優先順ははっきり見えてきます。
変更要求のリスクを踏まえた費用を算出する
効果の金額を算出したら、対応するための費用のほうも算出します。
対応費用は、対応するレベルによって大小様々となります。
経営レベルであれば広範囲の変更となるため、大掛かりな費用となることが多いです。
操作性改善であれば、操作の工数もわかるため、費用が出せれば費用対効果が比較的に明らかとなります。
しかし、操作性改善の費用については、意外と大きかったりします。
表面的な改修と思ったら、内部ではデータが連携しており、他のITにも影響が及んでしまったということもあり得ます。
従って、現行IT調査を実施の上、費用算出を行います。
案件間の関係を調査する
変更要求案件は一人から上がってくるとは限りません。時に様々な方向から発生します。
リスト化した際に、別々に上がってきた変更要求案件が、実は関係しているということがあります。
要求そのものが関係していることやITが関係していることがあります。
要求が関係していると、要求によって順序性があったり、一つ実施したらもう一つは不要となったり、といったことがあります。
ITが関係していると、一つの要求で改修中のプログラムは直せないことになりますし、二つの要求について同時に改修したほうが効率的ということもあります。あるいは、ITが繋がっていて、直す範囲がさらに広がるということもあります。
業務もITも、さらには顧客や発注先も含めて繋がってくることもあります。そうすると順序や費用に影響してきますので、考慮する必要があるということです。
費用対効果に関係なく優先順位高いものをリストアップする
リスト化された案件は、費用対効果にて並べられていることになります。
費用対効果が定量化されていれば、効果の高いものから実施するのは非常に分かり易いことです。
ただしそれだけの観点では、優先順位は決められません。
緊急度という観点も必要となります。
来月までに変更要求に対応しないと、サービス販売ができない、などといったことがあります。
本来は、要求を出す時期を早める必要があったのでしょうが、それを今言ってもしょうがないとなってしまっていることもあります。
そのような案件は、ビジネス上の問題であるため緊急度が高いことになります。
案件の着手時期と完了時期を決める
案件の優先順が決まったら、実施時期を割り当てます。
実施時期が確定した段階で、タスクリストとなります。一つひとつのタスクとして、マネジメントされることとなります。
案件の関係者を捉え、実行担当を決める
案件を実行するにあたっては、要求を正しく捉え、調査を行い、要件を確定していかないといけません。
よって、要求に関わる関係者を正しく捉えます。
経営者からの要求であったとしても、担当からすると少しニュアンスの違うことを言っているかもしれません。
あるいは、顧客などの関係先も出てくることもあります。
関係先を正しく捉えないと、正しい要求を引き出せません。
そして、関係先を踏まえて実行担当を割り当てます。
案件の進捗状況を計測する
案件がリスト化されていますので、それぞれが予定どおり進捗しているかを計測します。毎週などのタイミングで確認していきます。
案件の進捗計測レベルを決める
案件ごとに工程がありますので、予定としての工程に対して、実績の工程が遅れているのか、進んでいるのかを計測します。
計測には、できれば定量的なものがあればよいです。
定量化しづらいのであれば、タスクを細分化して、実施状況を把握するようにします。
要件定義中だけだと進捗が見えません。要件定義タスクが要求確認、現行調査、機能要件、非機能要件などのタスクとして細分化します。
案件の進捗状況を見極める
案件の進捗状況により、状況を見極めていきます。案件によっては順序性がありますので、一つの案件の進捗だけを見ているわけにもいきません。
後続が控えているものは特に着目して見ていく必要があります。
進捗について、できるだけ定量的に捉えますが、それが本質かどうかも見極める必要があります。
完了と認識している工程について、関係先含めて内容を理解し同意しているのか、といった視点でも確認し、本質的な進捗を見極めます。
実行担当別という観点でも案件を見てみます。
一人の実行担当のほうで別な作業で滞っていないかなど、メンバのリソースの観点でも見るということです。
案件状況によりテコ入れを行う
案件の進捗状況に問題がでているようであればテコ入れする必要があります。
テコ入れについては、どこに問題があるのかを探って、問題に応じた対策を取っていくことになります。
対策としてはいくつかの方法があります。
優先順位を見直す
あまり実施すべきではないですが、優先順位を見直すということも場合によっては必要です。
後からでもよいものは、少し待ってもらって今やるべきものを先に片づけます。
実行担当を見直す
実行担当といったメンバに問題があるケースもあります。その場合支援担当を入れるなどの対応が必要となります。
優先順位が高いものばかりになってしまった場合は？
メンバのリソースが限られていて、優先順位もあまり入れ替えることができず、優先度高の案件ばかりになってしまったらどうしたらよういでしょうか。
これについては手の打ちようがありません。
しかし少しでも対応しようとするのであれば、対応する対策と対応しない対策があります。
対応する対策としては、案件としての優先順位は高いですが、案件は細分化できるかもしれません。
タスクの中で順位を調整できるのであれば、その中で順序性を変えて計画を再構築するという方法があります。
タスクではなく、要件が切り離せる可能性もあります。
優先順が高いのは要件１であり、要件２は後でもいいということが調整できるかもしれません。
対応しない対策というのは、優先度を見直せないかという調整に入ることです。
これもできる場合のみの対策ではあります。
この調整の際には相手の立場に立った調整や交渉が必要です。
やる人がいないので、という理由はIT側の理由です。事情を承知してもらうというのは一つの手段ではありますが、相手の立場で、もし優先順位を下げても、別な手段があれば変えられないか、ということを考え提案していきます。
つづく。
コメント