書評）Elastic Leadership 自己組織化チームの育て方

Management
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

エラスティックリーダーシップ 自己組織化チームの育て方 [ Roy Osherove ]
価格：3080円（税込、送料無料) (2020/3/1時点)

楽天で購入
 
 
感想
「自己組織化」が最近の個人的ホットトピックなのですが、それで検索するとそのままズバリの本が見つかったので読んで見ました。
 
「チームリーダーである私たちの目標は、チームの各メンバーとチーム全体の自己組織化と自己管理のスキルを全体的に成長させて行くことだ」というようなテーマで書かれたこの本は、チームのフェーズを3つに分け、それぞれに必要なリーダーシップのスタイルを解説していました。
 
サバイバルフェーズ：指揮統制型リーダーシップ
  • このモードを解除することがミッション
  • チームに学習する時間がない
  • ゆとり時間を作り脱出する
 
学習フェーズ：コーチ型リーダーシップ
  • 自分や他のバス因子を重要な枠割りから取り除くのがミッション
  • 建設的なことにゆとり時間を使う
  • 経験のないメンバーに一緒に経験させる
  • 適宜、指揮統制型として介入する
 
自己組織化フェーズ：ファシリテート型リーダーシップ
  • ファシリテーターとしてこの状態を維持するのがミッション
  • 現状を処理するチームの能力に注意を払い次に取るべきリーダーシップスタイルを判断する
  • リーダーは実験したり重要なことに時間を使える
 
それぞれのフェーズでリーダーに求められる振る舞いがわかりやすく解説されていました。その内容も良かったのですが、後半が著名なリーダーたちのエッセイ集となっており、そこがまた刺さります。
かつ日本語版特典として日本のリーダーたちのエッセイも収録されているのですが、なんか聞いたことがある人がいっぱい…。
 
「近い・遠い、具体的・抽象的の組み合わせで考えるリーダーとしての方向性の導き方」や、「チームをマネジメントすることを言い訳に、事業やプロダクトや技術から目を背けていい兄貴になりがち」といったエッセイがグサグサ刺さり、気が引き締まるのを感じながら読み終えました。
 
 
ポイントサマリ
 
エラスティックリーダーシップを理解する
 
チームリーダーマニュフェストに向かって努力する
  • チームが求めるリーダーシップは彼らのスキルに応じて変化する
    • リーダーシップスタイルを継続的に変化させるアプローチを採用する
    • チームのニーズに合ったスタイルを認識する
  • 自分自身とチームが改善することに挑戦する
    • ゆとり時間を作る
    • 安全よりもリスクを取る
    • 現状維持よりも実験する
    • 適切な道具、プロセス、実際の仕事環境で実験する
  • メンバーを導くことが中核的なプラクティス
    • 人やコミュニケーションの問題を解決するテクニックを学ぶ
  • リーダーが問題を解決すると学習するのはリーダーになってしまう
 
リーダーシップスタイルをチームのフェーズに合わせる
  • サバイバルフェーズ：指揮統制型リーダーシップ
    • このモードを解除することがミッション
    • チームに学習する時間がない
    • ゆとり時間を作り脱出する
  • 学習フェーズ：コーチ型リーダーシップ
    • 自分や他のバス因子を重要な枠割りから取り除くのがミッション
    • 建設的なことにゆとり時間を使う
    • 経験のないメンバーに一緒に経験させる
    • 適宜指揮統制型として介入する
  • 自己組織化フェーズ：ファシリテート型リーダーシップ
    • ファシリテーターとしてこの状態を維持するのがミッション
    • 現状を処理するチームの能力に注意を払い次に取るべきリーダーシップスタイルを判断する
    • リーダーは実験したり重要なことに時間を使える
       
バス因子（トラックナンバー）に対処する
  • 単一障害展、ボトルネック、士気の低下、成長の阻害
  • バス因子を見つけ、防ぎ減らすことがリーダーの役割の大部分を占める
 
 
 
サバイバルモード
 
サバイバルモードに対処する
  • 中毒性があり留まろうとする傾向がある
  • いくつかのコミットメントを取り消す必要がありそれがリーダーの仕事
  • リーダーの仕事の対価
    • 厳しい要求に応え、判断を下すこと
    • チームをプロフェッショナルにすること
    • 全力をかけてチームがソフトウェアを届ける際に最善を尽くせる状態にすること
  • 自分の習慣を破る
    • 新しい挑戦の前には確かな足がかりを捨てる時期がある
  • 指揮統制型リーダーシップ
    • 会議を開かず決定を下す
    • 悪い決定を正す（Gitを使おうなど）
    • 課題解決は得意な人をアサインする
    • 反対意見には1on1で今のモードを説明する
      • 別のProjectで働いてもらうことも
      • 時間を浪費しない
  • 移行期間に行うこと
    • 不要な会議を捨てチームと過ごす時間を増やし支援する
    • 複数のステークホルダからチームに指示させない
    • 割れ窓理論を理解する
      • レビュー品質の妥協は割れ窓
         
学習モード
 
学習することを学ぶ
  • 学習モード
    • チームを安全地帯の外へ押し出す
      • 抵抗を感じるならチームをうまく操縦できている
    • ゆとり時間を集中訓練に使っている状態
  • 基本はコーチスタイル
    • 間違った決定には時に指揮統制が必要
    • SCMを使わない、というのはありえない
  • 学習には谷（リスクや生産性の低下）があり飛び込むことを恐れてはいけない
    • 全く異なる技術スタックの組織で見習になる、など
  • メンバーを谷に飛び込ませるための「宿題」という方法
    • 全ての会話で一番最後に話す人になる、など
    • 1on1で説明するのが良い
 
コミットメント言語
  • 効能
    • メンバーが阻害要因だと感じていてもリーダーに話しにくいと思っていることを探しだすのに役立つ
    • メンバーが言ったことに対して責任を感じる
  • 制御下にないコミットメントを可能なものに変える
    • バグを今週中に修正します、は制御下にないコミットメント
    • ではなく、毎日5時間をバグ修正に当てます、ならコミットできる
    • 外部要因に関わるものも注意
  • 約束できないことを伝えることは誠実である
  • リーダーもチームもこれを理解し実践する
    • あらかじめこの言語を使うことを説明する
    • 間違いはお互いに直すルールを敷く
    • 最初は不快（谷）になることを知っておく
  • コミットメントを果たせないことがわかった時はすぐに警告をあげる
    • 早ければ早いほど手を貸すことができる
  • Active Listening でコミットメントしたことしてないことを確認する
    • 最後は感謝で締める
 
メンバーを成長させる
  • 挑戦的課題「あなたはそれに関して何をするつもりですか？」
    • コミットメント言語での回答を求める
    • リーダーが解決してはいけない
    • 最初は不信感、反発がありえる
    • リーダーは背後からサポートする
      • 人脈や時間など
    • 解決できなくても罰しない
    • 問題が起きたときに自問することを教えている
  • 宿題
    • 恐怖や不快感を伴う谷に飛び込ませる
    • 日常の作業ではなくスキルを学ぶこと
    • 例
      • タイピング速度の向上
      • 否定的表現を1日3回までに
    • 定期的にフォローアップする
  • あなたとチームのペース
    • ペースを考慮し挑戦が多くなりすぎないように
    • 短期的な付き合いであっても同様に接することで将来帰ってくるかもしれない
 
自己組織化モード
 
自己組織化を促進させるためにクリアリングミーティングを行う
  • 目的はうまく行っていないことやしまい込んでいる悪い感情、共有すべき情報など、チームが知っていることを全てクリアにすること
  • コミットメント言語、誠実さ、ゆとり時間を組み合わせてチームが自分たちの問題を解決するための学習に向かわせる
  • 進め方
    • 今週うまく行かなかったことは？
    • あなたはそれに関して何をするつもりですか？（コミットメント）
    • 今週良かったことはなんですか？
  • 最後に自分も話す
  • 問題に対してすでに対処しているメンバーの数が自己組織化の度合いになる
 
影響パターン
  • 6つの影響力のコンテキストを考える
  • 個人レベルの能力、モチベーション
    • メンバー自身の問題か
  • 社会レベルの能力、モチベーション
    • 周囲の人々、支援、情報、リソースの問題か
  • 環境レベルの能力、モチベーション
    • 設備や予算、報酬の問題か
  • これらの観点で問題の要素を洗い出して全て解決する
管理職のためのマニュフェスト
  • チームリーダーと役割を分け合う
    • リーダーは技術、チーム、プロジェクトに関連することにおいてチームを成長させることができる
    • 管理職はそれ以外のあらゆることにおいて部下を成長させることができる
    • 全体的なスキル向上や個人を多様なプロジェクトで作業させる、など
 
 
チームリーダシップについて知るべきこと
  • フィードバック
    • サバイバルフェーズ
      • よくない行動、やらなければいけないことを伝える
      • 「XをやめてYだけに集中しなければなりません」
      • 「今週終わらせて欲しいことはXです」
    • 学習フェーズ
      • 欠けているスキルに関すること
      • 貢献してくれているメンバーが直面している難題に関すること
      • 「あなたはXで素晴らしい仕事をしました、それはあなたにとってもとても難しいことだったとわかっていました」
    • 自己組織化フェーズ
      • チーム全体の意思決定や目標に関すること
      • 「このアイディアは素晴らしい。できれば2つ以上出して初めに試したい方を選ぶようにしてください」
      • 「どうすれば目標を達成できるか。そのために支援できることはありますか？」
  • 衝突を学習に導く
    • チームが衝突し決定できない時は、コミットメントの延期を提案する。
    • それぞれを試し、そのデータから判断させる（並行学習）
    • 効率と引き換えに効果を手に入れる
    • サバイバルフェーズではこのアプローチは取れない
  • おそらく技術的な問題ではない
    • 実際は、理解しているのが当然でしていなければ失格という考え方や、それによってグループから追い出されるかもしれないという恐怖かもしれない
    • これは個人ではなく社会レベルの問題
  • コードをレビューしよう
    • できない場合、社会レベル、環境レベルでの問題に目を向ける
  • 空気、食料、水をドキュメントする
    • リポジトリの場所、チームの開発フローはチームにとってそういったもの
    • 「ちょっとした質問」は「ただ」ではない
    • バス因子を減らすことにも役立つ
  • （給与）査定とアジャイルは仲が良くない
    • 査定は個人、非継続的、トップダウンである傾向
    • 学習とキャリア開発を個々のユーザーストーリーに組み込む
    • イテレーションごとにメンバーが学んだことについて会話する
    • イテレーションごとに査定時に参照できる記録を残す
  • 学習を通して導くというリーダーの責務
    • メンバーに失敗する機会は提供するが、それは必ずチームのセーフティネットのコンテキスト内にある
  • Coreプロトコルの紹介
    • チェックインプロトコル
    • 自分がどう感じているかを怒っている、うれしい、悲しい、不安だ、の4つを使って表現する
  • リーダーシップと成熟したチーム
    • 自己組織化フェーズにいるリーダーは、チームを観察することが主な責務となる
    • 実際には重要なスキルを欠いていることがわかったら、学習歩フェーズに押し戻す必要がある
  • 作業負荷を分散する
    • 衝突を恐れて頼みやすい人にばかり退屈な仕事を押し付けてはいけない
    • 衝突に対処するのがリーダーの責任
  • メンバーが自分たちで仕事を管理できるようにする
    • 今後は自分たちで仕事を分配することを期待していると表明する
    • 難しければ手を貸すことも伝える
    • それを実現する方法を理解しているか確認し支援する
  • 見守り、尋ね、敬意を示す
    • 現在妨げとなっているものの根本的な原因を明らかにするためのオープンで厳密な質問をたくさんする
  • リードについて
    • 「言いにくいな」とおもったときこそ発言しよう
    • 実は別のメンバーも気になっている
  • チームに成長してもらうためのリーダーシップ
    • 自分が学び成長する
    • 他人の学び方を学ぶ
    • 1人で抱え込んでいる仕事を減らす
    • 現在を記録し、後になって振り返る
    • 成長したチームを維持するために力を発揮する
      • 解散からリスクをとって守る
  • コミニケーションメンテナになる
  • コンセプト駆動のリーダーシップ
  • 相互リスペクトの維持
  • 部下やメンバーに鍛えてもらう
    • 共に作業し自分の実力をさらけ出す
  • 静かなリーダーシップ
    • こうあるべきだ、というのを宣言して周りへ説明しながら淡々と地道に進み続けていく
  • いく先を決める
    • 集団で活動するときの不安要素
      • 今何をすべきなんだろう
      • なぜそれをすべきなんだろう
      • それによってどうなるのだろう
      • やるべきことは多いが一体どれからすべきなんだ
      • チームの人はどんな人だろう
      • 自分の考えはどう受け止められるだろう
    • 方向性はこれらの道標となる
      • 近い・遠い、具体的・抽象的の組み合わせで考える
      • 制約はチームのモード、余裕と体力
      • 求めるゴールが自分の考えを超えて欲しい時は「遠い」方向性を出す
        • 遠くて抽象的はぼんやりするので具体的にする
      • ゴールが明確でそれを超えたものを求めない時は「近い」方向性を出す
        • 近くて具体的、は裁量がないので抽象的にする
      • 具体的な方向性の例
        • エディタを作る
        • 近いテーマ
          • 起動が早く軽快なエディタを作る
          • 活動がイメージしやすく目指しやすい
        • 遠いテーマ
          • 使う人がコードを書くのが楽しくなるようなエディタを作る
          • チームの能力が足りないと迷走する
      • 方向性は現状、抱えている課題、チームの能力、環境、時間んじくなどから導くもの
  • 採用プロセスについてもっと考えよう
    • 採用も重要な仕事
      • 業務後の疲れた頭で正しい判断はできない
      • 優秀な人ほど見極める力が高いことが多い
    • 採用後のギャップを減らす
      • 無理して採らない
      • 文化や雰囲気に合わない人も避ける
      • チームの平均より上の人を採ることで総合力が上がっていく
      • みんなわざわざファイルを開いて見ないので壁に貼る
    • 名前づけ
      • チームが得た気づきに名前をつけて定着させたり外の人へ伝える
    • 初めよければ全てよし
      • 良いこと、成功しやすいことを先に行う
      • 振り返りはKeepから
      • ポジティブFBから
    • リズム
      • チームのイベントはリズムを持って定期的に
    • 問題　対　私たちの構図
      • 席を同じ方向に向け視線の先に問題を置く
      • 改革ではなく小さくても良いので行動を起こす
    • 最後に：QoEL
  • 大事な問題にフォーカスする
    • 事業を伸ばすには事業を伸ばすことを考える必要がある
    • ロジックと願望の違い
    • 本当に今最も大きい課題はチームビルディングなのか
    • 「いい兄貴」になる誘惑に負けず、難易度の高い問題から目を背けてはいけない
    • チームをマネジメントすることを言い訳に、事業やプロダクトや技術から目を背けてしまいがち
    • 第一線でリードし続けることが、結果的に自己組織化したチームを作る見本になることもある
 
 

