この記事はACCESS Advent Calendar 22日目の記事です。
こんにちは ACCESS開発本部IoT開発部の渡辺 (@sassy_watson) です。
今回は私がコミュニケーションについての記事を書きたいと思っています。
コミュニケーションの難しさ
一人でコードを書いてサービスやプロダクトを作ることもできますが、
ある程度大きなものを作る場合はやっぱり一人じゃ限界があります。
いろんな人に気持ち良く使ってもらうソフトウェアは、やっぱり複数人が関わって開発する必要があります。
しかし、人間、生まれ育った環境も違えば信じる宗教も違います。
そこで意思疎通するのは非常に大変です。
特に私みたいにコミュ障の人間は非常に苦労します。
しかしこの問題をうまく解決しないと、ものを作るのに支障が出てしまいます。
今回はこのコミュニケーションについて考えようと思います。
隣の人がなにをやっているかわからない問題
トランザクティブ・メモリー
上記に書いてあるように、
組織においては「誰が何を知っているか」を把握するのはとても大事です。
Aさんが１週間悩んでいることをBさんが１時間で解決してしまう、そんなことがあるかもしれません。
Bさんに聞けば一瞬で解決するのに、それを知らなかったためにAさんが苦労するのはもったいないです。
また、ちゃんとみんなが何をやっているかということを把握していないと、
Xという部署とYという部署が同じものを作るといったことが起きてしまいます。
こういったことも避けなければいけません。
メンタルの管理
きちんとコミュニケーションをとらないと、
隣の人のメンタルケアができないということがおきます。
良かれと思ってやっていることが相手に負担だった、そんなことがあるかもしれません。
メンタルがやられるのは、決して長時間労働だけじゃありません。
ここらへんに気づくためにもコミュニケーションをきちんと取らなくてはならないと思います。
「態度」と「型」
コミュニケーションの問題を解決するには、
一つは「態度」、もう一つは「型」だと思っています。
なにかコミュニケーションでつまづいたらここを見直すことが大事だと思っています。
態度
HRT
コミュニケーションの基本は
HRT(謙虚・尊敬・信頼)です。
コミュニケーションをするうえでこの三つは意識して行う必要があります。
例えばコードレビューを行うとき、謙虚な姿勢でいるでしょうか？
自分の言っていることがわからなくてイライラしたりしていませんか？
もしかしたら自分の説明が悪いかもしれないのです。イライラするのはそこに傲慢な態度があります。
また指摘の仕方も相手の人格を否定していませんか？
相手に対してきちんと尊敬の念を込めて
ものをいうようにしましょう。
こういったことは実は人として基本的なことではあるのですが、
エンジニアは意外とできていなかったりします。
HRTに関しては、「Team Geek」という本に詳しく書いてあります。
ぜひ読んでみてください。
型
ももいろクローバーZをはじめ、アイドルグループを応援している人はわかると思いますが、
実はアイドルグループの応援は「型」が決まっています。
曲の途中で「うりゃ！ おい！」というところもあれば、
メンバーコールするところもあれば、振りコピするところもありますが、
全部これは決まっています。
型が決まっていることにより、初めての人でも楽しめるようになっているのです。
コミュニケーションも同じです。
要するに、コミュニケーションを円滑にするために、型を決めてしまえばいいわけです。
レビューだったら、Githubのpull requestを出して、
該当する行にコメントをつける、
OKだったらLGTM画像をはりつける、
そういう型を決めて仕舞えば、コミュニケーションが円滑になるわけです。
会議もツールのひとつ
よく「会議はムダ」と聞きますが、本当にそうでしょうか？
僕は会議はコミュニケーションツールの一つと考えているので、
ムダだと感じるのならばツールの使いドコロがまちがっているので、やめてしまえばいいと思うし、
必要ならば開催すればいいと思います。
たまに対象のことをなにもいわずに「会議」そのもののが意味がない的なことを語る人がいますが、ナンセンスだと思います。
例えばその会議に自分が必要ないと思ったら、参加するのはヤメればいいと思います。
コミュニケーションのデバッグ
コミュニケーションが円滑に進まない場合は、なんらかの障害があるはずです。
その原因をつきつめてデバッグする必要があります。
デバッグも対処療法ではなく、根本原因をつきつめて、
それがおきないような「型」を導入することが大事です。
導入した「型」が合わなかった場合は必ず見直します。ここは、Try & errorです。
デバッグするときは「HRT」を意識するようにします。
「HRT」がかけているとうまくいきません。
では、どうやってコミュニケーションを円滑にするか、具体例を書いていきます。
あんまり目新しいこともやっていないし、参考にならないかもしれませんが。
チーム内のコミュニケーションの具体例
デイリーミーティング
デイリーミーティングやってますか？ チームによっては"朝会"と呼ばれてるかもしれません。
私の現在のプロジェクトもやっています。
対面でコミュニケーションをする機会をつくらないと、
モクモクとコードを書くことに集中してしまい、
もしかしたら仕様を勘違いをしているかもしれませんし、もしくは実はつまらないことで悩んでいて
チームメンバーがヒントを持っているかもしれません。
また実は進捗が遅れているが、コードに夢中になっていて気が付かないかもしれません。
問題点に早めに気づきけるように対面でコミュニケーションをしておくといいと思います。
デイリーミーティングでは、型がきまっていて、
やったことと、これからやることを言っていくという基本的なことをやっていきます。
あくまでも現状を把握して問題点をはやめにキャッチアップするきっかけを作る場です。
朝やる必要はない
私のプロジェクトは夕会をやっています。
夕会の方がいい理由は、
区切りをつくってダラダラ残業しないようにする。
その日の問題にぶち当たってモヤモヤしてるのを話しておくことで、ちょっとでも不安を取り除く、もしくは翌日問題解決の話し合いの機会を設定してもらってすっきりさせる。
これはプロジェクトの特性によって変えればいいと思います。
立つことが目的ではない
デイリーミーティングは立ってやることにこだわる人がいますが、
別に立つことは重要ではないです。
短時間で終わらせれば座ってやってもいいわけです。
短時間で効率よくやることを意識しましょう。
たまに長時間ダラダラ立ち話しているプロジェクトをみますが、いいとは思いません。
(意外とみんな体力があって長時間立ってても苦にならないってこともありますからね。)
ただ、その場で問題を解決しておきたいなら解決するのもアリだと思います。
その場合はとことんやりましょう。
あんまり「こうすべきだ」ということにこだわって目的が達成されないのは本末転倒です。
必要ないと思ったら思い切ってやめる
とにかく、惰性でやっているならば時間の無駄なのでやめてしまっていいと思います。
この会は本当に必要かどうか判断できるように、きちんと考えて行動する。
見直す、ということは大変重要です。
ただ今日やったこと、明日やることをダラダラ言って終わってるだけだったら
意味が無いのでやめちゃいましょう。
顧客とのコミュニケーションの具体例
ミーティングの数を増やす
お客様とはとくに会社単位で文化が違ってしまいます。
また、対等な立場ではないため、誤解を生むことが多かったりします。
もしかしたら相手の社内事情で情報が出せないかもしれませんが、口頭だったら話すことが可能かもしれません。
この場合は時間をかけてでも対面のコミュニケーションの手段を増やしましょう。
相手の表情をみることで、誤解を生じることも少なくなると思います。
ビデオ会議
といってもお客様との拠点が遠い場合は訪問するのも大変です。
その場合はビデオ会議ができるかどうか聞いてみましょう。
私のプロジェクトも週１の訪問だけだったのが、
あと週に１回のビデオ会議を増やすことにより、
問題点の解決だったり疑問点の解消だったりがスムーズに行えるようになりました。
ツールも重要
やり取りにツールを導入するのも重要です。
さきほど情報は出せなくても口頭だったら話せるかもしれないといいましたが、
逆に口頭だけだと認識の齟齬があったりするかもしれません。
たとえば、お客様と自分たち両方が観れるバグトラッカーがあれば、
なにかバグを発見したときに再現手順も含めてチケットを切って貰えばいいのです。
またそのチケットに情報を書き込んだり進捗率を書き込むようにすれば、
お客様がこちらの進捗を把握することが可能になるわけです。
会社でのコミュニケーションの具体例
Fika
週に２回、Fikaというコーヒータイムをやっています。
こちらでは技術情報の交換だったりディスカッションだったりをしています。
この試みで、誰が何をやっているかだったり、誰が何に詳しいかを把握したりできます。
問題点は参加者が少ないことですが…・
ちなみにFikaにはfikanoteというツールを使って情報のソースを記録したり議事録をとったりしています。
https://github.com/gmkou/FikaNote
Weekly Hack Hour
週に１度、みんなで集まってコードを書く回をやっています。
趣味である程度コードを書いていたい、
見つけた問題点を解決するコードを書きたい、
またはマネジメントの仕事をしているためほぼコードを書かなくなった人がコードを書きたい、
なとなど個々人のモチベーションは違いますが、
一人だとあんまりコードを書こうという気持ちになれない人があつまって
みんなでコードを書く回です。
やりたいことだけをとことんやります。
大事なのは毎週やり続けるという事です。
ゆるく集まってゆるく解散しますが、
できたものはみんなで共有して意見をもらったりします。
こちら、ずっとやってた試みですが、
最近集まりが悪くなりちょっとサスペンドしてますが、なんとか再開したいな〜と思ってます。
チャット
会社の標準のコミュニケーションツールはメールなのですが、
一部HipChatを導入しています。
メールだと非同期で情報の伝達が遅れたり、埋もれてしまったりといった問題点が多く
チャットだと円滑なコミュニケーションがとりやすく重宝しています。
例えば難しいバグがあって誰かと相談したくなったら
グループチャットに話しかければ、誰から問題解決のヒントをくれるかもしれないし、
解決方法の議論をしてくれるかもしれません。
もしかしたらフロー状態でコードを書くのに集中したいメンバーもいるかもしれませんが、
そんなときはあとでログを見返せばいいのです。記録が残るのもチャットのいいところです。
ただ、やはり古い会社なのでチャットを使いこなせない人が多かったり、
古いツールにこだわってる人がおおいため、まだまだ使うのにはハードルが高かったりします。
飲み会は問題解決にならない
コミュニケーションの問題を解決するのに、必ず「飲み会」とか「宴会」を提案する人がいます。
ただ、個人的にはこれは問題解決にはならないと思っています。
なぜならば、これは、根本的な原因をみつけて修正する、という行為を怠っているからです。
飲み会は要するに、例外がでるプログラム全体をtry-catchで囲んじゃえ、って言っているようには思えないからです。
たぶん他にも解決する方法があるので、きちんと解決策を「考える」ということを行いましょう。
いろいろ考えた結果、飲み会が最適なソリューションという結論になればそれはそれでいいと思います。
まとめ
コミュニケーションについてとりとめもなく書いてみました。
(本当は簡潔にまとめなくてはいけないんだろうけど、ダラダラと書いてしまいました。)
まだまだ問題点はたくさんあると思っていますし、デバッグが必要だと思っています。
これからもいろんな文化を取り入れて
コミュニケーションを円滑にできるようにして、さらに組織力を向上させたいなーと思っています。
明日は @pankona さんです。
明日もよろしくお願いします。