ホーム > ブログ > 竹内博樹の記事一覧 > 【第14回】ITの構想・企画がブレていると、その後のプロジェクトも迷走する


【第14回】ITの構想・企画がブレていると、その後のプロジェクトも迷走する

Pocket

< 前回 | 目次 | 次回 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< 前回 | 目次 | 次回 >

Pocket

| 目次

Profileプロフィール

竹内博樹
竹内博樹
1991年 筑波大学卒業後、三和銀行のシステム子会社である三和システム開発株式会社(現、三菱UFJインフォメーションテクノロジー株式会社)入社。同社にて銀行業務のリテール、法人、国際の各分野において、大規模プロジェクトにおける企画・設計・開発に、主にプロジェクトマネジメントを実行するマネージャとして携わる。また開発後の保守にも従事するなど、幅広い業務でマネージャとして活躍。2004年より当社にて、大規模プロジェクトにおけるPMOの運営およびプロジェクトマネジメント支援や、IT部門の組織改革等、幅広くコンサルティングを手がける。 保有資格:情報処理 プロジェクトマネージャ、PMPほか。PMI会員、PM学会会員。

Recent Entries最近の記事

このページのトップへ