All Articles

manage and playing playing

TL で流れてきたmanagers playing bookを読んで今後ヒントになりそうな部分を噛み砕いて行動に移していこうと思う。最近は、思ったより自分の開発時間がとれないのでscrum master としてチームの出力をあげつつ、自分の出力もあげるためにはどうしたらいいか考えながら読んでいく。自分で手を動かして形にするのは楽しいのでなるべくコードは書きたい。コードを書くまでのプロセスを高速化したい。

以下、Kamil Sindi氏のmanagers playing book の日本語訳。ほんの一部削ったり、参考から詳細を付け加えたりしています。

Principles

  • チームとプロダクトがどうなっているか、いくか、常に気にかけておく
  • アーキテクチャを熟知し、技術スタックを常に最新に保つ
  • 毎週、直属の部下と1on1を行う
  • 顧客を重視する。製品が実際にどのように使用されるか理解する。販売やサポートの電話に参加してみる
  • 積極的だが、達成可能な目標を設定する。達成したい結果に焦点を当てて、逆算して仕事をする
  • アドバイスやフィードバックをする際には、オープンな質問をすることでオーナーシップを促進させる
  • 計画やコンセンサスよりも行動や意思決定に偏りがあること
  • チームのコーチやチアリーダーになりましょう。成功を頻繁に祝い、ポジティブな行動を強化する

  • 可逆的決定と不可逆的決定を区別する方法を知っています

    • 可逆的な決断とは、入念な調査などが不要でもとに戻せる決断のこと。反対に不可逆な決断とは、もとに戻せないため、入念な調査に基づく情報が必要になる決断のこと。世の中の多くは、可逆な決断なので、行動に移してデータを得たほうが競争に勝ちやすい。ドアに例えると、可逆な決断は両開きなので、ドアを開けた結果が気に入らなければ、得た結果を持ち帰ってくればいい。不可逆な決断はドアを開けた結果に向き合い続けないといけない。しかし、また別のドアを開けることで別の問題にフォーカスすることが可能。かといって、可逆な決定にも調査はもちろん必要で、amazon では必要な情報の70%が揃ったらGoという風にしている。そして、コース修正を行っていく。これは90%の情報を待ってからGoを出すより効果的なようだ。
  • すべての報告書がチーム、組織、会社の最優先事項を認識していることを確認する
  • 模範となり、自分が実践していることだけを説く
  • マネージャーの下にはタスクはない。コーディングでなくても手を汚す。

Non-Coding Contributions

  • ドキュメントを書く
  • 1週, 1ヶ月, 1年など期間に応じた優先度を考える
  • 新しい情報について勉強し、シェアをする
  • issue を整理する
  • チームメイトのスキルを向上させる
  • 顧客を助ける
  • ワークフローの自動化
  • 1on1でのフィードバック

One on ones

  • 決して1対1を飛ばしてはいけません。それは、フィードバックを受け取り、与えるための最高のプラットフォームです。ほとんどのチームメイトはそれを大切にしているし、そうでない場合は、よく行われたものを見ていないからだ。
  • 毎週1on1を行うのを狙う

  • 5つの topic に集中する

    • 予測可能性：ルーチンを作成し、期待を設定し、変化を正常化する
    • 所有権：オプションを提供し、所有権を明確にし、より多くの責任を与える
    • 目的：全体像の価値と課題の重要性を明確にする
    • 進捗：マイルストーンを作成し、勝利を共有し、進捗を祝う
    • 所属：チーム文化とマネジメント(文化を維持、進化させていくようにするってことだろうか)

  • 各トピックのフレーム化に役立つ質問 "1-10段階であなたはどう評価しますか..."

    • 予測可能性：あなたに期待されていることをどのくらい明確に感じていますか？
    • 所有権：意思決定力や方向性への満足度？
    • 目的：あなたの仕事がチームにどれだけの違いをもたらしているか？
    • 進行状況：毎週の進行感はどうか
    • 所属：チームとのつながりを感じていますか？

  • それほど頻繁ではない追加の質問

    • モチベーション
    • あなたの仕事の中で一番楽しいことは？
    • あなたの仕事の中で楽しくないことは？
    • 毎週あなたにとって最大の時間の浪費はなんでしょう？
    • 長期目標
    • どんなスキルを磨きたいですか？
    • どんなキャリアパスを探していますか？
    • 社内の誰からもっと学びたいと思いますか？
    • ビジネスのどの部分にもっと関わりたいですか？
    • 組織の意識
    • この製品の何が嫌いですか？
    • 我々が見逃している最大の機会は何ですか？
    • 今4半期の3つの優先事項は何ですか？
    • あなたがCEOだった場合、何か違うことをしますか？
    • マネージャの役割
    • あなたをよりよくサポートするために私は何ができますか？
    • あなたが私だったとして、あなたが変えたい1から3つのことは何ですか？
    • あなたが得ているフィードバックの量についてどう思いますか？
    • フィードバックが欲しい。私ができることは2つありますか？
    • あなたとの連携の仕方を改善するためにできることは？
    • 優先度
    • 今週の最優先事項はなんですか？
    • 成功はどのようになりますか？
    • 障害物はありますか？
    • 新しい人間との最初の1on1
    • 以前のマネージャーのどこがよかったですか？何が嫌だったの？

