とあるソフトウェアエンジニアのブログ

　先週は、嫌なお客の話をしたので、今週は、もう一度ご一緒に仕事をしてみたいお客様の話をします。
そのお客さんは、とあるCEサイトを業者に作ってもらったのですが、残念ながらバグバグのシステムで大変不満を持たれていました。おりしも不況と重なって会社もリストラを始めたり、元々の担当者が止めたりで、新しく担当になった方は、業務は解るが、IT（WEBサイト）のことはよく知らないといった感じの人でした。色々不満もあったかと思いますが、そういったことは表に出さないで真面目にプロジェクトに取り組まれていました。
もっともITのことはあまり詳しくなかったので私が業者との交渉（バグの伝え方から、改修予算の値引き交渉やら、相手から来たメールの意図を翻訳したり）のサポートを行っていたました。

ただ、ECサイトによくあることですが、いかんせん売上が上がりませんでした。そういう中で次期開発の話が出てきたのですが、当然やりたいことにお金（予算、売り上げ）がついてこないので、そのギャップに担当者の方が悩んでいまして、ミーティングで愚痴を言われていました。そこで、思わず私が、
「今までの経験上、上手く行かないやり方を続けていてはダメになるばかりでっせ」
と言いました。

つまり、売上を上げていないのなら、無理に開発を進めるのではなく現行のシステムは修正にとどめたり、儲からないサービスやめたりするのも手ですよというある意味当然のことを言ったのですが、ただ、多くの日本人は『止める』という発想がなかなかできないようで、私も過去にこのようなことを言ってプロジェクトから外されたこともありました（本音を言ってくれてありがとうという人もいました）。

今回もこれは言い過ぎかなとも思ったのですが、この一言が担当者を救ったらしく、サービスメニューの構成を変えるように話しが進みました。以前なら『生意気なことを言うな』と言われるところだったのですが、平成不況も長くなると営業の現場の人もプライドを捨てて話をされるようになったようです。

その後、残念なことにやはり改修の規模が大きくなり、コストがかさむと同時にリストラが進み担当者もご勇退されプロジェクト自体が空中分解して、結局はそのECサイトはまったく改善をされずに閉鎖になりました。

私自身は営業的に失敗したプロジェクトをいくつも経験しているし僭越ながら自社のシステムを含めて成功しているプロジェクトも経験しているのですが、そのプロジェクトが終了したことは残念でした。もちろん予算がないプロジェクトだったので私自身もアドバイザーという形で週に1回しか打ち合わせに参加していなかったので、私のかかわり方として不完全燃焼な面もありました。
次回、その顧客と仕事をする機会があればぜひもっと良い結果を出せるように頑張りたいと思いました。

不況が長く続きますが、こういう難局を乗り越えるのもソフトウェアエンジニアというよりビジネスパーソンとして真価を問われていることだと思います。頑張りたいものです。

私は今でも顧客の元で仕事をしたりするので、この手の話題は避けたい面もあるのですが、たまには、ADP以外の記事を書いてみます。

私はかれこれ20年近くITエンジニアとして働いていますが、今ちまたで問題になっている以下の話題ですが、IT業界では昔からありました。
・鬱
・派遣切り
・モンスターカスタマー（パワハラ）

鬱は、昔からテクノストレスという言葉があり、私も十数年前にストレスに悩まされたことがありました。
今では結構気軽に鬱という言葉が使われますが、昔はそういった認識もあまりなく、ただひたすらいらいらする毎日でした。。。そういえばストレスチェッカーなるサイトをよくみていました。

派遣切りも昔からありました。もともとIT業界自体がはやくから派遣が可能だったというのもありますし、ソフトウェア開発プロジェクトは労働集約型になる為、プロジェクトが佳境に入ると人を集め、プロジェクトが終了すると人も減らすということが行われていので小規模ながら派遣切り（というかお役御免）ということが行われてきました。

モンスターカスタマーというかパワハラも昔からありました。私が受けたもので一番印象に残っているものですが、もう15年程前の話になりますが、風邪で休んでいるところを、無理やり出社させられて、
出社すると顧客の担当者は満足そうに笑みを浮かべており、
私がそのまま、イスに座ってボーといたら（風邪をひいているのでとうぜんなのですが）
『ぼさっとしないで、ちゃんと仕事をしろ！』
とお客の担当者に怒られ、そのままありがたい講釈を聞いたことです。
別にトラブルがあった訳でも、カットオーバー等のイベントがあったわけでもなかったので、今でもなんでこのようなことをされたのか理解に苦しみますが、まぁご自身の力を誇示したかったようです。
それ以降、幸いにして今現在に至るまで皆様良いお客様で感謝しております。

