Rui Software理不尽はなぜ起きるのか：怒る前に「型」で切り分ける全体地図【第1回】
納得できない決定が、話し合いではなく力関係で押し切られる。誰も悪意を持っていないのに、なぜか現場だけが損をする。この記事を読み終えると、理不尽を「技術・組織・制度」の3つの型に切り分け、①記録する ②原因を振り分ける ③逃げ道を用意する の3手に変換できるようになります。ジュニアエンジニア向けの全8回シリーズ、その第1回です。
⚠️ このシリーズの事例について
各回に登場する職場のストーリーは、Reddit（r/ExperiencedDevs、r/cscareerquestions 等）・Hacker News・X（旧Twitter）で繰り返し共有されている体験談をモデルに、人物・企業・時期・数値を置き換えて脚色したフィクションです。実在の個人・企業を指すものではなく、特定の体験談の再現でもありません。一方、検証セクションで扱う事故・サポート終了・判例・統計は一次情報で確認できる実在の出来事であり、参考文献に原典を示しています。フィクションと事実を混ぜないことを、このシリーズの約束とします。
🎯 テーマの主役：「理不尽の型」——感情ではなく構造を見る
今回の主役は理不尽の型です。一言で言えば、理不尽の型とは「同じ形で繰り返し現れる、納得できない出来事のパターン」のことです。
日常の例えで言うなら、天気です。急に雨が降ってきたとき、私たちは空に向かって怒りません。「今日は降るらしい」と予報を見て、傘を持ち、どうしても無理なら出かけるのをやめる。天気はこちらを意図的に困らせているわけではなく、こちらの都合とは別の理由で動いているからです。理不尽もこれとよく似ています。誰かがあなたを狙って意地悪をしている場合もありますが、多くの理不尽はあなたとは別の事情で動いている構造から生まれます。構造だと分かれば、天気と同じで、予報・傘・中止判断という対策を用意できます。
この記事で扱う「理不尽」は、次の3つの条件がすべて揃った出来事と定義します。第一に、説明を聞いても納得できないこと。第二に、こちらの努力や正しさでは覆せないこと（力関係や物理法則の問題であること）。第三に、こちらに落ち度がないことです。この3つが揃うと、人は「自分が何かを間違えたのだろうか」と考え始めます。しかし実際には、間違いを探すべき場所は自分の中ではなく、構造の中にあります。
動機：なぜ「正しいのに通らない」が起きるのか
ジュニアエンジニアとして最初に戸惑うのは、技術の問題ではなく「正しさが通らない」という経験かもしれません。テストが通っている。仕様書通りに実装した。レビューも通った。それなのに、リリース直前に「やっぱりこの機能は今回見送り」と決まる。あるいは、障害の原因がはっきり特定できているのに、「表向きは別の理由」で報告書が書かれる。上長の判断で、明らかに不利な技術選定が決まる。
このとき、多くの人は2つの方向に考えます。「自分に説明力が足りなかったのだろうか」と自分を疑うか、「あの人は分かっていない」と相手の人格を疑うか。しかし、この記事の仮説はこうです。
理不尽のほとんどは、個人の人格や能力ではなく、構造から生まれる。構造には型があり、型が分かれば「対策の在庫」を持てる。
もしこれが正しければ、理不尽に遭ったときにすべきことは、反省でも罵倒でもなく、「これはどの型か」を判定し、型ごとに用意された対策を打つことになります。天気が相手なら、晴れるまで待つのではなく、傘を買い、予報を見て、場合によっては外出を取りやめる。この判断ができる人は、理不尽に遭っても消耗が少なくなります。逆に、どんな理不尽も自分の努力不足だと捉える人は、努力では埋められない穴を、自分の体力で埋め続けることになります。
🔍 検証①：「理不尽」と「厳しい」は何が違うのか
最初に、言葉の解像度を上げます。理不尽と似て非なるものに、「厳しい」「不運」「意見の相違」があります。これらを混ぜてしまうと、対策の向きが変わってしまいます。
| 出来事の種類 | 説明を聞けば納得できるか | 努力で覆せるか | 自分に落ち度があるか | 取るべき対策 |
|---|---|---|---|---|
| 厳しい指導・高い要求 | 納得できる（理由がある） | 覆せる（成長で応えられる） | ある（未熟さ） | 素直に受け取り、期限と量を交渉する |
| 不運（事故・災害・景気） | 理由はあるが納得はしにくい | 覆せない | ない | 確率の問題として受け止め、保険をかける |
| 意見の相違 | 立場が違えば納得できる | 説得で覆せることがある | ない（どちらも正しい） | 判断基準をすり合わせ、決定者に持ち上げる |
| 理不尽 | 納得できない | 覆せない（力関係・物理） | ない | 記録し、切り分け、逃げ道を用意する |
この表で重要なのは、理不尽だけが「3つの条件がすべて揃う」という点です。厳しい指導は自分に落ち度があります。不運は誰の落ち度でもありませんが、納得はできなくても理由は理解できます。意見の相違は、決定権を持つ人の判断で決まりますが、努力や説得で動かせる余地があります。
理不尽が精神的に効くのは、「こちらに落ち度がない」のに「自分に原因があるのでは」と考えさせられるからです。だから最初の対策は、技術的なものではなく、「これは理不尽である」と正しく名付けることになります。名付けを間違えると、対策が「努力」に寄り、努力で埋まらない穴に体力を注ぐことになります。
</svg>
🔍 検証②：理不尽の3つの型——どこから来るかで対策が変わる
理不尽は、その発生源によって3つに分かれます。この分類が、このシリーズ全体の背骨になります。
| 型 | 発生源 | 典型例 | 努力で覆せるか | 基本的な対策 |
|---|---|---|---|---|
| 技術の理不尽 | 物理法則・ソフトウェアの寿命・外部仕様 | OSのパッチで動かなくなる／ライブラリのサポート終了／APIの廃止／性能の限界 | 覆せない（迂回はできる） | 期限を先に知る／依存を可視化する／段階的に移す |
| 組織の理不尽 | 人間のインセンティブ・情報の偏り・力関係 | スコープの急な追加／手柄の移動／評価の理不尽／ハラスメント | 部分的に覆せる（合意形成で動く） | 記録する／関係者を増やす／判断の場に持ち上げる |
| 制度の理不尽 | 法規制・契約・予算・市場 | 法令対応のやり直し／予算凍結／取引先の都合による方針転換 | 個人では覆せない | 前提として織り込む／該当箇所を設計で隔離する |
3つの型は、「効く速さ」と「効いている期間」が違います。技術の理不尽は、期限が来た日に一斉に効きます（それまで静かです）。組織の理不尽は、日々じわじわ効きます。制度の理不尽は、ほぼ常時一定の圧力として効き続けます。この違いを意識すると、「今は静かなので大丈夫」が実は一番危ないことが分かります。技術の理不尽は、締切前日まで何の音も立てません。
🔍 検証③：なぜ構造的に起きるのか——4つの非対称
理不尽が「構造から生まれる」と言いました。では、その構造とは具体的に何でしょうか。ここでは4つの非対称を挙げます。
| 非対称 | 内容 | 現場で起きること |
|---|---|---|
| 情報の非対称 | 当事者どうしが持つ情報量が違う | 「なぜその決定になったか」が現場に降りてこない。降りてくるのは結論だけ |
| インセンティブの不一致 | 人によって「得したいもの」が違う | 現場は品質を守りたい。上層は今期の数字を守りたい。どちらも正しい |
| 責任の非対称 | 決める人と痛みを受ける人が違う | 決めた人は痛みを知らず、痛みを受ける人は決められない |
| 力の非対称 | 覆すために必要な力が足りない | 正論は届くが、決定は動かない。正しさと決定権は別物 |
情報の非対称は、経済学では「レモン市場」の問題として古くから知られています。中古車市場で売り手だけが車の状態を知っていると、買い手は疑い深くなり、市場全体が歪む——という議論です（Akerlof 1970）。これを読むと分かるのは、情報の非対称は「悪意の産物」ではなく、構造そのものだということです。売り手が嘘をついていなくても、情報を持っている人が持っていない人より有利になる。だから、理不尽に遭ったときに最初に疑うべきは相手の人格ではなく、「何の情報が、誰に、いつ渡っていないのか」です。
2つ目のインセンティブの不一致も、人格の問題ではありません。会社組織では、経営は今期の利益を、開発は品質を、営業は顧客の要望を最大化しようとします。それぞれの立場で合理的な行動が、全体としては現場の負担になる。これは構造です。ここで「あの部署は敵だ」と捉えると、対策が「対立」に寄り、長期では情報がますます来なくなります。捉えるべきは「この人たちは何で評価されているのか」です。
3つ目の責任の非対称は、理不尽を語るうえで最も重要です。図で確認します。
🔍 検証④：理不尽に遭った直後の3手——記録・切り分け・逃げ道
理不尽の型が分かっても、実際に遭遇している最中は頭が回りません。そこで、遭遇した直後に打つ3手を決めておきます。順番が大切です。
第一に、記録する。感情ではなく事実を書きます。「いつ・どこで・誰が・何を言ったか・自分は何をしたか」。このとき、相手の人格への評価（「横暴だった」）ではなく、再現可能な事実（「14:05の会議で、Aさんが設計変更を口頭で指示した」）を残します。記録は、後で使うかどうかが分からないからこそ、その場で書く必要があります。人間の記憶は、数日で都合よく書き換わります。
第二に、切り分ける。「これは3つの型のどれか」を判定します。技術の理不尽なら期限と影響範囲を調べる。組織の理不尽なら誰のインセンティブと情報が絡んでいるかを確認する。制度の理不尽なら前提として受け入れて、影響を隔離する設計を考える。型の判定を誤ると、対策が空振りします。
第三に、逃げ道を用意する。ここでいう逃げ道は、退職の準備ではありません。「この理不尽が悪化したとき、自分はどう動くか」をあらかじめ1つ決めておくことです。たとえば「これ以上要件が増えたら、期限の延長か作業範囲の縮小を、書面で相談する」「この言動が続いたら、記録を持って相談窓口に行く」。選択肢を1つ持っているだけで、同じ出来事の受け取り方が変わります。心理学的には、コントロール感の回復がストレスの影響を緩和することが知られており、この「逃げ道を用意する」は最も費用対効果の高い対策の1つです。
🔍 検証⑤：理不尽の「効き目」は経験で変わる
ここまでで、理不尽には型があり、対策の3手があることを確認しました。最後に、なぜ同じ理不尽でも、人によって消耗の度合いが違うのかを考えます。
答えはシンプルで、経験とは「対策の在庫」のことだからです。初めて本番障害に遭った人は、何が起きているか分からないまま全力で対応し、終わったあとも数日引きずります。10回目に遭った人は、まず影響範囲を確認し、関係者に連絡を回し、止血してから原因を調べます。同じ出来事でも、在庫のある人にとっては「作業」であり、在庫のない人にとっては「災害」です。
この在庫は、本を読んでも一部しか手に入りません。実際に遭って、記録して、次に備えた人だけが在庫を増やせます。だからこそ、この記事の最初に「記録する」を置きました。記録は、その場を乗り切るためだけでなく、次のあなたが在庫を使えるようにするための投資です。
結果：理不尽に遭遇したときの判定表
ここまでの内容を、実際に使える形に畳みます。理不尽に遭ったとき、次の順で判定します。
| # | 確認すること | 判定の分かれ目 | 次の一手 |
|---|---|---|---|
| 1 | これは理不尽か、厳しい指導か | 説明を聞いて納得できるか。自分に落ち度があるか | 厳しい指導なら、期限と量を交渉する |
| 2 | 型はどれか | 発生源が物理か、人か、制度か | 型ごとの対策に切り替える（第2〜7回） |
| 3 | 期限はあるか | いつ効き始めるか。今日か、3か月後か | 期限があるなら、逆算して予定に入れる |
| 4 | 決定権は誰にあるか | 自分か、上司か、顧客か、法規制か | 決定者に渡す「判断材料」を先に作る |
| 5 | 記録は残っているか | 事実が日付つきで残っているか | その日のうちに書く。後でまとめない |
| 6 | 逃げ道はあるか | 悪化したときの選択肢を1つ言えるか | 言えないなら、それが今いちばんの課題 |
考察：理不尽を「なくす」のではなく「小さくする」
ここまでの話をまとめると、この記事は「理不尽と戦う方法」ではなく、「理不尽に飲まれない方法」を書いています。理不尽をゼロにすることはできません。技術は壊れ、組織は利害で動き、制度は個人の都合を考慮しません。無くせないものを無くそうとすると、必ず消耗します。
代わりにできるのは、影響を小さくする設計です。雨を止めることはできないが、傘を持ち、予報を見て、場合によっては外出を取りやめる。この3つは、すべて事前にできる準備です。理不尽への強さとは、痛みに耐える力ではなく、準備の数だと考えられます。
そして、準備の数は人によって違います。だからこのシリーズでは、第2回以降で型ごとの「準備の作り方」を具体的に見ていきます。技術の理不尽（第2回・第3回）、組織の理不尽（第4回〜第6回）、そして過去の負債という特殊な理不尽（第7回）を扱い、最終回（第8回）で「飲まれないための設計」をまとめます。
📌 注目ポイント
第一に、理不尽は3つの条件（納得できない・覆せない・落ち度がない）で定義できることです。この定義があると、「自分を責めるべきか、対策を打つべきか」の切り替えが速くなります。第二に、理不尽には技術・組織・制度の3つの型があり、型ごとに効く速さと対策が違うことです。第三に、遭遇直後の3手（記録・切り分け・逃げ道）は、その日のうちに打つ必要があることです。特に記録は、後で使うかどうかが分からないからこそ、その日のうちに書きます。第四に、決定権と痛みは分離していること。この分離を埋めるのが、技術力ではなく伝達の設計です。
💡 活用事例①（脚色）：リリース前夜に消えた3か月——SNSで繰り返し語られる型
※以下は、Reddit や Hacker News で繰り返し共有されてきた複数の体験談をモデルにした脚色（フィクション）です。実在の個人・企業ではありません。
中堅のSaaS企業に転職して8か月目のエンジニアAが、3か月がかりで請求機能の作り直しを担当していました。仕様は固まり、テストも通り、リリースは翌日の午前10時に予定されていました。午後8時、Aはまだオフィスにいました。最後の動作確認を終え、リリース手順書を読み返しているところでした。
午後8時17分、マネージャーがSlackでこう書きました。「ごめん、今回の件、上の判断で一旦中止になった。詳細は明日」。
Aはその場で椅子に沈み込み、それから2時間、何が起きたのかを考え続けました。自分が何かを見落としたのか。報告の仕方が悪かったのか。テストが足りなかったのか。実際には、そのどれでもありませんでした。後になって分かったのは、四半期の途中で大口顧客との契約条件が変わり、その顧客に合わせた仕様に作り直す必要が出た、という事情でした。決めたのはAではなく、Aが会ったこともない人の、Aには見えない会議室での判断でした。
Aはその夜、日付・時刻・発言・自分の作業内容を、ノートに3行だけ書き残しました。「20:17／Slack／マネージャーB『上の判断で一旦中止』／リリース準備は完了していた。中止の理由・決定者・再開予定は不明」。怒りは書かず、事実だけを書きました。
3週間後、この3行が効きます。新しい仕様の影響範囲を聞かれたAは、「中止時点でリリース可能な状態だったこと」「決定理由が現場に降りてこなかったこと」を、日付つきで正確に説明できました。Aは自分の記憶を信じるのではなく、記録を根拠に話せたのです。そして何より、Aはこの出来事を「制度の理不尽（顧客契約という自分の外側の事情）」として正しく名付けることができました。名付けができたことで、「自分の実力不足だ」という結論に3週間を費やさずに済んだのです。
この事例の構造を分解するとこうなります。
| 観点 | 起きたこと | 型 | 正しい対策 | やってはいけない対策 |
|---|---|---|---|---|
| 納得できたか | できなかった（理由が降りてこない） | — | 理由を求めるのは正当。ただし「今すぐ」でなくてよい | 理由を求めて関係を消耗させる |
| 覆せたか | 覆せない（顧客契約が上位） | 制度 | 前提として織り込む。契約変更のリスクを先に設計に反映する | 自分の説明努力で覆そうとする |
| Aに落ち度は | なかった | — | 落ち度を探すのをやめ、記録に切り替える | 自分の実装や報告を延々と反省する |
| 情報はどこで | 止まったか | 組織 | 決定理由の共有を、次回の依頼時に条件として添える | 「上は何も分かっていない」と結論する |
| 逃げ道はあったか | 用意してあった | — | 次に中止されたら、他タスクの優先順位を書面で確認する、と決めていた | 何も決めずに「次も耐える」と考える |
このストーリーがSNSで何度も共有され、共感を集めるのは、登場人物が誰も悪くないからです。マネージャーは伝令を務めただけ、上層は顧客契約を守っただけ、Aは正しく働いただけ。それでも現場だけが3か月を失う。これが「理不尽が人格ではなく構造から生まれる」ということの、最も身近な現れです。
💡 活用事例②（実在）：チャレンジャー号——技術的懸念は、なぜ組織に届かなかったのか
1986年1月28日、スペースシャトル・チャレンジャー号は打ち上げから73秒後に空中分解し、7名の乗員が亡くなりました。事故原因は、固体ロケットブースターの接合部にあるOリングという部品が、低温下で弾力性を失い、燃焼ガスを封じ込められなくなったことです。
重要なのは、この懸念が当日の朝、技術者によって指摘されていたことです。前夜の電話会議で、メーカーの技術者は低温での打ち上げに反対しました。しかし議論の末、経営側は打ち上げを承認しました。事故後、大統領委員会（ロジャース委員会）の報告書には、物理学者ファインマンによる付録が添えられ、氷水に浸したOリングが弾力を失う様子が示されています。ファインマンはそこで、「技術を成功させるには、現実が広報より優先されなければならない。自然は騙せない」と書きました。
この事故は、単に「部品の欠陥」ではありません。情報の非対称（現場は懸念を、上層は打ち上げの圧力を抱えていた）と、力の非対称（懸念を述べた側が決定権を持たなかった）が重なった構造的な事故です。社会学者ダイアン・ヴォーンは、この事故を含む一連の判断を分析し、「逸脱の常態化（Normalization of Deviance）」という概念で説明しました。小さな逸脱が繰り返され、それが無害だったために基準が少しずつ緩み、やがて事故につながる——というプロセスです（Vaughan 1996）。理不尽の型で言えば、組織の理不尽が技術の理不尽に転換した瞬間が、この事故だったと言えます。
事例①のAと、この事故の技術者は、同じ位置に立っています。正しい情報を持っているのに、決定権がない。違うのは、Aの場合は損害が「3か月の作業」で済み、チャレンジャーの場合は「7名の命」だったことです。規模は違いますが、構造は同じです。
この2つの事例からジュニアエンジニアが持ち帰れる教訓は、「正しさは自動では通らない」という一点です。懸念は、それが正しいだけでは決定を動かしません。誰に、どのタイミングで、どの形で渡すかが設計されていなければ、正しさは力の前で止まります。これは第4回（社内政治）と第5回（記録）で扱う主題です。
✅ 要点まとめ
この回で持ち帰ることを、実際に使う順に畳みました。「全部覚える」必要はなく、遭遇したときにここへ戻ってくれば済みます。
- 理不尽＝納得できない＋覆せない＋落ち度がないの3条件。厳しい指導・不運・意見の相違と区別する。
- 型は3つ。技術（物理・寿命）／組織（政治・評価・情報）／制度（法・契約・予算）。型ごとに効く速さと対策が違う。
- 構造の正体は4つの非対称。情報・インセンティブ・責任・力。どれも人格の問題ではない。
- 遭遇直後の3手は記録→切り分け→逃げ道。順番があり、その日のうちに打つ。
- 決定権と痛みは分離している。埋めるのは技術力ではなく、判断材料を先に渡す伝達の設計。
- 理不尽はゼロにできない。影響を小さくする準備の数が、強さの正体。
- 経験とは対策の在庫。在庫は「遭って・記録して・次に備えた人」だけが増やせる。
- 正しさは自動では通らない。チャレンジャー号は、組織の理不尽が技術の理不尽に転換した事例である。
🚀 取り込み方：明日から使う3段階
今日（15分でできること）：最近1か月で「納得できなかった出来事」を1つ選び、3条件（納得できない・覆せない・落ち度がない）で判定してください。当てはまらなければ、それは理不尽ではなく別のカテゴリです。当てはまったら、発生源が技術・組織・制度のどれかを書き添えます。これだけで、次に同じことが起きたときの初動が変わります。
今週（小さく試すこと）：出来事の記録用のメモを1つ作ってください。場所は何でも構いません（ノート、テキストファイル、社内のメモ帳）。形式は「日付／場所／関係者／起きたこと／自分がしたこと／次にどうするか」の6項目です。ポイントは、その日のうちに書くことと、人格の評価を書かないことです。
今月（仕組みにすること）：自分の担当範囲について「型ごとの備え」を1枚の表にしてください。技術なら、使っているライブラリとOSのサポート期限を調べて書く（第2回で手順を示します）。組織なら、自分の仕事の決定権が誰にあるかを書く。制度なら、前提になっている契約・規程・予算を書く。この1枚が、理不尽に対するあなたの「防災マップ」になります。
🔥 ハマりポイント
その1：「理不尽」と「厳しい指導」を混同する。 「納得できない」と感じたとき、まず自分に落ち度があるかを確認してください。落ち度があるなら、それは成長の機会です。理不尽として処理すると、自分の改善点が見えなくなります。逆に、落ち度がないのに「自分が未熟だからだ」と捉えると、努力で埋まらない穴に体力を注ぐことになります。判定を誤ると、どちらの方向にも損をします。
その2：記録を「武器」として書いてしまう。 記録を始めた直後は、相手への怒りが文章ににじみます。しかし、感情を書いた記録は読んだ人の信用を落とします。「横暴な言い方をされた」ではなく「14:05に、3名の前で、Aさんが『この機能は明日までに外せ』と述べた」と書く。事実だけが、後で誰に対しても使えます。感情は別の欄に書いて構いませんが、事実の欄には混ぜないでください。
その3：「逃げ道を用意する」を「今すぐ逃げる」と読み替えてしまう。 逃げ道は、使うために用意するのではなく、使えると自分が知っているために用意します。退職の準備を始めた途端、仕事の意味が失われて消耗する人もいます。ですから、最初に決めるのは「いつ実行するか」ではなく、「どんな条件が揃ったら考えるか」です。
🔄 比較：理不尽への3つの構えとその代償
理不尽への構えは、大きく3つに分かれます。どれが正しいというものではなく、何を犠牲にするかの選択です。
| 構え | 行動 | 向いているケース | 代償 |
|---|---|---|---|
| 我慢する | 飲み込んで、仕事を続ける | 期限が近く、今は動く余裕がない短期局面 | 消耗が蓄積する。長く続けると健康と判断力が落ちる |
| 対決する | 正しさを主張し、決定を覆そうとする | 決定権が対等に近く、関係が壊れても困らない局面 | 情報が来なくなる。勝っても次から警戒される |
| 設計する | 記録し、材料を先に渡し、逃げ道を持つ | 長く同じ組織・同じ技術に関わる局面（多くの場合） | 効果が出るまで時間がかかる。地味で評価されにくい |
3つ目を選ぶ理由は、理不尽の多くが繰り返すからです。単発の理不尽なら我慢も対決も機能しますが、繰り返す理不尽に対しては、そのつど消耗する構えは長持ちしません。このシリーズが扱うのは、ほぼこの3つ目の構えです。
📅 今後の展望：このシリーズの見取り図
ここから先の7回は、型ごとの具体的な対策を扱います。第2回は外部起因の仕様変更（OSのパッチ、ライブラリのサポート終了、APIの廃止）、第3回は内部起因の仕様変更（上流の思いつき、スコープの増加）、第4回は社内政治、第5回はハラスメントと境界線、第6回は評価と処遇、第7回は過去の負債、そして第8回でシリーズ全体をまとめます。
読む順番は問いません。が、第1回の3条件と3手は全回で使う道具なので、ここだけは先に読んでおくことをおすすめします。姉妹シリーズの「コンピュータサイエンス入門」（全8回）と「開発フロー入門」（全8回）が技術の土台を扱っているのに対し、このシリーズは技術者の身の守り方を扱います。両方を持っていると、技術の判断と身の守り方を切り離して考えられるようになります。
まとめ
理不尽は、あなたの努力不足から生まれるものではありません。技術の寿命、組織の利害、制度の前提というあなたの外側の構造から生まれます。だから、最初にすべきことは反省ではなく、名付けです。「これは納得できない・覆せない・落ち度がない」の3条件で判定し、技術・組織・制度の型に振り分ける。そして、その日のうちに事実を記録し、悪化したときの選択肢を1つ決めておく。
ここまで読んだあなたは、理不尽に遭ったとき「これはどの型か」と考えるだけで、自分の体力を穴に注がずに済むようになります。理不尽はこれからも起きます。でも、起きたときに何をするかは、今日から決められます。
参考文献
- Akerlof, G. A. “The Market for Lemons: Quality Uncertainty and the Market Mechanism.” The Quarterly Journal of Economics, 1970.
- Jensen, M. C., & Meckling, W. H. “Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure.” Journal of Financial Economics, 1976.
- Simon, H. A. Administrative Behavior. 1947.
- Cyert, R. M., & March, J. G. A Behavioral Theory of the Firm. 1963.
- Conway, M. E. “How Do Committees Invent?” Datamation, 1968.
- Kahneman, D., & Tversky, A. “Prospect Theory: An Analysis of Decision under Risk.” Econometrica, 1979.
- Argyris, C. “Double Loop Learning in Organizations.” Harvard Business Review, 1977.
- Reason, J. Human Error. Cambridge University Press, 1990.
- Vaughan, D. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press, 1996.
- Edmondson, A. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly, 1999.
- Feynman, R. P. “Appendix F: Personal Observations on the Reliability of the Shuttle.” Report of the Presidential Commission on the Space Shuttle Challenger Accident, 1986.
- Rogers, W. P., et al. Report of the Presidential Commission on the Space Shuttle Challenger Accident. 1986.
- 厚生労働省「職場におけるパワーハラスメント対策」 https://www.mhlw.go.jp/
- 独立行政法人労働政策研究・研修機構（JILPT）「労働政策研究報告書」 https://www.jil.go.jp/
- IPA（情報処理推進機構）「IT人材白書」 https://www.ipa.go.jp/
- Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). https://www.pmi.org/