何でも自動化
Posted by michy on 4月 21, 2005 in 妄想、バトン、思いつき
日経のニュースでにこんな記事が載ってた。
→NEC子会社がシステム構築の新サービス、業務プロセスを定義するだけでアプリを自動生成
顧客から、業務についてヒアリングして、そこから業務プロセスを定義するデータを作ってあげると、そのデータから業務に必要なプログラムができあがるらしい。
業務プロセスを定義するだけでアプリケーションをほぼ自動で生成できることが特徴。「システムの開発中や開発後に業務内容が変更しても、容易に反映できる」
ほんとかよーー！！！業務プロセスってどうやったら定義できるの、私も定義して自動化したい、って思って業務プロセスで検索。自動化できるなら、自動化したい仕事でいっぱいだよ。
→第2回 オブジェクトモデリングの基礎としてのデータモデリング
…あたり前だけど、すっごくややこしいことをやらないと業務プロセスって定義できないのね。
挫折。
しかも、元記事をよく読んで見たら、
NITSはCGAA/ARISを使ったシステム開発を1システム当たり5000万から5億円で請け負い、今後3年間で180億円の売り上げを見込む。当面、対象とする顧客は製造業と流通業である。
あ、自動的につくってくれるだけなのにそんなお金とるのね…。もちろん、「プロセスの定義」でかなりお金をとるんだろうけど。そりゃ、「なんとなく自動化」だ。
しかし、定義したらプログラムできるって、それは美しく無駄の無いオブジェクト指向なプログラムなのかなー。美しくなくても動けばいいなんて、私はそんな考え方は嫌いだーー！！！（だから、プログラマは挫折した…）契約書もプログラムも、意味さえとおればいいんだろうけど、後からのメンテナンス性とかを考えると、絶対にきれいに作っておいたほうがいいの。それにそれが私の美学にかなうの。
業務フローを計算機に理解可能な形式にさせるだけで、こんなに難しいなら、契約書のXML化は遠いなと思った…。
やっぱ、コンピュータのCPUがノイマン型じゃ無理だ。
4 Comments
コメントをどうぞ
-
カウンタ
リンク
オイシックスとか、冷凍食品コーナーとか、実にヤバイ
楽しいiPhoneアプリを見つけると幸せになれる。iPhoneの正体は実は育てゲーなのかも
さりげなくいい曲があるのがフリーダウンロードの不思議
amadanaのケトル。罪な外観です
amadanaのコーヒーメーカー。ケトルと一緒に揃えたくなります
深沢直人デザインのLEDデスクライト。シンプルで機能的で、本読み用にかなり欲しいです
EIZOの新しいモニタ。AV入力対応です。PS3もXbox360も1080pでイケて、PC画面上に同時にAV画像も表示出来るみたいです。キレイな画面でゲームしながら、テレビ見ながら、ネットサーフィンに
なかのひと&うごくひと
ランキングリンク
こんばんは(=ﾟωﾟ)ﾉ
逆に俺は構造化なしで進む契約書とか恐ろしいな
(^^;)
多分はっきりと明示しなくて、なんとなくみんなそれぞれのカラーでやっているのだと思うけど、それを一度決まったフォーマットにしてあげれば後々仕事が楽になるのではないかな。とはいえ俺にはわからない苦労がたくさんあるのだと思うけど。
XML 化といってもそんなに構える必要はなくて、定義が自由なDTD という仕組みがあるのでどんなフォーマットでもちゃんと構造化すればXML(DTD)仕様としてOK なのですよ。
ただしどんなにCPU が高速でも、それに何をさせるかは人間の脳みそを使わないといけないものね。
構造化スキルは僕も勉強中です。
職場でも、ちゃんとしたエンズニアはそういう能力も高いですよ。
業務プロセスを定義して、アプリ作成自動化ですかぁ。
かなり眉唾ですよね（笑）。
私はシステムエンジニアをしていましたが、やはり定義
することは困難でした。それは技術的な面よりも、
むしろ業務それ自体が曖昧なもので成り立っているた
めでした。
最近は、そういった曖昧さをなくして、業務定義を
行い、暗黙知を組織知に変えていこうという考えもあ
ります。つまり「業務のマニュアル化」を進めましょ
うということですが、これによってみんなの力で業務を
より善くしようというのがねらいです。
このアプローチの最大の成功例は、なんと言ってもト
ヨタ自動車ですよね。
>>グッサン
構造化された契約書、理想だね。
契約書はプログラムが実現したいことによって違うのと同じく、実現したいビジネスによって書くべきことが違うの。そして、人間が解釈するので、人間が理解できることは飛ばして書いても間違っていても恥ずかしい思いはするけど許させるし、実行できちゃう。
でも、間違いに途中で気づく（締結前の回覧に出してる段階で気づく）人が多くて、しかも日本語にみえるからみんな好き勝手に直すんだよねー。
多人数が好き勝手に直したプログラム、しかもデバッグしなくても動く、、、怖くない？？
そして、その上、そのうち事情が変更になって「あのビジネスやっぱ辞めます」ってことになって、「元の契約書のここをこう読み替えましょう」っていう差分だけが締結される。（最初から変更しようとすると、やたらと文句いう人がいるのと、変更点を明確にしたい意図からこうすると思われる）
……解読できないっす。
きちんとできる人は構造化や抽象化が上手なのは私もそう思う。先輩はやっぱりそういうの上手。でもね、日本語だから他の部署の人もみんな好き勝手文句言うんだよね…。それが苦労。もちろん、最後はうまく抽象化した文書でまとめるべく法務が腐心するわけですが、全部の契約書が全部、そういう技術のすぐれた法務部員の手にかけられるかというとそうでもなく。
>>nbdyさま
アメリカはJob Discriptionがあって、曖昧さがないようですね。でも、私は曖昧さは日本のよいところだと思うので、あまり排除しすぎる考えは好きじゃないです。
とはいいつつ、矛盾するようですが、マニュアルづくり好きですよー。私も共通かする部分は暗黙知を組織知に変更したいんです。
思うに、暗黙知のままがいい部分とそうじゃない部分があって、その基準ってどの一定程度の期間、一定程度の人数が恒常的やるか、ってことによると思うんです。一人でもずっと続くようならマニュアル化が必要。もちろん、多人数でやるにも必要。
今まではその期間×人数の値がある程度大きくなるまで、みんな引き継ぎで許容してたんだけど、さすがに消費者側の情報の共有化が進んで異なる対応をしたら目立つようになってきたので、その値が下がって来た。
実は人に引き継ぎをするだけのほうが工数が無駄になったりしないし、そうでなくても、そのほうがその人の創意工夫があらわれやすくて業務の効率化にかなう、っていうのはあると思います。
[computer][law]リーガルパターンの可能性
「オープンな法体系（SF小説風）」（@isologue4/17付）において、法令や契約書のxml文書化を通じた自動処理の可能性が語られているわけですが、webmasterの見立てとしては、そちら方面には進まないように思います。
というのも、その補足に当たるエントリで紹介されてい…