ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

新刊『エンジニアリングマネージャーのしごと』発売のお知らせ

みなさんこんにちは。@ryuzeeです。

言いたいことはタイトルに書いたとおりなのですが、2022年8月26日に、新刊『エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法』が発売になります。

原著はDr. James Stanier氏の『Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs』です。 James Stanier氏は、マネジメントに関する人気ブログ(The Engineering Manager)を長年執筆しており、現在はShopifyでDirector of Engineeringを務めています。 翻訳はいつもの株式会社アトラクタのアジャイルコーチ3人と、Regional Scrum Gathering Tokyoなどの実行委員を務める竹葉さんにも加わってもらって行いました。

みどころ

何を紹介しようか迷ったのですが、どんな本なのかは訳者まえがきに書いたので、そちらを引用して紹介します(出典『エンジニアリングマネージャーのしごと』vii〜viiiページ、オライリージャパン、2022年)。

今さら言うまでもないことですが、世の中の変化がどんどん速くなり、企業が存続するためには、顧客が満足するプロダクトやサービスをすばやく継続的に提供することが求められるようになりました。

このような環境では、事前に問題や解決策が分かっていることよりも、問題や解決策がわからないことに試行錯誤や探索しながら取り組む割合が増えていきます。 つまり仕事の内容ややり方が変わってきているのです。仕事の内容ややり方が変われば、そこに携わる人をマネジメントする方法も変わります。

答えが分かっているものを効率的に終わらせることが求められた時代では、マネージャーに求められていたのは、いかに従業員を無駄なく効率的に働かせて、短い期間に安いコストでたくさんの物を作れるようにするかでした。 マネージャーは多くの知識を持つ司令塔で、従業員はマネージャーが考えた計画に従って動く駒のようなものだったのです。

しかし前述のとおり試行錯誤や探索が必要となる複雑な状況では、このようなやり方は機能しません。 複雑な状況においてはマネージャーを含めて誰も答えを持ち合わせていません。 したがって、チームに目的を与え、チームが自律的に機能し、成長を続けながらチーム自身で答えを見つけられるようにしなければいけません。 マネージャーの役割はまさに機能するチームを作ることに他ならないのです。

本書では、エンジニアリングチームのマネージャーに向けて、マネージャーとしての心構え、日々のふるまい、部下との関係づくり、採用や評価、情報の扱い方、組織との関わり方、キャリアについての考え方など、日々の活動に関係がある話題を網羅的に扱っています。 訳者の1人(吉羽)はある外資系企業でマネージャーとして働いた経験がありますが、当時社内で見聞きした内容や教育を受けた内容と本書で紹介している内容には多くの共通点があります。 日本においては、マネージャーになるときに包括的な教育を受けることはまれですが、もしそのような教育があるなら含まれるであろう内容がそろっています。 これからマネージャーになる方や、マネージャーになって日が浅い方はまずは全部読んでみてください。 すでにマネージャーとして長く活動されている方は、日々の活動のなかで随時必要なトピックを参照するのがよいでしょう。

本書が皆様のお役に立つのを願っています。

376ページと分量はそれなりにありますが、平易な文体であること、それぞれの章単位でそれなりに独立していることから、一気に読みつつ、必要なときにリファレンスとして使っていただくのがよいかなと思います。 それぞれのトピックごとに組織のマネージャー同士で読書会なんかをしてみるのも面白いかもしれません。

以下で目次を紹介しておきます。 気になるトピックがきっとあるはずです(希望)。

なお、電子書籍版はKindleはありませんので、オライリー・ジャパンのWebサイトから直接PDFやepub形式の電子書籍をご購入ください。