書評）「最高の人材」が入社する 採用の絶対ルール

Management
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

「最高の人材」が入社する　採用の絶対ルール [ 釘崎清秀 ]
価格：1430円（税込、送料無料) (2020/2/23時点)

楽天で購入
 

 

感想
採用活動について「心得「求職者を集める」「応募者から選ぶ」「内定辞退を防ぐ」「自社の採用プロセスを評価する」というステップごとに古い常識についての説明→まとめ→正しい常識、とまとまっていてとても読みやすく理解しやすかったです。
 
既に採用に携わっている人やこれから携わる人が読めばそれぞれのステップで必要な正しい知識と陥りがちな罠を学ぶことができて良いと思いました。
 
例えば採用初期でまだ応募者の知識が浅く企業と関係性ができていない段階で「当社を志望した動機は？」と聴いて判断基準にすることに意味はなく、「企業を選ぶ上で大事にしている、または譲れないところは？」とその人の価値観を探り、一致すればどう一致するのかを言語化して伝えることで、企業と応募者が一緒に志望動機を醸成することができる、みたいに具体的に採用面接に活かせそうなTipsも多く学べました。
 
 
ポイントサマリ
 
求職者を集める
  • 4つの観点を整理する
    • 必須要件
    • 優秀要件
    • ネガティブ要件：あってはならない
    • 不問条件
  • 説明会を社員とのコミュニケーションの場にする
  • プレゼンはそんなに聴いていない
  • エントリーの質を上げるためには、合わない人が遠慮する工夫
    • こういう人は合わない、明示する
    • ネガテイブな面も伝える
      • リアリティショックを抑えることにも
      • 合理的な理由を説明できるように
 
応募者から選ぶ
  • 面接官の先入観への対策をする
    • どんな人材が欲しいのかの認識を合わせる
    • 面接官同士でフィードバックし合う
  • 見極め、動機形成は分けて考える
    • 1次と2次で分けるなど
    • 面接シートは見極め用
  • 志望動機は採用プロセスを通して求職者と醸成するもの
    • 購買動機が上がらないのは売り手にも問題がある
    • どんな基準で企業を選んでいるか、から価値観を探る
    • 入社後の働き方がイメージできるようにする
  • 志望度では合否を決めない
  • 当社を志望する理由ではなく、何を大事にして企業を選ぶか
  • 育成が困難なものを洗い出し、人材要件に入れる
    • 育成可能なものは優秀要件に
  • 業務の性質を振り返り、見極めが必要な能力を考える
    • 自ら楽しんで学習できるか
    • 変化に対応できるか
    • 相手の言葉で状況を説明できるか
  • 社風に合っているかどうかを応募者任せにしない
    • 言語化して伝える
    • 内部事情を紹介しながら入社後の活躍イメージを伝える
    • どういう行動や考え方が評価されるかを考える
  • 質問のポイント
    • 仕事をする上で大事にしていること、譲れないことは？
    • 当社以外で惹かれている企業は？重視するポイントは？
    • 来てくれたことに感謝を伝え話しやすい雰囲気を作る
    • 曖昧な回答を否定せずにまず受け止めて、深掘りする
    • 意見の相違はまず受け入れて、自分の考えを伝える
    • メモを取りながら話すことをあらかじめ伝える
 
内定辞退を防ぐ
  • フォローアップは募集時から始まっている
  • 関心度を高める
    • 自社がどのように人の役に立ち社会に貢献しているかを伝える
    • どんな人が活躍しているか、など
  • 志望度を高める
    • 応募者の大事にしている点、価値観に合った自社の特徴を伝える
  • 適応予想度
    • 入社後にどう適応・活躍できそうかを伝える
  • 内定後の過度な説得は逆効果
    • 内定後の意思決定を支援する、情報を提供する
 
自社の課題を見つける
  • 新入社員に採用プロセスを評価してもらうことは有効
  • 関心度、志望度、適応予想度がどこでどう上がったか
  • 採用サイトで関心度は上がったか
  • 説明会で関心度、志望度は上がったか
  • 面接で志望度、適応予想度は上がったか
  • 内定者フォローで十分に支援されたか
 
 
 

書評）ソフトウェアファースト

Management
 
なんかもう全部入りでした。
 
ソフトウェアは業務を効率化するだけではなく、ビジネスのルールを変えるものであるという考え方をソフトウェアファーストと呼び、
 
ソフトウェア開発を「手の内化（内製してコントロールできてる状態）」するために組織に必要な観点をプロダクトマネジメント、エンジニアリングマネジメント、採用、評価、給与体系、DevOps、経営、組織文化、キャリア開発などなど、様々な観点を交えて著者の方の経験に基づいて語られています。
 
中にはリーン、インセプションデッキ、デザインスプリント、スクラム、k8sなどのトピックにも触れていてその経験知識の広さにびびります。
 
ほんと全部入りでした。
 
ポイントサマリー
 
定義
ソフトウェアは業務を効率化するだけではなく、ビジネスのルールを変えるものであると言う考え方。課題ドリブンで出発し、ソフトウェアファーストで解決する。
 
 
誤った品質追求
  • 当たり前品質（基本品質）：充足されて当たり前、不足すると不満
  • 一元品質（性能品質）：充足されると満足、不足であれば不満
  • 魅力品質：充足されていれば満足だが、なくても仕方ないと受け取られる
  • 無関心品質：満足度に影響を与えない
  • 逆品質：充足されていれば不満、不足であれば満足、人によって異なる
  • サービス開発において重視すべきは魅力品質
  • 他者が真似すればすぐに基本品質になる
 
プラットフォーム構築
  • 小さいうちに汎用性を高めると期待を裏切る
  • 最初は特定の領域、企業が確実に使えるものを
  • APIエコノミーも一種のプラットフォーム戦略
 
あらゆるサービスは課題解決のためにある
  • 恩恵を受ける人が多ければ多いほど支持される
  • 課題ありきで考えないとオーバーエンジニアリングになる問題
  • 最初はプロダクトマネージャーがひたすらその企画が正しいのかを検証する
 
プロダクト企画のやり方を変える
  • プロダクトアウト：作ったものや作りたいものを売る
  • マーケットイン：市場やユーザに必要とされるものを作る
 
10Xを目指す
  • 10%成長なら既存の改善で達成できるかもしれないが10倍となると根本から変える必要がある
  • 制約を強くすることで創造性を生む
  • Chrome bookはPC起動からGmail利用まで10秒を目指して実現した
 
名は体を表すとは
 
競合に対する見方を変える
  • 航空業界の競合はリモート会議システムとなった
  • 終電を逃した客を狙うビジネスホテルの競合はタクシーだった
  • 競合が新機能をリリースしたら、それは誰のどんな課題を解決しようとしているのかを考える
  • 競合は自社に気づきを与えてくれる
 
ユーザーを理解する
  • インタビューでお困りのことは？と聞いて得られる回答に価値はあまりない
  • 観察を通じて本人が気づいていないユーザー自身の理解を進める必要がある
  • 遠慮の文化が邪魔をするときは、周りでお困りの方は？と聞くと有効なことがある
 
インナーソース
  • OSSプロジェクトのやり方を本来クローズな会社組織にも当てはめてみようという考え方
  • 誰もが参加、利用可能な状態で開発を進める
  • 社内ハッカソンのコードをGHEに置き部署を超えて全ての人と社内OSSとして共有
  • 大事なのは社内のエンジニアが担当外にも貢献したいと思える状況を作ること
 
事業会社のIT人材育成、コニカミノルタ
  • 1年半かけて実施、月一回木金土曜
  • 宿題も
  • 講師は社内中心で時に外部講師
  • 前期の受講生から次期運営を選出
 
開発組織のマネージャーの役割
  • メンバーのパフォーマンスを最大化し、成長を助け、成長し続ける組織を通じて事業に貢献すること
  • 現場発信の議論を受け、引き出し、解決に向けたタスクを提案し、リードしていく
  • それに加えて技術面の判断も求められる
 
CTOとVPoE
  • CTOの役割を一部切り出したのがVPoE
  • CTOが主に自社の技術ディレクション、経営に対しての技術面からの関与、開発への投資判断やパートナー選定、事業に対して技術面からの判断を担う
  • VPoEはエンジニアリング組織のトップとしての組織マネジメントを担う
  • テック企業の場合、経営陣に技術出身が多くあえて置かないこともある
 
出島戦略
  • CTO直下で素早い事業判断
  • 何をもって成功とするのかを明確に定める
  • 目的達成の度合いを正確に測定できるKPIを設定する
  • 四半期ごとに何らかの成果を出し、周知を徹底する
  • PoCをやるだけの組織にならないように注意
 
変化に強い開発組織は「信頼」から生まれる
  • やれること、よりやりたいことを尊重する
  • やりたい人に任せてできるようになれば会社の資産となりその人のキャリアアップにもつながる
  • さくらのインターネットではコンテナ、k8sもやりたいひとから発信された
 
マネージャになることを望まないエンジニア
  • エンジニアとしての力量が乏しい人がマネージャとして権勢を振っているのを見ている
  • あまり意味があると思えない事務作業などに追い立てられているのを見ている
 
 

書評）サーバント・リーダー

Management

 

感想
管理職の主人公が仕事も私生活もうまくいかなくなったきたところで妻に勧められて修道院へ一週間入り、そこでいろんなバックグラウンドを持つ同じように悩みを持ってそこへ来た人たちと、今は修道士となりリーダーシップの講義を受け持つかつての伝説的経営者の元でサーバントリーダーについて話しながら気づきを得ていく、みたいなストーリーでした。
抽象的な話になりがちなトピックですが、ストーリー仕立てになってることでとてもすっと入ってきました。
「リーダーとしてのあなたが作り出してきた環境で、従業員たちは起きている時間の約半分を働いて過ごす」という責任を選択したリーダーがどう振る舞う必要があるのか、努力して備える必要のある技能は何か、結果得られる報酬は何か、といった話は全て自分としても気づきの多い内容でした。
特にサーバントリーダーシップについて、これまで基本として「奉仕し導きましょう」だと考えていたところに対して、「リーダーを選択した時から奉仕し犠牲を払うことが求められ、その行動の結果として権威（影響力）が備わっていく」という視点は新しく、サーバントリーダーシップを実践する目的がよりクリアになりました。
今後も何度か読み返したいと思える本で、うちの部署でも沢山のリーダー的な人たちに読んでもらいたい本でした。
 
ポイントサマリ
 
リーダーが見落としているもの
  • リーダーとしてのあなたが作り出してきた環境で、従業員たちは起きている時間の約半分を働いて過ごす
  • 権力は地位や力で強制する力
  • 権威は個人の影響力によって、自分の意思通りのことを誰かに進んでやらせる技能
  • 権力は与えたりでき、関係を蝕むもの
  • 権力に頼らなければならないのは、権威が崩れたかなかったから
 
殻を破り、逆転の発想を
  • 自分のパラダイムは包括的で不変のものだと思い、新しいことを受け付けずにいると危険
    • 上から下へのパラダイムでは誰もが上司の方を向いていて客を見ていない
    • 監督者が従業員を客と考えて、彼らが何を必要としているのかを見極め、答えようとする
  • 欲求ではなくニーズに応える
    • 親が子供のやりたい放題やらせることは欲求通りにさせること
    • 人により違うニーズはなんなのか常に自問しなければならない
    • 下のニーズが満たされると上のニーズぎ生じる
    • 一番上は自己実現、最高の自分になること
 
奉仕と犠牲とリーダーシップ
  • なんでも賛成する人間や自分に似た人間ばかりをそばに置くな
  • 奉仕と犠牲から影響力や権威が生まれる
  • 意図 − 行動 ＝ 無
    • 行動が伴わないことに意味は無い
  • 意図 ＋ 行動 ＝ 意志
    • リーダーシップは意志から始まる。意図に沿った行動をする
    • 正しい意志があれば愛を選ぶ。この愛は動詞で、正当なニーズを見極めてそれに応えること
    • リーダーは人々のニーズに応える過程で奉仕し、犠牲を払う事が求められる
    • 他人に奉仕して犠牲を払うと、権威や影響力を手にする
    • 人に対する権威を得た時、リーダーと呼ばれる権利をも手にする
  • つまりリーダーシップは、ニーズを見極め、満たす事
 
行為としての愛について
  • ここでの愛とは、感情を抱くことではなく、良き振る舞いをする行為を意味する
  • どう感じるかはコントロールできないが、どう振る舞うかはコントロールできる
  • 相手が感じ悪くとも、自分は忍耐強く、正直に、丁寧に接する事ができる
  • 忍耐とは、自制する事（過ちの指摘におい。て）
    • リーダーとしての仕事は、設定されている基準と実際の仕事の差を指摘する事で、そこに感情は必要ない
    • 訓練とは行為を正して教育する事で、罰することではない
  • 優しさとは、注意を払い評価し励ますこと
    • 人に注意を払う絶好の機会は、積極的に話を聞くこと
    • 積極的に聞くとは、相手の話す間ほんの数分であっても相手の世界に入り込むという犠牲を払う努力が必要
    • 評価
      • 人は探しているものを見つける、選択的知覚
    • 励ます
      • 誠実さを持って具体的に
  • 謙虚とは、信頼でき、虚偽や傲慢さがないこと
  • 敬意とは、他者を重要な人物として扱うこと
    • なぜなら実際に重要だから
    • 人は存在するだけである程度尊敬に値する
  • 遅刻で伝わるメッセージ
    • 彼らの時間の方が大切
    • 私はそれほど重要じゃない
    • その人は正直じゃない、自分で言った事（時間）を守らない
  • 無私とは、自分の必要より優先して、他者の必要に応える事
    • 応えるのはニーズであって、欲求ではない
  • 許しとは、悪いことをされた時に怒りを捨てること
    • 気づかないふりをすることではない
    • 正当に自己を主張する振る舞いをする
  • 正直とは、欺かないこと
    • 真実を話さない、一部を隠すことも欺くこと
    • 欠点について話し合うのを避けるのは不正直
  • 献身とは、選択を貫くこと
    • あなたが発した言質に、全力を傾け続ける行為
    • リーダーとしての真価は、難しい相手のために努力しなければならない時に顕著になる
  • 愛するという動詞としての愛は、メンバーの正当なニーズを見極め、それに応えることによって、人のために努力する行為を意味する
 
