2024年の振り返り

今年はの冬休みは出かけたり作業に集中したりして恒例の振り返りが書けなかったのでこの時期になってしまった。 ただ2024年は色々と挑戦した年だったが上手くいったこともあるし、良くなかったこともある年だった。

勉強会や交流会に参加

経営者同士の交流会に誘われて参加した。結果から言うとちょっと自分には今のタイミングではないなと感じたので退会した。悪い場所ではないと思うし合う人には合うと思うが、子どもが小さいタイミングで優先して継続的に参加するのは難しかった、、

ただそれ以外の勉強会やiOSエンジニアの交流会にも参加してああエンジニアの勉強会はこういう感じだったなあと思いだした。

年初の個人開発やめることについて

結局色々と考えた上で完全にやめるというのはしないことになった。ただ、個人開発と書くと趣味みたいな感じになるので普通にサービス作りというように変える。

継続する理由としていくつかある。

まずコロナ直前からあったDXブームは少し一段落した年だった。その結果システム開発自体の件数は落ち着いた傾向にあると思う。
そのためちょっと営業すれば良いようなことは難しく、何かしらの戦略を持たないといけないなあとはやっていくうちに感じた。また単純に受託して何でもやりますだと印象に残りづらい。そのためこういうことに興味があるということを発信するためにもサービス作りはした方が良いし、またサービス経由で仲良くなれたらいいなと考えている。

追い風としてコーディング面も含めてAIの発達が進んだので昔よりも敷居は下がったと思うし、AIを活用する素振りとしてもサービス作りの経験は重要そうである。 とはいえ毎回一からスクラッチするのでは大変なので共通化しやすいようにしていっている。

受託について

今年はいくつかの案件に参加した。ただ、やはり普段の自社サービス企業の開発とは違う。自分の参加したシステム規模は大きくないので比較的にリスクは小さいがこれが何千万や何億みたいな金額のシステムになると全然違うスキルが求められる。ということで自分はシステム開発はできるけど、受託開発のプロではないと感じることが多かった。

が、今の受託開発のやり方が今後AIが導入され始めるとめちゃくちゃ大きく変わるなあと同時に思った。とくに大規模なシステム開発というよりも自分が得意とするスモールチームでの開発のやり方は大きく変わる気がする。今までは重い要件定義や見積もりをしてから本格的な開発着手だったが、今後はPoCのようにAIである程度までのシステムを一気に生成しお客さんに触ってもらいながら詳細をつめるみたいなことが起きそうである。この方が認識の齟齬もおきづらいし、とりあえず触ってみないとよく分からないと今までだったらわがままな要求も満たせそうである。ただ要件定義までの時間は短縮はされると思うが全体の工数が下がるのかというと劇的に下がることは無さそうと思う。結局デモとしてシステム開発とユーザーに提供するシステムは作り込みが違うので期間は下がるかもしれないが、システム開発に費用はそんなに落ちないと予想している。

ともかく昔のiPhoneクラウドと同じように、AIによる受託システム開発はゲームチェンジャーである。

技術について

iOSの開発は継続して行っている。今年は本格的にSwiftUI導入の年だったので、UIKitよりSwiftUIで構築する時間の方が多かった。

自分のサービスではNext.jsを使った。とくに最新のAppRouterを使用して作業した。よくSNSで言われているような難しすぎるという指摘は一部当たっているし、誇張に表現されている面も多いという印象を受けた。 ただ、Next.jsは自社開発という枠組みでは上手くいくかもしれないが、受託開発になるとやはりまだ先進的すぎて使うのは時期尚早ではあるなあと。

あと受託の方はRailsを使用した開発を行っていた。久しぶりなので結構忘れていたが、こちらも改めてメリット・デメリットあるなあと感じた。とはいえRailsMVC全て完結するフルスタックの面とActiveRecordの優秀さなどはやはり唯一無二と感じる。

ここしばらくTypeScriptでバックエンドを構築していたが、オブジェクト指向ではないし、かといって関数型言語ような強力なパターンマッチやIO向けの機能が備わっていないので記述量が多く疲れた(個人的に感じるあらゆることがTypeScriptはBetterではあるがBestではない)

仕事の強度

