２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第２５回目。
いままでで、その変遷をふりかえってきました。今日は、「で、結局、ソフト業界は変わったのか」ということについてです。
■ネットについては、たしかに変わった
ネットについては、たしかに変わりました。
さっきのNetscapeのはなしもあるけど、昔は、NetWearのLANやパソコン通信だったのが、インターネットがでてきて、一挙に別次元の世界に変わっていきました。
このインターネットも今後、どのように変わっていくのか、まだまだ期待がもてそうです。
（期待しすぎ・・ ＾＾；）
■開発の分野は？言語は確かにいろいろ出てきたけど
では開発の分野は？というと、言語は確かにいろいろでてきました。
COBOL／Fortran／PL1からC、C++、Java、perl,PHP,Ruby、クライアントではjavascriptと
まあ、いろいろ変わってきたのですが、逆な言い方をすると、決定打があるわけではない。
そして、今後も言語が生まれては消えしていくんだろうけど、決定打が出ない理由である、言語として、なにを表現すればOKなのか？という部分がはっきりしていないと思う。これさえ決まってしまえば、それを表現する表現力のある言語を開発すればいい。
いくつかの言語が必要になるだろうけど、その分野においては、その言語で決まり！っていう形になるだろう。
で、これをはっきりさせるには、世の中の仕様の大枠を決定してしまえばいいんだろうけど問題は。。
■開発方法論に関しては、発展したのか？
この世の中の仕様の大枠を決めるための、開発方法論という点について考えると、はたして、発展したのだろうか？
構造化設計がでて、オブジェクト指向がでて、アスペクトにいき、アジャイルにいった。
しかし、では、構造化設計やオブジェクト指向は、仕様に対して、どこまで表現でき、それをコンピューター上に、どのように、落とし込むのか、どこまで落とせるのか？を明確にしているとはいいきれない。どのように落とし込むのかについては、たしかに「方法論」というのだから、きまっていなければ話にならない。しかし、どこまで表現できるのか、表現したものが正しいのかという論証は全く行っていない（DFDは多少やっているけど・・）。
これでは、バグが出てきて、当然だ。なんたって、書いた仕様書やプログラムが正しいことが論証できないのだから。
■この点において、失われた２０年といえる。
この論証は、数学を援用して行う。
ホーア論理やダイクストラの検証論が、かつて出てきたわけだが、それを応用し、論証していくことになるだろう。
このプログラムの検証論と開発方法論を結びつけるという分野は、１９７０年代からいままで、まったくやられていなかった。といっていいだろう。
つまり、いろんな方法論は出ては消え、出ては消えしてるけど、その方法論を使って、正しいプログラムが書けるという保証もないし、そのためには何をしたらいいかという制約もはっきりさせていないという状態が、２０年以上も続いたことになる。
これじゃあ、バグバグシステムが量産されたって無理はない。なんたって、ちゃんとしたシステムができる（数学的）裏付けはないのだから。
＊ただし、ハードのほうでは、すでに数学的検証に基づいた開発は行われている。
■この失われた２０年が、今、かわろうとしているのかもしれない。
しかし、この辺の分野、数学的レベルでの論証をベースにおいて、システムを構築していき、裏付けをもって開発し、どこまでの範囲で正しいと言い切れるのかを吟味していく分野は、最近始まろうとしているのかもしれない。
たとえば、UMLのクラス図を論証していく、兼岩 憲 氏の「UMLクラスダイアグラムの矛盾検証」などがあげられる。
この辺の数学的論証という立場や、計算理論、計算可能性と、各種開発方法論、言語などが結びついてくると、この言語、方法論では、何が表現できて、表現した内容が正しいのか、正しくないのかについて、体系化・さらには自動化ができてきて、あらたなブレークスルーが起こるであろう。
最後の結論が、論理のジャンプが激しすぎてしまいました。
もう一度、別の機会に説明します（年明けにでも）
ということで、このシリーズは、今回でおしまいです。
アクセス
トータル
ランキング
