ObjectSquare [2008 年 2 月号]

[技術紹介]


The Core Protocols
〜チームワークの最強兵器〜

株式会社オージス総研
アドバンストモデリングソリューション部
大村 伸吾
https://d.hatena.ne.jp/everpeace/





この記事では、ソフトウェア開発におけるチームワークの効果を最大限に活用するために非常に有効だと思われる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)"として新たに出版されています。



メンバーをソフトウェア開発というゲームに没頭させろ!([3])

Jimは"ソフトウェア開発のダイナミズム"という著作の中でこう叫んでいます。また、「メンバーを没頭させるために何が必要なのかを考え、一定期間メンバーを没頭させること」こそがソフトウェア開発におけるマネージャーの役割であるとも言っています。

多くの方が、この言葉に賛同されるのではないでしょうか。言わずもがな、ソフトウェアというのは「知的生産物」です。 開発者たちの知識や知恵が凝縮されたものです。その知識の源泉ともいえる開発チームメンバーにやる気がなかったら、どのようなソフトウェアが出来上がるのかを想像してみてください。背筋が凍る思いがするのは私だけではないはずです。

それでは、開発メンバー全員が「最高のソフトウェアを作ること」という共通のビジョンに向かって走るためにはどうすればよいのでしょう。

逆の問いをすることもできます。

「なぜチームメンバーはいつもバラバラになってしまうのだろう??」
「チームのゴールは全員に周知して共有しているはずなのに、なぜ??」

では次に、「チームを一致団結から遠ざけてしまうのは何なのか」について考えてみます。




人と人の間で真実を伝えるための媒体となるもの、それは感情である([3])

当然ながら、ソフトウェアは人が作るものです。

ソフトウェア開発が行き詰り、メンバー同士で議論をしている時、

「頼むから、僕が言ってることだというのを忘れて、中身だけを聞いてくれ!」

と、こんな風に叫んだことはないでしょうか。お互いの感情が真実(本当に伝えたいこと)をブロックしてしまっている状況です。

このような不必要な感情の妨げを無くすためにはどすればよいのでしょうか。人対人のコミュニケーションでは、どんなアイデアを伝えるにしても、必ず、伝える人と伝えられる人の感情を抜きにして伝えることはできません。「問題対私たち」という構図になったとしても、アイデアを発言する人の感情と、アイデアを受け取る人の感情を抜きにはコミュニケーションは不可能です。この事は、感情の作り出す「場」の存在を気づかせてくれます。グループにおけるコミュニケーションでは、各個人の抱く感情が複雑に絡み合った「場」(感情の海と言ってもよいかもしれません)の上をアイデアがやり取りされるのです。そのような意味で、この節のタイトルはそれを的確に打ち抜いているのです。

この節のタイトルの文章を受け入れるならば、チームメンバー同士で「真実」のやり取りをスムーズに行うためにコントロールすべきもの、それは「感情」だということになります。

それではどのように感情をコントロールすればよいのでしょうか?

他人の感情の動きを直接コントロールするのは到底無理なことは明らかです。直接コントロールできないのは明らかなわけですから、間接的にコントロールする以外にはありません。それにはまず、人と人とのコミュニケーションにおいて「感情」を動かす要因となるものを考えてみると糸口が見えてきます。

様々なものが挙がるでしょう。

いくらでも羅列できそうですが、この辺でとめておきましょう。

せっかく、「素晴らしいソフトウェアのため一致団結したい」と思っていても、コミュニケーションの方法が悪ければ、相手の感情を悪い方向に刺激してしまい、真実(本当に伝えたいこと)が伝わりません。

最悪なパターンだと、相手から「こいつの話はどうせ・・・」なんて見限られてしまった日には、もう取り返しのつかない状態でしょう。(Jimは「ソフトウェア開発のダイナミズム」で、この見限り現象を「ボゾビットをフリップする*2」と表現しています)
*2ボゾ(bozo)は"ばか者、愚か者、あほ、間抜け"という意味で、「ボゾビットをフリップする」は言ってみれば、「無能な奴フラグを立てる」とも言えるでしょう。

ということで、「コミュニケーションの方法」を上手くコントロールしてやれば、感情の動きをコントロールできるというのは言いすぎとしても、悪い方向へ動かないように歯止めをかけられるという点で有効だという考えが見えてきました。

私はこの「コミュニケーションの方法をコントロールしてやる」という単純なアイデアは、非常に本質的で効率的だと思います。そして、その方法の一つとしてCoreプロトコルと出会ったのです。




Core プロトコル〜チームワークのための最強兵器〜

Core プロトコルは2つの大きな要素から構成されています。