メンバーが成長できる環境とは
  • 成長するのは本人の力、人ができるのは健全な環境を整えること
  • 関係の銀行口座
    • 人前で人を罰すると周りの人の口座からも引き出すかとになる
    • 人前で人を褒めると周りの人の口座にも預け入れる
  • 自分の責任範囲においては行為を規制することができる
    • メッセージとして伝えて自らの変化を促す
    • あなたを変えられるのは、あなただけ
    • 人は自らの選択で変わらなければならない。リーダーができるのは人が変化し成長することを選択するよう、必要な刺激を与えることだけ
    • 規制に従わなければその組織に居続けることはできない
 
どう行動するかを選びとるとき
  • 行動をとることで感情がついてくる
  • 違う行動をとりたいという気持ちが強まれば、そうするだろうと考えるが、そんな感情が生じることはあまりない
  • 奉仕する人を愛し、彼らのために努力して、それに合わせた行動をとれば、時間が経つにつれて、その人たちに好意的な見方ができるようになる
  • 相手が〇〇したら、私は変わる、は責任を押し付けており、かついつになるかわからない
  • どのような要因や因果があれど、選択をするのは本人の責任
  • 考えは行動になり、行動は習慣になり、習慣は人格になり、人格は運命になる
 
リーダーにたいする真の報酬
  • 権威を持って導くという訓練を自らに課すことは、個人的なミッションステートメントを掲げるようなもの
  • 人間としての真の目的は、心理的、そして霊的な成熟に向かって成長すること
  • 愛し、奉仕し、他者のために努力する中で、私たちは自己中心的な考えを捨て去っていき、自らが成長していく

書評）実務でつかむ！ティール組織

Management
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

実務でつかむ！ティール組織 [ 吉原史郎 ]
価格：1944円（税込、送料無料) (2019/9/1時点)

楽天で購入
 

 

感想
今話題のティール組織とはなんぞや、ときになったので読んでみました。いつも通り抽象的な分厚い本が苦手なのでこの本を選択。
一言で言うと「社長や上司が管理／実務介入しなくとも、組織の目的実現に向けてメンバー進むことができる独自の仕組みや工夫にあふれている組織」のことだそうで、この本ではティール組織の一つの形態であるホラクラシー組織について、旧来のピラミッド階層型の組織がどのようにして「自主経営」型に変化していくかを事例交えて手短に説明してくれていました。
 
だいたい言ってることは納得ですし、これまで読んできた本とそれほど遠くない印象でした。
心に残ったのはこの辺。
 
マネジメント（上司）がチームに任せられない理由：
  • 自分に自信を持っていると、うまく育成できず、人に任せられない
    • 右腕候補を見つけても、自ら首を突っ込み、あなたはダメだという
  • マネジメントの考えてることとメンバーが考えていることのズレが心配
    • メンバーが重要な勘所を抑えて仕事しているか不安
    • メンバーが、自然と業務上の勘所がわかるような環境、仕組みがないことが原因
    • 目的地図と重要指標の透明化でメンバー自ら進み、管理できる仕組みを
  • マネジメントとメンバーの、会社のことを考えている度合いのズレが心配
    • メンバーにとっては経営理念は人が作ったもの
    • 想いを伝え、行動を共にし、組織のビジョンへ近づいていることを共有しないと伝わらない
 
自主経営を阻害する要因：
  • 仕事の役割の不透明性
    • 誰が何やってるのか、自分はどこまでしても良いのか
  • 役職による意見交換のしにくさ
    • 上司に聞いてもらえるか
  • 意思決定プロセスの曖昧性や不納得
    • どういうプロセスで新規投資や給料が決定されているのか
  • 重要指標が見える化されていない
    • 結果に至るまでのプロセスの指標が見えているか
    • 価値のあるプロセス上の重要指標はなんなのか
 
次世代組織へ移行する難しさ
  • 理由は変数が多いから
  • 移行前に部分的にでも実践期間を持ち定着させるとこから始める
 
また、ここでも言われていたのは組織のビジョンと個人のビジョンの結びつきの重要性でした。まずはビジョンを見せること、そしてそれがメンバーのビジョンと繋がって、メンバーが実現したいと思えること。
そうした土壌があって、個人が最大の能力を発揮できる組織作りができる、という話はサーバントリーダーシップとも通じていました。
 
ポイントサマリ
 
ティール組織
  • 「生命体」に比喩される
  • 社長や上司が管理／実務介入しなくとも、組織の目的実現に向けてメンバー進むことができる独自の仕組みや工夫にあふれている組織
  • 3つの要点
    • （進化する）存在目的
      • 競争、市場シェアよりも、存在目的という一定の方向性を示すことを重視
    • 自主経営（がかのジュとなる仕組みや工夫を有している）
      • ピラミッド構造からチーム制へ
      • 決定に前には専門家やCEOからの助言を受ける助言プロセス
    • （個人としての）全体性の発揮
      • 人間性を保つことを重視
      • 感情的な部分にも目を向ける
 
ホラクラシー組織とは
  • ティール組織の一形態
  • 人／役職ではなくロールが主役
  • 個人ではなくロール、ガバナンスプロセスに権限を委譲する
    • 各ロールの目的、ミッション、権限を決めるのは上司ではなくガバナンスミーティング
  • ガバナンス（ホラクラシー憲法）があることで管理者がいなくとも機能する
 
ホラクラシー組織の「自主経営」
  • 役職ではなく役割を与える
  • 役割は柔軟に修正可能で全メンバーがその意思決定に関われる
  • 役割に基づいて日々業務を行う中、良いアイデア、懸念があればそれに寄り添うことを約束事にする
  • 重要な指標を透明化
  • チャレンジしたい役割に一定時間さける
 
組織モデル
  • 生き残るためのトップダウン（北風、わたし型）
  • 軌道に乗ってきて新たな価値、組織の目的を生むためのボトムアップ（太陽、わたし達型）
  • マネジメントの引き出しとしてどちらも使える
 
ボトムアップから次世代組織
  • マネジメントの考えてることとメンバーが考えていることのズレ
    • メンバーが重要な勘所を抑えて仕事しているか不安
    • メンバーが、自然と業務上の勘所がわかるような環境、仕組みがないことが原因
  • マネジメントとメンバーの、会社のことを考えている度合いのズレ
    • メンバーにとっては経営理念は人が作ったもの
    • 想いを伝え、行動を共にし、組織のビジョンへ近づいていることを共有しないと伝わらない
 
次世代組織への距離感
  • 変数の多さ
  • まずはマネジメントの「心の奥の想いに気づき」、メンバーと対話すること
  • 目的地図と重要指標の透明化
    • 目的地図は計画段階で重要な勘所が漏れないようにある
    • 指標は進捗管理や評価のためではなく、メンバーが、確認するためのもの
  • 組織の目的とメンバーの目的の繋がり度合いの向上の仕組み作り
    • PDCAのCの前に出来なかったことだけでなく、小さくても出来たことを確認する
    • その結果感じたメンバーが大切にしたい価値観と組織の目的が緩やかに繋がっていることを感じる
    • 自分として、仕事をする際に大切にしたい価値観や考え方と、組織目的の繋がりを見つける
    • また、繋がっていることを伝える
  • これらを移行前に実践期間を持ち定着させるとこから
 
役割：リードリンク
  • 役割
    • 組織の方向性や重要指標の透明化
    • 事業の優先順位
    • 資金の事業への配分
    • ロールへのメンバーの配置
    • メンバーへのアドバイス
  • 認められないこと
    • 指示命令
  • ザッポスの事例では、社長から社内的にはリードリンクのロールへ
  • 組織目標を実現するための必要な環境を整える
 
自主経営を阻害する要因
  • 仕事の役割の不透明性
    • 誰が何やってるのか、自分はどこまでしても良いのか
  • 役職による意見交換のしにくさ
    • 上司に聞いてもらえるか
  • 意思決定プロセスの曖昧性や不納得
    • どういうプロセスで新規投資や給料が決定されているのか
  • 重要指標が見える化されていない
    • 結果に至るまでのプロセスの指標が見えているか
    • 価値のあるプロセス上の重要指標はなんなのか
 
ネットプロテクションの事例
  • 自分に自信を持っていると、うまく育成できず、人に任せられない
    • 右腕候補を見つけても、自ら首を突っ込み、あなたはダメだという
  • 組織を一枚岩にするために価値観を定め、採用もこれに従う
    • 誠実に向き合う
    • 力をあわせる
    • 本質を考える
    • 最高にこだわる
    • 自分を磨く
  • 若手の定着の組織課題に向き合うため次のビジョンの作成に取り組む
    • 若手社員も関わり時間をかける
    • 複数チームでビジョン餡を作り持ち寄る
    • できあがった7つのビジョン
      • 歪みない事業／関係性を作る
      • 全てのステークホルダーと真摯に向き合う
      • みんなで会社を作る
      • 志を尊重する
      • ワクワク感を大切にする
      • 違いこそを組織の力に変える
      • 厳しく求め、支え合う
  • 新人事制度
    • 基本給与は「能力／姿勢への対価」
    • 賞与は「成果への対価」
 
 
 
 

書評）サーバント・リーダーシップ実践講座

Management
 
感想
もともとサーバント・リーダーシップが自分の大切にしている部分と一致することが多い気がして興味があったので読んでみました。
で、哲学的抽象的な話が苦手なので実際の企業の例が中心となったこの本を選択。
 
ざっくり要約すると、今の複雑化、高度化するご時世、リーダー1人が引っ張って出せる成果ではやってけないので、リーダーはメンバーが自己成長して能力発揮できる環境／状況を作ることに重きを置きつつ、こうしたいという想いを持ってビジョン（進む方向）をしっかり見せて組織全体で頑張っていきましょうみたいなことかなと思いました。
 
また、トップの人がサーバント・リーダーシップを持つだけでなく、多数の人が身につけ相互にネットワークを組みながら進んでいくのがこれからの姿だという点にすごく共感できました。
 
言われてみれば当たり前のことも多いですが、実際に発揮できているかどうか振り返ってみると怪しいことも多々あります。過去の成功体験に固執して相手の意見を無視してないか、とか。
7つの習慣でも似たようなことが言われてますが、周りを変えたいならまず自分から、はどこにでも当てはまりますね。
 
ほんとに、この本を読んでもらいたい人がいっぱいいますw
 
 
ポイントサマリ
 
この国にはリーダーシップが足りない
  • 難しい問題はリスクをとって自分で意思決定せず、上位者に判断を委ねようとする傾向
  • リーダー待望論は他責で依存状態
  • 組織や社会の中に多数のリーダーが存在しネットワークを組みながら進んでいくのがこれからの姿
  • 「想い」の罠
    • 個人的な想いのために周囲を巻き込もうとする
    • 想いを実現するために全てを自分でやろうとする
 
新しいタイプのリーダーの台頭
  • 部下の意見を取り入れつつもビジョンを示す
  • 部下の自己成長の邪魔をせず、支援し、環境づくりをする
  • 部下だけでなく協力してくれる関係者にも感謝を表する
 
なぜ今、サーバント・リーダーシップが注目されるのか
  • 細分化され高度化する状況においてメンバーが指示通りに動くだけでは成果が上がらない
  • ネット社会
    • 情報操作ができなくなり、情報コントロールによる独裁を破壊する
    • 戦略はすぐに表に出て戦略の中身による差別化が難しい
  • 雇用環境の変化
 
サーバント・リーダーシップとは何か
  • ただの親切ではない
    • 本来はこうあるべきだ／こうしたいとビジョンを描くこと
    • それを実現するために人を巻き込みその人たちが活躍できるように奉仕すること
  • 物事を全体として捉える
    • 個々の事象を解決するのではなく大きな枠組みを変えようとする
 
リーダーとリーダーシップ
  • リーダー
    • 任命、選ばれて肩書きがつくケース
    • 自然発生的にリードする立場になるケース
  • リーダーシップ
    • 能力と人間性という２つの資質から発生している影響力
    • マネジメントは権限に基づきルールや制度を利用して指示命令で動かすこと
      • リーダーシップを発揮していない管理職も存在しうる
      • 創意工夫を生むにはマネジメントだけでは限界がある
    • リーダーシップを強化するには能力と人間性を磨いていく必要がある
      • つまりは自分を変える事
 
サーバント・リーダーシップの要件
  • 従来のリーダーシップとの違い
項目
従来のリーダーシップ
サーバント・リーダーシップ
モチベーション
最も大きな権力の座に就きたいという欲求
組織上の地位にかかわらず、他者に奉仕したいという欲求
競争を勝ち抜き、達成に対して自分が賞賛されることを重視
みんなが協力して目標を達成する環境で、みんながウィンウィンになることを重視
影響力の根拠
目標達成のために、自分の権力を使い、部下を畏怖させて動かす
部下との信頼関係を築き、部下の自主性を尊重することで、組織を動かす
コミュニケーションスタイル
部下に対し、説明し、命令することが中心
部下との信頼関係を築き、部下の自主性を尊重することで組織を動かす
業務遂行能力
部下に対し、説明し、命令することが中心
部下の話を傾聴することが中心
成長についての考え方
車内ポリティクスを理解し活用することで、自分の地位をあげ、成長していく
他者のやる気を大切に考え、個人と組織の成長の調和を図る
責任についての考え方
責任とは、失敗した時にその人を罰するためにある
責任を明確にすることで、失敗を学ぶ機会とする
  • ５つのバリュー
    • 個人を尊重する
    • 導く（共有できるビジョンを打ち出し勇気付けて導く）
    • サーブする（お互いに尽くす）
    • 人の持てる力を引き出す
      • 強みに正しい評価を与え勇気付ける
    • 個人の成長へとつなげる
      • 癒しと学びの過程を通して成長を促す
  • 10の特徴
    • 傾聴
      • 相手と自分の内なる声
    • 共感
    • 癒し
      • 相手の心を癒し本来の力を取り戻させる
    • 気づき
    • 納得（相手の）
    • 概念化
      • 大きな夢やビジョナリーなコンセプトを持つ
    • 先見力／予見力
      • 現在と過去から将来を予想する
    • 執事役
      • 自分の利益よりも相手の利益
    • 人々の成長に関わる
      • 一人一人が秘めている力や価値に気づき信じる
    • コミュニティ創り
      • 人々が大きく成長できるコミュニティを
  • 奉仕は実行力を高める
    • 人は欲求充足という理屈で動く
      • リーダーの指示で欲求を満たせると思うならやる気を持って取り組む
      • 君臨型リーダーの指示は熱心に行動しているように見せかける方向に
  • ５つのバリュー、１０の特徴の意味
    • 相手の欲求を満たす
    • より効果的な行動をとる支援ができる
    • 協力学習やチームビルディングにより相乗効果を生み出す
  • 目的の力：人は大義に燃える
    • 目標だけでなく目的を明確にすべき
    • 目的のない仕事は人に悪影響を与える
    • ビジョンは目標／目的の意味合いがあり、ミッションは目的そのもの
      • ミッションも合わせて示す
    • リーダーの個人的な欲求のみにフォーカスしたビジョンにも大義はない
    • 管理職になって偉くなったと勘違いする人がいる。偉くなるとは神に近づくことだがそれは違う。
      • 管理職になったら遅く出社するのがその例
      • 人の上に立つものはむしろ模範を示さなくてはならない
    • リーダーは難しいときほど根明であれ
    • 人を許すことを身につけるべき
    • 一人一人に参画意識を持たせることが大事
      • 部下自身がこれをやらねばと思うように導く必要がある
      • そのためにはコンセンサスが大事である
      • しかし「皆で決める」は衆愚であり最悪
        • 大事な事は自由に意見を言える事
        • リーダーはその中で最良のものを選ぶが、意見が採用されなかった人もこれは俺の意見だと皆が思えるように導くべき
 