会社員・フリーランス・経営者関係ないんだけど、仕事の強度を減らしていくのはやめた方がいいなと思った。30代後半って絶妙で目の前の仕事は今まで資産でなんとかこなせるし、育児も含めてプライベートでも忙しくなる期間だと思う。ただそうすると手癖で処理するようになり、新しいことの挑戦や目の前の仕事にスーパーコミットするみたいことをしなくなり40代ぐらいの微妙なおじさんが出来上がる下地になりそうだなと思った。

だから今の期間に1日2~3時間しか仕事しなかったり、旅行しながら仕事するみたいなことはしないように自分を律しないといけない。

家庭の時間を減らすというのは別にしないが受けている仕事や自分の仕事については営業時間内は精一杯コミットする習慣をもっと継続していきたい。


2025年について

今年からは年間単位の目標を立てることはやめることにした、というよりも立ててもあまり行動に結びつかないので意味がなかった。
そこで今年からはOKRを使うようにする。OKRというツールはここ何年か仕事先でも使っていたし、四半期単位で設定するのも良い区切りだと思うので。別に目標設定をしないという判断をしてもいいのだが、そうすると目の前のタスクばかりに手を取られて緊急ではないけど重要なタスクに手がつけられないので長期的にやばいなという自覚が出てきたので。

やばいなという実感の一つとして生成AIの台頭である。エンジニアの仕事がこの先どんどん需要が逼迫するという予想だったのだが、生成AIの登場で前提が大きく変わった。つまり今の開発のやり方が10年以上先までも同じやり方で残るとは到底思えない。生成AIによって低品質な翻訳やイラスト作業が消滅したようにどこかのレイヤーがまるっきり無くなるということはありえるだろうし、そこまで頭数が要らなくなり賃金が低下することはありえそうである。

ただ悲観的な面だけではなく解決できる課題も広がるし、今まで良くも悪くも日本語が障壁だったのが同時通訳によって海外の仕事を請け負うハードルが低くなることもあるだろう。

まとまりの無い感じになってしまったが、今年も頑張りたい。

工数見積もりのサービスを作った

最近、システム開発向けの工数見積もりを簡単にするサービスを作った。

https://www.bakumitsu.com/

トップページのデザインは全然だめだし、まだ作りたい機能は山程あるが一旦リリースしないとずるずるしてしまうなあと思って公開した。

バクミツのコンセプト

一言で言うと「システム開発における工数見積もり作業に対して、正確さと作業時間の短縮」を目指し、より抽象的には「工数見積もりのベストプラクティスを集めたフレームワーク」を提供したい。 システムに開発において要件からどのぐらいの工数を見積もることはクライアント作業であれば利益に直結するし、自社開発でも事業計画に影響があるので正確に見積もることはすごく重要である。

例えば最近でもスタートアップが金融向けのシステムを大手企業と協業して作ろうとしたら、莫大な開発が必要と発覚して最終的には解散になった。これは極端な例だけどエンジニアをやっていれば当初予定していたリリース日から2~3ヶ月遅れてしまったということは結構な人が経験していると思うし、その結果の機会損失や軌道修正に多くの作業・時間が失われることになる。

他には受託開発であれば見積もりを出して欲しいと依頼があると思う。ただこの見積もり作業というのは作業としては非常に重いのに、失注した場合はタダ働きになる。このような損失を少しでも減らすために見積もりの効率化は重要であるし、さらに早い段階で不明点を洗い出せておけば赤字というのも防げる。

自分が持っていた課題点

見積もりにおいて誰にどのようなシステムを作るのかという要件定義はかなり重要だ。ただ要件定義の部分は個々のケースが違うので共通化して解決することは難しかったりする。ただ見積もりが外れる点として自分は以下の課題があった。

  • Excelスプレッドシートで見積もりすることも多いがとくにテンプレートを持っていいない
  • Excelスプレッドシートについて苦手意識がある
  • 誰かが公開しているテンプレートもあるが、自分には不要な項目があったりしてしっくりこない
  • システムの設計・実装の部分に見積もりにを重視しすぎて、その他のドキュメント作成やミーティング時間に対してのぬけもれが多い

つまり見積もりにおいて要件定義は以前として重要であるが、そもそも他の部分も改善できるしこれが10%改善するだけでも大きな差になっていく。

その他のモチベーション

以前宣言したがあまり個人での開発についてやる気は実はなかった。ただ、今年は入って外部の人と交流するようになって感じたのは自分のサービスやプロダクトを持っている方が話題のきっかけになりやすいなあと感じた。

