はじめに
とりたてて読む動機はなかったのだけれども, 図書館でふとタイトルに止まったので借りて読んでみました.
内容
Google のエンジニアがエンジニアの働き方について書いた本.
薄い本なのですぐ読める (1-2 時間) しかし, 得るものはおおい. 講演を元にしているようで,口語で軽い語り口だほ
- 1 章 天才プログラマの神話
- 2 章 素晴しいチーム文化を作る
- 3 章 船にはキャンプテンが必要
- 4 章 有害な人に対処する
- 5 章 組織的操作の技法
- 6 章 ユーザーも人間
感想
1 番こころにのこったのは, 第 3 章だ. この章は, マネージャーについてかかれている.
管理職にはなりたくない
正直にかくと, マネージャーにはなりたくない.
消極的な理由は, 自分はひとをまとめる力がなくて, メンタル的に打たれよわいから. また, 自分のまわりにいるマネージャーをみると, いつも障害対応でクタクタになっているように見える.
積極的な理由は, コードを書く時間がなくなるから.
サーバントリーダーとテクニカルリーダー
マネージャーは, 野球部の女子マネージャーのような存在で, 野球選手が輝くためのことをするべき存在だと思っていた.
そんな自分の思いを移すような内容だった. この本では, それを
サーバント・リーダー
と表現している. 19,20 世紀的なマネージャー観とこれからのマネージャー観は違うと書いている. 野球選手やお笑いタレントを影で支えるのがマネージャーの仕事.
その代わりにサーバント・リーダーとともに, 技術的にチームを引っ張っていくテクニカル・リーダーの存在も書いている. 会社がうまく回るためには, サーバントリーダーとテクニカルリーダーの存在が不可欠なのだと.
自分のなりたい姿について
あっというまに, 読んでしまったのだけれども, 少なからず自分のこれからの仕事観に影響を受けた.
自分の将来が未だに描けないのだが, 自分はテクニカル・リーダーになりたいと思った. 従来のような管理職にはなりたくない.会社の仕組みとか人の管理とか, 興味ないし.
実現したい想いをもって, ストーリーを描けるようになりたい.
もしかしたら, そのためにはコードを書くことを犠牲にするかもしれない. 協力してくれる仲間を巻き込んで, 1 人ではできないような大きなことを成し遂げるのも, それはそれでいい.
仕事をつくるのは誰か?
現状のマネージャー独裁運営から, テクニカルリーダーとサーバントリーダーによる共和制に移行するためには, テクニカルリーダーがもっとお金稼ぎについて責任をもつ必要がある.
今の職場では, 仕事はマネージャーがつくりだすものだけれども, これからは, メンバの 1 人ひとりが, 新しいビジネスにつながることを考えないといけないと思う. そのためには, 一人ひとりが技術の動向についてもっと追いかけ, 議論して, 新しい金の卵は落ちていないか探す必要がある.
今, 自分の所属している部署は, 売上が減ってきている. 受託開発を長年しているのだけれども,受託が減ることはこの先は明らかなのだ. 生き残っていくには, 新しいことにチャレンジする必要がある.
しかし, 自分の目からみると, どうも回りの人は技術の動向に疎いように見える. 家に帰ってプログラミングをすることを厭うような文化がある. 家庭のためにプログラミングを通じてお金を稼ぐサラリーマンのような.
今までは仕事があったからよかったのだけれども, これからは, 一人一人がもっともっとお金稼ぎについて 頭をひねるようなことをしないといけないと感じている.
そんな状況で, 自分にできることはなんだろうか?
ということを考えることが, 今受けてる会社の研修内容だったりする. 答えはおぼろげなので, ここまで.
Bookmarks
以下, 心に残ったものを抜粋する.
天才プログラマの神話
ソフトウエア開発は チームスポーツ である.
隠したらダメになる.いつも一人でやっているとリスクが高くなる. 成果を共有することで バス係数 (冗長性) が高くなる.
ソーシャルスキルの三本柱は以下.(HRT)
- 謙虚 (Humility) 世界の中心は君ではない. 君は全知全能ではないし, 絶対に正しいわ けでもない.つねに自分を改善していこう.
- 尊敬 (respect) 一緒に働く人のことを心から思いやろう. 相手を 1 人の人間として扱い, その能力や功績を高く評価しよう.
- 信頼 (Trust) 自分以外の人は有能であり, 正しいことをすると信じよう. そうすれ ば, 仕事を任せることができる.
素晴らしいチーム文化をつくる
コミュニケーションの原則は, 同期コミュニケーションの人数を減らし, 非同期コミュニケーションの人 数を増やすこと である.
コミュニケーションツール
- ミッションステートメント
- プロジェクトが目指す姿を短い言葉で表現して共有する.
- 方向性 と スコープの制限 を明確にすること.
- 企業のわけのわからない抽象的な表現がミッションステートメント をダメにしている.
- 効率的なミーティング
- ミーティングに 5 以上参加させてはいけない.意思決定者がいなけ れば, 決まるものも決まらない.
- ミーティング中にノート PC をいじってメールチェックをしている人 は参加しなくていい人.
- ミーティングを開くときの簡単な 5 原則
- 絶対に必要な人だけを呼ぶ
- アジェンダを作ってミーティング開始前に配布する
- ミーティングのゴールを達成したら時間前でも終了する
- ミーティングを順調に進める
- ミーティングの開始時間を強制的に中断される時間の前に設定す る (お昼休み, 就業時間)
- 設計文書
- 設計文書は 1 人が所持するもの. 大勢の人がレビューして, 2,3 人の人が承認するもの.
- 何をどうしたいのかを低コストでチームに伝える手段.
- タスク分割につかうもの.
- プロジェクトが進むにしたがって更新するべきもの.
- メーリングリスト
- チームが同じフロアにいるのであれば, メーリングリストで議論す る必要はない.
- 議事録・ミーティングメモ・決定事項・設計文書などをメーリング リストに投稿して, 記録をまとめる.
- オンラインチャット
- 信じられないほど便利なツール. 他人の作業を邪魔することなくリクエストを送信できる.
- IM では, チーム内での情報共有ができない.
- 課題管理ツール
- ただの掲示板. メーリングリストと同じ.
- バグの優先順位をつけることができる.
- コードレビュー
- すべてのコミットにコードレビューする.
- コードの監視方法をプロダクトに導入する.
- コードの行のスタイル・品質・ケアレスミスを第三者が確認するべき.
船にはキャプテンが必要
リーダとマネージャー
マネージャーは, “サーバント”, 執事のような存在だ. 芸能人のマネージャーがタレントの活動をサポートするための黒子に徹す るのと同じように, マネージャーはチームのエンジニアに最高のパフォー マンスを発揮させることが使命.
一方, リーダはすべてのエンジニアに要求される役割.
トンガリ頭のマネージャーは, 軍隊の階級制度を散光にして, 産業革命の ときに導入されたもの.向上では組み立てラインの稼働を労働者に命令する 必要があった.
エンジニアリングの世界でも時代遅れの マネージャ"という肩書きを使っ ている.マネージャーじゃなくて, リーダーにしたほうがいいと思う.
マネージャーになりたがらない理由はたくさんある.ぼくたちが耳にした大 きな理由は, コードを書く時間が少なくなるから.
もう一つの語られない大きな理由は, “階層的な組織に属する人間は,必ずその人の無能レベルまで昇進する”
マネージャーは, サーバントリーダーとして謙虚・尊敬・信頼の雰囲気をつくり 出さなければならない. これは, エンジニアでは対処できない社内の障害物を排除することかもしれないし, チームの合意形成を支援することかもしれない.あるいは, 夜遅くなった時にチームに夜食を買ってくることかもしれない.
マネージャーになるメリットは, 自分のストーリーを描くことができるから. また, 自分がコードを書く代わりに, チームメンバを利用して より多くのコードを書くことができるから.
その他
1 週間に書いたコード行数のような意味のない (デラタメな) 方法で生産性を計測する会社もある. (行数が少ない方がいいに決まっている)