サーバント・リーダーシップの実践例
    • サーバントハート
      • 日頃陽の当たらないバックヤードの従業員を表彰
      • 他部署の仕事を１日体験し相手の立場を知る
      • 従業員だけでなくその家族も家族としてみる
        • 家族で会社イベントに参加など
      • 人事部はHuman resourceではなくPeople & Leadership development
    • 楽しむ
      • 採用時にユーモアを重要項目として扱う
      • Kick offやプレゼンも楽しみ要素を、など
    • コアバリュー
      • 人を大切にする
    • ミッション
      • 私たちはコーヒーを売っているのではなく、コーヒーを提供しながら人を喜ばせるという仕事をしている
    • ビジョン
      • 人々の心に活力と栄養を与えるブランドとして世界で最も知られ、尊敬される企業になる
  • チックフィレイ
    • S：将来を見極め、計画を作り込む
    • E：周りの人たちと積極的に関係を持ち、
    • R：常に新たな発明／改善に取り組む
    • V：ビジネスの結果だけでなく従業員、お客、家族のリレーションシップを重要視する
    • E：それぞれの価値を具体化して実行する
  • P＆G
    • 権限移譲をし、部下の話をしっかりと聞き、何をサポートすればビジネスがアップするのか。お客様を頂点に置いた、組織スタイルを構築するにはどうすれば良いのか。このマインドを常に持ち、リーダーシップを取るのが、サーバント・リーダーである
    • 会社のような組織をサーバントリーダーとして動かそうと思ったら、まず自分の中にミッション、ビジョンを明確に持ち、それを組織のメンバーに伝える努力が不可欠になる
    • 大切な事は変革の必要性や可能性を社員に理解させ、ゴールを示して、そこに主体的に向かうようにモチベートする事だ
    • リーダーが指示するのは1割でいい。自分たちで考えて思う存分活動できる舞台を与えてあげてほしい
    • 哲学や企業理念といったしっかりとした幹があればあとは自由でいい。異なった能力が集まった企業が一番強い。同質が集まっても発展性はない。
 
サーバント・リーダーシップの要素と効用
  • メンバーに奉仕する
      • 全員経営
        • 細かい経費含めすげて公開、社員が当事者意識をもつ
      • 公私混同の禁止
        • お金ほど人をダメにするものはない
        • 社員を信用しやりたい人に任せる
        • 失敗したら任せた側も一緒に連帯責任
      • 連帯感／コミュニケーション
        • 一緒に食事をしたり語ることを大事に
      • 席替え
        • 社長役員の席を通路側にして気軽に報告相談ができるように
      • 肩書きではなく名前で呼び合う
        • 肩書き文化はポジションパワーで人を動かしコミュニケーションが一方的に
        • 名前で呼び合うことでポジションパワーが効きづらい風土に
        • お互い甘えられない
          • 部下が上司に「〇〇さんどうしたらよいでしょうか？」と安易に答えを求めてきても、「○○さんはどう思ってるの？」と返す
        • 管理職が「社員の成長に関わる」ように支援した事例
      • 飼育研究会という勉強会
        • 実はベテランでもわかってないことや、固定観念に囚われていることがわかった
      • 理想の動物園というビジョンは明確になっても予算がなかった
        • 「全員が自分が今できることをやる」という方針を掲げこれがコアバリューに
        • 職員の工夫から「行動展示」につながった
      • 人の成長への関与とコミュニティづくりによる社員の支援の事例
      • 再生への第一歩
        • 倒産したリゾートを再生するときに始めにやるのは従業員の話を聞くこと
        • 新しい経営者が自分たちの話をしっかり聞いてくれることが「癒し」に
      • キャリア像を押し付けない
        • 本人のキャリア目標をサポートする育成制度
      • 究極のフラット
        • 言いたい事は言いたい人に言いたい時に
        • 自由でフラットなコミュニケーションを会社の環境として保証していく
      • 侃侃諤諤な組織
        • 誰もが意思決定者になる組織
        • 立場で発言に重みをつけない
        • 管理者の謙虚さとメンバーの力を引き出してあげたい思い
      • 威厳は必要ない
        • 若いスタッフに頭にきたらこちらも頭にきて物を言えばいいだけ
      • 自分の不完全さを認める
        • 権限で威厳を保つのは正しいことを言うことを要求され続けること
        • 常に正しいことを言ってるわけではないと伝える
      • 社員の本気のコミットメントを引き出す
        • 散々テーブルに意見を出した上で意思決定したならば、みんなでそれを達成する
        • 最終的に自分の意見が採用されなくても、発言できること自体、自分の話をきちんと聞いてもらえること自体でかなり欲求を満たすことができる
      • オープン主義
        • 愚痴で多い１つは意思決定への不満。誰がこんなこと決めたのか。
        • 意思決定プロセスは公開した方が良い
        • 経営会議に一般の社員が入ることができるように
      • 立候補制
        • 愚痴でもう１つ多いのが上司、人事の悪口
        • リーダーに複数人立候補させて誰がベターかを選ばせる
          • 欠点はあるがこういう長所がある、と欠点を認識して選ぶ
        • 共感、納得、人々の成長に関わる、により自律とモチベーションを引き出す事例
    • セコム
      • 従業員への統制は極力しない
        • 予算統制、権限規定も設けない
        • 統制することが社員の自発的なアイディアの蓋をすることになる
      • 後継者が自由に采配を振るために自身が障害になると思ったら身を引く
      • 全国を回って組織の問題点を４つに分類
      • 人災
        • 売り上げが悪いのを店長のせいだと言う
        • 実際、問題は商品力、接客技術など企業の総合力から起きている
      • 経験頼みの個人プレー
        • 共通のオペレーションがないとノウハウが積み重なっていない
      • 仕組みがないこと
        • 現場で起こっていることを組織や仕組みに反映させる作業が経営者の仕事
      • 社風
        • バイヤーが買いすぎることによる大量在庫の問題
          • バイヤーのせいにして人災として対処療法に終始していると解決しない
          • 全員で共有できるシステムを作り見える化を徹底
          • 全社共通のフォーマットを導入して解決
          • 感性を大切にする社風にメスを入れシステム的にアプローチ
        • 計画95％、実行5％という企業文化を変更
          • どうせ計画は狂う
        • 社風、企業文化を変え、仕組みを変えて社員を支援
    • キャノン電子
      • 震災復旧時、工場長に社長の権限を委譲
        • 現場を知っているのは現場
      • いざという時に自分の判断で動ける人や組織を
        • 日頃から情報共有、目的を明確に伝える、権限移譲をすることにより
    • 未来工業
      • 「常に考える」というモットーを掲げている
        • 何か提案するために500円
        • 習慣の積み重ねが差別化のアイディアを生む
      • 勤務時間を抑え休日を多くする
        • みんなが勤務時間内に能率や生産性をあげ、競争力を確保しようと必死に
        • 徹底してメンバーを信じた仕組み
  • 代議あるミッション／ビジョン／バリューを示す
      • 社名の変更
      • ビジョンの明確化：リゾート運営の達人になる
        • 待遇など未整備なことが多くてもビジョンを示すことはできる
        • これにより採用もできるように
      • ビジョンとのギャップに悩みやめる人も
    • セコム
      • ビジョン：あらゆる不安のない社会へ、困った時はセコム
      • 事業展開の判断基準
        • 社会にとっての正しさの追求
          • 他の企業がやった方がいいと世間が思えばチャンスがあってもやらない
        • 既成概念の打破、創造的破壊
          • 既存事業の撤退も躊躇せず
      • サービスが先、利益が後、という考え方を社員に徹底
        • 全員経営
      • グループ全体で社員数17万、本社にはわずか300人
        • 本社が全部コントロールするのは不可能
        • どんどん権限移譲を
      • 公益資本主義
        • 会社を社会的存在と捉え、株主のことだけを優先するのではなく、従業員の働きがいや、顧客、地域社会などへの貢献をバランスよく重視する考え方
 
日本企業の問題を救うサーバント・リーダーシップ
  • 日本企業の苦戦
    • 練磨の文化
      • 日本は島国で農耕民族
      • 練磨を続けることで成果をあげる文化
        • 前提が変わると対応できない
        • 練磨ではなく、新しい前提に基づいた戦略の変更が必要
        • もしくは現実に合わせて自ら前提そのものを設定し直すことが必要
    • リーダーシップの問題
      • 有能なリーダーが成功に溺れ傲慢になるケース
      • 現実を認識できない
        • 人の話を聞かない
        • 過去の成功体験に固執
      • 個人的感情で動く
        • メンツが潰れたり、長年の努力が水の泡になるような優れた意見を無視
        • イエスマンばかりを集める
      • 権限移譲しない
        • 他人を信用できない
        • 自分の限界が組織の限界に
  • 戦略と実行にどう影響するか
    • 実行への影響
      • 権限移譲しないことによるモチベーションの低下
        • 双方向コミュニケーションで共感を作り出すことが必要
        • 100％価値観に合わなくても納得して取り組んでもらうために
      • 権限移譲しないことによる自律性の低下
      • 自律性が育たないのでメンバー間の相乗効果も生まれない
    • 戦略への影響
      • 前提を疑いながら成長することをダブルループ学習
      • セカンドチェンジへの対応
        • 自分たちは何で何をしようとしている存在か、から見直す必要がある
        • ビジョンそのものも見直す
        • フィルム事業衰退時のビジョンの見直しが差となった
        • コアバリューの問題
      • 我が社がなくなったら社会や人々はどんなふうに困るか、という問い
        • 将来どんなふうに困られる存在になりたいか
      • 試行錯誤する
        • 一度の試行錯誤でできるのはさっきより質の良い仮説だけ
        • フィードバックを回すためにはコミュニケーションが重要
          • 双方向だけでは不十分
          • 自分の考え方に固執せず更新する
      • イノベーションを起こすために
        • 挑戦のための失敗を許す文化が必要
    • なぜサーバント・リーダーシップか
      • 自分の不完全さを認めることで効果的な戦略を立てることができる
      • 認めるために謙虚さを持つ
      • 認めることで学び続ける
 
  • 想いが強烈になると野心になるが悪いことではない
    • 強い野心が成功を支えることは間違いない
    • 野心がエゴに向くと君臨型に
    • 私の成果、ではなく私たちの成果、に
  • 自分の弱みをさらけ出すこと
    • 常に自分が一番正しい、ではサポートもできない
  • 相手に関心を持ち考えや背景を知ろうとする
  • 感謝の気持ちを持ち心から言葉にする
  • 自分にしてもらいたいことをまず相手にする心を大切にする
    • これらの価値観を浸透させる
  • 自分たちのあり方、どうありたいかに向き合う
  • 愛
    • 愛は行動
    • たとえ本当はメンバーへの愛情がさほどなくても積極的に声をかけ傾倒し、関わりを多く持てば愛情は湧いてくる
  • 謙虚さ
    • 自分を客観視する
      • 自分にとって耳の痛い話をしてくる人をそばに置く
    • 現場に出て自分の成功体験だけでは通じないことを知る
    • 自分が何らかの繋がり合うネットワークの中の一員と認識する
    • 高い目標を持ち、自分の能力の不足を知る
 
 

書評）エンジニアのためのマネジメントキャリアパス

Management
感想
著者の体験を基にした、マネジメントキャリアに関する勘所がメンター、テックリード、人／チームの管理、複数チーム／複数管理者の管理、経営幹部、とそれぞれのステージごとにまとめられています。
自分の今のステージの章を読む事でいま期待されている事は何か、要注意点は、といった理解が得られ、一つ上のステージの章を読む事で上司が何を見ているのか、そこへ行くためにはどうすればいいかといったヒントが得られるような感じです。
エンジニアのための、とはありますがそれ系の組織にいる非エンジニアの人が読む事でも、技術系組織でのマネジメントの勘所に気づきを得られそうです。
何人か読んでもらいたいメンバーがいるので年明けに勧めてみたいと思います。
 
ポイントサマリ
まえがき
  • まずは話す
    • オープンドアポリシーでは疎遠な部下はより疎遠になる
  • 評価と採用
    • 会社の行動規範は抽象的すぎることが多い
    • 日々の業務で自分たちが尊重するものは何かを考える
      • メンバーにも関与してもらい実例を加え自分たちが使えるものとして
      • それを実際の評価と採用で用いる
 
マネジメントの基本
  • 上司に何を求めるか
    • １対１のMTG
      • 目的1：上司と部下の人間的なつながりを作ること
      • 目的2：要検討事項について1対1で話す定期的な場を設けること
        • 定期的であることで準備、態勢を整えられる
    • フィードバックと指導
      • 悪い癖や習慣は早く知れば知るほど直しやすい
      • 褒めるのは人前で、叱るのは1対1で
        • 人前で褒められるのが苦手なら先に伝える
      • 成果物の助言を上司に仰ぐのは一目置いていることを示す手っ取り早い方法
      • 昇進したいならどういう方向に照準を定めるべきかを聞くのが早い
      • 面白くない仕事でも価値や会社への貢献をしっかり理解させる
    • トレーニングとキャリアアップ
      • キャリアアップに必要なトレーニングなどのリソース、役に立つ他部門の専門家を見出し繋げる
      • 昇進基準を満たすための準備の指導をする
  • 管理のされ方
    • 自分が何を望んでいるのかをじっくり考える
      • 新人であろうとベテランであろうと自分と向き合う責任は自分が負っている
    • 自分に対する責任は自分で負う
      • 希望を表明するのは前へ進む一番手っ取り早い方法
      • 否定的な反応を上司が返してきたら自分が今おかれている立場を認識させてくれる材料となる
    • 上司も人の子
      • 自分の手で変えられるのは自分自身だけ
      • 地位が上がれば問題の報告だけでなく解決策の提案も期待される
      • 上司へ解決を求めるのではなく助言を仰ぐ
    • 上司は賢く選ぶ
      • 上司次第であなたのキャリアは大きく差が出る
      • 社内での駆け引きの仕方を心得ている上司はあらゆる面で後押ししてくれる
 
