狂戦士と錬金術師、ベルセルクとアルケミスト

ある日の夕方にTVをザッピングしてたら、巷で大人気の『鋼の錬金術師』がやっていた。面白いという話は聞いていたけど、少年漫画だし、天の邪鬼というわけではないですが「万人ウケする作品はそんなに面白くないんじゃないか」と思ってて、進んで手を出す気にはなれなかった。それに僕はハードな作品を好むので、『ゆるせない話』が放送自粛に追い込まれる程に視聴者がクソ五月蠅いこの時代において大人気獲得＝ソフトな気がして、僕はそんなに好きにはなれないだろうな～と思っていた。

で、その日は暇だったのでちょっと観てたんですけど…あれ？面白そうじゃないですか。テーマはそこそこ重たそうじゃないですか。でも、たまたまその回だけがいいのかもしれないので、一応何度か観てみたり、ブックオフで立ち読みしたりして検討した結果、このたび原作漫画を全巻購入する運びとなりました。いや～やっぱり日本の漫画ってレベル高いですね。



この作品の素晴らしさは散々語り尽くされ倒しただろうし、そもそも僕はこういう作品を批評しうる文化レベルを持ち得ないので、ここでは特に語れる事など無いですが。
ストーリーと関係無いところで言えば、作中のギャグや単行本巻末のおまけ4コマ等を鑑みるに、この作者笑いのセンスも高くね？

ところで、「所々の設定とかがベルセルクに似てるな～」と思った。
ググって調べてみたら、同じ感想抱いた人も結構いるようで。



ちなみに僕が思いつく類似点は以下です。

• 鋼の義手
• 血の色をした究極アイテム（『ベヘリット』と『賢者の石』）
• 『日蝕』の一大イベント
• 魂とかが還る場所
  （「一なるところへ」「全てのものは一へと帰って行く」）
• 『生贄』と『人柱』
• 復讐に燃えるごつい男
• ホムンクルスは使徒っぽいし（特にエンヴィー）
• 髑髏の騎士は多分アルフォンスと同じ鎧魂男
• 世界の仕組みを語るシーン
  ベルセルク24巻の「それが魔道です」
  ハガレン6巻の「それが錬金術」
• サブタイトル間の挿絵の雰囲気（黒地に白文字な所とか）

他にも何かあったような気がしたけど、まぁこんなもんでしょうか。
ちなみにギャグセンスは『鋼の…』の圧勝ですが。

『鋼の…』の方の原作は既に終末に向かっているようで、何となくどういう終わり方するのか想像がつき、ちゃんと話纏まって終わりそうですけど、問題は『ベルセルク』。10年以上読んでいるけど、この作品の終わり方だけは全く想像つかん。ちゃんと考えているんですかね？大丈夫なのだろうか？
ちなみに僕の最終回予想ですが、何だかんだでハッピーエンド！って思ったらテレジアに復讐されてバッドエンド、というものです。過去に登場したキャラがひょっこり登場ってパターンが割とあるじゃないですか。

ていうか相変わらず休みすぎ！

＊

『鋼の…』みたいなそこそこ重くてそこそこ残虐（僕はそんなに思わんが）な作品が受け入れられるのに、繰り返しになるけど『ゆるせない話』が何で自粛に追いやられてしまうんだ？分からん。
まぁカテゴリ全然違うので比較するのが間違ってるかもしれんが。

スードラの下のバリア、プログラマの下のコーダー

現在社会人4年目、27歳。今のところプログラマとしてのキャリアのみで、SE経験を中々積む事ができておらず、自分の行く末を非常に危惧している。以前からのオフショア化の波に加えて、昨今のクラウドやSaaSの台頭により、プログラミング以下の仕事すらどんどん減少していく状況である。エンドユーザーとの交渉スキル等、SE経験で得られるスキル無しでは生き残れないだろうから。

うちの会社、SEのパイは一応あるにはあるのだけど…少ない。プライム案件で直接エンドユーザと遣り取り可能なポジションであれば尚更（大抵は、プライムであってもお客さんの情報システム部までしか接触できない模様）。さらにその少ないパイは、どうも社員の大半を占めるおっさんCOBOLerに優先して割り振っているみたいなんだよな。実際、上期の中間面談で「枠は無い」って言われたし、同期や1～2年上の先輩の様子見てても難しそう…。周りを蹴落とすぐらいの力がお前に無いからだ！と言われれば返す言葉も無いですが…ただ、一つ言い訳させて貰いますと、

