なぜ遅刻をしてはいけないの？ちゃんと考える（IT業界）

遅刻すると怒られたり怒られなかったりします。
IT業界では結構怒られないこともあります。
何故だろうと考えると、遅刻してはいけない理由が複数あるからだと思い至りました。

１．ルールだから（よくあるやつ）

規律、規則、契約みたいなやつです。
IT業界ではこういうのは合理性の前では弱いですね。
「やることやってんだから遅れてもいいだろ」って人も居ますね。

２．労働時間が減るから

毎日２時間遅れて定時で帰ったら、160時間のところ120時間しか働いていないことになります。
そんな人いる？？と思うかもしれませんが、IT業界には居ます。

これはプロジェクトの納期に影響が出るので大変です。

あとは、朝しかやっていない作業などがあると、もっと影響が大きいですよね。

３．退社時間が遅くなるから

会社が24時間営業になってしまいます。

４．他の人の待ちが発生するから

例えばAさんが作業をしないとBさんとCさんとDさんが動けない、みたいなケースでは、1人の1時間の遅刻が大きな損失になります。
そしてプロジェクトの納期に影響が出ます。

５．ミーティングが始められない、ミーティング可能時間が減る

ルーズな人が複数人居るようなプロジェクトでは、大体ミーティングに誰かが居ないみたいな歯抜けで開始します。
これは情報伝達に問題が発生します。
遅刻は怒られないけどミーティングに遅れると怒られることとかありますよね。

対策して遅刻しよう！

合理的に対策すれば遅刻できるのでは？

１．ルールを変える

つまり裁量労働制です。

２．労働時間をきちんと確保する

２時間遅れたら２時間遅くまで仕事すればいいですね（裁量労働制？）

もし退社時間を揃えたいなら、ちゃんと朝来ましょう。

３．退社時間が遅くなる

→　対応不可？リモートワーク？

４．前日に準備して、他の人の待ちを産まない

不可抗力で遅れることもありますから、できれば前日に用意しておきたいですね。

５．ミーティングは遅刻しない

これはしょうがない。

サービス・事業・活動の考え方まとめ：誰をどこまでアップデートするか

メモです。

サービスや事業を考える時に「どういう人をどういう状態まで改善するのか」という観点があると思いますがここについてまとめている情報を見たことが有りません。
ちょっと何言ってるかわからないですね。具体的に書いていきます。

１．「困ってる人を助ける」というモチベーション

援助、介助

恵まれない人を、通常状態にするというモチベーション。
「恵まれない人に救いの手を」というやつです。非常にわかりやすいです。

救助

助けを求めている人を助けるというモチベーションです。

互助を促す

コミュニティを作って互助を促そうというモチベーションです。

２．「誰かの助けにある機能の１つを提供する」というモチベーション

これは「誰をどこまで」ではなくなります。
ドメインを絞らないので安定性があります。

３．「マスに対する改善」というモチベーション

これが一番多いのではないでしょうか。
特に日本は一億総中流などと言われていたこともありほとんどこれでしょうね。

４．「成功者・専門家に対して新しい価値を提供する」というモチベーション

こういうのは都内・都市部に多いです。
インフルエンサーに好まれるような新しい何か、と言えばイメージつくでしょうか。売上を求めるならどうしても３のマスにアプローチしていかなければなりませんが、そうではなく、ひたすらより良いものを追求するという観点ではこちらになります。

５．「新しい価値・考え方の提供」というモチベーション

これまでとは新機軸の革新的な価値を提供しようという考え方です。

アイディアを考えても大抵１〜５のどれかに偏る

世の中を見てみるとわかりやすいですが、大体どれかに偏っていますし、同じような考えの人が固まっています。
ゼロベースで色んなアイディアを考えているようでいて、やっぱり価値観が固定されていることが多いです。

私はずっと５のタイプでした。ということに最近自覚できたと思います。
どうしてもそれ以外に目を向けられませんでした。何故かと言えば・・・ちょっと毒吐きになるので書きませんが。
少し反省して、今後目を向けるのも有りじゃないかと思っています。
中々同じ業界にばかり居ると１〜５のどれかに捕らわれてしまうので、よりフラットになるように色んな価値観に触れるべきですね。

