フリーランスは年取ったら仕事無くなるぞ問題

昔からフリーランスは年を取ったら仕事無いぞというのをよく言われてきた。反面今まで業務委託で仕事していると人手不足はどの現場でも発生していて、年取ったらえっそんな仕事減るのという思っていた。

ただ最近少し受託営業活動してみて年を取ったら仕事無いぞという指摘に対しての意味が分かるようになってきた。

まず前提として一人親方で業務委託として単価を上げていってもだいたい1,500万円ぐらいの売上で頭打ちである(この額が高いか低いかは別として)。それより伸ばそうと稼働時間を伸ばさないとかなり難しい。ただ、稼働時間を伸ばすといっても若い時は可能であるが家庭を持つ、健康も含めて考えると長時間の稼働を長期的にやるのは難しい。

そのため考えられることして、何かサービスを運営したり売上が大きい請負の受託をするか、あとは組織化してSESのクライアントワークの高度化に分類される。 ただフリーランスが一人でやるサービスの運営は難易度がかなり高く、収益も実際そんなに上がらなかったりする(センスがいい人はすごく伸びるが、センスが無いと全然伸びない世界)

そうなると難易度とリターンのバランスを取ると請負の受託、組織化していくのが選択肢にあがってくる。

受託の世界

実は自分のキャリアとして最初の会社は受託会社だった。ただ1年半しか在籍していないので、詳しくないまま事業会社に転職してしまった。で、受託の営業してみたが難しい。というよりも調べてみて分かったのが、受託については9割紹介で決まるみたいだ。

これは過去の自分の経験にも合っていて社内で外注したい時は既に取引実績がある会社に頼んでいた。これには理由があってシステムの環境構築だったり、社内アカウントを既に発行していたりなどしていて実作業までの時間を短縮できるからだ。発注者の立場で考えてみると多少安かったりする新規の会社よりも面倒な雑務をカット出来たり、最悪システム開発で炎上したとしても社内的に言い訳が出来るのだ。

つまり何を言いたいのかというと取引実績があり、それが継続しているというのはシステム開発においてはかなり有利である。証拠として事実規模の大きい企業であっても企業サイトがかなりダサかったり、古かったりする企業は多い。

ということはフリーランスが年を取ってから仕事が無くなってきたので、急に受託の営業をしたとしても難しいというのが分かる。また新規に出すとしても金額が安く、体力があって将来有望そうな若い人に仕事を振る方が優先度は高い。

年を取ったら仕事無いぞの正体

受託では技術力ではなく、いかに取引実績があるのかというのが極めて重要である。そのため、年を取ってるのに人脈が薄いフリーランスに対して警報を鳴らすのだと思う。ただフリーランスにもグラデーションがあって、ちゃんと需要の高い技術をちゃんとキャッチアップしているエンジニアやスピードががちで10倍ぐらい違う人もいるので例外も沢山ある。個人的な経験だけど警報を鳴らすのが中小企業の社長さんが多かったので、失礼だが質の悪いフリーランスエンジニアとの経験や仕事の依頼が多くバイアスがかかっているのでは?と感じた。 また受託の営業と業務委託で1人分の仕事を売り込む営業では難易度は違う。変な話だが業務委託で1人分で最初の契約期間は1ヶ月にすれば新規取引だろうがリスクが低い。つまり実力があれば人脈が薄くても2~3社知り合いの会社がいてその案件を回せばとりあえず食っていくことは可能だ。

いかに新規を取るか

結局のところ何も武器がない状態で受託の新規を取るのはかなり難しいだなという実感になった。そうなると取引実績のある会社から紹介してもらったり、既存の取引先よりも1/10ぐらいの予算を提示する、過去にあったクラウド・モバイルアプリという新市場にいち早くキャッチアップするなどしないと難しかったりするのかなと思った。

とはいっても自分の性格や経験から営業がめちゃくちゃ強くなるというビジョンも見えにくい。昔知り合った人はそれこそ週5で飲みに出歩いて取引先も含めて関係性を深めていたが、自分が出来るとは到底思えない。

そう考えると継続的に自分に強い分野を作り発信していく必要性を感じているので、ここをもう少し試行錯誤していきたい。

2024年以降の生成AIの予想

もはや何番煎じなのか分からないが、年末年始にずっと着手していなかった生成AI関連のキャッチアップしてみて思ったことを記録として残しておきたい。