Core コミットメント
チームの憲法ともいえるもので、チームメンバーが常に守るべき心構えです。11個の約束事からなっています。
Core プロトコル
このプロトコルはチームワークを行う上で様々な場合に使えるコミュニケーションの方法を規定しています。 このプロトコル使用者に対して、Coreコミットメントを守る方向へ立ち直らせる力が働くように設計されています。

Core コミットメント

百聞は一見にしかず。まずCoreコミットメントの全文を掲載します。

Coreコミットメント
  1. チームに参加するときは次のことを約束します。
    • 次を常に自覚し、メンバーに公表します。
      1. 何を求めているのか?
      2. 何を考えているのか?
      3. 何を感じているのか?
    • 常に良い協力者を捜します。
    • 一貫性のない感情のやり取りはしません。
    • 今見つかっているアイデアより、良いアイデアを見つけたら
      1. そのアイデアをチームとして受け入れるかどうかを提案します。 もしくは(さらに)
      2. 改善案を探していることが全員に分かるようにします。
    • ベストなアイデアは
      1. 情報源がどうであれ
      2. 後でより良いアイデアが出るかもしれないと思っても
      3. より良い代替案を自分が持っていなければ個人的にサポートします。
  2. 理解されようとするだけでなく、理解しようとします。
  3. チームを活用します。特に難しい問題を扱っているときほどチームを活用します。
  4. 努力に対する結果の比(results/effort ratio)の改善が確信できるアイデアは必ずチームに公表し、それ以外のアイデアは公表しません。
  5. 理にかなっていて、常に結果を意識するような(result-oriented)行動やコミュニケーションしかしません。
  6. 生産性の低い状況に陥らないと約束します。
    • このCore コミットメントを守れなくなるような状況や
    • 他のチームとの活動のほうが大切になってしまうような状況です。
  7. そのうちやらなくてはいけないことで、今効率的にできることは、今やります。
  8. 行動主体で振る舞うことで、ゴールに向かって進もうとします。
  9. Core プロトコル(またはより適切なプロトコル)を使えるときは必ず使います。
    • 適時、適切に、偏見を持たずに、プロトコルチェックプロトコルを行い、かつチームメンバーからのプロトコルチェックプロトコルにも対応します。
  10. 誰かのCore コミットメントの遵守を妨げたりしませんし、誰かの妨げ行為を許容したりしません。
  11. 故意に愚かな行動はしません。

とても素晴らしいコミットメントだと思います。
一つ一つのコミットメントにとても熱いメッセージが込められていると感じますが、ここでは注目すべきポイントを次の6つのポイントにまとめて説明してみます。

チームの勢いの把握(Coreコミットメント1.)
「何を求め」「何を考え」「何を感じ」ているのかを常にみんなで共有すると宣言されています。通常であれば、現在その人が何をしているか、次は何をすべきかという、タスクの進捗を共有するという考え方になりがちですが、これだけでは、チームのある瞬間の状態しか把握することはできません。

チームは常に動いています。人と人とが複雑に絡み合いながら、そこに非常に複雑なダイナミクスを孕みながら。そのように生物的でカオスなチームというものを、時間を止めて把握するよりも、

「チームは今どのような動きを呈しているのか、次にどちらの方向に動こうとしているのか」

というチームの勢い、ベクトルという表現でも良いかもしれません、を把握することはとても大切であるということを気づかせてくれます。

一貫性のない感情はやりとりしない(Coreコミットメント1.)
相手とのコミュニケーションにおいて、自分の表明している感情に対して責任をもつ、とも言いかえられます。

衝動的でチームワークに必要のない感情の上がり下がりは自分の中だけにとどめておきます。

常に協力的(Coreコミットメント1.,2.,3.)
メンバーは常に協力者を探しています(1.)。そしてチームで問題解決に向かおうとしている(3.)、すなわち協力的であるという意味です。

さらに、相手とのコミュニケーションでは常に傾聴的に振舞うことを約束しています(2.)。この点についてはよく目にする点だとは思いますが重要な点です。

確信をもった発言のみ(Coreコミットメント4.)
発言されたアイデアは、常に「努力に対する結果の比が改善できる」と当人が信じている、という事が保証れています。つまり、チームにとってよりゴールが近くなると信じられる、本気のアイデアしか発言されないということです。常に提案されるアイデアは本気ですから、発言したときの本人の「心つもり」を確認する必要はないということもコミュニケーションのコストを抑えるのに役立ちます。発言はすべて本気な発言のため、相手の意見を真剣に受け止めなくてはならないというメンバーの姿勢が起こると期待されます。  

これはメンバーにプレッシャーをかけているように思われがちですがそれは誤解です。確信しているのが自分だけだったとしても発言できるという点が重要です。少なくとも自分自身を説得できる説明を持ったアイデアのみを発言しようということです。単なる思い付きをそのまま口に出すのではなく、一旦落ち着いて考え、チームに対して貢献できるアイデアであると、少なくとも自分を説得できるアイデアだけを発言しようということなのです。