また今までは自分が好きだったり、将来性がある(勝手に?)と感じたサービスを作ってきたが、自分が継続的に使用するという部分については出来てなかった。そういう意味では開発する上で見積もり継続するので最終的に自分ひとりだけでも使用する。

直近の目標

まずは工数見積もりの一点について10倍の効率化を目指すツールを目標にする。

【2024年】受託案件でRuby on Railsを使用した感想

5月から7月末の3ヶ月間に受託の案件をしており、その際にRuby on Railsで使用した。
選定の理由としては元々の依頼主がRailsに詳しかったり、別の先行しているプロジェクトで参考になるコードが多かった、つまり資産を流用できるのでリスクが低いと判断して採用した。

個人のRailsの経験で言うと合計で2年ぐらい過去に使用していたが、結構忘れてしまったところも多かった。ただ1ヶ月を過ぎたぐらいでだいぶ書き方を思い出したのでそこまで足を引っ張ったわけではなかった。

この記事の狙いとしては久しぶりにRailsを使った感触について書いていく。

実装の作業量はフロントの方が圧倒的に高い

最近のプロダクトの業務量としては圧倒的にフロント側の方が高くなってしまった。これは単純にユーザーが普段使用するtoCサービスにおいてUI/UXがかなり向上し慣れてしまったからだ。
その他にも純粋にサービスの機能で差を付けるのが難しく、また競合に真似もされるのでプロダクトにおいての違いの部分が使いやすさが重要になった。

そのためSPAのように画面遷移をなるべく挟まない、昔ながらMVCで十分という古いエンジニア多い意見に対して賛同できない。今はよっぽどPoCとかそういうプロジェクトでない限り純粋な機能差で圧倒できるビジネスモデルは難しい。(めちゃくちゃ使いにくいけど圧倒的な営業力で売上を上げているプロダクトはあるが、それはこんかいとは関係のない話)

以上の背景が前提にある。

Hotwireの感想

今回の案件では画面の動きをHotwireメインでサービスのコアとなる複雑なUI部分だけReactで実装した。Hotwireについては以下のブログ記事がとても参考になるし主張している箇所も納得できる。

Hotwireの良かった点、辛かった点、向いているケース、向いていないケース - 猫Rails

ただ上の記事でも書いてあるようにReactとHotwireの両方を利用するバットプラクティスを実践した。理由はコアの部分の仕様が複雑すぎてHotwireのみでは実現が難しかった。

Turbo Frames, Turbo Streams, Stimulusの使い分け

Turbo Frames, Turbo Streams, Stimulusの左から右への順番で複雑なUIに対応ができて、StimulusというのはJavaScriptも書きたい場合に使用する。要するに段階的に使えることがメリットらしいが自分は逆にデメリットに感じた。

そもそもそのUIが以上の3つうちどれからスタートすればいいか経験がないと判断が難しい。Turbo Framesからスタートしていけばという意見もあるが、どう考えてもその試行錯誤している時間は無駄だし、またUI変更とは頻繁あるのでその度に切り替えるのはコストがかかる。

Railsは選択のレールがしっかりしていて、迷いが少ないというのが売りだがここには迷いが生じているので個人的には微妙な点だった。

手続き型のJavaScript

Reactは関数型の傾向が強いが、Hotwire(Stimulus)は手続き型の記述なのでなんというか、昔のjQueryでの実装に近い。確かにJQuery使うのであればHotwireで良いと思う。 たぶんRails自体が関数型の書き方ではないから、それに合わせたと思う。

ただ手続き型で複雑なUIを実装していくには困難ということは歴史が証明しているので、今回コアの部分をReactする結果になった。

そのため機能によっては一部Reactなりで書かないといけないみたいなことが発生すると開発者がHotwireとReactの両方に精通する必要があるのでそこは問題がある。 しかし、上の記事にもあるようにView側は完全にReactでRailsAPIサーバーに徹する場合にコミュニケーションコストが確かに発生するので、小規模案件ではペイしないと主張も正しい。

TypeScriptを使わない

Stimulusは基本的にJavaScriptで記述していく(DHHがそのように方針を変更した)。そのためビルドが複雑になるのを回避するために、ReactもJavaScriptで記述するようにした。結果的にReactの部分が複雑になったのでケアレスミスが発生しまた補完が効かないので効率が悪かった。

