前回の記事ですが、読者の方から洗脳を解くには弱いという指摘を受けたのでちょっと補足を考えてみました。実際にオブジェクト指向に洗脳されている方には何をいっても聞かないのですが、そもそも論として、なんでこんな記事を書くのか？ということを説明しましょう。
一般的な話になりますが、エンジニアの中には原理主義者よろしく自身の考えを曲げない人が確かにいます。その人の世界で頑張ってもらえればよいのですが原理主義者の中には妥協という言葉をしらないのか、他人のコードや考え方に口出しをする方もいらっしゃいます。たとえば『手続型はダメ。オブジェクト指向はよい』とかですね。彼・彼女が完成されたエンジニアなら口出しも立派なアドバイスとして成立するでしょうが、ある意味究極のセオリーだと私が考えるのは『コードに正解はない』ということです。あるとすれば『こちらの方がより適切かもしれない』ということと『動くコードはやっぱり最強』ということです。あるエンジニアに、その昔私が書いたコードをありがたく手術と称してリファクタリングしてもらいましたがテストをすると重要なエラーチェックが抜けていることに気づきました。質問すると「まだ書いていない」という返事をもらいました。つまりこういうことです。エラーチェックのコードは時として見栄えが悪くなります。まぁ通常処理に加えて異常系の処理を加える関係上仕方がないでしょう。そういうコードから異常系の処理を取り払えば確かに見栄えはよくなります。さて、見栄えは良いが重要な処理が抜けているコードと見栄えは悪いがきちんと処理が入っているコード、あなたはどちらを評価するでしょうか？見栄えを取るという人は将来失業しないように気を付けましょう。
オブジェクト指向に心酔するのは構わないのですが、結論から言いますと残念ながらオブジェクト指向技術は思ったほど役には立ちません。詳しくは連載を通して理解してもらえればよいのですが、非常に残念なことにオブジェクト指向に過剰に心酔する人がいるのも事実です。例えば、この記事です。
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて
経験のあるエンジニアならこの記事が眉唾だと理解できるのですが経験の浅いエンジニアなら真に受けてしまうでしょう。少し技術的な点を突っ込んでおきます。記事中
アセンブリやCOBOLのような言語では、オブジェクト指向言語で一般的なカプセル化という考え方がきわめて弱いということがあります。変数は静的なグローバル変数が中心であり、
とありますが、アセンブリ言語でもローカル変数はあります。またいわゆるメンバ変数もシミュレートできます。もし仮にアセンブリでローカル変数がなかったりメンバ変数をシミュレートできないとすればJavaやC++のコードはどうやって実行されると考えているのでしょうか？OSはどんなふうに記述されていると考えているのでしょうか？JavaやC++はコンパイラを通して一旦機械語に変換されます。アセンブリとはその機械語に一対一に対応します。また、そもそも論としてアセンブリとCOBOLを同じテーブルに並べるところにもの凄い違和感を感じます。もしあなたが違和感を感じられないのならオブジェクト指向を勉強する前に他に勉強することがあるということになります。
さてこの方の約3年後の他の記事を見てみましょう。
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例
引用しますと、
最後に、最近になって気づいた自分の間違えについて書いておかなくてはなりませんね。以前であればこうした設計上の問題は日本のSI業界の構造が問題なのであるという話をしていたかもしれません(^_^;)が、ここで書いたような話は多少フィクションが入っているとはいえ、実際私がSI業界以外の今の会社で体験したことに基づいていると告白しなくてはなりません。言語の特性から、Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もありますが、こういった話はSIer以外でも、どこの国の開発チームでもあるのだなということですね。
この中にある
Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もあります
この感覚は実はオブジェクト指向症候群から脱する第一歩になります。多くの生き残っているエンジニアは大なり小なりこういう感覚を端緒とし、次に”Javaはダメだ○○は良い”となり、最後には”オブジェクト指向がダメなんだ”となります。もちろんですが私も20年程前にこういう感覚に襲われたことがあります。
まとめますと、オブジェクト指向症候群にかかると間違った知識をまき散らします。さらに病気から抜け出すと後でそれを修正しなければならないという二度手間が発生するわけです。できれば早く抜け出した方が本人の為でもありますし業界のためでもあります。
と長くなったのと月末でいろいろ忙しいので、今週はこれにて終了です。次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。
私の盟友（？）こと
みながわさんの日記が更新されたので覗いてみた。2016年1月29日の記事によると、とあるWEBの記事
「staticおじさん」はなぜ自信満々なのかというのが目につく。
この手の記事に対しての警鐘は以前にも行ったのだが、未だにこういう煽り記事が出てくるということは出版業界はよっぽど不景気なのか？と邪推したくなる。
アメリカに留学して習った単語にobjectiveというのがあり日本語訳は客観的で、反対語はsubjective（主観的）になります。論文を書くときは客観的であれといわれます。といっても何が主観で何が客観か分からないでしょう。本当かウソか分かりませんがアメリカではこのobjectiveということを子供の頃から教わるらしいです。もっとも子供の頃にそんなことを習ったことのない日本人は文章を読むときに、何が主観的か客観的かが判断がつかないこともあるでしょう。ちなみに何の説明もなしに『普通はこうだ』とか、他にも記事を読んで『俺の意見を代弁していてくれる』と思ったら、その記事は主観的である可能性があります（主観的の定義に従えば自明ですよね）。
さて、元の記事にあるこの部分
Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。
これは、
インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり
と読み取れます。思わず普通ってなんやねん？と突っ込みたくなるのですが、
そろそろこのインスタンスメソッドを使うのが普通という誤謬を解きたいのですが、staticメソッドは場合によっては推奨されています。
期待するコードを期待するように書こうという本から引用させていただくと
クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ
このReadable codeという本は私は英語版を購入したのですがそこでも同様のことが書かれています。
また、英語が読める人は、static methodで検索をかければいろいろ議論を見ることができます。たとえば以下のQAたち
https://www.quora.com/Why-is-using-statics-Static-method-block-variable-in-Java-programming-bad-programming
http://programmers.stackexchange.com/questions/98083/cant-i-just-use-all-static-methods
ここでは、インスタンスメソッドを使うのが普通とか訳のわからん理由ではなくきちんと事実に則って議論がされています。
事実（fact)に則って議論するということは客観的(objective)な議論ができているということになるでしょう。
ざっくりとまとめますと、staticメソッドを使うと
欠点：継承ができなくなる。ポリモーフィズムも使えなくなる。
利点：メンバー変数へのアクセスを制限できる。パフォーマンスが上がる。
ということです。他のものは自明として、利点のところで『パフォーマンスが上がる』かは検証の必要があるのですが、ポリモーフィズムはオーバヘッドを発生させるのでそれを使わなければパフォーマンスがあがる可能性はあります。
また欠点の中で、『ややこしくなる』という意見もあったのですが、これは主観的な意見でしょう。たとえばstaticメソッドを使いなれた人はむしろすっきりとすると考るかもしれません。
さて、継承もポリモーフィズムも使わないということであれば、staticメソッドを使ってもよいということになるのですが、この反論として、『オブジェクト指向でなくなる』というのがあります。もはや手段と目的が混同されているとしか言いようがない意見でいやはや疲れます。
まぁ一介の無名なエンジニアが何をいっても仕方がないのでもっと説得力のある例を出しましょう。
επιστημη さんという著名なライターさんがいらっしゃいますが、彼は思い切りstatic メソッドを使っておられます。
http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx
のコードのrefereeクラスがそれに当たります。refereeクラスには3つのメソッドがありますが、すべてstaticメソッドになっています。
つまり、事実としてstaticメソッドは使うときは使うのです。ちなみにもちろんですが、επιστημη さんがオブジェクト指向を理解していないということはないでしょう。
という訳で、
ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。
というヒマがあったら自身が思わぬ誤謬をしていないか記事の検証を行うことを勧めます。
2/4追記
コメント欄で文意を汲み取っていないという指摘を受けましたが、まぁ充分文意を汲み取って反論をしているのですがどうも分かりづらいかもしれないので、補足します。
ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。
こういう教示的な文章は一見ごもっとなことのように受け取れますが、冷静に読めば分かりますとおり、ど素人でも同様のアドバイスができるでしょう（例を出すとサッカーや野球観戦をしているおっさんが野次っているさまと同じと言えば納得できるでしょうか？）。
社会人としては自分を律したり反省することは歳をとろうが若かろうが、技術者であろうがなかろうが、常に必要でいちいちアマチュアに指摘されることではないです。
そうはいっても100歩譲って、プログラミングに携わるプロが
『（引用先の記事に書かれてるニュアンスでの）自分はstaticおじさんではないか？』
と自問するということはどういうことでしょうか？
つまり、『staticは使えるのか？使えないのか？』という正に私がここで行っている議論をすることです。
そしてまさに
インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり
こういう意見が20年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。
ヒマになると思ったのもつかの間で地味に忙しくなってきたが、今週も
極言暴論がアップされていましたのでコメントします。
これからはIT部員だとCIOになれない
テーマ自体、あまり興味がないのですが、この記事を真に受けて変な方向に走る人がいないとも限らないのと、（あまり言いたくはないが）零細企業とはいえ私も経営者として10年以上に渡ってやってきたので、その経験からコメントしましょう。
例により、いい加減な点をまずは指摘します。
「システムを作る力が失われてしまえば、米国企業などとのグローバル競争に勝てないのに」と悲憤慷慨するもの。これを内製原理主義と呼ぶが、酒飲み話としては相当盛り上がるらしい。
これからはIT部員だとCIOになれないから引用
という風にシステム開発力が失われることを一刀両断していますが、別の記事、
窮余のフルアウトソーシングは禍根残すでは、
開発部隊をどうするか。バックヤードのシステムの保守しかやっていないから、運用部隊とともに外に出してしまおう、と考えるのは短絡的。見てきたように、将来の禍根の種になる可能性が高い。それに、バックヤードだけでなく、ビジネスに直結するシステムが必要になったとき、開発部隊の不在は、より大きな問題となる。
窮余のフルアウトソーシングは禍根残す
と真逆の論調になっています。ちなみに
これからはIT部員だとCIOになれないで引用している記事もあるのですが、時系列に並べると、
2013/03/21
「システム内製こそ正義」のたわ言（内製反対）
2013/07/12
窮余のフルアウトソーシングは禍根残す（内製賛成）
2015/02/03
これからはIT部員だとCIOになれない（内製反対）
ということになる。2年に渡って言うことがコロコロと変わるようです。CIOを目指す人は数年に渡って活動をするかと思いますが、そういう長期スパンで考えた場合に参考になる記事ではないでしょう。5年後にどういう主張をするか分かったものではありませんので。
とりあえず、
余計な心配をする前に記事の矛盾を解消しましようね。
と言っておこう。
CIOという職種がなくなったり社長（CEO）が兼任するということであれば、いろいろな理由があるでしょうが、今の日本の状況で一番の理由として考えられるのは、単純にその会社にポストがなくなったのでしょう。つまりその会社が衰退しているだけです。
有名どころでは電気産業の衰退が挙げられます。電気産業ではIT部門を縮小したりアウトソースしているらしいですが、電気産業といえば自動車産業とならんで日本経済を引っ張ってきた産業でしたが、ココに来て国際競争に負けて絶賛リストラ中ということでしょう。
「システムを作る力が失われてしまえば、米国企業などとのグローバル競争に勝てないのに」と悲憤慷慨するもの。これを内製原理主義と呼ぶが、酒飲み話としては相当盛り上がるらしい。
これからはIT部員だとCIOになれないから引用
記事では只の愚痴のように扱っているが、只の愚痴か本当に警告なのかを区別しないといけないでしょう。もし警告を愚痴という風に受け取る経営者がいたらそれはそれでダメでしょう。電器産業の場合、恐らく経営者もIT部門を切る問題点は理解しているが、それ以上に経営が圧迫しているということでしょう。つまり追い込まれている訳ですが、経営というのはトレードオフを決める作業になり、トレードオフの結果IT部門を切っているということになります。
ただし、IT部門とトップマネージメントのどちらの言い分が正しいか、つまり経営判断が正しかったかどうかは今ではなく、これから解ることになります。もっとも円安になっているにも関わらず電気産業の景気のいい話を聞かないのは、国際競争力を失ったということで、電器産業が斜陽産業と化したという証だと思われます。
とまぁ暗い話になりましたが、私の半径3メールのエンジニアに聞いてみましたが『CIO?ピンとこないな・・・』と返されました。私もそうですし、多くのエンジニアがそんなものかと思います。
ITエンジニアたるものCIOを目指すのではなく、結果としてCIOになっていたというふうに精進したいものです。
今週は
『極言暴論』がアップされていた。ゆっくり読んで週末にコメントをアップしようかと思っていたが、英検の結果が良くなく今週は勉強に集中したいので、とっととコメントします。
発注者として最低最悪、公共機関のシステムをどうするのか
何からコメントするか困惑するが、かと言ってあまり時間をかけてもいられないので、決定的な間違いを１つ指摘する。記事の４ページ目の下から２段落目で、
政府情報システムの整備及び管理に関する標準ガイドラインについて
システムを導入する際には利用部門の業務改革を行うことを義務付けている。全く正しいが、この手の業務改革は民間企業で軒並み失敗しており、ハードルはさらに高くなる。
記事から引用
と言っているが
そのガイドラインを見てみたが『業務改革を行うことを義務付けている。』とはどこにも出てこない。近いものでは、『業務の見直し』という章がありそれを引用すると
ＰＪＭＯは、情報システムの整備を行うときは、制度所管部門及び業務実施部門を中心に、次のとおり検討し、既存の業務の見直しを行うものとする。更改又は機能改修を行うときは、更改又は機能改修の規模、内容等を踏まえ、既存の業務の見直しの必要性を判断した上で、当該見直しを行うものとする。
なお、新たな業務を開始するに当たって情報システムを新規に整備する場合においても、効率がよく、かつ、効果の高い業務となるよう企画立案し、その内容をこの章の５．に規定する業務要件として定義するものとする。
ガイドラインから引用
とあるが、これは『業務改革を行うことを義務付けている。』ということではない。
いわゆるシステム開発の上流工程では業務分析を行うが、そもそも論として『その業務が必要なのか？』とか『ちょっと業務を変えれば従来システムが使えるのではないか？』ということがある（実際の運用業務開始後でも同様のことが発生するが）。これらは発注時に『なぜそのシステムまたはその改修が必要か？』という質問への回答になり特段リスクの高い作業ではない。こういう話はシステム開発のイロハである。
記事ではガイドラインを熟読したとあるがガイドラインでは『業務改革』という言葉自体が出てこない。
いったい何をどう読んだら『業務改革を行うことを義務付けている。』という解釈が出てくるのか謎だが、少なくとも筆者がシステム開発の素人だということはよく分かった。日常的にシステム開発に携わっているかプロジェクトマネージメントの教科書がきちんと頭に入っていれば、こんな間違いはしないでしょう。まぁ、
自身の不勉強を棚に上げて公共機関に対して『バカ』と言える度胸をほめつつ、「一度、きちんとシステム開発の勉強を行い、発注側および受注側の業務を経験してから評論しましょうね」と言っておこう。
せっかくなので、ガイドラインについてコメントしましょう。
ガイドラインですが極めて基本に忠実な印象があり特段コメントはないですが、抜けているとしたら以下の観点が思いつく。
１．ガイドラインを順守するコスト
２．プロジェクト関係者に対してガイドラインを順守させるリスク
３．ガイドラインにプロジェクトの規模についての観点がない
まず、コストについてですが、ガイドラインの背景および目的には
まさにこの政府情報システムを業務の見直しも通じて効率的かつ効果的に整備及び管理することが電子政府の構築につながり
とあるが、ガイドラインを守らせようとするにもコストがかかる。例えば10人が関わる2時間のレビューを1回すれば少なくとも5万円以上掛かることになるが、プロジェクトを通してレビューにかかる総費用と、レビューをすることにより期待できる費用削減効果を考慮しなければならないでしょう。
次にリスクについて、プロジェクト関係者がどれだけガイドラインを理解しているか？例えば発注者が『業務改革を行うことを義務付けている』と解釈していたらプロジェクトが変な方向に行くでしょう。
その他、官僚的な組織によくあることだがガイドラインを悪用して足を引っ張る人が出てくる。つまりプロジェクト推進派と反対派がいた場合、反対派はガイドラインを盾にとってプロジェクトを妨害する可能性がある（実際そういう現場を見たことがある）。
このように場合によってはガイドラインを守らせることが返ってリスクになる場合もあり得る。
最後に規模の観点について、一般論になるが大規模プロジェクトに関しては充分な準備が必要であるが、小規模なプロジェクトの場合、あれこれ悩むよりやった方が速いこともある。つまり予算が100万円規模の小さいプロジェクトの場合いちいちガイドラインを守るより、別途100万円用意して（つまり計200万用意して）不測の修正に対応してもらった方がうまくいったりする。が、ガイドラインではそのような柔軟性がみあたらない。もっともこれについては国の事業ということの縛りがあるのか、はたまたガイドラインの運用でカバーするということも考えられる。
とまぁ、確かに糾弾されるべきお役人もいるが、的外れな指摘をする素人に『アホ』といわれるお役人には同情するしかない。ガイドラインへの意見でも重箱の隅をつつくようなものもあり、それに対して真面目に対応する様は『ご苦労様』と言いたくなる。
が、だからと言って国民の監視の目を緩めるわけにはいかないのでそういう意味では記事の存在価値はある（中身が残念ではあるが）。
今週は極言暴論がお休みだったのだが、その代わりに
記者の眼に記事が上がったらしい。
本当は突発的な仕事が入りちょっとヒマでなくなったのでパスしたい気満々なのだが、私の極言暴論watchを読んでいらしたのかどうか、極言暴論ではなくど真ん中のストレートで書かれたらしく大変参考になるとのことで、こちらも真面目にコメントします。
この記事を１行でまとめると、とある会社で『IT部門は要らない』と宣告し、その４年後にIT部門を解体したらしい。
らしいというのはどういうことかというと記事では従来あった基幹系のシステムがどうなったのか？置き換わったのかどうかとか具体的なことが今ひとつ見えない。ただ『成功した』としか書いていないのである。
で、調べてみるとその会社はちょうど４年半程前に１６００人規模の早期退職者を募集しそしてほぼ実行したとのことである。追加でコメントするとリストラ中に希望退職に応じなかった社員を出向させ、その後、裁判経て和解の結果、出向を取り消した経緯がある。ただ、
元の記事にはそのことには一切触れておらずに稀有な成功例というふうに賞賛している。記事を読んで、『ジャーナリズムとはなんなのだろうか？』と疑問を持たざるを得ない。
リストラ等を経験した人は、この４年間に何があったか想像できるだろう。そしてリストラを行う経営者が
『君たちは要らない』
といったら経営の失敗を従業員に押し付けていると思うだろう（今から１０数年前に「社員は悪くありませんから」と泣いた社長を思い出す）。しかもIT部門
は要らないのではなく、IT部門
も要らないのである。この一字の違いは大きいでしょう。
４年後にリストラが成功したとのことであるがそもそもリストラは短期間（数年間）の成果を追うためのもので、その際にカットした施策が良かったのか悪かったのか、つまり本当の意味でのリストラの成果はもう少し長期的な視点でみないとわからない。大会社の場合、体力がある分、何もしなくてもしばらくは潰れないしリストラの成果も見えにくでしょう。
しかし、リストラする側が経営責任に触れずに『君たちは要らない』と本当に言ったとしたら、要するに働く人をリスペクトしない世の中になったんだな〜と思うばかりである。ちなみに私は正社員だけを擁護しているのではなく、安易に派遣社員や契約社員を切り捨てる社会の風潮に疑問をもっており、また安穏として仕事をしない正社員の方を擁護するつもりもない。が実際に私の半径3メールの経験でいうと仕事をしない人は皆無である。
まぁ、この記事を書いた人に『リストラされたことがあるのでしょうか？』と本当に聞いてみたくなった。