- 新しいチームに加わった直後に見えるおかしな点をすぐ指摘せず、WTFノートブックにためておくと、不平を言う人ではなくチームを助ける人として信頼を築くための文脈を得られる
- 記録する対象は、振り返りがアクションなしで終わる状況、ローカルでテストできないこと、赤いビルドボード、特定業務の一人依存のような、チーム運営と技術の流れで引っかかるシグナル
- リストは時間がたつにつれて、妥当な理由があるもの、すでに修正が進行中のもの、チームにとって優先度が低いもの、簡単に直せる項目へと選別されていく
- 数週間後にも残る問題は、チームメンバー・チームリード・マネージャーと話して原因や経緯を確認し、長く不便だったが比較的単純な問題から一緒に解決する
- すぐに問題を噴出させるのではなく、文脈と優先順位をためておけば、新しいチームメンバーでも信頼を失わずに問題解決者としての評判を作れる
WTFノートブックの使い方
- チームで得たい評判は、「自分の問題解決を手伝ってくれる人」「自分が重要だと思う仕事を終わらせてくれる人」である
- 新しいチームに加わるたびに、バレットジャーナルの新しいページに
WTF - [Team Name] と書き、おかしいと感じることに出会うたびに記録する
- 変えたいことが出てきたら、別の作業としても残す
- 最初の2週間は記録だけに集中する
- チームが間違っていると思うことをすべてすぐに口にしない
- 振り返りで変えるべきリストを一気に吐き出さない
- 見て、聞いて、深くおかしいと感じることを書き留める
- この方法は、チームに変化を起こしながら自分自身を管理し、不平ばかり言う人に見えないようにしてくれる技法である
新しいチームで見つける異常のシグナル
- 新しいチームには必ず「WTF」と感じることがある
- 代表的な例は次のとおり
- チームが振り返りで深刻な問題について1時間話すが、アクションアイテムなしで終わる
- テストがローカルで実行できないのに、誰も気にしていないように見える
- ビルドボードの大部分が常に赤い状態である
- 重要で時間的制約のある仕事を1人だけが処理できる
- チームがある機能に多くの時間を使っているが、それがなぜ重要なのか、顧客にどう役立つのかを誰もよく分かっていない
リストから消えていく項目
- 十分に大きなリストができたら、項目を1つずつ消し始める
- 消える理由はたいてい4つある
- 実際に良い理由がある
- チームがすでに修正作業をしている
- チームがその問題を重要だと考えていない
- 本当に簡単に直せる
- ローカルテストが実行できない問題も、文脈によっては大きな問題ではない場合がある
- すでに知られている課題で、解決への取り組みが進行中かもしれない
- チームがすべての作業を仮想マシン上で行っており、チャットコマンドでそのマシンを簡単にプロビジョニングできるかもしれない
- 継続的インテグレーションシステムが整っていて、小さな変更を頻繁にデプロイする習慣があり、ローカルでテストできないことが1日に何度も行うデプロイを妨げていないかもしれない
- 項目によっては単純な解決策が見える
- 場所さえ分かればドキュメントを書ける
- 正しいスクリプトを見つければ簡単な変更かもしれない
- 簡単な解決策が見えたらすぐに直す
残った問題をチームと一緒に扱う
- 数週間たってもおかしく、解決されていない問題が残っていれば、チームメンバー、チームリード、マネージャーと対話を始める
- 質問の焦点は、それらの項目がなぜその状態なのか、どうしてそうなったのかである
- 目標は、心から興味を持ち共感する人、忍耐強く同僚の専門性を尊重する人として信頼を築くこと
- 問題が残っている理由は、おおむねいくつかに分かれる
- チームが気づいていない
- チームが慣れてしまっている
- 問題が比較的新しく、その前の問題ははるかに悪かった
- 直し方が分からない
- 以前に直そうとして失敗した
- 最初のいくつかのタイプは、質問するだけですぐに直ることもある
- 相手がすぐに直す、または一緒に解決方法を探す
- 技術的な問題なら、ストーリーやチケットを一緒に書いて作業する
- プロセスや社会的な問題なら、振り返りでチーム全体と話す
- この時点では、新しい同僚の1人をしばらく悩ませていて、比較的単純な解決策がある問題を1つか2つ見つけるのがよい
- 振り返りボードに載せたとき、自分だけが不便に感じている問題ではないものを選ぶ
- チームでの会話中にそのチームメンバーが提案したことを、すぐ試せるアクションアイテムとして設定する
- チームは、新しいメンバーが自分たちの問題解決を助けてくれていると感じ始める
より難しい問題とマネージャーとの対話
- 時間がたつと、チームが知ってはいるが扱うのを恐れている粘着質な問題に入っていく
- こうした問題は「そこまで悪くはない」と見なされているが、誰も話したがらないものかもしれない
- 必要な技術力が不足している可能性がある
- 複雑な人間関係の問題が中心にある可能性がある
- この段階では、これまで作ったリストをマネージャーのところへ持っていき、話し合う
- 数週間見てきたこと
- 一部は進展しているが、一部はもっと時間がかかりそうに見えること
- 何か見落としていることがあるか
- どの領域に集中してほしいか
- マネージャーも同じ問題を懸念していたが、チームが大きく困っているようには見えず、強く押し進められなかったのかもしれない
- その後、マネージャーの懸念と問題を一緒に整理し、過去にうまく機能した事例やそうでなかった事例について話せる
- マネージャーは、その人を優れた判断力を持ち、より難しい問題の解決を助けられる人だと見始める
すぐ指摘しない理由
- 欲しい評判は「Natは私の問題解決を手伝ってくれる」「Natは私が重要だと思う仕事を終わらせてくれる」というもの
- こうした評判は翌年の業績レビューで望む結果を得ることにつながり、数年後には推薦にもつながり得る
- 以前は、問題を見つけるとすぐに口にしていた
- その結果、「いつも不平を言っている」「私たちが絶対に正しくやらないと思っている」という評判を得た
- 人々は聞かなくなり、個人的にも挫折し、職業的にも非効率だった
- 新しいチームメンバーが、実際には問題ではないこと、チームが問題と見ていないこと、すでに解決中のこと、あるいは最初は見えていなかった簡単な解決方法があることについて大騒ぎすると、信頼は急速に崩れる
- チームには改善できる問題が常にたくさんあるが、実際に解決可能なものは一部だけである
- 問題を見つけた順番が、最も効果的な解決順であることはまれである
- WTFノートブックは、「今すぐ直したい」という衝動を一時的に保管し、何から扱うべきかを決める文脈ができるまで待たせてくれる
1件のコメント
Hacker Newsのコメント
この記事は、ひとつの点を十分に強調していないように思う。新しい人の視点は一度きりだということだ。
プロダクトの使いやすさをうまく判断できないのは、すでに使い方を知っていて、ミスや欠陥に鈍感になっているからだ。
新しいチームメンバーはまだそうなっていないので、何を尋ね、どこで詰まり、どこに本当に助けが必要なのかを見れば、チームは多くの洞察を得られる。
ノートを持って座ってメモを取り、ユーザーがプロダクトを使っている間に会話する。
どれだけ大量のテラバイト級のテレメトリデータを集めても、実際のユーザーと話すほどには、プロダクトがどう使われているかを理解することはできない。
テック業界は、他の人間を怖がる態度をもう少し克服すべきだ。
熟練した教授が、初学者には説明が必要な内容が難しいのだという事実を忘れてしまうのに似ている。
ただし、全員が同じように下手なわけではなく、入門者の立場に立てるだけの共感力と関心があるかが大きく影響する。
Bashシェルを数えきれないほど使ってきた2人でも、初心者にとって何が奇妙で直感的でないかについての理解はまったく異なり得る。
新鮮な目で見ることもスキルであり、実際の光や物体を見て描く方法を学ぶのと同じように、訓練で上達できる。
すぐに口に出さずに書き留めておけば、なぜ物事がそうなっているのかを学ぶ時間と、組織の地形を把握する時間が得られる。
アカウント、権限、承認といったものが整理されてから、そのリストをもとに動ける。
そうすればチームも、「次々と飛び出してきてWTFと叫ぶ人」ではなく、助けようとしている人として受け止める可能性が高くなる。
12〜15人規模では非常にうまく機能したが、より大きな規模でもうまくスケールするかは分からない。
書き留めて待つことは即時的で負担が低く、「リストが長くなった」という小さな報酬もあるので、体系的に練習すれば簡単に学び直せる。
認識して記録する段階と、後で地図を作り、見て学び、同じ問題意識を持つ人たちを集めて導く段階を、ずっと分けている点が良い。
業務ジャーナルを書くのは常に良い考えだが、この記事のトーンにはどこか引っかかるものがある。
Borgのように振る舞ったり、『How to Win Friends and Influence People』から持ってきたような台本に従う人とは一緒に働きたくない。
誰かが自分を操ろうとしているように見えたら、少なくともそれに気づいた瞬間からは信頼しにくい。
それでも、その即座の拒否感だけに引きずられない方がよい。
私もステークホルダーに自分をどう感じてほしいかという目標を持っていて、行動基準としてかなり有用だった。
技術的に良い仕事をしていても、人間関係の次元を無視すると問題が起きたし、どんな噂が流れているか、自分がどう認識されているか、自分の仕事がどう包装されているかは実際に重要だった。
「ただ良い仕事をすればよい」だけでは、自分の仕事と自分自身が他人にどんな印象を与えるかが重要だという事実は消えない。
『How to Win Friends and Influence People』は読んだことがないが、文章自体はかなりよく書けていると感じた。
経験豊富な個人貢献者であれ、新任マネージャーであれ、士官であれ同じように、最初の30〜90日は何も変えず、物事がどのように、さらに重要なのはなぜそのように回っているのかを理解しようとすべきだ。
組織的に得られる利点は多く、短く言えば、これが実際にそうするやり方なのだ。
エンジニアは悪いマネージャーの下で働いたことがあり、なぜ悪いのかを正確には説明できなくても、感覚では分かっていることが多い。
その「悪いマネージャー」感は、しばしば戦術的に良いリーダーシップを取れないことから生じており、工学と同じようにリーダーシップも学べるスキルだ。
問題は、軍隊や上級幹部向け教育のように、それを意図的に教える場が多くないことだ。
良いマネージャーの下で働きたいなら、実際には良いリーダーの下で働きたいということであり、リーダーシップは効率的なC++コードを書くのと同じく戦術的なスキルだ。
チームメンバーがそれぞれ単独で達成できる合計を超える目標に向けて人々を調整し導くことなので、ある角度からは操作のように感じられるかもしれない。
それでも、チームを外部の愚かなことから守り、必要なリソースを確保し、公の場で称賛し私的に批判し、過度にマイクロマネジメントせずに方向性を示し、成果を認めて報い、基準未満を放置しない人が、たいていエンジニアに好まれるリーダーだ。
逆に、技術を知らないMBA出身のカリスマ的な政治プレイヤーが、こうした手法を悪い理由で使えば、一緒に働きたくない人になる。
技術職から管理職に上がったものの、管理が技術力とは別物だと受け入れられない人も、よく嫌われる。
結局、業界全体で有能なリーダーを増やすには、こうした記事のように、リーダーシップを曖昧な生まれつきの勘ではなく、やり方を説明できる戦術として扱う必要がある。
「Nat は自分の問題を解決してくれる」という評判を得るのは推薦には有利だが、キャリアには危険になり得る
複数の部署で20年間そうしてきたが、毎回、問題解決役として引き留めようとはされたものの、昇進候補に挙げられることはなかった
40年働いて退職した同僚も、どんな問題でも解決してくれる人で、管理職たちよりずっと有能だったが昇進できなかった
みんなにとっての切り札だったが、ほとんど評価されず、問題を解決することが「当然」と見なされ、報酬もなかった
同じ職位の他の人たちにははるかに低い基準が適用され、最後の業績評価でも上司は「同僚ではなく、目標に対する成果で評価する」と言った
私も別の上司から同じことを言われたので、偶然ではなかった
何よりも、私の上司は、自分経由ではない依頼を遮ってくれるとき、いつも私の味方だった
知らない人から些細ではない仕事を頼まれ、時間がない、あるいは関心がなければ、「今は見る時間がありません。優先順位付けが必要なら私のマネージャーと話してください」と言えばよく、100回中99回はマネージャーのところまで行かなかった
部署や会社全体で頼られる人になる最大の利点は、知り合いとネットワークが積み上がることだ
チームの外から情報が必要なときや、重要な仕事のために官僚的な手続きを突破しなければならないとき、小さな超能力のように機能する
新しい機会を探すときに連絡できるネットワークもでき、民間分野で15年働く間に得た仕事はすべてこのやり方でつながった
ただ、2つのアプローチのうち一方は昇進プロセスをうまく通過し、もう一方はそうではない、と言える
簡単ではないが、境界線を引くことは重要なスキルだ
「問題を見た瞬間にすぐ持ち出したせいで、Nat はいつも不満ばかりで、こちらが何をしても間違っていると思っている、という評判ができた」という部分は、記事のかなり冒頭に置くべきだ
このレベルの自己認識は、身につける価値のある本物のスキルだ
元宇宙飛行士の Chris Hadfield も著書で、新しい任務やチームに加わるときに似たようなやり方をしたと述べている
まず観察モードに入り、WTF な瞬間が本当に妥当なのかを学び、新しいチームメンバーをいら立たせないやり方だ
読む価値がある
長く同じ場所で働いてみると、ノイズを流し込む場所を作り、少なくとも頭の中にそのまま残らないようにしてくれる
単に問題が妥当かどうかを判断するだけでなく、ある種のことは手放す方法を学ぶことにも近い
どの本か教えてもらえるとありがたい
すでに存在している状況に入るときは、だいたいこういう形で取り組んできた
最初の1週間はすべてを見直しながら、質問と観察を書き留める
「WTF」な瞬間だけでなく、うまく機能していることや、本当に良いアイデアだと感じたことも記録する
その後ではじめて見直し、優先順位を付けてから議論に入る
これはチェスタトンの柵とうまく合う原則のように見える
ある柵を取り払いたがっている人に対して、「その用途が分からないなら、取り払わせるわけにはいかない。行って考え、その用途を理解したと言えるようになってからなら、なくしてもよい」と言う話だ
もっと明確に言えば、何かがぎこちなく見えても、先にいた人たちは賢く、そこには理由があったのだと仮定したほうがよい、という意味だ
その理由は今では古くなっているかもしれないが、考慮しなければ同じ失敗を繰り返すことになる
直したいことの一覧を維持するだけでなく、時間を置いておくと何がなぜそうなっているのか理解できるので、良いアイデアだ
急いで作った、あるいはミスがあった場合も多いだろうが、ときにはコード1行を見ただけではすぐ理解しにくい隠れた複雑さが実際に存在する
前者は明らかな失敗で、後者はその環境に十分浸かっていくとたいてい解ける
それでも両方を書き留めておくのは有用だ
ちょうど今週、同僚2人に、自分のコンピューターに「How the F」というファイルを置いていると話していたところだった
筆者が言っていることとまったく同じではないが非常に似ていて、新しいチームに入ったとき、問題が起きるたびに「これはまたどうやるんだっけ？」と思うものをすべて書き留めている
原文のようにマネージャーに持っていくわけではないが、チームや会社の障害物が何なのかを把握し、時間をかけて解決していく視点を与えてくれる
思いついたアイデアはすべてリストに書き留めるやり方で生きている
特別な順序はなく、紙やテキストファイルにひたすら追記する
アイデアは必要なときにはなかなか出てこず、別のことをしている一日中ずっとやって来るが、書き留めておかないと、少なくとも私は覚えていられない
いざ何かをしなければならないときは、1つずつ消していけばよいので次に何をするか悩む必要がなく、アイデアが尽きないため、かなり大きな生産性の爆発が可能になる
個人の ToDo リストを整理する話のように聞こえるが、原文はチーム内で適応し、コミュニケーションする方法についての記事だ
人生はメモを整理するには短すぎるので、とにかく全部書き留めて、逆順ソートと検索に頼るほうがよいと思っている
皮肉なことに、驚くようなアイデアの宝庫があることは分かっているが、この年になると20代のころのように実行するほど気にかけなくなった