Java神話
2017年にもなるというのに、自社製フレームワークをJavaで開発しやがって何考えてるんだと思ったら「Javaが一番メジャーでみんな嬉しいよね」とのことです。 もういいかげんにしろと、俺はJavaでプログラミングしても他の言語ほど楽しくないんだよ。
Javaは00年台は強かった。なんでもできて、Javaが使えれば職にあぶれることはないと言われていた。しかし時代は変わるんだ。Javaだけしか使えないプログラマはもう必要ないんだ。
Javaへの依存心は、かつての土地神話と言われていた状況と似ている。バブル時代には土地の価格が下がらないことを前提とした貸付が頻繁に行われていた。土地の値段は上がり続け絶対に下がらないものだと銀行は思っていた。もちろんバブル崩壊でそんな期待はあっさりと裏切られるわけだが。 Javaだけを使ってる奴らは"俺らは最もスタンダードな言語で王道を征く"とでも勘違いしてるんじゃないかというような節がある。そしてJavaの価値が永遠であると勘違いし他の言語を悪いものと決めつけているんじゃないだろうか。Javaが主流じゃなくなる時代はくる。まあ職にあぶれる心配はなくて、そのときは(例えば)Kotlin上でJavaみたいなコードが書かれるだけだが。
Java教徒の根深い問題はJavaに関係ないところでもその力を発揮するところにある。Javaベースの古臭い知識で邪魔をしてくるのだ。 なんというか冗長で読みにくいコードを書く。冗長でないにしても、継承が必要ないのに継承を多用したり、メソッドの定義になんでもかんでもインタフェースを用いたりと好き勝手する。 彼らに言わせるとオブジェクト思考がわからないとインタフェースの良さはわからないらしい。 俺は"オブジェクト指向"といものがなんなのかさっぱりわからないので普段から「オブジェクト指向って難しいですよね、さっぱりわかんないです」と正直に告白している。
Java8とかでJava9でそこそこモダンになるじゃないかという意見もあると思うが、不思議なことにJavaしか使えないプログラマの多くStreamAPIを理解できていない。他の言語も理解しているものは使いこなしている。
ただこのJava神話を利用してプロジェクトを成功に導く方法がある。Java以外の言語でプロジェクトを計画するのだ。今だとKotlinとかScalaが候補に挙がるだろう。 Javaで募集すると能力が低くて、やる気がなくて、上から目線のものがやってくる。Kotlinで募集すると少なくともやる気があるものが集まる。 Javaしか使えない無能を他のプロジェクトに押し付けて、自らのプロジェクト守護れるのだ。
システムエンジニアの日常3
僕「プログラムできました」
上級SE「わかりました、詳細設計書はどこにおいてありますか？」
僕「要件定義書で内容が充分だったのでとくに作ってないですね」
上級SE「でもプログラムはあるんでしょ、詳細設計書はどこ？」
僕「ないですね」
上級SE「だから詳細設計書はどこですか、あるんでしょ？」
僕「ないですね」
上級SE「詳細設計書がないとプログラムが作れるわけねえだろうがッ！」
上級SE「なんで嘘つくの、理由は？」
僕「詳細設計書はありまあす」(なにいってんだこいつ)
上級SE「最初からそういえよッ！」
システムエンジニアの日常2
社長「顧客からスピード感が足りないとお叱りが来ています(憤怒)。みんなで頑張りましょう」
～保守案件発生～
プロマネ「改修計画作成！要件定義作成！見積作成！スケジュール作成！」
プロマネ「要件定義レビュー実施！見積もり会議実施！リスケ！」
プロマネ「詳細設計書作成！詳細設計書レビュー実施！リスケ！」
プロマネ「リスクとなる要素を全て洗い出す！開発はそれまでストップ！リスケ！」
僕「プログラム修正（1行）！」
プロマネ「テスト設計書作成！テスト設計書レビュー！テスト実施！リスケ！」
プロマネ「納品資源確認実施！承認実施！納品！」
プロマネ「開発スピードがおそすぎる！！！！」
僕（なんでこの人プログラム1行修正するだけの作業に3日もかけてるんだろう…）
1LDKのマンションにトイレが4つあるようなシステム
業務設計者がどういったわけだか知らないが、その場しのぎで考えたような要件定義を作成することがある。 その歪さがどんな感じなのかといったら"1LDKのマンションにトイレが4つあるような"感覚である。 常識的に考えて、トイレは1つで充分である。 なぜそのようなことが起こるかというと、業務設計者がトイレとキッチンを区別することができていないので起きる。 業務に関する手続きの最小単位を見極められず、「キッチンがあったらついでにトイレもあるよね」という考えで要件定義を作成するのであろう。 そして当然のように他の部屋にもトイレを付ける。
まともでない要件がシステム開発に降りてくると、複雑なクラス設計になりプロジェクトに悪影響を与える。 共通化を使わざるを得ない状況が増えるのだ。 無理がない要件は、プログラミングの際に共通化を使う機会が減り、よりシンプルな設計に落ち着く気がしている。
業務固有の実装箇所で共通化が発生する場合というのは2つ考えられる。 1つはプログラマの腕がヘボくて共通化できないのに共通化してしまっている場合、もう一つは業務設計内に同じ意味を持った処理が分散している場合である。 どちらもシステム開発における敗北を意味する。本来は業務特有の処理というのは共通化する必要はなく、それ自体が独自性を持つものである。 業務固有箇所で共通化が発生することは問題視されなければいけない。
古く効率の悪い方法でプログラミングする人
馴染みのない効率100のやり方と、過去に苦労しておぼえた効率10のやり方があるとして、前者の方を選ばない人はいないだろう。単純に効率に10倍のひらきがあるから。
しかし現実には、何時までたっても古いやり方しかできない人がいる。新しいことを実践しようとせず過去に培ったスキルセットが未だに通用すると信じ込んでいる。実際にはそんなことないのに。 挙句の果てには、こちらが新しい方法を提案しても、「余計なお世話だ、俺には今までうまくいってきたやり方があるんだよ。」と受け入れようとしない。
ようするにその人は、自分が今まで時間をかけて手に入れた物が不要になってしまうことが惜しいのだ。本当に優先すべきは効率であるべきなのに。 ネトゲでアップデートがあって、効率のいい狩場が移動したにも関わらず、以前と同じ狩場でレベル上げを続けるような行為だ。 目的に合わせて最善の手段を選ぶという行為は当たり前に行われなければならない。
たとえ過去にお金や時間をかけて学んだものでも、必要ないとわかった場合は切り捨てなければならない。これには苦痛を伴う場合がある。といっても人間すぐ忘れるので2日もあれば特に何も思わなくなるだろう。 プログラミングで言うと、初心者時代に作ったお手製ライブラリなんて、よく調べたら同じような機能をもつ高性能なライブラリが見つかったりするだろう。 当然さっさと乗り換えるべきである。
技術力の乏しいものが作成したフレームワーク（OSSではなく、自社製のボロいやつ）が誕生することがある。 インタフェースがボロボロで使い勝手も悪い。 やっかいなのは問題が個人の範疇でなく、集団に関わってくるということだ。
自社製フレームワークを作成した費用を回収するために、むりやり自社製フレームワークを使おうとする。 これはシステム開発にとって弊害しかもたらさない。資金投入したのに開発効率が悪くなり開発者のストレスもたまるようになるとは意味がわからない行為である。 本当ならクソなフレームワークはかけた費用、時間に関わらず即刻捨て去るべきなのだ。
技術に暗いものにフレームワークを作らせてはならない。
社員全員が裁量労働制のSIerはもれなくブラック
裁量労働制って何？
労働者の実際の労働時間によらず、あらかじめ決められた賃金が支払われる労働形態のこと。例えば、「労働者の月給は基本給に加えみなし残業時間40時間分を付与したものにする」となっていた場合、労働者は100時間働いても200時間働いてももらえる給与は同額となる。 詳しくは下記リンクを参考に
https://ja.wikipedia.org/wiki/%E8%A3%81%E9%87%8F%E5%8A%B4%E5%83%8D%E5%88%B6 https://ja.wikipedia.org/wiki/%E3%81%BF%E3%81%AA%E3%81%97%E5%8A%B4%E5%83%8D%E6%99%82%E9%96%93%E5%88%B6
企業が裁量労働制を採用する建前
- 個人の力量次第で自由な働き方を可能とする。優秀な人は早く帰れる。
- 残業代目当てでカラ残業する人を減らせる。全体の残業時間短縮につながる。
裁量労働制の現実
- 優秀な人しかこなせない仕事があるので優秀な人は帰れない。
- 残業してるのに残業代でなくてやる気が落ちる。
SIerでは個人の裁量が仕事量を左右しない
経営者が「一人一人の生産性を向上させて定時どおり帰れるようにしましょう」と言うことがある。はっきり言ってそれは大嘘だ信じてはいけない。残業が発生するのは、時間内に処理できる量を越えた仕事が割り当てられているからだ。新人でも仕事量が少なければ定時内に帰れるし、たとえベテランでも大量の仕事があれば定時内には帰れない。残業を個人の能力による問題と言うのは、マネジメント能力のないことの責任転嫁に過ぎない。
事量を決定するような裁量は一部の社員にしか存在しない。なぜならSIerは受注開発で、マネージャーと開発者が全体の作業量を決定できず、仕事量が営業の取ってきた仕事量と直結する。残業が発生する最大の原因は営業が自社のリソースを上回る量の仕事を取ってきていることである。開発者が自分の作業速度に合わせて仕事量を調整しようとしても営業が仕事を取ってきた段階で納期、作業量が決定してしまっており、裁量の発揮しようがないのだ。
ブラック企業の方針
ブラック企業が裁量労働制を採用する理由は簡単である。残業代を節約できるからだ。平均残業時間が100時間ほどあるような企業でも、裁量労働制みなし残業40時間とすれば月にして60時間もの残業代を節約できる。 もっとも、みなし残業時間を超えた分は払うのが法律で定められているのだが、ブラック企業では当然のように支払わられないのはなんでなんでしょうね。
問題点は残業代節約だけにとどまらない。プロジェクトの計画が残業してもコストが0なことを前提に進むのだ。例えばちょっとプロジェクトが遅れたとしよう。埋め合わせに2時間残業したとすれば、通常のプロジェクトなら2時間分のコストが発生する。そして、このようなマネジメントの崩壊により、裁量労働制を導入する前よりも労働時間が増える場合があるのだ。
全員が裁量労働制というのもおかしな点である。まっとうな会社なら下っ端に裁量労働制を適用しているわけがない。裁量労働制がふさわしいのはマネージャーやマーケティング担当といった自分で自分の仕事量を調整できるものだけだ。
どのような裁量労働制ならよいのか？
一定の成果を出せばそれ以上は仕事をしなくてよいという権限が開発者に必要である。しかしブラック企業の現状は成果を出してもそれをマネージャーは把握できずに、一定の時間になるまで働かせようとする。これはマネージャーが部下の成果を把握する技能が低いことが原因である。成果を把握できないで作業時間しか見れないというのはお粗末すぎやしないだろうか。
最後に
求人欄に裁量労働制と書いてあるところには気をつけよう。
サンタクロースは子供の夢
「サンタクロースが実在しないことを子供に教える」という行為は一般に禁忌とされている。禁忌を犯そうものなら人権すらも侵害される勢いでけなされる。「せっかくの子供の夢を奪うんじゃない」と。 挙句の果てには”嘘にもいい嘘がある”といい、”サンタクロースは存在する”というのはいい嘘だよね、と言ってしまう。
しかし、何でサンタクロースがいないという意見を表明するだけで叩かれねばならんのだと疑問に思った。 だって子供からしたらサンタクロースが実際にいようがいまいがなんの影響もないし、そもそもサンタクロースという概念が何なのかをあまり理解できていないだろう。 ”サンタクロースが実在すると子供に主張する大人”は子供のためではなく”美しい子供の思い出を守護る自分”に酔ってるだけなんじゃないかと。
そもそも子供を騙している行為であり、誠実でない。 大人を騙すの悪徳だが、子供を騙すのは許されるのだろうか？
根拠のないデタラメを吹き込まれた子供は混乱し大人の言うことを信じられなくなる。 「詐欺師を信じると不幸な目に遭う」という教訓を得意気に語る一方で「サンタクロースはいるよ」と語るのは矛盾してる。 子供は何を信じたらいいかわからない。
クリスマスプレゼントをもらえない子供もいる。 私もクリスマスプレゼントは特に何もなかったので、サンタクロースがいたら何なの？と思っていた一人である。 枕元にプレゼントなんてないわ。 プレゼントをもらえない子供が自らをみじめに思い絶望するではないか。
