- 企業はToyota流の製造力、six-sigma品質、Dell流のサプライチェーンのような運用能力に追いつくため多額の費用を投じるが、改善プログラムが持続的な成果につながるケースはまれ
- TQMは、かつて広く使われた後に急速に押し流された事例であり、Fortune 1000のうち十分に発達したTQMプログラムを持つ企業は10%未満だった
- 失敗の原因は特定のツール選択よりも、新しいプログラムが物理的・経済的・社会的・心理的構造とかみ合うやり方にあり、改善は結局システム問題になる
- 成果ギャップが大きくなると、組織はより長く働くWork Harderと、能力を高めるWork Smarterの間で選ぶことになるが、後者は遅延と失敗リスクのため後回しにされやすい
- 改善時間を減らすShortcutsは短期的な産出を高めるため魅力的だが、後から表れる能力低下が蓄積すると、組織をCapability Trapに閉じ込める可能性がある
改善プログラムが失敗するパラドックス
- 企業は、製造、品質、顧客理解、サプライチェーン管理といった運用能力を開発するため、プロセス改善に積極的に投資している
- 1997年の米国企業による経営コンサルタント費用と研修支出の合計は1,000億ドル超で、そのかなりの部分が優良企業の運用能力に追いつくために使われた
- 一部に劇的な成功例はあるものの、多くの改善プログラムは意味のある結果を生み出せなかった
- TQMはこのパラドックスをよく示している
- 1980年代、日本企業の成功に刺激され、米国企業の間で大きく流行した
- 1990年代半ばには、学界とビジネスメディアの関心が薄れ、re-engineeringのような新しい革新に押されていった
- TQMの規律と手法に真剣にコミットした企業は、競合より高い成果を上げた
- ある研究では、Fortune 1000のうち十分に発達したTQMプログラムを持つ企業は10%未満だった
- 別の研究では、TQMは1993年に3番目に多く使われたビジネスツールだったが、1999年には14位に落ちた
- 過去の改善手法は、名前を変えて再登場することもある
- 統計的工程管理と変動削減の中核的な規律はsix-sigmaへとつながった
- quality circleはhigh-performance work teamと呼び直された
ツールより難しいのは実装の構造
- 成果改善のツールや手法は急速に増え、情報技術とコンサルタントの増加によって、どの手法を誰が使っているのかを学ぶことも容易になった
- ほとんどの管理者にとって、より大きな障壁は新しい方法を知ることではなく、それを日常業務にうまく実装することだ
- six-sigma品質プログラムのような能力は、ターンキー製品のように買えるものではなく、組織の内部で育成されなければならない
- 10年以上にわたり、通信、半導体、化学、石油、自動車、レジャー製品産業で12件以上の詳細なケーススタディが実施された
- 観察、参加者インタビュー、記録資料、定量指標が用いられた
- 実装と改善のダイナミクスを捉えるためのモデルも併せて開発された
- ほとんどの組織が改善イノベーションの利益を十分に得られない理由は、特定の改善ツールの選択とはほとんど関係がない
- 新しい改善プログラムは、ツール、設備、作業者、管理者、物理的・経済的・社会的・心理的構造が組み合わさる場所で機能するため、システム的な問題になる
改善の基本物理学: 時間と能力
- プロセスの実際の成果は、作業時間(Time Spent Working) と、その仕事を遂行するプロセス能力(Capability) によって決まる
- 製造では、1日の労働時間と生産性、すなわち労働時間あたりの利用可能な産出の積によって、正味の利用可能産出が決まる
- 成果は、より多く働くか、改善により多く投資するかで高められるが、両者の結果は異なる
- 週あたりの勤務時間を20%増やせば、残業が続く間は産出が20%増える可能性がある
- プロセス能力の改善は、その後に投入されるすべての作業時間の産出を高める
- 欠陥製品の手直しのための残業は、残業が続く間だけ産出を増やすが、欠陥の根本原因を除去すれば、手直しの必要性を継続的に減らせる
- 能力は、時間とともに蓄積される資産(stock) として扱われる
- 改善に使う時間は、能力への投資を増やす
- 根本原因を見つけ、解決策を発見・試験・実装するには時間がかかるため、改善活動と能力変化の間には遅延がある
- 機械の摩耗、工程の逸脱、設計の老朽化、手順の陳腐化によって、定期的に維持されない能力は衰退する
- 改善の遅延は、プロセスの技術的・組織的複雑性によって異なる
- job shopの機械歩留まりのような比較的単純なプロセス改善の遅延は数か月規模である
- 製品開発のような複雑なプロセス改善の遅延は数年以上に及ぶことがある
- 製品と人員の変化率が高い組織では、改善された能力の寿命も短くなる
Work HarderとWork Smarterの緊張
- 経営陣は、顧客需要、保険請求処理量、四半期ごとの新製品発売数といった目標をDesired Performanceとして設定する
- 実際の成果と目標の差はPerformance Gapとなり、研究対象となった組織では期待を上回るプロセスを見つけるのはまれだった
- リソース増強や追加採用を避ける組織において、成果ギャップを埋める基本的な選択肢は2つある
-
Work Harderループ
- 管理者は成果ギャップがあるとき、作業速度の引き上げ、残業、より攻撃的な目標、目標未達へのペナルティといった方法で作業圧力を高める
- 成果レビューの頻度、レビューの詳細度、レビュー担当者の役職といった、より微妙な手段も作業圧力に含まれる
- ある企業では、上級副社長が工場現場の個々の機械の成果をレビューしており、これはどんな代償を払ってでも機械を回し続けろというメッセージになっていた
- あるプロジェクトマネージャーは、担当サブシステムのスケジュールが遅れると、プロトタイプが仕様を満たすまで毎時間の状況報告電話を求められた
-
Work Smarterループ
- 管理者は、改善プログラムの開始、新しいアイデアの実験奨励、研修投資などを通じてプロセス能力を高めようとできる
- 成功すれば、時間の経過とともに能力が向上し、処理量が増えて成果ギャップが縮小する
- 改善投資は長期的により大きな効果を生む可能性があるが、効果が現れるまでかなりの遅延があり、根本原因の発見や新しいツールの適用が失敗するリスクもある
- 緊急の問題では、Work Harderがしばしば選ばれる
- 重要顧客を担当する製造ラインが止まれば、管理者は信頼性改善の研修よりも、ラインを再稼働させ、出荷が終わるまで残業を押し進めるほうを選びやすい
- 一時対応が終わった後も改善活動に戻れなければ、より一生懸命働くやり方が標準的な運用方式になる
再投資ループと能力の罠
- 組織には余剰リソースがほとんどないため、作業圧力が高まると、人々は休憩のような非作業活動を減らし、残業を増やす
- 知識労働者の残業は、しばしば無給のまま夜間や週末にまで及び、家族やコミュニティ活動の時間を奪う
- 時間をこれ以上増やせなくなると、拡大し続ける成果ギャップに対処するため、改善時間を削るしかなくなる
-
Reinvestmentループ
- 改善投資が成功すれば成果が上がり、成果ギャップが縮小して、より多くの時間を改善に使えるようになるため、好循環が生まれる
- 逆に、処理量ギャップに作業圧力で対応すると、改善時間が減り、能力が衰退し、成果ギャップがさらに広がって、より強い作業圧力とさらなる改善縮小へつながる悪循環が生まれる
- 成功した改善事例では、生産性向上で確保したリソースを再び改善活動に明示的に配分し、再投資プロセスを強化していた
- 多くの組織では、コスト・日程圧力がダウンサイジングやより高い成果目標につながり、改善リソースを奪って、能力が停滞または低下した
-
Shortcutsループ
- 改善会議の省略、予定された予防保全の延期、文書化要件の無視といった近道は、ただちに作業時間を増やす
- 能力低下はすぐには現れないため、近道は短期的には効果的で魅力的に見える
- 予防保全を先送りした管理者は、予定ダウンタイムを避け、保全コストを節約する猶予期間を得るが、その後、設備の老朽化と摩耗によって歩留まりと稼働時間が低下する
- 文書化を省いたソフトウェアエンジニアは、プロジェクトを期限どおり終えられるかもしれないが、数週間後または数か月後、テストで見つかったバグを修正するときにそのコストを支払うことになる
-
Capability Trap
- Work Harderは、最初は総処理量をすぐに高め、改善時間減少のコストは遅れて現れるため、better-before-worseの状況を生み出す
- Work Smarterは短期的な産出を減らすが、時間がたつと能力向上が作業努力の減少を相殺し、成果を高めるworse-before-betterのダイナミクスを持つ
- ShortcutsとReinvestmentの相互作用は、組織を能力低下の悪循環に閉じ込めるCapability Trapを生み出す
2件のコメント
Hacker Newsのコメント
記憶は少し曖昧だが、良い事例がある。
ある組織で重要な注文処理があり、必要な情報がすべて届く、あるいは正確に届くとは信頼できない状況だった。そこで入力値を整え、処理方法を変える検証ロジックを作り、各注文でどの検証がトリガーされたかを指標として残した。新しい検証を追加したときは日付も付けた。
この指標を公開してときどき共有していると、誰かが「XYZならどうなりますか？」と尋ねたときに、「すでに対応済みで、XYZによって####件の注文が止まるのを防ぎました」と答えられた。
チームが慎重に仕事をしており、システムが継続してうまく回るにはこうした作業が必要で、それをデータで裏付けられることが明らかになった。そのおかげで組織内の会話は「なぜ考えなかったのか」よりも「次に何をすればよいのか」へと変わり、予防的な品質への評価も上層部に伝わるようになった。
たいていのチームは注文成功率のような指標だけを見て終わっていただろうが、悪いデータを処理した回数を指標にすれば、良いことが目に見えないという落とし穴から抜け出せる。
最近、職場でまったく同じことを経験した。
組織の技術リード／アーキテクトとして最近リリースされたプロジェクトをレビューし、深刻な信頼性／性能問題のため必ず改善すべき箇所を見つけた。あるチームの複数のリリースがリストの上位にあったが、そのチームのPMとエンジニアリングマネージャー、さらに上の人たちは機能アップデートを優先すべきだとして、すべての懸念を無視した。
数か月後、休暇中に問題が発生し、sev 1エスカレーションとなり、複数の顧客が怒り、CEO／CTOまで関与した。問題の粗雑なコードを書き、警告を無視していたまさにそのチームが昼夜を問わず働いてサービスを復旧し、今では彼らは英雄になっている。特にそのマネージャーは、障害中に活発にコミュニケーションを取り、リーダーシップを示したという理由で社内での評判が上がった。
他人が作った問題を直すほうが印象的だ。自分のミスを直した人に賞賛を浴びせたいとは思わないし、自分も自分のミスを直したからといって賞賛を期待しない。そもそも台無しにしたことについて皆に謝るだろう。
タイトルの問題を、自分の価値との関係でずっと考えてしまう。
誰かが3か月間詰まっていた仕事を40分で助ければ、私の価値は誰の目にも明らかだ。だが、私がずっと一緒に働いていて誰も3か月間詰まらないなら、私の価値は不明瞭になる。このパラドックスにどう向き合えばいいのかわからない。
努力と時間をさらに費やすと、報酬は遅れたまま、より多くの努力と時間を期待されることが多い。価値と機会は、努力と時間に対してカオス的なプロセスに近い。
結局、機会が現れたときにつかめるよう、頭が冴えている程度の仕事量を保つようにしなければならない。誠実でバランスの取れた同僚は助けになるが、最終的には自分でやるべきことだ。
上司が説明しようとしても、次のレイオフで切られるのは私の首かもしれない。
ほかの会社には、私がこういう仕事を得意としていると伝えてくれたが、何にもつながらなかった。小さな会社相手の請負仕事は、その日が最初で最後だった。
そのためチームメンバーの士気はくじかれない。チームメンバーは心理的に、自分の個人としての貢献が認められる必要がある。
こうした上司は、有能な個人貢献者からチームリードになった場合が多く、自分自身がその技術の熟練者であるため、管理している個人貢献者を最もよく判断できる立場にいる。
回避した惨事を生々しく描写し、人々が明確なイメージを思い浮かべられるようにする必要がある。
もう一つの変形は、実際に一度起きた問題を防ぐためにリソースを過剰に割り当て、より深刻だがまだ起きていない問題は手薄にすること
これはマネジメントの問題。ほかのもっと重要なことをするのが合理的だったとしても、同じ事故が繰り返されたときに責任を取りたい人はいないから
小さな傷が、硬直して柔軟性のない組織に置き換わるようなもの。何かが一度起きたからといって、二度と起きないように必ず変えなければならないわけではなく、そうした過剰反応が将来大きな負担になり得る
その損失を受け入れ、また起きる可能性があると認めるほうが、確実に防ごうとして過度に予防するよりよい場合もある
実際に何かが起きるまでは予防リソースを割り当てないという方針は、ある程度合理的
障害に過剰反応していること、そして実際に起きた問題には非常に単純な解決策があることを説得するのに、悲惨な1年を過ごした。しかし上級管理職は、再発によって自分の立場が危うく見えると、部門全体に類似問題のコードを見直して修正するよう命じる。そして奇妙なことに、ものすごく過剰設計された解決策を出す最大の声に耳を傾ける
またあるときは、パスワードの有効期限切れで取引スタックに障害が起きた。これを「二度と起こさない」ためだとして、ばかばかしいほど複雑な手製の解決策に注ぎ込まれた労力にはあきれた。結局1年以上作業したあとにすべて捨てられ、最初からそうすべきだった、はるかに単純な中央集権的な解決策に置き換わった
以前働いていた場所を思い出す。フィードバックを求めるたびに、「ここでは**PIR（post-incident response）**なしには何も優先事項にならない」と繰り返された
最後のころには、PIR関連のチケットが上がると、その事故を防げたはずなのにバックログで埋もれていた実際のチケットの重複としてマークしていた。自分たちの担当領域で予測可能な問題を防ぐことに何の影響力も持てないことは、チームの士気を大きく損なった
チームメンバーのほとんどは、改善提案を完全にやめた。管理層が、私たち自身でチケットを引っ張ってくることを許さなかったから
企業式のScrumがどんな地獄に変わりつつあるかを、とてもよく描写している
Agileは文字通り、素早く働き、能力を短いサイクルで改善しようというものだった。ところがScrumは、置き換えようとしていた計画プロセスよりも悪いバージョンになった
Scrumが仕事を目の前の問題へと細かく分解するやり方は、むしろこの循環を悪化させる。長期的には、火事は上へ押し上げられ、技術的負債は下へ押し下げられるチケットシステムになる
そのうえ、コンサルタントや役員が最適化ごっこをしやすい、追跡はしやすいが意味のない効率指標まで吐き出す
こういうことを言っても大丈夫。親しい友人の中にもスクラムマスターがいる
なぜそうなるのかは理解できる。できることが山ほどある中で、何をするかを誰かが決めなければならない。この機能はお金を稼いでくれるのか？ 機能ではないがリソースコストを下げる作業はどうか？ 機能の提供速度を遅らせるという技術的負債はどうか？
私は上級管理職ではないが、結局、上の誰かは会社を存続させ、稼がせ、私たちに給料を払う責任を負っている。彼らも私たちと同じように、得られる少ない情報で意思決定しなければならない。だから「これはコストがいくらで価値がいくらか」と「あれはコストがいくらで価値がいくらか」を比較する方法が必要になる
それを見積もる方法が必要で、テック業界がその手段としてAgileを売り込んだので、それにつかまったのだ。誰のせいだろう？
そうして頻繁な見積もり、スケジュール追跡、儀式が付いてきた。これが自然に付いてくるべきだと信じていない人もいるし、私も同意する。だがいずれにせよ、その儀式はカルトの一部になった
私たちはScrumを捨て、リファインメント会議、ストーリー見積もり、ストーリーポイントも捨てた。今では月に一度、PMと公式に会い、チーム単位で現在地をTシャツサイズ見積もりだけで見る。それ以外は、PMが求めたときや私たちが必要だと感じたときに更新する。おかげで権限は私たちにあるが、その分、責任を持って状況が不安に見えたら適時知らせる。依然として「見積もり」はしなければならない。結局、上級管理職は意思決定しなければならないから。ただ全体としてはかなり軽量で、本当に解放感がある
全員がプロセスにコミットしており、Scrumチームは労力の20%を負債処理の優先枠にしていた。各自のベロシティもかなり正確で、個人の関心事に使う20%を追加で反映でき、ステークホルダーの優先事項は残りの60%を埋めていた
あるスプリントでは、エピックやチーム目標を終わらせるために力を入れる必要があったり、緊急事態やバグで優先順位を変える必要があったりすれば、方向転換した
プロセスを追加したいからといって大量に追加しても、価値は生まれない
オフィスに貼っていたこの漫画を思い出す: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
だから多くの企業文化では、問題が自分の直接の担当領域でなければ、直し方を知っていても先回りして防がないほうが報酬上有利になる。問題が表面化するのを放置し、誰かの緊急事態になってから直せばよい
もちろん長期的には、そんな組織がうまくいくはずはないので、去る計画も立てるべき
「誰も、起きなかった問題を直した功績を認められない」（2001）[pdf]を思い出す
YouTuber やソーシャルメディアのクリックベイトが、Y2K バグは大したことではなかったと主張するたびに、この考えが頭に残る
大したことにならなかった理由は、私のような大勢のベテランたちが何カ月も前から徹夜して、ちゃんと動くようにしたからだ
いまでも UTC の午前0時カウントダウンの緊張を覚えている。その次に東部時間のカウントダウンでまた緊張し、ローカル時間でももう一度そうなった。太平洋時間が2000年になって、ようやく緊張を解くことができた
2038年に分かるだろう
同じ時期なら Y2K も非常に良い例だ。目立ったことはほとんど起きなかったが、人々がただ無視していたら、多くのことが起きていた可能性が高い
私の給料がそれにかかっていたから、というわけでもない。他の仕事の機会はいくらでもあった。実際にエネルギー産業を麻痺させかねない問題で、大手企業と、その無数の依存組織に影響したはずだ。この経験から見ると、金融や資源開発など多くの産業にも、直接・間接に同じ衝撃があっただろうと思う
だから良い例なのだ。いまでも Y2K を大したことのない騒ぎとして覚えている人に会う。そうではなかった。あなたにとって問題でなかったのは、多くの人が懸命に防いだからだ
その問題はものすごく複雑だったわけではないが、広範囲に存在し、重要で、大きな作業量を必要とした。人類の偉業として掲げる月面着陸級の工学問題というより、爆発の前に大量の愚かな Challenger の O-ring 問題を直すことに近かった
そのため当日には、些細な残存バグが少し残っていただけだった。新聞には冗談がいくつか載ったが、大衆はおおむねそのまま通り過ぎた
私は気候分野で働いていて、同じことが起きることを望んでいた、あるいはいまも望んでいる。だが近いうちに、誰もが注目せざるを得なくなりそうに見える
備えができていれば、何も興味深いことは起きず、生活は続き、人々はノートPCを開いてボタンをいくつか押した程度に記憶する
備えができていなければ、テキサスの電力網が凍りつき、人々が死に、貯蓄を失い、「ここまでひどくなるとは誰も想像していなかった」となる
告白すると、私もその作業に参加していた。おかしいのは、以前の顧客企業に呼び戻されて、過去の自分の作業が文字通り作り出した問題を直したことだ。問題を見た瞬間、20分で直した。そして「来たついでに、これも少し見てもらえますか……」が続き、その部署が閉鎖されてニューヨークへ移されるまで約2年続いた
少なくとも請求可能な時間としては認められた
この記事がその直後に書かれていたので、Y2K の話だと思っていた
90年代後半の数年間、Y2K プロジェクトに携わり、英国の重要インフラが午前0時に止まらないよう支援した。たとえば私たちの努力がなければ、ウェールズには水もガスもなかったはずだ
ところがその後、「何も起きなかったのだから明らかに問題ではなかったのに、なぜ Y2K にあれほど金を使ったのか？」とか「Y2K は IT 業界が作った詐欺だった」と言われた
私たちは勝ったのだ。Y2K バグを成功裏に防ぎ、それは大変な仕事で、午前0時までにすべて捕まえられたかどうかも確信はなかった。なのに祝福されるどころか、一部の人はそれを、私たちがぼったくった証拠だと見なした。人間は妙なものだ
うんざりするのは、気候変動でも最善のシナリオがこれと同じだという点だ。実際に終末を避けることに成功すれば、すべての「気候否定論者」は自分たちが正しかったと感じるだろう
Hacker Newsのコメント
タイトルを見て、興味深い古代中国の逸話を思い出した。Toyotaが最近スキャンダルに巻き込まれたのも少し皮肉だ: https://www.bbc.com/news/articles/c1wwj1p2wdyo
魏の文王が扁鵲に「三兄弟がみな医者なら、誰がいちばん優れているのか」と尋ねると、扁鵲は「長兄が最も優れ、次兄がその次で、私は最も劣ります」と答えた
長兄は病がまだ形を成す前に見抜いて人知れず取り除くので、名が知られているのは家の中だけであり、次兄は病が現れ始める時に治療するので、名は村の路地の外までは広がらず、扁鵲自身は血管に針を刺し、強い薬を使い、肉を切り開くため、その目に見える行為のおかげで諸侯の間に名が広まった、という話だ
苦労している部門が自分たちの作った問題を英雄的に収拾したという理由で、次の四半期に称賛と予算増額を受ける会社を見たことがある
一方で、静かにうまく回っていた私の部門は、明かりをつけ続けることさえやっとだった
ダブルクリック程度しか分からない非技術系の経営陣と、実際に会社を支えているエンジニアリングとの断絶のせいで、この業界では深刻な問題になっている。経営陣がエンジニアリング出身になる以外に、うまい解決策が思い浮かばない
ある種の問題は、リーダーシップが学ぶ機会になるよう、修理する前に痛みのシグナルを上へ送るべきだ
ただしインセンティブ設計は難しく、最上位の経営陣が部下や部門に痛みや問題を表に出させない構造になってはならない。善意でシグナルを隠してしまう人も多いので、大きな組織ではいくつかの問題は展開するに任せ、過度に反応的にならないほうが効率的だという点をコーチングする必要がある
皆が正常条件と完璧な運用を前提に設計しているとき、設計・サービス・インフラ・アプリをどう壊せるかを見つける人が重要だ
IT部門の同僚は商用証明書をLet’s Encryptに切り替え、EV要件をなくせば2,000ユーロ強を受け取れるはずだったが、結局もらえなかった。そういう仕事は「本来業務」だという理由だった
実際に動くサービスを作ったチームは、予算を凍結され、人員まで減らされた
他のチームで問題が起きたとき、私たちのチームに同じ問題がなかった理由を、完了した作業の一覧で示すことができる。作業はすでにやっていて、ただダウンタイムを避けられるより良いタイミングで行っただけだ
こういうことはよくある。特に、優雅な解決策は後から見るとたいてい単純に見える、という点が気に入っている
長く考えた末に賢い解法を見つけて説明すると、相手は「うん、当然だよね」と反応する
隣の席で問題を不必要に複雑にした人のほうが、あんなに難しいものを作ったと称賛される
大企業はいまだに複雑さに感心する側に遅れているのかもしれないが、直接であれ間接であれAIの出力を受け取る立場からすると、複雑さは以前ほど印象的ではない
奇跡的な復旧であるほど、「甥っ子がちょっとした問題をすぐ解決した」という話を聞かされ、まるで私にはそれができなかったと強調されているように感じる
責任者は複雑なやり方で書くよう助言した。そうしないと出版されないからだ。頭がいいからではなく、解法が複雑に聞こえないと認められないということだ
美しい解法より複雑な過程が称賛される現実と正確に重なっており、官僚主義もたぶんこうして生まれたのだろう
そのコードはリリース15分後には忘れ去られ、誰にも二度と読まれなかったが、何年も使われた。だからAIは、多くの人が思っているよりずっと早く仕事を奪うかもしれないと思う
クリーンコード、関心の分離、保守性のように、私たちが最も時間を使うものは実際には評価されてこなかった。「十分にそこそこ」であればマネージャーは満足し、問題が起きたらAIがスパゲッティ式でもパッチを当てられる
以前の職場でも似たような問題があった。会議の予定を組んだり、会議前に必要な情報を全員がそろえておけるようにしたりといった、裏で回る事務作業にほとんどすべての時間を使っていた。
ところが評価の時期になると、私が仕事が崩壊しないようにつなぎ止めるのに忙しく、ストーリーポイントをあまり消化できなかったことだけが重要だと言われた。
そこで事務作業をすべてやめて、ストーリーポイントの完了だけに集中してみたところ、1〜2週間後にマネージャーがチームに「どうして会議が全部めちゃくちゃになっているんだ？ 会議に入っても誰も何が起きているのかわかっていない」と尋ねた。
Y2K対策でほぼ2年間、ネットワーク・ハードウェア・ITの仕事をものすごくやったあと、マーケティングに移り始めた。結局、"何も起きなかったのだから" その時間と費用は無駄だったと、ほとんどすべての会社が考えていた。
ある会社にいたっては全額返金を求めてきて、私が行った作業を元に戻してよいなら返金すると言ったところ、それに同意した。翌日、その会社の全システムが崩壊した。
父の会社のネットワーク支援も、正規の料金を決して払おうとしなかったので引き受けにくかった。ほかの2人が問題を解けなかったあと、私が15分で直したところ、今度は15分しかかからなかったことを理由に、なおさら金を払いたがらなかった。
壊れないように維持する能力は評価されず、壊れたあとに直すことだけが評価された。マーケティングのほうが報酬は良く、毎日実際の数字で自分の給与を正当化できた。好きの度合いははるかに低いが、これまでやってきたどのIT業務よりも尊重された。
評価されるのは、プリンターを直すこと、コンピューターの問題A/B/Cを直すこと、友人のために作った広告なしのAndroid Sudokuのような単純なものばかりだ。
お金をもらってやっている中核業務は評価されない。いろいろな業界で、お金が絡むと契約上の役割を果たすことが当然になり、感謝が減るように思える。
技術を知らない人たちは、開発者は在宅勤務で1日30分しか働かないと思っており、AIはそのイメージをさらに悪化させた。
Ian Rushがうまく言っていた。「ストライカーが最高だ。5回外しても決勝点を決めれば英雄だ。ゴールキーパーは見事なセーブを続けていても、1点入れられただけで悪者になる」。
私が働いたすべての場所で、火事を起こさないようにした人よりも消防士が報われていた。さらに悪いのは、インセンティブを決める人たち以外は全員、その計算を明白に理解していることだ。
逆側の問題もある。決して起きないことを心配するのに全時間を使う人たちもいるので、単に防御的な姿勢だけを報酬対象にすればよいという話でもない。
職場での昇進はこういう形で起きる。何かを壊し、エスカレーションされて目立ち、役員にメールが飛ぶ。そこでそれを「直す」と、みんながよくやったと感謝する。
もうひとつのパターンは、本来やるべき仕事を長く引き延ばして可視性を高めることだ。役員は、問題になる前に責任を持って終わらせる人たちの仕事を見ない。
その代わり、何かを壊して1日を「救った」人の名前は覚える。
そして役員に取り入って、「doublerabbitには任せないほうがいい」「チームプレーヤーではないようだ」などと言う。全部私のインフラなのにそうする。
どうして私が人間嫌いなのかと聞かれる理由はこれだ。
小学1年生のときにはもう学んだことだ。授業中におとなしくして宿題をやる子どもたちは、先生の時間や労力をあまり必要としない。
ルールに従わず、勉強に少しでも努力するたびにいちいち褒められる必要がある問題児たちが、先生の注意を奪っていく。
ITで過ごした時間は、二つの極端のあいだを行き来していた。
「周りは全部うまく回っている。なのに、なぜITに金を払うんだ？」
「全部壊れている。なのに、なぜITに金を払うんだ？」
個人的には後者より前者を目指していた。「自分がちゃんと仕事をしていれば、自分がここにいることすら誰にもわからない」とよく言っていた。だが、そのせいで解雇された。
因果応報という意味で以前の会社の人たちとは今でも連絡を取っているが、今は完全な大混乱になっている。それがせめてもの慰めだ。
能力の罠を知ると、どこにでもそれが見える。
Sterman、Repenning、そのほかの共同研究者たちはこの論文のあとも何本も書いており、どれも興味深いが、ほとんど全部が憂鬱になる。
とりわけ、システムダイナミクスが最初に学問として確立されたMIT Sloanが、システムダイナミクスが最初に無視されたHarvard Business Schoolのすぐ近くにあるという点が、なおさらそうだ。