メンタリング
  • チームの新人に対するメンタリングの意義
    • メンターにとっては他者への責任を負う経験をする好機
    • メンティーにとっては専任のお目付役に教えを請う好機
    • 卒業見込み以外の学生を採用しない
    • その会社の正規雇用を志望する学生を採用する
    • インターンは買い手市場
      • 普段重用されない多様性のための採用も
  • インターンのメンタリング
    • 最高の夏を体験させる
      • 大学へ戻って仲間へ語れるような
    • 受け入れ態勢／環境を整える
    • プロジェクトを用意し学生とともにマイルストーンへ至る過程を検討する
      • プロジェクトを振り返って自分なら2、3日で完成できるような機能や要素を見つける
    • 締めくくりにプレゼン
      • やり遂げた仕事が有意義であったと実感してもらう
      • 会社が仕事を認めてくれたと実感してもらう
    • 自分が将来リーダーとなるために必要なスキルを磨くチャンス
      • 傾聴
        • きちんと伝わる形で話すのが下手な人が多い
        • 口にする言葉以上のことを聞き取る
          • 口調、しぐさなどのシグナル
        • 相手の質問がわかりにくいと感じたら表現を変えて返したり絵を描いたりする
        • 質問しやすい雰囲気を作る
      • 明確な伝達
        • なすべきこと、出すべき結果を的確に伝える能力を磨く
          • まずは自分で調べて、わからなければ質問して良い、など伝える
      • 自身の対応の調整
        • 相手の能力や進捗など状況に応じて対応を調整する
          • 報告は週1か、毎日がいいか
          • フォローはどの程度が適切か
  • 新入社員のメンタリング
    • 研修、会社に溶け込むための支援、社内の人脈作り、など
    • 日常になってしまっている「不文律」を伝える
    • 新人の人脈は自分の人脈ともなる
  • 技術／キャリアに関わるメンタリング
    • その関係に対する期待や目標を明確にすることが大切
  • メンターになったら
    • メンティーに何を望むのかを伝える
      • 質問の仕方、割ける時間
  • メンティーになったら
    • この指摘関係から何を得たいのかを考える、必要がない場合もある
  • すごい上司／ひどい上司ーアルファギーク
    • 誰かの功績は自分の手柄、失敗には我関せず
    • 自分の知っていることは知っていて当然
    • メンタリングは変わるきっかけ
      • メンティーに最適なやり方で手ほどきすることという視点を持てれば
    • アルファギークを管理職にする場合は熟慮が必要
      • 優位性を保つために情報を独占することも
  • メンターを管理するコツ
    • 焦点を絞った計測可能で明確なゴールを設定
    • プログラミングの職務以外で功績をあげたい人を選ぶ
    • 一つの責任を追加で引き受けた功績を認める
    • ある業務スキルの向上を目標とする場合はその熟練者が最適
    • メンタリングは未来のリーダーを育成する好機
      • 内気な開発者も視野が広がるきっかけ
      • 傲慢な開発者はインターンのメンターで謙遜を感じるきっかけに
  • メンターの重要な心得
    • 常に好奇心を絶やさずオープンな心で
      • フレッシュな目を通して見つめ直す機会
      • 不明確な仕組み、自分の理解の浅さ、再検討に値すること
    • 相手の言葉で話す
      • 傾聴の訓練
    • 人脈作り
      • キャリアは長く、業界は狭い
 
  • シニアレベルに達したエンジニアが順次一時的に担う職責群
    • メンバーコミュニケーションと育成
    • プロジェクト管理
    • チーム全体の生産性向上
    • 難局の打開
    • 他部門との協業
    • キャリアパスを登るために必要なスキルを身につける段階
  • なるタイミング
    • まだ早いと感じているなら受けない方が良い
    • 将来もっと上の職位についてから「技術力不足」とならないように
  • テックリードのコツ
    • 技術面での貢献とチーム全体のニーズへの対応のバランスを取る
    • 自分の時間管理
    • チームの負担への配慮
    • プロジェクト全体への大局的な視点
  • システムアーキテクトとビジネスアナリストとしての役割
    • 対象のシステムの十分な把握
    • 複雑なソフトウェアを設計する方法の理解
    • ビジネス要件に対する理解と要件定義能力
  • プロジェクトプランナーとしての役割
    • デリバリ可能な単位で大まかに分割
    • 熟知している人から助言をもらい進め方を考える
    • 優先順位を検討しプロジェクトの初期に最優先事項に取り組む計画を立てる
  • 開発者兼チームリーダーとしての役割
    • 問題が生じたら自分で解決しようとせずすぐに伝える
    • PDMが妥協するであろう課題にチームが疲弊するのを割ける
    • メンバーに任せられる作業を見つける
  • プロジェクトの管理
    • まぁまぁ満足できるほどに予測し計画できる範囲内で、幾分かでも洞察力を働かせる
    • 立案作業に費やす時間に比べれば完璧度は重要度が劣る
  • 時間を割いて説明することの大切さ
    • 相手が納得するまで懇切丁寧に説明する
    • 相手は肩身の狭い思いをせずに必要な知識を得られる
    • 自分の判断や忠告を信頼してくれるようになる
  • プロジェクト管理の実務
    • 複数の工程に分割する
      • 大枠から徐々に細かく
      • 必要な人の支援を仰ぎながら
      • 始められるタスクはチームに割り振ってさらに細分化してもらう
    • 細部の引っ掛かりや道の要素にもくじけない
      • 未知の要素に納得がいくまで向き合う
    • プロジェクトを始動し、調整を加えながら進行させる
      • どこまで進捗して完遂まであとどのくらいかを大まかに把握できる計画に価値がある
    • 立案過程で得られた洞察を活かし、その後の要件の変化に対応する
      • 諸要件に配慮してプロジェクトを分割する過程で洞察が得られる
      • 変化のコストをみんなに伝え妥協点を探る
    • 完了に近づいたら細部の詰めを
      • 大失敗に終わる想定で逐一検討してみる
      • 公開の計画だけでなくロールバックの計画も
  • 技術職か管理職か
    • どちらにもメリデメはあり進路変更は可能なもの
  • ひどい上司ープロセスツァー
    • プロセス信者
    • プロセスはチームや作業のニーズを満たさなければならないことを理解する
    • 仕事のやり方はチームによって違う
    • 順守状況を見守る番人ではなく守りやすいものへの改変を検討する
    • プロセスで縛るのは失敗を恐れる不安から
    • 「ゆるい」状況でも大丈夫だと安心できる働きかけを
  • 優秀なテックリードとは
    • アーキテクチャを理解している
      • プロジェクトを率いていくための明確なイメージを描けるように
    • チームプレイに大切さを心得ている
      • 自己犠牲だけでもダメ
      • 面白いところ総取りもダメ
    • 技術的な意思決定を主導する
      • 見極める
        • 自分で決めること
        • 経験豊富なメンバーに判断を委ねること
        • チーム全体で決断すべきこと
      • 討議中のこと、討議の結果をみんなと共有する
    • コミュニケーションの達人である
      • チームの代表となり外部とのコミュニケーションを担う
      • 書く力、話す力を伸ばす機会
      • ブログやセミナーで発信力を磨く
      • あらゆるFBを受け傾聴しメモを取り自分の表現に直すなど
 
人の管理
  • 直属の上下関係
    • 信頼感と親近感の構築を
      • その人の管理をやりやすくしてくれる質問をする
      • 褒められる場合は人前が良いか1対1がよいか
      • 重要なフィードバックは検討できる書面か口頭か
      • ここで仕事をする理由、希望、意欲、期待など
      • 不機嫌／落ちてる時ははたから見てどんな感じか
      • いつも不愉快になる要因で事前に知っておいた方がいいもの
      • 耐え難いと思う上司の振る舞い
      • キャリアアップの明確な目標
      • この部署にきて何か言っておきたいことができたか
    • 今後１ヶ月／２ヶ月／３ヶ月の計画を立てさせる
      • 部下が明確に目標を立案できれば理解が進んでいることがわかる
      • 人選の誤りを検知し対処が必要なことを認識できる
    • 新人研修用のドキュメントを更新させて理解を促す
      • 前回更新後のUPDATEを反映してもらう
      • 不明瞭な点を改善する
    • 自分の流儀や要望をはっきり伝える
      • 1on1の頻度や報告の仕方
      • 進捗や結果をどのように把握／レビューしたいか
      • どのくらい自力で問題解決を努力したら応援を求めても良いか
    • 新人からもFBを得る
      • 最初の３ヶ月間のチームに関する感想や意見をできるだけ述べてもらう
      • 批判を煽る行為は禁止
  • チームメンバーとのコミュニケーション
    • 定期的な1on1は必要
    • 1on1のスケジューリング
      • 週一でやってみて頻度を調整する
      • お互いにとって都合の良い日時を選ぶ（月金を避けるなど）
    • 1on1にまつわる調整
      • 頻繁にやり取りする相手なら不要な場合も
      • 新人ならコーチング、ベテランなら業務内容などにフォーカス
      • 報告が得意でない部下なら頻繁に
      • 良好な関係でも実施する
        • 良好と相手も思ってるとは限らない
        • 優秀な部下を顧みず問題児にだけ時間を費やすのは誤り
      • 会社が変化／不安定なときは部下も気になっている
        • ちゃんと答えてあげることに噂を封じる効果がある
        • 言えない場合は今は言えないと伝えてあげる
    • 1on1の進め方
      • ToDoリスト型
        • 口頭で済むようなToDoリストをトピックにすると不自然
        • 口頭がふさわしいのは「微妙なニュアンスを伝えたい」もの
      • キャッチアップ型
        • 部下の最新情報を入手するための1on1
        • 部下主導で進めさせること
        • 重要だと思う議題を気楽に持ち出せる雰囲気づくり
        • 不満を並べ立てる場にならないように、建設的であること
      • フィードバック型
        • スキル向上や知識獲得のため
        • 目標の達成度のレビュー
        • 問題児は頻繁に
        • 解雇を検討中なら文書で記録し上司から要望も添えて送付
        • 悪いFBは直後に
      • 経過報告型
        • 管理者が下級管理者と開く1on1の多くは経過報告型になる
        • 直前のプロジェクトレポートからの差分更新だけになっている場合は注意
        • プロジェクトと無関係なトピックを用意する
          • チーム、会社、etc.
      • 相手を知るための機会
        • 相手のことを一個の人間として気にかけているという姿勢を見せる
        • 家族、ペット、趣味、これまでのキャリアについて話してもらったり
        • 今後の長期目標を尋ねて見ても
        • 部下を後押ししたいという気持ちを表明する
      • 議事録
        • 共有のドキュメントで作成し管理することがオススメ
        • 書記は上司
        • 議論の要点、持ち上がった考慮点、ToDoなど
    • 細かすぎる上司と、任せ上手な上司
      • どのMTGにでるべきか、何を報告すべきか一緒に考える
        • いざという時一カラになってくれる安心感
        • 裁量権があり自主性が発揮できる状態はモチベを生む要因
      • 委任と放任の違い
        • ほったらかしにせず支援に備えて待機する
  • 効率よく仕事を任せるために
    • チームの目標
      • 成功の計測基準をチームに尋ね、その結果を報告させる
      • 計画がない場合は期限を切って目標を立てさせる
    • チームに尋ねる前にシステムからの情報収集を
      • 自分が入手できる情報でチームの時間を犠牲にしない
      • チームの目標に基づいて情報を収集する
    • プロジェクトの進行に伴って焦点の当てどころを調整
      • 初期とデリバリ前は支援が必要
      • それ以外は順調に進んでいる作業と手間取っている作業を大雑把に
    • コードやシステムに関する基準を設定する
      • 不安を払拭するために大きな共通の物差しを作っておく
      • 基準を決めておくことでFBから個人的要素が排除できる
      • 技術スタックに大幅な変更を加える場合は上位のレビューをするなど
    • 情報は良きにつけ悪しきにつけオープンな形で共有する
      • 正しい報告の仕方を教える
      • 個人に責任を問わない
        • 批判を避けるために手遅れになるまで報告しなくなる
  • 継続的なフィードバックの文化を根付かせる
    • 肯定も訓戒も定期的に共有する
    • 部下に目を向ける、やりにくい会話をする訓練に
    • 部下の基本情報を仕入れる
      • 目標、長所と短所、昇進のための改善点
      • 焦点の当て所を見定める準備
    • 日頃から部下を見守る習慣を
      • 才能や功績を見つけてあげる練習を
      • 継続的な粗探しにならないように
    • 深刻な話題も日常レベルでさらりと
      • 肯定的なFBを続けると訓戒系のFBにも耳を傾けてくれる
      • 継続的なFBのサイクルを利用してきになることをFBする
    • コーチングとの組み合わせ
      • 問題が発生した時に「他にどうやり得たか」と問う
      • 肯定のFBの時も今後どこをさらによくできるかという提案もする
      • コーチングはそれを必要とし傾聴する気のある部下に行う
  • 勤務評価
    • 360度評価
      • 多数のFBを集める
      • 継続的なFBで見過ごす可能性のあるパターンや傾向が見えてくる
      • 悪意のこもったFBを共有するかは見極める
    • 勤務評価の要約の作成と面談
      • 評価をする十分な時間を確保する
      • 直近のことだけではなく期間全体に目を向ける
        • 常時記録を取る、メールを見返す
        • 全体を視野に入れることで成長や変化に気づく
      • 具体例をあげ、周りのFBも引用する
        • 色眼鏡を通して評価しない
      • 功績や長所にはたっぷり時間をかける
        • 昇進を決定する際の重要な判断材料になる
      • 要改善点は焦点を絞って
        • 周りのFBの中の共通項で自身が同意見のもの
        • 良くある事例
          • 手伝いすぎて自分の時間を取れない
          • 共同作業で批判的すぎる
          • 作業の分割が下手
          • 多部署との共同作業が苦手
          • プロセスに従うのが苦手でやっつけ仕事になる
      • 予想外の評価で驚かせない
        • 昇進したばかりなら基準が変わっていることを事前に伝えたり
      • 悪い評価は具体的に理由を説明できるように
        • どうすれば良い評価を得られるか具体例も含めて
      • 潜在的な可能性
        • 一定期間勤続していてこれといって手腕を発揮できない場合はこの会社で将来性はないと見ても良いかもしれない
        • 真の可能性は時を置かずに芽吹くもの
          • もうひと頑張りの努力を惜しまない
          • 問題が発生すれば鋭い提言をする
          • 手付かずだった領域でチームを助ける
        • 独自のやり方を持った人の評価が悪い場合は開花するところに移す
          • プログラミングは苦手だが危機管理はピカイチなら運用チームへ、など
  • キャリアアップへの取り組み
    • 自分の会社が昇進に対してどのような方針と手続きを取っているのかを把握する
    • 昇進を希望するがそれに満たない部下に対してはそれを知らせ、改善すべき事柄を把握できるようにする
    • 昇進が近い部下に対して昇進材料となりそうなプロジェクトをアサインして成果を上げさせることも必要
    • 一定のランクまで昇進して打てる手がない場合は多部署に紹介してメンタリングや支援を要請するなどして新たな挑戦課題を
      • 地位によって職務が異なり、経過とともに能力限界まで昇進して無力化する
      • 現在の職位での成績は昇進後の活躍を保証してくれない
      • ある職位に昇進させる以前からその職務を課す
        • そうしたキャリアアップの好機がチーム内にない場合、より大きな責任を負わせられるよう仕事の割り振りや進め方を再検討する必要があることを示唆しているかもしれない
  • 成績不振者の解雇
    • 徹底したコーチングが必要
    • 期待されているレベルの仕事ができていないことをはっきり知らせる
    • 与えたFBについて記録を取る
  • 脱皮のためのコーチング
    • 希望するが昇進する見込みがない、一定レベルまで昇進して足踏み状態
    • 次のレベルで求められるスキルがどういったものなのか
      • 説明しても見合う努力をしない
      • そのためここはキャリアップを図る上で最適な場所ではない
      • 昇進を望むなら別の部署へ移る必要がある
    • 他の部署など仕事を見つける機会を与えてあげる
 