目次

  • 本書への推薦の言葉
  • 訳者まえがき
  • はじめに
  • 第I部 オリエンテーション
    • 1章 新たな冒険
      • 1.1 最初の週を始める
      • 1.2 スナップショットを作成する
        • 1.2.1 チームに自己紹介しよう
        • 1.2.2 チーム全員と週次1on1を予約しよう
        • 1.2.3 上司と初顔合わせミーティングをしよう
        • 1.2.4 自分のスナップショットを作成しよう
      • 1.3 アクションリストを作成する
      • 1.4 いったん落ち着こう
    • 2章 まず自分を管理しよう
      • 2.1 整理整頓をしよう!
        • 2.1.1 ツール 1:カレンダー
        • 2.1.2 ツール 2:ToDo リスト
        • 2.1.3 ツール 3:メール受信箱
        • 2.1.4 ツール 4:情報を記録する場所
        • 2.1.5 あなたのツールキット:まとめ
        • 2.1.6 ツールキットを使った1日の例
      • 2.2 活動を分類して生産性を高めるには
        • 2.2.1 情報収集
        • 2.2.2 意思決定
        • 2.2.3 ナッジング
        • 2.2.4 ロールモデル
        • 2.2.5 あなたの活動を分類した1日の例
      • 2.3 マネージャーとしてのアウトプットを測るには
      • 2.4 準備完了!
  • 第II部 個人と働く
    • 3章 人間と関わる
      • 3.1 上手なコミュニケーションをするには
        • 3.1.1 コミュニケーションの3つの媒体
        • 3.1.2 あなたに合わせるのではない
        • 3.1.3 一貫性を保とう
        • 3.1.4 フィードバックをするには
        • 3.1.5 避けるべきコミュニケーションの特徴
        • 3.1.6 コミュニケーションと共にあらんことを
      • 3.2 委譲
        • 3.2.1 悪い委譲:両極端
        • 3.2.2 説明責任は委譲できない
        • 3.2.3 委譲の物差し
        • 3.2.4 委譲でやるべきこと、やってはいけないこと
        • 3.2.5 実装方法はあなたに委譲する
      • 3.3 上司との連携
        • 3.3.1 動き出そう。待つのではなく
        • 3.3.2 パフォーマンスについて話そう
        • 3.3.3 マネージャーの世界の蓋を開ける
        • 3.3.4 サマリーの力
      • 3.4 進め!
    • 4章 1on1
      • 4.1 毎週、毎週
      • 4.2 1on1 の準備をするには
      • 4.3 コントラクティング:最初の 1on1
        • 4.3.1 コントラクティングとは何か?
        • 4.3.2 コントラクティング:まとめ
      • 4.4 話す内容と進め方
        • 4.4.1 あなたではなく、相手のためのミーティング
        • 4.4.2 沈黙は金なり
        • 4.4.3 状況報告:退屈なところ
        • 4.4.4 会話の話題のアイデア
      • 4.5 メモを取りアクションをアサインするには
      • 4.6 セラピストでないことに留意する
      • 4.7 次はどうする?
    • 5章 その人に合った仕事とは
      • 5.1 何が人を動かすのか?
        • 5.1.1 欲求の階層
        • 5.1.2 仕事の役割
        • 5.1.3 自己実現への道
      • 5.2 発達の最近接領域
        • 5.2.1 タスクレベルで発達の最近接領域を適用する
        • 5.2.2 キャリアレベルで発達の最近接領域を適用する
      • 5.3 大聖堂とバザール
        • 5.3.1 大聖堂を建設する人
        • 5.3.2 バザールをぶらつく人
        • 5.3.3 会話する
      • 5.4 面談の前のレビュー
    • 6章 1年でいちばん輝かしい季節
      • 6.1 迷信退治
        • 6.1.1 迷信その1:面談はマネージャーがトップダウンでフィードバックをするためのものである
        • 6.1.2 迷信その2:面談は会社が行うものである
        • 6.1.3 迷信その3:パフォーマンスの上がらないスタッフにしか面談は重要ではない
        • 6.1.4 迷信その4:面談は人に嫌われているのでさっさと終わらせよう
        • 6.1.5 迷信その5:面談は当日のサプライズであるべきだ
        • 6.1.6 迷信その6:面談は昇給を言い渡すために使われる
        • 6.1.7 迷信その7:面談はパフォーマンスについて話す唯一の場である
      • 6.2 評価面談の準備をするには
        • 6.2.1 ピアフィードバックを受け取る
        • 6.2.2 面談フォーム
      • 6.3 当日やること
      • 6.4 お金の話をするには
      • 6.5 さて次は?
    • 7章 採用中!
      • 7.1 採用する人を選ぶ
        • 7.1.1 才能が多ければよいものでもない
        • 7.1.2 カルチャーフィットについて
      • 7.2 素晴らしい職務記述書を書く
        • 7.2.1 職務記述書テンプレート
        • 7.2.2 スタイル、トーン、ジェンダーニュートラル
      • 7.3 面接プロセスを設定する
        • 7.3.1 応募書類をレビューする
        • 7.3.2 電話でのスクリーニングを実施する
        • 7.3.3 1 次面接
        • 7.3.4 技術課題(オプション)
        • 7.3.5 最終面接
        • 7.3.6 条件を提示する
      • 7.4 採用の次は……
    • 8章 ゲームオーバー
      • 8.1 人が去るのは普通のこと
      • 8.2 スタッフが去るとき
        • 8.2.1 良い退職理由
        • 8.2.2 悪い退職理由
      • 8.3 うまく戦う
      • 8.4 スタッフを辞めさせる
        • 8.4.1 PIP を準備する
        • 8.4.2 PIP を作成する
        • 8.4.3 PIP の受け渡しと実施
        • 8.4.4 解雇
      • 8.5 もう別れは十分!
    • 9章 友人を作り、人に影響を与えるには
      • 9.1 チームを超える
      • 9.2 ネットワークを構築する
        • 9.2.1 自己紹介をする
        • 9.2.2 定期的に連絡する
      • 9.3 お返しをする
        • 9.3.1 メンタリング
        • 9.3.2 コーチング
      • 9.4 ワンランク上を目指す
  • 第III部 全体像
    • 10章 人間って難しい
      • 10.1 詮索と審判
        • 10.1.1 上も下も
      • 10.2 ぐらつき
        • 10.2.1 傾聴と観察
        • 10.2.2 消化
        • 10.2.3 伝達
        • 10.2.4 同僚のサポート
      • 10.3 ムチとニンジン
        • 10.3.1 ムチ
        • 10.3.2 ニンジン
      • 10.4 馬鹿の山
        • 10.4.1 ダニング=クルーガー効果
        • 10.4.2 インポスター症候群
        • 10.4.3 ギャップを埋める
        • 10.4.4 ダニング=クルーガー効果と折り合いをつける
        • 10.4.5 インポスター症候群と折り合いをつける
      • 10.5 人間だけの問題ではなくて……
    • 11章 プロジェクトって難しい
      • 11.1 サウロンの目
        • 11.1.1 警告のサイン
        • 11.1.2 視線を浴びているとき
        • 11.1.3 視線がそれたとき
      • 11.2 あなた自身の成功の犠牲者
        • 11.2.1 人ではなく生産性
        • 11.2.2 それであなたができることは?
      • 11.3 スコープ、リソース、時間
        • 11.3.1 スコープ
        • 11.3.2 リソース
        • 11.3.3 時間
        • 11.3.4 レバーの透明性を保つ
      • 11.4 いったん落ち着こう
    • 12章 情報の証券取引所
      • 12.1 スパイとゲートキーパー
      • 12.2 必要十分な情報を共有するには
        • 12.2.1 悪い情報を届ける
        • 12.2.2 より高い透明性へ
        • 12.2.3 常に必要十分
      • 12.3 社内政治
        • 12.3.1 政治はどう起こるか?
        • 12.3.2 政治をうまく使う
        • 12.3.3 政治をネガティブに使う
      • 12.4 いったん力を抜こう
    • 13章 コントロールを手放す
      • 13.1 タスクを超越する
        • 13.1.1 ストア派とあなた
        • 13.1.2 コントロールの三分法
      • 13.2 偽りの生産性の罠から脱出する
        • 13.2.1LモードとRモード
        • 13.2.2Rモードを活かす
        • 13.2.3 自分のキャパシティを賢く使う
        • 13.2.4 通知をチェックするのをやめる
      • 13.3 仕事以外でやることも重要
        • 13.3.1 睡眠の重要性
        • 13.3.2 体を動かす
        • 13.3.3 重要なのは今だけ
      • 13.4 本章も……手放す
    • 14章 良いハウスキーピング
      • 14.1 コミュニケーションがソフトウェアの設計を決める
      • 14.2 ギルドでサイロを壊す
      • 14.3 トークの文化を奨励する
        • 14.3.1 チームでのライトニングトーク
        • 14.3.2 部門トーク
      • 14.4 問題を学習の機会に変える
        • 14.4.1 5Why
        • 14.4.2 マネジメントバグ
      • 14.5 よくある問題を解決するツール
        • 14.5.1 このコードはなぜこうなっているのか?
        • 14.5.2 チームは時間とともに改善しているか?
        • 14.5.3 誰に責任があるのか?
      • 14.6 次はキャリアの整理の話
    • 15章 デュアルラダー
      • 15.1 インディビジュアルコントリビューター(IC)トラック
      • 15.2 マネジメントトラック
      • 15.3 キャリアアップフレームワークを作る
        • 15.3.1 キャリアアップ表
      • 15.4 キャリアアップに関するトラブルシューティング
        • 15.4.1 マネージャーは両方のトラックにいるのでは?
        • 15.4.2 マネジメントをやってみても好きじゃなかったらどうしよう?
        • 15.4.3 キャリアアップフレームワークは主観的なものではないのか?
        • 15.4.4 スキルセットの幅が大きい場合はどうしたらよいか?
        • 15.4.5 キャリアトラックがどのように報酬を決定するのか?
        • 15.4.6 うちの会社ではうまくいかない!
      • 15.5 大きな問題に取りかかる時間
    • 16章 現代の職場環境
      • 16.1 ダイバーシティとインクルージョン
        • 16.1.1 パイプライン
        • 16.1.2 文化的な問題
        • 16.1.3 あなたができること
      • 16.2 リモートワークへの移行
        • 16.2.1 見た目ほど簡単ではない
        • 16.2.2 リモートワークをサポートする準備をする
      • 16.3 ワーク・ライフ・バランス
        • 16.3.1 チームを守ろう
        • 16.3.2 すべきことをする
      • 16.4 文化について
      • 16.5 ユニコーンの国へ
    • 17章 スタートアップ
      • 17.1 ソフトウェアが世界を飲み込む
      • 17.2 マネージャーの機会
        • 17.2.1 マネージャー第1号になる
        • 17.2.2 波を捕まえて乗る
      • 17.3 マネジメントがスタートアップの将来を左右する理由
      • 17.4 あなたの未来はどうなっている?
    • 18章 クリスタルボール
      • 18.1 生命、宇宙、万物のあいだにあるもの
      • 18.2 自分のビジョン
        • 18.2.1 自分はどうしてここにたどり着いたか?
        • 18.2.2 次の10年は?
      • 18.3 あなたの計画
        • 18.3.1 プランステートメントを書く
        • 18.3.2 コンピテンシーを評価する
        • 18.3.3 スキルバックログを作る
      • 18.4 エクササイズをスタッフとやってみる
        • 18.4.1 ステップ 1:10 年ふりかえり
        • 18.4.2 ステップ 2:10 年コーチングセッション
        • 18.4.3 ステップ 3:スタッフのビジョンのレビュー
        • 18.4.4 ステップ 4:インプット、レーティング、宿題
        • 18.4.5 ステップ 5:1 年コーチングセッション
      • 18.5 これでおしまい
  • 参考文献
  • 索引

是非お買い求めください。よろヒヒーン!!

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 なぜ「スクラム開発」という用語に違和感があるのか?
次の記事 【資料公開】スプリントプランニング Deep Dive

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World