背景
開発初期の段階で、画面、フロントエンド、バックエンド、データベース、インフラなどシステム全体で様々な設計が開始された状況。
アンチパターン
拡張性を重視する
解説
あなたはPM兼アーキテクトとして拡張性を重視して設計するよう方針を他のエンジニアメンバーに伝えます。
まともなシステム開発を経験してきたエンジニアメンバーは、過去のいけてない設計のシステムの負債を精算するために辛酸を舐めた経験を持っているはずですので、開発初期の頃から拡張性を重視する考え方には賛成します。
その結果、拡張性を高めるためにシステムの抽象度を上げ、どのような抽象化を行うかの議論が活発に行われます。その結果、設計書に記載される用語の抽象度はあがり、新規メンバー向けの解説なども必要になってきます。
新規システム開発でまずは到達しなければいけないのは、ユーザにシステムをデリバリすることです。
まだユーザのついていない新規システム開発の道筋は、あまりにもか細く、いとも簡単に方向転換を余儀なくされます。社内の方針変更、顧客意思決定者の一言、予算の調整、人員の離脱、その他社内政治的な内容..などなど様々な要因があります。
新規システム開発責任者は、これらの方向転換の発生する要因とうまくバランスを取りながら、デリバリまでこぎつけなければいけません。
その際に有効な方法の１つが、とにかく早くデリバリまでこぎ着けることです。 言い換えると、新規システム開発で最も重要なのはデリバリまでの速度です。
いかに拡張性を高く変更に柔軟なシステムを開発していても、開発が停止してしまっては何の価値もありません。 いかに拡張性高く変更に強いシステムを設計したとしても、開発初期の段階でビジネスサイドのピボットの方向性を予想することできず、その変更に備えることはできません。
開発初期の段階で拡張性を議論するときは、それは何に対する拡張性で、それは本当に今必要かどうかを吟味してください。それを今実施しない場合後になってどのくらいの負荷がかかるのか検討し、可能な限りその作業を遅らせてください。
後で負債となる設計にエンジニアメンバーは納得しないかもしれません。というより大抵は納得しません。 新規開発システムの最重要課題はデリバリであること、それらの技術的負債の返済は然るべきタイミングで実施することを十分に説明する必要があります。
アンチパターンとならない場合
契約や関係者の合意によりシステムがデリバリに至る道筋が明確に見えている場合、上記の不確定要素が少ないと考える場合、設計に議論する時間をもっと割ける場合もあります。
