DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

　どんな仕事をする場合でも同じだと思いますが、その仕事の目的や達成目標が明確では無い場合は、どんなに頑張っても、そこから生み出された成果は、お客さまから真の満足を得られることはありません。

　目に見える物を作るプロジェクトを行なう場合は、お客さまは途上段階を目で確認できるため、「これは違う！」などといったご指摘を早い段階でいただけるかもしれません。例えば都市の再開発などでは、再開発のコンセプトをある程度決めた後に３Dで街のイメージを作ったり、モックアップ（外見を実物そっくりに似せた模型のこと）を作り、そのイメージを固めて行く方法をとります。

　一方でソフトウェアの場合は、ＲＡＤでユーザ確認をしながらイメージを固めたり、プロトタイプを作り、そのイメージを固めるなどの方法を取ります。

しかし都市の再開発も然り、ソフトウェア開発も然り、どのようなイメージを作ろうとも、そもそも「何のために作るのか！」を明確に定義し、、それを利害関係者が共有できていなければ、三者三様のソフトウェア仕様になってしまいます。

構想・企画段階でイメージを固めるために上記の取り組みをするのであれば良いのですが、プロジェクトが開始した後にそのような取り組みを行なっているのでは、プロジェクトは迷走してしまいます。

そのため、プロジェクトが開始してからその目的や達成目標を明確にするのでは遅く、その前段である「構想・企画」段階においてその目的を明確にしておくことが、とても重要になります。

構想・企画には大きく分けて２種類あると考えています。

１つは、現状課題を解決するための『改善型の構想・企画』。

もうひとつは、世の中で誰もやっていないことを実現するための『創造的な構想・企画』です。

前者の場合は、現状の課題を明確に出来ていれば、その解決により実現したいことが、構想・企画に書かれる目的になります。しかし後者の場合は、現状の課題からは導き出せないため、思考のジャンプ『創造』が必要になります。

　先日あるSier企業向けに、プロジェクトマネジメントにおける計画段階の研修を講義する機会がありました。その企業の方々は、プロジェクト開始後に発注団体が作成する要件定義書の提示を受けてから、システム開発の作業を行なうスタイルで仕事をする方が多かったようです。その要件定義に対しても、発注団体が提示してきたものであるため、内容に違和感があろうとも拒否せず、しかもその後に発生する仕様変更にも黙々と耐えながら仕事を進められている様子でした。

　その方々に
「プロジェクト計画書に書かれる目的が明確になっていないと、プロジェクトを運営する際の御旗が無いため、その後の要件定義以降の設計工程で、ユーザの属人性に振り回されることはありませんか？」
とご質問したところ、ほとんどの方が
「そのとおりだと思う。」
とおっしゃっていました。

さらに
「なぜプロジェクトの計画が不明確なのでしょうか？」
とご質問したところ、特段の反応はありませんでした。

• プロジェクトの目的は、大概色々な思惑で作られるので、明確化できないのが現実的。
• 「○□を構築する」というソリューションが目的として掲げられることが多い。そのことの是非はともかくとして、ソリューションは明確であるので、プロジェクト計画書の目的が不明確であるという実感は無い。
• そもそもプロジェクト計画書を見てプロジェクトに取り組んだことが無いため、実感が湧かない。
• たとえプロジェクトの目的が明確であったとしても、プロジェクトを開始すると目的は蚊帳の外に置かれ、ユーザの勝手気ままな要望を組んで要件定義以降の設計をやらざるを得ないのが実情。なので、現実的には目的を明確にしてもさほど意味は無い。
• 発注者サイドの業務の流れを気にしたことが無いため、そもそも良くわからない。

などなど、様々な理由があるため、反応がなかったのかもしれません。

　そこでプロジェクトマネジメントで行なうプロセスである「立上げ」⇒「計画」⇒「実行／監視・コントロール」⇒「終結」の意義、特に立上げ段階で行なうべきことをご説明したところ「そうか、そもそも超上流フェーズであるＩＴ構想・企画段階で目的を明確に出来ていないことが、計画プロセス以降のフェーズも不明確・不明瞭な目的を継承したままになり、設計フェーズで要件が決まらないといった状態が起こるのか！」と、受講生の方は気づかれていました。

ではなぜ「なぜプロジェクトの計画が不明確なのでしょうか？」とご質問した際には無反応だった受講生が、上記プロセスのご説明をすることで超上流の重要性に気づかれたのでしょうか？

本件は次回のメルマガでお伝えいたします。

（追伸）
　最近システム再構築に関するお話しをユーザ系企業の情報システム部門の方とする機会が増えています。その中で多く耳にするのが「情報システム部員の高齢化」です。かつて企業にＩＴを導入し始めたころに社内ＩＴ担当として活躍された方々が、そのまま現場レベルの仕事をやり続け後輩を育ててこなかったため、もしくはＩＴ組織を会社としてどのように位置づけるのかを明確にしないまま今に至っているために起こっている事象のようです。数年前に言われていた「2007年問題」と同じ悩みです。経営者は「ＩＴでアプリケーションやハードウェアを構築するのはシステム子会社やベンダーなので、社内のＩＴ部門はその調整だけすれば良い。会社間の調整さえ出来れば、ＩＴの専門的なスキルは不要」との認識を持たれていることが、ＩＴ組織を現場から変革できない理由の１つである、ただ今後とも経営者には、ＩＴ部門の必要性・価値を訴え続けてゆくと、某プラント系企業のシステム部長はおっしゃっていました。昨今の経営者の関心事の１つに「固定費の削減」があります。ＩＴ部門も固定費としてとかく見られる傾向が強いです。そのような状況だからこそ、必要なＩＴ予算を確保することに傾注するのではなく、企業が払える費用の中で、いかに価値あるＩＴを実現してゆくのか、発想を大きく転換しなければならない時代になっている、そう感じています。

＜　前回　｜　目次　｜　次回　＞