生成AIの何がすごいのか

自分の感覚で言うのであれば実は今まで機械学習でも原理的には同じことは出来る。ただし、今まで機械学習はモデルの作成までに膨大なデータや人件費やお金がかかっていてさらに特定の業務にしか特化していなかった。そのため一般の企業ではその膨大なコストが払うことが出来なかったので、現実的に採用するのは難しかった。

しかし、OpenAIのモデルは汎用かつ高性能、しかもコストが圧倒的に低く提供しているため現実的に使えるようになったのが革新的である。

また使い勝手もかなり簡単になっている。今までアセンブリ言語で記述が必要だったのが急にPHPぐらいまでの記述が簡単になっている。一応専門的な能力は必要だがかなり敷居が下がったのは事実だ。

そういう意味では自分としては生成AIという言葉よりも、機械学習の大衆化のニュアンスの方がしっくりくる。

大前提

前提として生成AIがビッグワードでどこから着手していいのか分からない人が多いと思うが触ってみて改めて感じたのは個人の力をパワーアップさせる力が根源な気がした。つまり会社や組織の力をパワーアップさせるよりも個人の力を最大限に引き伸ばす武器としての活用が現時点では大きい。

エンジニアリング

もう既になっているのかもしれないが、今年・来年以降は生成AIの力を使った設計及びプログラミングはだいぶ本格的に浸透すると思う。これだけだとだいぶ雑な予想になるけど、プログラミングの面でいうとRuby on Railsのような設定より規約のような大体だれが書いても同じような仕組みのフレームワークを使うと効率化できそうな気がした。またRailsじゃなくて、DDDのように冗長だけど統一された書き方の方が上手く行きそう。

つまり何を言いたいのかというと冗長さを減らすために凝った作りにするよりも、冗長の部分は補完や生成に任せて統一する方がコード生成しやすいのではという考えだ。なので要件にあったピッタリとしたFremeWorkを使うよりも情報源が多い重厚なFrameWorkを使った方が機能拡充面ではスピードが早くなるのではという考えだ。

またインフラ構成もコード化しておけば、アプリケーションよりも複雑ではない分補完がかなり効くと思うので積極的にした方が良い。

モバイルアプリ

一応今はiOSエンジニアなので言及しておく。今は新規のアプリではFlutterやReact Nativeでの採用が多い。正直自分もよっぽどの要件でもない限りそれらの技術を使った方が良いのではと思っている(ただしそれらの技術も人材不足なのでそこは考慮していない)

ただ今後生成AI関連のプログラミングの質が上がってくればわざわざクロスプラットフォームではなくて、ネイティブで書いてしまうのもアリな気がしてきた。ネイティブはそこまで頑張らなくても動作も軽い、細かいチューニングもいざとなったら出来る、端末の最新機能を存分に活かせるメリットがあるので。 そう考えると新規でのクロスプラットフォーム採用も一定の範囲内で収まるのではないか。

デザイン・コピーライティング

Googleが広告部門の人員を大幅な削減したように、広告部門でのクリエイティブ関連の整理は進む。例えば広告のクリエイティブは1枚1枚丁寧に作成するよりも、生成AIで大量クリエイティブを作りその中でABテストを頻繁にした方が結果が出そう。

ランディングページの作成もコンセプトやターゲティングは自分達が考えて、参考したいページを渡して、生成AI側がいくつかデザイン案を考えてマークアップまでしてくれるというのはたぶん1~2年ぐらいで現実になりそう。そういう意味では今ザイナーやマークアップエンジニアを目指すのはやめた方がいい。またマークアップも今まではオフシェアで一部人件費で安い国で外注していたがここは生成AIでかなり置き換えが進む。

SNS活用

凝ったSNSでの活用をしないのであれば普段のSNSでの投稿やショート動画作成は生成AIで活用できるのではと思っている。例えば、サービスでユーザーが作ったコンテンツ紹介などはわざわざ人が運用しなくてもプログラムと生成AIを使って自動投稿が出来そうである。

まあ動画については0から作るのは難しいかもしれないが、編集の工程をかなり減らすことが出来るようになる。

直近必要な能力とは

エンジニアとそれ以外で大きく違うところは自動化できるの箇所の見極めが出来る点である。例えば普通の人が30分かけていたところをプログラムで自動化してしまう、また普通の人が自動化できると思ったところを逆に難しい(コストが合わない)と判断できるところである。

