shine-Notes

ゆるふわ思考ダンプ

PdMのつらみに向き合う物語『Aligned』

今回の読書ノートは『Aligned』。原題は "Aligned: Stakeholder Management for Product Leaders”。 そのタイトルの通り、プロダクトマネージャーが避けては通れないステークホルダーマネジメントの話。非常に非常に面白かった。

意外だったのが、本書の半分くらいを占めるビジネス小説部分が予想以上に面白かったことである。ちょっと軽めのTHE UNICORN PROJECTを読んだくらいの読後感が有った。ステークホルダーとAlignedしていくためのプレイブックと並行して、PdMである主人公「アイリーン」がステークホルダーに向き合ってプロダクトマネジメントを進めていく物語が展開される。

あと自分は物理書籍を買ったのだが、ページの色やフォントなどに非常に意図された仕掛けと言うか遊びがあるのも良かった。物理書籍を手に取れる方は是非。

サマリ

本書の構成は「組織」「人」「ラポール」「信頼」「ロードマップ」「変化」「挑戦」の7章+エピローグ。各章でフレームワークやツールの説明があり、それと並行して架空の中堅PdMアイリーンが新しい会社に転職してステークホルダーと奮闘するストーリーが進む。

想定読者はおそらくプロダクトマネジメントに関わる人々…だが、昨今「プロダクトマネジメント」の要素自体がプロジェクトマネジメントにも滲み出ているので、プロジェクトマネジメント関係なく単純にマネジメント本として面白く読めると思う。とはいえ本書はプロダクトマネジメントに関わる人にほど勧められる。

例えば「プロダクトマネージャーのしごと」が刺さった人には、間違いなく2冊目としておすすめできる。自分の2023年のお気に入り本だ。

自分はアイリーンほどの立場ではないにしても、プロダクトマネージャーを数年やっており、中々読んでいてつらい所も多かった。自分の実感としても、コードベースやビジネスが一定のサイズを超えれば、次のボトルネックは、人、というかステークホルダーになる実感を日々感じているからだ。

苦闘するアイリーンの物語

少し物語の話をすると、プロダクトマネージャーとして転職してきたアイリーンを囲むステークホルダーとして、創業者、COOやカスタマーサポート、セールスなどなどが登場する。皆それぞれが違うことを考えていて、そこをアラインしていく過程が物語になっている。とくに物語でアイリーンを最も振り回すステークホルダーは中々に厄介で、物語の後半は殆ど「彼」に振り回されることになる。(ネタバレになるので深くは書かない)

どれだけ理不尽に思えるステークホルダーにも事情がある

自分が感じ入ったのは、本書が一貫して『どれだけ理不尽に見えるステークホルダーにもその人なりの事情がある』姿勢を崩さなかった事だった。何度か「この状況なら諦めてもいいのでは?」と思える場面も出てくるし主人公も退職を考えるのだが、最後までアイリーンはステークホルダーに向き合い、物語は一定の結末を迎えることになる。勿論そのためのノウハウが色々と紹介されるのが本書なのだが、自分は物語の全てに通底する、この他者理解への姿勢が最も共感できたかもしれない。

本書内でも言及が有った気がするが、このあたりは前に読んだ「NVC 人と人との関係にいのちを吹き込む法 新版」に通じるかもしれない。

その他ピックアップ

ここからは本書のプレイブック部分で紹介された内容のうち、留め置きたいものをまとめる。

「アラインメント(Aligned)」の定義(はじめに)

本書におけるアライメントの定義は「全員を思い通りに動かすことではなく、全員がプロセスに関与していると感じ、目指す方向を理解し、プロダクトの成功のために一緒に働くことをコミットすること」とされている。みんなが思い通りに動くわけでもなければ、みんなが欲しいものを全部もらえるわけでもない。でも全員が方向性を理解してコミットしている状態を作ること。ステークホルダーマネジメントとはこのアライメントの状態が取れているかを確認するプロセスでしかない。