チームの管理
  • 開発グループマネージャのJD
    • チーム全体の作業を遅らせない範囲で技術的成果物に携わる
    • チームの作業の遅滞を招くボトルネックや問題を突き止め解消する
    • 最も価値のあるプロジェクトを見極めチームを集中させる
    • プロダクトリードと協力してスコープを調整し成果物を構築する
    • 人員計画を立案し人材を募集する
    • 異なるスキルセットを持つメンバーをチームとして管理する
    • メンバーの役割と期待を伝えFBを提供する
    • プロダクトの技術的ロードマップを管理する
    • 主要なマイルストーンのデリバリを主導する
    • 技術的負債を費用対効果分析し解消の計画を経営陣に提示する
  • 管理者にとって一番大切なこと
    • 最高の技術力を持つことではない
    • チームの人々を後押しし成功を極力サポートすること
  • ITスキルの維持
    • 確かな技術力の持ち主という評価が得られないと、ある会社で管理職になってもそのあとの選択肢が限られる
    • 小規模な技術的作業への従事で得られるもの
      • システムの課題、負債を察知できる
      • 構築に手間取っている、デプロイが遅い、オンコールの負担が高いなど
      • 要件の実現可否、難易度の評価が自身で可能
      • 新機能実装の最短ルートを見分けられる
    • 中間管理職より上に登るのに必要な技術力を十分に身につける
  • 機能不全におちいったチームの「デバッグ」の基本
    • デリバリにこぎつけられない
      • 人は些細なゴールであっても定期的に達成することで精神衛生を維持する
      • ペインポイントに気づきボトルネックを解消する
        • リリースに関わるツールの不備
        • 手作業に頼りすぎなテスト
        • 規模が大きすぎる機能
        • 作業の細分化のコツを心得ていない開発者
    • 厄介な部下への対応
      • 波風を立てる、マイナスにこだわり続ける、噂話がすぎる、排他的など
      • 必要なら上司に応援をあおいでも構わない
      • 他チームへ配転させるだけでも解消することも
        • 嫌な思いをせずにチームから出ていけるように手を貸す
      • チームのエネルギーを吸い取り枯渇させないように
      • 巧みな攻撃こそが最大の防御、迅速な行動が不可欠
    • 過労による士気の低下
      • システムの不安定性が原因であれば当面安定性のためのロードマップを
      • 計画立案の段階で持続可能性のためのリソースを確保
      • 納期が間近で過労状態の時はチアリーダーたるべし
        • 一丸となって難局を乗り切ることで結束が固まる効果も
        • ともに乗り切ったかが嫌だったかを部下は覚えている
      • 難局から学び再発防止に努める
    • 協働に関する問題
      • 関係部署との協働で足を引っ張られる形になっているケース
      • 管理者が改善の意欲をみせるだけでも効果がある
      • 相手責任者に不満があってもチームの前では前向きに
      • 皆で一緒にちょっと息抜きをするような機会を考える
  • 元同僚を自分の部下として管理する立場になったら
    • 気まずい状況を認め向き合う
    • 助けが必要であることを腹を割って話す
    • 決断を独りで下そうとしない
    • 自分が手放さなければならない技術的作業を任せる
    • 売られた喧嘩は「価値ある戦い」のみ応戦する
    • 管理者になった後の移行期間は「大人の対応」で乗り切ったほうがうまくいく
  • 盾になる
    • チームが目標に集中できるように不要ないざこざの盾になる
    • ただし目標のコンテキストを理解することに役立つならチームの中に入れてしまった方が良い場合もある
    • 知らせた方が良い会社のことを隠蔽してはいけない
      • 他から伝わると疑心暗鬼に
    • 管理者はチームのメンバーの親ではない
  • チームの意思決定を主導するコツ
    • 「データ重視」の文化を根付かせる
    • 顧客に対する共感を深め、チームにコンテキストを伝える
    • 将来を見据え２歩先に立って考える
      • 変化を起こしうる新技術を把握するための情報収集の時間を設ける
    • 意思決定やプロジェクトの結果を振り返る
      • 自分たちの意思決定から常に何かを学べる
  • 「対立を手なずけられる」と「避けて通りたがる」上司
    • 多数決、投票結果に従って決定を下す方法だけに頼ってはいけない
      • 時には管理者が決定する責任を負うことも必要
    • 意思決定から個人的要素を排除するための明確なプロセスを確立する
      • チームに委ねたいなら明確な基準を用意する（リリース承認の例）
    • 「爆発寸前」の問題に見て見ぬ振りをしてはいけない
      • 問題に気づいたらすぐに指摘する、指摘できる関係性を作る
    • 本当に対処を要する問題だけを取り上げる
      • 管理者がチームのセラピストになることが目的ではない
      • マイクロマネジメントにならないように
    • 他チームへの責任転嫁は禁物
      • 側からの見た目を気にしすぎず、自チームの問題にも目を向ける
    • 人に好かれたいのはやまやまだが、管理者は優しさよりも親切を旨とすべし
      • 昇進にはまだ早いと判断した部下がいたら正直に伝えて支援するのが親切
        • 気休めをいうのはただの優しさ
    • 恐れずに勇気を出して
      • 対立を避ける気持ちは恐怖から生まれる
    • 我が身を振り返る
      • 対立を恐れる気持ちを克服する秘訣
  • やりにくい仕事／チームの結束を乱す人への対処
    • 心理的安全性を作る
      • 人として扱い、プライベートな話もする
      • チームに馴染む人材を採用する
    • ブリリアントジャーク
      • 非常に有能だが自己中心的で周囲を攻撃する人
      • 変わることを望んでいない人を変えるのは土台無理
      • 好ましくない言動は断固、公然と否定する
        • 叱るのは1対1で、の例外
        • チーム全体に有害であると判断された場合のみ
          • 自身に向けられた場合は1対1で
        • あくまで冷静に
    • 秘密主義者
      • 隠し事をし、レビューなど必要な協力を得ない人
      • 期待されている職務をこなせていないと明言しても良い
      • 根元には恐怖心が隠れている
        • 力不足がバレる、興味のない作業を振られる、など
      • 恐怖心の元を探る
        • レビューが辛辣すぎるなど
        • チームの文化を変えさせるか、配転するかどちらが良いか考える
    • 無礼者
      • 本当にこのチームで働きたいか聞いてみる
        • 働きたいなら期待値を伝える
        • そうでないなら異動を
  • 管理者が担当すべき、より専門的なプロジェクト管理
    • 管理者は大局的な計画と進捗の管理
      • 短期的な目標はチーム主導によるアジャイル型手法が有効
    • システムの持続可能性維持に2割割く
      • 本筋で遅れが出た時に振り分けることも可能
    • 納期間近の立ち回り
      • 期限を優先してスコープを狭めるか伸ばしてでも実現するか
      • 本当に期限内に完成させなければならないものをチームと共に厳選しなければならない
    • 即席の見積もりには倍増ルールを適用
    • 長期的作業の見積もりには立案のための時間を要求する
    • チームメンバーに見積もりを頼むなら厳選して
      • ただでさえ忙しいメンバーの気を散らさないように
  • コラム：小さなチームの新米の管理者
    • チームのプロセスを深く理解して技術的信頼を得る
    • 適任者を見つけてシステム、アーキテクチャ、テスト、リリース手順を説明してもらう
    • 現場作業に加わって経験してみる
 
複数のチームの管理
  • 現場の勘所を維持する方法
    • これまでやってきた分野でレビュワーなどの形で関わり続ける
    • 週に半日は創造的な活動に時間を使う
      • 技術ブログ、カンファでの発表、OSSへの参加など
  • 時間の管理
 
 
緊急でない
緊急
重要
必須。時間を作る
明らかにやるべきこと
重要でない
明らかに回避するべきこと
ついつい注目しがちな「気の散る要因」
  • 重要性よりも緊急性にインパクトを感じがち
    • メールやチャットで流れ込んでくる情報や依頼
    • それほど重要でないことに時間を使ってしまう
  • 重要だが緊急ではないこと
    • 効率的なミーティングのための準備
    • 将来を考える、計画する、焦点の当てどころを見直すこと
  • 緊急だが重要でないこと
    • 出る必要が明らかにないミーティング
    • ミーティングで参加者の様子を確かめる
      • 集中していない人が多い場合は浪費的なものになっている
  • 意思決定と委任
    • 一度に回さなければならない皿の数が多すぎる場合の委任という秘訣
 
 
頻繁
頻繁でない
単純
委任
自分でやる
複雑
（慎重に）委任
訓練目的で委任
  • 複雑な仕事を委任して後任やチームを強化
    • 頻繁でない：評価の要約を書く、人材募集の計画を立てる
    • 頻繁：プロジェクト計画立案、システムデザイン、障害復旧のまとめ役
    • チームに不可欠な仕事を管理者なしにできるように
      • やり方を完璧に知ってるのが自分だけの仕事をリストアップ
  • 委任により空いた時間を新しく楽しい仕事に当てられる
  • やりにくい仕事／「ノー」にも言い方がある
    • はい、それでですね
      • 肯定しつつも限界と実情を伝える
      • 優先度を見据えた現実的な交渉に持ち込む
    • ポリシーを決めておく
      • 管理者からイエスを引き出すための要件をメンバーに理解させる
    • 私にイエスと言わせてみて
      • １回限りの判断で明確なポリシーがない場合
      • 疑わしい部分に突っ込んだ質問を重ねる
      • 相手が甘さに気づくことも、斬新なアイディアで驚かせてくれることも
      • 好奇心を持って質問することでノーと言いやすくなり教育ともなる
    • 時間や予算を盾にとる、今すぐは無理
      • 後日、真剣に考える
    • 手を組む
      • チームのために権限を行使してあげる
      • 関係部署長に後押ししてもらう、悪者になってもらう／なる
    • ズルズルべったりは禁物
      • ノーを先伸ばさない
      • ノーが速合点であれば素直に謝る
      • 全てにおいて調査分析して判断する余裕はない
  • コードの作成以外のITスキル
    • 会社から求められている職務をきちんと把握しているか
      • どのようなコードを書くべきかを把握している
    • 自分の職務を遂行する上で必要な機器やツールを持っているか
      • ツール、自動化、プロセスが用意されている
    • 毎日最高の仕事ができる機会を得られているか
      • インシデントに忙殺されずにコードが書けている
  • 直属の開発チームの健全性を見極める
    • コードのリリース頻度
      • 問題を抱えているのに無視していないか
      • 頻度を上げるための技術的チャレンジの指揮をとる責任がある
    • コードへのチェックインの頻度
      • 作業が細分化されテストコードを書くプロセスになっているか
    • インシデントの発生頻度
      • 対処するだけでなく発生件数を減らすことに取り組んでいるか
      • 予防を重視しすぎてもベストではない
  • 「イングループ」を作りたがる上司とチームプレイを重んじる上司
    • イングループ：愛着や忠誠心で所属意識を持つ集団
      • 自分たちが特別な存在という優越感でアイデンティティを確立してしまう問題
        • 会社の目標より優越意識に目が向いてしまう
      • リーダーを失うと脆さが露呈
        • 排他的なチーム
      • 外部の考えやアイディアに聞く耳を持たない
        • 成長の機会を逸する
        • 優秀なメンバーが会社を去る
          • 車内のベストなグループにいるのに面白くないと思い込む
      • 帝国を構築する
        • 組織全体にとっての最善に目が向かない
      • 柔軟性に欠ける
        • 外部から命じられることを逆風と受け止める
    • チームプレイを重んじる上司
      • 全社の目標や文化を土台とし、強く永続性のある協調関係を構築したチームを作る
      • リーダーやメンバーが辞めてもすぐに立ち直れるチーム
        • 全社レベルの目標を基盤としているため人が辞めても針路を見失うことがない
      • 目標駆動型のチーム
        • 達成に有用なことを出どこに構わず取り入れる
      • 部長クラスの同僚こそがチーム
        • 直属のチームだけに目を向けない
        • 会社全体のニーズに配慮した意思決定を下すことができる
      • 目標達成に役立つ変化を喜んで受け入れる
  • 無精と短期の効用
    • チームが進めている仕事の効率が悪いと感じたらすぐに自問する
    • 合計所要時間を減らして同レベルの価値を会社にもたらすことを考える
      • 労働時間を増やすのではない
    • 帰宅できるよう集中して仕事をする、せざるを得なくなる文化を
 
