[技術紹介]
この記事では、ソフトウェア開発におけるチームワークの効果を最大限に活用するために非常に有効だと思われるCore プロトコル*1をご紹介します。この度、筆者が翻訳作業に貢献させて頂き、日本語版を作成することができました。この記事を通してより多くの方にCoreプロトコルを知っていただければと思います。
*1CoreプロトコルはGnu Public Licenceで公開されています。CoreプロトコルはJim McCarthy, Michele McCarthy両氏によって考案された「人対人コミュニケーションのためのプロトコル」です。Jim McCarthy氏は"ソフトウェア開発のダイナミズム"(原著:"Dynamics of Software Development")の著者であり、Visual C++の開発プロジェクトを 率いていた一人でもあります。Visual C++は、「必ず遅れる」とまでいわれるソフトウェア業界の中で、3〜4か月という短い周期でリリースを続け、ソフトウェア業界でなくてはならない開発ツールの地位を確立しているのはみなさんもご存じだと思います。
彼らがVisual C++の開発チームを率いた際に築き上げた(鋭い洞察力によって"気づき"上げられた)チームワークを最大限引き出すためのパターンは、1995年に"Dynamics of Software Development"にまとめられました。彼らはその後も、チームワークを効率的に発揮するための方法論について調査・研究を続け、そして現在も勢力的に続けています。彼らの鋭い洞察から導かれた成果の数々は彼らのサイトで随時発表されています。
その調査・研究の中で、チームワークを発揮するためのコミュニケーションツールとして完成されたのがCore プロトコルです。
また、"Dynamics of Software Development"は、2006年にはCoreプロトコルを含めたいくつかの興味深いパターンとともに、"Dynamics of Software Development (Best Practices)"として新たに出版されています。
Jimは"ソフトウェア開発のダイナミズム"という著作の中でこう叫んでいます。また、「メンバーを没頭させるために何が必要なのかを考え、一定期間メンバーを没頭させること」こそがソフトウェア開発におけるマネージャーの役割であるとも言っています。
多くの方が、この言葉に賛同されるのではないでしょうか。言わずもがな、ソフトウェアというのは「知的生産物」です。 開発者たちの知識や知恵が凝縮されたものです。その知識の源泉ともいえる開発チームメンバーにやる気がなかったら、どのようなソフトウェアが出来上がるのかを想像してみてください。背筋が凍る思いがするのは私だけではないはずです。
それでは、開発メンバー全員が「最高のソフトウェアを作ること」という共通のビジョンに向かって走るためにはどうすればよいのでしょう。
逆の問いをすることもできます。
「なぜチームメンバーはいつもバラバラになってしまうのだろう??」
「チームのゴールは全員に周知して共有しているはずなのに、なぜ??」
では次に、「チームを一致団結から遠ざけてしまうのは何なのか」について考えてみます。
当然ながら、ソフトウェアは人が作るものです。
ソフトウェア開発が行き詰り、メンバー同士で議論をしている時、
「頼むから、僕が言ってることだというのを忘れて、中身だけを聞いてくれ!」
と、こんな風に叫んだことはないでしょうか。お互いの感情が真実(本当に伝えたいこと)をブロックしてしまっている状況です。
このような不必要な感情の妨げを無くすためにはどすればよいのでしょうか。人対人のコミュニケーションでは、どんなアイデアを伝えるにしても、必ず、伝える人と伝えられる人の感情を抜きにして伝えることはできません。「問題対私たち」という構図になったとしても、アイデアを発言する人の感情と、アイデアを受け取る人の感情を抜きにはコミュニケーションは不可能です。この事は、感情の作り出す「場」の存在を気づかせてくれます。グループにおけるコミュニケーションでは、各個人の抱く感情が複雑に絡み合った「場」(感情の海と言ってもよいかもしれません)の上をアイデアがやり取りされるのです。そのような意味で、この節のタイトルはそれを的確に打ち抜いているのです。
この節のタイトルの文章を受け入れるならば、チームメンバー同士で「真実」のやり取りをスムーズに行うためにコントロールすべきもの、それは「感情」だということになります。
それではどのように感情をコントロールすればよいのでしょうか?
他人の感情の動きを直接コントロールするのは到底無理なことは明らかです。直接コントロールできないのは明らかなわけですから、間接的にコントロールする以外にはありません。それにはまず、人と人とのコミュニケーションにおいて「感情」を動かす要因となるものを考えてみると糸口が見えてきます。
様々なものが挙がるでしょう。
いくらでも羅列できそうですが、この辺でとめておきましょう。
せっかく、「素晴らしいソフトウェアのため一致団結したい」と思っていても、コミュニケーションの方法が悪ければ、相手の感情を悪い方向に刺激してしまい、真実(本当に伝えたいこと)が伝わりません。
最悪なパターンだと、相手から「こいつの話はどうせ・・・」なんて見限られてしまった日には、もう取り返しのつかない状態でしょう。(Jimは「ソフトウェア開発のダイナミズム」で、この見限り現象を「ボゾビットをフリップする*2」と表現しています)
*2ボゾ(bozo)は"ばか者、愚か者、あほ、間抜け"という意味で、「ボゾビットをフリップする」は言ってみれば、「無能な奴フラグを立てる」とも言えるでしょう。
ということで、「コミュニケーションの方法」を上手くコントロールしてやれば、感情の動きをコントロールできるというのは言いすぎとしても、悪い方向へ動かないように歯止めをかけられるという点で有効だという考えが見えてきました。
私はこの「コミュニケーションの方法をコントロールしてやる」という単純なアイデアは、非常に本質的で効率的だと思います。そして、その方法の一つとしてCoreプロトコルと出会ったのです。
Core プロトコルは2つの大きな要素から構成されています。
百聞は一見にしかず。まずCoreコミットメントの全文を掲載します。
Coreコミットメント
- チームに参加するときは次のことを約束します。
- 次を常に自覚し、メンバーに公表します。
- 何を求めているのか?
- 何を考えているのか?
- 何を感じているのか?
- 常に良い協力者を捜します。
- 一貫性のない感情のやり取りはしません。
- 今見つかっているアイデアより、良いアイデアを見つけたら
- そのアイデアをチームとして受け入れるかどうかを提案します。 もしくは(さらに)
- 改善案を探していることが全員に分かるようにします。
- ベストなアイデアは
- 情報源がどうであれ
- 後でより良いアイデアが出るかもしれないと思っても
- より良い代替案を自分が持っていなければ個人的にサポートします。
- 理解されようとするだけでなく、理解しようとします。
- チームを活用します。特に難しい問題を扱っているときほどチームを活用します。
- 努力に対する結果の比(results/effort ratio)の改善が確信できるアイデアは必ずチームに公表し、それ以外のアイデアは公表しません。
- 理にかなっていて、常に結果を意識するような(result-oriented)行動やコミュニケーションしかしません。
- 生産性の低い状況に陥らないと約束します。
- このCore コミットメントを守れなくなるような状況や
- 他のチームとの活動のほうが大切になってしまうような状況です。
- そのうちやらなくてはいけないことで、今効率的にできることは、今やります。
- 行動主体で振る舞うことで、ゴールに向かって進もうとします。
- Core プロトコル(またはより適切なプロトコル)を使えるときは必ず使います。
- 適時、適切に、偏見を持たずに、プロトコルチェックプロトコルを行い、かつチームメンバーからのプロトコルチェックプロトコルにも対応します。
- 誰かのCore コミットメントの遵守を妨げたりしませんし、誰かの妨げ行為を許容したりしません。
- 故意に愚かな行動はしません。
とても素晴らしいコミットメントだと思います。
一つ一つのコミットメントにとても熱いメッセージが込められていると感じますが、ここでは注目すべきポイントを次の6つのポイントにまとめて説明してみます。
チームは常に動いています。人と人とが複雑に絡み合いながら、そこに非常に複雑なダイナミクスを孕みながら。そのように生物的でカオスなチームというものを、時間を止めて把握するよりも、
「チームは今どのような動きを呈しているのか、次にどちらの方向に動こうとしているのか」
というチームの勢い、ベクトルという表現でも良いかもしれません、を把握することはとても大切であるということを気づかせてくれます。
衝動的でチームワークに必要のない感情の上がり下がりは自分の中だけにとどめておきます。
さらに、相手とのコミュニケーションでは常に傾聴的に振舞うことを約束しています(2.)。この点についてはよく目にする点だとは思いますが重要な点です。
これはメンバーにプレッシャーをかけているように思われがちですがそれは誤解です。確信しているのが自分だけだったとしても発言できるという点が重要です。少なくとも自分自身を説得できる説明を持ったアイデアのみを発言しようということです。単なる思い付きをそのまま口に出すのではなく、一旦落ち着いて考え、チームに対して貢献できるアイデアであると、少なくとも自分を説得できるアイデアだけを発言しようということなのです。
「この話し合いで何を決めたいのか」「今のタスク(アクション)の結果は何であるのか」を常に意識します。「とりあえずやっている」や「なにかよくなるだろう」というあいまいな動機で行動は起こさないということです。
このコミットメントはチームワークのすべての活動の基礎となるべき心構えで、憲法とも呼べるものでしょう。最近ではクレド(信念)という言葉も聞きますが、そのようなものにも該当するかもしれません。
先ほどの、「真実(知識・アイデア)は感情を媒体としてやりとりされる」という立場で言えば、Coreコミットメントは媒体としての感情の在り方を約束したものだと言えるでしょう。
それでは、次に、実際の「コミュニケーションの方法」を規定し、チームワーク中に渦巻くダイナミズムをコントロールするCoreプロトコルに進みましょう。
Core プロトコルは次の個々のプロトコル群から構成されます。ここでは、それぞれの特性を紹介していきます。個々の詳細なステップはCoreプロトコル本体を参照してください。
提案に対して「反対」を投じる時には次のような忠告が添えられています。
また、誰に対しても「絶対反対」という強い拒否権が与えられており、その発言が投票時に出た段階で提案は引き下げられます。しかし、この「絶対反対」という強い権利の行使に対しては
という強い忠告が添えられています。
このプロトコルは非常に形式的に行われるべきであることが強調されています。「どのように変更すれば、賛成しますか?」という調停者の問いに対して反対者は明確に賛成するために必要な変更を述べます。ここで反対理由などを述べることは許されていません。
採点者(訳では完成アドバイザーとしています)は減点法による採点が求められます。改善点が見つからない場合はどんなに気に入らなくても10点を与えなくては なりません。採点結果に対してもポジティブな批判のみを伝えるようになっており「10点をとるためには〜〜が必要です」という伝え方をします。
このプロトコルは改善のためのアイデアを集めることが目的であり、実際にそのアイデアを採用するかは改善を行いたい当人にゆだねられています。
今回はJim McCarthyのCore プロトコルを紹介しました。
チームワークは、「複雑に絡み合った感情の場」の上を、アイデアがやり取りされる事によって進んでいきます。
チームワークにおいて「コミュニケーションの方法」を取り決めて、メンバー間でアイデアをやり取りすることは、「真実は感情を媒体として伝わる」ということを受け入れるなら、非常に効果的といえるのではないでしょうか。
このCoreプロトコルは、これまでの数多くの開発チームを率いてきたJim/Michele McCarthy両氏が10年以上洗練を続けて完成したプロトコル群です。まだ、このプロトコルを私は実践したことはありませんが、非常にうまく働くのではないかと期待しています。
Coreプロトコル自体はとても魅力的なのですが、チームへどう適用するかもまた重要で興味深い問題です。この適用法については文献[1]にまとめられています。
また、Coreプロトコルの背景にある、ソフトウェア開発におけるいくつかの興味深いチームダイナミズムについては、文献[2],[3]にまとめられています。興味のある方はぜひ参照していただきたいと思います。
特に文献[2],[3]にはソフトウェア開発という複雑な感情の渦の中で「良いソフトウェアを納期どうり出荷するためには」という至上命題に向かって、「チーム=ソフトウェア」という独特の考えの元に、非常に興味深い洞察が行われています。
近年では、「アジャイル」というキーワードで「人」にフォーカスされたさまざまな手法が提案されていますが、この手法はその中で、異彩を放ち、とても魅力的なものに筆者は感じます。
今回、Coreプロトコルの翻訳に私が貢献させていただけたこと、この記事を通してより多くの方にCoreプロトコルを知っていただける機会が得られた事を大変嬉しく思います。読者の方もぜひCoreプロトコルを含めたこれらの著作を読んで共感していただけたら幸いです。
|
© 2008 OGIS-RI Co., Ltd. |
|