今やどこを見ても、「変革」「改革」「イノベーション」「創造的破壊」など、変化に素早く対応することの大切さが強調されています。

　確かに変化に対応できなければ、あのマンモス象が、その巨体のために地面の草を食べることができずに滅びていったように、人間社会においても、それは例外ではありません。現在は、過去に記録されている人類の歴史の中で、かつてないほどのスピードで変化が起こっている時代であると言っていいでしょう。

　そして、今やリスクを冒すことに対するリスクよりも、リスクを冒さなかったことに対するリスクの方が大きく、台風がじっと通り過ぎるまでを待っていても、何もなく通り過ぎることがなくなってしまいました。何か手を打たなければならないのです。外に出て、窓に板を打ち付けたり、家につっかい棒を当てたりしなければ、家が飛ばされるほどに、この変化の風は強いのです。

　こういう経験をされた方もおられるのではないでしょうか。つまり、新しいシステムを開発するために、システム分析や設計を行ったが、あまりの環境変化の速さに設計した時点でもうすでに古くなってしまったと・・・。実は、これは笑い話しではなく現実に起こっていることなのです。

　では、どうするか。

　それには、「変化に容易に対応できる【変更容易システム】にするしかない」ということではないでしょうか。

　よく情報システムに関する雑誌を読んでいますと、これからは開発の時代ではなく、自社の取引形態や事務仕事をパッケージソフトウエアに合わせる時代だ、などと言われていますが、本当にそうでしょうか。

　もちろん、自社独自にシステムを開発しても、パッケージソフトウエアの機能や信頼性にかなわないということもあるでしょう。また、自社の仕事レベルがまだ低く、パッケージソフトウエアを導入したほうが仕事レベルの向上になることもあるでしょう。

　しかし、企業は日々に進化していくものです。ですから、ある時点において、このパッケージソフトウエアはうちの会社にぴったりだと言っても、その先もぴったりであるという保証はありません。もちろん、企業が成長していかないなら話しは別ですが・・・。

　例えば、中学１年生のときの学生服を高校、大学と着続けなさいと言われているようなものではないでしょうか。親は、服を買い換えるのいやなので、子供に成長してはだめだと言うでしょうか。

　ソフトを開発するときも同じでしょう。激変する環境の中で将来の変化に対応できることは、システム開発においてもこれからますます重要になっていくでしょう。

　ただ、会社の中には、どの会社にも共通するほぼ固定化された仕事もあります。例えば、税務上の会計処理をしたり、会計上の定まった帳票を出すような仕事がこれに当たるでしょう。

　こういった仕事には、使えるパッケージソフトウエアが見つかれば、当然導入するほうが独自開発する場合の何十分の１のコストとなります。

　つまり、これからは会社の中でも変化の大きいところや、差別化のための独自性を出さねばならないところには、できるだけ自社の要望が反映されるシステムとし、それ以外にはコストのかからないパッケージソフトを導入していく、それぞれの特徴を生かした「複合システム」としていくことが必要だとも言えます。

　これは、一見社内を一枚板で統一するというＥＲＰの考え方とは異なる考え方ですが、それらのプログラム群（モジュールと言ってもよい）をつなぐことによって統一をなし、価値連鎖を実現していくことが可能となります。

●仕様変更の問題

　さらに、システムを開発する場合において、よく問題とされる項目に、「仕様変更」の問題があります。システム設計が終わってからの仕様変更は、システム開発者からはすこぶる嫌がられる問題です。

　なぜなら、進められてきた開発が後戻りを余儀なくされるからです。納期の延期や、費用面での加算などがあればまだしも、もし、それもなければ開発者にとって苦しみ以外の何ものでもありません。

　でも、よく考えてみたいのです。システム開発者は、上流工程、特に要求仕様の確定が極めて大切でそのために「ユーザ教育」が必要だとよく言います。

　確かに、発注者が何をやりたいのかも決められずに、システムの開発を依頼することはできませんので、それもその通りのところがあります。しかし、これも「程度の問題」で、完全に要求仕様が決められるべきだとする開発サイドからの考えには、極端があるのではないでしょうか。

　自分もそうであるように、人間というものは現実に具体物にさわってみて初めて、ここがこうなっていればいいのにと気づくところがあります。ですから、画面の内容も設計段階のときはこれでいいと思っても、実際に使い始めてから気づく不具合なども多いものです。

　さらに、ユーザでも中堅・中小企業においては、システムの専門家を置いていない場合がほとんどです。そして、そこで働く社員の方々は、新しいシステムの仕様を考えるよりも、今日の自分の仕事をこなすほうで精一杯のところがあります。そういう方々に、要求仕様を完全にまとめて下さいと言う方が無理があるのではないでしょうか。

　だからこそ、もし後で要求仕様に対して変更が発生したならばお互いによく話し合い、将来の姿までよく意見交換をし合って問題解決をしていくことが大切ではないでしょうか。でもこれは発注者に何もしなくても良いと言っている訳ではありません。

　つまり、発注者のほうは出来るだけ時間を割いてしっかりとした「要求仕様」をまとめ、一方、受注者は、「仕様変更は起こり得るものである」という考えのもとで、システムの開発を行うことが大切であるということです。

　そのためには、システム開発ツールに何を用いるかということが、すこぶる重要なポイントになってきます。

　つまり、画面のレイアウトや、色や動き、帳票のレイアウトやその印字の形式などが、ワープロを扱うように簡単に行えることが必要となってきます。ましてや、Webのページ記述（Html記述)と、プログラムロジックが一緒になっていては、後での変更は大変な作業になってしまいます。ですから、変更に対する影響度の少ない開発形態やツールを採用することが重要となります。

　余談ですが、プロのプログラマは、優秀であればあるほど細かいところまで指定ができないという理由で、なかなか簡単なツールを使いたがらないものです。でも、これからはシステムのクセや動きの全てを知り尽くした優秀なプログラマこそが、簡単なツールを使ってプログラムの生産性と保守性を、大きく上げていくことが大切ではないでしょうか。