今や色々な組織管理技法があり、スクラムはソフトウェア開発者ではなくコンサルの方がより雄弁に語るものとなったので、迂闊に「プロジェクトマネージャー」「プロダクトオーナー」「プロジェクト管理者」といった言葉を使うと悪いことが起きそうな気がしますが、ここでは盛大に無視して使いまくりつつ、その意味はざっくりとソフトウェア開発の現場でそのプロジェクトの日程や開発する内容を取り決める役割の人、くらいに留めておきます。
世の中には多くの謎があり、そのいくつかは科学の力を持ってしてもいまだに解き明かされていない（どうして「re」は「lemon」の「レ」なの？）のですが、ソフトウェア開発における謎のひとつに「営業がプロジェクトマネージャーをやるとプロジェクトは決してうまくいかない」という法則があります。さらには、最近ではそれに加えて「営業がプロジェクトマネージャーをやるとプロジェクトは決してうまくいかないのに、なぜかいつも営業がプロジェクトマネージャーをやっている」というのもあります。
もうずっと以前のことですが、受託開発の現場にいた頃に初めてそんな事象に遭遇したのは今でもよく覚えています。当時、支払額はよかったけれども非常に日程がタイトな受託案件に携わっていました。日程がタイトなだけでなく、決済などシビアな機能もあった上に機能仕様も手探りなままだったので、連日徹夜での作業が続きました。クライアント企業の社長が近くの六本木で飲んでいたのでそのまま真夜中に数名の女性を引き連れて視察に来たこともありましたが、あれはなんだったのかもまだ科学では解明しきれていません。また私を含めメンバーも選りすぐりとは言い難いもので、社内からはプログラマとして筆者が参加し、企画職から移動してきたばかりの営業が一人、それに急遽かき集めた派遣会社のプログラマが二人追加されただけの非常に厳しい体制でした。まあ、この状態ですから誰が管理しようとプロジェクトはうまく行くわけがないのですが、悪い前提条件はそれだけではありません。派遣できていたプログラマのうちの一人は全くコードが書けず「わたし、配列ってよくわからないんです」などの衝撃発言も飛び出す人材で、もう一人はプログラミングの力量はそこそこで話をしてもとても面白い愉快な人だったのですが、なんというか自分のペースを決して崩さないタイプで、スケジュールが詰まっているのにこちらが徹夜明けで客先とミーティングしている間に楽天でずっと買い物していました。彼は時間給だったので、楽天で買い物している間にも給料をもらえるわけですから、なんだかプロのバイヤーみたいですね。
過労でその場で寝てしまう前に、私が彼に向かって携帯を投げつけていたのを見たという人もいましたが、違います。ショックで手に持っていたのをぽろりと落としただけです。
さて、そんな第二次世界大戦の南太平洋の戦場のような末期的な現場である日、朦朧とした頭でふと顔を上げると、何やら営業の人が怒っているのに気がつきました。どうやら理由は何か不具合があったからなんだそうです。話を聞いていてしばらく意味が理解できなかったのですが、ようやく整理できた頃に最初に頭に浮かんできた質問は、
「お前、どっち向いて仕事してんの？」
でした。うん、不具合が起きて困っているのはわかる。だけど、バグが発生するのは誰のせいなんだろう。プログラマがサボっているから？ではバグを発生させることがないプログラマを用意すればいいの？局所的な条件でもない限りは原理的に無理ですよね？不具合というのは、それをあぶり出してチェックできる体制と時間がきちんとしていればそれなりに減らすことができる、そんな性質のものなんです。それを用意しないなら、運を天に任せてじゃんけんで物事を決めるのと大した違いはありません。少なくとも、プログラマに怒るというのは意味がわからない行動です。
しかし、人間は何の理由もなく怒るような状態にはなかなかならないものでもあります。つまり、この営業の人が特別に異様な精神状態にあるのでもない限り、何か怒る理由があるはずです。そこで、少し話を聞いて彼女の行動の動機を確かめることにしました。すると、いくつか面白い言い分を聞くことができました。その中でも特に面白かったのは
・自分はお客様の声を代弁しているのだ
という主張でした。そっか、金を払ってるのに何やってんだ、というお客さんの声をそのまま伝えたつもりなんだね。
基本的に、営業職というのはお客さんに「はい」と返事してもらうのが仕事です。「これを買ってください」「はい」、「これも買ってください」「はい」、「できれば追加でサポート契約もしてください」「はい」、という具合に物事が進むのが理想です。そのため、お客さんが「はい」と答えてくれない障壁は可能であればいずれも無くしてしまいたいという強い動機があります。「もっと安くならない？」「ここ、もうちょっと変えてくれないかな」「工期が厳しいけどなんとかしてよ」といったクライアントの要求に対して、自分の会社に不利だからと全部突っぱねていると失注しかねないわけで、可能であれば全部飲んであげる方が、少なくとも表面的には有利になります。それに、人間は目の前に相手に対して常になるべく「いい人」でいたいという欲求があるらしいですからね。
でも、給料はお客さんからもらっているわけじゃないのまた事実なのです。
もし営業職の人が経験豊富でそのような動機付けに対してもう少し長期的な視点を持ち合わせていればそれなりに抑止できるのかもしれませんが、それでもインセンティブの方向を変えることはできないわけで、たとえ利益率の上限を定めてそこに金銭的インセンティブを与えたとしても、失注するよりはギリギリの線でも契約した方がマシというのに変わりはありません。つまり営業職は基本的にクライアントと利害が一致してしまいがちなので、そのためプロジェクトには営業職に対して歯止めとなるような利害関係のある立場の人が必要になります。これはインセンティブがそうなっている以上は個々人の賢さを越えたところにある傾向なのです。
いくら営業職にとって短期的・局所的に利益になるとはいえ、そのために自社により負担をかけてしまえば結局共倒れになるわけですから、誰かがうまく線引きをしなければいけません。プロジェクト管理者がこの歯止めの役割を果たすのが理想なのですが、もし営業職がプロジェクト管理者であれば、余程のことがない限りそれはちょっと期待することができません。ソフトウェア会社の価値はいい製品を開発できることだけではなく、それを継続できること、そのための利益をあげられることがセットになっている必要があります。その実現のためには、営業職に課せられたインセンティブはあまり適切ではないのです。
しかし、案件というのはまず営業が客先と交渉してスタートするもので、日程や機能の調整の場にも必ず営業が出席します。そしてこちら側の言い分も特に案件の最初のステージでは営業が会社を代表して交渉するものなので、どうしても営業が案件自体をドライブすることが多くなってしまいがちです。そこで、技術寄りの担当やプロジェクト管理の担当を早めに投入して営業の利害だけで話が進んでしまわないよう抑制しなければいけません。特に体制が整っていないベンチャー企業ではどうしてもその辺りのケアが手薄になります。またプロジェクト管理担当がすぐ営業とつるんで遊びに行ってしまうような人選も避けないといけません。優秀な営業ほど人たらしも上手なのです。
というわけで、営業って一種の二重生活を送ることになるんですよね。クライアントに向ける顔と、自社に向ける顔の両面を使い分けるスパイのように。特に優秀で会社に利益をもたらす人ほどこの二重性のコントラストが強くなります。まあ妹の彼氏を評価する場合はこの傾向はちょっと不利になるかもしれませんが、営業職としてはこれが適性なんだと思います。繰り返しますが、これは個々人の賢さを超えたところにある傾向であって、ミクロ経済学では人はインセンティブに影響されるとあります。インセンティブというのは人に何かをする動機を与えるもので、それに影響されるのだから、人は動機に動機付けられるということになります。これは絶望的な話ではなく、人はそこまでアホではないという救いでもあります。詳細は以下のビデオに解説されています。
さて、結局、くだんの営業の人は、どっちを向いて仕事していたのでしょう。多分、自分自身だったのだと思います。うるさいクライアントとノロマで間抜けなプログラマの板挟みになって、正直うんざりしていたのでしょう。でも、そんな時こそ忘れてはいけません。こんな体制と条件で案件のゴーを決断したのは誰だったのかを。あるいは、会社の売り上げが思わしくなく投資家に毎週のように締め上げられていると切々と語りながら、最終的には現場の判断でゴーしたという体裁にした経営者のことを。使われるもの同士がいがみ合っていては、いつまでもそこから利益を得る側の思う壺なのです。
繰り返しになりますが、大事なことなのでこの点は強調しておきます。これは営業の人が個人的な能力に問題があるからだという話ではありません。単純に、どうしても営業にはクライアントの言い分に従うことが短期的には利益になるので、そのように行動してしまう理由があるということです。それは個人の能力や賢さに関係なく、否応なしに機能する傾向としてインセンティブが働いてしまうというだけのことです。