Coaching

何を、どのように、誰がといったキーワードでオープンな問を投げかけることで、問題の所有権を与える。

  • 質問ありますか？より、あなたはどんな疑問を持っていますか？のほうがよいです
  • これはいい案ですか？より、なぜこれが正しいアプローチなのか？のほうがよいです
  • どうしたらいいですか？と聞かれたら、今までの感想は？と答える。

相手に考えさせて、言語化させる。聞くことが大事。

  • コーチング相手の言葉を要約し、同じ立場になり、問題を特定することを助ける

  • 会話を生産的にする方法を理解する

    • 次のステップは何ですか？
    • これをどのように追跡する必要がありますか？

Feedback

  • 迅速であること、理想的には、それを促したイベントの当日にフィードバックを提供すること

  • フィードバックの提供についての賛同を得て、謎を減らす

    • 今朝のスタンドアップについて話す時間は10分ありますか？
  • 賛辞から始めて否定的なフィードバックを埋めないでください
  • 肯定的なフィードバックであっても、具体的に説明してください

  • 行動ではなくデータに焦点を当てる

    • 最近の3つのPRで行われたコメントのいずれにも対応していないようです
    • あなたが私に頼んだチケットをピックアップしていないことに気づきました
  • これがなぜ重要で、誰に影響を与えるかについて話します
  • 問題を解決する方法を一緒に理解する

  • 行動計画に同意する

    • 次回チケットの期日を見逃さないようにするにはどうすればよいですか？

Thinking strategically

  • あと一人増えたらどうするの？
  • あなたのチームはどのように針を動かしていますか？正しいことに集中していますか？あなたが構築している機能が顧客の利益になることをどうやって知っていますか？
  • あなたの製品の使命と信条は何ですか？
  • 今年の会社の最優先事項は何ですか？ 3年後の会社はどこにあるのでしょうか？
  • チームが推進している会社の年間目標は何ですか？
  • あなたが昇進した場合、あなたのチームの誰があなたの代わりをしますか？この人はどのようなスキルや経験を習得する必要がありますか？
  • あなたのチームの問題点は何ですか？どうすれば2倍速く出力が上がりますか？
  • あなたがとりとめのないことで心配になっていることはありますか？

Making decisions

  • 意思決定が可逆か不可逆か決定すること
  • 誰かが可逆的な決定に同意しない場合は、その決定をチームで再検討する日を設定します。理想的には、その決定の成功を定義するためのメトリクスも用意しておきましょう
  • 誰かが不可逆な決定に同意しない場合、彼らに彼らのケースを提示する機会を与える。いずれにせよ、誰もが決定は最終的にあなた次第であり、チームは反対し、行われた決定に全面的にコミットする必要があることを認識する必要がある。
  • 決定が行われた理由とチームが直面したトレードオフを参照できるように、決定を文書化します。

Coding

  • クリティカルパスでのコーディングは避ける
  • 誰かが休暇を必要とするときにオンコールをカバーしますか？
  • コードレビュー
  • 煩わしいが最優先に思われることのないP2バグを拾う
  • 監視チェックをクリーンアップし、カバレッジを生成するためのライブラリを作成していますか？

