3月4日（水）に TeamGeek 読書会@札幌 -4を開催しました。
今回はチームの同期（意識を合わせること・作業の質を合わせること・情報を共有すること）、コードについてディスカッションしながら読み進めていきました。
すべてはコードに通ず
2.9を改めて読み返したのですが、1ページしかないこの章、すごく良い。
強いチームは自然発生するものではなく育ててゆくもの
コードはマシンとのやり取りではなく人と人とのコミュニケーション
コードを書くことを目的とする強いチームは、膨大なコミュニケーションを通じて育っていくもの。コードもコミュニケーションの一つであり、ただのマシンへの命令文ではない。
話したこと
会議のこと
「良い会議」「悪い会議」「必要だけどもっとうまいやり方がありそうな会議」について身近な例で話し合いました。
- 目的がはっきりしている
- 必要な人”だけ”が参加している
- 事前に考えをまとめて会議に臨める
- 適切なファシリテーター
経験上、これらがない会議はだめになることが多いということで意見が一致しました。
（悲しいことに、現実としてこういう会議はけっこうあります）
“もっとうまいやり方がないだろうか？”はみんなで話し合って、いくつかためになりそうな意見が出せたのでとても良かったです。
日常的な議論のためのツール
いわゆるコミュニケーションツール。
現在だと「メーリングリスト」「IRC」「Facebookメッセンジャー」「Skype」「line」「Googleハングアウト」「Idobata」「GitHub」「Facebookグループ」などが挙がりました。
lineがチームのコミュニケーションツールの一つになっているというのにはびっくりした。
（例えばリリース直後の反応や喜びのテンションがリアルタイムにスタンプとかで流れてくるみたい！）
これらのツールは
- コミュニケーションのきっかけになるもの
（話しかけやすいけど過去ログは流れやすい、気軽なかんじ） - 意思決定をオフィシャルにするための道具
（アーカイブが残る、必ず全員の目に触れる、少し敷居が高いかも） - コンタクトまでの早さ
（逆の視点から言うと割り込みの発生しやすさ）
という観点で分類できるよねという話になりました。
それぞれ向き・不向きがあるのでうまく使い分けていくことが大事ですね。
疑問点
「同期」の話でいきなり設計書が出てきたこと
ミッションステートメント → ミーティング → 地理的障害の克服 → 設計書という順番で紹介され、最初は？と面食らいました。私たちが普段知っている設計書だと、この流れには合っていないような気がしたからです。
原著を調べてみると、設計書は「Design Doc」と書かれていました。
そこで GoogleのDesign Docについて調べてみたところ、私たちが想像していた「設計文書」とは違いそうなことがわかりました。
実際にGoogleでドキュメントを公開しています。
全てを読めていないのですが、よく言われる「設計書」というよりは、私たちがwikiに残している記録に近い感じがしました。
読書会の進め方
黙読しつつ付箋に思ったことを書き、話し合いのときに付箋を出しながら進める。
という方法で確立されてきた感じがあります。
話が発散・前後しないように付箋を出すタイミングだけを気をつけるようにしたい。
次回は4月2日（水）開催です。
いよいよリーダーについての章に入ります。
実際にリーダーをやっている人達の話をたくさん聞けたらいいなあと思います。
TeamGeek 読書会@札幌 -5