それは生成AIも同じでここは生成AIを使って短縮出来ますよ判断する能力が今後は必要になりそうである。しかも仕事で使えるレベルにはなるには、現実的に可能なのか、どのくらいの精度と工数で出来そうなのか見積もれる能力かなと。

企業では上手く使えるのか

広告など一部の業界ではものすごく活用されるが、正直まだ大きな成功事例は多くはない。今は期待が過剰にされている期間なので少し落ち着いて評価をする必要がある。ただそうはいってもトライしてみないと効果検証できないので多く企業で挑戦した事例は今後2~3年は増えると思う。

2023年の振り返りと個人開発の終了

今年はほとんどブログを書けなかった。 基本的に自由に使える時間は個人開発に当てていたので、ブログを書くよりも作業をしていたので。

ただいきなり本題だが個人開発は今年をもって終了することにする。自分にとって個人開発や趣味というよりも仕事という認識でやっていたので、そういう意味では趣味としてやるかもしれないが仕事という認識はやめる。

今年リリースしたアプリだがやはり集客が難しかったのが理由だ。もちろん全てやり尽くしたというほどやっていないが、総合的に見るとこれを直近事業として成り立たせるのは難しいと。もちろんユーザーヒアリングしたり広告を打ってみたりして非常に面白かったが、じゃあ事業としてどうだろうと考えるとかなり赤字と時間を掘る必要があるので、ハッキリ今の自分の能力だと難しい。

仕切り直しということで、個人開発の思い出を書こうと思う。

個人開発の思い出

現在はフリーランスだが元々は自社サービスのつなぎとして始めたものだった。そのため、最初は週4稼働で1日と週末を開発に当てるスタイルでスタートした。ただ、この方法だと開発に当てられる時間が少なかったので初めのサービスを2年近くかかってしまった。

最終的にこれは終わらないと思い4ヶ月間フリーランスをやめて集中してリリースまで行った。その次は友達と組んで行ったがその出来事は過去のブログに書いてある。そして今回のアプリが最後になる。フリーランスになって既に6年間が経っているので、自分はサービス数が少ない方だ。

途中のコロナ以降はフルリモートで作業ができるようになったので、今まで通勤時間が減って作業に当てられる時間が増えたのは良かった。

個人開発の反省点

どんなサービスを提供するかがほぼ勝負は決まってしまうが、これについては失敗した人の全てが共通認識なのでわざわざ言及するほどでもない。想像以上に重要だと思ったのは「販路・チャネル」だと思う。つまり、自分が想定したユーザーにどうやってリーチしたりするのかが最大に重要かなと。toCならSNSのどのプラットフォームでどのようなコンテンツで届けるのか。toBであれば見込み客をどのように集め接するのかなど。

正直ある程度の見込み客を集めれないとフィードバックを貰えないので、何が足りのかやそもそもコンセプトやターゲットがズレているのかが分からないので、全く進んでいる気がしない。

そういう意味では本格的に作る前に仮説検証は非常に重要だと感じたし、それこそ自分自身がSNSで最初の見込み客を引っ張れないと難しいのかなとも感じた。

個人開発をやって良かった点

個人開発ではいわゆる新技術の採用は出来るだけやめろという教訓があるが、今となってはそれについては無視して良かった。個人開発では使用した技術としてPython, Elixir, Kotlin, Node.js, Dart, TypeScript, React, Flutter, Spring, Phoenix, Django, Nest.js, GCP, AWSなどなど。他にも動画配信のサービスも作ったので動画関連の知識も出来た。

もちろん上の技術が本職の人たちにどう評価されるかと言われると自信は無いが、もし実践でやるとなっても1週間ぐらいでそこそこ書けるとは思う。

そして一番自信が出来たのは自分で企画・要件定義・デザイン・実装・効果測定まですべて一通り出来るようになったのは良かった(強いていうなら集客スキルが欲しかった)。

まあ6年間ほぼ毎日やっていたので、伸びるのは当たり前か。

なぜやめるのか

6年間を使って結果が出なかったそれに尽きる。 またヒットしたとしてもフリーランスの収益に比べると少ない収益しか当たらず時間もかかりそう、つまり期待値として低い。マクロな面を見ても昔よりも明らかに作り込みが必要になっていたり、過去のアプリバブルのような市場変化が起きていない。つらい話だが個人開発するよりもNoteやzennで本を売る方が難易度が低い(これも大変だと思うが、、)

