Feedback Loop

サービスを作るとき、その仕様について議論する。この機能はどうあるべきか、この画面には何が表示されるべきか。議論の内容が複雑になるときもあるが、その時に気をつけたいのが空中戦にならないことだ。

空中戦とは地に足がついてない様で、仮定の上に仮定を重ねたり、イメージだけでなんとなく話していたりする状況。こういうときは具体例を出したり、ホワイトボードに情報を書き出したりして一度全員の視線を同じ箇所に集めたい。私は本当に重要なことはシンプルに表現できると思っているので、会議の参加者の数人しか話についていけないような状況は不健康に感じる。最先端の話をしているようであって、実は誰にでもわかる言葉にできるほど解像度が高くないだけな気がする。

チームに新しいメンバーが入るとチームが活性化するが、これは各個人が持っている暗黙知が言語化される機会が強制的に作り出されるのが大きい。なんとなくやっていたことの手順や目的を明確化する。他メンバーにとってはもちろん、自分自身にとっても良い振り返りになる。新メンバーからの質問はチームを強化するが、新メンバーからすると自分だけ分かってないような気がして気が引けて聞きづらいときもある。そんな時もやはり、「誰でもわかる地に足ついた話」を目指していることを伝えておけると幾らかは言いやすくなる。経験上、一人が話についていけてない時は大抵他の数人も分かってなかったり、理解しているつもりで少しずつズレてたりする。

暗黙知を言語化する方法は口承でもドキュメント化でもなんでも良いが、ソフトウェア開発でいうとコード上で表現することもできる。技術構成をコードで示したり、コーディングルールを設定ファイルに記述する。チームのルールから踏み外した場合はエディタ上でフィードバックされたり、あるいは勝手に自動修正される。ドキュメントは作って終わりではなく運用が必要で、更新を忘れると実際のソースコードと状態が乖離してしまう。その点ソースコードで表現しておけばズレようがないので管理を一元化できる。

前職ではペアプロという手法を導入しており、これは二人で一つのコードを交代しながら書いていくというもの。それだけでもすでにユニークだが、さらに毎日ペアを変えるペアローテーションという仕組みがあった。機能開発を誰かが担当するのではなく、その担当者がクルクル変わる。そうすることで毎日仕様や構成を言語化する必要がある。ドキュメントは陳腐化しやすいので、そうではなく細かく常に情報を同期しようというやり方で、わりとうまく回っていた。最適な手段は人や場所によって異なると思うが、地に足のついた議論は意識しておきたい。