ITスタートアップ/ベンチャー企業に就職したい人向け！調達から会社の状況を推測する

一般的に就職するときには、その会社を不変のものと捉えることが多いのではないかと思います。
特に大企業であれば、入った時と10年後でそこまで大きな変化は無いのかもしれません。
しかしスタートアップやベンチャーは非常に早いスピードで変化が生じます。わずか1,2年で別物になり取り組む課題や組織が変わっていきます。
なのでそこに就職したり参画する場合は「今どういう状態か」「近い将来どうなっていくか」を予測する必要があります。会社の成功に賭けるようなものです。

とは言え、外から見てるだけで会社がどうなるかなんてわからなさそうですよね。
そこで重要になるのが資金調達です。
上場や会社売却を考えているようなスタートアップ・ベンチャー企業は似た課題にぶつかり、似たように資金調達をして乗り越えていきます。裏を返せば資金調達から会社の状況がある程度推測できるわけです。

基本の知識

ざっくり書きます。詳しくは別途調べてもらったほうが良いと思います。

出資と融資の違い

融資は銀行などからお金を借りることです。返す必要があります。
出資は株式の一部を売ることでお金を得ます。もちろん返す必要はありません。
上場すると基本的に株価が何倍にも膨れ上がるので、出資者はそれを狙います。
（なので出資者は当然上場を迫ってきます）

投資ラウンド

出資を受ける前　シードラウンド
１回目の出資　シリーズA
２回目の出資　シリーズB
３回目の出資　シリーズC

なぜ出資を数回に分けるのか？というと、会社資産＝全株式の総額のうち、どのくらいの株を放出できるかという問題があるからです。上場していないくても徐々に株価の評価額は上がります。徐々に調達しなければなりません（そうしないと大半の株を他社に取られてしまいます）
また、会社の成長は突然起きるわけではないので、いきなり大金を受け取っても使いきれなかったりします。

出資の金額と目的

もちろんこれは会社や事業次第なんですが、ITサービス運営の場合はかなり似てきます。

シードラウンド
貯金・身内に借金・エンジェル投資家など
100万〜1000万円くらい　とりあえず事業開始するところまで

シリーズA
1000万円〜3000万円が多く、ほとんどは人件費に費やす
ただ広告費が必要な場合は数億円になることもある

シリーズB
5000万円〜15億円くらいが多く、人材獲得と事業拡大に費やす

シリーズC・シリーズD
2億円〜数十億円くらいが多く、事業の多角化に費やすことが多い

調達は良い兆候？悪い兆候？

当然事業をしているわけですから、そこですこぶる儲かっていたら調達する必要性ってあまりないんですよね。
例えばシリーズAだけ調達して数年沈黙っていうところ結構あります。
3000万円でそんな何年も会社が持つわけないので、事業でちゃんと儲けているということでしょう。

じゃあシリーズBの会社はまずいのかと言えばそうでもなく、好調な事業を更に大きくするために調達して加速する会社はたくさんあります。個人的にはシリーズBはやって当たり前なのかなーと思えるくらいにどこもやってるイメージあります。

ではシリーズC・Dはどうなの？というと、少し事情が変わってきます。
シリーズBの後に上場するケースがよくあるので、上場せずにシリーズC・Dとなると、何か理由がありそうです。
これが戦略的な理由であればいいですが、単純に上手く行ってない場合は調達おかわりということなので、注意が必要でしょう。
（上場せずにひたすらデカくなる会社もありますから、そこらへんは何故上場しないのか分析する必要があると思います）

ここらへんは一個人が知れる情報なんてたかが知れてるんですが、資金調達のプレスリリースで出ている調達理由がどれほど納得できるものなのかで判断すると良いと思います。

各フェーズでの会社の状況

シードラウンド

とにかく金が無い短期決戦の状態です。基本的に近づくメリットは薄いんですが、やろうとしていることに共感できるとか、0→1を体験したいなら良いと思います。
ここらへんは要件定義力・コミュ力がかなり問われるので注意しましょう。
私も複数案件で経験があります。どんな感じなのか聞きたければ直接聞いてください。