複数の管理者の管理
  • 各チームの健康度に目を光らせ、目標設定を支援する
    • 人材募集
    • メンバーのコーチング／育成
    • 目標のレビュー
    • プロジェクトの状態
    • インシデントの事後検証と報告
  • スキップレベルミーティング
    • 各チームの健全度や焦点の絞り方を把握する
      • 上層部への立ち回りが上手い管理者で見えない問題を察知する
    • ２つ上の上司に質問できる機会が生まれる
    • 重要なトピックに水を向け部下から話を引き出す
    • 部下のための面談であることを示唆
    • 質問例
      • 今担当しているプロジェクトで最高／最悪だと思う点は？
      • 自分のチームで特に素晴らしい動きをしているのは誰？
      • 直属の上司に何かフィードバックは？
      • 担当している製品にどんな改良ができるか
      • 我々が見落としていると思われるチャンスは？
      • うちの部の活動についてどう思うか？改善、増強、削減できるところは？
      • 社の経営戦略でピンとこないところは？
      • あなたが持ち味を出し切れてない理由は？
      • この会社で働くことに満足しているか？
      • この会社で働くことの満足度を上げるために我々ができることは？
  • 部下である管理者たちに責任を課する
    • 管理者たちが各自きちんと職責を果たし、上位の管理者が務めを果たしやすくする
    • 管理者はチームの健全性と生産性に関する責任を負っている
      • ロードマップが安定しないならプロダクト部門と調整を
      • テックリードが本筋から外れていたら方向修正と支援を
      • 火消しに追われていたら火事の原因に対処するための計画と支援の要請を
    • 管理者の後ろ盾となって解決策の模索や実施を助ける
  • ノーと言える管理者とイエスマン
      • 問題が発生してもチームに知らせず外界から切り離すように守ろうとする
      • メンバーのスキルアップよりも日々業務を進めることを重視する
      • 機嫌を損ねると顔に出る
      • 依頼されると断れないがどれも捗らない
      • チーム内外にイエスと言ってしまい混乱を招く
      • 社内で起きている問題を知っているが自ら対処しない
    • イエスマンのタイプ
      • 自分のチームにノーと言えない
        • 実行不可能な約束によりチームを失敗に陥れる
      • 外面がよく問題を外部に明かさない
        • 部下との気まずい対話が苦手
        • 管理者自身が失敗を恐れるためチームが失敗を糧にして成長できない
    • イエスマンへの対処
      • イエスばかり言うことがチームにとって問題であることを自覚してもらう
        • 人に喜んでもらいたい気持ちは褒める
      • 意思決定を一人で背負い込まないで良いプロセスを考える
        • 有力なパートナーをつける
        • アジャイルプロセスで計画立案をチームに委ねる
  • 新任管理者の管理
    • スキップMTGで管理者が指導を要する領域を突き止める
      • キャリアパスの提示ができているか
      • 昇進を見据えた支援をしているか
      • 仕事は委譲できているか
    • マイクロマネージャー／仕切りたがり屋
      • 手に入れた権限に固執し厳しく管理しすぎる
      • メンバーは決定権がないことへストレス
      • 権力を奪われまいとして報告しない
    • 人選
      • まずは小規模なチームを任せて見極めるのが理想
      • 人選ミスに気づいても管理職に止めるのは重大なミス
    • 社内外の研修も勧める
  • ベテラン管理者の管理
    • 最初の難題は統括するチーム全体の文化に合う人物かどうか確認すること
      • 文化的な相性で妥協してはいけない
    • 自分なりのフィードバックを遠慮してはならない
      • 管理という仕事に対する捉え方の違いを埋める必要がある
    • 自分が最良だと思うチーム文化を直属の管理者が尊重できるように計らう必要がある
      • 透明性の高い運営を望むなら情報共有の場を
      • アイディア模索を奨励するならそのための時間確保の支持を
    • ベテランは管理の仕事そのものは独力でできる
      • 担当分野における戦略策定と方向付けに関するコーチングが多くなる
      • 自分の職務のうちどれをベテランに異常できるか検討する
  • チーム管理者の中途採用
    • 今求めているスキルの有無を確かめる
      • 模擬1on1でどのような質問で部下に考えさせFBするか
        • 悪い評価をFBするなどやりにくい場面をどうさばくか
      • 管理経験を訪ねる
        • プロジェクト遅延時
        • 退職希望者との面談
        • 優秀な部下の昇進をどう支援したか
      • 自身の経営（組織管理）哲学について語ってもらう
        • 現場の状況をどう把握するのか
        • 委任はどうやるのか
      • プレゼン能力を見る
      • 技術スキルを見る
    • 組織の文化にあっているかを見る
      • スタートアップ→大企業のケース
      • 大企業→スタートアップのケース
        • 上下フラットな関係の中でのコミュニケーション
        • 形式ばらず迅速／柔軟に進められるか
      • まずは自分が自社の価値観をしっかり理解する
      • 身元照会
        • 前職の上司同僚に勤務状況を問合せる
  • 自分が疎い分野のチームの管理
    • 自分をメンティーに見立ててどんどん質問する
    • 新任の仕事を理解して真価をよく認められることを目的として
    • 勝手知ったる分野よりも時間をかける必要がある
  • 機能不全に陥った組織のデバッグの基本
    • 仮説を立てる
      • うまくやっているように見えるが退職者が多い、など
    • データ（事実）をチェックする
      • チャットやメール、コードレビューの内容
      • MTGの量、1on1の有無
    • チームを観察する
      • チームに悪影響を及ぼすかもしれないがMTGに参加する
        • 活気はあるか、みんな発言しているか、公平か
        • 準備は十分か、頻度は適切か
      • ただし参加することでチームの振る舞いが変わる可能性もある
    • 質問をする
      • チームが目標は何か、理由は何かを把握しているか
      • メンバーが意思決定に関与してなければそれは何故か
    • チームの人間関係をチェックする
    • 支援に乗り出す
      • 問題のあるチームの管理者だけの責任にしない
    • 常に好奇心を失わない
      • なぜ？と究明することを繰り返して育っていく
  • 期日の見積もりと調整
    • 技術部長は見積もりに関して強気に通すのが鉄則
      • 見積もりのプロセスに関する交渉も務め
    • 見積もりの誤りから学ぶ
      • 見逃していた複雑性
      • 見積もる価値のある事柄
      • 見積もりの伝え方、遅延した時の対処
    • なんでこんなにかかるのかという質問
      • 相手の状況を理解し共感することで理解を得られることも
    • 最終的にはスコープ縮小の判断と責任を負うことも
  • やりにくい仕事：ロードマップにまつわる不確実性への対処
    • 変化は必ず発生しメンバーからの不満をぶつけられる
    • その中で、技術的負債に対処する時間をどう捻出するか
    • 会社の成長に合わせて方向転換の可能性を受け止める
      • 半年で終わらない作業をチームに確約するのを避ける
    • ある程度の結果を出せる単位に細分化する
      • その時々で最大価値に焦点を絞って再検討を繰り返す
    • そのうちやる、と安請け合いしない
      • 重要なら直近でスケジュールに乗せる
    • 2割をメンテナンスに割り振る
    • 技術プロジェクトであっても重要性を見極める
      • 規模、価値、完遂後のチームにとっての意味、KPI
    • 変化にチームが意欲的になるよう取り計らう
      • これまで取り組んできた仕事を仕上げる時間を確保する
      • 計画立案の初期に関与させる
      • 理由と目標を理解させる
  • 技術力の点で時代遅れにならないためには
    • 技術的投資の監督
      • チームから提案された技術要素に目を光らせる
    • 情報収集のための質問
    • 技術と事業のトレードオフと分析
      • 事業に予想外の影響を与えそうなら懸念を表明できるように
      • 事業目標を把握しどの技術プロジェクトで達成できるか助言できるように
    • 上層部とチームの間の伝言役にならないように
      • ただ要求されたことをやるだけでなく、より高次の目標の達成を可能とする方法を模索する
    • 技術的な感を磨くための取り組み
      • 時々でも自分たちのシステムのコードを読む
      • その領域に詳しいエンジニアに解説を仰ぐ
      • 障害の振り返りに参加する
        • 自分が当然と思うことがなされていないことも
      • 開発プロセスに関する業界のトレンドを把握する
      • 社外でも技術系の人脈づくりを
 
