多種多様なチームでの業務経験を経て、Greg Young はプロジェクト内でチームはしばしば根本的に過剰なエンジニアリングを行うことを発見した。チームは9か月のプロジェクトを開始するが、異なる観点から問題を考えることにより95%の価値をほんの数週間で提供することが可能であるかもしれない、そうYoungはロンドンで最近開催されたDDD eXchangeの基調講演で主張した。
この過剰なエンジニアリングの理由は私たちが不正確な成果物を構築しているからである。Youngにとって大きな問題は、人々が本当に必要なものに十分焦点を当てられていないということである。二つの全く異なる取り組みかたで人々が必要としていると考えるものに焦点を当てる。機能の使用状況は、本当に数少ない機能だけを実装することにより実際の使用では多くの場合問題がないということを意味するパレート分布に頻繁に従う。稀に使用されるユースケースの残りの部分を補うことは少ない成果しか得られないわりに多くの努力を必要とするだろう。
Youngは、ソフトウェアはより広範なシステムのたった一つの部分でしかないことを強調する。ソフトウェアの周辺には全体のビジネスプロセスが存在しており、特定の課題はソフトウェアの代わりにビジネスプロセスを通じて解決されることになると言っても全く誤りはない。最悪ケースに関することや、それをソフトウェアでどう解決するかということを議論しすぎている。もし業務の99.9%以上を自動化できたとすると、しばしば残りの部分はドメインの専門家による手動の取り扱いに任せることができる。
手動の介入が必要なら、人間がやればよいのだ!
Brownfieldプロジェクト(訳注: レガシーシステムの存在を前提ととしたシステム開発プロジェクト)は過剰なエンジニアリングが発生しがちな領域の一つである。Youngにとっては、これらのプロジェクトは過剰なエンジニアリングを防ぐことが容易なプロジェクトでもあり、どちらの理由も経験とデータの取り扱いに起因する。ドメインの専門家による列挙や実際のシステムを稼働させることにより基本的なユースケースを発見することで、おそらく使用方法の重要な部分を検討対象とすることができるだろう。不幸なことに、起こりうる境界条件についてドメインの専門家とあまりに多くの議論を行う傾向があり、この結果製品では稀にしか使用されない大量の複雑なコードを記述してしまうことになる。Youngは全ての複雑性はシステムのモデルに非常に影響を与えることを指摘している。
Greenfieldプロジェクト(訳注: 既存システムの制約を受けないシステム開発プロジェクト)は同じように過剰なエンジニアリングが発生しがちな領域はあるが、実際の使用方法を知ることができない。これを克服するためにYoungが推奨していることは、継続的にデプロイを行い、デプロイして二ヶ月後にリリースするということに対して事業サイドと合意を取り付けるということである。この時間の間に、システムを使用し、稀にしか使用されない機能を実装することを防ぐことを可能とするデータを収集するというのが理由である。Youngはまた、最初のリリースの後は機能に対してではなく、バグに対してのみ作業を行うことも提案している。システムに欠落している全てのものはバグとして報告される。彼の経験上、事業は一つの事柄、つまりバグだけを優先するので、これはとてもうまくいくのである。彼はこのやりかたが内部のユーザによる内部のプロジェクトの場合のみに対して有効であることを指摘している。この戦略は固定価格の契約や公開Webサイトには適切でない。
Greenfieldプロジェクトにおいては、私たちは想像上の世界に存在するのである
プロセスマネージャパターンやオーケストレータはYoungが過剰なエンジニアリングが発生すると指摘する第三の領域である。彼は複数のサービス間のオーケストレーションを実際に成功させている例をほんの少ししか見たことがない。偶発的な複雑性が押し寄せることにより実装が大きなプロジェクトに変化してしまうというのが唯一最大の理由である。これ以外の他の例においてさえ、プロジェクトは基本ユースケースを発見することに失敗し、代わりに物事が失敗しうる全ての方法を列挙する傾向にある。
Youngはシステムが人間から完全に業務を取り上げることを常に意識する必要はないと要約している。業務の99%を肩代わりすればほとんどの場合は十分であり、残った1%を取り上げることはしばしば経済的に価値があることではないのだ。
来年のDDD Exchangeは2017年の4月後半に予定されており、既に登録が可能である。