今どうすればいいか？ 設計変更のための計画策定

システム設計、計画、アーキテクチャについて人々と話し合う機会は非常に多くあります。そしてその議論が遅すぎるケースも多く、設計がすでに実装済みだったり、部分的に実装されていたりすることがあります。進行中の設計が状況に最適ではないと判断された場合、これは非常にやっかいなことになります。

このような状況から生じる挫折感は理解できますが、IT業界にいる私たちは非常に頻繁にこの状況に直面しなければならず、この反応を建設的に管理することが重要なITスキルです。技術的にも感情的にも、この状況をうまくコントロールできるようにならなければなりません。それによって動けなくなってはいけません。これはすべてのIT専門家が定期的に経験する自然な状況です。落胆したり麻痺したりすべきではありませんが、そのように感じることは十分理解できます。

このような経験をする主な理由の一つは、ITがあらゆる状況で考慮すべき多数の変数を持つ広大な分野だからです。また、どんな問題に対しても多数の実行可能なアプローチが存在し得る、高度に創造的な分野でもあります。唯一の「最善」の選択肢が存在することはほとんどありません。通常、多くの競合する選択肢があります。これらが非常に密接に関連していることもあれば、まったく異なるために意味のある比較が非常に難しい場合もあります。

もう一つの主な理由は、要因が変化するということです。新しい技術や情報が明らかになったり、新製品がリリースされたり、製品がアップデートされたり、価格が変わったり、あるいはビジネスニーズが意思決定や設計プロセスの近く、あるいはその最中に変化することがあります。この変化のスピードは、IT専門家としてコントロールできるものではありません。受け入れ、できる限り対処していくしかないものです。

よく見落とされることとして、作成時には最適だったソリューションが、同じ決定を今日行う場合には最適でなくなっている可能性があるということです。これは元の設計の欠陥を意味するものでは決してありませんが、多くの人々がそのように反応するのを見てきました。この行動が最も見られる一般的なシナリオは、現代のストレージ設計におけるRAID 5の使用への嫌悪感です。RAID 6とRAID 10が正当な理由で人気の代替案となっています。しかし、2009年頃から一般的になったこのRAID 5への嫌悪感は常に存在していたわけではなく、1990年代中頃から2000年代末頃まで、RAID 5は実行可能なだけでなく、特定のビジネスおよび技術的ニーズに対して最善のソリューションであることが非常に多くありました（嫌悪感の増加はほとんど漸進的なものであり、突然ではありませんでした）。しかし多くの人は今日RAID 5を選択肢として問題があると理解しつつも、この新しい嫌悪感を何十年も前に設計・実装されたシステムに適用しています。これは意味がなく、純粋に感情的な反応です。2002年においてRAID 5がシナリオに最善の選択肢であったことは、2015年においてもそれが最善の選択肢であり続けることを意味しません。しかし同様に、2015年においてRAID 5がシナリオに対して貧弱な選択肢であることは、それが数年前に非常に優れた選択肢であったことを否定したり軽視したりするものでもありません。

最善とは言えない設計決定がなされた後にどうすれば良いかと、何度も聞かれてきました。「今どうすればいいか？」

完璧がもはや選択肢でない場合（すべてのITはトレードオフについてであり、本当に完璧だったことがあったとしても）に何をすべきかを学ぶことは非常に重要なスキルです。まず取り組むべきは感情的な問題です。それが他のすべてを損なうからです。できる限り一歩引いて、状況を受け入れ、合理的に行動しなければなりません。最後にしたいことは、最善ではない状況を、悪い決定を正当化しようとしたりパニックになったりすることでさらに悪化させることです。

完璧な設計はなく、常に完全に正しいことはできず、これに対処することはITの仕事の一部であることを受け入れることが最初のステップです。一歩引いて、深呼吸してください。そんなに悪くはありません。これはユニークな状況ではありません。設計を行うすべてのITプロはこれを常に経験します。できる限り最善の決定を下すよう努めるべきですが、それがほとんどできないことも受け入れなければなりません――そうするための十分なリソースにアクセスできる人はいません。あるもので仕事をするのです。さて、ここにいます。次は何ですか？

次は状況を評価することです。今どこにいるのか？多くの場合、実装は完了しており、これ以上することは何もありません。状況は理想的ではありませんが、悪いのでしょうか？すでに実装された設計に直面している人々が犯す最大の間違いは、コストが高すぎるということです――通常「より良い」ソリューションがより優れているのは、速いや信頼性が高いからではなく、安い、簡単、または実装が速いからです。それは残念な状況ですが、麻痺するほどのものではありません。費やされた時間やお金は、当時は許容できる金額であり、承認されていたはずです。今すぐできる最善は、意思決定プロセスから学び、将来の過剰支出を避けるよう努めることです。既存のソリューションが機能しない、あるいは驚くほどうまく機能しないということを意味するものでもありません。単に、関わるビジネスニーズ、主に財務的なものを考えると、完璧な選択肢ではなかったかもしれないというだけです。

実装された設計が規定されたビジネス要件を十分に満たしていない状況があります。これは、私の経験では幸いにもあまり一般的ではありませんが、はるかに難しい状況です。この場合、ビジネスニーズを満たすためにいくつかの修正を行う必要があります。これは高コストまたは複雑になる可能性があります。しかし、見た目ほど悪くはないかもしれません。これへの反応は誤解を招くことが多く、状況は多くの場合救済できます。