それとサービスを作るという面では総合的に伸びたが、経営者として自分を見た時に成長はしていない点はずっと気になっていた。そう考えた時に業務委託をやって余った時間でサービス作りに時間を投入するというやり方が本当に正しいかは一度立ち止まって考える必要があるなと。

次は何に挑戦するのか

シンプル来年は売上金額のみを目標にする。そのため最悪手段は問わない。 金額はエンジニア個人で稼げる最大金額と昔思った額を目指す。今まであまり額に対してコミットしてこなかったがそれは逃げの感覚もあったので。

ただ金額だけだともし仮にその金額に達した場合と達成しないと分かった瞬間にやる気が無くなるのも問題なので、久しぶりに技術でも目標を持つ。

直近今の現場で必要そうに感じているのが全文検索関連の技術。ここ何年もフロント関連の仕事をしてきたが元々の技術としてはバックエンドやインフラ関連の方が好きなので携わってみたい。また狙いもあって企業向けの生成AI関連でもデータと検索に関わる部分が1番重要になると感じてるのが理由だ。

個人開発は色々と残念な結果になってしまったが、じゃあやって後悔もしていないし将来的にもやらないと決断したわけではないのでそこまで悲観はしていないが来年からはそんな感じで。

個人開発のサービスのα版が完成した

今月App Storeへの申請が承認されてあとはリリースボタンを押すだけになった。 やっと一息つけた感じではあるが、正式版を開発を進めてα版と正式版の期間を出来るだけ短くしたいのでリリースするのはもっと先の予定だ。

とはいえやっと一つのマイルストーンに達したので現状の振り返りをしたい。

どんなサービス

オンライン上でお金を払い一緒にゲームをする相手を探すサービス。

振り返って良かったこと一覧

  • Figmaをデザインツールとして選定したこと
  • Flutterを採用したこと
  • Node.jsをbackendに採用したこと
  • PlanetScaleを採用したこと
  • Notionで出来るだけWebページを構築したこと
  • Cloud Runを採用

箇条書きで書いた内容のことをいくつかピックアップする。

ツールと技術選定に関しては振り返ってみても良い選択だったと思う。今までAdobe XDでデザインを構築していたが将来性や無料プランを比較するとFigmaにして良かった(途中でAdobeFigmaを買収してXDの立ち位置も微妙になっていたし)

Node.js(TypeScript)の採用もまあ悪くはなかったと思う。GCPとFirebaseのSDKも豊富に揃っているし、そこそこ型付けできて(普段書いているSwiftを比較すると微妙だけど)、インクリメンタルビルドをサポートしている。サーバーサイドに関しては結局全部100点のものは無いので失敗しなければ良いと考えている。

PlanetScaleの採用はかなり良かった。GCPでCloud SQLを建てると月額でも料金がかかるので、今のところ無料で使えているのは嬉しい。また本番反映のフローもPull Requestもどきみたいなフローを使えるのでそこはかなり新鮮だった。

今までHerokuを使っていたが今回からCloud Runを使うようにした。IAMの連携やBuildやデプロイに関してはかなり複雑になり(今までのHerokuが簡単すぎた)途中後悔もしたが、終わってみると一週間ぐらいで構築出来たからそこまで問題にはならなかった。 ただ、Terraformで管理、ベストプラクティスなIAMを構成したいみたいなことをやると時間がかかるのでどこかで妥協出来て良かった。

振り返って今ひとつだったこと一覧

  • 単純に開発期間が長すぎたこと
  • Webサービスではなくモバイルアプリにしたこと
  • α版の定義が微妙だったこと。もっとApple審査に通すことを主目的にすれば良かった
  • 認証を最初からメールアドレス・パスワードにすれば良かった
  • Firebase Firestore難しすぎ

単純に開発期間が長すぎた。開始から16ヶ月かかったのでそれは想定外だった。 開発期間が長くなったのはひとえにApp Storeに公開するために必要な機能を初期の段階から揃える必要があった。これがWebサービスであれば自分の裁量でスコープを決められるがApp Storeから公開となるとユーザーもまだいないのに必要な機能が増える。 Webサービスとモバイルアプリの比較は初期リリースだけではなくて、長期的に見て比較してみないと分からないこともあるので現時点での評価は難しい。

