プロジェクト開始前にやること

これもITプロジェクトあるあるなのですが
これまでにも何度も言っているようにITというものは「ツール」です。
その為、手段ではあっても目的には通常なりえません。
にも関わらず、何故かITプロジェクトがスタートを切ってから、
何をしたいか考え始めたりすることが多いです。
ツールを先に決めて、そのツールで何をするかを後で検討するという状態ですね。

プロジェクト開始前にはものすごく大雑把な方向性だけが決まっていて
予算と規模感だけで製品選定に入り、プロジェクトスタート！
スタートしてから、

じゃあ、どうする？＊＊するって言ってたけど、具体的にどうやるの？

みたいな話になることを、今まで幾度となく見てきました。

面白いことにITのプロジェクトでは、
この要件定義の手前の段階の話を検討するフェーズは設けられません。
なのに、プロジェクト開始前に検討しないで、
プロジェクトはスタートするという摩訶不思議なことが頻繁に起こります。
（これはコンサル側の思惑もあると思いますが・・・）

また、これとは別に、息の長いプロジェクトの途中でだんだん目的を見失って、
カットオーバー直前には「導入すること」が目的にすり替わってしまう
という事もまま起こります。

いずれも「やりたいこと」と「そのためのツール」の立ち位置が
逆転してしまっているのですが、プロジェクトの開始前に
「ITを使って何をしたいのか？するべきなのか？」をしっかり検討しないまま
プロジェクトスタートに踏み切っている時点で、目的を見失う種は植えられていると言っていいと思います。

そういう意味では、

そもそもITプロジェクトのスタートがどこからなのか？

という事を、はき違えている人が多いのかもしれません。

そもそも論ではありますが、プロジェクトを立ち上げる前には
自分の会社で困っている事
これがあるはずです。

これがあるから、
解決しないとまずい
につながり、
じゃあ、ITで何とかしてみようか
と続くはずですが、この最初の
自分の会社で困っている事
をしっかり意識しない、もしくはプロジェクト終盤まで見失わない
という事が出来ていない為、
最終的に「システム導入が目的」となってしまうわけです。

IT導入を始める前に、まずはここをしっかり落とし込まなくてはいけません。

例えば単純に

システムが老朽化したので新しくしないといけない

というのが「自分の会社で困っている事」だとします。
本当にこれだけが理由で、現状のシステムで満足している
という事であれば、同じシステムの後継バージョンに刷新すればよい
という事になると思います。

しかし、往々にして
じゃあ、これを機に、あれとこれとそれをなんとかしたい
という話が持ち上がってくることが多いと思います。
この部分をしっかり具体的に落とし込む必要があるのですが、
往々にして各部門からやりたいことをザックリ聞いて、
それが「出来そう」なシステムをいくつかピックアップして
相見積もりをとって、導入システムを決めて、プロジェクトが動き出してから
やりたいことを詰め始める
というケースが非常に多いです。

そうではなく、導入システムを決める前に
もっとやりたいことを詰めておかないといけませんし
今回のプロジェクトの目的（達成目標）をもっと絞っておかないといけません。
上記の例でいうならば
システム老朽化の対応を最優先事項として置き、
その上で

システム刷新において、現在の業務における課題の洗い出しをし
それらが具体的にどういった不具合をもたらしているのか？
それが解消された暁にはどういったメリットがもたらされるのか？を整理し、優先度をつける

必要があります。

それをしないままフワフワした状態で始めると
何故か、システムを新しくするつもりだったのに、
延命処置をしただけというような終わり方をしたり
本当にやりたいこと、やらねばならぬことが脇に追いやられ、
効果は少ないが、とりあえず簡単にやれそうな機能を実装して「やった気」になる
というような、何を目的としていたのかわからないような状態になってしまいます。

また、そういった意思入れをしっかりしないままSIerに見積もりを出しても
SIerにも意思が伝わらないので、
とりあえずリスクONしまくった高額見積もりを提示されてしまい
予算の枠に入らずに、プロジェクトそのもの断念といったようなことも起こり得ます。

このように、ITプロジェクトのスタートの段階で
やるべきことは明確にあり、
それをやらないでプロジェクトのスタートを切ることが本当に世間には溢れており、
その結果、無用にプロジェクトの難度を上げてしまっています。

ただ、じゃあ現実問題として
その部分まで含めてコンサルティングしてくれる会社があるか？
というと、そうそういないというのが実態です。

何故そこをしてくれないのか？
というのは一旦脇に置いておいて
じゃあ、そこをするのは誰なの？というと、
ここで名前が挙がるのが、社内SEになります。

社内SEはその名の通り、社内にいるわけですから、
プロジェクトのタネの段階から関わっていくことが可能です。

とは言いつつも、組織の縦割り構造だったり、SEの社内的な認知度によっては
他の部署のプロジェクトに首を突っ込みづらいこともあるかと思いますが
その壁を乗り越えて、社内SEとしての価値をアピールしてくれる人たちが現れてくれれば、会社にとっても良い兆候ですし、社内SEとしても自身のバリューを見出すことのできる機会になるはずです。