前回はコラボレーション開始当初のハードルについて挙げてみた。今回は,コラボレーションで開発作業を行う最中に発生する問題とその対策をリストアップしておこう。受注が確定して実作業に着手すると,成否に深刻な影響を及ぼすのはメンバー間のコミュニケーションだ。プロジェクト単位で動く以上,良好な人間関係は,プロジェクト成功の基盤である。

「世界の感じ方,とらえ方」は,人によって違うことを知る

 コミュニケーション不全の大半は,相手との「世界の感じ方,とらえ方」の差異に気づいていないことが原因である。世界のとらえ方は人それぞれで,その差は,私たちが思っている以上に大きい。これは,技術習得や作業改善で乗り越えられる問題ではない。では,どうすればよいだろうか。

 それには,技術やデザインやトレンドの情報だけでなく,人間関係やコミュニケーションに関する情報にも,アンテナを張っておくことだ。とりわけ,世界のとらえ方の差異についての学術的な情報―――パーソナリティに関する心理学の情報や脳科学の情報―――が役に立つ。

 それは色彩心理や認知科学などと違って,実務には何の関係もない情報かもしれない。だが,自分と相手の両方のパーソナリティのタイプを知れば,仕事に対する価値観や,考え方や行動のクセを把握できる。相手の「世界の感じ方,とらえ方」を知識として理解すれば,対応方法がわかり作業が進めやすくなる。

 具体的には,以下のような点に注意あるいは工夫をして,人間関係を築いていこう。

タイプによって伝える方法を工夫する

 図による説明は,長文の理解を助けると考えられている。しかし,世の中には図解のほうが苦手な人もいる。書面の指示より,口頭による説明のほうがわかりやすい人もいれば,反対に書類のほうが理解しやすい人もいる。話し言葉,文章,イメージ,音,コード,図,フローチャートなど,理解しやすい方法や記憶しやすい方法は人によって異なる。発信者にとってわかりやすい方法が,受け手にとってわかりやすい方法とは限らない。

 相手が理解しやすい方法で伝えなければ,伝えようとする熱意は伝わっても肝心の内容が伝わらない。指示や意図や仕様を的確に伝えるためには,相手に応じて説明方法を変えるのが賢明だ。標準化された方法は尊重すべきだが,何がなんでもUML,何がなんでもフローチャートなどと,こだわらないほうがよい場合もある。

 文系出身のプログラマの何割かは,フローチャートに親しんでいない。仕様書だけですべての作業が進むような職場経験にも乏しいことがある。ハードウエアへの関心も薄く,パーツをハンダ付けするといった実体験をしていない人もいる。だから,仕様書だけで指示を伝えようとしても,受け止めてもらえないことがある。

 例えば,筆者がコラボレートしてきた中の一人,フリープログラマの相方は文系プログラマだが,クラス単位,プロシジャ単位で論理的に積み重ねるのではなく,小説を書くように1行目からコードを書いていくタイプだ。1個の処理ごとに短文で指示や意図を書いて伝える方法がわかりやすいという。優秀でユニークなメンバーの潜在能力を押しつぶさないように,伝達する側にも工夫が求められる。

 単純なことを記憶するのが苦手なメンバーには,メモやICレコーダーを活用する,常にデスクトップに工程表のファイルを置いておく,などの工夫を要求するとよいだろう。

責任回避/依存タイプには,書類を多用する

 サラリーマン開発者だと,上司の命令一つで,相性が合わない人とのコラボレートを余儀なくされることがある。もちろんSOHOでも,いつも相性の合う協業相手を見つけられるとは限らない。

 そもそもデザイナーとプログラマは天敵同士だ。作業面では歩み寄れたとしても,心も同じように歩み寄れるとは限らない。また,プロジェクトに複数のプログラマが参加しているケースでは,これはあくまで推測だが,ライバル意識の強過ぎる人がいた場合,同業者同士の間でも問題が生じることがあるかもしれない。

 それでも何とか相手と良い関係を築こうとして,歩み寄れば歩み寄るほど,関係がぎくしゃくしてしまうタイプの人がいる。作業上の困難を手助けをすると依存傾向に拍車がかかったり,何か面倒なことが生じると目をそらそうとする,次のような人たちだ。

  • 失敗や苦労を,必要以上に仕様書や顧客側の希望に責任転嫁する
  • 自らコミュニケーションの工夫や努力をしない
  • 責任を伴うことになりそうな,他のメンバーからのアドバイスには耳を傾けない
  • 「できるはずがない」「失敗するかもしれない」「そんなことをして何になる」といった,他のメンバーの積極性を否定する発言が多い
  • 仕事を通しての成長や社会貢献に関心が薄く,開発を労働と対価の交換だと割り切っている

 このようなタイプの人とコラボレートする場合は,作業指示書や報告書などを多用して関係を保つほうがよい。回避しがちな細かくて面倒な作業の指示も,指示書でアウトラインを伝えた後で,時間を置いてから口頭で説得すれば納得させやすい。また,文書を残せば,聞いたか聞いていないかといった問題が生じることもなく,責任を問うこともできる。心理的に,一定の距離を保って付き合うほうがうまくいく。