→ 当たり前だが「全員が同意している」事を理想としないのがミソだ。いわゆる「Disagree and Commit」と同じ。(この「Disagree and Commit」は、実践しようと思うほど、言うは易しだと思う)

dev.classmethod.jp

専門性と自信と当事者意識(4章:信頼)

信頼されるためには自分の専門性を見せるのが必要なところがある。この時は専門性を語るのではなく見せることが重要。相手の言葉で話して、自分の関連する経験を共有する。

自信とは無根拠に「自分はできる」と思うことではなく、自分の能力を信じること。意思決定をステークホルダーに伝えるときに自信がなさそうだったら、そもそも伝わらない。これは精神論ではなく実務的な話で、自信を示す方法はちゃんと準備をしていること、答えのすべてが揃っていなくてもその透明性を示すこと。裏を返すと、PdMとして「こいつはちゃんと意思決定ができる」と思わせたかったら、それだけの専門性を相手の言葉で話せていて、かつ準備してきたことを示して、わからないことも含めて透明にしている状態が必要。

さらに当事者意識のレベルが3段階で示されている。一番低いレベルが「うまく実行する」、次が「ステークホルダーを巻き込む」、そして最高レベルが「積極的になる」――つまり特に言われなくても必要なことは全部やる。誰かに言われる前に積極的に取り組み始める、問題を他人が見つける前に解決策を提案する。

→ 正直自分はこの全部ができているか?を一番考えてしまった章だった。特に「当事者意識」は「うまく実行する」「ステークホルダーを巻き込む」でも日々のタスクは進められてしまう。自分は積極的になれているだろうか。

相手のモロさを受け止める(3章:ラポール)

相手が話している中で自分の間違いを見つけたとき、その間違いを責めるのではなく受け止めてあげるとよい。相手のモロさを受け止めてあげると、「この人ならモロさを出しても大丈夫だ」と相手に思ってもらえる。そして自分が先にモロさを見せると、相手も見せやすくなる。

→ 良い言語化だと思った。ちょうど「失敗できる組織」で似たような話を聞いた所だった。

パワーアライメントグリッド(1章:組織)

レポートラインの組織図は影響力の組織図ではない。組織図ではわかりづらいが実際に影響力を持っているパワープレイヤーは往々にしている。権力×アライメントの4象限(パワーアライメントグリッド)で整理したとき、権力は強いがアライメントが弱い「要注意者」を協力者にいかに引き込むか。

有効な対策としては、自分のプロダクトをパワープレイヤーの成功に関連づけるか、パワープレイヤーを自分のプロセスに引き込むのが効果的。(例えば意思決定の途中で素直に意見を伺ってみると、意外とあっさり仲間になってくれることもある)。

→ わかる。特に相手のインセンティブを把握したうえで「自分のプロセスに引き込む」のは経験上、効果的だと思っている。

DACIモデル(1章:組織)

意思決定文化には指示型・民主型・参加型・コンセンサス型の4種類があり、プロダクトマネジメントに推奨されているのは参加型。その参加型を回すためのモデルとしてDACIが紹介されている。Driver(推進者)、Approver(承認者)、Contributors(貢献者)、Informed(通知対象者)の4つの役割で、ポイントは推進者と承認者は1人ずつにすべきということ。

→ わかる。これを1人ではなく複数人にすると半端に民主型になって大抵機能しない。

ステークホルダーディスカバリーインタビュー(2章:人)

ステークホルダーとの対話はカスタマーディスカバリーインタビューに非常に似ている、という指摘。聞きたいことは結局、その人がどのように仕事をしているのか、どんなインセンティブがあって、どんな評価をされるのか。

→ わかる。特に「どんなインセンティブがあるのか」は自分も必ず探るようにしている。

退職のフレームワーク(7章:挑戦)

扱いづらいステークホルダーに疲弊したとき、辞めたいから辞めるのではなく、退職すべきか残るべきかを判断するためのフレームワーク。このまま行くと未来で起こりそうなことを考えて、辞めた場合と辞めなかった場合の期待値を計算する。さらに「何月までにこれが起こらなかったら転職活動を開始する」という基準を決める。

→ なかなかよくできている。

