- PR -

「簡単に作れる」なんて言うから

投稿者投稿内容
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2004-07-12 13:43
引用:

がるがるさんの書き込み (2004-07-12 13:29) より:
どもでふ。がるです。
んと…時々見る「笑い話」ですねぇ。

他の方も書いていますが。大抵、この手の発言を真に受けると、
ろくでもないシステムを作ってとんでもない目に会います




もとスレのツールの評価はできませんが、世の中には 簡単に高度なアプリを作れるありますよ
ただがるがるさんが知らないだけです。javaとは違いますがdelphiとかもそうだし
ただ 中には癖が強くて ある一定の枠組みを超えると急激に難しくなるあるいはできない
という ケースもあります。
井上孝司
ぬし
会議室デビュー日: 2001/09/08
投稿数: 668
お住まい・勤務地: 東京都
投稿日時: 2004-07-12 13:47
井上です。

筋論からいえば、開発ツールのおかげで省力化できた分の手間や時間を、ロジックの学習や作りこみ、デザイン改善などの部分に使うのが正しいんでしょうね。ただ、この種の問題は何も開発ツールに限ったものではなくて、たとえば PC そのものにもいえることです。「GUI で操作が簡単に」とはいっても、それが「情報リテラシー」の涵養に直結するわけではないのと同じで。

