IQ49

IQ49の日常

システムエンジニアの日常4

メンター「Aさんは凄いからな、社外で発表したり、勉強会を主催したりとエンジニア界隈では一目置かれてるんだ!Aさんみたいなエンジニアを目指せよ!」

新人「はい!!!」

Aさん「この会社クソなんでやめます。」

新人「…」

~一年後~

メンター「Bさんみたいなエンジニアを目指せ!」

新人「はい!!!」

Bさん「やめます」

新人「…」

ジェネラリストを作ろうとして全体の効率を落とす人たち

部の方針でジェネラリスト育成をされている。俺が、というか部員全員が。 育成というか仕事押し付けられてるだけでフォローは皆無。 そして慣れない仕事で成果を出せず文句を言われるという事態。 もうねいいかげんにしろと、俺がビジネス周りのことやって誰が得するんだよ。

原因は部内で残業時間に差があるから、残業時間の多い人の仕事を少ない人に押し付けたいんだと。 そのためには、部の全員が全種類の仕事ができる必要があるよねと。 "俺が苦しんでるんだからお前も苦しめ"の精神に端を発して適当な指示出してんじゃねえぞと。 そしてジェネラリストなんだからと全員が残業前提のスケジュール組むとか人としておかしいだろ。

手の空いてそうな人がいるから、他の仕事をやらせて時間を有効活用しようなんていうのは、ペットボトルのジュースを飲み干した後に、まだ少し残ってるからと必死に残り滓をかき集めるようなせこい真似でしかない。もっと他の解決方法があるし、手が空いたのなら休んでもらってればいいだろ。なんで残業時間が少ない人を目の敵にするんだ。

そもそも全体の効率が落ちるのが良くない。慣れない仕事をすると仕事の効率は下がります。当たり前だろにんげんだもの。 野球でいうとキャッチャーが足りていない状態で、「選手には全てのポジションを憶えさせるのが良いよね」と言っているようなもの。 できることを増やすのに取られる時間と、たとえそれができてもすでに他の経験者がやった方が効率が良い場合もある。安易にできることを増やしても活用できるとは限らない。 最も多く取り組む課題に対する能力を上げる方が効率が良いことは明白だろう。

無駄なプロセス実施とか、糞コードの量産とか過去の炎上要因が腐るほどあるのになぜそこから目を背けるのかが意味不明。

声に出して読みたいIT企業

子の曰わく、今のシステムエンジニアは明日から夜まで能く事うるを謂う。
犬馬に至るまで皆な能く事うること有り、
敬せずんば何を以て別たん。

・先生は言われた、「近頃のシステムエンジニアというのは朝から夜までよく仕事をすることをいう。犬や馬まででもよく仕事をする。尊敬するのでなければどこに区別があるのだろうか。」

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つはプログラマの腕がヘボくて共通化できないのに共通化してしまっている場合、もう一つは業務設計内に同じ意味を持った処理が分散している場合である。 どちらもシステム開発における敗北を意味する。本来は業務特有の処理というのは共通化する必要はなく、それ自体が独自性を持つものである。 業務固有箇所で共通化が発生することは問題視されなければいけない。