今回はα版でとりあえずApp Storeのレビューを通すことが目的だったのだが、結果的にいくつかの機能が増えたり消してたりした。そもそも最初のレビューからReject判定されまくり、承認されるまで2ヶ月かかった。これが事業会社であればPMはストレスで倒れると思う。 Rejectされた理由としてはもうこれだけで一つの記事が書けるぐらいだが、レビューアーへのアカウント提供が上手くいかなくて時間がかかった(これを掘り下げるとまた記事が1本分に相当しそう)。

実はチャット機能があってFirestoreを使って実現している。チャット機能を過去の現場ではポーリングで実装していて、クライアントの実装が大変だったのでサーバーからのPushがあるやり方で実装したかった。ただ自分の実力不足もあるのだがRDBとFirestoreでのデータ同期が大変だったしFirestoreのスキーマ定義がかなり難しい。クライアントはシンプルになったが、全体の処理の流れは難しくなったと思うので結局どっちが良いのかは分からなかい。というより、スケールしやすいとかは正直そこまで重要ではなくて単純にリアルタイム更新が出来ればよかったので、Pusherとかで購読処理するだけでも良かったのか(ただ金額までを含めるとFirestoreに軍配が上がるし、、)

まとめ

時間がかかりすぎたという事実だけど、自分のペースを守った結果なので。あとは正式版までに足りなかった機能を追加しつつ、その後は既存の機能のブラッシュアップをしつつ集客に力を入れていきたい。

GPT-4でエンジニアはどう変わるのか

話題になっているGPT-4というかChat-GPTというかAIがエンジニアにどう影響するのか今の予想を残しておこうと思う。

開発について

色々な人が語っているがプログラミングというか開発に大幅な影響を与えることは確定的だなと。先月ぐらいから自分もGitHub Copilotを使用しているがかなり便利ではある。今のところ大規模なコード生成ではなくコードアシスタントとして活用しているが、ボイラーテンプレートの補完はかなり便利だ。ただ大規模なコード生成を活用していないのは自分が得意な領域のコードを書いているので頼らなくてもすぐに書けるのが理由だ。これは例えば普段書きなれていない言語や領域であればかなり活用する。

他にも経験が少ないFirestoreのNoSQLのデータ設計をしてくれるとかなりありがたいな。こう考えるとGoogleで検索やStackoverflowで調べていた作業は省けそうな気がしていて、生産性はより高くなるのは間違いないだろう(関係ないけど、みんなAIに頼ってWebに技術記事や質問を書かなくなった世界はどうなるのだろう)。

とは言ってもやはりまだ最近出たばっかりなので今すぐやらないと置いていかれるみたいなことはならなそうではある。というより進化のスピードが早く知識の陳腐化も早いのでもう少し落ち着いたタイミングで書籍で勉強する方が良さそう。まあ新しい物好きの人はやれば良いと思うが、勝者総取りのゲームではないので後で対応するで十分追いつける。

未経験・シニアエンジニアへの影響

未経験エンジニアの参入はより難しくなると思う。これらのAIの進化で面倒だけど難易度が低い人手必要な作業はAIでかなり置換が出来そうな感じはある。そうなると簡単なタスクをふることが難しくなるし、非エンジニアでも出来そうなタスクが増える。

悲観的なことを書いたがプログラミングの学習の効率化はかなり進むと思う。今まで学習においてコーチングやレビューしてくれる人がいなかったのだが、問題ありそうなコードをまるっと渡せば問題点を指摘してくれるのはすぐ実現する(もう出来てる?)。

シニアエンジニア関してもいかにAIの力を借りて進めるのかで生産性がかなり変わりそうでより少人数での開発が可能だ。が、生産性が上がったとしてもやるべき施策の数も比例して増えそうなので一日数時間しか働かないということにならない。ただし、今までいた技術顧問みたいな立ち位置の人は今後AIに置換されそうである。

今後のエンジニアの仕事について

エンジニアでコードだけ書ければいいというのはオワコンとは言えないけど、今後プレゼンスは低下しそうかなと。反対に企画・実装・分析までを行うエンジニアが増えるのではと思う。というより今回一番影響が受けそうなのは実は企画側の人間なんじゃないのかなと。例えば、企画のネタだしなどはかなりAIで候補も出せそうだし、サービスの文章もAIが生成してくれるので。