ただ、マスコミ的には、「○○するだけで問題解決 !」というのは魔術的に効能のあるフレーズなので、そこからボタンのかけ違いが始まるのです。
_________________
www.kojii.net
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2004-07-12 13:52
こんにちは〜。なかなか興味深いスレですね。(^^;

そうですねぇ… D&D で作成可能といえば、はじめて VB を触ったときにはいたく感動しました。
これまでの GUI 作成の苦労は何だったんだ!と。
(地道に計算してましたね…昔すぎて忘れてしまいましたが…)
ですが、すぐに 「”見た目” だけか…」 と落胆した記憶があります。
本当にやりたいことができなかったり、実装するためにえらい遠回りをしなければならなかったりしたからです。
(広い意味で考えれば、これもフレームワークなのかなぁと思ったり…言語の仕様ですけど…)
そうまでならなくとも、D&D で 「簡単に」 作れてしまうため、個々人がおのおの勝手に作り進めてしまい、結果としてメンテしにくいモノになってしまったこともありました。
(コーディング規約はあっても 「○○処理は××に書け!」 まではなかったからなぁ…)
おまけで、VB がとても脚光を浴びた時期に 「VB は何でも簡単に作れる」 と信じていた SIer さんと一緒に仕事をして、ヒドイ目を見たこともあります…。
(そういう会社さんが DB 回りやら WAN の帯域やらも考慮しているハズはなく…シロウトでも分かるわよ!二度と関わりあいたくないわ!)

ですが、だからといってツールが不要だとは思いません。
確かに、簡単に作れる部分は存在し、それは便利なのです。
ただ、「そこから一歩抜け出す」 となると、難しいです。
なぜなら、ツールから入った人には 「それが全て」 に見えていて、「それが何なのか」 まで考えがなかなか至らないからです。
…という部分が、Jitta さんが危惧していらっしゃるところなのかなぁと思いました。(^^;
ホビーならいざ知らず、職業人(プロ)としてはかなり心許ないですね…
# 私も他人のことは言えませんけど… how だけじゃなくて why も考えるようにしてますよ!

プログラミングは、とても奥の深いものです。
簡単にできるモノにも、とてもたくさんの意味があります。
技術屋さんなのですから、自分の技量でもって、お客さまによいサービスを提供できるように努めたいものです。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2004-07-12 14:39
どもです。がるです。
レス付けるかどうか、ちと悩んだのですが。

引用:

七味唐辛子さんの書き込み (2004-07-12 13:43) より:
もとスレのツールの評価はできませんが、世の中には 簡単に高度なアプリを作れるありますよ
ただがるがるさんが知らないだけです。


んと。まず「高度なアプリ」とはどういったものをさすのでしょうか?
七味さんのイメージがどうかはわからないのですが、一般に広告で
宣伝されている内容ですと「高度なアプリ == 複雑なことが出来るアプリ」
というイメージが比較的強いように思うのですが。
私が、特に業務系のアプリを考える場合、重要視するのは「メンテナンス性」
です。
ぶっちゃけて言ってしまえば「DBのテーブルレイアウトが変わる」ことすら、
それは「設計が原因」の場合も「業務的にやむを得ない」場合も含め、
ありえます。

そういった部分をきちんとフォローするのは、結局のところ設計力に
かかわってくる部分の問題です。
# 私はよく「言語に寄らないスキル」という発言をしますが、概ね
# その延長線上にある概念です。

んで「複雑なことが出来る」ことは、それが必ずしも良いとは限らない
ので(「複雑なことを単純に整理する能力」が一番重要だと思う−UNIX系
文化の持込になりますが−)。
結果として、「便利なTool」には一定レベル以上の評価を下しにくい、
ってのが個人的感想ですね。
# 優秀なAIでも付いてくれば…とか思わなくもないけど(笑

引用:

ただ 中には癖が強くて ある一定の枠組みを超えると急激に難しくなるあるいはできない
という ケースもあります。


これも結構困るんですよね。
現実の業務にシステムを落とし込むと、意外とよく「一定の枠組みを超える」
ような状況が起きるので。
で、割と多くのところで「一部の、メンテナンスをする人間が泣く」
「実情にそぐわないアプリになり、使う人間が頑張って運用回避をする」
という逃げ方になっているように見受けられます。…システム化した意味が
限りなく低くなってる気がするんですがねぇ(苦笑

あと、Toolで「バックボーンが隠れている」から「基礎知識が理解できてない」
ために起きるトラブル、も散見されるように思われます(.NETとか、
多いですねぇ。Javaでもたまに見かけます)。
この辺は、システム屋にとっては致命的…だと思うのですが、意外と
多くの人が気にしていないですね。

日曜プログラマにとってはいいと思うのですが。プロが使うには、色々
な意味で不足が多いのかなぁ、とか思ったりします。
だから「使わない」ではなく、だから「使えるところを見極める」のが、
多分理想なのだろうなぁ、と。
で、使うにしても、そのToolの根っこの部分もしっかり勉強する、と。
理想としては「自分でもそのToolが作れる」くらいに学習するのが
よいのだろうなぁ、と思います。

雑感込みでつらつらと。
CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-07-12 14:47
引用:

がるがるさんの書き込み (2004-07-12 14:39) より:

で、使うにしても、そのToolの根っこの部分もしっかり勉強する、と。
理想としては「自分でもそのToolが作れる」くらいに学習するのが
よいのだろうなぁ、と思います。


こう思うプログラマが増えれば、PGのイメージが一新されますね。
ただ「言われたとおり製造する」だけのイメージはあまりにも
悲しいです、、、が現実です。
で、その原因を作っているのがたいして勉強もしないのに、
俺はプログラマだと名乗る人が多いからではないでしょうか。

#プログラマを名乗るには、それなりのスキルが必要だと思います。

_________________
世界平和を願う!
http://park8.wakwak.com/~chin/

[ メッセージ編集済み 編集者: CHN 編集日時 2004-07-12 14:50 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-07-12 16:02
 午前、午後と会議が続いていたので、帰ってきてびっくり。

七味唐辛子さん:
>>ただフレームワークを理解すること、とはどうゆうことなんでしょうか?
 ツールにはたいていフレームワークも一緒に入っていますよね。またはパッケージ。これらを理解とまではいかなくても、どんなクラスやどんなメソッドがあるのか知らなければ、「初心者を卒業する」のは難しいのではないでしょうか。
 あと、「ツールは要らない」と言いたいのではなく、宣伝の仕方を問題にしたいのです。ツールは要ります。しかし、宣伝の「簡単」は、簡単なプログラムを作るのは「簡単」ですが、必要な機能を持った売り物としてのプログラムを作るのは、簡単ではないですよね?


maruさん:
>>「簡単に作れるのはこのレベルまで」「設計やプログラミング技術は大事」
>>というのをメーカ側が情報を積極的に流すべきと思う。
 これこれ。これです。
 ので、次の七味唐辛子さんの
>>ツールの問題と個人の問題は切り分けましょう
まさに正論なのですが、ツールの宣伝が、その2つを一緒くたにしている、または曖昧にしているのでは、という疑問です。


HIRさん:
>>短期間で開発する=思考をサボってよい
>>という短絡的な考えに陥らなければ強力な味方になると思います。
 が〜〜ん! いや、短絡的に考えていませんが、あははは・・・


井上孝司さん:
>>マスコミ的には、「○○するだけで問題解決 !」というのは
>>魔術的に効能のあるフレーズなので、そこからボタンのかけ違いが始まるのです。
 かけ違ったボタンを、どこで気がつくか。早ければ早いほどいいに決まってます。その為の情報って、いったいどこにあるのか。
 例えば、数年前から急にベンダー資格がクローズアップされているように思います。また、MSに限ってはMVPだのエバンジェリストだの、一般人または特定の社員を啓蒙活動の為に取り上げています。逆に考えると、そういうものが必要なほど、“簡単ではない”のでは?と思うのです。


はゆるさん:
>>確かに、簡単に作れる部分は存在し、それは便利なのです。
>>ただ、「そこから一歩抜け出す」 となると、難しいです。
>>なぜなら、ツールから入った人には 「それが全て」 に見えていて、
>>「それが何なのか」 まで考えがなかなか至らないからです。
 そうです。そして、それを宣伝が助長している、と。もちろん、宣伝効果を期待する為には、「簡単」という言葉ほど魅力的なものはないのですが。。。

 実際に有効なアプリケーションを作るのは、そんなに簡単ではない、と思うのです。それは設計もしかり、テストもしかり、そういったコーディングとは違うフェーズは簡単にはいかないものが多く、ツールが楽にしてくれるのは、アプリケーションの製造過程の中の一部分でしかないからです。


 実は今、「簡単にする」為のシステムを作っていて、その「簡単」に疑問を持っているから、他の「簡単」に反応してしまったのかもしれません。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-07-13 09:32
はにまるです。

記事のタイトルを捻くれた根性で見ると、「GUIを開発するツールについての話で、それ以外はワシャ知らん!」とも受取れますね。(やるな...オヌシ!

話しを戻して。

結局の所、多くのツールは「問題原因」の排除では無く「問題」の解決策を提供しており、またツール自身が前提条件を必要とし適用範囲が決まっている為、その範囲を超えれば覆い隠されていた問題を結局、自分で対応する必要性がある事を「ツールの特性」として理解しておく必要があると考えます。

また下記の2点が「魔法の杖」状況に拍車を掛けているかな?と考えます。
1.高度化された状況下では本当の素人は相手にしない。
 ツール自身が持つ「前提条件」や「適用範囲」の問題を助長している原因として、高度化された状況ではツール供給者からすれば、その「前提条件」や明確な「適用範囲」をイチイチ説明しないのが世の常だと考えます。言わば「知って当り前の話し」と考える訳です。

2.ツール自体の問題原因化
 ツール自体が後の「問題原因」になっている事さえ多々あります。実際OSや開発言語は問題解決ツールでしたが、今では問題原因に多々なっています。この「目先の問題解決」&「新たをなる問題原因の追加」を繰返した結果の状況を「高度化」と言うんでしょうね。

個人的には、上記の暗黙的了解が有るとは言え、今回の参照記事は行き過ぎている感じがします。高度化を担う人達も急速過ぎて付いて行けていない状況の現われかもしれません....
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2004-07-13 09:59
引用:

がるがるさんの書き込み (2004-07-12 14:39) より:



>んと。まず「高度なアプリ」とはどういったものをさすのでしょうか?
>七味さんのイメージがどうかはわからないのですが、一般に広告で
>宣伝されている内容ですと「高度なアプリ == 複雑なことが出来るアプリ」
>というイメージが比較的強いように思うのですが。

パッケージ製品をイメージしています。


>私が、特に業務系のアプリを考える場合、重要視するのは「メンテナンス性」
>です。

-------   中略 -----------
>んで「複雑なことが出来る」ことは、それが必ずしも良いとは限らない
>ので(「複雑なことを単純に整理する能力」が一番重要だと思う−UNIX系
>文化の持込になりますが−)。
>結果として、「便利なTool」には一定レベル以上の評価を下しにくい、
>ってのが個人的感想ですね。


正直なにを伝えたいのかよくわかりません。「複雑なことが出来る」比較的エレガント
の実装できる言語として delphiをあげます。これは コンポーネントを選択して
それぞれをつなげて、必要に応じてプロパティなりイベントを追加して動的な振る舞いを
決定します。見かけ上は複雑ですが、内部的にはコンポーネント オブジェクトの連携プレー
です。複雑なことを単純な形の実装できます。単純にとはいっても個人のスキルによっては
難しいかもしれません。ちなみにこのdelphiは自分で、既存のコンポーネントを継承して
好きなようにカスタマイズして、通常のコンポーネントのように使えます。
さてトピックスにある開発ツールもコンポーネント指向ということで、必要に応じてカスタマイズ
できるとうれしいのですが、そうすることにより、使えるツールになります。さらに
車輪の再発明を防止できます。 以前から思ってますがjavaの世界ではコンポーネントの
流通というのは聞かないですね、 汎用グリッドクラスとか、XX計算クラスとか


>ぶっちゃけて言ってしまえば「DBのテーブルレイアウトが変わる」ことすら、
>それは「設計が原因」の場合も「業務的にやむを得ない」場合も含め、
>ありえます。
>そういった部分をきちんとフォローするのは、結局のところ設計力に
>かかわってくる部分の問題です。

たしかにそうですが、それと開発ツールとは関係ないですよねそれこそ
言語に寄らない考え方で、ヘタレが作れば、どんなものもヘタレになるし
優秀な人が作れば、メンテナンスしやすいものができるし


>これも結構困るんですよね。
>現実の業務にシステムを落とし込むと、意外とよく「一定の枠組みを超える」
>ような状況が起きるので。
>で、割と多くのところで「一部の、メンテナンスをする人間が泣く」
>「実情にそぐわないアプリになり、使う人間が頑張って運用回避をする」
>という逃げ方になっているように見受けられます。…システム化した意味が
>限りなく低くなってる気がするんですがねぇ(苦笑

そうですね。まぁ仕方ないですね。でもこの場合 TOOLの話をしているのか
言語の特性のことを指しているのか不明ですが、作りが悪ければおんなじです。

スキルアップ/キャリアアップ(JOB@IT)