金属製造用の優れたソフトウェアを構築および購入する

scanrail/iStock/Getty Images Plus

ソフトウェアは、現代のファブショップにとってますます関連性が高く、重要なものになってきています。 社内でコードを開発している場合でも、サードパーティのツールを購入している場合でも、何を探しているのかを理解することが重要です。 ソフトウェアがどのように作られるのかを深く理解していなければ、それは難しいかもしれません。

Healthcare.gov は、ソフトウェア設計のリスクに関する簡単にアクセスできるケーススタディを表しています。 10年前に打ち上げられ、すぐにドスンと音を立てて着陸した。 非常に遅くて不具合が多かったので、最初の週に登録できたのは興味を持った人のわずか 1% でした。 Web デザインは、ワークフローが貧弱で、ユーザー インターフェイスに不具合があり、絶対的な基本を実現できていませんでした。 さらに、健康保険提供者にはサイトから不正確な情報が提供され、登録を正しく処理することが困難または不可能になっていました。

予想されるユーザー数を調査するはずだったストレステストはまったく不十分でした。 公開の前日、同時ユーザー数がわずか 1,100 人でサイトが遅すぎることが判明しました。 想定ユーザー数は5万～6万人。 それが十分に悪いことではなかったとしても、実際の同時ユーザー数は最初の 1 週間で 250,000 人に急増し、リリース前のストレス テストでサイトが処理できることが示されたユーザー数の 200 倍を超えました。 振り返ってみると、そもそもストレステストがなぜ行われたのか疑問に思う人もいるでしょう。 彼らの明らかな失敗は、リリースのスケジュールを変えるには何もしませんでした。

プロジェクトは予算不足でつまずいたわけではありません。 当初の費用は 9,370 万ドルと見積もられており、たとえ予算を超過しなかったとしても、驚異的な金額です。 しかし、その見積もりは大きく間違っていました。 完成までに、総コストは驚くべき、涙を誘うような 17 億ドルに上り、推定のほぼ 20 倍でした。

Healthcare.gov は 2023 年にはうまく機能しますが、立ち上げ当時はおそらく史上最も壮観で高価な公開ソフトウェアの大失敗でした。 Healthcare.gov の展開を取り巻く複雑さの多くは避けられませんでしたが、その失敗した展開を利用して、ソフトウェア プロジェクトの成功と失敗の原因を探ることができます。 その失敗は、独自の社内ソフトウェア チームを構築する方法についての洞察を提供するかもしれません。 また、サードパーティ ソフトウェアを購入する際に何に注意すべきかについての洞察も得られる可能性があります。

前回の記事で、サウスウエスト航空が 2022 年の休暇中にどのように破綻したかについて書きました。簡単に言うと、同社は数十年前のソフトウェアに依存しており、そのためスケジュールの中断に対処することが非常に困難でした。 従業員は問題を理解していましたが、企業幹部は日々の業務上の苦痛から切り離され、何十年も新しいインフラへの投資を怠っていました。 この失敗に冬の嵐と季節需要の高まりが重なり、会社全体が停止に追い込まれ、クリスマスの週には数万人が足止めされた。 サウスウエスト社自体は、この災害により最終的に同社に約 10 億ドルの損失が生じると見積もっている。 意思決定者が運営上の問題に十分近づき、緊急性を理解していれば、このような異常な出費は避けられたかもしれません。

ここで得られる教訓は、優れたソフトウェアは緊密なチームによって開発されるということです。 優れた近接性は 2 つのことを意味します。1 つは、ソフトウェア チームが解決しようとしている問題をよく知っていることです。 第 2 に、開発者はソフトウェアによって生成される結果をすぐに知ることができます。 別の言い方をすると、良好な関係にあるチームは痛みを理解し、独自のソフトウェア ツールを使用してそれを軽減します。 ソフトウェアが目標を外していたり​​、不具合があったり、使いにくかったりした場合は、開発者が最初にそれを発見する必要があります。

これは、Healthcare.gov プロジェクトが確実に失敗した分野の 1 つです。 開発者は、Web サイトが解決するように設計された問題を理解していたかもしれませんが、親請負業者は Healthcare.gov がサービスを提供している米国ではなく、カナダで事業を展開していました。 システム全体のさまざまなコンポーネントも多くの下請け業者に委託されていましたが、どの下請け業者も完全なアプリケーションを所有していなかったでしょう。 たとえ開発者がソフトウェアが解決することを目的とした問題を理解していても、エンドツーエンドのユーザー エクスペリエンスは個々のソフトウェア開発者の制御の範囲外にあったでしょう。