以上。また読み返したい良い本だった。

心理的安全性の先の姿を『失敗できる組織』から見る

今回の読書ノートは『失敗できる組織』。 「心理的安全性」という概念を提唱したエイミー・エドモンドソンが、心理的安全性の先に目指す「失敗との向き合い方」を論じた本。とてもおもしろかった。
一方で皆々様否応なく経験しているであろう「失敗」に向き合う本なので中々読んでてつらくなる箇所も多かった。だからこそ面白かった。

原題は "Right Kind of Wrong: The Science of Failing Well”。「正しい失敗」については書籍内でも言及が有るが、本書の提起する失敗の活かし方を考えると、邦訳タイトルにもある「組織」という観点も正しいなと思う。

サマリ

本書は失敗を3つに分類し(賢い失敗・基本的失敗・複雑な失敗)、それぞれに対してどう向き合い、どう学ぶかのフレームワークを提示していく本だ。第一部で失敗の全体像を理解し、第二部で実践的に「上手に失敗する技術」を身につけるという構成になっている。

一番の想定読者はチームや組織をリードする立場の人全般だと思うが、仕事で何かしらの失敗を経験したことがある人なら誰でも刺さる。読んでいて自分の過去の失敗が次々と思い浮かんで胸が痛かった。この「(良い意味で)つらい」読書体験がこの本の一番の価値だと思う。

自分はエンジニアとしてそれなりにキャリアを重ねてきた立場にいるのだが、日々の仕事の中で失敗と向き合う場面は山ほどある。インシデント対応、設計判断のミス、コミュニケーションの齟齬。この本で言われている失敗のパターンに「あー、あれだ」と思い当たるものが必ず出てくるので、読んでいて他人事にならない。

また書籍内の解説にもあるが、この本を読むと所謂「心理的安全性」が、高度な仕事を進めていくうえでの必須の前提条件であることが腹落ちする。心理的安全性は、難しい仕事を達成するために失敗を報告し共有するための前提条件であって、それがないとそもそも失敗が上がってこない。上がってこなければ学習もできないし、難しいことを達成できない。「心理的安全性が確保されていると良いよね」の話ではなく、ないと難しい仕事に立ち行けないのだという切実さが伝わってくる。

メモ

以下、自分が読んだ中で記憶に残った部分のまとめをメモ的に残す。

失敗と失敗が起こるコンテクストの3分類

失敗の3分類

  • 賢い失敗:未知の領域での実験・挑戦から生まれる失敗。新たな知見をもたらし、イノベーションに不可欠
  • 基本的失敗:既知のルールや手順からの逸脱。注意不足・準備不足が原因で、仕組みで予防可能
  • 複雑な失敗:複数の因果が絡み合い予測しづらい状況で発生。システム全体の構造を見直す必要がある

コンテクストの3分類

  • 一貫性コンテクスト(知識が確立された領域)
  • 変動性コンテクスト(状況が都度変わる領域)
  • 新規性コンテクスト(未知の領域)。


この掛け合わせで「今この失敗はどの種類で、どのコンテクストで起きているのか」を整理できる。

失敗から学ぶのが難しい理由(5章)

詳しくは割愛するが、「人間は他者の成功よりも他者の失敗からのほうが多くを学べる」(他者の成功に対しては興味がないし、自分の失敗は冷静に向き合えない)という話が身も蓋もなくて好き。いわゆる「しくじり先生」方式の事例共有がITエンジニアリングの一部では人気だと思っているが、その感覚とも合致していて面白かった。

パーフェクトストーム(4章)とシステム思考(7章)

複数の悪い要素が同時に重なって最悪の事態を引き起こすアクシデント(「パーフェクトストーム」:本書の例だとタンカーの座礁、ダイビング中のスイッチ押し忘れ、ボーイング737MAXの事件など)の話と、リスクを理解するための考え方として「システム思考」というものが出てくる。細かい話はさておき、このあたりの内容を乱暴にまとめれば「複雑系を侮るな」みたいな話だと思う。

