前回は 第2部 文化 6章 スケールするリーダー、を読んだ。
今回は
- 『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』Titus Winters、Tom Manshreck、Hyrum Wright 編、竹辺 靖昭 監訳、久富木 隆一 訳 https://amzn.to/3YrMBEn
の第2部 文化 2章 チームでうまく仕事をするには、を読んでいき、学んだことや考えたことや印象的なことを記していく。
2章 チームでうまく仕事をするには
本章において決定的に重要な考え方は、ソフトウェア開発とはチームによる取り組みであるということだ。そして、エンジニアリングのチームで（あるいは他のどんな創造的共同作業でも）成功するためには、「謙虚、尊敬、信頼」という中心的原則をめぐる自身の行動を改革する必要がある。
ソフトウェア開発はチームによる取り組み。謙虚、尊敬、信頼。
2.1 自分のコードを隠すのを手伝ってはくれないか
メンバーが抱えるそれぞれの不安から発生する、ソフトウェア開発のさらに大きな問題の兆候、これから語られる。キーワードは、不安 (insecurity) 。
2.2 天才神話
天才神話は、人間としての我々が、チームの成功を単独の人物／リーダーに帰せずにはいられないという性向なのである。
人間には、リーダーやロールモデルを探して偶像化し、真似ようとする自然の本能がある。
この天才神話は、抱える不安が顕現した一形態としてよくあるものにすぎないことがわかっている。
実際のところ、それは違う。この場合は、読者が間違っており、仕事の隠蔽こそが大問題にほかならないと我々は断言する。以下がその理由だ。
天才に憧れる。それは不安の一形態、裏返し。そしてその不安は、仕事が出来上がるまで、自分が天才だと満足できるまで、途中の仕事を隠すことにつながる。そしてこの仕事の隠蔽が大問題。
2.3 隠蔽は有害とみなされる
単独作業に全ての時間を費やすことは、不要な失敗をしたり成長の可能性を逃したりするリスクを増大させているに等しい。
2.3.1 早期発見
正しい対象への作業に取り掛かっていること、作業を正しく行っていること、以前に同じ作業が行われてはいないことを確認しなければならない。過失が初期に起こる可能性は高い。早期に請うフィードバック（feedback）15が多ければ多いほど、こうしたリスクを減らせる16。
2.3.2 バス係数
バス係数【bus factor】（名詞）：プロジェクトを完全に破綻させるのに必要な、バスに轢かれる人の数
値が大きいほど安全
各担当分野に主オーナーならびに副オーナーを置くのに加え、せめてまともなドキュメンテーション （documentation）の存在が保証できれば、プロジェクトの成功を将来にわたり盤石なものとすることや、プロジェクトのバス係数を向上させることができる。
バス係数を上げるための要素にドキュメントがあるのは、今までの自分の取り組みを肯定してくれているようで嬉しい。
バス係数の先には、全般的な進捗ペースの問題がある。独りで仕事をすると長く辛い作業となり、認めがたいほど進捗が遅れる場合が多いことは忘れられがちだ。独りで仕事をする際にどれだけの学びがあるだろうか。どれだけ速く進めるだろうか。GoogleとStack Overlowt は意見や情報の源としては素晴らしい場所だが、実際の人間的経験の代わりにはなりえない。他者と直接仕事をすることにより、その取り組みの背後で集団的英知が増す。何か馬鹿らしいことで行き詰まると、自分で招いた苦境から脱するのにどれだけの時間が無駄になるのか。自分がどうしくじったか、またその問題をどう乗り越えるかを、肩越しに見て教えてくれる、それも即座に教えてくれるような同僚が数人いたら、その行き詰まりの経験がどれだけ異なったものになるか考えてみてほしい。これがまさに、ソフトウェアエンジニアリング企業においてチームが一緒に着席する（あるいはペアプログラミングをやる）理由だ。プログラミングはきつい。ソフトウェアエンジニアリングはもっときつい。他者の目が必要なのだ。
心に響いた。
2.3.3 進捗ペース
こうして我々は、コードの質を高く保ちソフトウェアが少しずつ正しい形で進歩していくことを担保する。技術的生産性に関する現在の DevOpsの哲学は、この種のゴールに関して明示的に述べている。すなわち、なるべく早期にフィードバックを得よ、なるべく早期にテストせよ、なるべく早期にセキュリティと本番環境について考慮せよ、というものだ。開発者ワークフローにおける「左への移動」の考え方にはこうしたことが全て包含されている。問題を発見するのが早期となればなるほど、問題修正のコストは低下する。
これってシフトレフトのことだっけか？→あってた。
たくさんの目があれば、どんなバグも浮かび上がる」との名言は大多数のエンジニアの知るところだが、より優れたバージョンは「たくさんの目があれば、プロジェクトは意味があり順調な状態に保たれる」というものかもしれない。
チームで仕事をすることでフィードバックループが得られ、順調な状態に保たれる。
2.3.4 要するに、隠れるな
チームならば、1人で仕事をするのは本質的にリスクが高い。ポイントは、誤った対象に向けた無駄な作業による時間を浪費。
2.4 チームが全て
2.4.1 社会交流の三本柱
むしろこの三本柱こそが、全ての健全な相互作用と共同作業とが拠って立つ基盤なのだ。
第一の柱：謙虚 自分は（自分のコードも！宇宙の中心的存在ではない。自分は全知全能でも、常に誤りのない存在でもない。自己研鑽に対して開かれた存在が自分である。
第二の柱：尊敬 ともに仕事をする他者を心から思いやる。他者を親切に遇し、他者の能力と成果の価値を認 める。
第三の柱：信頼 他者が有能で正義を為すであろうと言じ、適切な場合には他者に舵取りを任せることに異存がない。
けんきょ、そんけい、しんらい。何だっけってなることがよくあるんだよなぁ。
2.4.2 何故三本柱に意味があるのか
ここでの教訓は、人付き合いのゲーム (social game) をプレイすることの威力を過小評価するなということだ。人を騙したり操ったりする話をしているのではない。物事をやり遂げるために人間関係を構築するという話だ。
「達成のための人間関係を作る」という言い方は覚えておきたい。
2.4.3 謙虚、尊敬、信頼の実践
2.4.3.1 エゴを捨てろ
もっと良い方法は、代わりに「集団的」エゴを目指すことを検討してみるというものだ。自分が個人としてすごいかどうかについて心配するよりむしろ、チームの成果やグループの誇りといった感覚の醸成に努めてほしい。
自分自身の自慢は、批判などの種になりそうな一方自分たちのチームを自慢するのは賞賛される傾向にあるように確かに感じる。そっちを目指すのが良いと言うのも納得。
2.4.3.2 批判のやり方を学べ、批判の受け方「も」学べ
読み始める前から『フィードバック大全』が思い浮かんだ。同じことを別の言葉で言っていることだろう。
読み進めていくと、謙虚尊敬信頼、のワードがあり、これらを軸に論が展開されている。
そして最も重要なのは、建設的批判は（相手への）尊敬に満ちているということだ。すなわち、建設的批判を行う者は他者を心から気遣っており、他者自身もしくは他者の仕事の改善を望んでいる。
このことは、単に自分のスキルについて謙虚であることのみならず、相手が自分のために（そして自分のプロジェクトのために！）善かれと心底思ってくれており、自分のことを馬鹿だと本当に思っているわけではないと、相手を信頼することを意味する。
謙虚さを駆使し、どうやって質問を相手に関してではなく自分に関するものとしているか、その点に注目してほしい。相手が間違っているのではない。自分がコードを理解するのに苦労しているだけなのだ。
2.4.3.3 高速に失敗し、反復せよ
Googleには、社員たちお気に入りのモットーとして「失敗は選択肢の1つである」というものがある。ときどき失敗するようなことがなかったとすれば、十分に革新的ではないか、十分にリスクを取っていないかのどちらかであるということが、広く認められているのだ。失敗は、次回の試みに向けての学習と改善のための、値千金の機会とみなされている。
これを自分の最上位にずっと掲げるかどうかは慎重に柔軟にすると良いと思うが、ずっと失敗しないなら何かおかしいと疑った方がいい、というのは重要だと思う。
2.4.4 非難なきポストモーテム文化
適切なポストモーテムというものは、以下を含むはずだ。
- 分析対象イベント（event：事象）の簡潔な要約
- 発見から調査を経て解決に至るまでの分析対象イベントのタイムライン
- 分析対象イベントの主要原因
- 影響（impact）と損害の評価
- 問題を直ちに修正するための一連のアクションアイテム（action item：要処理事項）（とそのオーナー）
- 分析対象イベントが再度発生するのを防ぐための一連のアクションアイテム
- 学んだ教訓
まず失敗したことを書き記すドキュメントを、「ポストモーテム（postmortem : 事後分析）」と呼ぶのをのを知らなかった事はないと思うけども、改めて知った。
後は、批判とか責任追及ではないと言う事はよくわかっているか、具体的にどういったものを含むかのリストがあったので、これは役に立ちそう。ただ全部は必要かと言われれば、全部あればベストだろうけど、多少欠けていても、充分な事は多いはずとも思う。
2.4.4.1 忍耐を学べ
2.4.4.2 影響に対して寛容であれ
我々の経験では、人々は頑固者の意見や異議に耳を傾けることをやめて、代わりに、誰もがろくに気にも留めない障害物のように頑固者を「迂回する」ようになる。もちろん読者は迂回される者にはなりたくないだろうから、以下の考え方を脳裏に刻んでおいてほしい。すなわち、他の誰かのせいで自分の考えが変わっても問題ないということだ。
実際、脆弱性を表に出すのをいとわないことは、謙虚さを外向きに示すもので、結果の責任を取れることと、責任を担うのをいとわないこととを体現している。また、それは他者の意見を信頼していることを示す合図でもある。そうすることと引き換えに、自分の正直さと力量を人々が尊敬してくれるようになる。
2.4.5 Google的であること
この評価基準は、強力なリーダーシップを表象し、「謙虚、尊敬、信頼」を体現するものとして我々が求める、属性と品行のセットである。
曖昧の中にあっても成功する 環境が絶えず変動している最中であっても、互いに競合する複数のメッセージや複数の方針に対処でき、合意を形成でき、問題に対して進捗を遂げることができる。
フィードバックを尊重する フィードバックを率直に受け、かつ与えるという両方を行える謙虚さを持ち、フィードバックが個人の（ならびにチームの）成長にとってどれだけ有益か理解している。
現状に立ち向かう 他者からの抵抗や惰性があろうとも、野心的なゴールを設定し追求することができる。
ユーザーを第一に置く Google製品のユーザーへの共感と尊敬とを持ち、ユーザーの利益を第一に考えた行動を追求する。
チームを思いやる 同僚に共感と尊敬とを抱き、頼まれなくても積極的に手伝うように動くことで、チームの団結を強める。
正義を為す 行うこと全てについて強い倫理的感覚を持つ。チームと製品の誠実さ（integrity）+43を守るためなら、困難で不都合な決断を行うこともいとわない。