確かにRuby動的言語だから統一したかった狙いはあるかもしれないが、個人的には開発者体験が悪かった。まあRuby書いている人がその延長でStimulusを書く流れだから分かるが、、フロントエンドエンジニアからは不評である。

以上のことを書いてて結局Reactが必要がないような仕様であれば100%意見は変わっていたと思う。ただし、ユーザー視点ではなくHotwireだとキツイので仕様変更しましょうというのも違う気がするし今回のように自社開発ではない場合に断るのは難しい。

Hotwire以外でRailsの良さを感じたこと

Hotwireに関しては厳しいことを書いたが改めて良さを感じたことも多かった。やはりActiveRecordは強い。ORMとしてのメリットも大きいがバリデーションが直感的かつ短い記述で書けるし、テストの周りもFactoryBotやFackerなど定番のライブラリを使って簡単に記述出来たこと。 以前Nest.jsで以上のバリデーションやテストコードを書いたがRailsほどに洗練も情報も十分ではないのでやはり大きく差がある。

またRails consoleの使いやすさやdebuggerも使いやすいので、ViewではなくAPIサーバーに徹したコードをかけばストレスはほぼ感じない。

ただ最大に良いところはRailsフレームワークの機能ではなく、アーキテクチャも提供している点だ。いわゆるRails wayというものである。Rails以外のフレームワークは最低限の置き場所は決まっているケースもあるが基本的にはプロジェクトごとにアーキテクチャが異なる。もちろんちゃんと分析し設計すれば良いのであるが、プロジェクト初期にそこまで分析できることは稀である。また初期にその設計が良かったとしても初期メンバーが入れ替わったり、サービスのピボットでベストが変わる可能性がある。つまり、Railsの設計方針はBestではないけどBetterであるし、世の中のほとんどのプロジェクトはそれで十分だったりする。

Hotwire以外でRailsRubyの残念なところ

RailsというよりもRuby動的言語であるためnilの判定を事前にビルドしてチェックできない。 これは上記で書いた利点が動的言語であるからのトレードオフになっている。RBSというLintでチェックもあるらしいがまだそこまで広がっていない。それにRBSを後から頑張って書くのであればGo言語で書き換えしてパーフォーマンスの向上も選択肢に入る。結局昔感じた大きなプロジェクトの場合に事前に型のチェックが出来ないことによる問題は当たり前に残っている。

大規模プロジェクトにRailsが使えない?GitHubやShopifyのような大きなサービスでも使われているじゃないかという反論もあるがそもそも比較することがナンセンスだと感じる。所属しているエンジニアの能力も給料も全然違うしRailsを保守していく費用も日本の一般サービスと全然違う。

ただ難しい問題で事前に型のチェックような入ると今のRubyRailsの良さの部分も大きく影響あるだろうし、たしかに静的言語の要素を積極的に取り入れてしまうと単純にRubyの魅力も同時になくなる。

まとめ

以前以下のような記事を書いた。
受託企業のプログラミング言語とフレームワークの選定 - cassette

色々と批判的なことを書いたが受託開発する上で実はかなり相性の良いフレームワークと感じた。受託開発だとスタート開始時点で十分な仕様が固まっていることも稀だし、またドメインエキスパートとなる人間と距離がある中でBestではないけどBetterであるアーキテクチャを提供するのは開発を進める上で心強い。

受託開発の考察:スタートアップ時代からの変遷

今年になって受託開発をしたいなあと思って受託開発について色々と調査したり、イベントに参加したりした。その中で現段階のまとめをしていく。

前提

2010年代はスタートアップの時代で受託開発よりもとにかく自社サービスで一発当てるぞという時代だった。その中で有名なサービスの誕生した影で何十倍もの新規サービスも生まれては閉鎖されていった。また新規サービス構築の話や投資資金もスタートアップに流れいたためかなり金回りのいい時代だったので、スタートアップが自社サービスを運営しながら片手間でも受託開発をしていられる環境だった。

ただ、去年ぐらいからソリッドベンチャーという言葉も出来きたように赤字を掘って急激に成長するよりも手堅く利益を上げる会社やスモールビジネスが流行り受託開発会社が増えたと感じる。そのため競争が激しくなり特徴が無いと厳しくなっている。

つまり相対的に強みがないと今後受託開発企業は生き残るのが厳しくなっている前提がある。

強みの分類

上に書いたように受託開発会社が強みを作るためにどのような仕掛けしていくのか分類した。

