35歳目前にしてフロントエンドプログラマーが意識していること

ぼちぼち 35 歳が見えてきまして。

バツイチ独身子なし彼女なしと、なかなかどーしようもない感じになってきましたが、相変わらずフロントエンドプログラマーとして働いています。

いつのまにかエンジニアとしてのキャリアも干支が一周し、フロントエンドプログラマー歴も 7 年目と、まごうことなきおっさんになってきました。

これくらいの年齢になってくるといつのまにか同年代のプログラマーも徐々に減ってきて、自分がベンチャー企業好きということもあり、どこの職場に行っても最年長みたいなケースもかなり増えてきました。

そんなシニアエンジニアな自分ですが、まだまだエンジニアとしてのキャリアを積んでいきたい気持ちはありまして。

とはいえ需要がなければエンジニアとしてのキャリアを伸ばすことなんて到底できません。

ということで今回は、今後も需要があるエンジニアであり続けるために、仕事中に意識していることを書いていこうと思います。

• 2M1S
• 歳を重ねれば重ねるほど、立場が上がれば上がるほど腰を低く
• 常に Google でも通用するように
• 常に誰かのモチベーターたれ
• 成功するか否かは準備段階で 8 割決まる
• Yes &
• 型を大切にする
• 例外を許容しない
• スコープを小さく保つ

2M1S

何度かブログに書いてきた 2M1S ですが、未だにこの考え方は変わっていません。

• MAJOR
• MODERN
• SIMPLE

上記の頭文字を取って名付けたんですが、なんだかんだで大事だなーと。

とくに大事なのは SIMPLE だと思っていまして、物事をシンプルに考えることができる人が意外と少ない印象です。

日本製の SaaS なんかに多いんですが、とかくごちゃごちゃし過ぎているケースって少なくないよなと。

ユーザーが求めているのは最低限の機能であって、取捨選択を行いたいわけではないことを強く意識することが大事かなと。

歳を重ねれば重ねるほど、立場が上がれば上がるほど腰を低く

歳を重ねるほどに態度が偉そうになっていくヒトはアホです、ごまんといますが全員アホです。

そもそもヒトを年齢や性別、国籍などで判断すること自体非常にナンセンスなわけで、こんなことは言うまでもありません。

一方で日本は非常に年功序列の姿勢が強い国なので、歳を重ねると大したことないヒトでも簡単に調子に乗りやすくなってしまいます。

自分以外のヒトは自分が持っていない知識や経験していないことを持っているわけで、それだけで尊敬に値します。

ましてや上の人間が偉そうな態度を取れば取るほど周りはイエスマンばかりになってしまうわけで、まさに裸の王様、得られるものを減らしてどーすんねんって感じです。

自分もシニアエンジニア、ヒトから指摘される機会もだいぶ減ってきた感があり、改めて自信の身の振り方を考えないとなーと日々考えさせられています。

常に Google でも通用するように

ベンチャー企業で働いていると感じることの一つに、ベンチャー企業でしか通用しない働き方をするヒトが結構いるなと。

例えば出勤が曖昧だったり、開発フローがテキトーだったり、コミュニケーションが雑だったり、コーディングが汚かったり。

とはいえ普通に考えて、その現場でしか通用しない働き方をして何がしたいんだお前は？と思ってしまいます。

そういう甘い考え方を持っていると、海外の大手 Tech で働いているヒトとみるみる差をつけられてしまいます。

自分は日本の大企業で働いてきた経験もあり、コミュニケーション一つ取っても慎重に行うことが大事だよなと。

コーディングも然りで、大企業のコーディングは本当に丁寧に行われるので、その姿勢を忘れてはいけないよなと。

常に誰かのモチベーターたれ

スクラムなどを取り入れるとよく感じるのですが、スクラムチームのメンバーは仲間であって、ステークホルダーを含めたメンバーも仲間であり、会社のメンバーは全員仲間です。

仲間と働く以上は、やっぱり気分良く働きたい、当然のことですよね。

パワハラやセクハラなんてもってのほかですし、コミュニケーションを通してみんなモチベーション高く働くべきだよなと。

成功するか否かは準備段階で 8 割決まる

日本の開発において、開発前の準備段階のフェーズをなめすぎです。

ここが曖昧な状態で進めるとあとでボロッボロ問題が出てくるわけで、徒競走前に準備運動をしないバカはいませんよね？

開発を進めていくにあたって決めるべきこと、導入すべきモノ、フローなどはしっかりと決めましょう。

スクラム的な話でいうとインセプションデッキからユーザーストーリーマッピング、開発的な話でいうとパッケージのアップデートや Linter、Formatter などなど、決めなければいけないことは鬼のようにあります。

『あとで良いや』という考え方はいますぐに捨て、曖昧なことはしっかりと調べて明確にしてからプロジェクトを開始するようにしましょう。

Yes &

これも以前ブログで取り上げましたね。

日本になくて、シリコンバレーにある「Yes And」のマインド

Yes & が大切だと口にする割に実践できていないヒトもいて、心のなかで『いやいやいや』とついツッコんでしまいます。

型を大切にする

TypeScript の話ではないです、いや TypeScript も大事ではあるんですが。

物事を進めるにおいて、型に一定当てはめるということは非常に大切です。

たとえば自分がフロントエンド開発をするのであれば、Next.js で環境を作って npm の設定を入れて Linter と Formatter を設定して renovate 設定して…と、最初にすべきことはほぼパターン化されています。

他にもスクラムはまさに型そのものですし、Deploy やリリースフローなんかももうほぼデファクトスタンダードが存在しているはずです。

型に当てはまることを避けて、独自性を出そうとする会社や個人が多いことは個人的にかなり疑問があって、そこに時間をかけてオリジナリティを出そうとする意味がわからないというかなんというか。

一方で、同じ型を使い続けるのもこれはこれで問題です。

型は常にアップデートをかけていくことも大切なわけで、結果的にケースバイケースになる、というのが良いフローなのではないかなと思っています。

頑固になりすぎず、かといって変に柔軟性を持たず、無難かつシンプルに、それでも最新を取り入れる、やはり 2M1S の姿勢が大事なのかなーと。

例外を許容しない

これは個人というよりはチームや組織レベルの話なのですが、日本は例外を許容する文化が少し強すぎる気がしています。

◯◯さんだけ特別扱いしたり、このケースだけ例外として扱うみたいなことって意外と目にするのですが、個人的には例外はよほどでない限り許容すべきではないと思います。

例外を許容することによって例外を許容することが当たり前になり、結果的に考慮すべきポイントが増えるのは愚の骨頂です、シンプルじゃないですよね。

少し漠然として書きっぷりになってしまいましたが、何にせよこれもパターンに落とし込み、型にはめることが大切なのかなと。

スコープを小さく保つ

コロナ下のリモートワークなどが代表例なのですが、未だに会社全体でリモートワークを許容するだのしないだの定めているケースってめちゃくちゃ多いですよね。

で、これってめちゃくちゃ非効率的だと思っていて、個人的にはリモートワークで働けるヒトはリモートワークをすれば良いし、働けないヒトは出社すれば良いじゃないかと。

それを会社単位でルールとして定めるのってすげーダサいことだと思っていて、もっと小さいスコープで、例えば部署やプロジェクト、チーム単位で管理せーよと思います。

ルールの適用範囲（スコープ）が広い場合、そのルールが守られているかの確認が非常に困難になります。

ただ勘違いしてほしくないのは、ルールの適用範囲が広いことが問題なのではなくて、管理側が管理を行う意識を持てていないことが問題なのかなと。

従ってルールの適用範囲を狭めることで、ルールが遵守されやすくなり、管理も比較的容易になるのでは？というのが個人的な意見です。

ただ一方、管理する側の人材がイマイチ育っていないというのも結構デカい問題だよなーと思いつつ、残念ながらここらへんはおそらく改善されることはない気がします。

と、つらつらと書いてきました。

なるべく抜粋したつもりですが、意外と書きたいことが多くて自分でもびっくりな今日このごろです。