シリーズA

このフェーズもあまり資金に余裕がありませんが、従業員人数も5人〜20人程度とそれなりの規模になってくるためちゃんと組織だってきます。
個人的には一番おもしろいフェーズだと思いますが、まだまだ安定とは程遠いためカオスとの戦いになります。
シリーズBまでに明確に売上を立てて行く必要があり、上手く行かない場合は辛いことになるでしょう。人の入れ替わりも激しいです。

シリーズB

ベンチャーを狙うならシリーズB直後が一番良いでしょう。キャッシュにある程度余裕があり、このまま上場まで突っ走るべく準備するフェーズです。従業員数は15人〜40人程度でしょうか。徐々に中小企業じみてきます。
優秀な人もバンバン入ってくると思います。色んな業界業種から入ってくるので面白みもあると思います。事業も世間的に認知され、面白い時期です。
ただここで停滞する会社も多いです。
あと、前任者がやっつけで書いたコードを修正するはめになることが多いです。

シリーズC・D・上場直後

優秀な人達が寄ってたかってもがくフェーズだと思います。事業設計が複雑になってきて、より普通の企業に近づいていきます。
ベンチャーとしてのプライオリティはさほどありません。
コードも複雑になっていることでしょう。
ただし安定はしています。10年後も会社は存続しているはずです。

その会社のフェーズを知るには？

調達情報はプレスリリースが出るため、「会社名　調達」でニュース検索すればすぐ出てきます。
これで現在どのフェーズかがわかります。

ベテラン＋初級者の組み合わせは案外パフォーマンスが良いという話

システム開発というのは非常に時間コストが掛かる作業ですが、何にそんなに時間がかかっているかといえば、試行錯誤や手戻りに時間がかかっているんですよね。
最初に見積もりする時はだいたい一本道の正解ルートを辿った時のコストで考えてしまいます。
しかし僅かな仕様の差やバージョン差などで、Aという方法で上手く行かないということがあります。それでBという方法やCという方法を試したりして時間が掛かってしまうわけです。

体感ですが、すんなり正解の方法をとった場合のコストを80だとすると、見積もりで100を提示します。予想から漏れていたタスクが30増えて、試行錯誤で30増えます。結果160くらいで60％くらい上振れることが昔は多かったです。

最初に思い切って80の2倍の160と見積もればよかったんですけど、中々難しいですよね。頭の中では正解のルートを選択している想定なので。

実際は、Aルート、Bルート、Cルート・・・とあって、どれかを選択し、やってみて、だめなら他のルートを試すわけです。もしこの正解が予めわかっていたら、つまり登るべきタスクと言う名の山のルートが分かっていたら、かなり時間コストは抑えられるわけです。

だから、ルートを分かっているベテランが初級者をフォローすると、思ったよりパフォーマンスが出ます。

もちろんこれはタスクの種類に依るでしょう。
試行錯誤するための時間コスト、正解を引き当てるまでの確率、ベテランと初級者の作業のスピード差などによって状況は変わってきます。
ただアプリ開発やWeb開発においては、あまりにも選択の連続であるため、ルートを知っている者と知らない者で大きな乖離が出てきます。
初級者はベテランからの指示を仰ぐことでサクサク進むことができるはずです。

ただこの方法をずっと続けて良いのかという疑問は少しあります。
試行錯誤して、ダメなルートで何度も痛い目を見ないと、初級者がベテランになることはできないのではないか？と思います。
でもだからと言って無駄なルート取りをして苦しでもしょうがないですよね。
試行錯誤がそもそも好きな初級者ならいいでしょうけど。

これはその初級者がどの組織やどのプロジェクトでやっていくかに依ると思いました。
例えば正解ルートの1つだけ選んで行けばいいプロジェクトや組織なら他のルートについて知る必要はありません。
例えば事業会社なんかではこうなるかもしれません。リードエンジニアがしっかり居る受託会社でもこうなるかもしれません。

