プロジェクトマネージャの仕事には「賭け」が必要だ

今日改めて実感したこと。

プロジェクトマネージャの仕事には「賭け」が必要だ。

お客様のシステムを稼働させるために、私たちは厳しい要求をクリアしなければならない。

時には「そんなん絶対ムリ！！」と思うような要求もある。

しかしそんなとき、話を聞く前に要求を却下するようでは信頼は得られない。

「そんなの余裕でできますよ」というスタンスを取り、お客様のニーズと開発側の困難さを天秤に掛けつつ、ギリギリの交渉を行わなければならない。

スケジュール・費用・品質、全て満足のいくラインを獲得するための交渉を行い、結果的に自分たちの望む結果を得る。これがプロジェクトマネジメントの面白さでもあり、リーダーの醍醐味でもある。

「そんなの簡単にできますよ」

と私が発言すると、私の背後で開発者（プログラマー）が

「・・・・そんなんできるわけねーじゃん・・・」

とぼやく声が聞こえる。

そんな声が背後で聞こえたとしても、弱気になってはいけない。

大丈夫、私にはプランがある。

この交渉がプロジェクトの成否の鍵を握るから、まあ焦ってはいけない。

私だって彼ら（プログラマー）に余計な工数は使わせたくない。

お客様の「趣味」のような、トリッキーな要求に時間を割かれたくはないのだ。

だけど、お客様がそんなトリッキーな要求にこだわるのは、絶対に何か理由があるはず。

そしてその理由はコンピュータの問題ではなく、お客様内の人間関係のしがらみによるものなのだ。

情報システムを使って人間関係のイザコザを解決しようとすると、とたんに情報システムはいびつな形になる。

プロジェクトマネージャは、

「そんなトリッキーな仕様、いままで聞いたことありませんよ～」

「そんな仕組み、絶対上手くいくはずないですよ～」

などと間違っても言ってはならない。

それは、お客様の人間関係の悪さを小馬鹿にするようなものだ。

「なるほど、そういう仕様にしなければならない背景がきっとあるのですね」

と解釈すべきなのだ。

お客様の置かれている状況を理解し、仕様の意味を考えてあげるべきなのだ。

その上で、こんがらがった人間関係の糸を一本ずつ解いてあげればいい。

もちろん私たちが全て解けるのだったら苦労はない。

要は、仕様が混乱している相手同士で会話をしてもらえばいいのだ。

情報システムという題材を元に、共通のネタで会話をしてもらえばいい。

そうすると矛盾もハッキリ認識できるし、問題はコンピュータではなく自分たちの中にあることに気づいてもらえる。

こうなると、本来必要であるはずの仕様は、既にお客様自身が見つけてくれる。

これまでトリッキーだと（我々にも）思われた仕様がリファインされ、より生き生きと運用される仕組みに落ち着く。

開発者にとっても想定しやすい、作りやすい仕様にモディファイされるのだ。

私は後ろを振り向いて、背後でぼやいていた開発者に言う。

「なっ！予想通りの結末になっただろ！」と。

*:..｡o○☆ﾟ･:,｡*:..｡o○☆

こんな私は、開発者泣かせのプロジェクトマネージャーなのかもしれません。

しかし、こういうプロセスを通じてお客様からも開発者からも信頼を得ていくスタイルが、私のやり方なのだと実感しました。

関係者の皆様、いつもヒヤヒヤさせてごめんなさいｍ(＿　＿)ｍ