経営陣がITの警告を無視したため、技術チームが強硬策に出た
(theregister.com)ITチームの教訓的な対応
- オーストラリアの銀行のインターネットインフラチームで働いていた「Bruce」の話。
- インターネットバンキング初期、チームは急速に成長し、業務量も増加した。
- ISDNリンクの使用率が半分を超える前に、追加リンク購入の必要性を認識し、CIOに提案書を提出した。
経営陣の拒否とITチームの対応
- CIOは経営陣に追加のISDNリンク購入を要請したが、現在のリンク使用率が半分にも達していないとして却下された。
- ITチームはリンク使用率が50%を超えた時点で再度要請したが、100%近くになるまで待てとの指示を受けた。
ITチームの戦略的措置
- ITチームは経営陣のネットワーク接続を調整し、問題を経営陣に認識させることを決めた。
- 最初の週に10%下げ、その後は毎週さらに10%ずつ下げた。
- 1か月後、追加のISDNリンク設置が承認され、経営陣は「インターネットの問題」を解決したとして自賛した。
GN⁺の意見
この記事で最も重要なのは、ITチームが経営陣の決定に異議を唱え、実際のユーザー体験を通じて必要なインフラ投資を納得させた戦略的な対応である。これは、技術的な問題とビジネス上の意思決定の間にあるギャップを埋めるうえで、創造的かつ効果的なアプローチを示している。この話はITの専門家にとって興味深いだけでなく、非技術系の意思決定者にとっても技術インフラの重要性を理解する助けとなる教訓を含んでいる。
1件のコメント
Hacker Newsのコメント
以前、顧客に大きな問題を起こしていたひどいサードパーティ製ソフトウェアを使っていたことがある
社内で代替ソリューションを作っていたが、一部の人たちは契約を更新して、同じバグだらけのソフトウェアを使い続けようとしていた
顧客が開いたチケットをすべて既存ソリューション維持派に回すようにしたところ、最終的に私たちのシステムへ移行した後は問題がほとんどなくなった
現場の人たちは、その痛みが上に上がらないよう英雄的に食い止めることが多く、組織は問題をなくす代わりに人を鎮痛剤のように投入し、その状態に依存してしまう
旧システムは、すでにやっていたこと以外は大規模な配線し直しなしには何もできず、担当チームは知識を共有しなければ一生の雇用が保証されると信じていた
新システムは、クエリを直すよりCPUを足せばよいと考えていて、データベースの遅延が大きかった
2つのチームはすぐ隣に座っていたが互いに話さず、旧システムのチームはITディレクターの机の下にあった小包を爆弾として通報するところまでいった
新システムのチームは最終的にOracleを呼び、Oracleがクエリを書き直してくれた
リスクを明確に説明し、技術的な結果がビジネスにどう影響するかを語れる能力は、IT従事者にとって中核的なスキルだ
この銀行の経営陣が本当に深刻なほど鈍かった可能性もあるが、技術チームがきちんと説明できていなかった可能性もある
むしろITの中にいるからか、私たちはかなり上手に、正確にコミュニケーションしていると感じる
本当の問題は、中間管理職の政治がすべてを濁らせることだ
チームには「自分が失敗したので直す必要がある」と言えるが、上層部には大して重要でもない決定でさえ取り消さないために、あらゆる理由を並べる人たちがいる
もしかすると、誰かがすでに上司に「その機器はあと10年使える」と売り込んでしまっていたのかもしれない
同僚たちと仕事をしていると、受け手のレベルに合わせて複数の深さで説明しようと、かなり努力している
もっと頻繁に起きているのは、最高経営陣とその下の管理職が単に気にしていないということだ
頭の中にはすでに「巨大な計画」があり、開発者たちがその幻想は現実になり得ないとどれだけ言っても変わらない
たいていの場合、彼らは私たちの言っていることを完全に理解している
上位階級のnerdにしか分からない難解な専門用語を投げつけているのではなく、単に彼らが気にしていないだけだ
MBA的に頭も心もない人たちが会社を動かすケースが減り、エンジニアがより多く責任を負う組織が増えてほしいが、人生とはそういうものだ
企業ITは事務職のサポート業務から育ってきたもので、FAX機やPCが動くことに戦略計画は必要なかったため、当初は重要でない部門扱いされていた
スーツを着た人たちがけちだったり愚かだったり、あるいは技術を理解できないせいだと考えがちだが、実際にはコミュニケーション能力の不足である場合も多い
最初の職場で、CFOがAS/400のまともなバックアップシステムの要請をずっと拒否していた
そのAS/400にはERP、CRM、会計など会社全体の業務が入っていて、300人分の作業を8インチフロッピーにバックアップするなど、そもそも無理な話だった
ある日、大規模なディスク障害が発生して会社全体が数週間停止し、注文処理・サポート依頼・営業提案・顧客番号と住所の照会がすべてできなくなった
一部のディスクはKroll Ontrackに送ったと記憶している
その災害の後になって、ようやくまともなバックアップ機器を買った
数か月後、学生開発者が本番環境で
where句がコメントアウトされた削除クエリを実行し、テーブルが丸ごと1つ吹き飛んだバックアップはあったが、バックグラウンドジョブがそれを検知して4年分の請求書を再生成し、過去の全顧客に再度支払いを求めるメールを送ってしまった
テスト環境はほどなく用意された
少し前、へき地の2年制大学で働いていたが、すべてのデータが古いAS/400にあり、数週間ごとに1日か2日ずつ落ちていた
バックアップはなく、テープドライブは故障しており、当時の基準でも古い10Mbps NICのような部品は交換品もなかった
交換するかクラウドサーバーへ移行すべきだと何度も求めたが、「予算にない」「高すぎる」という答えしか返ってこなかった
実際の利用量ベースでは月に数百ドル程度だったのに、システムが落ちれば大学全体が崩壊し、永久閉鎖される可能性もあるリスクと比べると、まったく割に合わなかった
結局障害が発生し、数日間、メイン端末からはアクセスできるがネットワークとはまったく通信できなかった
人々はパニックになり始め、時給100ドル超のAS/400修理専門家を呼ぼうという話も出た
最後の試みとしてNICを直し、復旧したことを知らせる一方で、これが最後の起動になるかもしれないので、その前にどこかへバックアップしなければならないと強く念を押した
6週間後、私たちはピカピカのクラウドベースAS/400を手に入れ、その古く重い獣を最後に停止して葬儀を行った
最終稼働時間はほぼ25年だった
この話は可能性が低い、あるいは完全な作り話だと言うこともできるが、私はそうは見ない。
大きな組織で何かを成し遂げるには、経営陣に自分の痛みを感じさせる必要がある。
皮肉ではなく、世の中はそう回っている。
状況を理解するためのあらゆる思考の段階を、相手が自力で踏んでくれると期待する人は、厳しい驚きを味わうことになる。
90年代初頭でも、支店オフィス以外の場所でISDNは一般的ではなかったはず。
しかもトラフィックシェーピング/QoSの話が出てくると、さらに信じにくい。
当時ほとんどの人が使っていたCisco 2500/2600ルーターがそうした機能をサポートしたのは、ずっと後だったと記憶している。
もしかするとT1のことを言っているのかもしれないし、r/thathappened感が強い。
定義上、管理職は実務担当者とは違う仕事をしている。
例えばひどいコードベースの痛みを、管理職にどう感じさせられるだろうか。
職場でCisco 1604 ISDNルーターを常時接続にせず、自動ダイヤルに設定して費用を節約しようとしていた。
ところがWebブラウザパッケージがインストールされたIBM AIXが、1時間ごとにBig Blueへ定期的なテレメトリの電話をかけており、研究室のネットワークがアイドル状態に落ちないことに気づいた。
ルーターにファイアウォールルールを追加して、そのこっそりした振る舞いを止めた。
90年代後半でも、Microsoft、Sun、Novellはテレメトリに関してIBMほど厚かましくはなかった。
ここで浮かび上がる本当の問題は、IT側が正しいと分かっていることを、ビジネス側からある程度独立して実行できる自律性が必要だという点だ。
結局、組織でどれだけの監視を受け入れるべきかは信頼が左右する。
私のいるところでは、顧客に影響することでなければ許可を求める必要はない。
マシンが厳しそうに見えたり、SaaSの料金プランが上限に近づいたりしたら、そのままアップグレードする。
たまに新しい請求書や費用増について尋ねる人はいるが、物事を進めるために何度も尋問を受ける必要はない。
スーツ組は、些細な技術作業ひとつにも許可を乞わなければならない環境の欠点を考えるべきだ。
10年以上前に象牙の塔で作られた複雑な変更ポリシーのせいで、どれだけ多くのイノベーションがそのまま燃えるゴミ箱に投げ込まれているのだろうか。
ビジネスをITチームの顧客としてモデル化する形で、組織を考え直すことはできないのだろうか。
会社が失敗すればIT組織にも存在理由はないのだから、その方がはるかに単純な考え方に見える。
だから費用対効果が変わるので、コミュニケーションが必要になる。
「君の仕事は階層構造の決定を尊重することだ」というような反応を見ると、企業組織がいまだにどれほど軍隊式の思考にとどまっているかを思い出す。
かつてのプロイセン軍では、任務を目標中心で伝えていた。
「私はXを達成しようとしている。君はYを担当し、別の部隊はZを行う」という形で、実行は現場を実際に見ており、必要な知識も持つ現地の将校に任せていた。
また、将校や下士官が直属指揮官の命令に反対する場合、その上層部に抗議することもできた。
参謀将校が訓練過程で指揮経験も積まなければならず、指揮官の命令を相殺することもできる参謀制度まで加わって、変化する状況に適応する強く柔軟な体系になった。
将校たちは上官と議論したり、上層部に持ち上げたり、本当に必要だと判断すれば命令を拒否することもためらわなかった。
そうしてこそ下位階級の同意と参加が生まれるからだ。
可能な限り最も低い階層で意思決定する方式だ。
近代に入ってやや流行は下火になったが、私の知る限り、どの軍隊も純粋に「君の仕事は階層の決定に従うことだ」だけで運営されてはいない。
例えば書籍 Extreme Ownership のようなものだ。
私が悪意的すぎるのかもしれないが、そんなリーダーシップなら、ただ新しい職場を探して、船全体が沈むに任せていたと思う。
リーダーシップの観点から単純化してみると、毎年似たような提案が100件上がってきて、それぞれ100万ドルかかるとしよう。
すると償却や税務上の小細工を除いても、毎年純粋な費用が1億ドルになる。
銀行であっても大金であり、戦略的に使うべきで、浪費してはならない。
この構図では、リーダーシップに痛みを体感させ、なぜ今回の100万ドルが有効に使われるお金なのかを本能的に理解させることは、リーダーシップにとってもITにとっても事業にとっても、それなりに健全な戦略だ。
役員は会社の有限な時間、人員、費用などを管理する人間だという点もある。
もちろん概してその仕事が特にうまいわけではなく、会社の観点での純粋に合理的な選択は、彼らに一般社員と同じくらい、より豪華でない報酬を与えることだとも見なせる。
しかし「会社」が決めるのではなく、人が決めるのであり、その中には政治ゲーム、インセンティブ、自己利益が含まれる。
役員たちは情報、意思決定、リソース、金の流れを支配しているため、宿主である会社から過剰な取り分を吸い上げる寄生者のように振る舞う。
この問題の解決は読者への練習問題として残す。
「X日ごろに回線が50%飽和すると予測されます」とだけ聞かされていたなら、ITは本当に説明が下手だったということだ。
私たちは、この技術では50%の飽和が顧客の遅延や接続エラーを意味することを知っている。
それなら「X日ごろに顧客が接続問題を経験すると予想されます」と言うべきだ。
100%の上限が理想的な状況でしか可能でない理論値だと分かっているなら、実際に使える上限を基準に話すべきだ。
人々が情報に基づいて決定するには正しい情報を与える必要があり、技術を理解することで給料をもらっている側がITなら、その特性をスーツ組が理解できるように伝えるのもITの仕事だ。
もちろん最善を尽くしたのかもしれないが、文章だけを見ると、そうした情報なしにメモだけ送ったように聞こえる。
「使用率50%」という表現が、蛇口を半分だけ開けたような意味で使われているのがよく理解できない
単一のパイプに負荷が鋭く集中すれば、結局は断続的な性能低下が起きるのでは？
「悪い体験」をする時間の割合は分布次第で急激に上がるので、60%になるだけでも耐えがたくなりそう
たとえるなら、バーが平均需要だけを見てサーバーを1人だけ置くことにしたところへ、金曜の夜が来るような状況
まさにキングマンの公式が言っている内容
「使用率が50%を超えると、ITチームは再びISDNの発注を提案した。そしてまた却下された。使用率が100%に近づくまで二度と聞くな、という指示付きで」
これは当局のコロナ認識によく似ている
責任者たちは既存の傾向を見てもどんな予測もできず、災害が目の前に迫って初めて反応するように見える