個人的にはエンジニア側の立場でどんどん企画して改善したということの評価体制が社会的にまだ高くなっていないので、今後はもっと企画リードできるエンジニアの能力を評価する世界になってほしいと思っている。

お金について

エンジニアの専門分野が減り収入が低くなるのではという懸念があるが個人的には杞憂かと。それよりも景気・所属会社・開発したい会社の数の方がダイレクトに影響するのでAI云々が占める割合は低いかなと。ただ、これが10年後みたいな話になると分からないが10年後の予想をする意味がないと思うタイプなので。まあAIをどこまで活用できるかみたいなことは検査で調べられそうで、そこで差がつくことはあり得る。ただその技術もGoogle検索力みたいな話で、本気を出せば1ヶ月ぐらいで差は付かなくなるのでは。

まとめ

エンジニアの仕事が無くなる・無くならないみたいな二元論を考えるのは無駄だと思う。大体結果としては二元論のどちらかに結末はならないし、二元論で考えるとその間にあるグラデーションの変化を見落としてしまうので。

2022年の振り返りと2023年に向けて

例年通り今年の振り返りをしたいと思う。
さほどブログを書いていない自分だが、今年はより少なく技術記事も書けなかった。原因はプライベートの変化が大きかったため取り組む時間を確保できなかった。

個人開発

去年の立てた目標では3月にリリース予定であったが現在もリリースは達成できていない。早い段階でこれは3月の期限は難しそうだな判断し、夏ぐらいにリリース出来ればみたいなことを考えて、結局年内中に終らなかった。 理由は単純に今までより規模が大きいのと、育児が始まると自由な時間が減少したことによる。

しかし、業務委託先込でもあるが去年よりも600commitほど多く作業していたらしいので数字ベースで言えばそこまで悪くなっていない、外出が難しい環境になったのでスキマ時間にしっかりやることにしたので驚くことにほぼ毎日作業は継続出来ていた。

結局のところ色々な効率的な方法を探しているよりも、淡々と毎日積み上げるだけの方が効果があるんだなと実感した。

個人開発の技術

もうこの技術を使いたいというよりも一番開発効率が良くてで維持費が少なそうな選定をした。アプリ側はFlutterでサーバー側はNest.js(node.js)で構築している。Swiftでネイティブの方が初速は早かったと思うが、開発期間がここまで長くなるとFlutterを選定して本当に良かった。Hot Restart, Hot Reloadの恩恵もあるが、Material Designベースでほどよくデザインに力を抜けるメリットも大きかった。

サーバーサイドはNest.jsを採用した。前回はKotlinとSpring Bootの組み合わせで開発体験はそこまで悪くなかったがメモリ使用量とコンテナベースのインフラを考えるともっと軽量な言語の方を選びたかった。あとはGolangとNode.jsを比べて個人開発ならNode.jsだなと思い消去法で選定した。Nest.jsはSpring Bootに構造が似ているのでほぼキャッチアップの時間は無かったのも良かった。ORMだけはTypeORMを選択したが勢いのあるPrismaを選択をすれば良かったかなと後悔することもあるが、作り直すほど不満もないので使っている。

インフラ構築はまだしていないが、構想はあってサーバーはCloud RunにDBはPlanetScaleの無料プランを使用する予定。あとは各種Firebaseのサービスを使う。

業務委託について

去年に引き続きiOSでの開発を行った。業務委託先については変更をしたが内容については大きい変化は今のところ感じなかった。単価も上げることが出来たので、売上向上についても引き続き今年も考えていきたい。ただ育児でかなり時間を取られてしまっているのでこれ以上案件を受ける余力が無いのが悩みである。本当はiOS以外にも案件を受けてみたいが、、

2023年に向けて

個人開発のサービスは今作っているのを最後にしたい。フリーランスになってからほぼ毎年新規に作っていたがそれも飽きた。それよりも一つのサービスをじっくり運営していきたい気持ちの方が強い。なので正式リリースを今年の前半中には持っていきたいが、毎年年初に計画を立てるけど上手くいっていない。 何年も作ってきて思ったが計画通りに進めようみたいな形でやると上手くいかなかった場合に熱が冷めやすいので、継続的にやれる時にやるという心構えの方が上手くいきそうな気がしている。

