プログラマとSEのオブジェクト指向な関係
IT業界にはさまざまな仕事がありますけど、わたしはプログラミングにしか興味がありません（←我ながらずいぶんと偏っている）。
20代の頃に、SEという仕事はわたしには向かない、と思った主原因はそこにありました。
システムをデザインするということにさっぱり関心がない自分に気づいていたので、こんな人間がSEになってもダメSEになるだけだろう、と思ったんですね。
ユーザーさんのことを一番に考えるエンジニアになるべき論を読むと素直に感心しますし、それを実践していらっしゃるエンジニアを尊敬します。が、わたしはどうしても、どうすれば一番きれいなコードになるか、ということばかり考えてしまいます。
じゃあ、ユーザーさんのことなんてどうでもいいのか、というとそうでもなくって、自分が書いたコードが誰かにとって便利な道具になってくれることはうれしいんですよ。
「この子、こんなに優秀なんですよ～。こんなに役に立つんですよ～。こんなことまでできちゃうんですよ～」って自慢したいというか（←親バカ？）。
ついでにいっちゃえば、わたしには「こんなプログラムをつくってみたい」という願望がありません。
ただつくりたいだけで、何をつくりたい、というのがないんですね。
以前は「C++でつくりたい」という最低限の希望ラインがあったんですが、それもいつのまにか崩れ去ってしまい、もはや夢も希望もなく白紙委任な状態です（笑）。
できれば、背伸びしてようやくできるレベルのプログラムをつくらせて欲しいなあ、とは思いますけど。
そんなわけなので、何をつくるか、というお題を与えてくれる会社は、わたしにとってとてもありがたい存在です。そして、どうせつくるんなら誰かに喜んでもらえるものの方がいいに決まってる、と思っているわたしにとって、わたしとユーザーさんをうまいことつないでくれるSEはとても大事な存在です。
わたしほどSEの重要性を評価しているプログラマはいない……と言いたいところですけど、SEについてどう思っているか、という話題をプログラマ同士でしたことがないので、そこのところはよくわかりません。ヘタに話をふるとグチをきかされるだけで終わりそうで、こわくて（苦笑）。
わたしが求めているのは、プログラマとSEの洗練された依存関係です。それぞれがさまざまな状況に適応する多相性を持ちながら、ゆるやかな連結を保ち、協調して動作する、洗練されたオブジェクト指向プログラミングのコードのような。
そういう比喩でいうのなら、今の開発現場のほとんどは構造化プログラミング的なイメージがあります。
それぞれがそれぞれに与えられた機能をきっちり動かすことだけが求められ、互いに依存しあわないように機能を分割しようとした結果、ユーザーさんの要求の多様化や技術の複雑化に対応しきれなくなっている感じです。それを、SEがよっぽどしっかりしてるかプログラマがよっぽど我慢強いかでなんとかしのいでいたりすると、どちらかに負担が偏ります。で、突然、どちらかがフリーズや熱暴走する大惨事が発生したりするわけです（笑えない）。
SEとプログラマを「上下」の関係と認識することが、機能の関連性をおかしくしているんじゃないか、とわたしは疑っています。
SEはユーザーさんに「その処理なら関数電卓で十分ですよ。いいのを知ってますから紹介します」とかいっちゃってもいいんです。それでユーザーさんが納得するのなら職責を果たしたことになります。
けれどプログラマはそうはいきません。仕事そのものがなくなっちゃいますからね。それでも、SEがそう判断するのならプログラマは従うべきです。
それは「上下」だからではなく、その判断を行う「職分」がSEの側にあるからです。それだけのことです。
もっとも、職責をきちんと果たしていないSEにも従わなければいけない、とは思いませんので、SEと認めた人に対しては従うべき、と言うのが正確でしょうね。認めてもいないのに従うと「上下」の関係としか言えなくなってしまいます。
そして、そういう関係を威圧的に押し付けることはプログラマをダメにするので、最終的にSEの不利益になります。それくらいのことがわからない人が、ユーザーさんの利益をはかれるとは到底、思えません。
だからわたしは、プログラマに対して高圧的なSEを「ダメ*3SE」（＝「本人がダメダメなうえにプログラマをダメにするSE」）と呼んでいます。
プログラマがHow（どのように処理するか）の部分を的確に処理できる能力を持てば、SEはWhat（何を行うべきか）の処理に集中できます。
そんなシンプルな構造をベースにして、さまざまな問題を協調して処理していけばいいんです。むずかしいことなんて何もないと思いませんか？
まあ、人間関係のむずかしさが簡単に処理できるか！ と言われちゃったらそれまでなんですけどね。
それにしたって、縄張りをがっちり決めて、ここに入るな、そこから出るな、なんて大人げないとしか思えないんだけどなあ。
コメント
インドリ
>わたしはどうしても、どうすれば一番きれいなコードになるか、ということばかり考えてしまいます。
それは自然な感覚です。
だからと言って、システムデザインと両立できないわけではありません。
趣味では自分が美しいと思うもの、仕事では【お客様が美しいと思うもの】を目指せばいいのです。
可愛い子（コード）がお客様から嫌われるのは悲しいでしょ？
それならば、お客様に好かれるコードを頭の中でシュミレーションしつつ考えて書けばいいと思います。
> SEとプログラマを「上下」の関係と認識することが、機能の関連性をおかしくしているんじゃないか、とわたしは疑っています。
仰るとおりだと思います。
官僚主義的なその構造がこの業界の癌だと思います。
今回も興味深くよまさせていただきました。
次回も楽しみにしています。
ひでみ
こんばんわです。ひでみです。
インドリさん。いつもお言葉ありがとうございます。
> だからと言って、システムデザインと両立できないわけではありません。
> 趣味では自分が美しいと思うもの、仕事では【お客様が美しいと思うもの】を目指せばいいのです。
「お客様が美しいと思うもの」が私にはどうにもわかりません。
自分のセンスのマイノリティっぷりを信じているというか（苦笑）。
要するに「目指すもの」がどこにあるのかがわからなくって、途方に暮れちゃうんですよ。
もしかしたらある日、突然、システムデザインの美しさが理解できるようになって、SEを目指したりするのかもしれません。
そしたらコラムのタイトル変えないと（笑）。
インドリ
返信有難うございます。
>「お客様が美しいと思うもの」が私にはどうにもわかりません。
それは、お客様が使う光景を想像する事です。
お客様の業務を把握し、実際に使っている光景をコードからシミュレーションします。
これはなんちゃってSEには出来ない事であり、逆にプログラミング一筋のひでみさんこそ出来るであろう技だと思います。
ひでみさんこそ、会社に信頼される技術者になる可能性が高いです。
20年も一筋に生きてきた人の実力は相当なものだと思います。
その力は使い方さえ帰れば最強の武器となり、会社がひでみさんの重要性を分かる時が来ると思います。
会社から認められた後は、後輩に自分流のプログラミングの美しさを教えちゃいましょう。
友ぞう
ひでみさん、こんにちは。
友ぞうと申します。
今回のコラムを読んでいて、全く同じような考えのプログラマが
私の職場にいます。
とにかく職人であり、私はその人と現在仕事をしているのですが
とても仕事がはかどります。
私自身は多分SEなのですが、プログラムも書きます。
プログラムを書いて動くのは楽しいし、どういう書き方をしたら
パフォーマンスが上がるかということを考えるのに時間を費やしてしまったりします。
でも、私はプログラマには向いてないな、と思っています。
ちょっと難しいことを実現しようと思うと挫折してしまうからです。
その点、顧客の要望がどうしたら実現できるか、どうしたら業務が楽になるかを
考える方が達成感があって好きなのです。
そして、ちょっと実現するには難しそうだけど、機能として入れられれば
絶対よくなるっていう仕様を思いつくと、さきほどの彼女（女性なんです）に
お願いするのです。そうすると自分の想像した機能としてできあがってきて
感動しちゃいます（笑）
私は顧客のやりたいを具体化する部分を担当し、彼女が実体化する。
彼女だから自由な発想で仕様を決められるのです。
他の人と組むときは実装できるかどうかこちらで判断できる範囲でないと
仕様として入れることができず、結果として満足のいくものができないですね。
これはお互いの長所と短所がうまくかみあっているからなんだろうと思い、
とっても幸せなことだと思っています。
ひでみさんにもそのような相方がいらっしゃるといいですよね。（もういるのでしょうか）
ひでみ
こんばんわです。ひでみです。
インドリさん。
> ひでみさんこそ、会社に信頼される技術者になる可能性が高いです。
> 20年も一筋に生きてきた人の実力は相当なものだと思います。
ここまで言っていただき恐縮です。「ほめ殺し？」とびびっております（苦笑）。
私的には「20年もやってまだここかい」と思っているんですが。
まあ、この仕事には「果て」も「あがり」もないんで、いつまで経っても「まだここかい」なんでしょうけど。
友ぞうさん。
> ちょっと実現するには難しそうだけど、機能として入れられれば絶対よくなるっていう
> 仕様を思いつくと、さきほどの彼女（女性なんです）にお願いするのです。
私はSEに「こんなことってできるかなあ」と言われると、「こういうのもあるし、こういう手もあるし。あっ、時間くれるんならこんなことまでできちゃいますけど」と答えます。で、「いや、そこまでやらなくていいから」と言われるという。
> ひでみさんにもそのような相方がいらっしゃるといいですよね。（もういるのでしょうか）
今度、うちのSEにきいてみます（笑）。
私としては、今の会社に入って、プログラマなんか的なことを言われなくなって、だいぶ精神的に楽になりましたね。
なにせ、定年までプログラマでいさせろ、と言う人間を雇うような会社ですので。
プログラミングで食べていきたい人たちみんなが、素敵な相方と仕事をしている、と思えるようになればいいのに。
Atsushi777
ちっちゃな会社といっても、もううちのように社員10名くらいの会社(^^;;だと、
プログラマだのSEだの言ってられないので、それはそれで楽しいですよ。
「プログラムにしか興味がない」という気持ちはとてもとてもよくわかりますが、
背に腹はかえられないと意外と他のことも面白くなったりします。
その意味では、そういう会社に勤めることができているのは、
幸せであり、またある意味不幸せなのかもしれません。
インドリ
＞ここまで言っていただき恐縮です。「ほめ殺し？」とびびっております（苦笑）。
いえいえ、決してそんなことはありません。
プログラムからお客様が使っている姿を想像できるのはプログラマしか居ないと思うのです。
普通のSEでは出来ない芸当です。
そういった事で意識さえ変えれば会社の最終兵器になると表現しました。
世間のプログラマに対する評価が低すぎるのです。
ですからプログラマ達がその実力を見せ付けねばなりません。
管理者はプログラムを把握できないが、プログラマは顧客満足度を高められる存在だと私は実感しています（私のスキルの源泉はプログラミングです）
ひでみ
こんばんわです。ひでみです。
Atsushi777さん。
> 「プログラムにしか興味がない」という気持ちはとてもとてもよくわかりますが、
> 背に腹はかえられないと意外と他のことも面白くなったりします。
昔は背に腹はかえられずプログラミング以外の仕事もやっていましたが、毎回、やっぱりプログラマがいいなあ、と結論を出して戻ってくる、というオチでした。
いろんなことが楽しい人もいるし、ひとつのことでしか楽しめない人もいる。
その多様性は認められるべき、と思うわけですが、プログラマとしての地盤固めがようやくできてきた今なら、他のこともおもしろいと感じられるのかもしれないなあ、と最近になって思い始めました。
プログラマとして生きる、と決めたのが35になってようやく、くらいなもので、とにかくスローペースな人間なんです。というときこえがいいですが、キャパが狭くて消化に時間がかかるだけ、という方が表現としては的確かもしれません。
インドリさん。
> 世間のプログラマに対する評価が低すぎるのです。
> ですからプログラマ達がその実力を見せ付けねばなりません。
私もそれはいつも思っています。
プログラマを大事に育てようとせず、とにかくSEに仕立て上げようとする会社が多いですが、よいプログラマを育てることこそが会社の利益につながる、という認識が経営者たちの間で定着する日を待ちこがれています。
アマグラマーNo.6
The reasons why I hate programming in Japan...
（http://taekimsblog.blogspot.com/2004/11/reasons-why-i-hate-programming-in.html）
とかを読むと、アメリカ等ではＳＥとプログラマーという区別がないようなのですが、何で日本ではＳＥという職種をプログラマーとは別に作り（かつその人たちはプログラミング能力がゼロであるケースもあるらしい）、しかもＳＥ＞プログラマーという上下関係を設定しているんでしょうか？
ひでみ
こんばんわです。ひでみです。
アマグラマーNo.6さん。
ご質問の件ですが、それは私にとっても謎なことなので、残念ながら自信のあるお答えができません。
人気エントリーの欄でも紹介されている『下流から見たIT業界：SEとPG、どっちが頭がいい？(1)』（http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg1-acb2.html ）で、かなりつっこんだ考察をしていらっしゃるので、そちらをご一読することをお薦めします。
ちなみに私は、会社の上下関係がそのままSEとプログラマの関係に持ち込まれてしまった結果なのかなあ、と推測しています。
つまり、一次受け側の社員がSEとしてユーザーさんと直接交渉し、二次受け側の社員はユーザーさんと顔をあわせることもなく、言われるがままにプログラムを組み続けるしかない、という構図が、そのまま、SEが上でプログラマが下、という構図にすりかえられたんじゃないかと。
で、プログラマがしっかりしていると、SEがへっぽこでもプロジェクトはなんとなく収まります。そして、たとえほとんど仕事をしなかったSEでも、それは書類上ではキャリアになります。
ほとんど努力しなくてもキャリアが身につくとなれば、まじめに勉強する人は少数派です。
で、会社の威を借りているだけだということにも気づかないダメSEが量産される、というオチなんじゃないんですかね。
私はSEとプログラマの分業は効率的だと思ってますが、それは、私個人の資質としてはそうなる、というだけのことであって、すべてのエンジニアにそれがあてはまるとは思っていません。
一人で両方の役割をこなす方がよっぽど効率的なエンジニアの方もたくさんいらっしゃいます。
個々のエンジニアの資質を活かすことができる、多様な選択肢が存在することが重要なんだと思います。
アマグラマーNo.6
参照urlを見ました。終身雇用に基づく日本独特の雇用体制や、女性が結婚により退社する社会システムなど、いろいろな歴史的背景にあるんですね。
何ともややこしい話で、「不思議の国ニッポン」というか、外国と隔離されて社会が営まれていた時代の日本の状況がひしひしと伝わってきます。
しかしインターネット革命によって、外国と隔離されて仕事をすることが出来ない状況になってしまい、コスト削減のためオフショア開発に乗り出すようなことを自分で進めちゃっているわけだから、企業経営者は、今までの業務慣習が通用しない時代になっていることを自覚しないと、企業は存続していけない（というか、実際に存続できずに倒産しちゃっている企業が続出しているのが現在の日本ですが）と思うんです。
私は、プログラミングは、高度の知的能力と創造性が要求される頭脳労働以外の何物でもないと思うのです。実際にそうした要件を満たす人材でないとアメリカでは通用しないので、アメリカのソフトウェア産業は優れたエンジニアで構成され、新しいプログラミング言語やＩＴ技術は、つねにアメリカ発です。PCに載っているソフトはほとんどがアメリカ製（とヨーロッパ製）です。
一方、日本製で海外でも使われているソフトは、特定の個人が開発したRubyとか、･･･、他に何があったか思い出すのが難しいくらいの有様です。
日本のソフトウェア産業は、アメリカが開発した言語やフレームワークやライブラリ（Visual Studio、Java＋ミドルウェア、Javascript、AJAX、jQuery、LAMP、Eclipse、その他多数）を使わせてもらって、特定の顧客企業向けの業務システムを、常駐で製造するといったＩＴ土方スタイルが一般的です。
こんなことで日本のソフト産業が今後やっていけるとは到底思えないわけで、そのためにはＳＥとプログラマーの分業体制を見直すことが必須なのではないか、少なくともＳＥという職種は廃止し、日本のプログラマーはアメリカのように、システム設計も実装も両方こなすソフトウェアエンジニアに脱皮するべきではないかと考えるわけです。