結果を意識(Coreコミットメント5.,8.)
行われるコミュニケーションや行動は常に、結果を意識して行われます。

「この話し合いで何を決めたいのか」「今のタスク(アクション)の結果は何であるのか」を常に意識します。「とりあえずやっている」や「なにかよくなるだろう」というあいまいな動機で行動は起こさないということです。

自浄作用(Coreコミットメント6.,9.)
プロトコルチェックという自浄効果を持ったプロトコルを偏見なく使うこと。誰がいつ使っても印象を悪くしないことに同意しています。Coreプロトコルを守れないような状態に陥らないように自制するのですが、もしそうなってしまった場合は、この自浄作用によって自分を奮い立たせてくれます。チームメンバーが常に協力的だということも非常に役に立つでしょう。

このコミットメントはチームワークのすべての活動の基礎となるべき心構えで、憲法とも呼べるものでしょう。最近ではクレド(信念)という言葉も聞きますが、そのようなものにも該当するかもしれません。

先ほどの、「真実(知識・アイデア)は感情を媒体としてやりとりされる」という立場で言えば、Coreコミットメントは媒体としての感情の在り方を約束したものだと言えるでしょう。

それでは、次に、実際の「コミュニケーションの方法」を規定し、チームワーク中に渦巻くダイナミズムをコントロールするCoreプロトコルに進みましょう。

Core プロトコル

Core プロトコルは次の個々のプロトコル群から構成されます。ここでは、それぞれの特性を紹介していきます。個々の詳細なステップはCoreプロトコル本体を参照してください。

パス(パス解除)プロトコル
チーム内の活動への棄権(パス)を表明するためのプロトコルです。 このプロトコル使用時のコミットメント事項としてとても特徴的なのは「パスの理由を聞いてはならない」としているところにあります。パスするかしないかは完全に個人の判断にゆだねられ、各メンバーは個人の決定にたいして完全に信頼を置きます(パスばかりしていれば、Coreコミットメントからも逸脱してしまうのは言うまでもありません)。また、パスを解除したい時にはいつでも解除可能なことも触れられています。

チェックイン(チェックアウト)プロトコル
場に入るとき、または出る時に使用するプロトコルです。チェックインプロトコルでは、現在の気持ちを端的に表現すること(怒っている、悲しい、嬉しい、不安だなど)が求められます。また、特徴的なのは、発言した気持ちに対して 質問は許されないという点も挙げられます。この点でも発言者が感じている気持ちをそのまま受け取るという個人の判断の尊重が見られます。チェックアウトプロトコルの利用も完全に個人の判断にゆだねられています。

救援要請プロトコル
名前のごとく、助けを求めるために使います。このプロトコルで強調しているのは「助けを求めるだけならタダ。バンバン頼め。」ということです。そしてまた、どのメンバーにも「No」という権限があること、も同時に尊重されています。助けを求めるときの言葉も「〜さん、〜〜してくれますか?」という定形文で求めることから、非常にわかりやすく、不必要な感情のやり取りが避けられるようになっており、「助ける時はベストをつくす」ことも求めらます。

プロトコルチェックプロトコル
これはプロトコルの誤用に対して、正しいプロトコルを確認するために利用します。Coreコミットメントでも触れられているとおり、このプロトコルの使用に対してメンバーは一切偏見をもってはいけません。

意図チェックプロトコル
メンバーの態度や行動に、疑問がある時や興味があるときに使用します。意図を確かめる際の言葉も「〜している意図は何ですか?」と定型文で規定されています。加えて、意図をチェックする前に、「円満に解決する心づもり」をしてからこのプロトコルを使用するように求められています。

総意決定プロトコル
チームの意思を決定するためのプロトコルです。このプロトコルでは「提案」「投票」の手順が規定されており、投票では各個人の意見で投票することが厳しく求められます。この提案はCoreコミットメントに基づいていますので、提案者が「努力に対する結果の比」の改善を確信しているアイデアです。Coreコミットメントに従っている限り、この投票は参加することが義務付けられています。

提案に対して「反対」を投じる時には次のような忠告が添えられています。

  • 「反対」を投じ、膨大なコストを生じさせるようなチームの停滞または停止、を引き起こした後でも、チームの再始動に貢献できる信じるときのみ「反対」を投じます。

また、誰に対しても「絶対反対」という強い拒否権が与えられており、その発言が投票時に出た段階で提案は引き下げられます。しかし、この「絶対反対」という強い権利の行使に対しては

  • チームの方向修正やリーダーシップに多大な貢献をできると確信するときや、誠実さを貫くために絶対必要なときのみ「絶対反対」を投じます。

という強い忠告が添えられています。

