私、キットＰＭはプロジェクトマネジメントに関する
あらゆるご相談、ご用命を承ります。
サービス内容のご確認、ご連絡はこちらからどうぞ。
～～～～～～～～～～～～～～～～～～～
さて、前回はプロジェクトにおける目標とは何かと目的と目標の関係について考えてみました。ちょっと抽象的だったので、今回は具体的な例を上げて目的と目標を設定しながらより深く考えてみます。
少し前になりますが、ニッチといっても差し支えないある特殊な分野のパッケージソフト開発のプロジェクトマネジメントを行った時の話です。最初お話を頂いた時は現行のスパゲティ状態のシステム構造を根本から変えて、フレキシブルで機能追加が簡単なものに変えるということでした。それも、現行機能をバージョンアップする形でリリースするというのです。
あー、これは面白そうなプロジェクトだなと思って現行バージョンの機能と構造を調べ始めたのですが、これが、一筋縄ではいかない実に複雑な構造と機能をもっていたのです。つまり、結構長い歴史の中で機能追加が繰り返され、各機能が密接に影響しあって未分化の状況でした。密結合といいますが、私は温泉旅館構造と呼んでいます（笑 増築につぐ増築でお風呂にたどり着くのも難儀するという、ましてやお風呂からの帰り道は絶対にわからないという、アレですね。
さて、ここではたと困ってしまいました。パッケージメーカーというのは機能アップした新バージョンを定期的にリリースすることが必須のビジネスなわけです。理由は２つあって、ユーザー要求をいかに効率的に取り込むかが新規ユーザーの獲得に大きく影響するということ、既存ユーザーがバージョンアップすることで、確実に売上を確保するということです。特に既存ユーザーのバージョンアップは、ある程度正確な売上見込が立ち、経営的には大きなインパクトがあります。ということは、次期バージョンアップのタイミングがズレ込むと、売上予定に大きく影響するわけです。このタイミングで全く新しいアーキテクチャに変更し、尚かつリリース次期を守るというのは、あまりにリスクが大きすぎます。
そこで私はプロジェクトオーナーに、アーキテクチャの変更と次期バージョンのリリースの２つは同時には無理と判断するので、どちらを優先するのか？と訪ねました。とはいっても、ちゃんと状況分析報告書を作成して説明した上ですが。このプレゼンテーションは今思うと相当力が入っていたのでしょう。幸いにもオーナーには冒険より経営を選んでいただけました。結果として、既存システムのまま機能アップを図るというように目的と目標を変更したわけです。このプロジェクトでは、筆者が参画した時にはすでに「目的」が設定されており、その目的を達成するために全力を尽くさなければならない立場であったワケですが、計画作成段階で目的の妥当性検証を行ったのが正解だったということです。もちろん提案を受け入れて判断したオーナーも素晴らしかったということです。
ここで言いたいのは、プロジェクトの「目的」設定は大事でかつ難しいということ。プロジェクトのどの段階であっても、本来の「目的」を意識して必要であれば見直す勇気を持つということです。
さて、次回から「日本の会社文化とモダンPMの対立」（またまた重いテーマかな？）について考えることにします。