Ticket and PR process

  • チームの貢献ガイドラインを設定します
  • PRは1時間以内に適切にレビューされるように十分に小さくする必要がある
  • チケットのブロックを解除するには、PRに優先順位を付ける
  • コードフォーマッターを使って自動化できるレビューは自動化する

Meetings

  • 気難しいブレーンストーミングセッションは避けてください。決定を会議に委ねないでください。その場で意思決定を行い、長文でそれを伝え、会議を使用してそれについて話し合う

  • アマゾンスタイルの「6pager」と「2pager」として書かれる提案を奨​​励する

  • 会議の最後には必ずアクション、オーナー、タイミングを決めて、次のステップが明確になるようにする
  • スタッフミーティングについては、テーブルを回って、彼らの最大の懸念が何であるかをレポートに尋ねます

6 Page and 2 Page Documents Summary

この記事 の要約メモ

文書中によく出てくる disagree and commit はamazon 用語のようでこちらに詳しく書いてある。要は、意思決定を任せられるかってこと。

EC2チームにいる、米コンサルのTwo Sigma 時代に実践していた手法。
組織の課題に対して、情報を集約し、利害関係者がフィードバックから意思決定を任せられるかの決定をグローバルに行えるようにしたい。

使うタイミング 6ページのドキュメントと60分の会議で次の決定に関する会議で成功を収めることができた

  • チームが構築する予定と構築しないものの年間計画
  • 製品戦略のトレードオフ（要件、仕様、所有権など）
  • プロジェクトまたは製品提供計画のトレードオフ（つまり、スコーピング）
  • エンジニアリング実装のトレードオフ
  • 成功するために組織間の優先順位付けの賛同を必要とする大規模プロジェクトの定期的な更新

power point よりも文書化されたドキュメントで話すメリット

  • 議論の前に自分の考えを明確にすることができる
  • 会議中に話すのが苦手な人のために事前に資料を渡すことで発言機会が平準化される
  • 書面は、任意のペースで読むことができるので情報消費率(rate of information consumption)が均等になる。パワポは、発表者に強制的に合わせられることになる
  • 文書化されたものに関する質問は必然的に全体像に対するものになるので建設的。スライドに対しての質問や、あとのスライドで補足や解決するという段取りが必要なくなる
  • 文書には耐久性がある。意思決定のプロセスの記録になる
  • パワーポイントは、すべての利害関係者の間で本当の会話をしているというよりも、プレゼンターが大多数の時間を話しているような状態になりがち。つまり、発表のウエイトが多くなり会話が行われにくい。

ホワイトボードの前で集まって解決できるならそれが望ましいが、利害関係者が多くなったり、決定が論争を生むような場合はドキュメントをしたほうがよい。

哲学とトーン

ドキュメントの最も重要な側面は、様々な利害関係者がdisagree and commitを合意できるようにすること。 これを行うためには、領域の背景・問題の詳細・提案された解決策・様々な利害関係者とのトレードオフを語る必要がある。 これができていれば、誰もが話し合いの場に入って全体像を話し合い、正しい意見に同意することができる。これを達成するには、中立的にこれが世界の状態ですという口調が重要。

  • ドキュメントは著者のミスを隠してはならない。新しい変更にミスがあっても、冷静にその旨を書き記す。
  • 他人のミスを強調して記さない。たとえそれが誤った判断だったとしても。
  • 反対の事実を書く。利害関係者間に解決されていない事実または理想的な戦略の不一致がある場合は、ドキュメントをレビューしてオプションとして明示的に議論する前に、利害関係とともに議論する必要がある。レビューの前に利害関係者に会い、彼らの意見が理解され、構成に表現できることを確認する

ドキュメントの形式と構造

この形式は1時間以内にディスカッションを読んで締めくくることを目的にしています。 そのためには

  • 本文は 6 page 以下
  • 本文は付録を参照せずに聴衆が理解できるものであること
  • 少なくとも1 inch のマージン
  • 少なくとも10 point のフォント
  • 明確にバージョン管理されたドキュメント
  • 番号付きリストはポイントの呼び出しがしやすいので箇条書きよりも有線される
  • 番号付きページ、セクション、グラフ