いっぽうで読み終わって冷静に考えると、これ自分の仕事でもめっちゃそうだな…と思うし、そもそも現代のホワイトカラー業務の多くは、少なくとも本書で言う「変動性コンテクスト」や「複雑な失敗」と無縁ではいられない。そう考えると、このテーゼで言う「高度じゃない仕事」なんて実際どれほど存在するのか?という気持ちになってしまった。「高度な仕事では心理的安全性のある失敗できる組織が必要」というのが本書のテーゼだが、考えてみるとこのテーゼで言う「高度じゃない仕事」なんて存在するのか?という気持ちになってしまった。

個人的に思ったこと:高度な外科手術とインフラの本番環境作業は少し似ている

これは自分の個人的な発見なのだが、1章以降、本書で繰り返し出てくる外科手術の事例を見ていると、インフラの本番環境作業(それも難易度が高いやつ)を結構思い出した(クラウドインフラでDBマイグレーションとかNW設定変更作業があるやつ)。

  • 事前にある程度の計画は立てるが、実際にやってみると想定外の状況が発生する
  • 一人で完結せず、チームの連携が不可欠
  • リアルタイムで状況を共有し、異変があれば声を上げて止める必要がある

そして、この手の作業が上手くいくかどうかは、割と本書の外科手術の例であげられていたベストプラクティスと相似している。

  1. 事前検証と、その過程で「これはこういう意図でこうしている」を共有するドキュメンテーション
  2. 作業中に異変があったら誰でも止められる
  3. 作業中の状況実況(「今○○のステップを実行します」「△△の値が想定通りです」をリアルタイムで共有)

さらにシステム思考の観点で言えば、複雑なクラウドインフラは本書で言う「相互作用が複雑で結合が緊密」なシステムそのものだ。1つのコンポーネントの変更が予想外のところに波及する。だからこそ「この変更によって他に影響を受けるものはないか」という問いを常に立てる必要があるし、それを一人の頭だけで考えるのではなくチームとしてレビューする仕組みが要る。

この本を読んで、自分がインフラ作業で感じていた「うまくいくチームとそうでないチームの差」に対して、言語化のフレームワークをもらった感覚がある。

以上。また内容を繰り返し思い出したい良書だった。

「プラットフォームエンジニアリング」からプラットフォームのプロダクトマネジメントを考える

今回の読書ノートは『プラットフォームエンジニアリング』。 プラットフォームをサービスとして提供する側として考えるべきことを束ねた書籍。自分は直接のプラットフォーム提供者という訳ではないのだが、面白かった。

サマリ

プラットフォームエンジニアリングを実現するために必要な計画・運用・チーミングについて体系的に触れた本。ここでいうプラットフォームは、社内のエンジニア(本書では「顧客」と呼ばれる)が使う技術プラットフォームのようなものを想定している。

なので、技術的な要素、それを使ってもらうためのユーザーコントロール(というか、プロダクトマネジメント)、社内での立ち回りなど、技術要素が絡むこそからの難しさと対策を語ってくれている。自分は直接の社内プラットフォーム提供者ではなく、ちょっと想定読者から外れるかと思ったが、後述するように意外に他人事ではない気持ちで読むことができた。

プラットフォームをプロダクトとして捉える

自分が一番興味を惹かれたのはこの考え方だった。例えば、プラットフォームにどんな機能をつけていくか、どういうリリースをするか、ステークホルダーの期待にどう応えるか、この辺まんまプロダクトマネジメントである。言われてみればその通りで、顧客から要求される技術要素を束ねるだけのものがプラットフォームというわけではない。プロダクトとしてプラットフォームを見れば、そこには技術要素だけではなく、顧客やステークホルダー、ロードマップが有るわけで、それはプロダクトマネジメントになってくる。

言われてみれば当たり前なのだが、プロダクトマネジメントで常に悩んでいる自分としては意外なところから共通点が得られて、本書を読み進める強い動機になった。

マイグレーション、リアーキテクチャ、シャドウプラットフォーム

色々と要素は出てきており紹介しきれないのが、自分の印象に残ったのはこのあたりだろうか。