一方で、誰かが書いたコードを読むためには、正解ルートは全部しる必要があるし、ダメなルートも網羅的に覚えていかなければなりません。自分が普段使用しているAという方法以外に、BやCでも解決可能ならば誰かがそれを使ってコードを書いているでしょうし。そうなるとルートについてかなり深くまで知らなければなりません。

1. リードエンジニアが居て、フォローしてもらえる状態
2. 組織の規模が大きく、ベテランが容易に見つかる
3. 組織内でコードの書き方の規格が統一されている
4. 組織は大きいが、プロジェクトによって書き方がまちまち
5. 組織の規模が小さく、ベテランが見つからない
6. フリーランスなど自力が要求される状況

１、２、３なら初級者はルートについて詳しくなくてもどうにかなります。
ただしベテランが抜けたらどうなるかはわかりません。あと３は初級者には判断がつかないかもしれません。
４はよく見かける状況です。初級者でも試行錯誤が必要になると思いますが、前任者へのアプローチが容易なのでヒントはもらえるでしょう。
５は試行錯誤が必要ですが、１個の正解ルートを見つけたらそれだけ使えばいいのでコストはそれほど多いわけでは有りません。
６は試行錯誤が必要なうえ、全部の正解ルートやダメルートも知る必要があるので、ルートについて網羅的に知る必要があります。

だからこれはその人が今後どういうキャリアにするかに依るんです。まずそこを考えないといけないですよね。

そんなことを最近思いました。

その人が攻める山のドメインを適切に絞るのが大事なのではないかと。

エンジニアの幸福とは？どう実現するか

前回に引き続き、あまり推敲できていませんが、メモとして。
最近ちょっと混乱気味でちゃんと考えられてるかわかりません。

あと考えていったらエンジニアというより労働者の幸福みたいになってきました。

幸福を知るにはモチベーションを知らなければならない

何がしたいのか、何でエンジニアをやるのか。
もしくは究極的には働きたくないのかなど、そこらへんを探っていく必要があります。

３つの柱

やりがい、お金、時間と捉えてみました。どうでしょうか？
この配分は人によりますし、優先順位があったり、細かな差異もあります。

 

余裕が出ると顕著になる

そこそこのベテランフリーランスになって、潤沢な案件から仕事を選べるようになると、それぞれ働き方が変わってきて非常に分かりやすいです。
皆自分の幸福について考え始めるのではないでしょうか？

パターン１：もっともっと稼ぐ（複数の仕事をする）

パターン２：働く時間を少なくする

パターン３：働く場所を変える

パターン４：よりやりがいの感じる仕事を選ぶ

正社員の場合はこのパターン1、2、3が殆どできないので行動に顕在化されないですよね。
だから似たようなシステムで社員をやってるのに、それぞれのモチベーションが違うところにあったりして厄介です。

フリーランスを観察すると、700万あたりまではお金重視で、それ以降は働く時間重視の人が多いように思えます。これは観察対象が30歳前後で家庭を持っていない人が多いからというのもあるかもしれません。

それ以外のモチベーションの特殊事例

目標がある
例えば起業したいとか。
これはやりがいに入れてもいいですけど。

外圧
例えば家族に求められているとか。
これは主に金ですね。

なんとなく
意外とあるんですよね。

「お金」を分解する

これは金額面と安定面があると思います。

「やりがい」を分解する

• エンジニアをしていて楽しい
• ユーザーに使ってもらいたい
• お客さんの役に立ってうれしい
• 社会的な影響力
• チームプレイが好き
• 会社が好き
• プロダクトが好き
• 他の仕事より苦じゃないから（向いてるから）
• 自尊心・名誉が得られる
• 成長を感じられるから
• 夢や未来、将来性があるから

など

あるいはそれらを目標にしている状態。

幸福に対するマイナス要素「ストレス」

こちらも考える必要がありますよね。

• 将来への不安（不安定、キャリア、賃金など）
• スキル習得が難しい
• 人間関係のストレス
• 開発上のストレス（身体的ストレス、精神的ストレス）
• 長時間拘束のストレス
• 劣等感
• 虚無感

など
書き出すとわかりますが、「お金」「時間・働き方」に対するマイナスと、「やりがい」に対するマイナスが対の形で存在している気がします。

その人のモチベーションを分解した上で、そのモチベーションを最大化する環境と成長が得られる状態に身を置くのが最適解

当たり前のことしか言ってないんですが。
こうなりますよね。
まずどうしたいのか、どうなりたいのか、何が好きなのか、何が嫌いなのか、最終的にどうなりたいのか。
それらを考えた上で、決められるのは「自分がどうするか」と「どの環境を選ぶか」になると思います。

別解：短期的視点からのアプローチ

私は上記のようなアプローチでいつも物事を考えてしまうのですが。
どうやらそうではないような人もいるらしくて、もっと短期的視点で考えてる人のほうが世の中には多いのではないかと最近反省しました。

例えば私なんて、高校の時にITやろうと思って、そこから大学、大学院、就職と、約20年一貫してやってきているわけですが、世の中そんな人だけじゃないですよね。
それに短期的視点が悪いわけでもないなあと今更になって思いました。長期的視点は真面目なようでいて、達成まではずっと辛い状況が続くし達成できない可能性も結構高いわけですが、短期的視点だと臨機応変にその時々の幸福ややりたいことを考えて取りにいけるわけです。

幸福を考える時には最終的な結果だけ考えるのは間違いだと思います。幸福という視点では過程の方が大事かもしれません。
もちろん短期的視点にはデメリットも多々ありますが、上手くいくと幸福度は長期的視点より高いと思います。

短期的視点に立つ場合、「最終的にどうなりたいか」を考えるのをやめて「今どうしたいか」を考える感じになると思います。
結局決めるのは「自分がどうするか」と「どの環境を選ぶか」というのは同じなんですけど。中身のモチベーションの一覧が変わってくると思います。

エンジニアを採用する企業はどのようにエンジニアの幸福を目指すか

そんな事考えてる企業がどれほどあるのか不明ですが。
「お金」と「時間」はほぼ全員に共通する話題だと思います。一方でこれらは動かしづらいものでもあります。
やりがいについては多岐に及ぶので、全てを用意するのは不可能に近いのではないかと思います。ですので、自社で提供できるやりがいのリスト、あるいは提供できないやりがいのリストがあって、それにマッチした人材を探すのがベターな方法になりそうですね。

もしくは先に社員が居て事業を決める場合なら、どういうモチベーションがあるかを探ったほうが早そうです。
といっても、本人にすらわかってないケースも多いのでこれは理想論でしかないと思いますが。

キャリアを用意するのか、しないのか

最近ベンチャー界隈で働いていて感じるのは、キャリア全然ないなーという感想です。
そもそも規模が小さいのでキャリアを用意するなんて無理なのかもしれないですけど、あれ社員には不安ですよね。結局会社を転々としつつキャリアアップしていくしかないような気が。
もうそれでいいやって感じなんですかね？
そりゃー転職市場が盛り上がるわけだ。

エンジニアに立ちはだかる3つの壁

ちょっと考えました。

メモ。

エンジニアは3つの壁があると思います。
これらはどのような方針で攻略できるかでまとめました。

1つは普通にプログラミング知識やエンジニアリングの知識です。発展型として設計力があると思います。

2つ目は、所謂上流系のスキルと細かな開発テクニックの経験値です。

3つ目は、学術的な調査力や、特殊な専門性の高いスキルです。

最も簡単に攻略できるのは「プログラミング・エンジニアリングの知識」

本にも書いていますし、学校でも教わることが出来ます。先輩にも教えてもらえます。
ここらへんは3000時間も頑張ればモノになるんじゃないでしょうか。

ただ、ここの知識だけでフリーランスになるのはちょっと危険だと思います。
どうしても2つ目、3つ目のスキルが要求されてくるのと、フリーランスになってからここを伸ばすのが難しいので、組織の中で頑張るのが良いと思います。

上流系のスキル、開発テクニックのためには良質な複数の仕事が必要

これが１社で賄える大きい企業に属しているならラッキーですが、それが叶わない場合はどうにか勉強するか、転職などして大海に出ていかなければ得られないと思います。

もちろんハードルが高いです。あと時間も年単位でかかります。

調査力は全く別のスキル

1つ目と2つ目を戦略的に獲得できたとして、3つ目は全然系統が違うスキルだと思います。ただ仕事をしているとここらへんの特殊な専門性を求められることが出てくるでしょう。
それを突っぱねるのもいいと思います。というか完全に地力でやるのは無理があります。プロジェクトはチーム戦ですから専門家に任せるのもいいでしょう。
ただ、専門家に頼むほどではないけど調査や実験が必要なタスクというのが存在します。
例えば課金処理とか、ライブラリーやSDKを使って解決できるようなモノは非専門家のエンジニアがそのままやることが多いですよね。
それができず、詰むようだと、おそらく一人前・独り立ちとは認めてもらえないと思いますが、じゃあこの領域をどう教えてもらうかと言えばちょっとむずかしいですよね。個人の資質に寄ってしまいそうです。

1人前のエンジニアとはどこなのか？

1人前を「独立できるエンジニア」と仮定すれば、全部できてようやくだと思っています。そうしないと取れる仕事が減るので非常に危険です。

ただ、全員が全部できるべきかと問われれば疑問です。それはマッチョな思想ですよね。1人前じゃなきゃエンジニアじゃない、みたいな考えは現実的ではありません。

それぞれの戦略、どこに所属するのが幸せか

1つ目＋2つ目＋3つ目の方

独立してもいいですし、社内でベテランポジションに落ち着いてもいいですし、出世してもいいですし、プロジェクトリーダーをしてもいいと思います。自由です。

1つ目＋2つ目の方

こちらは社内に居たほうが安定すると思います。自分の専門性が活かせる会社です。危険なのは5年に1回しかそのスキルを使わないみたいな状況で、その度に勉強・調査が必要になると大変です。

1つ目＋3つ目の方

プロジェクトリーダーが最適なポジションだと思います。独立はあまりオススメしません。専門性を持った方を抱えている会社で、そういう人に仕事を依頼する解決方法を取るのが安定すると思います。

1つ目のみの方

1つ目のみの方の中には、2つ目3つ目を攻略途中な方がいると思います。そちらの方はそれぞれに適した仕事を見つけるべきでしょう。
そうではなく、力量的に、あるいは労働時間的に2つ目3つ目を攻略するほどの余裕はなく、1つ目に終止するならば、フォローしてくれる人や組織がある状況で、かつマッチョな思想ではないところに属するのが幸せだと思います。給料は安くなるかもしれませんが。

ただ基本的にどの会社もマッチョな考え方しますよね。っていうのを今日考えました。私はマッチョな考えにならないように気をつけたいです。

エンジニアよ、絶望せよ

キラキラした期待を持ったエンジニアの気持ちをくじきたい。今そういう腐った気分です。よろしくお願いいたします。

実務未経験者は絶望しよう

新卒や若手でもない限り、未経験者が潜り込めるような隙間はほぼ無いです。
それでもどうにかして入ってくる人が居ますが、極稀で優秀な人達だけです。
その優秀な人達ですら一旦泥水を啜るようなキツイブラックを一旦くぐって入ってくることがほとんどでしょう。
絶望してください。未経験者を普通に雇う理由は企業にほとんどありません。いくつか例外はありますが、ポジティブな理由ではなりです。

受託企業に絶望しよう

受託企業が絶望的なのは、単価の頭打ちがあることです。かなりいい所で月120万円が上限くらいになるんじゃないでしょうか。これは会社が受け取る単価です。実際の給料は半分くらいになります。
すると年720万円ですが、こんなうまくいきません。
閑散期があればもっと減りますし、大抵はプロジェクトが見積もりどおり行かずに揉めたり、炎上したりするともっと減ります。いいところ300万円台ですよね。
受託会社は常に締切に追われています。一部の仕事が集中してる人は寝袋を持って職場に寝泊まりしています。
規模を大きくするほどに経営者は儲かる構図なので、どんどん技術力が怪しい人を入れます。その割に育成に力を入れません。そんな余裕ないですから。
結果的にどんどん優秀な人がやめていきます。おかげでいつまでも技術力が会社につかず、それでもどんどん若手は投入されます。
大抵は残業代が出なくて、裁量労働制だとか言って裁量がありません。
社員はどんどん疲弊していきます。変な話ですが、外注の方が良い暮らしをしていたりします。
絶望です。

