社会人の入門書 Team Geekを読んだ

Amazonレビュー的な何か

入社した初日にScramについて何かいい本がないかと偉い人に聞いた際、Team Geekをオススメされました。

他の書籍を読んでいて存在を忘れていたのですが、チームメンバーも社会人入門書としてTeam Geekを推していたので読んでみました。

まさに、社会人入門書。帯にあるように、「ギークでなくても本書のアドバイスは読む価値がある。」はその通りです。

最高のチームの基礎は、HRT文化があることです。Humility(謙虚)、Rspect(尊敬)、Trust(信頼)の3つです。

具体的なHRT文化の例として、コードレビューに所作についての言及がされています。

君は君の書いたコードではない。 私は、この意味に気づくのに入社して1ヶ月もかかりました。

当初、PRレビューの仕方がよくわかりませんでしたが、コードに全員が責任を持つという意識を持ち始めてコツを掴めたのです。

チームで開発する中で、PRレビューの仕方にだんだんと慣れてきましたが、もっと早く読んでいればという後悔があります。

ちなみに、今ではレビューしてくれる人がつまづかないように、どういう経緯でコードを書いたのか。レビューする時には、自分の中で学ぶなどをコメントに書いています。HRTレビューは、チームを強靭にする一つの方法ですね。

書籍を通して、一番印象に残ったのは ミッションステートメント(いや、マジで) です。いや、これはマジ同意しかないです。

ミッションステートメントとペルソナが明確な組織は強いと思いました。

ペルソナは、ソフトウェア開発をする意味と目標を与えます。ミッションステートメントは、ソフトウェアのイデアです。

二つの明確なゴールがしっかりとしていなければ、不幸なチームができてしまうのでは、ないでしょうか。

なぜ、ミッションステートメントが印象に残ったのか考えてみると過去に苦しみ、現在もまた苦しんでいるからです。

過去の苦しみとは、大学での学生同士の開発です。世の中に、単位のかかったソフトウェア開発ほど上手くいかないものはないのではないでしょうか?そう、ミッションステートメントが真逆だからです。ある学生は、単位がもらえる最低限度のソフトウェアを望みます。また、ある学生は学びが多くなるように技術的好奇心を満たすソフトウェアを開発しようとします。

「チーム開発を学ぶ講義は、チーム開発を嫌いにする」というぐらいミッションステートの方向性が異なる崩壊チームは、チーム開発への嫌悪感を抱かせます。私は、いまだに学生同士のソフトウェア開発を成功させる方法がわかりません。

現在でもミッションステートメントでつまづいていることが、印象に残った理由です。

社会人になり、チームでの開発が上手くいってもまだ満足な開発は、できないことに気がつきました。

自分の認識できる範囲だと、一つの事業部署単位でチームになる必要があります。そう、事業部全体でミッションステートメントを共有する必要があるのです。

最後の章でも述べられているように、エンジニア以外のチームとの共有です。書籍では、マーケターでした。

ソフトウェアを開発して届ける。その過程全体に関わる人、全員でチームにならなければならないのです。

勢いで、書き殴ってしまったので少し締めようと思います。

Team Geekは、チームをマネージメントするだけが読む本では、ありません。全ての人が読む価値のある本です。

楽しい職場にしたいと願う全ての人にオススメの本でした。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか