勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェア開発における将来要件の扱い

ソフトウェア開発におけるムダ | Ryuzee.com の記事が面白かった。別にアジャイル開発プロセスに限らず、ソフトウェア開発にはいろいろな無駄がある。身近でときどき出てくる種類のムダとして「将来の再利用性などの要件を折り込む」ということがある(「使わない機能」の一種かもしれない)。「技術的負債」の逆バージョンについて。

ソフトウェア開発における将来要件の扱い

よくあるのはこういった話。

  • 将来の機能拡張を考慮したシステムを構築するという「要求」がある。
  • 未来の要件変更を考慮した機能設計をすることが要求される。
    • 未来の要件変更を考慮した汎用性が求められる、といった場合もこのパターンか。
  • 機能拡張時のコスト削減のために、将来の再利用を想定したものづくりが要求される。

アーキテクチャレベルで将来の変更を想定したり、そもそも変更しやすい設計を行うことは可能だ。しかし、上記に上げた要求に対しては「未来の要件」を仮置きで決めて開発せねばならず、それが難しい。費用対効果的な疑問もある。最近は「技術的負債」という言葉は一般的になってきた。技術的負債をできる限り減らすことは重要だ。しかし未来に対する先取り=「技術的投資 または 設計上の投資」はあまり合理的とは思えない。

未来の要求を決定することは難しい

そもそも、現在必要とされているソフトウェア要求を特定するのも困難なのに、未来の要求を(仮置きでも)定めるのはとても難しい。

  • ソフトウェアの真の要求は「使ってみないとよくわからない」。さらに未来の要求はもう「まったく仮想的なもの」である。
  • 将来の外部環境の変化についてはある程度予測は可能だが、それでも不確実性が残る。
    • 法的制度の変更など明確なものは除く。

そもそも未来は本質的には不確実である。完璧な未来予測が成し得ないのであれば、それに対するものづくりもムダであろう。

将来の再利用を想定したコンポーネントをつくることも難しい

再利用可能なコンポーネントを作成することは単一なモジュールを開発することに比べて3倍以上難しい。これに加えて要件の未来予測を行うとなると、検討するまでもないと思う。

じゃあどうする?:拡張性を残し、現在に集中する

冒頭のような要求がされた場合には、将来の変更を考慮した拡張性を残した設計を図るが、将来要件は取り込まないとするのが良いだろう。

  • 将来要件は断り、変更容易性などの非機能要件として充足するようにする
    • まだ使ったことはないけれど、仮想の変更要件を仮定して、変更容易性についてストレステストをするようなアプローチもいいかもしれない
    • 対応しやすい変更と、対応しにくい変更を明確にして、将来要件を現時点で取り込むべきかの判断は出来るだろう

ソフトウェア開発は不確実性の影響を受けやすい仕事である。常に現在(もしくはちょっとした将来)に注力すべきであって、足止めとなるような技術的負債ができるだけ少なくなるようにするのは言うまでもないが、あまり遠くを見通すことも考えものだ。未来のビジョンを持つのはかまわないが、未来の仕様を先取りするようなことは避けるべきだろう。