若い社員にSE枠を付与
↓
あぶれたおっさんCOBOLerはプログラマ枠へ
↓
しかしこの人達、年功序列制度のせいで現在高給
↓
さらに、オープン系言語等の再教育コストがかかる。
てか基本的に勉強する気がない。
↓
追加コストを払ってまで、高給取りを単価の安いPGとして働かせるのは利益率悪すぎ
↓
SE枠はおっさんで

…多分、こういう事情もあるのだと思います。
他には、僕はプログラマとしては（うちの会社の中では）かなり生産性が高いので、お客さんやプライムベンダのペースに振り回されるSEとしてより、プログラマのままとしておいた方が全体最適だ、というのもあるかもしれない。

はい、前述の通り、僕はプログラマとしては（うちの会社の中では）いい仕事してきたんです。また、SEが作ってきた仕様・スケジュールに対し「このA機能を先に作った方が、かくかくしかじかで効率いいと思いますよ」とか「B機能の○○ロジックは規模がでかいので、1機能として切り出して分業させた方がよいのでは？」等、周りに比べたら積極的に発言してきた方だと自負していますし。「これでもまだ足りないのか？」「相当パイが少ないのか？」とずっと思い悩んでいた最中、最近ふと疑心暗鬼に取り憑かれた。
「できる人間だからこそ、SE経験積ませて貰えないのでは？」と。

というのは、僕が新人の頃の新人歓迎会にて、つまり歓迎されてた時「できる人間はすぐ辞めるんだよね～」と言われたからだ。新人研修での成績がズバ抜けていたらしく、また入社前にソフトウェア開発技術者資格を取得済みだったこともあり、『できる人間』と見なされたらしい。「何でうち（の会社）来たの！？」ってのもあったな。もうホント度肝抜かれましたよ。新人歓迎会でそんなこと言うか！？
つまり、僕が思うに「いつ辞めるかしれない『できる人間』に、貴重なSE経験を積ませるのは勿体ない」という考えが根底にあるのではないかと。
完全なる僕の思い込みであれば、それは本当に会社に対して申し訳ございません！って話ですが、でもそういう思い込みが発生してしまっている時点で、会社を信頼できていない事が浮き彫りに…

ということで、そろそろ転職を考えないといけないのかなと思い始めている。まぁ、この大不況にSE経験無しが飛び出した所で仕事なんて見つかるわけないだろうから、すぐには動くつもりはないですが。ただ準備だけはしておこうと、最近、これまでの技術経歴の棚卸しをしました。で、それによって発覚した驚愕の事実。

「俺、Java初級じゃねぇか！」

よくよく考えたら、仕事ではオブジェクト指向プログラミング（以下、OOP）した記憶が無く、手続型ロジックしか経験無いことに気付いたんですよ。で、Javaプログラマの初級・中級の定義を調べてみたら、わんくまの方がこう言っています。

• 凪瀬Blog：初級者と中級者の間の壁

「Javaはコーディングができるという初級者と、プログラミングができるという中級者の間に大きな壁があります」
「…クラスを利用できる初級者とクラスを作れる中級者・上級者との間の壁…」

どうやら、OO使ってクラス設計してない内は初級だと。Javaで手続き書いているだけなら初級だと。そういう内はプログラマではなくコーダーだと。
はい、僕、クラス設計したことなく、手続き書いているだけの、コーダーです…

この3年半、様々なJava案件を行ったり来たりしてきたのだが、殆どの案件が「プログラミング不要！」「OO不要！」を謳っている内製向け商用フレームワークを適用した案件だった。OOPの概念は無く、ただ手続きを羅列していくだけの作業。UMLとかの『クラス図』を見た事がないという事実が、OO使ってない事を物語っている。ていうか、FWに依存する画面系はともかくとして、共通部品くらいはOOで作ればいいものを、設計担当者が悉くOOを使おうとせず（そもそも分かってない？）。部品のロジックパターン毎にクラス分割して多態性使って呼出部品切り替えればいいところを、分割単位はメソッド、呼出切替はif文…