エンジニアとして専門的な分野で活動するという目標設定の罠

mobile.twitter.com

昔、Web業界に入る前にある人からプログラミング技術だけではなく、業務知識も知らないと仕事にならないよと教わった。ちなみにここで言う業務知識というのは会計・在庫管理などいわゆるユーザー系企業の基幹システム関連や特定業界の商習慣を指している。その時は素直にアドバイスを受け取りいくつかの本を読んでみたが現在その時の内容はすべて忘れた。

じゃあその人は嘘を言ってたいたかという訳ではない。自分の行かなかったSIer系のシステム開発では重要だったのだろう。ただ、自分の場合はたまたま重視する業界に行かなかった。

なんで活用しなかったのかと言うと、SIerのシステムというのは基本的に社内で使うシステムがメインだ。そのため企業が変わっても業務知識は流用出来る。例えば、基本的な会計の知識は会社ごとに変わる部分は少ない。
反面、Web業界は一般的に社外向けのシステムを構築する。そうなるとターゲット層が違うため知識を横展開することが難しい。今まで教育系のサービスを開発していたのに、フィンテック系のサービスに移動しても今までの業務知識を活用するのは難しい(そのためWeb系は流用しやすい技術面のスキルを重視しがちである)。

冒頭のツイートも恐らく受託(SIer)目線での発言だと思う。受託目線であればそういう知識は強みになるが、Web業界にいる自社開発系のエンジニアとしてキャリアとして有効であるかは自分は疑問である。

目的を具体化

「5〜6年かけて何らかの専門的な分野で活動できるようにする」というのは良さそう目標設定に思えるが、実際には難しい目標設定だと考えている。まず具体的に何をもって目標達成なのかが明確ではない。本を出版するのか、指名で仕事を受注できるのか、特定技術に対してのコミッターになるのかゴールは様々であるが共通として外部の人から観測される必要はある。しかも人によって専門能力を持っているのかどうかは判断も違うし、本人も専門能力を持っていると発信する必要もある。専門的な分野の知見も貯めて、発信も欠かさないというのは実際かなり大変な作業だ(そもそも業務内容が発信出来ないのであればどうするのだろう)。

また専門性も賞味期限がある。7~8年前であれば例えばReactに精通しているのであれば立派な専門性があったが、今Reactが得意ですというのにどれほど価値があるのだろうか。まだReactであるならいいが、廃れてしまった技術であればかなりもったいない。

いやいや特定の技術ではなくて、もっと特定のドメイン分野の話だ。というと先ほどの内容のようにWeb系では特定のドメインに強いことがSIerよりも強く働かない。もし特定のドメインで経験を生かしたいなら、それこそコンサルタントやプロダクトマネージャーになる方がマシだろう。

それよりGoogleの〇〇のポジションのエンジニアになるという目標の方が遥かにロードマップと打ち手が明確で、最悪なれなかったとしても別の外資系企業に入れる確率は高い。

専門の流動性

以前新築を購入した知人にいい家とは何かという質問したことがあった。回答として日当たりや機能性についての内容が来るかと思ったが、内容は「すぐ売れる物件」という非常に現実的な返答だった。

このすぐに現金化しやすいことを流動性が高いと表現される。

そしてエンジニアのスキルを流動性の側面として捉えている人は少ない。一般的により専門性を高めていくと流動性は悪くなる。例えば、iOSのAR分野に非常に強かったとしても、ARのさらにモバイルで提供している企業は少ないのでスキルがあったとしても活かす機会が少ない。しかも、スキルが合致していたとしても賃金・勤務地などの条件のすり合わも必要だ。 もちろん流動性を常に高め続けることが必ずしも最適な戦略ではないが、5~6年も同じ分野の専門性を高めるというのは流動性の面から非常にリスクが高い。

結局どうすればいいんだ

とくに意外性の無い回答になるが、英語力を伸ばすのは今後ますます重要なのではないだろうか。円安で困ることはあっても、今後円高で困ることはここ10年は無いだろう。そうなるとグローバル企業働くか売上をドルで受け取ることは為替の大きな流れに乗ることが出来るのでかなりメリットがある。

また先程の特定の強みの技術を活かすのも日本だとニッチすぎて仕事が無いが、世界まで含めるとそれを欲している企業はありそう。

と、書きつつも自分は英語に関しては何も勉強していないので何も言えないが。