新IT導入・システム開発プロジェクトの説明に入っていきます。
プロジェクトは大きいものから小さなものまでありますが、ここではプロジェクトと言っているくらいなので、事業に大きなインパクトのあるプロジェクトと捉えてもらって構わないです。
新ITの導入やシステム開発を行うということは、一定規模の投資であって、他社を差別化するサービス提供であったり、業務プロセスの抜本的な効率化を狙ったものであったりして、それ相応の覚悟が必要なものとなっています。
関わる人も多くなってくるため、人の準備も必須となります。
新IT導入・システム開発を行うにあたっての準備
プロジェクトは非日常となります。非日常に入っていく上では、現日常が受け入れる準備できていないと、なかなかうまくいきません。
既存IT保守運用のマネジメントについては説明してきましたが、既存ITが安定していないと非日常を受け入れることなど到底できません。
よって、事業として取り組みたいIT事案があったとしても、既存ITの状況を確認してください。
プロジェクトの開始は非日常のマネジメントの開始
プロジェクトが開始されることは非日常に入ることですが、いわゆるプロジェクトマネジメントと呼ばれる手法が導入されます。
しかしこれはプロジェクトだけを見たマネジメント手法であり、実際は現日常があるわけですから、目を背けるわけにはいきません。
現状の状況を踏まえたうえで、特に新IT構想段階においては、その上にプロジェクトが上乗せされるイメージで、全体も見たマネジメントが必要となります。
場合により社長自らが進めている場合もあるでしょうし、関わるメンバとしては稼働工数だけでなく、持っている知識が重要となってくるため、誰が参画するにせよ知識の稼働状況を踏まえた実行計画が必要となってきます。
構想・企画でのマネジメント
新IT構想とは
構想段階は、全く何もなかったところから、何らかの新ITに関するニーズが生まれ、検討を開始することになります。
新IT構想とは、文字通り新しいITの姿を描くことです。
ただしITの姿だけでは構想を表したことにはなりません。
ビジネスの新しい構図とITの新しい姿をともに描くことになります。
また、現状から新IT導入後へ移行されるイメージも合わせて描かれます。
運用体制含めて移行できないのであれば、絵に描いた餅となります。
さらに、ただちに新ITの姿を描くことはできず、各種検討を重ねた結果となるはずです。その検討経緯もわかるようにしておきましょう。
新IT企画とは
新ITの構想という絵姿がイメージ出来たら、どのように進めていくかを決めていきます。
ここではどのくらいのコストが掛かり、どのくらいの効果がでるという金額的なところに始まり、実行体制や実行スケジュールを策定します。
現時点で分かっている課題などがあれば、それも企画の中にあるべきものです。
構想・企画段階でのマネジメントとは
ITの構想から企画にかけての流れは、ゼロの状態から、あるべき姿をもやもやから徐々にはっきりさせ、その後どのように進めていくかということを決めていきます。
もやもやをはっきりさせるプロセスは、簡単なものではありません。
経営の方向性もITの方向性も両方わかっている人がいるのであれば、それほど苦労はないかもしれません。しかし、経営とITの両方がわかっていないことのほうが多いです。
テーマが最初から絞られているのであれば、ITの導入ありきとなることもあるでしょうが、そのような単純なものは構想という段階を経る必要はありません。
構想と言っているからには、こういうのも考えられるし、あういうのも考えられる、といったように様々な代替策から検討していかないといけません。
重要なのは、発散と収束のプロセスを経て決まっていくということです。
様々な選択肢から検討するよう一旦発散しないと、後からやっぱりほかの手段があるのでは、という議論が蒸し返してしまいます。
よって、そのマネジメントのプロセスにおいても、単純に収束していくプロセスをイメージしたものではなく、一旦発散させるようなプロセスも含めて全体を、マネジメントしていくことになります。
発散中のタスクは増えたり広がったりしていくため、スケジュールやコストを見極めるのは難しいかもしれません。
しかし、テーマの大きさや論点数、そしてそれらの重みから想定して、発散してから収束するプロセスを計画し、マネジメントしていきたいです。
構想・企画段階でのタスクステップ
- テーマ抽出
- 実現方法の予備調査
- 効果想定・予算感策定
- テーマ論点抽出
- テーマ絞り込み
- 現状の把握
- テーマ論点再抽出と再絞り込み
- 目的の再確認
- 要求事項と実現方法のとりまとめ
- 将来像の策定
- 構想テーマの企画とりまとめ
テーマ抽出
構想が始まってからには、何かテーマがあるはずです。
テーマとは、ITを使って課題解決できるであろうと思っている課題分野です。
在庫をもっと減らせるのでは、という課題があったとしたならば、発注や受注のプロセスの改善とともに、ITによる解決が考えられるでしょう。
いくつかの課題感がありテーマになり得るものがあるのであれば、まずはどのテーマを検討するかを決めます。
デジタル化推進というテーマがあったとします。
そのような世間の流れに振り回されたテーマだと、何をやっていいかわからないという経営者の方も多いのではないかと思います。
デジタル化推進というのは手段が目的になっている典型例ですので、あくまでも顧客獲得や業務プロセス効率化に関わるような領域をテーマとして、結果デジタルを手段とすることを検討しましょう。
実現方法の予備調査
テーマについて構想を進めていく価値があるのかどうか、予備調査を行います。
予備と言っているのは、実現手段がどういうものがあるのか、それにより解決できそうなのかというレベルでまず調査するということです。
ここで、実現方法が見当たらなければ、構想を進めても断念せざるを得ません。
実現方法については、さあ探そうといっても、テーマに合う方法が見当たらない時もあります。
それとなく構想が上がってきたときには、実現方法も探りを入れているのではないでしょうか。その行為をもう少し進め、より実現に近づけるべく、代替案を考えていくことになります。
効果想定・予算感策定
テーマに対しての実現方法がいくつかあったら、金額感を把握します。
効果についても金額で想定します。
顧客獲得できることにより売上が1億円上がるであろうとか、業務プロセス改善することで在庫費用が5千万円下がるであろうという算出を行います。
金額化したものを利益換算し、掛ける費用に見合うものかを想定し、見合うものであれば、納得のいく金額にて予算化をします。
構想段階ですので、予算は概算レベルです。しかしここで金額感がないとその後の進めるかどうかの判断ができませんので、金額は把握します。
テーマ論点抽出
テーマのITによる実現方法について、検討を進めるにあたって、議論をすることで論点を抽出します。
実施すべきことは一つのテーマであってもいくつかあるはずです。
それは、業務ルール改善のこともありますし、価格や取引条件変更のような手段かも知れません。それらと同様にITを導入することによる実現方法も論点として挙がってきます。
これらは要求リストとしてまとめるとともに、要求を確定するために議論すべき課題を論点とします。
論点の切り口としては、例えばこのようなものがあります。
テーマ絞り込み
実施していくとわかりますが、ほぼなんとなく実現方法が見えていたはずのテーマであっても、検討すると様々な論点が発生し、当初考えていた実現方法とは違う方向に向かうことがあります。
一旦発散することは重要であるため、論点が増えることは歓迎します。難しいのは論点が増えることで、検討時間も増えることになるのですが、その工数が見えづらいということです。
よって計画もしづらいということになります。テーマがすんなり検討される想定時間に対して、実際の発散を経た検討時間は3倍くらいになるのではないでしょうか。
テーマが拡散した場合は、絞り込みが必要です。
絞り込みにあたっては、比較検討を行い絞っていきます。
しかし多くの場合は直感的に絞れないことが多いです。よって費用対効果による金額評価とメリット・デメリットによる定性評価を行い、選択していきます。
現状の把握
絞り込まれたテーマを実現するために、将来像を描きますが、その前に現状の把握を行い、描きます。
テーマを検討するにあたっては、現状との対比で改善点が見出されることが多いです。よって現状は見えているように思えます。
しかし、ここで言う現状は、テーマの領域全般を対象としないといけません。
というのは、全般を改めて見たときに、他に影響する箇所が見出されることが多いためです。
直接の影響がなかったとしても、影響しないようにしないといけないということにもなります。
ここでは、現状の業務プロセスと既存ITの両方が現状の対象となります。
いずれも、変革する部分と維持しなければならない部分とがあるはずですので、見極めます。
テーマ論点再抽出と再絞り込み
現状についてテーマ領域全般を検討したら、テーマに対する論点が再度抽出されることが多いです。
現状の業務プロセスの中で、思ってもいなかった領域にも影響があったため、対応方法を検討する必要があるといった点です。
現状の把握については、省略されてしまうことがよくあります。
現状は、今まさに現状の中にいるため内部の人にとっては当たり前で、考える対象にしないからです。
もし外部の人を構想段階で参画させていたら、現状のすべては知らないため、部分的にしか検討することができません。
部分的な検討で推し進められていくと、結果プロジェクトは破綻することが多いです。
この段階においては、現状の把握を踏まえて論点を再抽出します。一旦また発散のプロセスを経るということになります。
その上で、再絞り込みというアクションを行います。
目的の再確認
ここまでくると、様々な案と論点が出てきます。
論点を議論してIT化のテーマを改めて並べてみると、当初考えていた目的と少し違ってきていることがあります。
目的が契約のペーパーレス対応ということであったとします。
対象の範囲や実現に対するコストなどを検討し、関わる現状の業務実態を整理してみました。
すると、ペーパーレス化をする以前の問題として、契約の管理方法が統一されておらず、非効率になっているということがわかりました。
そのため、目的は業務効率化をいう方向とし、合目的性を確認していくことにしました。
要求事項と実現方法のとりまとめ
テーマから議論してきた結果を整理していきます。
それらを要求事項としてリスト化します。
要求事項と同時に、論点として検討してきた実現方法も記載し、取りまとめます。
論点として挙がったが、却下したものもあると思います。それらは最終版には不要ですが、記録としては残しておきます。
却下した理由も明確にしておきます。
そうしないと、却下した案が今後再燃してきてしまうからです。理由が納得できるものであれば、再燃はしなくて済みます。
将来像の策定
構想の最終段階では将来像を描きます。
目的と目的を達成するための実現方法の方向性が定まってきているはずですから、実現した後の姿を描くことで、より構想が分かり易いものとなります。
将来像は現状との比較においてさらに分かり易いものとなります。
比較的大きな範囲での構想となるのであれば、全社レベル、プロセスレベル、業務レベル等の3段階くらいで描くとよいです。
構想テーマの企画とりまとめ
構想の方向性が定まったら、企画として取りまとめていきます。
企画として策定したいのは、以下のとおりです。
- スケジュール
- 実行体制
- コスト計画
- 課題
スケジュール
今後進めていくスケジュールとなります。
実現すべきことが複数あって優先順位があるのであれば、順序性も踏まえたロードマップとして描きます。
やってみなければわからないようなものも中にはあるでしょう。それでもやるべきと判断されるものがあればアジャイル的に進めていく計画とします。
アジャイルの場合は、結果によりその後の実行範囲が異なってくる場合があるので、スケジュールに分岐を入れることもあります。
実行体制
どのような体制を進めていくかを描きます。
実行する人や工数が捻出できなければ、構想は夢に終わってしまいます。
コスト計画
コストが予算としてどのくらい予定されていて、いつ支出するか等の計画を策定します。
効果としての実現後の利益計画を合わせて、キャッシュフローも算出できるのがベターです。
課題
企画や計画を立てる段階にあっても、まだ課題が残っていることもあります。
構想段階では、詳細な検討の上で実現方法まで決められればいいですが、実際は検討が及ばず課題として残ることも多くあります。
論点の検討が残っているというスコープに対する課題もあれば、実行者いなかったりスケジュールに入らなかったりといった進め方の課題もあります。
また、現時点では課題と認識していないが、将来に発生するかもしれないものは、リスクとして認識すべきです。リスクがあればそれも企画の中に盛り込みます。
構想・企画段階でのベンダー・コンサルタントの関り方
新ITの構想・企画は、社長もしくは今いる人たちでできるのであればいいのですが、新ITのための技術もわからないし、導入するための現状の把握の仕方などもわからないということはあります。
その場合、外部に頼む場合があります。
新ITの規模や適用範囲などにもよりますし、そもそもどの範囲で何をすればいいのかもわかっていないということもあり、頼む範囲や金額は様々となります。
一定規模のプロジェクトになる想定であれば、ベンダーやコンサルタントに依頼して、構想に参画してもらい、あわせて将来像の検討や金額を出してもらうということを行います。
ベンダーに頼む時の留意点
ベンダーということは、ITの導入そのものもできるという前提となります。
構想・企画ができているのであれば、複数のベンダーにも提案を求めることは可能です。
しかし、特定のベンダーにこの構想から参画してもらうと、そのベンダーが実行できる方向性に導かれてしまう可能性が高いです。
まず、他に頼むかもしれないのでれば、そのつもりで取り組んでもらうようにします。
多くのベンダーは、構築・導入といった大きな作業領域まで受注しないと割に合わないため、構想・企画だけを切り出した依頼は受けてくれません。もしくは、ベンダーとして自社が構築や導入を行う前提とするのであれば、サービス的に構想段階を手伝ってくれるということはあります。
いずれにしても、ベンダーに導かれて、本当に実施したい目的からずれたり、割高となったりしないよう、自らよく見ていかないといけません。
コンサルタントに頼む時の留意点
ベンダーから中立なコンサルタントに頼むということも有効です。
そうすれば、特定のベンダーのサービスに偏ることはなく、最適な方向性を導けそうです。
ただし、この場合においても注意点はあります。
そもそも高額です。現状見えていない課題認識をも可視化するようにしていき、問題点を解決する方向性を出すという行為は、簡単なことではありません。よってそれなりのノウハウに基づいた高単価な仕事として、実施されることになります。
コンサルタントに頼んでも、その後うまくいくとは限りませんので注意が必要です。
自分たちが言ったことに対して、理解して可視化させるのは非常にうまいです。しかし、ベンダーと違って、その後の実行にあたっては専門外であることが多く、実はかなり難易度が高い企画になっていることがあります。
また、言ったことは描いていても、言っていないことは描いていない部分もあります。言っていないのだから当たり前と思えるかもしれませんが、実行段階では後々問題の原因になります。
つづく
コメント