ビジネスニーズを満たせないソリューションを実装した状況にある場合の最初のステップは、ビジネスニーズを再評価することです。これは、私たちのシステムが満たすことができるものに合うようにニーズを操作すべきだということを示唆するものではありません、まったくそうではありません。しかし、もともと記載されたニーズが本当に有効かどうか、単に十分に検証されていないかどうか、あるいはより可能性が高いのは、実装が行われた期間中にビジネスニーズが変化したかどうかを確認するために戻って見る良い機会です。実装されたソリューションが、実際のビジネスニーズを満たしている可能性もあります。たとえそれらが最初に誤って記載されたり、時間とともにニーズが変化したりしたとしても。あるいは、ビジネスニーズが劇的に変化したため、完璧な計画でも当初の既存のニーズには届かなかったかもしれず、実装されたソリューションが期待通りに機能しないことが軽微な結果となる場合もあります。ビジネスニーズのこの検証が、不十分と信じられていたソリューションを、ビジネスニーズの過大表明に誰も反論せず、または特定の技術投資の財務的価値に誰も疑問を呈しなかったために実際に必要以上のコストがかかった「過剰」なソリューションに変えてしまったことが、非常に驚くほど頻繁にあります。

第二のステップは新しい技術ベースラインを作成することです。これは、ITがサンクコスト錯誤の落とし穴に落ちるのを防ぐための非常に重要なステップです。誰にとっても（ITに限ったことではありません）、プロジェクトに費やされた時間とお金を見て、どれだけ愚かであっても、そのパスにすでに多くのリソースが費やされているから、元の道を歩み続けることが正しいと思うことは非常に一般的です。しかし、もちろんこれは意味をなしません。現在の状態にどのようにして至ったかは無関係です。関連するのは、部門と会社の現在のニーズを評価し、現在利用可能なソリューション、技術、リソースを把握することです。現在の状態を考えると、最善の進路を決定できます。現在の状態に至るまでに費やされた努力を考慮することは、誤解を招くだけです。

サンクコスト錯誤の良い例はチェスのゲームです。各手において、現在の状態に至るためにどのような手が使われたかは今後の手に関係がないため、利用可能なすべての手、リスク、戦略を再評価することが重要です。世界最高のチェスプレイヤーや素晴らしいコンピューターチェスアルゴリズムがゲームの途中から参加したとしても、現在の状態がどのように生じたかについての知識は必要ありません――単に現在の状態を評価し、それに基づいた戦略を作るだけです。

これは、ITにおいて私たちが振る舞うべき方法と同じです。現在の状態は現在の状態です。戦略計画においては、その状態に至るために何が起こったかは重要ではありません。意思決定がどこで失敗したかを学ぶために事後分析プロセスを行う際にのみ、それらの決定とコストを気にします。自分自身とプロセスについて学ぶことは非常に重要です。しかし、それは現在の取り組みのための戦略計画を行うこととはまったく異なるタスクです。

ここでの残念なことは、計画プロセスを再び開始しなければならないことですが、今回はより多くのものを持って作業できると仮定します。しかしこれは避けられません。最悪の場合、予算はもはや利用できず、欠陥のある設計を修正して必要なビジネス目標を達成するためのリソースがありません。時には妥協が必要です。あるもので対処することが、時には私たちにできる最善です。しかし、大多数の場合において、追加予算と既存製品の創造的な再利用の組み合わせが状況を改善するために十分である場合が多いように思われます。

不足点に対処した状態に達した後、過剰支出、不十分な提供を受け入れるか、ニーズを満たすよう調整した後、意思決定プロセスに戻って調査する機会があります。これを行うことで、個人として、そして可能であれば組織レベルで、間違いから学んだり、間違いがそもそもあったのかどうかを判断したりすることができます。すべての会社とすべての個人は間違いを犯します。私たちを差別化するのは、それらから学び、将来同じ間違いを避ける能力です。成長は主にこのような痛みを経験することから生まれ、直面することはしばしば不快ですが、ここに真の持続的な価値を生み出す最良の機会があります。それが自分自身で行う厳しい個人的レビューであれ、そのために訓練された人々が運営する正式な組織的レビューであれ、あるいはその中間であれ、レビューのためのこの機会を先送りにしたり、スキップしたりしないでください。意思決定プロセスが評価されるのが早ければ早いほど、記憶は新鮮であり、軌道修正が早く効果を発揮できます。

最後のステップは、意思決定プロセスのレビューが完了したら、できるだけ早く現在の実装の代替品を設計するための意思決定プロセスを開始することです。これは必ずしも近い将来にお金を使ったり設計を変更したりするつもりだということを意味しません。まったくそうではありません。しかし、設計において非常にプロアクティブになることで、計画のための追加時間、要件収集と文書化のためのより多くの時間、要件を定期的に再確認してそれらが安定しているか変化しているかを確認することで時間とともに変化する要件についてのより良い洞察、経営陣や同僚の賛同と決定への投資を得る機会、問題領域のより良い理解を通じて意図した設計を変更したり、次に実装する前にそれを廃棄してやり直すタイミングをより良く知るなどで、過去の問題を避けようとすることができます。また、あなた自身が次のサイクルが来たときに意思決定や実装の立場にない場合、後継者に引き継ぐことができる組織的知識を体系化するより良い機会を与えてくれるかもしれません。

良い合理的なプロセスと、最善とは言えないシステム設計や実装の場合に取るべきステップの良い理解があれば、失敗から回復でき、ほとんどの場合、短期的に回復するだけでなく、将来の同じ間違いから組織を保護することができます。