マイグレーション

プラットフォームを作ったとして、ユーザー(この本の文脈では社内の開発者)に移行してもらうときに、どこまでのコストを払ってもらうのか。プラットフォーム開発側はマイグレーションコストを軽く見がちで(とても分かる)、これを本書では『ユーザーの変化予算を多く見積もってしまう』というアンチパターンで紹介していたのが面白かった。

シャドウプラットフォーム

プラットフォームが使いづらければ、開発者は自分たちでシャドウプラットフォームを作ってしまう。シャドウプラットフォームに対しては観察しつつ、場合によっては取り込むことまで考えて接しないといけない、というのが中々シビアな観点で良かった。

ちなみにシャドウプラットフォームで好き勝手しようとする例として、データサイエンティストが独自基盤を要求する例が出てきた。元データサイエンティストとして見知ったパターン過ぎて笑ってしまった。

リアーキテクチャ

既存のものを捨ててv2を作るのではなく、飛行機を飛ばしながら修理するような「リアーキテクチャ」を計画的にやっていくアプローチが推奨されていた。プロダクト開発でどちらも経験が有るので非常にわかりみが深い。

ステークホルダー管理

ステークホルダー管理についての内容も、身も蓋もなくてよかった。関心度と影響力の高低でステークホルダーをマッピングして、どう付き合うかを整理する話が出てくる。個人的な体験も加味した解釈だが、結局プラットフォームというのは「社内の予算で社内の顧客に使ってもらう」というファクターがある以上、単一のキーマンではなくステークホルダーを意識せざるを得ない面があると思っていて、本書のステークホルダー管理の整理は、そのあたりの補助線になる内容だった。

また紹介しきれないが、本書が著者が「エンジニアのためのマネジメントキャリアパス」の人だけあって、他にもチーム作りや評価の話など、リアルに組織の中でプラットフォームエンジニアリングチームの存在価値を出していくための話題が多く出てくる。

自分は該当書籍の現実的な語り口(キャリアが上がっていくごとにコードを書く機会を失うことへの付き合い方など)が好きなのだが、そこに通じる書き口を感じる内容も多かった。

個人的な発見:実はB2Bソフトウェアも顧客にとってのプラットフォーム、みたいな要素がある(ので、他人事ではない)

ここからは大いに自分の私見を書く。

著者はいわゆる米国テック企業のキャリアであり、本書をそのまま置き換えて日本のエンジニアが読むなら、事業会社のプラットフォームエンジニアが一番刺さると思う。自分はキャリア上このあたりエアプなのだが、たとえば**社は社内◯penShiftをサービスのデプロイプラットフォームとして内製していた、みたいな話も見聞きしたことが有るので、そういったプラットフォームのエンジニアリングチームは間違いなく本書の読者だと思う。

いっぽうで自分はどちらかというとB2Bのソフトウェアプロダクトを作るキャリアにいるのだが、意外にも他人事でないと感じる内容が散見された。何故かを考えてみたのだが、それは結局B2Bのソフトウェアも(製品にもよるが)顧客のユーザーにとってのプラットフォームとして使われることを目指すからだと思う。顧客企業の中でそのソフトウェアの上に業務フローが積み重なっていけば、バージョンアップのたびに「どこまで顧客に移行コストを払わせるか」というマイグレーションコストは出てくるし、ソフトウェアの機能で実現できない業務を別のソフトウェアで代替する、つまりシャドウプラットフォームにユーザーが移っていくリスクがある。そんな中でユーザーにプラットフォームとして愛されなければ使われ続けない…みたいな悩みどころは、意外にもプラットフォームエンジニアリングの悩みと似ていて、面白かった。というか読んでて(良い意味で)つらかった。

以上。

「冒険する組織のつくりかた」を読み、軍事的世界観からの脱却を考える

今回の読書ノートは『冒険する組織のつくりかた──「軍事的世界観」を抜け出す5つの思考法』。面白かった。