1. 技術で差別化

基本的にはフリーランスエンジニアの生存方法と同じでフリーランスや小さい組織が向いている手法である。供給よりも需要の方が旺盛である新技術をキャッチアップして行くやり方。 過去の事例は山程あってiPhoneアプリ、Reactによるフロントエンドの変化、AWSの登場などが大きなトレンドである。最近であれば生成AI関連もこの分類である。 ただしこの手法は2~3年でライバルが急激に増えるので、賞味期限が速く参入障壁を持つのが難しい。

小さい組織ほど向いているので個人のエンジニアはファーストチョイスだろう。問題なのはそういう需要を伴った新技術が出てくるのを自分でコントロールするのが難しい。

2. パッケージ (SaaS)+ 受託開発

何かしら企業向けのパッケージを提供し、そのカスタマイズも同時に提供するパターン。実際にパッケージのみ一本で十分な利益を上げるのは難しい。そのため別途カスタマイズという名の受託開発もすることで利益をあげる。すごく分かりやすく言うとスーパーの広告の品がパッケージでお客様を集め、ついでに他の商品も購入してもらうという手法だ。

いくつか事例を聞いたが頭がいい手法だなあと感じた。実際に受託開発企業の鬼門はリード獲得と信頼関係構築だ。そのため受託で開発しませんかと営業をするのは、いきなり高額なマンションを売るのと同じように難易度が高い(何千万もする商品を良く知らない人に発注するのは勇気がいる)。

そのためフロント商品である企業向けのパッケージを提供し関係値を深めて、カスタマイズに移行するという手法だ。

ただ問題は2つあって、

  1. 魅力があるパッケージを作ること
  2. カスタマイズは一般的に開発が難しい

低額であってもいらないものはいらないので、魅力的なパッケージを提供するというがそもそもの難題だ。また自分もSaaSを作ったことがあるが非機能要件部分が多いので単純に開発量が多く、カスタマイズに手をまわしすぎて本体部分の開発が進まないということも考えられる。

とはいえ開発に自信がある企業であれば挑戦する価値はある。

3. 伸びているプラットフォーム乗る

例を出した方が速いがLINEのミニアプリ構築、ShopifyでEC構築する。昔ならEC キューブとかもあった伝統的なやり方。純粋なエンジニアからすると技術難易度が物足りないがこういう伸びているプラットフォームに乗るというのは手堅い。ただ開発能力が必要といよりも顧客はそのプラットフォームで売上を上げたいのが目的なので実際はコンサル面もサポートする必要がありそうと感じた。 そのため昔からやっている企業が実績が分かりやすく持っているので強い。さらにプラットフォームで有力な開発会社であればプラットフォーマーと繋がりを持っている。そのため後から参入するには障壁が高いので初期の段階で参入するのが重要だと感じた。

4. 案件を持っている企業・コンサルと組む

開発案件(高額含む)を沢山持っている人や企業と組む手法。例えば代理店やコンサル企業は多くのクライアントを抱えているので、その開発案件を分けてもらう。
企業サイトはボロボロや技術も高くないが売上がすごい企業はだいだいこのパターン。とはいっても一番鉄板で他の強みともコンフリクトしないし上手くいけば時間もお金も節約できる。最終的にこの手法のためにそれ以外の手法が存在するくらい強い。

ただ何も開発体制が揃ってない段階で高額な案件を受注しても納品が難しいので、いきなり実行するのは難しのではと感じる。

雑感

上に色々と手法を書いたがたぶん個人や小さい組織であれば行動量を増やせば何とかなる。ただ大きな規模の成長を目指すには工夫が必要みたいだ。 受託開発の社長の人とも話したが結局大きくなっても、安定的に大きな予算の案件を受注するのは難しいらしい。個人でも大きな受託開発の社長でも悩みは共通している。

受託企業のプログラミング言語とフレームワークの選定

最近は既存の業務委託の仕事に加えて受託開発の仕事も受けている。まだ全然始まったばかりだが受託関連の技術選定について書いていきたい。 ここでいう技術選定はプログラミング言語フレームワークという狭い範囲を指す。

まず自社サービス企業の技術選定はケースバイケースだ。よく議論でこうするべきだというのがあるが、サービスの特性だったりメンバーの経験であったり、それこそ今後の採用計画によって変わる。