背景資料に適切な時間を費やすという哲学に基づいて、ドキュメントは一般的に同じ大まかな構造を持つ。つまり

  • 2 page の一般的な背景
  • 2 page の特定の背景
  • 2 page のアクションと計画

エンジニアリング/製品/ビジネスの意思決定文書の場合、詳細な構造の例は次のとおり

  1. 1つの段落、ドキュメントの目的。理想的には、推奨されるソリューションで終了する
  2. 理念/ガイドライン/背景—システム/問題を理解するためのフレームワーク
  3. 問題の詳細
  4. 可能な解決策の詳細。理想的には、少なくとも2つのオプションを提示する文書
  5. 根拠のある明確な推奨ソリューション
  6. 可能な場合：解決策を想定した行動計画

<ここまでがドキュメント>

付録：詳細な表、詳細なグラフ、サポートデータも付ける必要があるだろう

本文を6ページにまとめるために

  1. 言い回しを減らす
  2. 主観的で曖昧な用語、および無意味な形容詞を排除する
  3. 実体を示さない相手をミスリードする言葉を排除する。(weasel wordsという)すべての単語についてどのような情報を伝えているか尋ねる(曖昧な表現リスト参照)
  4. 議論の余地のあるポイントを紹介する長いブルドーザーのリストよりも、議論の余地のないポイントの短いリストを好む。議論の余地のあるポイントは、紙のスペース、読者のヘッドスペース、会議の時間を取る
  5. 余談や詳細な説明は避ける。これは論文の評価ではない。問題のすべての側面に正直に取り組んでいることが示されている場合、利害関係者は詳細を記述してライターを信頼する。
  6. 付録を使用する。それが議論にとって中心的に重要ではないが、議論の中で浮上する可能性がある場合は、付録に移動させる。長い表、詳細なグラフ、例外的なケースに関するFAQ、特定の例の長いリスト。重要なのは、付録に説明文がないこと

上記のすべてを実行しても本文がまだ6ページを超える場合、60分のレビューに必要な情報が多すぎて温泉サスの決定に至らないことを意味する。理想的には個別の決定を引き出し、複数のドキュメントを独自のレビューのラウンドで作成する。それができない場合、要点は、60分のドキュメントのレビューでコンセンサスが得られることを期待すべきではないということです。場合によっては、利害関係者は、著者が文書を書くために入れた作業に合意を先延ばしにしても構わないということもある。重要な作業は文書を読むことではなく、書くこと。そこまで肥大化した文書は、今回取り上げている種類の文書ではなく、判断の種類も異なっている

会議のレビュー

理想的には10人以下の人がディスカッションに参加するよう招待する。そうでない場合、60分で会話が終了しない。ボトムアップ型では、文書作成者やその他の利害関係者が、詳細に話をしたり、決定結果に強く影響を受けたりするべきである。トップダウン型では、文書の決定に最終的な権限を与えることができる人がいなければなりません。

会議の形式は以下の通り

  • プレゼンターはハードコピーを持ち、誰もが入室時にコピーを取る
  • 最初の15分：座って本を読み始めます。誰も話しません
  • 次の20分：プレゼンターはドキュメントを歩き、ページ番号を呼び出してコメントを求めます。
  • 次の20分：決定についての議論。
  • 最後の5分間：結果的に会議を明確に終結させる

ドキュメントを読むのに好意的な場合は、前日に資料を配ってしまう。ただし、意図的に資料をさらっていくことを忘れないようにする。

会議を閉じるには、ドキュメントの作成者は次のステップとして何を見るかを明確にする必要がある。 通常は3つ

  • 文書案は、すべての利害関係者にdisagree and commitとして受け入れられた
  • ドキュメントは閉じていますが、メールで閉じることができるいくつかの詳細があります。
  • 文書は改訂する必要があり、別のレビューが予定されている