「軍事的世界観」と対比する形で語られる「冒険する組織」という捉え方がわかりやすい。二項対立的で課題認識の取っ掛かりを作りつつ、必ずしもどちらかの軸が正しい訳では無い、という説明の仕方がされるので読みやすい。前に読んだ『両利きのプロジェクトマネジメント』を思い出す瞬間がちょくちょくあった。

続きを読む

現代プロジェクトマネジメントの在り方を「両利きのプロジェクトマネジメント」で再発見する

今回の書籍は「両利きのプロジェクトマネジメント 結果を出しながらメンバーが主体性を取り戻す技術」。さっと読めたが、中々良い書籍だった。

全体所感

面白かった。正直に言えば紹介される手法や思考法は知っているものも多く、自分のようにアジャイル開発やプロダクトマネジメントについて実践に悩んだ経験があれば似たようなノウハウや姿勢には既に辿り着いているのではないだろうか。
一方で本書の魅力は、そういったノウハウが「なぜ必要なのか」著者の実地感覚に基づいて言語化されている所だと思う。

続きを読む

エグゼクティブになる予定はないが『エンジニアリング統括責任者の手引き』が面白かった

今回の読書ノートは『エンジニアリング統括責任者の手引き』。結果的に、今まで読んできた技術書系マネジメント本とは少し異なる視座の書籍で楽しめた。

サマリ

「エンジニアリング**」というジョブタイトルについての書籍は色々と有るが、本書で取り扱うのは「エンジニアリング統括責任者」である。後述するが、一旦はソフトウェアエンジニアリングに関わる組織のロールで最も責任のでかいポジションを想像するとよい。

なので本書の内容はかなり視座が高く、取り扱う内容も意思決定から人事まで幅広い。自分は精々が中堅どころなので内容の全てが即戦力とは言えなかったのだが、それでも有用と感じた内容が予想以上に有った。もうチーミングの本は読み飽きたよ、と思っているような中堅どころに是非勧めたい。キャリアラダーの先にある悩み、自分の上司やその上司が見ている風景を考える切っ掛けになった。あと後半の身も蓋もない困難なテーマの話(M&A、人事評価、ローパフォーマーなど)も好き。

とはいえ「エンジニアリング」「統括責任者」って何よ?

いわゆるCTO、VPoEなどが本書では例に挙げられている。とはいえ日本企業にお勤めの方で、これらのポジション名に必ず馴染みがあるかというと怪しいと思う。だったら本書は日本企業にマッチしないかというと全然そんなことはなく、普通に技術職でなんらかのソフトウェア事業のトップをしている層を想像すれば十分マッチすると思う。

このあたりの翻訳は著者ご自身も苦慮されたようだ。翻訳者の島田さんのBlogご参照。

(前略・リンク先より引用) レビュアーの方々との議論などを経て、最終的に選択したのが「エンジニアリング統括責任者」という訳語になります。耳馴染みがない部分も確かにあるかもしれませんが、自分の仕事を「エンジニアリング統括責任者」だと捉えている方々に本書が届きましたら、訳者としてこの上ない喜びです。

snoozer05.hatenablog.jp

ピックアップ

ここからは自分が面白いと感じた内容をピックアップする。

バリューは変化を開始する手段ではない。進行中の変化を後押しさせるもの(5.1)

大なり小なりチーミングをしようと思うとバリュー(所謂MVVのバリュー)を意識したり定義したりすることが有ると思うが、これは確かにと思った。考えて決めたバリューの文言を地味に感じることも今まであったが「変化を開始するための手段ではない」と思えば頷ける。

これが物議を醸すと感じるなら、個人の生活でどのように当てはまるか考えてほしい。時間厳守を重視すると主張しても、それが真実にはならない。一貫して時間通りに到着することが真実を作るのだ。(5.1 バリューはどんな問題を解決するのか)

統括責任者には複数のリーダシップが必要であり、これらを意識して使い分けたり開発する必要がある(8章)

もう少し噛み砕くと、たとえば「文書で決めたルールの通り、今回はこうします」という意思決定を取るようなリーダーシップ(本書では「ポリシー」のパターン)だけでは駄目で、複数のリーダシップスタイルが必要だし、自分が苦手なリーダシップスタイルは開発しないといけないよ、という話。

