このエントリーをはてなブックマークに追加LINEで送る

5.2. 共感、納得、同意

ハッピィ・エンジニアリング表紙

 「3.1 利害の対立」に記述したとおり、日本的な合意形成プロセスが「押しつけ」を生む。立場の違いを超えるために、相手の立場を知りゴールを共有することが重要だと記述したが、これは非常に難しい問題である。立場が違い、そして利害が対立する以上、心情的なものごとを共有するのは困難、いや、不可能に近い。

 

 開発プロジェクト内部の利害の対立は、小規模なプロジェクトで1社がすべてを取り仕切っている場合には表面化しないことが多いが、大規模プロジェクトで下請けの階層化が生じていると顕在化する。

 

 一例を挙げよう。そもそも元請けと下請けでは契約形態が異なる。元請けは一般に請負であるし、下請けは元請けに対する要員の派遣である。両者ともに人月を単位として測られるので混同されがちだが、意味合いは大きく異なる。

 

 元請けは大工と同様に注文主の意向に従い家を建てることが仕事の本質であり、人月はそのためにかかる作業量を測る尺度にすぎない。あらかじめ見積もった金額と実際にかかったコストとの差額は、そのまま利益・損失につながる。

 

 それに対して下請けは、バイトやパートと同じで、時間を売っているに等しい。単純に仕事の時間数による出来高で契約してしまうと、元請けにとってはいたずらに長時間労働を重ねられ過大な支出になりかねないので1カ月あたりの時間数の枠を設けたりはするが、本質的には時給いくらの世界と変わるところはない。

 

 事の善悪はともかくとして、会社単位で見るとそもそもの動機づけが元請けと下請けとでは大きく異なる。元請けは最終的には顧客にものを納めることがゴールだが、下請けにとっては契約した時間分だけ元請けが期待する以上の成果物を作り出して「元請け」に提出することがゴールなのである。

 

 元請けの目には、そうした下請けの姿勢は文字通りの「下請け根性」に映る。それゆえ、下請けの「参加意識」を醸し出させようとモチベーションの高揚を試みるが、ビジネス構造の本質からすれば幻想にすぎない。

 

 元請けと下請けというのは典型的な立場の違いであり、特に顧客からの要望に対しては利害が相反する。元請けは個々のシステムの完成度や今後の顧客との付き合いなども考慮し、ある程度受け入れていくが、下請けからすれば、そんなことは知ったことではない。仕様変更に伴う納期や工数の追加を元請けが呑むかどうか、あるいは、仕様変更への対応のためのパッチあてや無理やりの機能追加で懸念される品質の低下へのケア、などに関心が働く。下請けのソロバン勘定はそれらの状況いかんであるが、実態としては納期の延長もなく、工数の追加もないままにオーダーだけが下される。

 

 いかに「プロジェクトチームとして一丸となって」と元請けが美辞麗句を並べ立てても、下請けとは確実に利害が対立してしまうのである。

 

 プロジェクトの全体像やユーザ企業にとってのシステムの意義を聞いていたとしても、プロジェクトメンバが仕様変更を肯定的に受け止めることはまずあり得ないといって過言ではない。それが開発者であれば、なおさらである。「しょうがねぇなぁ」という思いで、仕方なくその作業を引き受けているだけのことだ。

 

 そして、プロジェクトマネージャ、プロジェクトリーダなどの立場で部下を抱えていたら、部下をなだめすかして手戻り仕事をさせることの大変さを何度も味わっていることだろう。自分が悪いわけではないのに、あるいはユーザ企業の強い要望に応えざるを得ないのに、開発者はその変更とスケジュールに対する不満をいうばかりである。

 

 システム開発において、「お互いの立場を知り、ゴールを共有すべき」ことは、ある意味で理想論である。このような動機づけの虚飾をはぎ取ると、どうなるだろうか?

 

 発注側と開発側の接点部分は駆け引きの世界だが、それ以外の部分の本質は、発注側も含めて、「やれ」と命じるだけ、つまり指揮命令系統の世界である。しかし、すでに何度も記述したとおり、システム開発は現状では、それ自体を機械化することができず、職人仕事であるため、命令ですべてがうまく進むことはない。誰もが経験的に、命令がものごとをうまく進めているのではないことがわかっている。特に日本社会ではそうである。個々人の責任分担があいまいであるのをいいことに、面従腹背することは珍しくない。命令は、常に「下策」でしかない。

 

 では、「下策」から一段階上がって「中策」といえるものは何だろうか?欧米人の場合には、幾何学の証明は「論理的に正しい」ということで容認されるが、日本人の場合、「証明は正しいのだろうが、俺は納得いかない」と平気で言う国民性がある。日本人は論理的ではないと言われるゆえんである。日本の慣習において、理論的な説得は大した効果を持たないという難しさがある。

 

 このような日本社会においては、経験論的なプロジェクト管理本に時折出てくる「共感」が鍵を握る。日本社会は「納得」の世界である。日本人の場合には、理詰めで「説得」しても「理屈はわかるけど、俺は納得いかないからやらない」という名文句が登場するだけのことだ。つまり、「説得」するのではなく、理も非もなく「納得」させることが大切だということである。

 

 一言で表現するなら、例えば「上のいっていることはめちゃくちゃだけど、とにかく一緒にがんばろう」と訴えかけることだ。ムラ社会といわれる日本は一般的に、「浪花節」あるいは「仲間意識」の世界である。

 

 しかし、仲間意識を訴えることにも限界がある。なぜなら、「相手の共感を得る」ことは、「相手を『納得』させる」ということ、すなわち「自分と同じレベルで『同意』を求める」という行為になる。つまり、「共感」という手段を選んだ時点で「命令」権を放棄している以上、拒否権が存在するのである。同意を求められている者は、心理的に同意できなければ拒否が可能なのだ。

 

 さらにいうと、上述のように「上のいっていることはめちゃくちゃだけど、とにかく一緒にがんばろう」という論調、すなわち「共通の敵を作る」というやり方は、二度三度通用する手だてではない。何度も使えば、いいかげん見抜かれてしまう。

 

 では、日本の開発現場における「上策」とは何だろうか? 「上策」は「頼み込み」である。

 

 日本文化では、ものごとを頼むというのは、自分が他人に「お世話になる」ことであり、自分が他人より下位に立つことを意味する。そのため、上下関係を考えた場合、上の人間にとっては心理的抵抗感が強く、なかなかできることではない。

 

 ところが、その心理的抵抗感さえ取り除いてしまえば、この方法は誰にでもできる簡単なものである。「皆さん方にお願いするしかありません」と言うだけのことだ。頼まれたほうは心理的に優位な立場に立つので、いい気持ちになって「仕方ない、やってやるか」という方向に向きやすい。「人生意気に感ず」という格言のとおり、相手は損得勘定を捨てて仕事をしてくれるだろう。

 

 しかし、この方法には、ひとつの前提がある。日本には、出入り業者に対して、かなりぞんざいな扱いをするという悪しき慣習がある。普段からぞんざいな扱いをしていたら、どれだけ頼み込んだとしても、相手は「都合のいいときだけ、そんな言い方してくるんじゃねぇよ」と思い、拒否してしまうだろう。しかし、中には発注側の立場であるにもかかわらず、きちんとした言葉で接してくれる人もいる。対等な立場として扱ってくれ、専門家として頼りにしてくれる人には損得抜きで最大限の努力を見せるのは、日本人にとっては当然のことだ。

 

 さらにひとつのプロジェクトが終わった後でも、この関係性は生き続ける。円滑な関係が結ばれていれば、今度はプロジェクトの初期段階から専門家としての提言を行ってもらえるようになるのである。

 

 立場の違いこそあれ、「出来の悪い子ほどかわいい」という心理状態は共通する。ただし、この方法が円滑に回るためには、「頼み込む」側が「頼まれる」側からなんらかの形で敬意を払われている必要がある。そうでないと、度重なる一方的な依頼に音を上げてしまう。ギブ・アンド・テイクという形が望ましい(それゆえに、信頼でき腕もある技術者の間には、自然に会社を超えたネットワークができあがっていく)。

 

 このやり方は、人間同士の信頼関係に基づくやり方である。実際に、このような人間心理を心得たプロジェクトリーダは、これを「活用」している。「人生意気に感ず」という気持ちにさせるというのは、裏を返していうなら、設計者・プログラマをいい気持ちにさせて、損得抜きで仕事をしてもらうテクニックである。これを計算ずくでやれる人間は、「嫌なやつ」である。何年もこの世界に身を置くと、このような「頼み込み」の場において、本気で頼られているか、あるいは、人間心理を逆手に取って頼み込んでいるかの区別もつくようになってくるだろう。しかし、ぞんざいに命令されるよりは、はるかに納得して仕事をすることができる。

 

 「ビジネスの場において、最後に自分を助けてくれるのは礼節である」という言葉をどこかで読んだが、この「上策」を取る上では、礼節という言葉が持つ意味は非常に大きい。人間はなかなか高い理想で生きることはできない。近しい人間関係・信頼関係の中で頼られ、それに応えること、そこに鍵があるのだ。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

5.2. 共感、納得、同意 ハッピィ・エンジニアリング関連ページ

5.1. 検討と意思決定
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
5.3. 作業指示
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング