許容範囲が狭い・我慢ができない・自分が変わるしかない
前にも書いたようなことをまた書く。自分の思いの丈を書き綴りたいだけなので、誰の意見も求めてないし、君達はコレを何も言わなくていい。何も言うな。
目次
- 現状に不満
- コレ以上負けていたくない
- プログラミングは人一倍我慢ができない
- リーダになる？
- 教育系の業界に回る？
- 起業する？
- 出来ないことを克服は出来ないのかもしれない
- じゃあ何なら変えられるか
- というワケで英語を頑張ります
現状に不満
現案件でまたムカッ腹が立っている。
- 無意味かつ複雑で何の効能ももたらさない ID 採番や命名規則のルールが多い
- 英語が分からないメンバ多数により、関数名や変数名をローマ字表記することになる
- Git の使い方が分からないメンバ多数により
mainブランチが頻繁に壊される - 自動化ツール等の存在を知らず、教えてもなお自分だけが慣れている手作業を貫き品質を落とすメンバ多数
- 工数見積やクリティカルパスの算出ができない PM による、その場しのぎの決断に振り回される毎日
いつもの無能セットだ。またコレかよって感じだ。この会社に転職してからまともな上司やメンバに恵まれたことがない。前職の方がまだ尊敬できる上司がいた。
「またコレ」なんだが、そうだと分かっているのに我慢ができない自分自身にも腹が立つ。もういつものことじゃないか、周りは皆無能なんだ、期待なんかするなよ自分、と思うのだが、やっぱりどうしても自分の思い通りに物事が動いて欲しい。
コレ以上負けていたくない
僕の元来の性格的に、変化に対応する力が弱く、自分の拘りが強く、我を通したがる性格ではあると思う。だが、この性格は後天的に、より強烈なモノになってしまった気がしている。
元配偶者と会話が成立せず、離婚に至り、子供との生活を奪われた。どうにかしたくて我慢してみたり工夫を重ねたりしてみたが、僕にはどうにもできなかった。あの時僕は「負けた」のだ。話の通じない相手が親権を握り、何とかしたいと思っている僕は親権を勝ち取れなかった。泣き寝入り状態だった。
この経験があるので、僕はもうコレ以上自分を我慢したくない、と強く思っている。ワケの分からない存在に自分の領域を侵害されて苦痛を味わいたくはないと強く思っているのだ。極端な言い方、今度は暴力に頼ろうとも、自分の世界を維持したい。
この思いが強くなっている時、僕の頭の中では、「俺こそが正しい、俺と意見が異なる奴は罪人だ、潰してやる、絶対に俺の思い通りに動かしてやる」と思っている。傍から見ればかなり危険なのだと思うが、僕の主観ではこうなってしまっている。
僕の拘りが一層強くなっている原因は、ココにある。
プログラミングは人一倍我慢ができない
要件定義の段階だと、「法的な決まりでこの業務は変えられない」とか「システム部だけでは業務フローを変える権限がない」とかそんなことで、綺麗な設計に落ち着かない場面が多々ある。「予算が足りないのでサーバスペックはコレくらいにして…」「会社が OSS を推奨してないのでこのパッケージを使ってあとはスクラッチ開発してくれ…」とか、そういう制約もよくある。会社ってそうだよな、人間って非効率だよな、と思いながら、まぁまぁ折り合いをつけて要件定義をし、なるべく最適なシステム設計をしようとしている。
だが、コーディングの段階になると、僕は途端に色々なことが我慢できなくなる。関数や変数の命名がデタラメだったり、全角と半角をテキトーに組み合わせていたりするのが全く許せない。一度や二度のケアレスミスならまだしも、英語に意識が向いていないとか、プログラミングの著名な原則を全く理解していないようなコードを見ると頭に血が上ってしまう。コレは何故だろうか。
なんとなく、「設計」までの「計画段階」というのは、色々な都合を加味して設計書を書き起こしているワケで、ある意味計画どおりに物事を進められているし、コレが最終成果物ではないから、くだらないしがらみや制約があってもまだ許容できるのかもしれない。しかし、コーディングは、成果物そのモノを作っているワケだし、そこの品質が落ちることで運用保守工程においてどのような悪影響が起きるか、先が読めているので、そのままの汚らしいモノをリリースすることに凄く抵抗感があるのだ。
- 例えば、包丁職人が、よく切れる包丁を作るとする。
- 今回は量産体制を組まないといけないので、時間的にも、品質面で妥協せざるを得ない部分があるとする。それを考慮して、いかに「なるべく切れる包丁を作るか」を設計したとする。
- しかし、いざ生産が始まってみると、現場担当者がテキトーで、素材に傷が付いたまま製造に回していたり、品質チェックをサボっていたりして、設計したモノより品質の悪い包丁が大量に出来上がるとする。
- そんなモノを世に出してしまったら、「前評判と実物が違う」といってトラブルになり、修理依頼が増えるかもしれない。リコール騒ぎになるかもしれない。そういうリスクを考慮すると、「生産工程」の品質チェックに妥協したくないのである。
コーディングするメンバ達にも事情があるのかもしれない。
- プログラミングの経験年数が短くて、「リーダブルコード」すら読んだことがないのかもしれない。彼らにとっては要求水準が高すぎるのかもしれない
- 英語の成績が単に悪いのではなく、ディスレクシアなどの障害を持っているのかもしれない。彼らにとっては「やりたくてもどうしても上手く出来ないこと」なのかもしれない
- 品質が悪いのは重々承知しているが、それ以外にも捌かないといけない仕事が多すぎて疲弊しているのかもしれない。彼らにとっては「この件は大した問題じゃない」ことにしたいのかもしれない
…ココまで考えてもなお、僕はコードが汚いことに対して我慢ができない。みんな最低限俺と同じくらいは出来ろ、と思ってしまう。俺は俺でどうしてもこの考え方を変えられないでいる。問題点が分かっていて、直すことに大きな時間は掛からないし (予定の工数内で対応できる範囲)、直さない場合の被害の方が高くつくことが説明できる、それでもみすみすその問題を見逃さないといけない、という状況に耐えられないのだ。
リーダになる？
じゃあ、PL になれば、アーキテクトとして携われば、こうした品質問題に対して強制力のある発言ができるのだろうか？アーキテクト担当だったこともあるし、現案件も PL に任命されているが、そう上手くはいかなかった。
この書籍に書いてあるとおり、このウェブサイトに書いてあるとおり、コレをこうして、この通りにしなさい、というルールを精緻に作っても、英語ができない人間は引き続きデタラメに変数名を書くし、分からないことを相談しに来ない奴は分からないことをそのまま誤魔化そうとする。彼らをどれだけマイクロマネジメントしても、ついに変えることはできなかった。出来ない奴はどうしても出来ないし、一生出来るようにはならないのである。
今回もそうである。散々彼らに説明した。「クリーンアーキテクチャ」だの「ドメイン駆動」だの、そんな小難しい話はしていない。
- 関数はたいてい動詞で書くモノだよ
- リストや配列の変数名は複数形、その中の 1 アイテムは単数形で書くと分かりやすいよ
- Controller に処理を書くと変更に弱くなるよ、今回は Service クラスが Fat になる分には許容するからビジネスロジックは Service クラスにやらせようね、コレを単一責務原則っていうよ
registは動詞じゃないよ- ケバブケースとスネークケースとパスカルケースを混在させるような命名はしないでね、具体的な決まりはこの公式サイトに書いてあるとおり、こうこうこういう命名規則があって Linter でも注意されるよ
この程度だ。この程度のことだ。
- 命名がちゃんとしていないとバグを生むよ
- ビジネスロジックを分離しておかないとテストやバグ修正が難しくなるよ
- 僕が携わった過去案件のデータを見せると、変数名起因のバグがコレだけあり、関心の分離ができていないことによるバグはコレだけ本番障害に繋がったことがあるよ
コレを毎回どの案件でも説明しているが、他人が変わってくれたことはない。ウチの会社の人みんなバカなんだと思う。少なくとも今の会社では、俺自身の観測範囲の物事を正すことは不可能だと思う。
教育系の業界に回る？
案件の中でこうした指導をしても意味がないなら、例えば新人教育担当だとか、IT 教育系の仕事に転職するのはどうだろうか。
教育系の仕事に就くのはやぶさかではないというか、可能性はゼロじゃないと思っているが、自分の本質は「最初から良いコードをスムーズに書きたい」のであって、「出来ない人を出来るようにしてあげたい」ワケではないと思う。
馬鹿げた現場から遠ざかれるという意味ではストレスが減ってアリなのかもしれないが、コレだけやってきて他人を分からせることが出来なかったことを思うと、僕に教育は向いていないんじゃないかと思っている。別のストレスが生まれそうだ。
起業する？
自分が社長になって、望みの人材だけを雇って少数精鋭で仕事をできれば、マイクロマネジメントも上手く行くかもしれない。というかそういう教育すら要らない優秀な人材と働ければ良いのかもしれない。
…んーと、起業するだけの資金は？起業して人を呼び込むだけの僕のセールスポイントは？…高望みしすぎた。
出来ないことを克服は出来ないのかもしれない
さて、「いつまでも英語が出来ない奴」「いつまでもコードを綺麗に書けない奴」がいて、「いつまでもそいつらのことを我慢できないでいる自分」がいる。
ココまで書いてきて自分でもよくよく分かっているけど、出来ないことを出来るようになるのって、物凄く難しいことなのだと思う。
僕は我慢ができない。人一倍我慢ができない。コレはどうやら直せないみたいである。我慢強くはなれない。「問題があっても無視する能力」が、ついぞ養われなかった。10年間この仕事をやってきてコレが変わらないならもう変わらないんだろう。
じゃあ何なら変えられるか
短所を克服するのではなく、長所を伸ばすという考え方を取ってみようか。
要件定義や設計工程は、割と苦ではない。それだけをやる仕事に回っても、続けられそうではある。
ということは、PL としてプロジェクト内のリードをしていくとか、アーキテクトとしてプロジェクト内での設計を浸透させるとか、そういう段階をさらに飛ばして、PMO や PM になるとか、さらに上の管理職になるという道が考えられる。
要は、コーディングの工程から身を引くのだ。「コーディングなど全体の内の些細な問題」という立場に自分の身を置くことで、コーディング品質にイライラしてしまう視点から逃げるのだ。PMO なら「支援」として横槍を入れるだけでいいし、PM なら「じゃあそういうことで、PL うまく回してね」で良いワケだ。
営業は厳しいと思うが、コンサル的な立ち位置はアリかもしれない。結局、コードが汚いことから逃げられれば良いワケで、「人って上手く動かせねえよな」と分かっている職なら、何か諦めが付いてそれなりにやれそうな気もする。
もう一つは、自分のコーディング力をさらに伸ばすのはどうか、ということを考えた。
「アイツ英語が出来ないよな」と文句を垂れながら、自分自身は英検3級しか持っていない。「アイツコード書けないよな」と愚痴りながら、自分自身は Java・HTML5・LPIC くらいの資格しか持っていない。あとは会社で取れと言われた OCI・GCP・AWS の資格を持っていたりするが、コレはインフラ寄り。
例えば、TOEIC が700点・800点取れてますとか、Java・Ruby のゴールド持ってますとか、そういう「明らかにスペシャリスト」な資格を所有して自己アピールできたらどうだろうか。
結局のところ、今の自分は「平均的な他人よりもわずかにチョットデキル」程度でしかなく、それは元来の神経質な性格ゆえに他人よりもちょっと気が付きやすいというレベルに過ぎないのだと思う。
だから、この能力をもっと伸ばして、具体的な資格でもって自分の武器を磨き上げていけば、参画できる案件のレベルが上がって、より優秀な人材と一緒に働けるのではと思った。
特に英語での線引きは、簡単には超えられなさそうな壁だし、自分の成績がもし頭打ちになったらそこで諦めがつく気もする。ちょうど今の会社の情勢的に英語が求められるようになりつつあるので、コレは良い機会かもしれない。
というワケで英語を頑張ります
凄く嫌な言い方をすると、「自分はもっと優秀なはずだ」と思っているからこそ、コーディングに対して文句が出るのだと思うので、だったらそれを証明してみろよ、という自分自身への挑戦として、勉強に打ち込んでみようと思う。
具体的には、今年度・2024年度中に TOEIC を受ける。大学入った時に受けて以来なので今現在が何点レベルなのか分からないが、英検3級保有ということで400点前後だと推測する。そこで、目標としてはまず600点台を目指す。自分にそこそこの英語力が確かにあることを、資格でもって証明してみせる。
そして、英語が求められる程度の案件に参画できるようになる。きっとそれは、ある程度の難易度が問われる案件であり、集まる人のスキルも高いだろうと予想してのことである。そこでの自分の立場は何でも構わないが、出来ればプログラマからアーキテクト寄りの立場で、コードの品質に口出しできる、裁量のある人間になりたい。やっぱり僕は、コードを綺麗に書き上げたい。
コードを綺麗に書ければ気が済むので、2・3人で回す少数精鋭な案件でも良いかもしれない。そうすればほとんど俺一人で思う存分コードが書けるワケだし。
で、じゃあ何の言語でコード書けますかと問われた時に、具体的な資格を保有しているプログラミング言語というのが少ない・もしくは取得していても初級中級レベルのモノで終わっていたりするので (会社で取れと言われたモノしか取ってきてないため)、Java で言うならゴールドのように、その資格の最上級のモノを一つは取りたい。明らかに出来る人だと証明したい。残念ながら僕が一番書ける JavaScript に関しては著名な資格があまりないのだが、会社から報奨金が出る出ないに関わらず、実力を確かに示せる資格というモノを取ってみせようと思う。
最初に挙げた「英語力」が、一つの大きなテーマだ。英語力によって、最低水準が底上げされた案件に参画できないかと画策しているワケだ。コレがもし上手く行かなかったら、特定のプログラミング言語やクラウドベンダのスペシャリスト資格を取得することで、自分のポジションを変えられないか作戦を練り直してみる。
周りが変わらないなら自分が変わるしかない。自分の変えられないところがどうしても変えられないなら、変えられそうなところを変えるしかない。生意気なことを言うなら、それ相応の実力を示してみせろ、俺、と。
今まで「会社は参考書の経費を出してくれない」とか「資格に合格しても報奨金をくれない」とか、小さなことで文句を言ってあまり資格試験に向き合ってこなかった方なのだが、書籍なんてたかが数千円だし、試験に合格すれば受験費用は経費で落ちる。最近はようやく報奨金が出る資格も出来てきたし、そうでなくても自分が求めてるのはそんな小銭の話ではなく「より水準の高いランクで働けること」なワケで、その要求を会社に飲ませるためにも、資格という分かりやすい指標でもって自分のスキルを見せつけてやるしかない。
特に TOEIC は最近会社が受験を推奨し始めたこともあり、だったら流れに乗って英語力を見せつけてやろう、と。自分自身としても、定量的に自分のランク・スキルレベルが数値化できれば、不相応な高望みはしなくなると思う。
あまりにも英語力がなくて打ちひしがれるかもしれないが、それはそれで諦めがつくかもしれないのでアリ。諦めがつくことで、現状のままでも我慢している感覚がなくなり、ストレスを感じなくなって平和に暮らせるようになったりしてくれたら、それでもいい。コードを綺麗に書きたいのは山々だけど、それよりも何よりも、仕事ごときでイライラしたくない。イライラしないで過ごせるようになるのであれば、どんな変化でも起こして行こうと思う。
