Software Engineering at Google: Chapter 3 - Knowledge Sharing

『Software Engineering at Google』の第三章「Knowledge Sharing」を読んだ。以下は感想文である。

知識共有は重要だ。しかし 善意によって 知識共有が妨げられることがあるというのは、面白いと思った。たとえば、エース級の人材が難しいタスクを「僕がやっておきます」と手を挙げるのは善意からの行動だ。しかし、知識がチームに根付かないという意味ではまずい行動である。

知識共有のためにドキュメントを書けばいいのだろうか。必ずしも、それが最善の手段ではない。アジャイルソフトウェア開発宣言には「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」という節がある。それぞれをあわせて、僕は「ドキュメントよりも、対話しながらソフトウェアを一緒に動かす」ことが知識共有にはベストだと考えている。この「一緒に動かす」というのは、ペアプログラミングを通じて、である。つまり、エクストリーム・プログラミングが知識共有に最も効くのでは、ということだ。

この意見に反論があるとすれば、スケールメリットに関するものだろう。ドキュメントは一度書いたら何度も読んでもらえる。一方で、ペアプログラミングはペアにしか知識が伝播しない。とはいえ、ペアをローテーションすることもプラクティスに含まれる。ローテーションさせ続けることで必要な人に知識を行き渡らせることは難しくない。なんなら ペアでドキュメントを書いても良い。

本章では質問者の無知に対して「feigned surprise (驚いたふり)」をしてはならない、とある。心理的安全性を低めるからだ。スタックについて質問しても「えっ、スタックを知らないの?」と返されてしまうような環境では安心して質問をすることは難しい、という例が紹介されている。もし現職で「スタックを知らない」と同僚から言われたら「ふり」じゃなくて、普通にびっくりしちゃう気がするけど、言葉や態度には出さないように気をつけたい。

ところで、心理的安全性について、若かりし頃の苦い思い出がある。僕は 20 才頃は学習塾でアルバイトをしていた。中学生向けの理科の授業のとき、16 方位を教えるため、まず東西南北について話そうとした。僕が「こっちが北だとすると、反対側は何かな?」と生徒に聞いたら、その子が「東...かな?」と答えた。僕は驚いて「えっ!」と声をあげてしまった。東西南北を知らない中学生がいるなんて...というのは、当時の僕には驚きだった。

その後、彼を塾で見ることはなかった。退塾したとのことだ。

この件に関して苦情を受けたわけではない。彼の退塾の本当の理由はわからない。でも、僕自身はこのときの自分の態度を悔いている。たまに思い出して反省もしている。なんにせよ、僕が彼の心理的安全性を低めたことに変わりはないだろう。

さて、他に本章で面白かったことと言えば「質問をすることで、他の人も質問しやすくなる」という話だ。僕は場が静まり返っているときほど質問をする傾向がある。まさに他の人の質問しやすさのためである。こういう所作を本の中で肯定してもらえるのは嬉しく思う。