フレームワーク特有のスキルはかなり身についたが、スキルって言っても『可能・不可能なこと』『向き・不向きなこと』は何かとか、あとは設定パラメータをどれだけ知ってるかってなもんで、とてもスキルなんて言える代物じゃない。それに何より、マイナー（※1）。上司は「マイナーだから競合相手がいなくて良い！」って言ってたけど…単純に情けない話だと思うし、それに繰り返すが『内製向け』FWなので、お客さんも徐々に内製にシフトしており、確実に発注減ってきてますよ！今年夏の現場なんか、詳細設計すらやらせてもらえなかったんですけど！
※1：懇親会とかで聞いてみるんですけど、まあ知ってる人いませんね。唯1人知ってた方は「使いにくい！」って仰ってました…

実務経験　　　：3年半
経験言語　　　：Java　約3年　※但しOOP、クラス設計、5.0以上の経験無し
他は.NET系を少々
フレームワーク：それどこの？

何てこった、俺、空っぽじゃねぇか。市場価値なんて無いに等しい。SEはおろか、プログラマですらなく…スードラの更に下に実はバリア（アンタッチャブル）という最下層階級がある事を知った時並の悲しみ、と言ったら大袈裟だけど…

果たして俺は這い上がれるのだろうか？

＊

そんな俺にも、やっと中級者へのステップアップのチャンスが。今月仕事はピュアJavaによる計算ライブラリの基本設計～単体テスト。基本設計にはクラス設計も含まれている。バージョンも初めての5.0。よっしゃ！計算ロジックは5パターンあり、全パターンで共通のロジックもあるので、これは継承と多態性の使い処だ。計算パターン毎にパラメータが異なるので、それらはそれぞれBeanクラス作って…といった感じで、今月はいつになく張り切って楽しんでいます。

ただなぁ…プロジェクト規約でクラス名を『ABCDX(0～9の連番)』とIDみたいにしなきゃいけないんですけど、その『0～9の連番』ってあるように、クラス数10個以下に抑えないといけないっぽいんですよ。前述の通り、計算パターンで5あり、それぞれのパラメータ用のBean作ったらもう在庫切れちゃうんですけど…『規約』というより『制約』だなこりゃ。全く。制約があって燃えるのは恋愛だけだっつーの。
あと単純に、Beanのクラス名がIDみたいな名前だと、分かりにくいったらありゃしない。『囚人クラス』と呼んでますよ。

ちなみに、JUnitも初めて仕事で使いました。やっぱり再テスト時は物凄く便利ですね。心置きなくリファクタしまくれる。けど、テストコードは単体テスト仕様書とは見なされない…

『しんぼる』レビュー～TVでできない事やるのでは…

松本人志のラジオ『放送室』をしょっちゅう聴いている。mp3化してiPodに入れて、通勤中・ジョギング中に聴くのが主だ。聴いてたら顔がニヤついてきたり、場合によっては吹き出しそうになってしまい、近くのストレンジャーからストレンジに見なされる事がしばしば。『今の時代、気持ち悪がられている方が安全だ』というのが持論なので、僕にとっては一石二鳥。実際、電車でニヤついていると、僕の周りが少し空く事があり、『安全』とは違うが『得』。いや、周りが空く事により『痴漢冤罪の可能性が減る』って考えると『安全』に繋がるか。いやいや、ニヤついている奴なんて怪しすぎるから、むしろ間違えられる可能性高いだろ。

電車だけに話が脱線したが、先月また第1回から聞き始めた。番組が始まったのは2001年秋、アメリカのあのテロの余韻冷めやらぬ頃だ。『ごっつ』の秋スペが低視聴率だったといったような懐かしい話、現在の松本氏の状況考えると何か新鮮に聞こえる結婚トーク等、再び楽しんでいる。そんな感じで楽しんでいると、ある回で「TVでもう面白い事できない」から「VISUALBAMを再開する」と言っていた。あー確かにそんな事言ってたなー、ところで何で再開しなかったんだっけか？と思って回を進めていると、「映画撮ります。だからVISUALBAMは一先ず置いておく」、あーそうだっけか。つまり「TVではもうできないようなぶっ飛んだ事は映画でやる」って事ですね。