調停プロトコル
総意決定プロトコルの投票において少数の反対者が発生した場合に、調停のコストより、提案が通過した場合に得られる利益が多い場合など(何種類か尺度が紹介されています)に、このプロトコルによって調停を行います。

このプロトコルは非常に形式的に行われるべきであることが強調されています。「どのように変更すれば、賛成しますか?」という調停者の問いに対して反対者は明確に賛成するために必要な変更を述べます。ここで反対理由などを述べることは許されていません。

完成ゲームプロトコル
自分の成果物を改善するために、他のメンバーのアイデアを集めたい時に使用します。

採点者(訳では完成アドバイザーとしています)は減点法による採点が求められます。改善点が見つからない場合はどんなに気に入らなくても10点を与えなくては なりません。採点結果に対してもポジティブな批判のみを伝えるようになっており「10点をとるためには〜〜が必要です」という伝え方をします。

このプロトコルは改善のためのアイデアを集めることが目的であり、実際にそのアイデアを採用するかは改善を行いたい当人にゆだねられています。

自己改善プロトコル
このプロトコルはチームを構成する各メンバーの質を向上させるために非常に重要なプロトコルです。このプロトコルは継続的に行われることが望ましいでしょう。このプロトコルでは自分が目標を達成するための妨げとなっている「障壁」を分析し、「理想像」を明確に意識します。そして理想像へ向けての自己改善活動を協力的に行うために「シグナル」と「レスポンス」という動作を決めることによって、お互いに、それが改善活動であること、その改善活動を行っていることへの称賛を相手に明確に分かる形でやり取りします。

調査プロトコル
このプロトコルは、メンバーに起こっている現象を調べるために行います。このプロトコルでは質問を繰り返し行う事で調査を行います。質問の結果にたいして分析を行ったり、理由づけをしたりすることは認められていません。単に質問を繰り返すことで、情報を集めることに集中し、相手の感情をなるべく刺激しないようにします。



まとめ

今回はJim McCarthyのCore プロトコルを紹介しました。

チームワークは、「複雑に絡み合った感情の場」の上を、アイデアがやり取りされる事によって進んでいきます。

チームワークにおいて「コミュニケーションの方法」を取り決めて、メンバー間でアイデアをやり取りすることは、「真実は感情を媒体として伝わる」ということを受け入れるなら、非常に効果的といえるのではないでしょうか。

このCoreプロトコルは、これまでの数多くの開発チームを率いてきたJim/Michele McCarthy両氏が10年以上洗練を続けて完成したプロトコル群です。まだ、このプロトコルを私は実践したことはありませんが、非常にうまく働くのではないかと期待しています。

Coreプロトコル自体はとても魅力的なのですが、チームへどう適用するかもまた重要で興味深い問題です。この適用法については文献[1]にまとめられています。
また、Coreプロトコルの背景にある、ソフトウェア開発におけるいくつかの興味深いチームダイナミズムについては、文献[2],[3]にまとめられています。興味のある方はぜひ参照していただきたいと思います。

特に文献[2],[3]にはソフトウェア開発という複雑な感情の渦の中で「良いソフトウェアを納期どうり出荷するためには」という至上命題に向かって、「チーム=ソフトウェア」という独特の考えの元に、非常に興味深い洞察が行われています。

近年では、「アジャイル」というキーワードで「人」にフォーカスされたさまざまな手法が提案されていますが、この手法はその中で、異彩を放ち、とても魅力的なものに筆者は感じます。

今回、Coreプロトコルの翻訳に私が貢献させていただけたこと、この記事を通してより多くの方にCoreプロトコルを知っていただける機会が得られた事を大変嬉しく思います。読者の方もぜひCoreプロトコルを含めたこれらの著作を読んで共感していただけたら幸いです。




参考文献

  1. Jim McCarthy, Michele McCarthy, "Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision," Addison-Wesley Pub(Sd),(2001/12/27)
  2. Jim McCarthy, Michele McCarthy, "Dynamics of Software Development(Best Practices)," Microsoft Pr; Pap/Cdr, (2006)
  3. Jim McCarthy,"Dynamics of Software Development," Microsoft Pr; Pap/Cdr,(1995)
    (訳本:ジム・マッカーシー(著),三浦 明美 ,福崎 俊博 (翻訳),"ソフトウェア開発のダイナミズム,"マイクロソフトプレス,1997年)
  4. The Core Protocols V3 (原文)
  5. The Core Protocols Foreign Translations(日本語版有)
  6. An Agile Way: Product = Team(製品づくりはチームづくり) -- Jim McCarthy at SDBP2007
  7. An Agile Way: The Core Protocols V3.01 日本語版 -- クリエイティブコミュニケーションに突き刺され
  8. Milestones to EVERPEACE〜alius via〜: The Core Protocols V3.01 日本語版
top ページのトップへ戻る

© 2008 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP