SQLってみんなどのくらいかけるの？
ブコメみてて「SQLなんて基礎の基礎だけでいいわ 」とか「どーせ忘れる 毎回ググれば良い 」とか「本職と言ってるWebプログラマは実際には大してSQLできない人も多いので〜」とかあるんだけど、SQLできないとWebアプリとか作れなくないか？このブコメに限らず、SQLの話題になった時、一定数の割合でSQLを敵視するような人がいてビビる。気楽に使えばいいじゃん。
あれか、DB屋ってわりとマサカリ投げてくる人が多めの印象だけど、そのせいでSQLも嫌いなのかな？DB屋なんて見下せばいいじゃん。DB屋は、自分たちが見下され続けた結果、マサカリを投げることしかできなくなってしまったかわいそうな人達なんだよ。
ある退職エントリについて思ったこと
このエントリ読んで思ったこと。
本当はやりたい仕事があるけど、配属された部署は自分のやりたい仕事ではなかった、という人、これまで何人か見てきました。 古い世代の人は「会社員として働く、ということはそういうことだ。組織の一員である以上、泥をかぶる必要もある」って考えるのかもしれないけど、なんのスキルの向上につながらないことを長年続けた後に、あっさり会社側から切られる、ってことがないんですかね？
転職でよかったと思いますよ。
北朝鮮情勢の予想
トランプ大統領が来日している。当然、北朝鮮情勢についても話し合われることかと思う。今後の事態の推移について、推測してみたいと思う。
現状維持シナリオ
少なくとも５〜１０年は、戦争で事態を解決するのではなく、現在行っている経済制裁を続けていく、というのが、一番ありそうなシナリオだと思う。 この事態の関係国は、アメリカ、北朝鮮、中国、韓国、日本、ロシア。この中で、戦争を望んでいる国はないのではないだろうか。
それぞれの国が戦争を避けたいと思っている理由は以下。
- アメリカー自国から遠く離れた極東のために、自国の軍隊の出血は避けたい
- 北朝鮮ー戦争になれば、破滅することがわかっている
- 中国ー極東情勢の変化を望まない。
- 韓国ー戦争となれば、かなりの被害が想定される
- 日本ー＊後述
- ロシアー極東情勢の変化を望まない。
考えると不思議な気分になるのは、他の国のことは思惑が何となく推測できるのに対し、日本政府がこの問題をどのようにして解決しようとしているのか、いまいち判らないことだ。仮に戦争になった場合、北朝鮮から飛来するミサイルにより、どのくらいの被害が想定されていて、どのくらいの被害なら許容範囲だと考えているのであろうか。「日本を守り抜く」というフレーズからは、一発の着弾も許容できないと思われる。そうなると、日本としても戦争になる事態は避けたいのではないだろうか。
また、２０１８年に平昌オリンピック、２０２０年に東京オリンピックと考えると、最低でも２０２０年までは何も起こしたくないとアメリカ、日本、韓国は考えているのではないかと思われる。
戦争をする積極的な理由が各国にないため、当面は戦争はないと考える。
戦争シナリオ
戦争へ至るシナリオはいくつか考えられる。
まず、北朝鮮がアメリカの考えるレッドラインを踏み越えてしまい、アメリカが事態を座視するわけには行かなくなった場合が考えられる。アメリカのレッドラインは、
になるかと思う。北朝鮮にラインを超える意図がなくても、例えばグアム沖１００ｋｍなら大丈夫だと北朝鮮は判断したが、アメリカはそう思わなかったケースで戦争になる可能性がある。
次に、アメリカが自国の軍事力に圧倒的な自信を持っている場合が考えられる。空爆だけで決着できる確実な自信があれば、アメリカは先制攻撃に踏み切るのではないだろうか。ただ、現時点の軍事技術を持ってしても、空爆だけでは決着しないであろう。その場合どうしても地上戦を覚悟しなければならないのだが、アメリカにその覚悟はあるのだろうか。
15年前のプログラマ
はじめてのJava
１５年前、私は異業種からプログラマに転職した。最初の会社は特定派遣専門の会社で、自社のオフィスに行ったのは面接の時だけであった。この時、同じ時期にもう一つの会社から内定をもらっていたのだが、そちらの業務内容はサポートセンターであった。サポートセンターの方が給料が良かったように思うが、今考えると、そちらに行かなくて本当に良かったと思う。
派遣先の会社は、SI２次請けで、最初の仕事はJavaのAPIドキュメントの作成だった。研修なんてなかったので、標準APIのドキュメントを参考に、見よう見まねで作成していたのだが、本当に自分のような素人が作成していていいのだろうか、と思いながら作業していた。後にわかったことだが、そもそもAPIドキュメントなんて誰も信用しておらず、APIの本当の仕様を知りたければソースを読む、というのが実態であった。
一ヶ月ぐらい後で、Javaのプログラム作成を行うことになった。未経験であるがゆえに、当然わからないことだらけなので、他の人にいろいろ質問しにいくのだが、そこでわかったのは会社でJavaのプログラムを作った人が誰もおらず、皆C/C++プログラマである、ということであった。Javaがある程度使い物になったきて、これからはJavaだ、Write once,run anywhereだ！と叫ばれていた時代であった。今考えれば理解できるが、当時はじゃあなんでC/C++で作らないんだ？と思っていた。
周りにJavaを知っている人間がいなかったので、入門書を見ながらJavaを覚えていった。C/C++プログラマからも、再帰呼出しや自動変数とヒープ変数の違い、クラスとインスタンスについて教えて貰った。C/C++でどうやるか教えてもらって、それをJavaでどうやるかを考えるような進め方だったので、共用体とかマクロとか結構困った。後に、C/C++でもプログラムを書くようになるのだが、シンタックスシュガーが多いので、正直あまり好きではない。一人で作るのならいいのだけど、複数人で作るようなものだと、各個人でスタイルが異なるので、プログラムを読み通すのが大変だった。今時のプログラマなら、コーディング規約は？命名規約は？と思うかもしれないが、昔はそんなことはどうでも良かったのだ。
プロジェクト
働き始めて半年くらい過ぎた頃、とあるプロジェクトに参画することとなった。当時はわからなかったけど、それまでの半年は、要件定義やら基本設計を行っていた時期で、自分はプロトタイプ的なものを作っていたのだった。「プロトタイプ的なものを作っていた」というとかっこよく聞こえるかもしれないが、要は「JavaというのはC/C++に比べて誰でもできるものらしい」「じゃあ素人に覚えさせてどうなるか見てみよう」ということだったのだろうと思う。素人にやらせて、どうにもならなかったらどうするつもりだったのかと思うが、まぁなんとかするのだろう。
プロジェクトが始まった。私の担当工程は、詳細設計、コーディング、単体テスト、結合テストであった。プロジェクトは炎上した。今考えると、うまく行かなかった原因は２つであったと思う。
１つは、独自のフレームワークの設計がまずかったことだ。そのフレームワークは、細かく部品化した業務ロジックをJavaで作成し、フローの設定をXMLで記述する、というものであったが、何か問題があったときに、Javaのコーディングがおかしいのか、XMLがおかしいのかすぐにはわからなかった。また、そのような作りである以上、オブジェクト指向ではなく手続的（今時の言葉で言えばトランザクションスクリプト）に徹するべきだが、実装の業務ロジッククラスを作るのに、やたらに複雑な継承ツリーを要求されるのもダメな点であった。今でも「独自のフレームワーク（いわゆるオレオレフレームワーク）」なんてダメだと思っている。ある程度実績のあるOSSフレームワーク上に、薄いラッパを噛まして使うか、そのまま使うのがいいだろう。あのフレーワーク設計者は今どうしているのだろう。
もう１つは、コーディング、単体テストの半分くらいを、中国のオフショアとしていたことだ。日本側は詳細設計書を作って中国に送り込み、上がってきたモジュールを結合テストで受け入れる、という流れだったのだが、ちゃんとしたモジュールを上げてもらうためには、コーディングと１：１になるような詳細設計書を作らなければならず、そんなもの作るくらいなら日本側でコーディングした方がマシだったのだ。オフショアが悪いとは思わないけど、やるなら上流側から依頼するか、本当に単純作業を依頼するか（エビデンスのスクリーンショットを取るとか）にするべきだと思う。今は、オフショアを使った開発からは離れてしまったけど、現在でもオフショアってコストメリットあるんですかね？
そんなわけで、終電より初電の時間の方が馴染みがある生活を続けているうちに、私は働きはじめて１年になった。なんやかんやがあって、私は派遣先の会社に転職することとなった。「なんやかんや」の部分をもう少し具体的に書くべきなのだろうけど、余り具体的に書くと特定されかねないのと、まぁ「なんやかんや」としか言いようがない事情があるため、このくらいしか書けない。まぁ、IT業界にいる人なら、わかってくれるんじゃないでしょうか？
特定派遣専門の会社って、業界の問題点であると各所で論じられているが、私にとっては、全くの未経験から業界への道を開いてくれた存在として、意味のないものではなかったと思う。ただ、そういった会社で働く場合でも、最長でも３年にしておいた方がよいだろう。後に、そういった会社で長くやっている人を何人かみてきたけど、正直なところ、一般的な社会人として生きていくのは無理だろうな、と思う人ばかりであった。この辺り、具体例は別の投稿で書いてみたいと思う。
アルパインスタイルシステム開発
ヒマラヤの8000m峰を登る手段は、大きく「極地法」と「アルパインスタイル」の二種類があります。
「極地法」というのは、ベースキャンプから、食料や酸素ボンベといった資材を次のキャンプへ運び上げていき、そのキャンプを頂上に向けて少しづつ設営していくことで登頂を目指す方法です。
資材を大量に持っているので、登頂までのスケジュールに余裕が持たせやすいです。したがって、悪天候時は停滞するという選択肢がとりやすいので、結果として成功率が高いというメリットがあります。
資材の量と、それを運び上げる人員が多く必要になるため、期間とコストがかかってしまうことがデメリットになります。
「アルパインスタイル」というのは、ベースキャンプから最小限の前進キャンプのみを設営して、少ない人数、短い期間で一気に登頂を目指す方法になります。
極地法に比べると、必要な資材や人員が少なくて済むため、期間とコストを削減することができますが、悪天候時に取りうる手段が少ないことと、問題の解決をサポートメンバーに頼ることができないので、登山家自身に高いスキルが求められます。
IT システム開発の見積もりの単位として「人月」というものがあります。文字通り、人数と期間（月）の積の値で、10人で12ヶ月、という場合は、120人月ということになります。1人月100万円なら、1億2千万円ですね。
ITシステム開発の見積もりを取った時、出てきた見積額にびっくりするかもしれませんが、上記のような見積もり方法なので、別にぼったくってるわけじゃないんですね。
ただ、発注側の立場になってみると、例えば1億2千万円かけたものを、5年で回収しようと思ったら、年間2〜3千万円の効果がなきゃいけないわけで、そうなると、そんなの無理、となってしまいます（業種にもよるでしょうが）。
ITシステム開発には金がかかる、でもそんな金はかけられない、というギャップを埋めるためには、内製化するしかないと思っています。また、内製化するにあたり、10人で12ヶ月、なんていう見積もりをしても何もメリットがないので、2人で6ヶ月、という見積もりで実現する必要があります。
10人で12ヶ月かかるものを、2人で6ヶ月でできるのは理屈に合わない、と思うかもしれませんが、人を減らすことによって、コミニュケーションコストを減らすことができます。
ITシステム開発では、各メンバーが同じ目的を共有することが大事ですので、そのためのコミュニケーションを疎かにすることはできません。で、10人メンバーがいるのと、2人しかメンバーがいないのでは、後者の方がコミニュケーションにかかるコストが少ないことは理解できるかと思います。というか「コミュニケーション大切！」と言う割に、そこにかかるコストをわかっていない人マジ多すぎだと思います。
また、内製化のメリットとして、要件定義、基本設計の工程をある程度簡略化できるメリとがあります。請負で開発を行う場合、これらの工程が適当だと、後々揉めることになるので、きっちり時間をかけて行う必要がありますが、内製だと、途中で要件が変わった場合でも、リリース時期の調整も行いやすいので、これらの工程が適当でも帳尻が合わせやすくなります。
すっごいとりとめなくなってしまいましたが、以上は、Sier開発者から、ユーザー企業内製開発者の両方を経験してみて思ったことです。
「同一労働同一賃金」についてよくわからないこと
これ、どうやって実現するんだ？派遣元と派遣先は別法人なんだから、派遣先が派遣元の賃金をコントールなんてできないでしょ。あと、同一労働であっても、会社ごとに賃金は違うんだから、どこに派遣されるかで同じ労働であっても賃金が変わるよね。それって派遣労働者側には納得できるのかな？
俺の考える労働環境の改革案は
- 正社員の解雇をやりやすいようにする
- 失業保険の拡充（金額と期間）
- 転職回数が多いことがマイナスにならないようにすること（履歴書にこれまでの会社名を記入することを禁止してもいいかも）
かな。要するに、雇用の流動化を一層すすめるような方向がいいんじゃないかと思います。愛社精神とかなくなっていく方向になって、これまで日本企業が持っていた良さみたいのは消えていくだろうけど、それがトータルで考えた時にいいのか悪いのかはよくわからないです。