人材派遣型SESに絶望しよう

SES、私は良いと思うんですよ？　勉強する分には、案件ガチャが上手く行けばですけど。
不景気になった時に強いって言いますしね。今まさにその時ですよね。でも会社が潰れたら元も子もないんですけどね。
SESが絶望的なのは、所属感がゼロな割に社名を背負ってるので責任は重いところですね。責任は重い割に重要な部分の技術を触れせてくれなかったり。
案件ガチャもあります。変なのに捕まると数年出てこれません。
そしてガチャがあるにしては安い。
もちろん会社に入れる分が差っ引かれるので安いんですが、会社は人を増やそうとしますよね。その人が増えた分自分にメリットが有るかと言えば無いです。昇進するみたいな仕組みがエンジニアにはない事が多いですからね。結果やっぱ皆出ていきますよね。
実績を口外できないことが多いのも困ったものです。守秘義務ってそこまでに及ぶの？っていつも疑問なんですが、会社通してるのでおおっぴらに書きづらいですよね。

常駐フリーランスSESに絶望しよう

個人的にはだいぶ良いと思いますけどね。
数年もやってると限界が見えてきます。まずリーダー経験みたいなのは積めないです。職場を転々とすることで社員と仲良くしようとする気力が徐々に削がれていきます。これは人徳やコミュ力次第かもしれませんが、どんどん知人が増えていくか、どんどん減っていくかの二択です。私は後者です。

あと前任者の書いたクソコードをひたすら直す作業に明け暮れるはずです。自分のせいじゃないのに仕事が遅いことを咎められます。それが仕事です。絶望してください。

報酬はいいですけど、明日突然仕事が無くなってもおかしくない状況なのは変わりないです。コロナでどうなるんでしょうね。あとローンが組みづらいです。家を買うのは結構キツイんじゃないですかね。

自社サービスのベンチャー（立ち上げフェーズ）に絶望しよう

ベンチャーに憧れるのはわかります。
まだ5人以下の小さな会社で世にインパクトを与えたいというモチベーションもわかります。
ただしこの規模の会社はとにかく金がありません。激安で凌がなきゃいけません。
その上ヒットする確率は雀の涙ほどです。
ストックオプションは基本的に無駄になります。絶望してください。あなたは零細企業に勤めています。

スタートアップに絶望しよう

立ち上げフェーズが上手い、成功させるのが数回目みたいなチームがあると思います。
気をつけてください、彼らのやり方は通常のものではありません。だいたい骨までしゃぶられた後で切られることでしょう。
それも勉強と思って参画するには良いですけど、次のあてを探しておくのが賢いと思います。

大きめのベンチャーに絶望しよう

もう既にある程度成長した、上場前後のベンチャーは仕事をするのに大変良い環境だと思います。
でもその分優秀な人が既に入っていて、仕事の方針をだいたい固めてしまっています。
そこに後から入っていっても、あまりイニシアジブは取れません。人数も多いので、結局一兵隊として働くことになるでしょう。それで良いのであれば良いですけど。色んなことができると夢見てきた人は絶望して去るでしょう。

機械学習・AI系に絶望しよう

そちらに行けばもっと面白い仕事ができるのではないか、と思って転向された方も居るでしょうが。
考えてみてください、KPIの数値改善をして喜ぶのは大きな金額を扱っている大企業が基本です。
そこに対して提案しなければならないと言う状況は、SIerがやっていることと近いです。
別にSIerが悪いとは言わないんですが、わざわざ機械学習とかAIに手を付けた人が、結局大企業を相手にして数値改善をするために技術のわからない人と交渉することになるのは望んでいない展開なのではないでしょうか。
こっちも多分絶望的だと思っています。

終わりに

エンジニアは隣の芝生が青く見えているでしょう。
あそこならもっと良い仕事ができるんじゃないか、そう夢見ているかもしれません。
ですが大抵は幻で、どこに行っても絶望はあると思います。
さあ諦めましょう。
ふて寝しましょう。