で現在、そんな事を言っていた氏も既に2作撮りましたが、当時の決意は果たして実現できたのか？･･･プチ信者の僕としては、正直どちらも物足りなかった。ぶっ飛んだレベルではない。実際、本人も「大分レベルを抑えた」とか「海外でも伝わるように台詞を抑えた」とか言って、思いっきり大衆向けに作っているような事言ってたし。それでも『大日本人』は普通に面白かったですけど。とは言っても、『面白い』というハードルは越えてはいるが、氏が今まで創ってきた多くの作品の中で特別上位に入るようなレベルではなかったというのが正直な感想ですが。純粋な『面白さ』で言えば、『HEY! ×3』の遠藤久美子とのトークの方が上だったりする。

では、この秋公開された『しんぼる』に関しては･･･という事で、ちょっと遅めのレビュー。
と言っても、そんなに文化レベル高くないので、大した事言えませんが。
尚、殆どTwitterの焼き回しです。
注：ネタバレあり。ていうかもう公開終了してるか？

＊

正直、笑えるものではなかった。この世の仕組みをこんな風に捉える創造力は流石だと思ったが。

笑いの要素が転がっていたのは（僕の中では）『修行』パートのみなんですが、全てベタなんですよ。ドリフのコントみたいに（別にベタがいけないとかドリフが面白くないと言ってる訳ではない）。素人の僕でも笑いの展開が大体予想でき、実際予想通りになったことがしばしば（醤油の件とか）。ベタと言えば、氏が『放送室』で特に多用している『一周回った笑い』というのがありますが、そう捉える事も出来なかった。

『修行』パートの『しんぼる』押下時の現象、真っ先に頭に浮かんだのは『マイクロフィルム』。それが浮かんでしまってからは、ひたすら『出前一丁』が出てくるのか待ってる自分。帰宅してからググってみたら、みんな同じ感想を抱いたようで。他には、ドアに向かってダッシュの件は、雰囲気は確かに『引っ張る男』。まあそんな感慨を抱いたというだけ。

『実践』パート以降は何にも無かった。これ以降の『しんぼる』押下時の現象は、『お笑い共通一次』の理科の問題「アルコールランプで加熱したら」「ハムが飛ぶように売れた」みたいな感じで、現世に発露するんですけど、その現象が『首が伸びる』とか『火炎放射』とかいった感じで（悪い意味で）ぶっ飛んでいるんですよ。ここはベタな感じの方が良かったんじゃないかな？前述のハムのような。ど素人の僕が思いついたのだと、押す度に「メガ牛丼一丁！」。世界向けにするなら「メガマックプリーズ！」とか。
それと、このパートだと天使が大人じゃないですか。なんで、『しんぼる』も大人仕様にして、その上にモザイク被せるなんて演出はどうだろうか？なんて思った。『大日本人』の娘のように。

＊

以上、やっぱり大した事書けなかったな。精進せねば。ちなみに世間の酷評とは裏腹に、僕の周りの客は結構笑ってた。前述の醤油や腰打ちの件とか。一番最初の絶叫（CMでもやってるあれ）のシーンで笑っているのは訳分からんかったが。

プチ信者としては、世界や大衆無視して、本当にぶっ飛んだものを創って欲しかった。キャシーのコントのようなものを。公開前のたけしとの対談でも「TVで面白い事出来ないから映画に逃げてきた」って言ってたのに･･･。でもそれだとスポンサーが金出さないんだろうな。これまた放送室で言っていた「この世のトラブルの原因の殆どは金」、トラブルの原因に限らず、何するにしても結局金か？

ゲームがファミリー・大衆向けになってきたのと同様、松本氏の笑いもそうなってしまうのだろうか（既になってる？）。正直、氏の場合は結婚しても子供産まれても路線変更のような事はまあ起こらないと思ってきたが、分からなくなってきた･･･。あぁ、人生の楽しみが･･･

