３０年くらい前は、銀行や大手企業など特定の業種で特定の業務にだけ使用されていました。だから、コンピュータシステムを構築する際には、要件定義（どんな業務でどのような事を行うか）を決め、仕様書（プログラムの機能を詳細に記述したもの）を作成し、初めてプログラミングを行うとい方式が一番効率的でした。いまでも基幹システムでは同様の手順を踏むケースがありますが、昔みたいにやるべき仕事が明確になっていない（目的はあるが、方法が明確でない）場合が多く、昔の方法では対応が困難になってきています。

​

特に、近年、あらゆる業務、手作業で行ってきた仕事、感で判断していた仕事もシステム化の対象となったことから、最初からこうすべきであるという「回答」がないまま、手探りでシステム化を行う必要があるようになりました。

​

しかし、１０年以上前にシステム開発に携わっていたエンジニアは、昔の仕事の手順から抜け出せておらず、相変わらずの方法でシステム構築を行おうとします。

その結果、机上で考えて仕様書を作成するため、実際には使いもしない沢山の機能や、あらゆる事態に対応するための数多くの機構などを実装することにより、高価格化と長期化が発生してしまいます。

​

そもそも、過去のシステム開発は、全て自前で開発する必要があため、システム全体の設計図が重要だったのですが、現在は多くの実装したい機能は部品化されて、メーカーやオープンソースで提供されており、主な開発舞台はビジネスプロセス（何をどうするか）を構築することになっていて、割と簡単に組換えが可能となっています。

加えて、不確実性をはらんだ現状のビジネスプロセスをそのままシステム化しても大幅な業務効率化は望めません。つまり、やってみて不都合があったら作り替えることが容易になったのです。

​

イノベーションは仮説立て、実行してみて、結果を評価してより良い方法を探すことにより起こせます。そこは不確実性の世界であり、先が見通せない世界です。そのような現状でシステム構築に完全性を求めること自体が不可能なのです。

​

もし、皆さんの上司や役員の方、さらには、システムベンダーとお話される場合、この不確実性の世界でイノベーションを起こすための方法を議論してみてください。

​

私は、要件定義ありきの開発（ウォーターフォール方式）も、やってみる方式（アジャイル方式）でも開発した経験があります。両方とも良い面がありますが、Web時代にマッチした開発手法は、やはりアジャイル方式だと思います。

​

もし、ご興味があれば私にご連絡ください。一緒にどうすればいいのか考え、実行してゆきましょう。