完全な知識という誤った考え

私たちはみな心の奥底では、すべてを知っているわけではないことを知っています。うまくいけば、私たちは毎日少しずつ、自分の専門分野や社会、自分自身について学んでいきますが、それでもすべてを知ることは到底不可能です。しかし、学ぶのをやめてしまうと、すぐに落ちこぼれてしまいます。ソフトウェア業界では特にそうです。そうなったら残りの人生、別の職業や他の仕事に弟子入りすればよいと考えているなら、あなたはドードー鳥†と同じ運命をたどってしまいます。

今の私たちの時代、土台としているテクノロジー、テクニック、アイデアはあまりに急速に変化します。私たちは絶えず学ばなくてはなりません。また同様に、私たちは無知にも対応しなければなりません。必要な知識を調査するために、プロジェクトの一部を費やす必要があるのです。それなのに、なぜ私たちは、開発フェーズにおいてプロジェクトに関するすべてを知る必要がある、あるいは、知ることができると偽り続けるのでしょうか？

ソフトウェア工学の歴史とは、ソフトウェアが品質欠陥によって失敗しないように、注意深く統制された開発工程および保守作業により、プロジェクトをいかにコントロールするか、という試みの歴史でもあります。伝統的な「ウォーターフォール」型などの方法論の多くは、十分な時間と実直な勤勉さがあれば、ソフトウェアプロジェクトは完全に理解可能だと仮定しています。ここでは、たいていの場合、コードを書く前に要件が確定されていることを要求しています。なんてばかばかしいことでしょう！

開発中にすべてを知ろうと思わずに、後になればすべてがわかると考えることもできます。スパイラルやアジャイルといったソフトウェア開発方法論はそう仮定しています。そこでは「最終的に確認された」要件に基づいてソフトウェアを開発し、納品するために、イテレーティブな開発が重要だと考えています。残念ながら、こうした方法論の支持者にとって、ソフトウェアプロジェクトの納品は開発の区切りにすぎず、完了を意味するものではありません。

事前の詳細設計によって「合意」されていたとしても、要求は開発中に変化するものです。前もってすべてを知ることは不可能なのです。複数の要求が矛盾していることもよくあります。たとえ情報源がひとつしかなくてもそうなのです。人によって同じ要求が別のものを意味していることもあります。それぞれ解釈が異なるのは、見識や目標、言語が異なるためかもしれません。ソフトウェアプロジェクトを成功させるためには、こうした考え方を受け入れて、さらには喜んで応じなくてはなりません。私たちはすべてを知りませんし、決して知ることもできないでしょう。

完全な知識という誤った考えは、ソフトウェアプロジェクトのための完全で矛盾のない要求が獲得できるという妄想のことです。現実には、ソフトウェアプロジェクトのライフサイクルのいかなる時点においても、要求が完全にわかることはありません。分析フェーズ、開発フェーズ、保守フェーズ、システムがレガシーであるときですらそうなのです。

イテレーションやリファクタリングといったアジャイルテクニックをソフトウェア開発ライフサイクルの保守フェーズにおいて継続的に活用することで、いくつかの懸念は解消されていきます。ソフトウェアがどのように進化するのか、もっと理解することが次のステップになります。このような概念的なツールを手に入れて、それらを日々活用し、規模を問わず無知を受け入れましょう。そうしない限り、私たちには完全な知識という誤った考えの犠牲になり続けるでしょう。