曖昧な表現リスト
a number of いくつかの
clearly はっきり
completely 完全に
could たぶん...だろう
exceedingly 極めて
excellent 優秀な
extremely 極めて
extraordinary 並外れた
fairly 尤も
few 少ない
interestingly 妙に
it is said 言われている
large 大きい
less than 未満
many たくさん
more than 余り
most 最も
normally 一般的には
often しばしば
probably おそらく
quite とても
recent 最近
relatively わりと
remarkably 著しく
several いくつかの
significant 有意義
substantial 実質的
surprising 意外
tiny 小さな
up to ~まで
usually 通常
various いくらでも
vast 広大
very とても

Hiring

最高のプログラマーは、単に優れたプログラマーよりもわずかに優れているわけではありません。
彼らは、概念的な創造性、スピード、デザインの工夫、問題解決能力など
どのような基準で測定されても、桁違いに優れているのです。
- ランドール・E・ストロス

採用はマネージャが行う最も重要な決定である

  • 上級エンジニアに求めること

    • 100%自分の責任ではない場合でも、問題の所有権を持つことができ、なぜそうなるのかを理解している
    • Q.あなたが責任の範囲外で何か重要なことをしたときのことを教えてください。なぜそれが重要だったのですか。結果はどうでしたか？
    • 長期的な目標のために短期間の利益を犠牲にするという難しい決断をしたときのことを教えてください
    • あいまいさを処理する
    • 野心的な問題を解決しなければならなかった時期について教えてください。なぜ問題は重要だったのですか？
    • 完全な情報なしで決断しなければならなかった時のことを教えてください。どのような状況でしたか？どのようなリスクを取りましたか？なぜ、あなたはその決定をしたのですか？
    • Team Player. フィードバックを上手にとる
    • Communicator. さまざまなレベルでアイデアを明確にすることができます
    • あなたがよく知っていることを私に説明してください
    • 履歴書でXについて言及しました。出会ったことがないかのように説明してください
    • Deep diver. 内部で何が起こっているのかを理解するために、要素をより深く掘る
    • あなたのチームで問題を理解しようとしていた時に、それを理解するために何層も下に降りていかなければならなかった時のことを教えてください
    • Simplifier.単に物事をハックするのではなく、問題を単純化し、技術的な負債を追加します。build vs. buy のメンタリティを持っているか
    • 複雑な問題を簡単な解決策で解決したことを教えてください
    • Missionary. 会社の使命や技術に興味がある
    • 現在の会社が何をしているのか、なぜそれが重要なのか説明してください。
    • 弊社で働いていることに興味をお持ちですか？それはなぜですか？

  • 注意するべきこと

    • 企業での短期在職。候補者が通常1年未満会社に滞在する場合は、その理由を尋ねます。完全に正当な理由がある場合もあれば、その人を採用するのが難しいパターンを示している場合もあります。
    • 履歴書の内容
    • 解決した問題ではなく、使用した技術を羅列しただけの履歴書は、全体像を考えていないことを示している可能性があります。また、ジュニアエンジニアの典型的な特徴でもあります。
    • 長い履歴書
    • 2ページを超えると、その人は何が重要なのかを明確にするのが難しいことを示しているかもしれません。しかし、文化的な理由で履歴書が長い場合もあります。例えば、ヨーロッパの一部の国では、履歴書は長く書くことが推奨されています。

Onboarding

優れたオンボーディングプロセスを持つことは、チームと新しいチームメンバーの成功に不可欠。これにより、チームメンバーができるだけ早く貢献し、プロセスと文化に同化することが保証される。

新しいチームメンバーが参加の初日にバグ修正を提供できる場合、オンボーディングプロセスは成功である

  • Team mission

    • あなたのチームは顧客にどのような価値を届けようとしていますか？

  • Documentation

    • Code contributing guidelines
    • PR review process
    • Ticketing process
    • 用語集
    • コードのリリース

Announcing change

  • 昇進、reshuffles、restructuring
  • 変化の困難さや機会を認識する

  • なぜかを説明するために物語を使って感情に訴える

    • この変更が会社にとってなぜ重要なのですか？
    • この変更は誰に影響しますか？

  • 事実を利用して論理性をアピールする

    • この変更によりどのような指標が達成されますか

  • 変化を社会化して賛同を得る

    • それが最も影響を与える人々から始めましょう。
  • ex.) Carta’s covid-19 layoff

参考

Published 2 May 2020

Software engineer at Tokyo. smith-30 on Twitter