あと、35歳定年説というのもありました。35歳を過ぎるとITエンジニアとして価値がなくなるという都市伝説ですが、今これを転職市場に置きかえますと確かに35歳を超えると転職も難しと聞きます。

ということは現在ITエンジニアがおかれている労働環境は、20年後の日本の労働環境を占うことになるかと思いますが、ITエンジニアの皆様の労働環境は明るいでしょうか？、暗いでしょうか？

@ITさんのエンジニアライフのコラム実はオブジェクト指向ってしっくりこないんです！(http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html)のコメント欄に参加しました。
件のブログですが、実名と思われる名前まで出しているのでご本人はすごく真面目なのでしょうが、こちらは、「この不景気な時代に大丈夫か？」と真面目にブログ主の去就を心配したりしました。
あまりにもな文章にしかなっていないのでせめてコメント欄はましにという感じで書き込みました。
ただ、大変失礼なのですが、件のブログ主、やはり文章力に少し難があるのか、ご自身に都合のよい発言とも受け取れたり、レベルの低い発言とも受け取れる発言をされたり、いささか困りものです。好意的にみますと、頑張って書いているようですので、温かく見守る必要もあるかもしれませんが、恐らく読んでいる人たちにとっては不快感が残るのでしょう。未だに炎上してますね。

もともと内容のないブログでしたが、コメント欄にていくつか興味深い話ができましたので、私自身オブジェクト指向の現状の把握ということで整理します。


■はじめに、オブジェクト指向プログラミングと先のブログへのツッコミ
皆様オブジェクト指向プログラミングと聞いて何を連想するでしょうか？
・カプセル化
・継承
・多態性
などが、一般的でしょう。
私としてはこれに、多重ディスパッチ（マルチメソッド - Wikiを参照、書籍ではMore Effective C++の項目31）を入れたい。
こういう話をすると、『デザインパターン』とかも出てくるでしょう。
さらに『Mixinはどうした』とか・・・もう話はつきなくなるでしょう。

さて、では皆様、これらの技法って何時覚えたでしょうか？ 10年以上の経験のあるエンジニアの方の恐らく多くの方が、10年前には基本的な技法は最低限の知識として身に付けていたでしょう。私はstaticを何時覚えたのか、もう忘れた位に昔（おそらく16,7年程前の23,4才の時）になります。当たり前ですが、JavaやC#は、C++を源流にしています。staticの用法はJavaやC#でも変わりありません。

なので、得意げに
　『staticってつけるとインスタンス作る必要がないって知ってた？』
みたいなブログを読むと
　「で？」
と返したくなる。

さらに、
　『新人の奴にはstaticを教えないとダメだろ？』
みたいなことを言われると、
　「そんなことより、他にもっと重要な事があるのでは？」
とか、

