VB:「VB 再考 VB はオブジェクト指向言語か?」
いまさらですが。
今朝はおきてからこの内容が頭を離れません。(どんなだよ・・)
ずーっと悶々と脳内議論していたのですが、ちょっと書いてみます。
■ 何でそんなことを考えていたかの背景
なんで、いまさらオブジェクト指向かどうかなんて話題なのかというと
今やっている仕事やフリーソフトを公開する場合のデメリットとして、
.NETじゃないこと、移行しづらいことに原因があります。
VB6 や その技術を使ったVBA(非.net) のような技術を
シュウカツ中も含め散見しましたし、現在そんな仕事をしています。
でも、なんだかVB6ってバカにされてませんか?
Webの人たちからするとVB6 ?ぷふー。
移行できなかった人たち???
的な目線で見られている気がしてなりません。
が、フリーソフトでは、環境が千差万別といえるほどなので、
はっきり言って、.NETは向いていない。と、思っています。
広く環境を制限しない開発がフリーウェアでは
結構、重要だったりするわけです。
そういうネイティブExeが作成できる言語。
VC、VB、デルファイ などがあります。
Javaも比較的軽いランタイムだけで動くと思えば、候補のように
思えますが、クライアントアプリを作る上で、何がよいかにおいて
ネイティブに勝てるわけではなく選択肢にJavaは入れません。
というより、Webに強いだけでクライアント用のGUI機能が
貧弱なものについては、正直却下なのが心情かもしれないし、
私が嫌いなだけかもしれない。
が、時代はJava ですよね。
UI だってJava + αであればなんでもよいわけです。
けど+αを最初から考えるならWFPで充分なわけで・・。
やはりあえて、特別にJava を選ぶ理由はない気がします。
なので、結果、レガシーでもお客さんがそれでよいならそれで。
と、なることもあるわけです。
そこに参加している人は多いわけで、少しでもバカにされない理由を
考えてみたいなぁ・・と、妄想してました。(w
移行できなかった人々。。ぷっふー。
って、思われてそうな理由のひとつに
VB6技術者は、.NETに移行しにくいなんて迷信があるけど、
どちらかというと本当はJava技術者のほうが来ない気がしています。
C#ですら、Noな感じでした。
この迷信の裏には、VB6 = 非オブジェクト指向言語。
という定着が進んでしまったというのもあるかもしれない。
2001年ごろ、確かにそんな話題が持ちきりで、.NETはガンガンに違いない!
って、私も思ってました。
蓋を開けてみると手続き型でも書けてしまう・・。(← 書くなってほどじゃない。
なんだこれ・・??(← こっちのほうが衝撃的だったわ。w
というより、根本が間違っていたわけで。
VB6は、オブジェクト指向言語じゃない!。では、ない。w
というのが、自分の中の答え。
正確には、色々加味してこれなんですが、少なくともVb6技術者は、
.NETにチェンジできる知識しかない。
ではなく、意図して使いこなしていないだけ。ということが最大の理由。
Set objA = new myClass()
これのどこが新しかったのでしょう?
つまり、そういうことだと思う。(厳密にはもっと。)
なので、少しでも自分がバカにされている気分を晴らすために書いてみます。
というより、自分で納得したいだけ?
■ そもそもオブジェクト指向 ってなに?
まずはこの話に決着しないとダメですよね。
存亡危機のウィキペを使って読んでもらうと、こんな感じ。
そう重要なのは、オブジェクト指向 と呼ばれる条件(構成概念の項)です。
本などを読むと、オブジェクト指向と呼ばれる条件として毎回出てきます。
聞き飽きましたよね。
・カプセル化
・継承
・多様性多態性(ポリモー なんとかw
・動的束縛?????
(失礼・・。なんか、多様性って書いちゃったw@2011.11.01)
そう・・・なんだこれ!!??
4つ?3つじゃねぇのかよ!?
(ときどき、多重継承が4つめだったりしますね。)
と、思う人とそうでない人。いるはず。
説明にも書いてあります。
この特性を備えていないオブジェクト指向言語もある。
と。
ここ一番重要です。
そんで、説明がスゴイわかりにくい(とうか、なってない!)ので
書いてみると、
オブジェクト指向言語 と呼ばれるための条件、それは
カプセル化できるかどうか。
だけです。
ってことは・・・ぉい!
VB6はオブジェクト指向言語ですか?
ってなります。
まぁ、話のネタ元はこういうことです。
頭の中で考えた妄想。(いや、よく言われるんだけど)
誰か:「VB6って、オブジェクト指向言語じゃないジャン!」
私:「厳密な意味ではね。」
誰か:「厳密って・・負け惜しみするなよwwwwwww」
てなのをよくやられるわけです。
で、上の話を言うわけです。
すると、
誰か:「でも、最近はこの3つでオブジェクト指向が一般的だよねww」
と、当然なる。
それは、このwikiを読んで疑問に思った人ほとんどそれかな。
なので、こう答える。
私:「主流がそれであれば、厳密な意味では、Javaも違いますよねw」
誰か:「?」
そう。多重継承はどうしましたか?
いつからJavaは厳密な意味でのオブジェクト指向言語に進化したの??
バージョンを教えてくれ。
(ぃや本当に・・いつ対応したの??してないの??どっち?)
記憶では、Java は多重継承できなかった。
今時点2010年の何かを読んでもダメとある。
というより、オブジェクト指向言語の条件と書いたけど、これらは
正確にはオブジェクト指向言語の要素でしかない。
全部を実現すると無駄が増えるので結局のところ
2011年11月時点では完全なるオブジェクト指向言語は存在しない。
というのが個人的な認識。(この発言を読んだのは数年前ですが。)
なので、
「オブジェクト指向じゃない言語VB6ぷっふーっwww」
は、
「ばっかじゃねぇーのぷっふーwww」
と、今でも思っている。
それと、wikiではわかりにくいですが
・オブジェクト指向
と
・オブジェクト指向言語
と
・オブジェクト指向開発
は、ばらばらで別のものである。という、認識。
特に、オブジェクト指向開発は、その言葉自体が後発で、
Win95以降の世代には、あたかもこの頃に流行りだしたのが
オブジェクト指向のように感じる節がある。(と思っている)
オブジェクト指向は、80年代だっけ?
オブジェクト指向開発と同義のオブジェクト指向プログラミングは、
その近辺だったように思うけど、最近じゃない。
当然、オブジェクト指向言語もそう。
つまり、概念的なものと同義、そうでないものをごっちゃにして
一緒くたに覚えてしまったのが問題なのかもしれないけど、別もの。
なので、
「だって、VB6ってオブジェクト指向開発できないじゃんww」
という、ヤツには
フォームにボタンでも貼り付けさせてやれば良いと思うよ♪(シンジ風味
やり方は、VB IDE開いてフォーム追加して、ボタンをその上に作るんだよ。
ほらできた。
これ君の言う「オブジェクト指向の継承と生成動作ね。」
wikiにもちゃんとオブジェクト指向の方式として書いてあるけどわかりにくい。
クラスを継承するか、インスタンスを引き継ぐか。の違い。
VB6 は、Com なわけ。
コンポーネント
オブジェクト
モジュール(モデルは、概念だったはず・・・)
いわゆる部品をオブジェクトと呼ぶし、相手がクラスであるかどうかはどうでもよいの。
オブジェクトって意味あいがいつも食い違うのはココ。
あんたらが知らないだけだよ。
最初のフォームをマウスで作る作業をコードで書くと
dim objFrm as formA ' ← いわゆるformA.frmね。
Set objFrm = new formA()
なわけ。(ごめん、formをNewするメソッドが浮かばない 苦笑)
型として使ってるからわかりにくいけど何処が継承なわけ?
タダのクラスのインスタンス生成じゃん。とは、思う。
ところが、このFrmA内には、新しくメソッド追加もプロパティ追加も出来ちゃうわけだな。
たとえば、このフォームモジュール内に
public sub tuikaMeth()
なんてものを書いたりできる。
この作業だけ見るとわからないけど、これって実際には
Application.Form から FormA を定義して、そのFormAにメソッドを追加した。
ということ。
さて、コレは継承でしょうか?それとも継承ではない何かですか?
というか継承ってなに?
VBはコンポーネント指向言語ですからそもそも継承(という、クラスベース方式の考え)が
できるわけがない。
なのに、継承がオブジェクト指向の条件みたいに言われちゃうから、
○○っぽい。ことをできる。といわざるを得ない感じなのでしょうか。
再利用に必要なもの=継承という発想もMSにはあるらしく、
それでいくと、まさにこれなんだよね。
一応、MCSDのVBの本には、VB6はオブジェクト指向開発に必要な要件を
満たすと書いてある。
ようするに発想と実現方法の違いで継承と同じく再利用できることで
要件を満たしたといってるんですね。
いつからオブジェクト指向の開発要素が
・再利用
・多様性
・カプセル化
になったんだ・・・orz
ちなみにその本にもどんな本にもきちんと
VB6は継承をサポートしません。
とある。
そして、但し書きとしてそれを実現するためにActiveX(Comのことね。)を
使った継承動作(つまり今書いたプログラム)が行えることになっている。
まぁ、確かに継承の使い道ってそういうことだよね。
とある定義(Com内の定義)を元にクラス(Form)が作れて、中身(メソッドの数)をいじれる。
無茶苦茶言っているようだけど、そういうことだと思う。
MSのよくいうActiveX技術を使った継承とはまさにこれなんだと思う。
でも、それはJavaやC++からみたら継承wwwって呼ばれるかもしれないけど、
クラスベースかComベースかの違いに過ぎない。
継承できないじゃん!=オブジェクト指向じゃないじゃん!
っていわれるのが嫌でこだわってるなら、そもそもオブジェクト指向の原点が違うってことに
気づいてない可能性が高い。
最初に書いたように
・カプセル化
ができるかどうか。がオブジェクト指向言語の唯一の定義ならVB6は、
カプセル化できる言語です。としか、答えようがない・・。
(ただし、プロパティの隠蔽方法が他と違う。)
でも、
・カプセル化
・継承
・多様性多態性
といわれてしまうと、VB自身継承はできない。と、書いている通り違うとなる。
が、それらしきことができますよ。
というのもまた事実。
コンポーネント化しなくちゃ、要素満たせないし、そもそも部品化して出すとか、
どんだけDLL地獄!!!って、笑われちゃうよね。
(いや、Java技術者はそこまで詳しくしらないからいわないか・・。)
でも、部品化=ばかじゃねぇの?
ってなったら、Beansはなんのマネか?
と問えばよいと思うよ。
あれこそCox(コンポーネントオブジェクト ほにゃらら)のJava版でしかないわけで。
わかるよ、VisualEditor(Eclipseに付属するVB IDEのRADみたいなやつ)を
一時期でもはずしちゃうわけだ・・。
まぁ、書き直せるかどうかでDLL地獄かどうかの違いは絶対的にあると思うけどね。
・・・やべぇ・・長文になってしまった・・。
多少、Java=オブジェクト指向!!最高!みたいな発想の人に
苦しめられているVB&VBA技術者に心安心していただけたでしょうか??
実は、次が本題で・・・やっぱVB6って・・・開発効率上げるための
オブジェクト指向プログラミング要素足りなすぎwww
って、話だったのですが・・疲れました。
またこんど。
でも、まぁ・・VBにしろJavaにしろ効率よければ何でもよいと思うのですがね。
私は。
保守的な意味では、
「動いているものを替えたくない」
という力の方が遥かに強く働くわけですから・・。
そして、それと同レベルに思うのが、
いいから開発効率上げるための要素は満たそうぜ・・。
とも思う。
FWでも自作してみれば良いと思うよ・・(ふ・・ふるい。
« 睡眠日誌メーカー:「日の出時刻が正しく算出されない不具合」 | トップページ | 睡眠日誌メーカー:「公開停止のお知らせ」 »
コメント
トラックバック
この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/290447/42757777
この記事へのトラックバック一覧です: VB:「VB 再考 VB はオブジェクト指向言語か?」:
« 睡眠日誌メーカー:「日の出時刻が正しく算出されない不具合」 | トップページ | 睡眠日誌メーカー:「公開停止のお知らせ」 »





うーん、難しい話題ですね。厳密にはVB6もオブジェクト指向言語ではあるんですけどね。
MSOfficeアドオンの作成以外にたいした用途はありませんが、インターフェースも持っていますし。
1つだけ言えるのは、オブジェクト階層(最近の言語だとパッケージング)を意識していない方が多かったは間違いないです。
そのため、ADODB.ConnectionとDAO.Connectionの競合すら解消できなかったという事例が私の周りであり、そんな状況で.NETなんかに手をつけて大丈夫?という感じでポカーンと見ていました。
あと、VB6プップーと吹いた割には、コーディングがVB6的でプップーという、口ほどにもないなと言う事例もありました。
何ていうか、半端な技術しかないのであれば、下手に.NETとかJavaに手を出さず、安パイ的にVB6で書いて欲しいというのはありますね。
Sharedだらけの.NETでも困りますし。
オブジェクト指向に踊らされて、設計者にしか分からないような自慰的なクラス設計をするのは言うまでもなく論外ですが。
大手だと、大分Javaや.NET、もしくはWebは普及しているかと思いますが、中小企業のシステム開発だと、そんなの使う必要ありますか?
私に言わせれば、言語の難易度に物を言わせて開発費をせしめ取ろうという意図しか匂って来ないです。
場所によっては、VB6どころか、ExcelやAccessでどうにかなりそうな所もありますしね。
私の結論としては、大手はオブジェクト指向言語やWeb,クラウドなど、最新の技術を使えばいい。(使いこなせればの話ですが)
そして、中小は小回りの効くVB6やらVBAで開発すればいいかと思います。
少なくとも無理にオブジェクト指向に踊らされる必要はないです。
投稿: azul-palazzo | 2011.10.30 20:25
こんばんは、azul-palazzoさん。
コメントありがとうございます。
VB6はオブジェクト指向言語。って、バサッと私も言えるようになると
いいのですが、未だに自信が持てません。
書いておいてなんですが・・(^^;
私も、自信が持てるようもっと色々と知らなくてはですね・・。
でも、VBというだけでVC技術者には小ばかにされ、次はJava技術者には
劣等感を強いられる感じが、就職面談していても気になってました。
流行りかどうかでそこまで言われるか?って、具合です。
今いる現場がWebとそうでない人のような括りっぽくって、再び感じていました。
(JavaはJavaで禁句っぽいですが・・苦笑)
バカにされる要因のひとつにやはりオブジェクト指向がある気が
してならないのですが、果たしてそれを何処まで理解し、有意義に
感じて使っているかについては、甚だ疑問に思うことがあります。
個人的には共通化と保守性の意味で便利とは思うのですが、構造化で
耐えられるレベルもあるので、そういった意味ではVB技術者が
あえてオブジェクト指向の土俵で戦う必要は本来ないと思います。
また、これだけの年数を経て、いまだオブジェクト指向とは?なんて
話題が出てくる時点で、無視して当たり前に使えるVBのほうが本当は
優秀なのでは?と、思うこともあります。
(FW同様意識しないことで使える技術を作る人が減る可能性はありますが。)
目的でいえば、作る対象が違うだけで開発効率の良さは圧倒的だったわけで
これからもVBを悪と感じる気はしませんが、ただ、人が減りましたね。
そして、サポートは気になります。
逆に純粋なVB6の仕事は古くからの画像処理系に最近特化し始めた気がします。
それこそ.NETの出番な気がしますが、買ってしまったコンポーネントってのが
結構足かせなのかもしれません。
inputマンとか普通に売っててびっくりしました。(笑
どれだけValidator失敗してるんだか・・。
言語や技術は、使いこなせるものを中心に選択するのがお客様の為と
いうのも個人的には強いのですが、一方で、フロントをAccessやExcelで
システム作りをするのは、アップサイジングの問題があるので、自分の中では
いまだ導入の是非に解が出ていない気がします。
中小企業では、確かにこの方が小回りは効くのですが、メンテで苦しむ方法や
運用をあえてしている企業を見てしまうと余計にそう感じます。
今回は、切り口がオブジェクト指向になってしまいましたが、
実際は開発効率と保守性を考えて、VB6の仕組みでVB.NETにあるような
オブジェクト指向要素ならではのメリット生かす考えを書きたかったのです。
ExcelVBAは個人的に一番好きですが、FW的、標準化的な仕掛けの導入が
あまりにも進まなかった気がします。
そこには、まさにそれら要素が便利だったりするわけで・・。
いまさらVB6、VBAで開発ってライフサイクル考えようよ・・。
って、本気で腰をすえなかった自戒や書いてみると久々に面白いという
興味があって、少しその辺を切り口に効率化を考えてみたいなと思っています。
ちょっとまた文面が長くなりました。(コメントも・・
良かったらまた、読んでみて間違い、誤解とかあれば教えていただけると
嬉しいです。
長文失礼しました。
投稿: bs_n | 2011.10.30 23:49
オブジェクト指向は、無理に踊らされるものではなく、単なる一設計手法・開発手法にすぎません。プップーてのがよくわかりませんが…
確かに自分もPerlで開発してたら、今時CGI?プップー
って顔された時もあります。
イマドキmod_perlもblessも知らんのか、ひょっとしたらcall_by_valueとcall_by_referenceの違いも分かってなさそうな…かわいそうなやつよのう…CPAN使えなくってかわいそうですねw
っていう話ですし。単にそれは言ってるやつの勉強不足にすぎませんよ。
世間様一般に公開したり、他社と連携したりする必要がなければ、VBAでもなんでもいいと思うんですけどね。
安くて安定してればお客様は文句ないんじゃないんでしょうか?
投稿: ばしくし | 2011.11.10 13:25
コメント頂きありがとうございます。ばしくしさん。
オブジェクト指向(開発・分析)は、手法に過ぎないというのは、確かにそうなのですが、
実際現場で効率化、標準化のためFW などで開発を行う場合、その手法の選択肢は
存在しないように思えます。
FWは、どちらかというとAspectですが、いずれにしても言語としてオブジェクト指向開発要素が
必要で、理解も必要だと思っていますし、参加してくる面子もそういう技術者です。
そういった現場を経験してきた人にするとオブジェクト指向開発要素のない言語=時代遅れ。
という風潮というか、雰囲気があるのは仕方ないと感じるのです。
とはいえ、VBはバカにされるべき言語ではないと思うし、オブジェクト指向要素ゼロな言語でも
ない。これがあえて書きたかった理由です。
でも、構造化から入った人ではなく、オブジェクト指向から入った人にとっては、確かに
構造化でカプセルのようなことをしていく言語を見ると、なんじゃこりゃ?
って、思うのかもしれません。
それは、勉強不足といわれればそれまでですが、現実問題Javaをやっている人の
多くがしばらくMS系技術に触れずに過ごしてきた人だったりします。
逆もそうで、MS技術を中心にやっているとJavaなど多言語に疎くなります。
DB2?まだあったの!!??
って、個人的には思っている時期もありましたし、逆にSQL Serverってなに?
は、普通に聞かれます。
正直、企業方針が固まっているならそういった世界だけでもやっていけたのかもしれません。
逆に固まっている企業に勤めている人からすると、多言語の標準的なツールや手法なんて
知る必要も泣ければ知ることもないわけで、Perlの現実がどうか。
なども、Perl を使わないと決めた日からどうでもよくなる。
今時CGI?ぷっふーの顔をされたというのは、そういった人たちからの目線なのかもしれませんし
CGIであることの問題=プロセスやメモリ問題という発想があり改善方法について知らないだけ、
ということなのであれば、そういう人たちにとっては、改善する前に自分の使う言語を選ぶだけ。
の話のようにも感じます。
慣れた言語でよりお客様の要望が満たせるならそれでよい。という基本的なルールですね。
この点は両者間違いではないけれど、ここで書いている内容は、おおよそ中堅企業以上の
システムでして、10人そこらで利用するものではありません。
確かに規模によって選択肢としてのVBAは充分にありだと思うのですが、
個人的にはVBやVBAをそれほど押しているわけではありませんし、
VB最大の問題はライフサイクルのことと、技術者確保、環境整備など
お客様にとって、本当にそれがよい。とは、いえない現実もあります。
また、VBA=安価で安定という発想は、個人的にはなくて正直複数人でのメンテや
アップサイジングでのDB移行時にVBA&他DB技術者を獲得する必要を
考えた時に小さい企業でも最初からある程度の規模を見込んだシステム設計は
必要に思うのです。
言語はやはり用途と規模で選ぶ。
この辺で問題ないと思うのですが、そこにオブジェクト指向開発要素がどうからむかは、
ここから先の流行り言語となりうるかどうか。=技術者獲得が容易かどうか。
という点も加味するべきと思っています。
VBA は大変魅力ある言語だと思います。
VB6はさすがに環境的にもレガシーになっていますが、VBAは2007移行をしたくない
企業様も多く、結構現役だと感じます。
ただ、問題なのはVBA で開発をする人がその効率性を上げる努力を
オブジェクト指向を学んだ人と同等に考えているかという点だと思うのです。
構造化から突き進んでいっても解はでますが、視点としてアスペクト指向なんて
オブジェクト指向があって初めて実現性が近づくわけで、そういった要素をVBA の
FWに生かせるかどうかは、VB 及び VBA を使っている技術者がオブジェクト指向の
視点を持っているかで設計にも差が出ると思います。
その上で、オブジェクト指向に踊らされているわけではなく、必要の是非として
取り入れる。
それが自分の中ではベストなのかなと思っています。
そして、なぜそんなことを思うか(これが次の本題だったオブジェクト指向の利便の部分)と
いうと、いまいまやっている仕事含めてVBAの現場では多量なマクロ連携が多すぎて
メンテナンスや運用の面で本当にお客様のためになっているか疑問を感じたからです。
個人的には共通化には、ものすごく力を入れて設計すべきだと思うのですが、
あまりにも突貫プログラムが多いと感じる理由のひとつに、そういった共通化する仕組みや
技術への理解が少ない言語という気がします。
その根源がおそらくVBA開発者自身にも 「オブジェクト指向ではない」 から、
Common、Util程度のことしかできない。
そう思っている人も中にはいるとおもいます。
オブジェクト指向は手法かもしれないけど、必要なら入れればいいはずです。
踊らされるかどうかではなく、必要の是非。
そこに強烈な肯定理由を感じなかったのだろうか?と逆に感じます。
踊らされるという表現は、本当にその肯定理由を覆すだけのメリットをもたらすのか。
技術者レベルの統一という意味での否定理由は私もとても大きいと思っています。
ただ、今後VB技術者が増える見込みがあるわけでもないなら、技術者レベルを
無視した次元で共通化する仕組みをVBの新しい敷居にすべきときにも思えます。
無理をするべきかという話に摩り替わりそうですが、ここは無理をしてでも
品質をあげる努力をするべき点なのだろうと感じます。
それがお客様のためにならないのは、それこそ技術者が怠慢すぎる。
と、感じます。
私は、オブジェクト指向万歳な人ではなく、どちらかというと否定派なのですが、
こと共通化やレベル統一、今後のメンテを考えた時にいつまで「車輪の再発明」に
お客様をつき合わせるつもりなのだろう・・・。と、思うこと多々あり・・。
すみません、なんか取り留めなく書いて長文になってしまいました。
読んでくださった方いらっしゃいましたら、読了いただいたことに感謝します。
投稿: bs_n(管理人) | 2011.11.13 12:56
ずいぶん、長文を書いてしまいましたので多少端的に書きます。
なんだか全体的に否定することだけを書いてしまったようにも思えますので、
反省、追記も兼ねて。
(長文で自分のコメントすらブロックされた 苦笑)
・スキル相応でより安定的安価に。
そう考えると、あえてオブジェクト指向は必須ではない。には、大賛成。
・オブジェクト指向(開発・分析・言語)を利用するかどうかは、必要の是非である。
・ただし、現場においてそれの是非に選択がないことがある。
・オブジェクト指向に限らず高みを望むことがお客様のためにならないことは、
チーム管理(とくにレベル統一)においてもとても大切。
・実現する方法をお客様が問うことは本来はないのだが、お客様のためを真に思うなら
「車輪の再発明」の労力を価格に載せることも本来は不可と考える。
・新人教育に同じく取り掛かりが大変だからやらないという発想は長期的に誰も得をしない。
強いて言うならば、その技術を持った人のみが生き残れる社会にしかならない。
(これは、結果その本人にとってもデスマを抜けられない要因ともなる。)
・体感的な次元ではあるが、やはりVB6という言語仕様を引き継いだ言語2007以下の
VBAにおいて、オブジェクト指向を取り入れた手法を。とは、言わないまでも
せめて、もう少し効率的な仕組みを実現してきても良かったように思える。
・ここが怠慢かというと、一概にそうはいえない。
現場レベルで考えた時に、「職にありつく」、「食にありつく」どちらの面でも
そこには人と人がいて、雇用する立場の人からも効率化=正ではない。
と、思っている現状があると私は思っています。
そこは正しく状況を判断し、本当にそれだけの理由ではなくスキル的なテコ入れが
成せていないだけならば、もう一歩技術者に踏み込んでもらうべきだと私は思っています。
一時的な安さや安定がお客様のために本当になるかどうかは、
本当はどれだけ技術者のスキルと経験、知識を詰め込めばよいかの按配でしかなくて、
そこにはデスマやサービス残業、報われない労働などの理由から一歩引いているか、
思考停止を起こしていないか。
これは、常に自分に問い続けなければならない事項なのかなと感じています。
「無気力になるとき」 というテーマで次は書いてみようかと思いますが、
IT技術者ばかりが苦労することは、確かになくても良い気がします。
かといって、運用で苦労するのをわかっているとき、技術者は、
・スキル
・経験
・労力
・知識
の按配を可能な限り高いレベルに持っていこうとするものだと信じています。
口で言うのはたやすいですが、継続は非常に困難で壁も多いです。
けど、だからこそ同じ指針や目的を目指すProjectという仕組みが成り立つわけで
チームメンバの力が必要、そして、独りでは実現なしえないことに思えます。
そういった現場があるからこそが、IT技術者で居たい理由かもしれない。
あれ?・・結局長文w
まぁ、そうはいってもVB6で無理矢理オブジェクト指向っぽいつくりをみんなでやる必要は
全然ないとわかっているわけですが。(ぉい 笑
投稿: bs_n(管理人) | 2011.11.13 17:39