実はオブジェクト指向ってしっくりこないんです！
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になってASP.NET C#等の言語を全く使いこなせていない。
■プログラムの過剰生産ぎみじゃね？
SIer系の仕事を見ていると、やれ何やらシステムを導入するとコレコレこういうメリットがあります！費用対効果が高いです！と夢のような話を連発する。仕事なのでそれは否定しない。で、実際に現場に行くと、ITに全く関心の無い社員に囲まれてシステムが動いている。
そういう光景を見ると、何かが違うよね感がにじみ出る。仕事してる社員さんとシステムが仲良くない。ファイルやフォルダ整理がいい加減だったり、Excelですらろくに使いこなそうとしない。そういう努力が足りないというより、努力のやりかたすら知らない。いや、使いこなすという概念すら無い。そんなところに、システムを突っ込んで業務の成果に繋がるのか？いつもそこに疑問を感じる。
■システムのひずみ
実際の現場がそんなふうなので、ソフトウェアの使い方がめちゃくちゃだ。Excelで足りるレベルの処理をわざわざAccessで回りくどくやっている。逆にAccessを使わなければしんどいような処理を、無理くりExcelでやっている。適切なソフトを選ぶというプロセスが抜けている。
そんな状態なので、どんなソリューションを導入しようと、優秀なエンジニアにシステムを作成してもらっても、値段に合った効果を得るのは難しい。また、そういう会社にシステムを売り込むというアプローチもずれている。
■必要なのはシステムじゃない。教育だ。
率直に言うと、SIerは必要の無いシステムを作り過ぎている。そして、SIerのスキルも低いので、膨大な無駄の上に大量のプログラマを抱えている。本来、そんなに多くのプログラマは必要が無いと考えている。そもそも、生産するシステムに対して、使いこなす人が少な過ぎる。そこを作り込みで回避しようとするので、無駄に人手が必要になる。
バランス的には、
システムを使う人 > システムを使いこなす人 > システムを作る人
というのが理想だ。だが、現代の分布は、
システムを使う人 > システムを作る人 ＞ システムを使いこなす人
になっている。システムを使いこなす前に、機能を追加して解決しようとする流れができている。それは順序が逆だろう。土木や建築と比べ、ITで生産されるものが不安定だと言われても仕方が無い。
SIerは、システムの使い方をみっちり教えて自立させるような、コンサル的な役割も担ったらどうだろうか。もっとも、これをやるにはエンジニアの育成が不可欠だ。高度な教育の技術も要求されるので、システムを作るよりも難易度は高い。商売と考えると、あまり旨みがないのは事実だ。
■本題のオブジェクト指向
そして、なんでオブジェクト指向がしっくりいかないかという話だ。私としては、プログラムをじっくり組むより、ワンライナーで生データをガシガシ処理したい。プログラムを組む以前の問題を処理するには、ソフトウェアを作る技術ではなく、コマンドやスクリプトでデータを処理する技術が必要だと考えている。
オブジェクト指向は、プログラミングを作成するには良い技術だと思う。だが、スクリプトやワンライナーでデータを処理するには、あまり有効活用できないように思う。もしくは、プログラミングの時と違った見方でオブジェクト指向を見る必要があるように思う。
最近、PowerShellというのが出てきている。これが非常に微妙なところを突いてくる。私の知る範囲では、Windowsでプログラミングをしてる人には好評だが、Linuxでシェルスクリプトを組んでる人には不評だ。その差が出る根拠が、オブジェクトをパイプで渡して処理するというコンセプトだと思う。
スクリプトくらいのレベルでコードを書いてる人にとってのオブジェクト指向とは何ぞや。これって、どうすれば有効活用できるのか？そもそも使うべきでは無いのか。それに対して、私が納得のいく返答はまだ得られていない。
■作る技術から解析する技術へ
今後、プログラマとは別に、スクリプトやら小規模な使い捨てコードを駆使して、データやシステムを解析するような立場の人が必要とされると考えている。高度に組み上げたはいいが、仕組みを制御できなくなったシステムを解析するエンジニアだ。私はそれを目指している。
ソフトウェアを使いこなせる人、理解できる人を増やすには、システムやデータを効率よく処理できる人が不可欠だと考えている。そういう人が使う、スクリプトやら小規模な使い捨てコードにも進化が必要なのだろう。
作る為の技術としてのオブジェクト指向は確立してると思う。表現は微妙だが、これを道具として使うという観点から見ると、何か新しい発想を付け加える余地があるように思う。まだ伸びしろがあるということだ。
スクリプトやら小規模な使い捨てコードを基準に考えると、まだ面白いもの出てくるんじゃねーかなぁ。そんな期待があるので、オブジェクト指向にしっくりしてもいられないのだ。
コメント
仲澤＠失業者
自分は日常的にC++、Java、Objective-Cを使っているのでオブジェクト指向の人です。
オブジェクト指向は複雑な処理を人にわかりやすく記述するための方法論なので、
そもそも単純な仕組みを記述するのにはあまり向きません。効果が出にくいのですね。
実際のところ、データベースを扱うページをJavaScriptで書いたときに実感しましたが、
UI部分を除けば、データベースをオブジェクトっぽく記述しようとしても、
せいぜい「テーブルオブジェクト」や「レコードオブジェクト」に
それぞれの「操作メソッド」があるってな感じにしか記述できないですよね。
しかも、テーブル設計に依存して汎用には書きづらいです。
パラメータを渡してSQL文を生成した方が楽だったと笑っちゃいました。
逆に、ウインドウ上での全ての操作をオブジェクト指向無しに記述するのは
もはや複雑になりすぎて無理です。CUI的OSの時代ならまだ可能でしたけど。
処理にはそれに適した手段があるってことなのでしょう。
Anubis
> 仲澤 様
コメントありがとうございます。
おっしゃる通り、短いコードしか書かないのでオブジェクト指向の恩恵を受けることがほとんど無かったです。なので、オブジェクト指向の仕組みは知っていても、真意的なところや、どう使えば便利かという部分はわかりません。
しかし、なんか面白そう、掘り下げていけば何かできるんじゃないか？と思い、いろいろと今でもたまに本を読んだりしてます。
Anubis
さて、このコラムを読んで、以前、みながわけんじ さんの書いた同名のコラムにかけて、狙っただろ？と思われる方も多々いらっしゃると思います。
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
もちろん、狙いました。
ただし、みながわけんじ さん のやり方、コメントの是非について問う気はさらさら無いです。訴えたいのは、正しさばかり追求しても新しいものは生まれないということです。コメント欄を見てそれを感じたので、あえて同じ題名を拝借しました。
みながわけんじ さんへの誹謗中傷、static云々のコメントに関しては、書き込んでも無条件で削除しますので、ご了承お願いします。
f
ワンライナーでオブジェクト指向の恩恵を受けるのは比較的容易ですよ。
先ず、オブジェクト指向でないと、メソッド（関数）の場所がわかりにくいですし、
既存の操作（スクリプト）を、UNIX風の思考で纏めておくと、UNIX流儀が促進されます。
ここでいうUNIXの流儀とは、簡単なスクリプトを使いこなすです。
オブジェクト指向で纏めておくと、一行で済むようなスクリプトを組み合わせて、
複雑な処理をするというUNIXの目的も可能となります。
その際に、型名を明記するというのが邪魔になりますが、
最近の言語には型推論機能があるので、その問題も解決できます。
y.k
>そんなところに、システムを突っ込んで業務の成果に繋がるのか？
とありますが、オブジェクト指向の1つの要素であるカプセル化は「そんなところに突っ込むための」システムでは。
使う側からすれば「中で何がどう動いているのか分からないけど、これを使えばとりあえず動く」レベルの認識で十分なのでは無いでしょうか。
もちろん、システムが複雑怪奇になると使う側の習熟度も求められてしまうのですが。
問題に対して解を得るために必要なものを作る、というのが職業エンジニアとしての使命である……これは受け売りなのですが。
Anubis
> f さん
コメントありがとうございます。ちょっと似たようなところで、VBAやWHSでClassを作って似たような事をしたことがあります。
確かに恩恵はありましたが、これがオブジェクト指向・・・？なのか？というところでモヤモヤ感がありました。たぶん、オブジェクト指向っぽい事はしてたと思うが、確証が持てないので、オブジェクト指向とは言わないようにしてます。
そんなところで、しっくりきてなかったりもします。
> y.k さん
>問題に対して解を得るために必要なものを作る、というのが職業エンジニアとしての使命である……これは受け売りなのですが。
私の場合、価値観が一般的なものから大きくかけ離れてます。特に、この一節を読んで強くそう感じました。
掘り下げて考えてみると面白いコラムが書けそうです。
コメントありがとうございました。
shu
オブジェクト指向といってもかなり広い概念だと
思いますが、とりあえず
値の入った変数(=オブジェクト)
と考えれば
変数.メソッド
を使用していればオブジェクト指向に触れている
考えられます。
メソッド(変数)
の形のみで記述されているのであれば恩恵に預かっていない
可能性は高いですね。
Anubis
> shuさん
> 変数.メソッド
こうなってたので、ギリギリでオブジェクト指向だったようです。
だが、サーバ管理者レベルでは、こういうスクリプトを書いて意図を理解できる人はいませんでした。
ブラックボックスみたいなのを増やすのもいたたまれないので、結局、周りの人と似たような書き方で事を済ませました。
とりあえず、一部スッキリしました。ありがとうございます。
たかたかハリコフ
社内SEの立場から考えると、ユーザーにとっての戦場はITじゃないって事だと思います。営業が営業をせずにExcelの勉強をするっていうのもどうかと思いますし。
もちろん、出来た方が良いので機会あるごとに教育の機会は設けてますけどね。
SIerのレベルも高くしていくべきだと思います。カスタマイズ無しのパッケージなら期待に応えてくれるのですが、フルスクラッチしたシステムに改修を依頼しても設計も出来ないし、相談しても提案が出てこない。
排他制御の仕様が出鱈目で、苦情を言っても「もう作っているから出来ない」とか言い出すし。
まず、SIer自身がITの専門家としての誇りと実力を身に付けるべきだと感じます。
本題のオブジェクト指向については近い考えです。私もJavaで開発してますが、ツリー構造が作れるような規模の大きな案件でないと無駄に難しくなるだけかと。
大規模システムは経営陣は喜びます（全体最適が云々とか）が、現場が求めるのは、小回りの利く小さな案件が多いんですよね。そんな案件にオブジェクト指向とか言われても...
プログラマーに要求されるレベルも高くなりすぎてしまって、職人の世界になってしまったように感じます。何のために高級言語が生まれたのか疑問に思ってしまいます。
Anubis
> たかたかハリコフさん
> ユーザーにとっての戦場はITじゃないって事だと思います。営業が営業をせずに
> Excelの勉強をするっていうのもどうかと思いますし。
この意見に対しては思うところがあります。Excelを使うのであれば、営業は営業とExcelを勉強すべきと考えています。ここら辺は書くと長くなるので、別のコラムのネタにさせて頂きます。
> 何のために高級言語が生まれたのか疑問に思ってしまいます。
実のところ、私も疑問に思っています。どの言語を使うにしても、複雑すぎて小回りが利かなくなっているように思います。小規模なものをサクッと作れる仕組みが乏しいように思います。
コメントありがとうございました。
BB
Anubisさん、無意識に高級言語の全ての機能と概念を使おうとしていませんか？
もし高級言語がなければ、機械語でプログラミングしなければなりません。
その事を思えば複雑だとは思わないはずです。
また、世界中のユーザーを満足させるために多機能化しています。
ですから、貴方様が使いたい部分だけを使えばいいのです。
そう思えば、自然と使いこなせるようになると思います。
所詮言葉であり道具なのですから、気楽に構えればいいと思います。