３ヶ月以上は無限
何かを開発したいとき、「最初の成果まで3ヶ月以内にたどり着けるよう、技術的な環境を整えておくこと」が重要である。
あなたはスタートアップの責任者として、日々忙しく仕事をしている。開発バックログは山積みである。
そういったなかで、エンジニアから「これは重要な問題で解決が必要です――ただし緊急ではありません」というエスカレーションがあったとしよう。幸いにしてあなたは「この忙しいのに例の件はまだか！」などと言うことはなく、「それにはどのくらい掛かりそうか？」とエンジニアに質問した。
そのとき「３ヶ月以上掛かるかも知れません」とかえってきた場合、おそらくその問題に取りかかる機会はやってこない。もし「分かりませんが、２ヶ月ちょっとだと思います」なら日の目を見ることがありそうだ。
つまり、ソリューションの実現期間には暗黙の崖がある。３ヶ月を超えると、事実上そのソリューションは選択肢として機能しなくなる。これは非常におそろしいことだ。
考えてみてほしい。ご存じのように、技術的負債というものは放っておくと溜まる一方だ。負債がたまると、開発に必要な期間は徐々に伸びていき、あるとき３ヶ月を超える。そうするとその選択肢は選べなくなってしまう。
技術的負債は経済的負債のメタファーだが、違うのはこの点だ。借金が１億円あってもまず100万円返すことはできる。しかし技術的負債は、大きすぎると返済そのものができなくなる。
Kent Beckは書籍 "Tidy, First?" で「設計はオプションである」と表現した。設計とは将来的な選択肢を広げ、迅速な意思決定と実行を可能にするための活動である。この延長線上として、ビジネス的な選択肢をリスクテイクできる期間内に収められるようにしておくことで、事業戦略の幅を担保しておくことが重要である。
生成AIはポイントとして下記を挙げたが、執筆者としては的を射ていないと感じる。個人的な意見だが、「作り込まないこと」「シンプルさを保つこと」「後戻りできない決定は先送りすること」が良い指針になるだろう。
具体的には以下のポイントを押さえることが求められる。
- モジュール性と疎結合な設計
各コンポーネントが独立して変更や拡張できるよう、明確な境界を持つモジュール設計を心掛ける。- スケーラブルなインフラ基盤の整備
あらかじめスケールアップ・アウトが容易なインフラを構築し、負荷増加や新機能追加に迅速に対応できる準備をしておく。- 標準化された開発プロセス
開発環境やデプロイメントの手順を自動化・標準化しておくことで、新たな要求に迅速に対応可能な体制を整える。- 継続的な改善と技術負債の管理
定期的に技術負債を整理し、コードやシステムの品質を一定以上に保ち続けることで、将来の開発スピードを維持する。こうした準備を整えておくことで、新しいビジネスアイデアや市場の変化に素早く対応でき、意思決定の柔軟性と機動性を確保することが可能になる。
エンジニアリング組織としては、この「3ヶ月で実現可能な設計オプション」を意識的に維持し、戦略的な柔軟性を持つことが、競争力のあるビジネスを構築するために不可欠である。
この記事は、文責者の骨子からAIが生成した文章を元にしています。
Discussion