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