いいけどね！
せっかくコメント無視、匿名で書いているんだから、
もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。
最近、IT業界って、暗いとおもいませんか？
村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。
こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。
ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。
さらに、テストに関しても、修正によって、影響が大きい場合、一時的に待つ等ということが行われました。つまり、テスト修正に対しても、管理されていました。これによって、仕様の矛盾がないように机上チェックが十分行われていました。
しかし、アジャイル、とくにテストファーストにより、とりあえず仕様を作って、プログラム作っちゃおうっていう感じで開発がおこなわれました。仕様の矛盾チェックを十分にやることなく、プログラミングされます（そーいえば、仕様チェックを行うSEの地位も、がっくーん！と低下したよね。プログラマの地位が急激に向上して、立場が入れ替わった）。
その結果として、安易な仕様変更がおこなわれ、五月雨式に仕様変更がおこり、その結果として仕様の矛盾が起こる。そのうえ、その矛盾は、つくってから気付く。結合テストで（さすがに、単体レベルの矛盾は作る前に気付く・・・と思いたい ＾＾；）。
結合で、すぐに修正してしまうから、安易な対処的修正にながれ、さらに構成管理も崩壊し、結果として、デスマーチに突入、７K,１０Kの世界になる。
でも、ユーザーはこれ幸いと、結合テストの期間が延びると、仕様変更をガンガンしてくるから、開発終了直前まで仕様変更される。。でも、アジャイルはこれを防ぐ論理がない。仕様が決まれば、プログラミングに移ってしまう。。
この結果、さらに矛盾は拡大し、システムは崩壊し、品質は低下し、人身御供は増え、業界は不幸になった・・・
この業界を少しでも幸せにしたいなら、
昔のように、要求仕様管理が必要になる。
要求仕様の変更を管理し、仕様変更の無矛盾性を確認し、その影響度合いを評価し、そこから、修正箇所とテスト項目を過不足なく抽出する技術が必要になる。
で、こーいう要求仕様管理は、法令における「溶かし込み」という作業と同じことで、法令工学での研究対象のようだ。
この分野の研究成果を応用し、要求仕様の変更を管理し、その仕様がほかに矛盾を起こさないかチェックし、その影響度合いを適格に評価したうえで、必要な仕様変更だけを、適切なタイミングで行えるような開発方法論を生み出してくれれば、この業界、少しは幸せになれそうな気がする。
法律は、実体法と手続法に分けて考える考え方があるが、手続法は、業務フローの機能要件のようなものであるといえる。したがって、手続法における法令工学の成果は、要求仕様の機能要件の策定に多いに貢献できる可能性を持っている。
しかし、法令工学の人たちが、こういうことに応用できると言い出さないのは、たぶん、そんなことをいって、アジャイルな人たちに邪魔されたくないんだろう。法律にアジャイルを持ち込めば、法が朝令暮改され、法の矛盾から社会は混乱し、人々は一挙に暗い社会に陥ってしまう。
IT業界のように・・・
ってことで、法令工学を応用することにより、IT業界が明るくなることに、期待はするけど、アジャイルな人たちが入ってこないように、そーっと見守っていく分野なのかもしれない。
しかし、「これでいける！」となったとき、法令工学を応用して、一気に要求管理方法を取り入れた開発方法論におけるパラダイムシフトが起こる可能性も大だ。
だから、JAISTのCOEの検証進化可能電子社会の今後には、そーっと要チェキなのだ！
アクセス
トータル
ランキング