経営幹部
  • 技術系の幹部として
    • 絶えず変化を続けるテクノロジーの世界でキャリアを積んできたものならではの責任を担う
      • 変化を受け入れ非効率を改善し変化を組織へ導入する媒介となる
      • 望ましい変化を実現できる組織を生み出す
    • 素養
      • 情報が揃わない中での難しい決断と責任を負う覚悟
      • 自社の事業の把握と将来を想定し計画する能力
      • 組織を強化する管理体制を敷くことの価値への理解
      • 事業を前進させるために建設的な駆け引きをする能力
      • 非技術系の同僚たちとも協力して仕事を進める能力
      • 皆の決断に違を唱える能力
      • 同意できなくても決定された事項を尊重し結果を出す能力
      • 個々の部下、部課に対して責任を課し、責任を問う能力
    • 4つの職務（High Output Managementより）
      • 情報の収集・共有
        • 会議、メール、1on1などにより様々な意見に耳を傾ける
        • 情報を素早く集め、選り分け、第三者に理解可能な方法で共有する
      • 注意喚起
        • 質問することにより相手に責任事項を想起させる
        • 質問を投げかけて注意を喚起し組織の脱線を防ぐ
      • 意思決定
        • 管理者の仕事の中でも一際労力のいる気苦労の絶えない仕事
        • 気の進まない場面でも最良の模範を示す
  • 技術系の経営幹部の肩書と役割
    • 研究開発
      • 開発チームとは別に技術戦略に関わる職権や新たなアイディアを掘り起こす役割を果たす
    • 技術戦略・ビジョナリー
      • 技術戦略と製品開発を結びつける役割
      • 業界や技術の動向に基づいて意思決定を導く
    • 組織化
      • 組織構造、要員計画立案、配置にも責任を持つ
    • 執行
      • 通常、組織化と兼任し各部署の職務執行に関する責任を負う
      • 各部署のロードマップの連携、作業の計画立案、広範な事業の調整を支援
      • プロジェクトの優先順位付け、進行の妨げの除去、意思決定も
    • 技術部門の対外的な「顔」
      • ソフトウェア製品を販売しようとする際の顔
      • クライアントとの会合への出席やカンファレンスなどでの講演なども
    • 社内の技術インフラとその運用
      • 会社の成長段階において経費、セキュリティ、規模拡大などに焦点を当てる
    • 事業化
      • 事業そのものに焦点
    • これらをいくつか組み合わせ、兼任しCTO、VP、CIOなどの役割を果たす
  • 技術担当バイスプレジデントとは？
    • 人員、プロジェクト、チーム、部課の事情に精通したベテラン管理者として期待される
    • 企業の成長に伴い戦略志向の度合いを務め組織管理を部課長に任せる傾向にある
    • 技術担当VP1名のみの企業における仕事
      • 作業工程を把握し下位の作業完遂を促す影響力を持つ
      • CTOがより広範な戦略と社内での技術部門の位置付けに、VPがアイディアの実現にそれぞれ焦点を絞るのが一般的
      • ロードマップ実現のための採用計画・活動の責任を担う
      • 既存の優秀な人材の発掘や人事部と連携した人材開発も
    • 組織をよく知り作業状況を素早く把握し人的・技術的信頼もあることが求められるポストであり、外から入れるのは困難
    • 組織戦略に対する全責任を負うことも少なくない
      • プロダクトチームとも緊密に連携
      • ロードマップ、事業目標が技術部門にとって達成可能な目標の中にあるか目を光らせる
  • CTOとは？
    • 技術系（エンジニアの延長上）の役職ではない
      • 経営幹部たるべき、エンジニアであることは2の次
    • その会社が現在の成長段階で必要としている戦略的技術系幹部
      • 戦略的：長期的視点に立って、事業の未来と、それを可能にする要素とを計画する作業を支援する仕事
      • 幹部：戦略的な思考の成果を実現、運用可能にする作業を支援
      • CTOが採用など人的管理に焦点を当てているのであれば、それが現時点でその会社の技術チームの最重要事項だから
    • 何よりも事業戦略に関わる仕事を優先すべし
  • コラム：CTOと技術担当VPの区別
    • CTO向き
      • 仲間と起業したい
      • アーキテクチャの監督や展開のプロセスや指針の策定を支援したい
      • 事業サイドについても深く理解したい
      • 対外的なイベント、売り込みを担当したい
      • 経営幹部やシニアエンジニアの募集を担当したい
      • 直属の部下を持たないシニアエンジニアの管理に関わりたい
    • 技術担当VP向き
      • 人を管理する仕事が好き
      • 技術的プロセスの効率アップが好き
      • チームの作業を対局で見て優先度付けに関わりたい
      • 組織の構造に関心がある
      • PDMとの協業が得意
      • 焦点を技術的詳細からチーム全体の能率に移すことに抵抗ない
      • アーキテクチャのレビューよりロードマップの立案に参加したい
  • 優先順位の変更
    • 最優先事項の変更は訪れる
      • あなた自身が最優先を理解しているか
      • チームは理解しているか、伝えられているか
      • 割り込ませるか否かの判断ができるだけの現場理解をしているか
      • 割り込ませる前に完遂すべき作業を上層部に伝えられているか
    • 重要事項を相手の意識に刻み込む工夫を
      • 下にも上にも方法や回数を多めに
      • 予想される質問の準備
      • 進路変更が好ましいものである点を売り込むことも
      • 3回繰り返すことで真剣に受け止め出す傾向
    • 上層部へは常時先を見越した形で知らせることが求められる
      • 最優先事項は十分理解しておりチームにも徹底している
      • 取り掛かるべく現場で進めている具体的な対応策も知らせる
  • 戦略の策定
    • 広範な調査と熟慮
      • 技術チームに「ペインポイントはどこか」
      • 経営幹部に「将来我が社のどの領域が伸びると期待するか」
      • 自分自身もに問い掛け、近い将来の変化を予想する
    • 調査の結果と自分なりのアイデアの紐付け
      • 調査、熟慮、推測、手に入れたデータからアイデアへ
    • 技術戦略の草案作り
      • 会社の組織構造、顧客にニーズ、起こりうる将来的な展開も考え合わせて
    • 経営陣特有の流儀
      • 将来を見越したアイデア
      • 講演用とは違う事前に目を通すための情報満載のスライド
      • 抑えるべきツボを抑える
    • 完全でない情報に基づいて将来を予測する作業に慣れなければならない
      • この視点により目指すべきビジョンが提示できるように
  • やりにくい仕事／悪いニュースを伝える
    • 大きなグループに血の通わないメッセージを一斉送信するのは禁物
      • 詳細は背景をきちんと説明してあげる人がその場にいないと誤解や恨みを生じる恐れが大きく
      • 全員を一堂に集めて知らせるのは2番目に悪いやりかた
    • できる限り個別に話す
      • 相手に反応したり質問したりするチャンスも
      • 大規模な部署に知らせなければいけない場合はまず管理者たちに詳しく説明し各チームに
    • 言語道断だと思うようなメッセージなら代役を立てても構わない
      • 全部1人でやらなければならないわけではない
    • その悪いニュースが招きそうな事態を直視する
      • 現実を直視して部下と腹蔵なく話し合う姿勢を貫く
    • 自分ならどのように告げて欲しいのか、想像してみる
  • コラム：非技術系の上司に手を焼いています
    • 専門用語の連発で煙に巻くのは禁物
    • 1on1はこちらが用意周到に
    • 問題を持ち込むのではなく、解決策を提案する方向で
    • アドバイスを仰ぐ
      • 相手への敬意を表す方法
    • 重要なことなら遠慮せずに2度3度念を押す
    • 支援を惜しまない
      • 他にお役に立てることは？
    • 積極的な自己研鑽を
      • 経営幹部としては新米、上は大ボスのみ
  • 他部門を統率する幹部仲間
    • 幹部仲間こそがチーム、全社レベルの成功に照準を
    • 部門の枠を超えた協業ができている状態
      • 仲間の縄張りを荒らさず、仲間もあなたの縄張りを荒らさない
        • 幹部仲間の専門分野を尊重する場面では敬意を表する
      • 根本レベルの信頼
        • 畑の異なる相手とはカルチャーショックが起きがち
          • 分析思考型の人
          • 創造・直感型の人
          • 迅速性や変化を重視する人
          • 長期計画や納期、予算にこだわる人
        • 相手の流儀を理解し信頼するための努力と工夫が欠かせない
          • 非技術系幹部にわかるように言葉を選ぶ、など
          • 相手を尊重すべき局面でつまづくのは、エンジニアこそ誰よりも頭の冴えた人種という思い込みによるものがある
      • 「ここだけの話」の手法
        • 幹部間の衝突を外で持ち出さず、決定事項に対して幹部全員が共同戦線を張る
        • トップレベルでは共同歩調を取るか辞職するか選ぶしかないような状況も
  • 反響
    • もはやチームの一員ではなく、今のあなたのチームは首脳陣となる
    • 直属の技術部門チームと距離を置くべき
      • 結びつきが強すぎると特別扱いせずにはいられなくなる
      • 会社を引っ張る立場として部下たちが本気で耳を傾ける関係を構築する必要がある
        • 発言が仲間のものなのかトップからの命令なのか混乱させてはいけない
      • 幹部レベルの心配事や不満を不用意に打ち明けることはチームの安定性を揺るがす有害な要因に
    • 距離を置くコツは、自分が関わる職務対象を慎重に選ぶこと
      • チームの意思決定の場に入ってしまうと多大な影響を与えてしまう
    • チームの一員でなくともメンバーそれぞれを生きた人間として気にかけることをやめてはいけない
      • 距離を置くことに成功すると社員を歯車として見られなくなる危険性も高まる
      • 社員のロールモデルとして
        • どのような手本を示して後継者を育てたいか
        • 会社にどのような文化や伝統を残したいか
  • 恐怖で支配する上司と信頼を基盤に置く上司
    • 恐怖の文化
      • 部下たちは失敗の責任を問われたり人前で批判されるのを嫌ってリスクを冒さない方向へ、失敗を隠す方向へ、というチーム文化を生み出す
      • 自己組織化するチームに育てるには、リスクを承知で賭けに出るようなメンバーが必要
      • オープンに議論できた関係も、あなたが幹部になることで一変し、相手が萎縮してしまう事態も
    • 恐怖の文化を改めるには
      • 心を通わせる習慣を
        • 兆候の一つは部下を人間扱いしようとしない傾向
        • 心理的安全性を座右の銘とすべき
        • 何気ないやりとりで徐々に相互理解が成り立つ
      • 謝る
        • ミスをしたら率直、簡潔に謝る
          • 長々と謝るとかえって言い訳がましく
        • 謝罪の目的
          • 自身が悪影響を及ぼしたことを認める
          • 間違いを犯しても大丈夫だが、人の感情を害したら謝罪が必要ということを教えるロールモデルになる
          • 謝罪しても立場が弱くなるわけではなく、チームが強くなることもあることを示す
      • 好奇心を持って
        • あることに同意できなくても糾弾するのは禁物
          • 非難された側は心を閉ざしていく
        • さらなる情報を引き出そうと手間暇かけて質問する
          • 理解不足による過剰反応に過ぎなかったと判明するケースも
          • 率直に質問することでチームはその事柄を別の角度から見る視点を明かしてくれる
      • 部下を悪者にせずに責任を取らせるコツを身につける
        • チームがしくじった場合は責任を問うのも役目だが、途中に様々な要件がある
          • 成功の度合いを測る基準は？
          • 成功に必須の能力をチームは備えているか
          • 過程で上司のフィードバックを与えるべきか
        • それらを明確にした上で最善を尽くしてもダメだった場合には、責任を問うにしても個人攻撃とはならないように
    • 恐怖の文化は技術系の世界では割とよくあるが、他のことがスムーズな環境だと見過ごされがち
      • 他に問題が生じた時に乗り越えられない
      • 信頼の文化の構築には手間暇かかるがそれだけの価値がある
  • True North
    • 「その部門で真に卓越した手腕がどのようなものか、その基準値を自ら示す」役割のこと
      • 管理者が職務を果たす上で外してはならない勘所
      • ※目指すべき基準そのもののようにも読める
    • 製品部門の幹部
      • まず顧客とニーズに配慮すること
      • 測定と実験を可能な限り徹底させること
      • チームが定めた目標に沿わないプロジェクトを先送りすること、など
      • 数字に注意を払うこと
      • そうした数字が会社に有利に働く運用方法を見極めること
      • 想定外の出費がないよう注意すること
      • チームが予算超過のリスクに直面した場合、チームにそれを認識させること、など
    • 技術部門の幹部
      • チームに製品をデザインさせ、リリース可能な状態にまで仕上げさせること
      • レビュー、運用、テストにおいて、合意済みの方針を尊重すること
      • 顧客に体験してもらえる状態に達していないと判断した要素はリリースしないこと
      • 誇りにできるようなソフトウェアやシステムを作り出すこと、など
    • 技術系幹部が設定に寄与すべきトゥルーノースはリスク分析を駆使する
      • 例えば一定の状況下では可となるリスク
        • SPOFがある状態
        • 既知のバグや問題点がある状態
        • 高負荷が許容できない状態
        • データの喪失
        • テスト中のコードの公開
        • 作業の進捗が悪い状態
      • 量産段階では慎重に勘案すべき事項
        • その点への注意を喚起してくれるのがトゥルーノース
    • 前者レベルでは緊張関係の要因ともなり得る
      • 製品部門では生産の支援よりも顧客体験を
      • 財務部門は可用性よりも全社的なインフラコストを
      • あらゆる部門のリスクに配慮せざるを得なくなる、健全な緊張関係
    • トゥルーノースを熟慮することで自分の権限とその範囲に対する理解を深められる
      • 技術系幹部の例
      • 意思決定の際に評価基準となる指針を定める
        • 現場でどう運用するかは部門の管理者に任せる
 
文化の構築
  • チームに文化を明示し、以後も常に配慮を怠らない
    • スタートアップ文化と構造や工程の話
      • 構造は作業の遅れやイノベーションの障害と見なされる
      • 成功も失敗もひっくるめて学習し、成功例や教訓を共有することが組織の安定化、規模拡大に欠かせない
    • 構造の価値
      • 規模を拡大し、多角化し、複雑な長期の仕事をいかに進めるか、といった仕組みや筋書きに他ならない
  • 自分の役割の見極め
    • 舵取りをしている乗り物の大きさの見定め
      • 社員数
        • 多くなれば全体を正しい方向へ引っ張る組織構造が必要になる
        • 現場が目標を設定するボトムアップ型の意思決定が多くなっているが、目標の設定と周知を円滑に行える構造画筆よう
      • 創業からの年数
        • 長いほど定着している慣行習慣が多く今後も存続する可能性が高まる
      • 既存のインフラの規模
        • ビジネスルール（顧客への請求金額の設定方法など）やインフラが多いほどその扱いを明確化する必要性が高まる
      • リスク許容度
        • 業界の規制なども会社の構造とプロセスに反映されているべき
    • 不都合の生じ始めが組織構造の修正箇所の見極めの機会
      • キャリアパスが規定されていないことで人材を逃し始めれば策定を検討することになる
    • 当時はリスクが大きいと考えられていたが今ややらないとリスクになること
      • リリース頻度
    • 構造の欠陥による不具合の例
      • 新人の受け入れに多くの工数がかかる
      • キャリアラダーが確立されていないため人が辞めていく
      • DBに誰かが直接アクセスして障害が発生することを繰り返す
  • 会社や担当部署の文化の創成
    • 組織文化
      • 企業文化は存在し重要だが理解していない人が多い
      • リーダーが注意を怠ればあっという間に懸念事項となり得る
    • 文化とは
      • あるコミュニティで共有されている暗黙のルール
      • 構成員全員が同じ価値観を有するわけではないが、行動規範のように作用する
      • 複雑な状況では接着剤の役割を果たし、先行き不透明な状況に陥っても一致団結して判断を下すことができる
    • 会社のコアバリューに自分の重視する事柄がどれだけ重なるかで、会社に溶け込む際の努力の程度が決まる
  • コアバリューの活用
    • 第1に、担当部署の文化を定義すること
      • 会社がすでに価値観を打ち出していればそれをチームに当てはめてみる
      • 独自の価値観を足したりチームにしっくり来るように言い換えたり
      • 例
        • 多様性の尊重
        • 学びの文化
    • 第2に、会社やチームの価値観をプラスの形で体現している社員を褒めることによって文化を強調する
      • 組織文化の周知徹底という点では勤務評価も有用
        • 重視している価値観を勤務評価の柱の一つにすることがポイント
        • 価値観が合わない部下を見抜くコツも身につけるべき
    • 第3に、コアバリューを採用面接のプロセスに組み込む
      • 面接担当者に価値観を再確認させ、面接時に積極的に探るように指示する
      • 友人として好ましく思える人だけを雇っても強力なチーム作りには繋がらない
  • 文化に関するポリシーの策定
    • オープンソースの雛形や他の会社のものを参考にすることでゼロから作る負荷を減らすことはできる
    • が、ある会社で成功したポリシーが別の会社でも成功するとは限らない
  • キャリアラダー作成のコツ
    • チームのメンバーにも応援を仰ぐ
      • シニアエンジニアに求められるスキルについてはトップエンジニアに検討してもらうなど
    • 実例をさらに集める
      • 自社より規模の大きい会社のものなど多角的に参考にする
    • 細部の表現を大切に
      • やる気を引き出し、過不足なく、社風や実情に合った解説文
      • あるランクで欠員が1人でて、新規採用にするか、それとも誰かを昇進させるか、判断を迫られている、という状況を想定し、その際に目安にするであろう詳細な基準をあげてみて、それを適切な表現でまとめると良い
    • 詳細な説明と要約とを併用する
      • 表形式で、昇格に伴う変化を段階を追って容易に把握できる簡易バージョン
      • 各ランクについてもの画たちの形で詳細を補う詳細バージョン
    • ラダーと給与の関連性を考える
    • キャリアの初期段階では昇進の機会を増やす
      • 初期段階では頻繁な昇給が期待される
    • キャリアの初期段階では給与の幅は狭くする
    • ランク数の少ないそうでは給与幅を広くする
      • ランク間のスキルの差が明確になる
      • 上下のランクの給与幅を重ならせる
        • 今のランクでかなり成績をあげているが次のランクの責任を追わせるのにはまだ早い、という状況でも優遇できる
    • ブレークポイントに当たるランクの設定も検討する
      • そのランクに達すれば以後昇進しなくても期待される成果を出しさえすればクビにならないというランク
      • これから先は昇進が難しくなる境目
    • 実績報酬の手段としても
    • 途中で管理系と技術系のパスを分ける
    • 人的管理のスキルを中堅社員の必須要件にするという選択肢も
    • 経験年数を条件とする場合は慎重に
    • ラダーは常に見直される
  • 職能の枠を超えたチーム
    • 管理は職能ごと、作業はチームごと
    • 職能の枠を超えた製品チーム、専門チームそれぞれ状況に応じて
      • 一丸となって一つの製品を生み出す目的
      • 革新的、先端的な技術を生み出す目的
  • 作業プロセス
    • 作業プロセスが皆無だと規模拡大で苦労
    • チームに合わない作業プロセスは作業停滞を招く
    • 作業プロセスはリスク管理
      • みんなで連携を軸にプロセスを確立し、リスクが誰の目にも見えるように
      • リスクが低い、明らかな作業のプロセスはシンプルに
      • メンバーか完全に従わなくても価値の得られるプロセスを
        • 変更やリスクをチーム全体で共有
  • 意思決定のプロセスから個人的要素を排除する
    • コードレビュー
      • 期待できる効果を理解しておく
        • バグが見つかるのはテスト
        • コメントやドキュメントのアップデートし損ない
        • 関連する機能への変更追加のし損ない
        • 修正追加されたコードへの不適切なテスト
      • コーディングスタイルの問題にはLintで対処
        • つまらぬ粗探しや非難に発展しがち
      • 未処理分のレビューリクエストに常に目を光らせる
        • レビューリクエストの件数に上限を設けるなど
        • 各自が担当作業を確実にこなせるように考える
    • 稼働停止（トラブル）の事後検証
      • 犯人を名指しし問い詰めたい気持ちは押しとどめる
        • メンバーが失敗を恐れるようになる
      • インシデントをめぐる状況を吟味し、経緯や背景を把握する
        • 学習のための検証となるように
      • 事後検証の成果は現実的な視点で取捨選択する
        • リストアップされたものすべてには対処できない
        • ハイリスクで再発する可能性高いものにまず絞る
      • 大きな変更について関連グループ内で共有しリスクを明確にしておく目的
        • 新しいシステム／言語を使いこなせる人が何人いるか
        • 訓練／教育のプロセスは
        • 使用上の注意点は
      • レビューの対象としてふさわしいのはどのような変更かを明確に
        • 言語、FW、ストレージ、ツールなど
        • 日常的な作業の前に負担の大きなプロセスを設けないように
      • レビューの価値はその準備段階にある
        • リクエストする人は理由を深く考えざるを得ない
          • 考えてなかったリスクに気づくことができる
      • レビューの担当者はよく考えて選ぶ
        • 変更で一番影響な受けそうな人たちを都度当てるのが望ましい
          • 管理者が全ての意思決定の責任を負わなくても済む
          • 関与すべき人たちがその意思決定の評価に加われるように
        • 無関係な人から反対されるほどやる気の削がれる事はない