【CASEなのか?】富士通の「Interdevelop Designer」に思ったこと

富士通は8月28日に業務プログラム開発支援ツール

「FUJITSU Software Interdevelop Designer」

の発売を開始しました。

富士通のプレスリリース「業務プログラム開発支援ツール「Interdevelop Designer」販売開始」へのリンク


この製品が支援する、業務プログラム開発の現場について、

「ソフトウェア開発の現場が、もっともソフトウェア導入がなされていない」

と言うのを読んだことがあります。

たしか「めざすは新世代コンピュータ」(上前淳一郎著)で読んだものだと記憶します。

そう言う現場にいる自分としては、自分たちの作業のICT化が遅れているのは事実だと感じます。

そして、この手の製品については、まず最初にネガティブな気持ちになります。

本当は、あればいいな、と思う製品なんですが、経験上、本当にそれは便利なのか?と疑ってしまうのです。


「Interdevelop Designer」に限らず、どの会社が出そうとも、この手の製品について気になるのは、大きく以下の2点です

1.本当に使いやすいのか?

プログラミングを行うにはそれなりのノウハウが必要ですが、それが不要と行っても、結局その製品を使いこなすノウハウが必要になります。

経験から書きますと、その製品のノウハウを覚えることと、プログラミングの技術を身につけることとは、それほど労力に差はないと思います。

そしてもっと気になるのは、その製品がシステム開発で大きなシェアを獲得すれば、その製品のノウハウでいろんなところで食べていけるのですが、そうでないと、限られた現場でしか仕事ができないことになります。

それであれば、いろいろなところで使えるプログラミングの技術を身につけた方がつぶしがきくと考えます。


2.保守工程で不便になることはないか?

ほとんどの場合において、いったん完成したシステム、そしてプログラムには、必ず修正が入ることになります。

それは、商売の変更や、法律の改訂などが必ずあるからです。

消費税が10%になれば、手が入るプログラムはたくさん出てくると思われます。

システムは完成したら終わりではなく、完成してから、そのシステムが廃止されるまでの期間が長く、そしてその保守(メンテナンス)の方がコストがかかるのが一般的です。

そしてさらに悪いことに、システムを作った人が、システムの保守を担当することは少ない、と言う現状です。

私は昔、大部分がCOBOLで一部が「下流CASEツール」で作られたシステムの保守をやったことがありますが…

まあ、扱いにくかったです。

COBOLのノウハウはありましたから、多少の「スパゲッティプログラム」でも読むことはできましたが、CASEツールで日本語で書かれたソースプログラムを読むのは大変でした。

結局それになれる前に、その職場を離れることになりました…


愚痴を含めてだらだらと書いてしまいましたが、結局言いたいことは、

「保守工程のコストパフォーマンスを意識した製品なのか?」

と言うことが問いたいのです。


「Interdevelop Designer」について、ネットの声をいくつか見ました。

twitter、Yahooコメント、2ちゃんねる…

2つリンクを貼っておきます。

Yahooコメント「富士通、日本語設計書からプログラムソースを自動生成する「Interdevelop Designer」」へのリンク

「IT土方失業のお知らせ!富士通が設計書からCOBOLやJavaコードを自動生成するツールをリリース」へのリンク

だいたいネガティブな声ばかりです。

私も、今のところは「買うか?」と尋ねられたら「No!!」と言うでしょう。


しかし、こういうシステムを研究し続け、試行錯誤して、完璧に近いものをつくることは大事なことだと考えます。

いつまでも、システム開発の現場を全自動化するのは無理、と言う概念にとらわれているのは良くないでしょう。

たとえば、「Interdevelop Designer」は、仕様書やソースコード(「プログラム」と同じ意味だと思ってください)の属人性を廃す、とうたっています。

これはこの製品になって初めて言われたことではないですが、非常に大事なのに、なかなか達成されていないことです。

なぜ、人によって仕様書やソースコードが違うとまずいのか、といいますと、人の書いたものは読みにくいものですし、それを理解するだけで時間がかかります。

さらに属人性だけならまだしも、仕様書の中でいろんな言葉が出てくることがよくあり、もう理解困難です。

(このブログ記事も、プログラムやソースコードなど、同じものを違う言葉で書いていて読みにくいと思いますが)

時間がかかっても正解が得られるならまだ救われますが、誤解も発生します。

それで保守を行うと、当然バグが発生します。

こう言うことを防ぐためにも、属人性を廃し、少ないボキャブラリで仕様書が書くことが望まれます。


途中で一度使いましたが、かつて

「CASE(Computer Aided Software Engineering)」

と言う言葉がありました。

おおざっぱにいえば、コンピュータを使ってシステムを作ろう、と言う考えかたで、そのためのツールもいくつか出ました。

え、システム開発ってコンピュータ使ってないの?

と思われるでしょうが、他の分野よりは遅れてると感じます。


今はほとんど使われていません。

結局その実現はむずかしいと言うか、商売にならないと思われたのでしょう。


でもいつかは実現されないと、品質にばらつきがあり、SEやプログラマ泣かせのシステムばかりが作られることになり、今の私たちの業界の不幸はなくなりませんから。

統合CASEでなくてもいいので。

そのためには、富士通さんには失礼ですが、「Interdevelop Designer」の初版がたたき台になって、試行錯誤されるのは、悪い話しではないと思います。


Share/Bookmark

この記事が気にいられましたら、記事の一番下の「ツイートする」「いいね!」ボタンで、ツイートしてもらったり、facebookに載せていただけると嬉しいです。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
ここまで読んでいただき、どうもありがとうございます。
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

気が向かれましたらこの「にほんブログ村」への投票ボタンを、ポチっと押してもらえれば嬉しいです。
 ↓ ↓
ブログランキング・にほんブログ村へ
にほんブログ村

ありがとうございます。

またのお越しをお待ちしております(^_^)/~
関連記事
スポンサーサイト

コメント


管理者のみに表示

トラックバック