形式論→意味論 X 見える化→自動化→エージェント。。。

　システム開発は、昔はプログラミング言語論などで、
どのような言語が効率的かとか、言語によるTipsの話が
多かったと思います。

　で、いまもそれはそうなのですが、自動化されてしまうと、
そのような形式論（形式言語）部分の話は、自動化対象と
なってしまい、むしろ、自分の業務を、どのプログラムに
マッピングしていくかという、意味論的な部分が中心に
なってくると思います。

---

さっきの、

見える化→自動化→エージェント

と話をあわせると、

●むかし

（１）プログラム言語の見える化
　→フローチャートやVISIOでいろんな図を書いたり
　　標準化された設計資料を使って書くなど・・

●いま

（２）プログラム言語の自動化
　brancoなどによる、プログラムの自動生成など、
　自動生成は、いま結構やられてますよね。
　ま、このブログもその辺の話が多いわけです。

（３）業務の見える化
　業務を見える化して、それを、プログラムに
置き換えていこうという流れ。
　UMLのアクティビティ図など

●ってことは今後は・・

　エージェント化は、ネットワークなどではやられているけど、
プログラムレベルでのエージェントとかは考えられる・・

　けど、（２）と（３）をつなげて、業務の自動化＋見える化
みたいな部分が先でしょうね・・

見える化→自動化→エージェント

　世間一般で、ここ数年、「見える化」がはやっているわけですけど、
　これは、見えないものを、見えるようにするということなわけです。

　グラフとか、経営資料であれば、「見える化」すれば十分かもしれない
けど、作業が伴うものについては、さらに、「自動化」してくれたほうが
うれしいわけです。

　たとえば、経営資料をかっちょいいFlashでグラフ化するのも、
それはコンピューター屋さんにとってはいいかもしれないけど、
どっちかというと、あぶない指標を自動的にチェックして、
そのグラフについて、先に出してくれたほうが、うれしいわけです。

　さらに、この自動化、決まったやり方であれば、１通りの方法を
自動化するだけでいいですが、環境に応じてやり方が変わるような
場合は、自律的にプログラムが動くエージェントのほうがいいわけです。

---

　まとめると、流れとして、

　　　　見える化→自動化→エージェント

であり、決まったやり方があるのであれば、自動化可能、

さらに、決まったやり方が状況に応じて変化するなら、
エージェント化ってことだと思います。

---

　ただし、じゃあ、決まったやり方があるから全部自動化すべきかどうか
という話にはならないのですが・・

　ただ、決まりがない、自動化できないものに対して、なにもしないって
いうんじゃなくって、それを、「見える化」できないかと考えたり、
決まりがあるモノに対して、「見える化」からさらに進んで、
「自動化」、「エージェント化」できないかと考えるのは、意味あること
だと思うんですよ。


ま、そもそも、この流れとかには、反論ある人も多いと思いますけど・・