2023年を振り返って
2023年を振り返って
振り返るって何をすればいいかわからないから、
とりあえず月別に振り返ってみる。
書いちゃいけないこともあるから、内部的に振り返ってみた。
客先業務の話題がほとんどで、プライベートとか会社のこと（SESなので）が何一つなかった。
これは、あまり良くないと思う。
業務に労力を取られすぎていると思う。
ほんとに。
残業してるのに更に残業を要求されるような案件。
ほんと、人の多い案件やシステムリプレースはだめ。もう入りたくないよね。
やりたいことや充実感のあることで時間が使われるのはいいのけど、
時間を切り売りしているだけの労働になってるのがいけないと思う。
来年は、充実した一年にしたい。
それが来年の目標。
ITとは開発か。サービスか。
どうも、bs12です。
むかしの現場に、尊敬できるシニアエンジニアの人がいました。
どちらかというと、インフラチームを率いてましたが、コードレビューもしていました。
その人は、本当に何でも知っていました。
インフラ定例会で、Linuxコマンドの隠しオプションについて嬉々として話していたり、
開発者のコードレビューでは、出来ない開発者にいつもあーだこーだと怒っていたりしました。
CTOの立場だったのか、経営者と怒鳴り合いの喧嘩をしている声が、壁越しにきこえることもありました。
いまでも忘れられないので、ぼくがその人にコードレビューをしていただいたことと、
全体勉強会でぼそっと言った一言です。
コードレビューは、一言で言えば最高でした。
その頃のぼくは、まだ新卒をちょっと抜けたぐらいで、業界のこともわからない木偶の坊でした。
なので、とにかくいろいろな経験がしたいと、当時の会社からの現場異動に、何も考えずに二つ返事をしてしまいました。
開発者のぼくは、運用・インフラのチームに属することになりました。
開発チームは、オフショアやニアショアが多いみたいでした。人は多いです。
運用・インフラチームに配置されても、ぼくの仕事はプログラムを書くことでした。
なぜ、と細かいことを話し出すときりがありません。
とにかくぼくは、運用・インフラチームのプログラマでした。
当時の上司は、運用とDBのスペシャリストでしたが、プログラムは素人に毛が生えたレベルだったと思います。
リプレース作業でした。
「難しい処理をしているから読むのは難しいかもしれない」とソースファイルの書き換えを依頼されますが、汚ソース過ぎて、ぼくにはどうすることも出来ませんでした。
名誉のため、だけではないですが、その人は本当にすごい運用・DBのスペシャリストだったとここに記しておきます。
いまでも、ぼくのDB関連のスキルは、その人に叩き上げられたと言っても過言ではありません。そして、一緒に働く同僚の中では、ぼくが一番DBがわかっている人になっています。
間違いなく、ぼくの運用・DBのスキルを育ててくれたのはその上司で、今でも尊敬しています。
さて、でも、やっぱりその上司はコーディングが出来ないわけです。
だから、ぼくが書いたコードを評価してもらえる機会はそうそうありませんでした。
だから、冒頭で出てきましたシニアエンジニアの方にコードレビューをしてもらえたことは、とても嬉しかったです。
人生初めてのコードレビューでした。およそまともなコードレビューは、いま現在にいたるまで、その人にしてもらったレビュー、一回だけです。
そして、もちろんぼくもいろいろと指摘を受けました。
けれど、その指摘のどれもが目から鱗の驚きで、自分では思いも至らないものばかりでした。
DSL、設定ファイル、例外を実装する深さ、などなど。
難しい本にかいてあるような内容だったのかもしれません。
本を読んだだけではわからない、現場で何十年と仕事をしていく中で培われた知見もあると思います。
そのどれもが新鮮で、驚きに満ちていた、プログラミングの奥深さを間近にして、可能性を感じられて、とても充実したレビューでした。
その当時の現場には、月イチで勉強会というイベントがありました。
開発者が全道に集まり、一つのテーマについて議論する。そんな勉強会でした。
ぼくは、運用・インフラチームの一員だったので、なかなか参加する機会がありませんでした。
あれは、秋が深まる１１月の頃だったかもしれません。１度だけ、その勉強会に参加させていただく機会がありました。
議題は、コードの書き方について、のようなものだった思います。
少なくともぼくは、「実装レイヤーによって書き方は変わるのではないか」という発言をした記憶があります。
低レイヤー層での実装なら、可読性よりも速度重視なので、読みにくいコードが正義とされる。
高レイヤー層では、共同開発者が多いから、パフォーマンスよりも可読性が優先される。
そんな感じの発言をしたと思います。
勉強会の終わりのほうで、そのシニアエンジニアの人が一つの疑問を投げかけました。
「ITとは開発か。サービスか」
そんな問だったと思います。
その時の自分は、なんだかわかりそうでわからない、ほんのりと理解できそうで詳細には理解できない、そんな感情に囚われました。
とても大事なこと。
この疑問をそんなふうに言語野で理解したことはありませんし、大事なことだから覚えておこうとも、衝撃を受けてもいませんでした。
でも、その疑問が頭から離れず、ことあるごとに脳裏をよぎり、ふと手を止めて立ち止まることが何度かありました。
現在の自分は、この問題をよく理解できていると思う。理解というより、見が切れるほどに痛感している。
「IT業界で働くこと。それは「開発」をすることなのか。「サービス」をすることなのか」
こういうことを言いたかったんだと思う。
ぼくは多少なりとも人をまとめる立場になりつつあります。
（管理やマネジメントは絶対に嫌なので、どうにか抗しているところです）
SESで働いていると、その要員は「エンジニア」と「労働力」に大別できると強く感じています。
「労働者」ではありません。「労働力」です。
「労働力」はコンピュータについて知りません。言われたとおりに手を動かすことしか出来ないので、事細かに指示を与える人が居ないと何も出来ません。
そしてマネジャにとって、プロジェクトは人月という「労働力」をものさしとしてしか管理されません。
つまり、深い洞察と膨大な知見で課題を解決する「エンジニア」も、詳細指示がないと何も出来ずに手戻りを繰り返す「労働力」も、同じ「１人月」なのです。
開発で求められることは、プロで専門家であるエンジニアの働きではなく、線表を満たすだけの「労働力」という数字です。
その数字に対して、根拠のよくわからないスケジュールを死守させるために、馬車馬のように働かされるのが、開発です。求められるのはスキルではなく、スケジュールを埋めるための、「労働力」という数字です。
（スキルを求めるのであれば、どうして「面談」だけしか行われないのでしょうか？
非SES業界のように、どうしてコーディング試験がないのでしょうか？）
もう疲れました。
業務経歴書には「Linux経験あり」なのに、どうして終了コードもとれないのか？
C#の経験がありますというのに、どうしてOOPを理解していないのか？
開発の経験がありますというのに、どうして論理和・論理積もわからないのか？
どんなに具体的にわかりやすくレビューをしても、なぜ同じ過ちを繰り返すのか？
どうして業務テーブルの全データをDELETE＆COMMITして笑顔でいられるのか？
クライアント・サーバアーキテクチャも知らずに、どうしてWeb開発現場に入ってこれたのか？
「明日には終わります」という進捗報告が、どうして３ヶ月も続くのだろうか？
もう、つかれました。
現在のSES業界では、エンジニアは必要ありません。
必要なのは数字という「労働力」なのです。
だから、未経験の人でも、働く現場がたくさんあるのです。
スキルは不要、または軽視されているので、面談さえ対策すれば、どんな現場にも入れるのです。
ITで働くということは、「開発をする」ことなのでしょうか。
「サービスをする」ということなのでしょうか。
