
ツールから入るのも手〜情シス目線のプロジェクトマネージメントTips#11
世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。
今日のテーマはプロジェクトマネジメントという主旨からはチョット外れていますが、プロジェクトの周辺で語られていることにもちょっと絡むので書いてみます。
ツールから入る「最悪のプロジェクト」
良く「最悪のプロジェクト」の例として挙げられるのが社長や偉い人が持ち込んできた「このツール」ありきの導入プロジェクト。事業の課題とか現場の問題とか特性を考えずに「このツール(システム)良いから導入してね」と言うことで担当者に割り当てられてしまう・・・・といったケースです。
きっと雑誌とかテレビを見てて思いついたか、どこかのコンサルにそそのかされたとかそういう話なのでしょうが、その結果、それを押し付けられた企画部門とかDX推進部門とやらが、現場との総スカンとの板挟みで右往左往する・・・・みたいな話がよくネット上の記事とかで挙げられています。
そこで登場してくるのが、ちゃんと事業なり業務を分析して「何に取り組むのか?」を決めるのが先で、「ツールから入る」のは本末転倒でお金の無駄遣いみたいな批判です。
いつの間にか時代は変わってる?
しかしながら時代は大きく変わってしまっているのです。
かつてはITツールを入れるとなると何十万円から何百万円もするし、そのツールを動かすサーバーも用意しないといけないし・・・・となかなか費用もかかるし人の手間もものすごくかかるのが当たり前でした。
確かに投資対効果が充分に見込めないと、本来は手を出してはダメでツールありきではなくて、まずは組織が抱えている課題の分析からということになるのは当然なわけです。
しかしながら、世の中はクラウドが普及してきて、使う人数や量で課金される形だったり、無料プランがあったり、そもそも安くて簡単に解約できるSaaSのサービスもあったりと、IT側の障壁はものすごく低くなってきています。従来のようなコスト的なリスクはだいぶん下がって来ているのです。
社長が持ち込んで来る大規模な導入は置いておいても、現場ベースでの導入なら「ツールありき」はそれほどデメリットがなくなっているというのが現状です。
時代は大きく変わってきています。
「ツールありき」だからこそ起きること
それでもやはり「本来は現状の分析と課題の抽出」が先であって「ツールありき」の考え方はおかしい!!・・・・と思う方も居るでしょう。
しかし2つの観点で「ツールありき」は有ってもいいと思います。
ひとつは「ツールから新しい視点が生み出される」で、もうひとつが「現場はなんとなく課題を認識している」です。
それぞれを説明してみたいと思います。
ツールから新しい視点が生み出される
以前の要件定義の話でもとりあげましたが現状の分析からは現状の仕事のやり方やシステムという枠の範囲からしか課題は生まれません。「馬車」の問題をいくら考えても「自動車」という発想が出てこないように、どうしても発想が大きく飛躍することがないのです。
外からのインプットがない限り、出てくる課題も対応策も「目先の改善」にとどまりがちになります。
でも、短期間で他社の事例なんか集まらないし、そのために時間もお金も使わせてもらえないというのが現実でしょう。
・・・・ここで「ツールありき」です
SaaSのツールというのは、・・・・少なくともメジャーになっているSaaSは他の会社の現場で利用されて何らかの課題を解決しているから広く使われているのです。元々のツールのルーツが現場の課題から生まれたというサービスも少なくありません。
そういった意味では費用に良い「インプット」でもあると考えられます。
違う会社の違う視点を取り入れる具体的な素材としてツールは非常に良いものと言えるでしょう。
人間同じところを反復していると、基本的に発想は鈍ってきて新しい発想や視点は生まれにくくなってしまいます。ここにツールという「新しい繁樹」を与えることによって、さらなる視点やアイデアを出すための「繁樹」であると考えてもいいと思います。
そう考えると社長が持ち込んできた、嫌な「ツールありき」もアリなのかもしれません。
現場はなんとなく課題を認識している
現場の課題や問題点を洗い出してから手段であるツールを考えるべき・・・というのはなぜなのかを考えてみます。
この前提は検討する人が現場の課題を知らない人だからです。経営者であったり、企画部門であったり、情シスであったり、コンサルであったり、SIerであったり・・・・たしかにこういう人たちがプロジェクトの中心であるならば、手段であるツールを考える前にきちんとした業務分析が必要になると思います。
・・・・では現場の人が自ら考えて、自らのリスクで試すのはどうでしょうか?
これはありなんじゃないでしょうか、もちろんガバナンスやセキュリティの問題はあるので勝手に始めちゃうのはだめかも知れませんが、そういったチェックをしてもらえれば現場の人による「ツールありき」は有っても良い気がします。
現場の人達だって、言われたことを言われたとおりにやれば良いと考えている人ばかりではありません。日常の仕事に課題感を持って仕事をしている人はたくさんいるはずです。たしかに構造化や言語化はうまくできていないかもしれないかもしれませんが、そういった現場の人による「これ使える!!」にはそれなりの根拠があるはずです。
無料のSaaSを使用して現場で試してみて、それからきちんとした現状との比較をして投資対効果を洗い出し、それを全社としての取り組みに発展させるというアプローチもあっても良いのではないかと思います。
改革改善は両輪で
よくトップダウンなのか、ボトムアップなのか?という話もありますが、これは両方必要なことであって、上からはきっちり戦略を練った作戦を現場に投下し、現場からは実践の繰り返しの中から上に湧き上がらせるというのが理想な気がします。
どちらかだけが頑張るというのも無理がありますしね
いいなと思ったら応援しよう!
