随分前に読了していた「Team Geek」を、思うところあって再読したところ、以前とは違った発見があった。 (今まで分かっていなかったことが、ようやく分かるようになってきた。)
Mission Statement
本書には、書籍には珍しく「Mission Statement」が宣言されている。 これによりスコープが特定され、対象読者の明確化が行われている。
本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。
本書で語られていること
今の自分にとっては、そういうメッセージとして受け取ることが出来たという話。
本書は、個人が”天才”という理想と幻想を捨て去るところから始まり、人と人とが協力しあうチームを形成し、組織的な協力をもとにユーザに価値を届けようとする1つの物語である。
最初にこれを読んだ頃は、まだ「チーム」というものが十分に分かっていなかったのかもしれない。 それこそ、スター選手のような先輩方に囲まれた中で、理想と幻想の区別がつかず、チームの協力関係にこそ真価があるという現実を見ていなかったのかもしれない。
今では、個々人の能力の素晴らしさもさることながら、個人が個人としての本当の能力を発揮するためにも、最高のチーム（そして文化）を作ることは非常に重要だと思うようになった。
各章で語られていること
1章では、個人の限界を語っている。 誰もが天才に憧れる一方で、そんなスポットライトに照らされたスーパースターの周りにいるチームこそ真価がある。 同僚たちとうまく協力できるかにかかっている。 重要な変化は自分から始まることを説く。
2章では、「チーム文化」を語り、個々を集合させた群としての振る舞いを語る。 コミュニケーションだけでは得られない、経験・価値・目標を共有することの重要性を説く。
3章では、「さてチームができたはいいが、どう舵をとればいい？」という問題に対して、チームを率いていくリーダー (キャプテン) の必要性を明らかにする。 例えばサーバントリーダーのような、様々なリーダーのあり方を説明する。
4章では、「さあチームとキャプテンは揃った、前へ進もう！」というときに現れる、厄介な”振る舞い”をどうハンドリングするか、という話になる。 厄介な振る舞いは人間がするが、本当に害なのは”人間”だろうか？ 本当の脅威はどこにあるのか、害ある振る舞いを排除するにはどうすればいいのかを説明する。
5章では、さらに規模を拡大させ、組織に対しての振る舞い、ガバナンスを説く。 泥臭いし、エンジニアはこういうことを何より嫌がるが、組織を味方につけることは重要だと思う。
6章では、ようやく一丸となったチーム、組織が、最終的に相手をしなくてはならない存在、つまりユーザーに対する向き合い方を説明する。
終わりに
最近、組織の人材教育・学習に関する書籍を読むようになった。 その影響を受けてか、Team Geekは「エンジニアが分かりやすく読めるように構成されたマネジメントやガバナンスの本」なのかなあと思った。 (マネジメントは本書の対象外だが、興味を持つキッカケを作っているとは思う。)
本書では、謙虚・尊敬・信頼の英単語の頭文字をとった、HRTという概念が丁寧に扱われている。 大変良い言葉でパワーがあるため、皆この単語を気に入るが、実際どうしたらいいの？というのは難しい。
HRTを他人に説くことは、HRTな態度だろうか？という疑問もある。 本書の第1章にある通り、「重要な変化は君から始まる。そこから他の人に広がっていく。」のだろう。 多くの喩え話や教訓が語るように、他人を変えることは出来ない。 変わるかどうかは、本人が決めることである。
また、HRTという大事な概念の理解を深めるためにも、Team Geek以外の書籍でも学ばなければならない、と思うようになった。 例えばエドガー・H・シャイン先生の本は、結構難しい内容なんだけど、読み応えがあって良い。 “Humble Inquiry” (放題「問いかける技術」)は、「謙虚さ」にフォーカスを当て、人から話を引き出すことで解決に導くことの大切さ、その実践方法を説いている。
チームという存在は、本当に多様で難しいが、それだけの価値と素晴らしさ、幸せの形があると思う。
目次
- 1章 天才プログラマの神話
- 1.1 コードを隠して
- 1.2 天才の神話
- 1.3 隠したらダメになる
- 1.4 チームがすべて
- 1.5 三本柱
- 1.6 実践 HRT
- 1.6.1 エゴをなくす
- 1.7 批判の配分と対応を学ぶ
- 1.7.1 早い段階で失敗・学習・反復する
- 1.7.2 学習のための時間を残す
- 1.7.3 忍耐を学ぶ
- 1.7.4 影響を受けやすくする
- 1.8 次のステップ
- 2章 素晴しいチーム文化を作る
- 2.1 文化とは何か
- 2.2 なぜ気にかける必要があるのか？
- 2.3 文化と人々
- 2.4 成功する文化のコミュニケーションパターン
- 2.5 ハイレベルの同期
- 2.5.1 ミッションステートメント（いや、マジで）
- 2.5.2 効率的なミーティング
- 2.5.3 「地理的障害」のあるチームで働く
- 2.5.4 設計文書
- 2.6 日常的な議論
- 2.6.1 メーリングリスト
- 2.6.2 オンラインチャット
- 2.7 課題管理ツールを使う
- 2.8 エンジニアリングとしてのコミュニケーション
- 2.8.1 コードコメント
- 2.8.2 ソースコードに名前を書く（別名：「Authorタグ」問題）
- 2.8.3 すべてのコミットにコードレビュー
- 2.8.4 リアルなテストとリリースプロセス
- 2.9 すべてはコードに通ず
- 3章 船にはキャプテンが必要
- 3.1 自然は真空を嫌う
- 3.2 @Deprecatedマネージャー
- 3.2.1 「リーダー」は新しい「マネージャー」
- 3.2.2 1つだけ怖いのは ……まあ、全部だ
- 3.3 サーバントリーダー
- 3.4 アンチパターン
- 3.4.1 アンチパターン：自分の言いなりになる人を採用する
- 3.4.2 アンチパターン：パフォーマンスの低い人を無視する
- 3.4.3 アンチパターン：人間の問題を無視する
- 3.4.4 アンチパターン：みんなの友達になる
- 3.4.5 アンチパターン：採用を妥協する
- 3.4.6 アンチパターン：チームを子どもとして扱う
- 3.5 リーダーシップパターン
- 3.5.1 エゴをなくす
- 3.5.2 禅マスターになる
- 3.5.3 触媒になる
- 3.5.4 先生やメンターになる
- 3.5.5 目標を明確にする
- 3.5.6 正直になる
- 3.5.7 幸せを追い求める
- 3.5.8 その他のヒントやトリック
- 3.6 人は植物
- 3.7 内発的動機と外発的動機
- 3.8 最後に
- 4章 有害な人に対処する
- 4.1 「有害」の定義
- 4.2 チームを強化する
- 4.3 脅威を特定する
- 4.3.1 他人の時間を尊重しない
- 4.3.2 エゴ
- 4.3.3 権利を与えすぎる
- 4.3.4 未熟なコミュニケーションと複雑なコミュニケーション
- 4.3.5 パラノイア
- 4.3.6 完ぺき主義
- 4.4 有害な人を追い出す
- 4.4.1 完ぺき主義者には別の方向性を示す
- 4.4.2 生命体にエサを与えない
- 4.4.3 感情的にならない
- 4.4.4 不機嫌の真実を探せ
- 4.4.5 優しく追い出す
- 4.4.6 諦めるときを知る
- 4.4.7 長期的に考える
- 4.5 最後に
- 5章 組織的操作の技法
- 5.1 善玉、悪玉、戦略漢
- 5.2 理想：チームがうまく機能している会社
- 5.2.1 理想的なマネージャー
- 5.3 現実：環境が成功の邪魔になっているとき
- 5.3.1 悪いマネージャー
- 5.3.2 オフィスの政治家
- 5.3.3 悪い組織
- 5.4 組織を操作する
- 5.4.1 許可を求めるより寛容を求めるほうが簡単
- 5.4.2 道がないなら道を作る
- 5.4.3 上司の管理方法を学ぶ
- 5.4.4 運と親切の経済
- 5.4.5 安全なポジションまで昇進する
- 5.4.6 強力な友達を探す
- 5.4.7 忙しい経営者に（メールで）お願いする方法
- 5.5 プラン B：逃げる
- 5.6 希望は残されている
- 6章 ユーザーも人間
- 6.1 一般認識を管理する
- 6.1.1 第一印象に注目する
- 6.1.2 小さく約束して、大きく届ける
- 6.1.3 業界のアナリストと付き合う
- 6.2 君のソフトウェアはどれだけ使いやすいだろうか？
- 6.2.1 観客を選ぶ
- 6.2.2 ハードルを下げる
- 6.2.3 ユーザーではなく利用を計測する
- 6.2.4 速度重要
- 6.2.5 いろいろ手を出さない
- 6.2.6 怠けない
- 6.2.7 複雑さを隠す
- 6.3 ユーザーとの関係を管理する
- 6.3.1 見下さない
- 6.3.2 我慢する
- 6.3.3 信頼と喜びを作る
- 6.4 ユーザーのことを忘れない
- 6.1 一般認識を管理する
 | オライリージャパン 発売日 : 2013-07-20 |