それに対して受託企業の技術選定というのは実はもっと固定化しており、それほど自由が無い。 しかし、実は利益率に直結するので自社サービス企業の技術選定よりも慎重に決めた方が良い。

前提として請負だろうが準委任だろうが受託企業の仕事範囲は新規サービス・プロジェクトのリリースまでが一般的には担当範囲となる。そしてその前提が今後のほとんどのことを決定する。

受託企業はクライアントとの要件定義後に詳細見積もりを行う。ここでは仮に50人月という見積もりだしたとする。ただ実際にクライアントに提示するのは60人月とか多めに請求をする。それは不足の自体のバッファでもあるし利益でもあるので悪いことではない。ただ、仮に70人月で提案して40人月で終わった場合に差し引き30人月分の労働力を他に回せるため利益率が高くなる。

つまり良いプロジェクトというのは提案した人月よりも出来るだけ少なく作業を終わることでリスクを回避し利益率が高くなるのを目指す。ということは逆にリスクとなるような新技術を使うよりも社内では枯れた技術スタックを使って進める方がリスクが低く、万が一炎上した場合に補充もしやすい。

ここまで書いてわかるように受託企業の技術選定は本当に案件にあった技術を選定をしたり、新しい技術を取り入れることはリスクが大きいしそもそも利益率が悪い。そのため一般的な人気技術を選定していることが多い。

具体的にはどういう基準で選ぶのか

ここからは個人の考えだけど大きく外してはいないと思う。

初速が速い

だいたいのプロジェクトは開発期間が3ヶ月〜6ヶ月ぐらいが多い。そのため1年以上開発したらありがたみが分かるような技術は選定しない。分かりやすく言うとコンパイルが遅い言語は微妙である。結局3ヶ月〜6ヶ月ぐらいのプロジェクトであれば頻繁なリファクタリングは発生しないため、保守がしやすいよりも最初から開発効率が良いのが選ばれやすい。

人員を調達しやすい

Javaが金融・製造業を筆頭にしたエンタープライズで採用されることが多いことの理由の一つとして、大規模なプロジェクトでの人員調達がしやすいことがあった。これがScalaであると人員調達が難しい。 例えば、プロジェクトが炎上しており外部から人員を調達する時はあると思う。ここでニッチだが生産性が高い技術よりも、人員調達コストが楽な技術を選択が重要である。

フレームワークデファクトスタンダードが決まっている

例えば、Rubyの中のRuby on Railsのようにデファクトスタンダードが決まっている。これは上の人員調達しやすいにも被っているが、要するにエコシステムとして一つのフレームワークに集中している方が問題があった時に情報量が多く対処がしやすい。

以上の要素を持っている言語とフレームワークの組み合わせを考えると自ずと選択肢として絞られる。

うん、、すごい無難である。
だが、これらのフレームワークで対応できない要件やパフォーマンスを求められるのであれば自社で開発した方が良いし、上記の中から選定をしてクライアントから後に怒られるということは無いだろう。


ここで別のギモンが生まれた。

受託企業の技術スタックに結構何でも対応しますと書かれていることが実は多い。例えば、JavaPHPRubyも何でも出来ますよという企業だ。完全な嘘ではないが上記の技術のクオリティを高く保つのは相当難しい。というよりも高く保てば技術スタックが分散して利益率が悪くなる。もちろん人数が多い企業であれば可能かもしれないが、現実的には人数が多い企業の方がその分の見積もりが高くなる傾向があるし、やはり同じWeb系のアプリケーションを作るのであれば分散する意味があまり無い。

そのためもし自分が発注者で技術選定を決めているのであれば、その技術に対して得意な企業を依頼する方がよい(病気の手術でもその病気の手術件数が一番信頼になると聞いたことがある)。 ただIT企業でも無い限り発注者が新規のシステムがJavaなのかRubyなのか気にするところは少ないのでよく見過ごされている。


最後に自分自身についても考えていく。
Webの場合はあまり上記の3つの技術に対してコミットするモチベーションは低い。技術が好きとか嫌いとかではないが、上記の1つを選択したとしても差別化が難しい。上の技術を選択するということは技術ではなくそれ以外の要素で勝負するということとほぼ同じ意味であるので。現状は子どもも小さく沢山営業活動をするというのも難しいのも理由のひとつだ。

ただ長くなってきたので別の記事にする。

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

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

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

まず前提として一人親方で業務委託として単価を上げていってもだいたい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年は増えると思う。