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

5.1. 検討と意思決定

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

 日本企業においては、真面目にコツコツと作業することが美徳とされてきた。雑談することや、何かを考えること(すなわち、ボンヤリしているように見えること)は悪とされ、仕事をしているフリも仕事のうち、という本末転倒な状況を発生させる原因となっている。しかし、システム開発という仕事は、雑談や考えごとというのが非常に多く、またその重要性が非常に高い。

 

 プロジェクトを管理しているマネージャ・リーダと、作業者であるSE・プログラマの間では、常にコミュニケーションに対する考え方が異なる。管理者側は、決められた指揮命令系統と役割分担を順守し、決められたレポートラインや公式な会議以外での情報共有や意思決定を認めたくない。しかし、どれだけ徹底しようとしても、公式な会議の場では活発な議論や情報交換が行われることはなく、作業者はそれ以外のルートを使ってものごとを進めていく。

 

 その理由は単純で、管理側の人間は、状況だけはきちんと押さえておきたいという要求によりレポートラインや公式な会議を重要視している。そして作業者は、多くの労力と時間が必要になる調整に貴重な時間を使いたくないために、それを嫌うのである。プロジェクトをスムーズに進めていくうえでは、この両者の要求を満足させるようなコミュニケーション手段の使い分けを行うことが重要である。

 

 米国は、業務定義書に書いてないことは原則として行わないスタンスの社会である。つまり、指揮命令系統と役割分担を明確にした公式な体制の確立が必須である。しかし、合意形成主義の日本では、さまざまなことをあいまいなまま進めていくため、公式な体制を整えることが成功を遠ざけることにつながる場合が多い。誰もが、公式な会議やそこに出される文書が、結果として大きな意味を持たなかったことを経験しているのではないだろうか?

 

 公式に決められた指揮命令系統以外の情報伝達を認めない場合、その指揮命令系統の途中にボトルネックがあると、そこですべてが停止してしまう。パイプ役となるメンバや意思決定にあたるメンバが忙しかったり、事象に対する理解力に欠けたりしただけで、ものごとが先に進まなくなり、実作業を担当するメンバの時間を無駄にしていくことになる。

 

 また、公式な会議には、作業の当事者ではない人間も多数出席する。このような場で短時間に状況を説明しても、その議論が満足な解決策に至ることはめったにない。そして、会議の結果として取り入れられる意見は、「正論」ではなく、「声の大きい者の意見」である。

 

 非公式なコミュニケーションの場合、なんらかの問題を発見した者が主導になり、その場その場で作業の当事者同士が詳細を詰めていくことができる。しかし、大きなプロジェクトの中では的確に有識者を集めなければ満足のいく結果につながらない。さらに、プロジェクトの規模が大きくなればなるほど、そこで検討された内容をプロジェクトメンバ全員に徹底させることが非常に難しい。情報共有や意思疎通を考えた場合、全員に徹底できないことは致命的である。

 

 このように、公式・非公式ともに、長所と短所を持っている。長所・短所を見極めたうえで、公式・非公式をどのように使い分けるかが、プロジェクトをスムーズに進めていくポイントになる。

 

 そもそも、公式な会議の場では、最善策をみんなで検討しないことだ。検討は、作業者同士で、立ち話、裏紙へのメモ、ホワイトボードへの殴り書きなどの有効なコミュニケーション手段を利用して行えばよい。公式な会議での検討は、誰もが経験しているとおり、議論は分散し、直接関係ないメンバはアクビをし、時間だけが過ぎていく。公式な会議を有効に利用するには、スケジュールや問題発生状況など、連絡や定量的な判断が可能な内容についての確認の場と位置づけることである。あくまでもこの場では検討をせず、当事者間で検討して出た結論の、採用の是非を判断するのである。

 

 では、非公式なコミュニケーションを行う場合に、的確に有識者を集めるには、つまりプロジェクトメンバが誰に何を相談すればよいかを判断できる「構造」にするには、どうすべきであろうか?

 

 時代に逆行しているように感じられるかもしれないが、欧米ならホームパーティー、日本なら飲み会の開催が効果的である。このようなコミュニケーション手段は、世間的には古くさく否定的に扱われるが、プロジェクトマネジメントの実践派はたいがい、プロジェクトの体制が確立された段階でのパーティーの開催を勧めている。なぜならば、プロジェクトメンバそれぞれが個人的なつながりを持つと、その中からキーマンを見極めることが非常に簡単になるからである。プロジェクト内のコミュニケーションチャネルを極端に複雑化し、プロジェクトメンバそれぞれが、自分が立ち向かうべき問題に対して適切なキーマンを探り当てられるような形を作ることが重要である。

 

 これはプロジェクトの開発チーム内に閉じた話ではない。ある程度のスキルが双方にあることが前提となるが、開発側と発注側間の調整も同様である。

 

 重要なことは、公式な会議での愚にもつかない議論により決まるのではなく、キーマン同士の2〜3分の電話で決まっていくのである。

 

 いわゆる「管理」という言葉とは相反するので理解しにくい面があるかもしれないが、会話による非公式なコミュニケーションを促進するうえで重要なポイントは以下の2点である。

 

  • なるべく自由にコミュニケーションできるように、管理をしない。

    (無駄話、立ち話OK。逆に仕事に集中したい人間は、ひとりになれる環境に移動して仕事する)

  • 意思決定(承認)と周知だけは公式なミーティングで行う

 

コラム:プログラムは夜作られる

 

 メインフレームの開発が主流だった時代、プログラマはマシンタイムを取り合い、開発を行っていた。生産性の高いプログラマは、電話や会議などの割り込みを避け、プログラミングに集中するために、夜に仕事をすることを好んでいた。「プログラムは夜作られる」と語られるゆえんである。

 

 現在では、喫煙場所が限定され、居場所を失ったタバコ吸いたちがタバコ部屋に集まっている。ここでのいわゆる「タバコ部屋コミュニケーション」や「タバコ部屋ネットワーク」は意外な力を発揮している。開発メンバ全員で行う定例会議では出てこないような作業上の問題点が浮き彫りになるのは、決まってタバコ部屋である。今や「システムはタバコ部屋で作られる」のである。

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

5.1. 検討と意思決定 ハッピィ・エンジニアリング関連ページ

5.2. 共感、納得、同意
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
5.3. 作業指示
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

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