プロジェクトにおける目的と目標 -2- | キットPM奮闘記 改め キットビジネスアナリスト奮闘記

キットPM奮闘記 改め キットビジネスアナリスト奮闘記

PMの世界からビジネスアナリストへ、キットPM2.0を目指して奮闘中です。BAを超上流とか言いますが、当たり前のようで難しいビジネス要件をどうやればちゃんとまとめられるのか、皆さんとご一緒に考えていきます。


 前回、プロジェクトにおける目的の設定が結構いい加減に行われているという話しをしました。どうしてそんなことが起きるのか?当然の疑問ですが、そのことについて考えを進める前にいい加減な目的設定でプロジェクトが進んでいくと、何が起きるのかについて考えてみます。そのほうが、問題の大きさがはっきりするように思えますので。

 
 さて、あらためて聞きますが一般的な営利企業の目的とはなんでしょう。営利ですからお金を稼ぐことですね。当然です。でも、いくら売上があっても利益がでないと成り立ちません。ということは、ただ稼げばいいということではなく、儲けなければいけないということになります。まだ、一瞬ヒット商品を出して大儲けしても、ヒットが続かないと企業は終わってしまいます。つまり、営利企業は「儲け続ける」ことが究極の目的になるわけです。もちろん、どうやって儲けるかや、どういう考え方で儲けるかなど考えないといけない大事な要素は沢山ありますが、もろもろを削り落として最後に残ったものが「儲け続ける」になるわけです。いろいろな企業のホームページを覗いて、企業理念を見てみると、芯にあるのはこれですね。

 会社の中で一つの業務形態である「プロジェクト」の目的も、実は究極の企業目的に結びつくものでないといけないと、私は考えています。つまり、プロジェクトを実施したその成果は、どのように会社の利益を獲得するのに役立つかということです。この観点を持ってプロジェクトの目的を捉えることは重要です。ちょっと片苦しくなりましたが、大事なところですのでよく考えてみましょう。

 前回の例で考えると「会計システムをダウンサイジングする」のでプロジェクトを立ち上げてくれと、上の方から現場のPMに指示がくるわけです。ここでPMがなにも考えずに、では「会計システムダウンサイジングプロジェクトを開始します。」と受けて、ダウンサイジングはどうしたら一番効率よく達成できるかと考え、計画し、行動します。ありがちな構図ですね。そして、一見まともな行動にも思えます。まぁちょっと極端な例かもしれませんが。
 さて、PMは決められた予算と期間の中で全力を尽くそうとします。一番リスクが少なく確実な手法は、ホストで動いているCOBOLのシステムを、自動変換してPCサーバーで動かすことだと考えたとします。手修正など多少の手間は発生しますが、一から新しく開発すると自社要員のスキルの問題、協力会社との関係など考えると、ずっといいアイデアのように思えたからです。仕様も現在のものを踏襲できますし、業務に対する影響が最小に押さえられるはずです。

 ところが、経営者の期待としては「運用コストの削減」「他システムとの密接な連動」「新機能の追加」なのです。PMがプロジェクトの基本構想を提示した後、おもむろにダメ出しされるわけです。PMの当初の考え方では要求に対応できないkない可能性がでてきました。また、練り直しです。貴重な時間を無駄に使ってしまいました。さて、今度はダウンサイジング+αの要件を満たす方法を考えなければいけません。でも、経営者が気にしているのは業務が充分に回せて、株主へのサービスをより高める。ことにあるわけです。経営者から見るとダウンサイジングが必要かどうかの要素はそれほど大きくないのです。もちろんITシステム全体の将来性をどう考慮するかという問題はありますが。

 つまり、PMが取り得る選択肢として従来のホストのシステムの改良やハードウェアの変更、保守契約の見直しなど、ダウンサイジングとは違った観点での可能性ができくるワケです。

 どうです?幸いにこの例では最終的に(時間は掛かりましたが)正しい目的にたどり着くことができましたが、チェック機能が正しく働かない場合、当初の方針でプロジェクトが進行してしまう危険性もあります。世の中ではそのようにして作られたITシステムが沢山あるわけですね

 次回は、別のパターンで目的の設定が不十分な場合を考えていきます。