正しいだけでは通らない:社内政治を「利害の地図」に変える作法【第4回】
技術的には正しい提案が、会議で5分で消える。あとで聞くと、別の会議室で決まっていた。この記事を読み終えると、「社内政治」を避けるべき汚いものではなく、読める構造として捉え、決定に関わる人を地図にし、提案を相手の言葉に翻訳できるようになります。理不尽との付き合い方シリーズ(全8回)の第4回です。
⚠️ このシリーズの事例について
各回に登場する職場のストーリーは、Reddit(r/ExperiencedDevs、r/cscareerquestions 等)・Hacker News・X(旧Twitter)で繰り返し共有されている体験談をモデルに、人物・企業・時期・数値を置き換えて脚色したフィクションです。一方、検証セクションで扱う研究・歴史的事例(OpenAIの2023年の経営騒動、ノキアの事例研究など)は公開情報で確認できる実在の出来事であり、参考文献に原典を示しています。
🎯 テーマの主役:「社内政治」——水ではなく、流れを見る
今回の主役は社内政治です。一言で言えば、社内政治とは、複数の利害を持つ人が、限られた資源(予算・人員・時間・評価)を取り合いながら意思決定を行う仕組みです。
日常の例えで言うなら、川です。あなたは泳ぎが得意かもしれません。しかし川では、泳ぎの技術より流れの読み方が生死を分けます。流れに逆らって泳ぐ人、流れに乗る人、流れの外に岩があるのを知っている人。技術的に正しい提案は、「速く泳ぐこと」です。それだけでは、流れの強い場所では進みません。
ここで大切なのは、「川」に悪意はないという点です。上流には上流の事情があり、支流には支流の水があります。それらが合流して、あなたの意志とは関係なく流れが決まる。だから川を攻めても意味がありません。読むべきは、水がどこから来て、どこへ向かっているかです。
政治という言葉に抵抗がある人のために、定義をはっきりさせておきます。 この記事で「政治」と呼ぶのは、次の3つです。第一に、決定権が誰にあるかを把握すること。第二に、それぞれの人が何を評価されているかを知ること。第三に、公開の場で決める前に、関係者に話を通しておくこと。これは操作でも根回しの悪用でもなく、合意形成の手順です。人を蹴落とす技術は、この記事では扱いません。扱うのは提案を通す技術です。
動機:会議で5分で消えた提案
※以下は、Reddit の r/ExperiencedDevs や r/cscareerquestions で繰り返し共有されてきた体験談をモデルにした脚色(フィクション)です。実在の個人・企業ではありません。
エンジニアGは、ある決済システムの設計上の欠陥を見つけました。データの整合性が崩れる可能性があり、放置すると数か月後に手作業での修正が必要になる種類の問題でした。Gは2週間かけて調査し、原因を特定し、修正案を3つ用意し、影響範囲を表にまとめました。
定例会議の議題に上げてもらいました。Gの説明は15分。図も表も準備しました。説明が終わると、部長が言いました。「なるほど。ただ、今期は新規機能の開発が最優先だから、これは来期に検討しよう」。
会議は5分でその議題を終えました。Gは納得できませんでした。技術的には明らかに間違っていることを、なぜ先送りにするのか。Gは「技術者が軽んじられている」と感じました。
3か月後、Gの予測どおり、データの整合性が崩れ、手作業での修正に延べ40時間がかかりました。Gは「だから言ったのに」と思いました。そして、その後の会議でGの意見は、以前より通らなくなっていました。Gの指摘が正しかったにもかかわらず、です。
このとき、Gは2つのことを誤解していました。 第一に、部長は技術的に間違っていることを理解していなかったわけではありません。部長は、「今期の新規機能」と「来期の整合性リスク」を、同じ土俵で比較していたのです。この比較には、技術的正しさではなく、損得の計算が使われます。第二に、Gの提案には「いつ、誰が、いくらで直すか」が書かれていませんでした。技術的には3つの案がありましたが、組織にとっての選択肢にはなっていなかったのです。
この記事の仮説はこうです。提案が通るかどうかは、提案の正しさではなく、提案が「決定者の評価指標」に翻訳されているかどうかで決まる。 もしこれが正しければ、技術的な正しさを磨くだけでなく、翻訳という作業を加えることで、同じ提案の通過率が変わります。
🔍 検証①:政治に「悪意」は必要ない——3つの構造的理由
社内政治と聞くと、権謀術数や派閥抗争を想像するかもしれません。しかし、政治が発生する理由は3つあり、どれも人格と無関係です。
| 理由 | 内容 | 起きること | 理論的な裏付け |
|---|---|---|---|
| 資源の有限性 | 予算・人員・時間は無限ではない | 誰かが取れば、誰かが取れない。必ず競合する | 資源依存理論(Pfeffer & Salancik 1978) |
| 利害の多元性 | 部門ごとに「良い」の意味が違う | 同じ事実から、違う結論が出る。どちらも合理的 | 組織を「連合体」とみなす見方(Cyert & March 1963) |
| 情報と認知の限界 | 人は全部の情報を処理できない | 自分の見える範囲で判断する。見えない問題は優先されない | 限定合理性(Simon 1947) |
3つ目が最も見落とされます。 部長は「間違っている」と判断したのではなく、「見えなかった」のです。あなたの提案は、部長の視界に入っていなかった。だから、政治の仕事の第一歩は、権力者に取り入ることではなく、自分の提案を相手の視界に入れることになります。
そして、この構造を踏まえると、「政治は汚い」という前提を捨てる必要があります。政治は、複数の利害を持つ人たちが資源を配分するための手続きです。手続きを無視して「正しさ」だけを持ち込むのは、交通ルールを無視して「まっすぐ進みたい」と言うのに似ています。まっすぐ進むことは正しいですが、交差点では信号に従わないと進めません。
🔍 検証②:決定に関わる5種類の人——地図を作る
政治の第一歩は、誰が決定に関わるかを知ることです。これを「ステークホルダーマップ」と呼びます。決定に関わる人は、5種類に分かれます。
| 役割 | 何をする人か | 見つけ方 | アプローチ |
|---|---|---|---|
| 決定者 | 最終的に「やる/やらない」を決める | 「予算は誰の承認が必要か」を辿る | 決定に必要な材料(コスト・効果・リスク)を渡す |
| 影響者 | 決定者の判断に強い影響を持つ | 「決定者は誰に相談するか」を聞く | 懸念を先に聞き、提案に反映する |
| 情報保持者 | 判断に必要な事実を持っている | 過去の経緯を知っている人を辿る | 事実を集める。味方にする必要はない |
| 実行者 | 決まった後に手を動かす人 | 自分のチーム、隣接チーム、運用担当 | 早い段階で巻き込む。後から知らせると協力が得られない |
| 影響を受ける人 | 決定によって損をする人 | 「誰の仕事が変わるか」を想像する | 損を補う案を添える。無視すると必ず抵抗される |
5番目を忘れると、提案は静かに殺されます。 「影響を受ける人」は、会議の場にいないことが多い(運用担当、他部署、顧客など)ので、あなたの提案には登場しません。しかし、その人が後から抵抗すると、決定は覆ります。だから提案の段階で、「この決定で誰が損をするか」を1行書く習慣が効きます。
🔍 検証③:ポジションとインタレスト——氷山の下を読む
交渉論の古典(Fisher & Ury, Getting to Yes, 1981)に、「ポジション」と「インタレスト」という区別があります。ポジションは「相手が要求していること」、インタレストは「相手が本当に気にしていること」です。
たとえば、隣のチームが「この機能はうちのチームで実装したい」と主張したとします。これがポジションです。インタレストは、「今年の評価に関わる成果が欲しい」「過去に他所のチームに実装されて痛い目を見た」「自分たちの設計方針を守りたい」など、複数あり得ます。ポジションは1つですが、インタレストは複数あり、満たし方も複数あります。
| 場面 | ポジション(言っていること) | インタレスト(本当の関心) | 可能になる合意 |
|---|---|---|---|
| 実装チームの争い | 「うちのチームで実装する」 | 今年の成果が欲しい/設計方針を守りたい | あなたが実装し、相手が設計レビューと露出の場を持つ |
| リリース日の争い | 「金曜にリリースしたい」 | 顧客への約束を守りたい/週末を空けたい | 木曜リリース+翌週月曜の監視体制で合意 |
| 技術選定の争い | 「この技術は使いたくない」 | 過去に運用で失敗した経験がある | 失敗した原因を回避する条件を設計に明記する |
ポジションで交渉すると、勝つか負けるかになります。インタレストで交渉すると、第三の案が生まれます。 そしてインタレストを聞き出す最良の方法は、「なぜそう考えているのですか」と一度だけ聞くことです。これは尋問ではなく、敬意です。「その意見には理由があるはずだ」と扱うことです。
🔍 検証④:翻訳——あなたの言語から、相手の評価指標へ
政治で最も実務的な技術が翻訳です。あなたが話す言葉と、決定者が評価されている指標は、多くの場合まったく別の言語です。翻訳せずに持ち込むと、「正しいが、今は関係ない」と言われます。
| 相手 | 評価されている指標 | あなたの技術的な主張 | 翻訳した言い方 |
|---|---|---|---|
| 営業責任者 | 受注額・顧客満足 | データ整合性の欠陥がある | この欠陥が顧客に見つかると、契約更新の判断に影響します。修正は2人週です |
| 経理・管理部門 | コスト・予算の遵守 | 設計が古くて保守に時間がかかる | 今の設計のままだと、保守に毎月40時間かかります。改善すれば20時間に減ります |
| カスタマーサポート | 問い合わせ件数・対応時間 | エラー時のメッセージが不親切 | この改善で、月に80件ある問い合わせのうち30件が減る見込みです |
| 開発責任者 | リリース数・障害件数 | テストが足りていない | この2週間でテストを足すと、来期の障害対応が3割減る見込みです |
| 経営層 | 売上・成長・リスク | 技術的負債が溜まっている | 放置すると、3年後に機能追加の速度が半分になります(比較的事例あり) |
この表の使い方は、相手を騙すことではありません。 あなたの提案が相手にとって何の意味を持つかを、正直に言い換えることです。もし言い換えた結果、相手にとって意味がないなら、それはまだ提案の順番が早いという情報になります。それも重要な発見です。
🔍 検証⑤:根回しは「悪」か——公開の場で初見にしない
「根回し」は日本では悪い意味で語られがちですが、本来の機能は「会議で初めて対立しないための準備」です。欧米の実務書では、これは「プレ・ミーティング」「ソーシャル・プロセス」などと呼ばれ、推奨される手順として扱われます。
根回しの目的は3つです。第一に、相手の懸念を事前に知る(会議で反対されると、あなたは反論の準備ができないが、事前なら設計に反映できる)。第二に、提案の弱い部分を直す。第三に、相手に「自分の意見が反映された」という共同所有感を持たせる。
「会議で初めて出す」は、実は最も失礼な方法です。相手は、その場で判断を強いられます。事前に何も知らされていなければ、「持ち帰ります」と言うしかない。つまり、あなたの提案は自動的に先送りになります。会議の場で「検討します」と言われた提案の多くは、根回しが足りなかった提案です。
| 段階 | やること | 言い方の例 | 得られるもの |
|---|---|---|---|
| 1. 情報を集める | 過去の経緯を知っている人に聞く | 「この部分の経緯を教えてもらえますか」 | 提案の前提が正しいかの確認 |
| 2. 懸念を聞く | 反対しそうな人に先に聞く | 「この案の問題点はどこだと思いますか」 | 会議での反対を、設計の改善に変える |
| 3. 弱い案を捨てる | 聞いた懸念を提案に反映する | 「指摘を踏まえて、案をこう変えました」 | 提案の質が上がる。相手が味方になる |
| 4. 決定者に予告する | 決定者に「次回こう提案します」と伝える | 「来週の会議で1件提案します。要点は3つです」 | 決定者が心の準備をできる |
| 5. 会議で正式提案 | 賛同者も同席の場で出す | — | 会議が「反対の場」ではなく「確定の場」になる |
結果:提案が通る5つの条件
ここまでを、提案の形式に畳みます。「正しい提案」と「通る提案」の差は、次の5項目です。
| # | 条件 | 書くべき内容 | 欠けたときの症状 |
|---|---|---|---|
| 1 | 決定者が明確 | 誰が決めるのか。決裁の単位は何か | 「検討します」のまま宙に浮く |
| 2 | 相手の指標に翻訳されている | 受注・コスト・問い合わせ・障害数など、相手の言葉で | 「今は関係ない」と言われる |
| 3 | 選択肢がある | 案A/案B/案Cと、それぞれのコストと効果 | 「やる/やらない」の二択になり、先送りされる |
| 4 | 損をする人が書かれている | 誰の仕事が増えるか。どう補うか | 決定後に静かに覆される |
| 5 | 期限がある | いつまでに決めれば、何が間に合うか | 「来期に検討」で永久に来ない |
5番目の「期限」は、理不尽への最も実用的な防御です。 「来期に検討」を防ぐには、「いつまでに決めれば、どうなるか」を数字で示すしかありません。「このままだと、◯月に手作業の修正が必要になり、そのときは40時間かかります。今なら8時間です」。決定を先送りすることのコストを明示すると、先送りは「判断」ではなく「選択」になります。第3回で扱った「値札を付ける」と、同じ技術です。
考察:政治は「使う技術」ではなく「読む技術」である
この記事の内容を、「政治をうまくやる術」と読むこともできます。しかし、本当に伝えたいのは逆です。
第1回で確認した通り、情報の非対称は構造です。決定者は現場の事情を知らず、現場は決定の理由を知りません。この非対称を放置すると、組織は「正しい情報を持っているのに間違った判断をする」状態になります。ノキアの事例研究(Vuori & Huy 2016)は、恐怖の雰囲気が情報の流れを止め、経営層が現実を見失ったプロセスを詳細に描いています。つまり、政治が機能不全になると、組織そのものが壊れます。
だから、あなたが政治を「読む」ことは、自分のためだけでなく、組織が正しく判断するための情報提供でもあります。翻訳して、選択肢を付けて、損をする人を明示して提案する。これは、最も誠実な政治参加の形です。そしてこの行動は、第5回で扱うハラスメントへの防御とも直結します。情報を流し、記録を残す人が、最も守られるからです。
📌 注目ポイント
第一に、政治が発生する理由は資源の有限性・利害の多元性・認知の限界の3つであり、どれも人格と無関係であること。第二に、決定に関わる人は5種類(決定者・影響者・情報保持者・実行者・影響を受ける人)おり、5番目が最も忘れられること。第三に、ポジション(言っていること)ではなくインタレスト(本当の関心)で交渉すると、第三の案が生まれること。第四に、技術的な主張は、相手の評価指標に翻訳しないと届かないこと。第五に、会議で初見に出すと、自動的に先送りになる。根回しは失礼の回避であり、提案の質を上げる工程です。
💡 活用事例①(脚色):正しかったのに、通らなかった2週間
※Reddit や Hacker News で繰り返し共有されてきた複数の体験談をモデルにした脚色(フィクション)です。
Hさんは、社内の問い合わせ管理ツールの改修を担当していました。ある日、Hさんは検索機能の設計が破綻していることに気づきました。データ量が増えると検索が10秒以上かかるようになり、その先は使い物にならなくなります。Hさんは2週間かけて調査し、修正案を3つ作り、定例会議で45分使って説明しました。
結果は、「いまは優先度が下がる。来期に検討」。Hさんは落ち込みました。
転機は、その後の「雑談」でした。 Hさんは、その会議に出ていたカスタマーサポートのリーダーに、廊下で聞きました。「あの提案、サポートの立場だとどう見えますか」。リーダーは答えました。「正直、いまは別のことで困っている。問い合わせの1件あたりの対応時間が今期の目標で、そこに効かないと上には言いにくい」。
Hさんは翌週、同じ提案を書き直しました。変えたのは中身ではなく、冒頭の3行です。「データ量が増えると検索に10秒以上かかるようになり、サポートが顧客と画面を共有しながら操作する場面で待ち時間が発生します。対応時間を1件あたり平均2分短縮できる見込みです(現在の検索400件/月で試算)。来期の改修では、データ移行が必要になり工数が3倍になります」。
この提案は、1回の会議で通りました。 技術的な内容は、1文字も変わっていません。変わったのは、「誰の、何の数字に効くか」が最初に書かれたことです。
Hさんは後にこう言っています。「2週間かけた調査は無駄じゃなかった。無駄だったのは、調査の結果を技術の言葉でしか書かなかったこと。同じ調査を、サポートさんの言葉でもう一度書くだけで、3週間が1日になった」。
💡 活用事例②(実在):OpenAIの2023年11月——決定権が誰にあるかで組織が割れた
2023年11月17日、OpenAIの取締役会は、当時CEOだったサム・アルトマンの解任を発表しました。理由として、取締役会は「CEOとのコミュニケーションに一貫して誠実さを欠く点があった」と説明しています。
この発表の直後、会社のほぼ全従業員が、取締役会に対してアルトマンの復帰を求める書簡に署名しました。数日後、マイクロソフトがアルトマンと他の共同創業者グレッグ・ブロックマンを迎え入れると発表し、さらに数日後、アルトマンはOpenAIのCEOに復帰しました。取締役会の一部は交代しました。
この一連の出来事は、「決定権を持つ人」と「実行する人」が分離したときに何が起きるかの、極めて明瞭な事例です。
| 観点 | OpenAIの2023年11月に起きたこと | 理不尽の型で読むと何が見えるか |
|---|---|---|
| 形式的な決定権 | 取締役会にあった(解任を決定) | 組織図の上の権限は、常に実効的とは限らない |
| 実効的な決定権 | 従業員・投資家・パートナー企業の側にあった | 「去られると困る人」が持つ力が、形の上の権限を上回った |
| 情報の非対称 | 取締役会の一部は日常業務に関与していなかったと報じられた | 決定に必要な情報を持たない人が決定すると、数日で覆る |
| 結果 | 5日間でCEOが復帰し、取締役会の構成が変わった | 決定権は「名目」と「実効」の2層に分かれている |
この事例から持ち帰れる教訓は2つです。 第一に、「誰が決定権を持っているか」は、組織図を見ても分からないこと。組織図に書かれた権限と、実際に決定を動かせる力は別物です。第二に、決定の実効性は、実行者が動くかどうかで測れること。実行する人が動かなければ、決定は決定になりません。ジュニアエンジニアの立場でも、あなたが「これは現実的でない」と静かに止める力は、決定の実効性に対する検証として意味を持ちます。
✅ 要点まとめ
政治は才能ではなく、手順と記録で扱えるものです。次の提案を出す前に、この一覧を確認してください。
- 政治は汚いものではなく、資源の有限性・利害の多元性・認知の限界から生まれる構造である。
- 決定者は組織図では分からない。名目上の権限と、実効的な力は2層ある(OpenAIの事例)。
- 決定に関わる人は5種類。決定者・影響者・情報保持者・実行者・影響を受ける人。最後が最も忘れられる。
- ポジション(言っていること)ではなくインタレスト(本当の関心)を聞く。第三の案はそこから生まれる。
- 技術的主張は相手の評価指標に翻訳する。翻訳できないなら、提案の順番が早い。
- 会議で初見に出すと自動的に先送りになる。根回しは提案の質を上げる工程である。
- 通る提案の5条件は決定者・翻訳・選択肢・損をする人・期限。
- 先送りのコストを数字で示すと、先送りは判断から選択に変わる。
- 経済の変化ではなく、情報を流すことが最も誠実な政治参加であり、最大の自己防衛である。
🚀 取り込み方:明日から使う3段階
今日(15分でできること):自分が今取り組んでいるタスクについて、決定者を1人、名前で書き出してください。「誰の承認が必要か」「誰に相談するか」を、役職ではなく個人名で書きます。名前が出てこないなら、それが今いちばんの問題です。第1回の「決定権は誰か」を、具体的な人名に落とす作業です。
今週(小さく試すこと):手元の提案を1つ選び、冒頭の3行だけを書き直します。技術的な説明の前に、「誰の、何の数字に、どう効くか」を書いてください。中身は変えません。相手の反応が変わるかを観察します。「今は関係ない」が「もう少し詳しく聞かせて」に変わったら、翻訳が効いた証拠です。
今月(仕組みにすること):自分が関わるテーマについて、利害関係者の一覧を1枚作ってください。5列(決定者・影響者・情報保持者・実行者・影響を受ける人)で、それぞれ個人名と「その人が評価されている指標」を書きます。この1枚は、あなたが転職するまで使えます。人が異動するたびに更新してください。更新のたびに、あなたの組織理解は深くなります。
🔥 ハマりポイント
その1:「政治なんてやりたくない」と距離を置く。 距離を置いても、政治はあなたを避けてくれません。決定はあなた抜きで進み、あなたの作業に降ってきます。政治を「読む」ことは、参加するかしないかの選択ではありません。読まないという選択は、他の人に全部を決められるという選択です。
その2:正しさで押し切ろうとする。 技術的正しさは、決定者の判断材料の一部です。決定者は、予算・期限・他部署との関係・自分の評価を含めた総合判断をします。正しさだけを強調すると、「この人は全体を見ていない」という評価になります。第3回の「ついで」と同じで、見えていないものが議論から抜け落ちます。
その3:根回しを「陰口」や「根回しの悪用」と混同する。 根回しの目的は、相手の懸念を聞いて提案を良くすることです。相手を飛ばして味方だけを増やすのは、別の行為(派閥づくり)であり、長期的にはあなたの信用を削ります。「反対しそうな人に最初に聞く」——これが根回しの最も健全な形です。
その4:「あの人は技術が分かっていない」と結論する。 この結論を出すと、あなたはその人から学ぶ機会を失います。そして多くの場合、その人は別の何かの専門家です。決定者が見ているもの(契約、顧客、法規制、予算、政治的文脈)は、あなたには見えていません。「何を評価されている人か」を推測するほうが、はるかに実用的です。
🔄 比較:政治への4つの構えと、その代償
| 構え | 行動 | 短期的な結果 | 長期的な結果 |
|---|---|---|---|
| 無関心 | 技術だけに集中する | 目の前の作業に集中できる | 重要な決定から排除される。雑務が増える |
| 対立 | 「上は分かっていない」と反発する | 正しいことを言った満足感 | 情報が来なくなる。評価が下がる |
| 迎合 | 上層の意向だけを追う | 評価が上がることがある | 技術的な判断力を失う。現場から信頼されない |
| 設計(翻訳と記録) | 利害の地図を作り、相手の言葉に翻訳して提案する | 手間がかかる。効果は1〜2か月で出る | 決定の質が上がり、あなたが情報の結節点になる |
4つ目の構えの最大の副産物は、「情報の結節点になる」ことです。 利害の地図を作り、翻訳して提案する人は、組織の中で情報が集まる場所になります。これは役職とは無関係に発生します。そして、第6回で扱う「評価」は、この結節点にいる人に対して発生しやすくなります。
📅 今後の展望:リモート時代の政治
リモートワークと分散チームの普及で、政治の様子は変わりましたが、構造は変わっていません。変わったのは、情報が流れる経路です。
オフィスでは、廊下・ランチ・喫煙所といった非公式の場が、情報の重要な経路でした。リモートでは、この経路が消えました。代わりに、チャットの雑談チャンネル、1on1、小さな定例が経路になります。つまり、意識的に作らなければ経路が存在しない状態です。
これはジュニアエンジニアにとって、不利にも有利にも働きます。不利な面は、自然に情報が入ってこなくなること。「なんとなく聞いた」が発生しません。有利な面は、情報の経路を自分で作れば、誰よりも早く把握できることです。具体的には、関係者に15分の1on1を依頼する、決定が行われる会議の議事録を読む、チャットで「これってどうなりましたか」と聞く——どれも、オフィスでは自然にできていたことです。
これからの政治リテラシーは、「視界に入ること」を待つのではなく、「自分から視界に入りに行く」技術になると考えられます。
まとめ
技術的に正しい提案が通らないのは、組織が間違っているからではありません。決定者の視界に、正しい情報が入っていないからです。あなたの提案は、決定者の言葉に翻訳され、選択肢として提示され、損をする人が明示され、期限つきで置かれることで、初めて決定の対象になります。
そしてこの作業は、決して「政治の汚い部分」ではありません。むしろ逆です。情報の非対称を埋め、組織が正しく判断できるようにする行為です。正しい情報を持ちながら黙っていることは、あなたを守りません。情報を流し、記録を残し、翻訳して届ける人が、最も長く生き残ります。
ここまで読んだあなたは、自分の提案について「決定者は誰か」を名前で言えるようになりました。そして、技術的な説明の前に相手の数字を3行で書けるようになりました。それだけで、あなたの提案が消える確率は大きく下がります。
参考文献
- Pfeffer, J. Managing with Power: Politics and Influence in Organizations. Harvard Business School Press, 1992.
- Pfeffer, J., & Salancik, G. R. The External Control of Organizations: A Resource Dependence Perspective. Harper & Row, 1978.
- Pfeffer, J. Power: Why Some People Have It and Others Don’t. HarperBusiness, 2010.
- Cyert, R. M., & March, J. G. A Behavioral Theory of the Firm. Prentice-Hall, 1963.
- Simon, H. A. Administrative Behavior. Macmillan, 1947.
- March, J. G., & Simon, H. A. Organizations. Wiley, 1958.
- Fisher, R., & Ury, W. Getting to Yes: Negotiating Agreement Without Giving In. Houghton Mifflin, 1981.
- Lax, D. A., & Sebenius, J. K. 3-D Negotiation. Harvard Business School Press, 2006.
- Cialdini, R. B. Influence: The Psychology of Persuasion. HarperBusiness, 1984(改訂版 2021).
- Conway, M. E. “How Do Committees Invent?” Datamation, 1968.
- Edmondson, A. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly, 1999.
- Vuori, T. O., & Huy, Q. N. “Distributed Attention and Shared Emotions in the Innovation Process: How Nokia Lost the Smartphone Battle.” Administrative Science Quarterly, 2016.
- Kahneman, D., & Tversky, A. “Prospect Theory: An Analysis of Decision under Risk.” Econometrica, 1979.
- Peter, L. J., & Hull, R. The Peter Principle. William Morrow, 1969.
- The New York Times / Reuters / The Verge 等による OpenAI の2023年11月の経営騒動に関する報道(解任発表 2023年11月17日、復帰 2023年11月21日).
- Rao, V. “The Gervais Principle.” ribbonfarm, 2009. https://www.ribbonfarm.com/
Rui Software