コミュニケーションはルール化すれば上手くいく 〜Core Protocolsによるコミュニケーション改善〜

コミュニケーションは難しい

同じプロダクト開発に関わっているとしても、開発チーム内には多かれ少なかれコミュニケーションの問題があります。

  • なぜあんな事言うんだろう??
  • 意味のない指示にうんざり
  • 否定されてばっかりでモチベーションが上がらない
  • 全然メンバーが助けてくれない
  • 一緒に仕事していると、チームメンバーと仕事に求めてるものが違う気がする
  • なんかアイツの言い方が腹が立つ

感じる問題は様々な形で現れますが、これらの問題の一因には、人と人(あるいはチーム)とのコミュニケーションの難しさがあります。コミュニケーションは難しいんです。話している内容以外に知らなければならないことが多すぎます。

 

ルール化してコンテクストの共有

他者とコミュニケーションするときに、相手が話した内容だけでなく、相手のバックグラウンド、コンテクストなど様々な情報が共有されていないと、コミュニケーションロスや、意図しない誤解を生みかねません。

そこで、「コミュニケーションにルールを作る」ことでコミュニケーションロス、誤解を減らすことができるのでは? という考えから、コミュニケーションに「プロトコル」を持たせる、という工夫があります。

Core Protocols

コミュニケーションのルール化のため、チームで自力でルールを策定することも可能ですが、何もないところからルール化するのにはそもそも大量のコミュニケーションが必要になり、現実的ではありません。(ルール化できるくらいコミュニケーションわかってれば苦労はないのだ)

そのような問題に対応するため、コミュニケーションをルール化したものが公開されているものもあります。私は、GNU-PLで提供されている Core Protocols(コアプロトコル) http://www.mccarthyshow.com/online/ というルールを利用していました。

このセッション

本セッションでは、Core Protocolsの内容を紹介した後、私が経験した多国籍チーム(シンガポール人、マレーシア人、日本人の混成チーム)でそれをどのように利用してきたか、それによってどのようなメリットがあったかをご紹介します。その上で、Core Protocolsの有効性、使いどころ、ハマった時の解決法をシェアします。

Core Protocolsが、あなたのチームのコミュニケーションの問題を改善に役立ちそう!(あるいは役立たなそう!)と判断ができるような体験をシェアできるセッションにしたいと考えています。

 
5 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Core Protocols(コアプロトコル)の紹介
  • 実際のProtocolの使用例のシェア
    • 私のチームの経験談
    • 実際に使っている場面のシェア
    • ハマりどころと対応
  • 考察
    • Core Protocolsの使いどころ
    • Core Protocolsが上手くいく/いかないチーム
    • どう上手く使っていくか

Learning Outcome

  • Core Protocolsとその使いどころがわかる
  • 普段のコミュニケーションの中に様々な暗黙の情報が隠れていることに気づける

Target Audience