チームプレイ不能タイプには,制御役をあてる

 プロジェクトに迎え入れたが,社交性はあっても社会性に難点がある人物だったことに後で気づくことがある。チームプレイは苦手でも本人に努力しようとする意志がある,という人たちのことではない。共感能力のなさを自覚しておらず努力の必要性も感じていない,次のようなタイプの人たちである。

  • 事実を感情に合わせるため,事実を捻じ曲げて解釈する。これは仕様の曲解につながる
  • 意見や方針が目まぐるしく変わるが,本人は一貫性の無さに気づいていない
  • 利他的な行動の意義を認めない。メンバー間に波風を立てる
  • 心からの謝罪ができない
  • 自他の境界があいまいで,公私混同する

 スケジュールを無視する人,プロジェクト・リーダーの指示や顧客の意向を聴く姿勢のない人,プライベートな事情が仕事の成果に直結してしまう人,何の理由で怒るか予測のできない人,嫉妬心から努力型のメンバーの足をひっぱる人,守秘義務についての意識の薄い人,他のメンバーが100歩を歩み寄ることを当然と考え,自分は歩み寄る必要がないと思っている人,1歩近寄っただけで50歩進む努力をしたような感覚を持ってしまう人――このような,自分が世界の中心であるタイプの人との関係の難しさは,Webアプリケーション開発の仕事に限ったことではないだろう。

 このような人たちを迎え入れてしまったら,プロジェクト・リーダーは,その言動を制御するために,マネージャー役のメンバーを一人任命する必要がある。

 マネージャー役となったメンバーは,例えば,他のメンバーの作業に介入しないように作業予定を細かく管理する,顧客用のメールやWebサーバーに関する各種設定ファイルの取扱方法を徹底する,動作を不安定にしかねないような私用目的で,開発用のマシンを使わせないよう指示する,といった監視機構の役割を果たさなければならない。

 この役割は非常に重責であるから,自己肯定感が強固で,プロジェクトの目的だけを見て冷静に対処できるメンバーを任命する必要がある。何か問題が生じそうになる度に,自分の歩み寄り方が足りないのだろうか,自分の指示方法が悪いのだろうか,と自己否定に陥ったり,プロジェクトの目的よりもプロジェクト内の和を優先する人ではなかなか務まらない。

 ここ数年,メンタルヘルスやモラル・ハラスメント(「モラル・ハラスメント」,マリー=フランス・イルゴエンヌ著,高野優訳,紀伊国屋書店 発行)に対する関心が高まりつつある。プロジェクト・リーダーには,根性論をふりかざすのではなく,マネージャー役がつぶれないように,その立場を冷静に把握して,バックアップする姿勢が求められるだろう。

 そしてプロジェクトが成功した暁に,多少なりともコミュニケーションに改善が見られた場合は,もう一度共に頑張ってみればよいだろう。だが,同じメンバーで次の仕事に意欲的に取り組む気持ちが萎えたなら,リーダーは社会性に欠けるメンバーの処遇を考える必要があるかもしれない。メンバー全員が責任感を持ち,意気揚々として良い仕事を完遂できなければ,迷惑を被るのは顧客でありエンドユーザーだからだ。メンバーの人間性を見抜くのも,プロジェクト・リーダーの重要な仕事のひとつである。

メンバー間で励まし合い,助け合おう

 いくらプロであっても,開発テーマには得意不得意がある。プログラマなら,業務改善,売上・在庫管理,検索処理,アンケート,統計,ショッピングサイト,電子商取引など,「これなら任せろ」という得意なテーマがあるはずだ。

 デザイナーも同様で,ファッション関係が得意な人もいれば,医療関係ならお任せという人,食や旅行なら右に出る者はないという人,それぞれだ。

 中規模案件のためのプロジェクトでは,予算も工期も限られており,テーマによって最適なメンバーを募ることは難しい。得意ではないテーマであっても,こなす必要がある。不得意なテーマに取り組むことになって自信を喪失しているメンバーがいたら,コミュニケーションを密にし,メールなどで励まして支え合おう。

 幸い筆者は,コラボレーターたちに恵まれている。筆者自身,自分が出来た人間だとは思っていないが,出来ていない部分を認めているからこそ,改善しようともがくのである。不器用でも歩み寄ろうと努力し続けることが,円滑なコラボレーションの第一歩のような気がしている。

 とどのつまり,「コラボレーションは,コミュニケーション」なのである。


本稿で述べたことは,複数のコラボレーターたちとの筆者の実務経験や,第三者の立場で見聞きした内容,同業者たちから受けた相談に基づくものである。必ずしも,すべてのデザイナーやエンジニアに当てはまるわけではないことをお断りしておく。


PROJECT KySS(プロジェクト・キッス)
薬師寺 国安(やくしじ くにやす,フリープログラマ)と,薬師寺 聖(やくしじ せい,個人事業所SeiSeinDesign自営,http://www.SeinDesign.net/)によるコラボレーション・ユニット。1996年,聖が勤務先で地域ポータルを企画制作,これを訪問した国安と知り合う。ActiveXユーザー同士で意気投合し,翌年「PROJECT KySS」結成。1999年よりXMLとDHTML利用のコンテンツ開発,2000年にはCMSツール開発と,一歩進んだ提案を行い続けている。XMLに関する記事や著書多数。両名ともMicrosoft MVP for Windows Server System - XML(Oct 2004-Sep 2005)。http://www.PROJECTKySS.NET/