2章 チームでうまく仕事をするには
HRTの原則
2.1 自分のコードを隠すのを手伝ってはくれないか
2.2 天才神話
既視感すごいと思ったら「Team Geek」の1.2天才の神話にも Linuxやジョーダンの話がありますね
同じ感想を抱きました笑
NetflixでMJのラストダンスを見たばかりだったので、めっちゃ共感した。
というか2章書いたのが「Team Geek」のブライアン・フィッツパトリックでした
各章に著者と編者がいるんですね
そうなんですよね。この本どうやって作ったのか、序文とかはじめに を見返しましたけどよくわからなかった
2.3 隠蔽は有害とみなされる
2.3.1 早期発見
2.3.2 バス係数
プログラミングはきつい。ソフトウェアエンジニアリングはもっときつい。他者の目が必要なのだ。
ここまで言い切るところに迫真さを感じるし、それだけGoogleとして向き合っているということなのかなと思った
バスに轢かれることは滅多にないけど、コロナに罹ることはあるので、こういうリスクの話も最近はしやすくなったと思います。
2.3.3 進捗ペース
エンジニアとオフィスの部分はリモートになってむしろやりやすくなったなーと感じる
開発者ワークフローにおける「左への移動」 の考え方にはこうしたことが全て包含されている。
これどういうことなんだろう
shift Leftの話ですかね?問題は早くに見つかれば見つかるほどいい的な
あえて一般的標語としての「シフトレフト」ではなく「左への移動」にしたって1.2.4の訳注に書いてますね。
shift leftという言葉があるんですね!知らなかった...勉強になります🙏ありがとうございます🙏
↑これどのあたりに書いてありますか? ← 2.3.3でした!P39の下から7行目です←ありがとうございます🙏
2.3.4 要するに、隠れるな
2.4 チームが全て
ソフトウェアエンジニアリングとはチームによる取り組みである
ここも言い切ってますね
2.4.1 社会交流の三本柱
人付き合い上の衝突のほぼ全てについて、根本原因を分析すると、謙虚、尊敬、信頼のいずれか、あるいは複数の欠如に究極的には行き着く。
体感として本当にそう
2.4.2 何故三本柱に意味があるのか
ここでの教訓は、人付き合いのゲーム(social game)をプレイすることの威力を過小評価するなということだ
日本人的には「信頼貯金」という言葉がわかりやすいかも
2.4.3 謙虚、尊敬、信頼の実践
I messageで話すの本当に大事だなあと例を見ていて感じる。「その書き方はこういう理由で間違っている」と「その書き方は自分にとってこういう理由で読みにくい」だと全然違うもんなー
ここの「批判のやり方を学べ、受け方も学べ」とある上での「Google Xではできるだけ早く論破することが推奨される」なんだろうなー。
2.4.4 非難なきポストモーテム文化
「非難なき」というのが重要で、適切なポストモーテム(事後分析)とならないのは、何かしら避難する人がいるからだろうなと、、
顧客向けのポストモーテム(不具合報告書など)は正直に書けない場合があるのが難しいところ
顧客向けのポストモーテムを読む人と共同の「文化」が築けていれば良いという話なんでしょうけど、表に出る文章ですしね
エージェンシースラックという話も
絶対に2人が一緒にペアでプログラムできないところにまで陥り、私たち双方にとって悔しい状態だった。(中略)忍耐と、新しい仕事のスタイルを即席で作り出すのをいとわない姿勢とが、プロジェクトを救い、そして私たちの友情をも救った。
ここまでハッキリと価値観とか手ぐせが分かれながらもうまく協力し合おうってなるチームをつくれるのは本当に素晴らしいなって思う。自分もこういう関係をつくれたのは数人以下だ。
2.4.5 Google的であること
我々は「Google的」という単語の利用は避けるようになった。期待されることというものは、いつでも具体的である方がよい!
「Google的」という言葉が「自分(Google社員)と似ている」になってしまうのと危険なのは本当にその通りだと思う。一方で、どういう行動が「Google的」だと感じたかが言語化できて、それがGoogle社員に共感してもらえるなら、「Google的」という単語を使うのは社員の絆を強めるし文化の形成にも寄与すると思うので全然良いとは感じた。
ただ、「具体的である方がよい!」という考えには共感できるし、それこそGoogle的な考え方だなーと思った。
アンコンシャスバイアスになりやすいっていうのめっちゃわかる。
「integrity」ドラッカーの翻訳だと真摯的とされることが多い気がします
紳士的ではなく真摯的?どちらも間違ってはなさそう
「真摯的」で正しい
2.5 結論
ソフトウェア組織が時の試練に耐えるには
これに対応する部分はどこなんだろう
2.3 かな?
時の試練: 車輪の再発明のリスク、バス係数のリスク、フィードバックループがないことで進捗ペースが鈍るリスクを踏み抜かずにシングルプロセスでやっていくこと
2.6 要約
チームビルディングに投資する価値をコンパクトに示してくれていて、他者に説明するときとかに使えそうだなーと思った。
この章の内容が2章という本の中でも早い段階で来ているのが、(推測だけど)それだけチームというものを非常に重要に捉えているということの証なのかもと思いつつ、「Googleのソフトウェアエンジニアリング」という本の内容に対して抱いていた事前のイメージと違って少し驚いた(もっとなんかガッチリとした理論に基づいたエンジニアリングしてます!みたいな内容だと思ってた)
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
「HRTが大切」で終わるのではなく、具体的に起きた事例ベースでなぜ「HRTが大切」か?が述べられているから
それぞれの章で著者が違うようなのに、1章でもこんなこと書いてあったよね と言ったように何か芯が通っているような気がする。例として適切かわかりませんが、マクドナルド・星野リゾート・TOYOTA・SEGAの従業員のバックグラウンドにある醸成された企業文化のような
「私たちはどう学んでいるのか」という本に「結果マネと原因マネ」の違いが書かれてましたが、後者だということですかね
現場でどこまでできているか?
この章に書いてあることは自分の周りだと全員が意識できているかなあ
残念ながら現場によってはチームというかただの集団で、それぞれが一蘭でラーメンを食べるように黙々と自分のPCで自分のコードとだけ向き合っていることはありますね
緩やかにみんな似たようなことを守れている気もするが、それがHRTなのかと言われるとわからないな〜と思う
この本があるのになぜ実践する企業はすくないのか?
募集要項とかにHRTが書かれている会社も多いので、実践している企業は多そうとは思いつつ、人を代替可能なリソースだと考えている場合は企業は実践が難しそうだと感じた。
HRTの効果を数字で測りにくく他人に説明しにくいから?
望ましいあり方ではあるものの、具体的にどういった行動がそれに当てはまる・当てはまらないのかその線引きが実はわかりにくいからなのかも?
共感はできるけど、自分ごと化しにくいから?
それの乗り越え方はなにか?
ベストは本書で書かれているような内容を参考にチームビルディングや人への投資が必要な理由を説明すること
厳しければ、人を追加したり代替された場合、無理をせずに素直にパフォーマンスを落として、失敗事例を作ってしまう
これらの規範に沿った評価の制度にする?うーんなんかそれも微妙な気もする
少なくとも何か褒められるとかそういう要素が必要な気もする
HRTすべて個々人の細かい行動が積み重なって形成されていくものなので、管理は不可能と思う
いずれも自意識を満たすより生み出す価値を優先できる程度には大人として振る舞うことがもとめられるが、これを定量的に測ったり外発的動機づけで行うのは難しい
特定企業の事情を扱ったものなので、「採用でそういう人をちゃんと見抜く」という結論はアリ
余裕が大事: 衣食足りて礼節を知る、金持ち喧嘩せず、マズローの欲求段階説は古臭いが段階自体は存在している
ステップを小さくするとしたらどうできそうか?
この勉強会みたいに、本章だけを読むのは良さそう
チームの場合 : 普段のふりかえりの時間で月に1度はHRTの原則にそってエピソードを出してみたり、HRTの原則を強めるアクションを会話してみるとか
マネジメントの場合 : チームが組織に対してHRTの原則を実感できていない部分をインタビューするとか、1on1のときの話題の1つにするとか
価値観にかかわる問題なので、いきなりこれを押し付けてもうまくはいかなさそう
チームに起こっている問題を解決するのはHRTなんだ、ということを全員で納得しないとプラクティスには持っていきにくい
ストーリーが必要かも?