ちなみに、就職前に僕は夢を描いていました。
『物凄く稼いで、松本人志のスポンサーになり、視聴率とか売上とか一切気にしない好き勝手な作品を創り続けてもらう』
という夢を。
そんな僕の現在の手取りは20万にも満たず･･･

（後記）
ずっと思っている事だが、ポップコーンやドリンクは無しだろ。ガサガサ音とかがとにかく鬱陶しい。あと携帯はバイブでもNGだっつーの。

システム開発アンチパターン～旧バージョンのロジックを残すな！

『旧バージョンのロジックを残す』とはどういう事か、まあ大体想像つくと思いますが、一応説明させて頂きますと『新ロジックの側にコメント化して残す』という事です。
僕の会社の例では、以下に示すような定数CONST_Aの値を変更する場合（言語はJava）、

従来のロジックはコメント化し、その上に修正ID・修正者・修正日付等の情報をこれまたコメントで追加し、旧ロジックの下に新ロジックを追加します。


修正前後の差分がソースコードだけで確認できるので一見良さ気です。そのソースコードの修正が絶対に1回までしか発生しないのであれば、これでも良いでしょう。でも現実はそんな訳ありません。長い間メンテして何回も修正されていくと、以下のようにカオス化し、ソースコードが見にくく（醜く）なっていきます。

例ではただの定数宣言部でしたが、計算等を行っているような業務ロジック部分が例のような状態になっていたらもう最悪です。現バージョンのコードが旧ロジックの中に埋もれてしまい、ロジックの流れを追ったりするのに非常に邪魔になります。今年夏に担当した、当エントリを書くきっかけとなったシステムでは、ソースの総行数7000行中旧ロジック3000行という超大作がありましたよ。そのままだと現バージョンのロジック追うのが大変だったので、コメント行の色を深紅のバラ色に変更して追いましたよ。そしたら目がチカチカして堪りませんでしたよ。

今時、Subversion等のバージョン管理ツールという非常に便利な無償ツール使えば、ソースの修正履歴・差分の確認行えるので、旧ロジックは残さず排除すべきです。さらにRedmine等のプロジェクト管理ツール（厳密にはBTS）とバージョン管理ツール連携させれば、修正要件との紐付けもバッチリです。

ちなみに、そのシステムはバージョン管理ツール導入してたんですけどね。2007年にCVSを（遅っ！しかもSVNじゃないのかよ！）。弊害しか生み出さないこんな運用を、何で未だに行っているのか分からない（実際、担当したプログラマは全員が「間違ってる！」と言ってたし）。恐らく『修正IDでgrepして修正箇所を一括確認したい』要するに『楽して確認したい』というのが理由ではないかと僕は予想してました。

4年以上もこんな運用してきて誰も改善してこなかったのが非常に悲しい。いや、改善提案してきたけど通らなかっただけか？とにかく、僕は上司に改善を申し入れました。すると以下のの答えが返ってきました。
「ピンポイントでそのロジックの修正者、修正日付、修正理由を調べたい」
つまり『ソースコードからの修正要件の逆引きがしたい』という事のようです。うーん、結局『楽して確認したい』って事ですよね。ソースコード見るだけで修正要件確認したいと。一々修正台帳やCVSのコミットログからトレースしたくねえよと。そりゃそちら側としては楽で良いかもしれませんが、その為だけにソースコードを醜くし、修正難易度を上げ、それにより修正工数・デグレ発生度アップし、品質低下させるなんて、馬鹿げている。そもそも『ソースコードからの逆引き』なんて、多分バグった時の責任追及時に行うのでしょうけど、そんな機会しょっちゅうあるもんなんですかね？

やっぱり結局は『修正IDでgrepして一括確認』したいのが本音のような気がする。でもこのやり方では修正コメントに修正ID含めるの忘れた場合、確認漏れが発生してしまいます。ていうか実際にありました。しかもその修正が原因でデグレ発生してやがんの･･･。結局、修正箇所の確認は一つ一つバージョン比較して行うしかないと思います。そして確認の際は、前述の様にデグレが発生していないかも確認するため、修正した部分だけでなくメソッド単位で確認すべきだと僕は思います。

ただ、このシステムの場合メソッドの行数が数百～千行だという･･･