はたまた、
　『他人のプログラムを引き継いだらインスタンスばかり作っていて苦労した』
とか言われると
　「いや、理解力が足りないだけでしょう。だって、この程度の文章しか(ry」
とツッコたくなる。

最後には、
　『だってRYOって奴はオレの言うこと理解したよ。だからお前も理解しろよ』
のようなことを言われると
　「ご自身の説明能力の低さを棚に上げて、人の名前を出さないでほしい！」
と怒りたくなる。

なにより、
　「貴方の小さい経験でオブジェクト指向プログラムをなぜ否定できるのか？」
というのが皆様のご意見だと思われます。


先のブログ主に「どうせ書くなら以下のようなな文章を！」と言っておきましょう。これは、7年前に私が書いたJAVA PESS 28の記事の中の一つのコラムの原稿です。念の為に言いますと記事自体は真面目な初心者向けのもので、息抜きの為に中に１つこういった曲がったコラムを掲載しておりました（どうでもいいけど関西弁って読みにくいわ～）。

--------------------------------------------------------------------------------
**なぜオブジェクト指向プログラムなのか？**
　10年前はあんまり耳にせえへんかったけど，ほんまに今やオブジェクト指向真っ盛りで，開発現場でも「クラスがぁ，オブジェクトがぁ」にはじまり「ここはシングルトンで言うたやろ！」とか，猫も杓子もオブジェクト指向って言いだしよった．ワシの職場でもオブジェクト指向プログラミングが進出してきよって，今や「オブジェクト指向技術を持っていなければプログラマにあらず」という雰囲気になってもうた．
　そんな訳で，多くのプログラマにとって無視でけへんようになったオブジェクト指向やけど，そもそも「なんでオブジェクト指向なん？」という疑問が沸いてきよる．
結果を言うたら「他に選択肢がない」というのが本音やろうな．これは後ろ向きな発言やけど，殆どの現場の人間にとってはしゃーないからオブジェクト指向を使こうてるみたいや．
もうちっと前向きに言うたら「今のところそれが一番いいと思われておる」ということかな，ミソは「思われておる」というところで，オブジェクト指向プログラミングがホンマにほかの開発方法より優れてとるっていう証拠はあんまり聞かへん．確かに「我がプロジェクトではオブジェクト指向開発をする事により30％開発期間を短縮できた」などという記事をたま～に見るけど，それ以上に現場のもんは，「難しぃ・解らへん・ついて行かれへん」と言いよる．
　「クラス」は，確かにオブジェクト指向独特の機能で，これを使こうたら複雑なプログラムもシンプルになることもある．せやけどクラスの使い方はいっぱいあって，細かいことになると専門家でも意見が分かれよる．古いところでは「多重継承の使用はいかん！」とか言ってみたり，最近では「継承そのものがいかん！」とか言い出すしまつや．一体どないせえちゅうねん．それを間に受けた現場のもんは「あーでもないこーでもない」ってそこらで議論しよる．そんなヒマあったら仕事上げろっちゅうねん．
まぁ，後10年もしたら，誰も「オブジェクト指向」って言わんようになるやろな．
--------------------------------------------------------------------------------

件のブログ主は、デビューまなしで、いきなり色々批判を受けて正直驚いたと思うが、ある程度の年齢のエンジニアは上記のような文章を過去に1万回程読んでいるので、ブログのような文章をみると本当に『時間を返せ!』という怒りがこみ上げると思われる。


■ネットバブル時代のオブジェクト指向の思い出
　若手の方はご存じないかと思いますが、おじさん連中にオブジェクト指向が否定的に受け取られることの一つに、『今から10年程前のネットバブルの時代に、破たんしたWEBアプリケーションのプロジェクトによくJAVAが使われていた』というのがあるでしょう。
もちろん全てのJAVAのプロジェクトが破たんした訳ではないですし、PHPのプロジェクトで破たんしたものもあるでしょう。が私の周りでは破たんしたプロジェクトとJAVAって結構相性が良かったりしてました。
このように書くと此処のコメント欄が炎上しそうですが、当時はJAVAのWEBアプリケーションというと結構なチャレンジだったと記憶してますです。もちろんその責任は、オブジェクト指向の考え方ではなく、充分な経験を積んだり勉強を行わないでWEBアプリケーションを作ったりした未熟な技術者にあったでしょう。人を憎んでOOPを憎まず（ってか）。

■オブジェクト指向プログラミングの現状について（私見）
　さて、先のコラムは7年前に書いたものですが、最近ではオブジェクト指向って案外普及しているなぁというのが正直な感想です。
私の最近の経験を書きますと一番印象に残っているのは、RoR（Ruby on Rails）でのWEBアプリケーションがあります。このプロジェクト自体は業務システムではなかったので件のブログのコメントではコメントしませんでしたが、これのプロジェクトが3年前になります。
ソースレビューも行われたりしたのですが、継承なんぞもみなさん普通にしてましたし、また、最近関わった他のプロジェクトでも普通に仮想関数が使われていて、まぁ隔世の感があります。

もちろん非オブジェクト指向のプロジェクトも今だにやっていますし、全てのエンジニアがオブジェクト指向を使いこなしているとはいえないのも事実です。が、先のブログのコメントに「空気のようにC++を使う」とか言われる人もいて、私も血が騒いだりします。ちなみにとりすけさん、本当にありがとうございました。私にとっては良い経験談を聞かせて頂いたのですが、あのブログのコメントではとりすけさんのせっかくの経験がものすごく汚された感がぬぐえませんです。すんません。

■それぞれ立場によるオブジェクト指向プログラムの現状
件のブログ主は、『実践ではオブジェクト指向は使えない』とおしゃっていましたが、このような発言の背景には、どうやら以下の事があるでしょう。以下、OOPはオブジェクト指向プログラムの略です。

・OOPをしなくてもおおよそ開発できる
　こういう言い方は嫌いな人もいらっしゃるでしょうが、CPUにとってはOOP言語も非OOP言語も同じになります。つまりほとんどの開発は非OOP言語でも出来ます。

・OOPが必要な程複雑なプログラムを作成していない
　件の主は、C#で作ったDBのサンプルコードをそのままコピペしてきたような開発の話をされいるようです（あくまでも私が受け取った印象です）。つまりライブラリの範囲内でプログラムをされているということと受け取りました。

・OOPを理解する技術力が足りない
　どんな道具でも使いこなせる人もいれば使いこなせない人もいるでしょう。

・OOPを使いこなすプログラミング経験がない
　OOPはやはり経験が必要だと思っています。ちなみに私の場合は解った気になるまで3年ほどかかりました。

・OOPするまでに業務知識がない
　件のコメントで私は『法人税の知識がある』と言いましたが、これはパッケージソフトが使える程度の知識です。比喩的に言いますとWindowsが使える程度の知識になります。ではWindowsを作るほどの知識となると実はこれはこれで大変だというのはお分かりだとおもいます。オブジェクト指向の教科書に動物の例があるのは背景の業務知識を動物の例に置きかえないと説明ができないからです。もちろん書籍等を書くにあたっては上手い題材を考える必要があるでしょう。ちなみに私がJAVA PRESSを書いた時は五目並べを題材にしました。

で、業務システムではなぜオブジェクト指向が流行っていないのか？
ということですが、これはSEの立ち位置によっても違うでしょう。概ね以下の理由になるのでは？と思います。

つまり、社内SEさんの傾向として（あくまでも傾向としてですが）

・OOPを使いこなすプログラミング経験がない

ことだと思います。社内SEさんはプログラミングだけでなく様々な業務があります。OOPをやる時間もあまり取れないでしょう。

で、次に受託開発を行うSEさんの傾向として

・OOPするまでに業務知識がない

となるかと思います。もちろん開発業務にあたっては業務知識は必要ですが、つまり設計する程業務知識を把握しているかどうかになります。受託開発では、概ね
　(1)仕様の決定
　(2)開発
という段取りを踏み、(1)仕様の決定では、いかにユーザさんのノウハウ（業務知識）を引き出すかがその後の修羅場を避けるうえでの重要な点になるでしょう。つまり、裏を返せば、開発初期段階では充分に分析出来るほど、業務知識が身についていないということになります。

受託開発での業務システム開発の範囲では、これらのジレンマがあって事例が少ないのでは？というのが私の意見でした。また件のブログでは、パッケージソフトを開発される方からご意見を頂き、確かにパッケージソフトの開発者ならOOPを取り入れやすいなと思いました。確かにパッケージソフトの開発であればこれらのジレンマは解消されるでしょう。

前回の更新からすっかり時間が経ち、年も越えてしまいましたが、ちょっと面白い仕事をしましたので、投稿します。

ソフトウェア稼業をしているとさまざまな修羅場（デスマーチ 炎上プロジェクト）に遭遇しますが、今回は知り合いからヘルプを言われまして、この週末に急遽とある地方都市に行ってまいりました。

あまり詳細は書けませんが、テスト中には動作していたのが客先の環境で動かすと動かないとのことで、かなりてんぱっておられる様子でした。
いろいろ話をしているうちに、私もしびれを切らせて「今からそちらへ行きます」とばかりに土曜日の朝に電車に乗り、日曜日の夜に帰ってきました。

『いきなり来てきちんと仕事ができるのか？』とか　『所詮、能書きだけで出来ないのでは？』とか思われるかも知れませんが、世の中には、火消し役といいますか、なんでも屋さんといいますか、まぁプロというものがいて、私もその末席に座らせて頂いており、人よりも少しばかり仕事ができます。
いくつかのバグを潰して、最低限、お客様に見せられるようになり、いたく喜ばれまして、私も久しぶりに手ごたえのある仕事をしました。

という訳で、ソフトウェア開発で修羅場に遭遇して藁にもすがりたい方はよろしければこちらを参照の上ご連絡下さい。ひょっとするとあなたの手助けができるかもしれません。