自分は例に挙げたようなアンチパターンを自覚して改善するうえで、「リーダシップは複数ある」という捉え方は非常に有用だと感じた。本書でスタイルの例として上がるのは次の通り。()内は自分の噛み砕き。

  • ポリシー(繰り返し発生酢料な意思決定に対して文書化したルールに則って決める)
  • コンセンサス(関係者のコンテキストを総合して決める)
  • 信念(難問に対してできる範囲でコンテキストを集めたうえで、最終的にリーダー自信の信念で決める)

一見とっつきづらいかもしれないが、本書内では著者が「StripeではこうしたしUberではこうした」と実例を挙げてくれるので、思ったよりもすっと理解できる。本書の無二の良さ。

前進するためのエネルギーの管理はポジティブサム。会社>チーム>自分自身フレームワークで動き続けることが最善とは限らない。

会社の意思決定において、考えるべき優先度は『会社>チーム>自分自身』と言われれば、それはそうかも、と思う。ただ本書では「それが一番自分自身やチームが前進するエネルギーになるのか?」という観点が出てくる。

リーダーシップとは、正しい場所にすばやき到達することであり、必ずしも直線的な道を歩むことではない。(9.2 エネルギーの管理はポジティブサム)

具体例が出しづらいが、自分も「方針Aをとるのが会社方針だけど、方針Bで会社に迷惑がかかる訳ではないしチームのやる気は出るよな」みたいな選択肢を見ることが多いので、この言語化は少し救われるものがああった。いっぽうで著者の挙げるルールも忘れないでおきたい。

もちろん、ルールを破るにもルールが要る。 最も重要なのは、自分たちの活力になる仕事が他のチームにう問題を起こさないようにすることだ。(9.2 同)

そもそも人事評価プロセスの参加者(個人、マネージャー、人事、統括責任者)の目的は相反している(22章)

本書は後半に行くにつれて身も蓋もない話題が出てくるのだが、そのあたりで自分が一番気に入ったのは俗かもしれないがこの話だ。ざっくり言えば、

  • 個人:自分の成長のためのFBがほしい。自分の昇進・報酬がほしい。
  • マネージャー:FBは公平にしたい。チーム全体で適切な昇進・報酬を提供したい。あと時間はかけたくない。
  • 人事:会社運営やコンプラ観点で個人が受けるFBを文書化したい。
  • 統括責任者:マネージャーによって一貫してない評価報告をネタに昇進を決めないといけない。報酬は予算を守らないといけないしヤバイ奴を昇進させたらいけない。

言われてみれば当たり前なのだが、確かに人事評価プロセスのステークホルダーは目的が全員少しづつ違う。

企業におけるパフォーマンスや報酬の評価プロセスには、常に改善の余地がたくさんある。一方で、評価プロセスの参加者には相反する目的から生じる緊張関係も存在している。この相反する目的は現実的で、根本的で、避けられないものであり、プロセスの運用方法を決定する際に念頭に置いておく必要がある。(22.1 相反する目的)

他にも好きな話

他にも書き出したい内容が有るのだが、本書は24章+付録5章(付録もいいのだ)と長いのであとはメモ的に書くに留める。気になったら是非本書で読んでほしい。

  • 発表会やデモ会は行うのは、「こういう内容を私達は評価する」という文化形成の効果がある。(10章)
  • 個人や組織が社外に対してプレゼンスを上げるためには、「肯定的な印象を与える発見しやすいコンテンツ」があれば十分だ。かつ不定期で高品質なもので良い。(12章)
  • 統括責任者にとって「同格の同僚」(他の統括責任者)こそがチームだ。(14章)
  • 放置でもなくマイクロマネジメントでもなく「検証を伴う信頼」を(17章)
  • 自分の思う仕事の基準に到達していない他組織のローパフォーマーに対し、その上司やCEOにクレームを入れても事態は解決しない(18章『基準の調整』)

以上。読むのに時間がかかってしまったが良い本だった。