はじめに
数年前、5人のチームでテックリードを任された。自分が得意だったのは設計とクエリチューニングで、そこは想定どおり回った。詰まったのは別の場所だった。
あるPRで、2人のメンバーが設計方針をめぐって平行線になった。リポジトリのレイヤ分割をどう切るか、という話だ。技術的にはどちらの案でも動く。テストも書ける。それでも2週間、PRは放置されたままだった。決まらない理由は技術の側にはなかった。片方が折れると負けになる空気があって、自分はその空気に手を出せずにいた。
似たことは他でも起きた。スプリントレビューで誰も異論を出さないのに、振り返りになると不満が一気に出る。見積りが常に楽観的で、しかも誰もそれを口に出さない。CIを整えてもデプロイ頻度が上がらない。自分はずっとツールとプロセスの問題として扱っていたが、ボトルネックはチームの中で交わされる会話の質だった。
そこで読み始めたのが今回の4冊である。純粋な技術書ではない。ただ、アジャイルな開発の前提になっている「短いサイクルで学ぶ」「率直に指摘する」「決められない論点を決める」という行為を、どうやって実際のチームで成立させるかを扱っている。スクラムガイドやDevOpsの本には書かれていない部分を、この4冊が埋めてくれた。
順番は意図的に組んである。開発プロセス全体の考え方から入り、日々のレビューとフィードバックに降り、対立の場面を深掘りし、最後にチームの土台に戻る。
① リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす — エリック・リース
著者のエリック・リースはシリコンバレーで複数のプロダクトを立ち上げた起業家だ。自身が関わったIMVUでの大きな失敗を分解して、この手法を組み立てている。
中心にあるのは「構築・計測・学習」のループを最短で回すという発想だ。つくったものが売れるかどうかを議論で決めない。最小の実装で市場に出し、数字で確かめる。言葉にすると当たり前だが、実際の開発現場ではこれがほとんど守られていない。
自分に効いたのは「虚栄の指標」の話だった。累計ユーザー数やPV総数は右肩上がりのグラフになる。ダッシュボードは健康そうに見える。ところがコホート別の継続率を出すと、機能追加が何も効いていないことがはっきりする。この本を読んだあと、チームのダッシュボードから累計値の指標を外した。
もう一つは、ピボットを失敗ではなく判断として扱う姿勢だ。エンジニアは自分が書いたコードに愛着が湧く。3ヶ月かけた機能を捨てる決断は感情的にきつい。捨てる基準を事前に数字で置いておくと、そのきつさが少し軽くなる。
注意点もある。事例はほぼ2010年前後のスタートアップで、SaaSの運用やA/Bテスト基盤が整った今読むと、手法の説明はやや素朴に感じる。フレームワークの出典として読むのが良い。
こんな人に: 機能を出しても手応えがなく、次に何をつくるかの決め方に迷っているエンジニア
② GREAT BOSS（グレートボス）: シリコンバレー式ずけずけ言う力 — キム・スコット
キム・スコットはGoogleとAppleでマネージャーを務め、Appleでは管理職向けの講座を担当していた。今は経営層のコーチとして活動している。
この本の骨格は2軸のマトリクスだ。相手を個人として気にかけているか、そして率直に言えているか。両方あるのが徹底した率直さで、気にかけているのに言えない状態を「破滅的な同情」と名づけている。自分のコードレビューはまさにこれだった。命名が曖昧でも、責務が混ざっていても、指摘を柔らかく包みすぎて相手に届いていなかった。
指摘の運用面も具体的だ。褒めるときは公開の場で詳細に、直してほしいときは短く早く個別に。溜め込んで四半期評価でまとめて出すのが最悪という指摘は刺さった。
実践してみて気づいたのは、順序が逆にできないことだ。信頼のない状態で率直さだけ持ち込むと、単なる攻撃になる。1on1で相手のキャリアの希望を聞く時間を先に積んでおかないと、このフレームワークは機能しない。
こんな人に: レビューコメントが遠慮がちになり、同じ指摘を何度も繰り返しているレビュアー
③ クルーシャル・カンバセーション 重要な対話のための説得術 — ケリー・パターソン、ジョセフ・グレニー、ロン・マクミラン、アル・スウィツラー
著者陣は組織行動の研究と企業研修を長年手がけてきたチームだ。数万人規模の観察データをもとに、高成果の人が難しい会話で何をしているかを抽出している。
扱うのは、意見が対立して感情が動き、しかも結果が重要な場面だ。冒頭のPR放置の話がまさにこれに当たる。本書はこういう局面で人が沈黙か攻撃のどちらかに逃げると整理し、そこから抜ける手順を示す。
一番使えたのは「事実と解釈を分ける」練習だった。「あの人はレビューを雑にしている」は解釈である。事実は「直近5件のPRでapproveまで平均4分だった」だ。事実から会話を始めると、相手が身構える度合いが目に見えて下がる。
もう一つが、安全が崩れた瞬間を検知したら、議題ではなく安全の回復を先にやるという原則だ。相手が黙り込んだら、そこで自分の意図を言い直す。設計レビューの場でこれを意識するようになってから、結論の出る会議の割合が明らかに増えた。
訳文は硬めで、例題も家庭や営業の場面が多い。開発の文脈に翻訳しながら読む手間はかかる。
こんな人に: 技術的な意見対立が人の対立に変わってしまい、決着させられずにいるリード
④ リーダーは最後に食べなさい! 最強チームをつくる絶対法則 — サイモン・シネック
サイモン・シネックは組織文化を主題に講演と執筆を続けている著者で、目的から語るリーダーシップ論で広く知られている。
本書のテーマは、人が安心して働ける輪をどう描くかだ。危険が外側にあると感じられるチームは協力する。危険が内側にある、つまり同僚や評価そのものが脅威になると、人は自分を守る行動に切り替わる。
読みながら、自分のチームの障害対応を思い出した。ポストモーテムで原因の所在を探る質問をしていた時期は、誰も深い部分を話さなかった。ログの共有が遅れ、再発防止も表層的なものに留まった。守る対象が仕組みではなく自分の立場になっていた。
インシデント対応、見積り、技術的負債の申告。どれも正直さがないと機能しない。心理的安全性という言葉をスローガンでなく運用として考えたいときに、この本の視点は役に立つ。
一方で全体は情緒的で、脳内化学物質を持ち出す説明は科学的な裏づけとしては弱い。理屈の厳密さを求める読者はそこで引っかかるはずだ。方向を決める読み物として付き合うのがちょうどいい。
こんな人に: 障害報告や見積りで本音が出てこない状態を変えたいマネージャー
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 開発サイクルを見直す | リーン・スタートアップ | 学習を最短で回す指標設計 |
| 日々のレビューを変える | GREAT BOSS | 率直に届くフィードバックの型 |
| 対立を決着させる | クルーシャル・カンバセーション | 事実ベースで話を進める手順 |
| チームの土台を作る | リーダーは最後に食べなさい! | 正直さが生まれる環境の考え方 |
今の課題に合わせて1冊選ぶなら、こう考えたい。
- 機能を出しても効果が見えない、指標が信じられない → リーン・スタートアップ
- レビューコメントが遠回しで、同じ指摘を繰り返している → GREAT BOSS
- 設計方針の対立が固まり、PRが止まっている → クルーシャル・カンバセーション
- ポストモーテムや見積りで本音が出てこない → リーダーは最後に食べなさい!
4冊まとめて読む必要はない。自分は1冊ずつ、目の前で詰まっていることに当てながら読み進めた。効いたかどうかはデプロイ頻度やレビューのリードタイムに表れる。測れる形で試すのが一番早い。