チーム内のコミュニケーションに課題を感じるメンバーの方

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Hiroyuki Ito
    keyboard_arrow_down

    Hiroyuki Ito - アジャイル・メトリクス実践ガイド

    45 Mins
    Talk
    Intermediate
    アジャイルの文脈において、メトリクスの取得・活用は、もはや一般的なこととなりつつあります。
    メトリクスには、仮説検証に基づく経験主義的な行動を促し、結果として自律的成長や協働につながるという側面があります。
    一方でプロダクト開発の現場からは、「メトリクスの取り方がよく分からない」・「どう活用すれば良いのか分からない」といった意見も耳にします。
     
    当セッションでは、プロダクト開発の現場の「メトリクス難民」を救うため、メトリクスの学術的裏付け、具体的な取得・活用方法および事例を、
    Agile2016・SQiP2016の最新の知見を踏まえながらご紹介させていただきます。
     
    さぁ、皆さんも爆ぜましょう!
  • Harada Kiro
    Harada Kiro
    Senior Consultant
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Kaizen is a Japanese word that means continuous improvements.

    However, people usually find that make one improvement is easy but having improvements continuously is not that easy and rarely could keep them continue.

    In this session, we present Kaizen patterns where teams can use to help themselves to achieve continuous improvements.

  • Liked Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - 結果的にスクラムになってる!なのがいいと思う!

    20 Mins
    Experience Report
    Intermediate

    この5年間くらい、いくつかのチームをスクラムな開発チームにしてきたんだけど。「スクラムをやろう!」ってしてると、あんまりうまくいかないなぁって感じある。じゃあどうすんの?って「結果的にスクラムになってる!」ってのが良さそうだなって思う。

    今、僕のサポートしているチームは全員がペアで仕事をしていて、スプリントの期間は1週間。開発チームと運用チームがあって、そのメンバーが2スプリント毎に入れ替わって知識を共有していってるから、全員がお互いにカバーできる状況になってるの。ペア作業をやるなんて余裕があっていいなって言われたりするんだけど全然そんなことなくて、めちゃめちゃ忙しいチームだからこそ、こういう形にしてしまったんだよね。スクラムをやろうとしてやってたら、できなかっただろうなーって思う。ほんと、結果的にスクラムになったって感じ。

    僕の所属してる楽天の大阪支社の開発部は、ほとんど全部のチームがスクラムを取り入れた開発スタイルなんだけど、そのそれぞれが自分たちの担当しているサービスの特性や、ビジネスメンバーの考え方、開発チームの成熟度や、メンバーのスキルなどに合わせて、色んな形のスクラムになってるのも、そういうことなのかなって。

    スクラムをやろうとするとどういうところが良くないのか、結果的にスクラムになってるっていうのは具体的にどういうことなのか、で結局どうやって進めていくと良さそうなのかを、僕のこれまでの体験を交えながらお話ししたいなって思います。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - Scrumありがとう、そしてさようなら-Scrum 破-

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Experience Report
    Intermediate

    ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。

    私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。

    このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。

  • Liked Oscar Lopez Alegre
    keyboard_arrow_down

    Oscar Lopez Alegre - How long does it take to write a name

    45 Mins
    Workshop
    Beginner

    I would like to propose this game session to improve productivity, this game was ideated by Henrik Knieberg and was a great success on the conference of agile Vietnam 2016 (http://www.agilevietnam.org/conf/2016/)

    When I start coaching scrum teams the number of story points that the team can deliver is usually low. One of the general reasons why teams performance is not high is because the team tries to start all the stories of the sprint backlog as soon as possible. But by trying this the amount of things "done"(AKA working software) at the end of the sprint is very low.

    After this workshop attendants will realise about the impact on multitasking on Delivery, Risk and Productivity.

  • Liked Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Itsuki Kuroda / Takeshi Arai - パネル: DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ

    45 Mins
    Panel
    Intermediate

    DevOps(継続的デリバリー)によって、プロダクト開発は、より短いピッチで仮説検証することが可能になりました。仮説を効率的に実装につなげ、素早くデリバリーして、部分リリースでメトリクスをとって検証する。リーンスタートアップが、大企業でも積極的に採用されるようになった、ともいえます。こうした時代に、プロダクトマネージャーに求められるスピード感や役割そのものが変化しています。おそらく正解もないので、パネルディスカッションを用意することにしました。ぜひ皆さんで議論しましょう。

     

  • Liked Yotaro Takahashi
    keyboard_arrow_down

    Yotaro Takahashi / Hayashi Hiroyuki / Kento Haneda / Kouhei Takamatsu / Midori Hirose / Naoto Nishimura / Naoya Muto - レガシーな組織に @nawoto を入れてみた〜とあるチームの半年間の軌跡〜

    45 Mins
    Experience Report
    Intermediate

     分社して早数年、依然レガシーを極めるリクルートジョブズ。

    その中に突如転職してきたアジャイルサムライこと @nawoto 。

    初めてのメンバー、初めての言語、初めてのチーム開発。

    そして突然はじまったリモートワーク。

    人と、組織の思惑が絡み合う中、いかにしてこのチームはリリースまでこぎつけたのか。目まぐるしい展開の中で @nawoto が下した決断は!?

    混迷の半年間が、各メンバーの口から語られる。

    衝撃のラストを見逃すな!!