portal shit!

熊本城マラソンに出場した。意図せずベアフットシューズで走ることになってしまった。なんとマラソン用のシューズ（ ASICS MAGIC SPEED 2 ）と間違えてトレランシューズ（ ALTRA OLYMPUS 4 ）を持ってきてしまっていたからだ。 OLYMPUS は重いし微妙にサイズが合っていないので、迷ったあげく、普段ばきや短い距離でのランニングに使っている XERO SHOES の HFS （ベアフットシューズでソールの厚みが 7.5mm ）でフルマラソンを走ることにした。

ベアフットシューズでの生活はもう 3 年くいらいになるが、ランニングでベアフットシューズを使うのはせいぜい 20km くらいの距離までで、フルマラソンをベアフットシューズで走るのは未体験だった。

スタートしてから前半の 18km 地点くらいまでは 5:45/km ~ 5:50/km くらいのネガティブスプリットでサブフォーを狙えるくらいのペースで走れていたが、後半にペースを上げるのは厳しいだろうという感触があった。 18km 地点でこのままではゴールまで足がもたないと悟り、真面目に走るのを諦めてジョグのペースに切り替えた。その後転倒したりもしたが、歩きを挟んでなんとか完走することができた。

ベアフットシューズはふくらはぎのヒラメ筋への負荷がすさまじいので、フルマラソン完走となるとかなり鍛えていないと難しいと思う。普段はベアフッ党の方でも本番はちゃんと厚みのあるソールのシューズを履くことを激しくおすすめする。どうしてもベアフットシューズでマラソン走りたいなら、当然に 30km 走をベアフットシューズでこなしておくべきだと思う。ワラーチや裸足でマラソン完走する人はマジですごい

先週末と今日ガチャガチャやって、ようやく Ruby 3 にアップグレードすることができた。 Ruby 2.7.3 → Ruby 3.1.6 。ただ Ruby 3.1 は今年の 5 月に EOL を迎えるみたいなのでこちらもさっさと新しいバージョンの Ruby に上げないといけない。

やったことは一つ前の記事に加えて以下。

kaminari-sinatra の SinatraHelpers が Ruby 3 ＆ ActionView v6 対応していなかったのでちょこちょこと修正した。

Fix ArgumentError on Ruby 3 · morygonzalez/kaminari-sinatra@45cba48

Kaminari Sinatra adapter. Contribute to morygonzalez/kaminari-sinatra development by creating an account on GitHub.

github.com

次に padrino-helpers が Ruby 3 と Haml v6 に対応していないのを対応させた。具体的には form_tag の中身のタグが過剰に escape されてしまうので、あんまり良くないかもだが capture_html したやつを html_safe した。 form_tag の内側に来るものはユーザー投稿コンテンツではないはずなのでエスケープはサイト管理者側でできるはず。

Changes to support Ruby 3 · morygonzalez/padrino-framework@2c94a4e

Padrino is a full-stack ruby framework built upon Sinatra. - Changes to support Ruby 3 · morygonzalez/padrino-framework@2c94a4e

github.com

ドキュメントでは

= form_tag

を

!= form_tag

にしろとは言われているが、 form_tag の中身で concat_contet してる片方（ capture_html(&block) の結果）が html_safe? => false になるので、 View テンプレート側で何かやっても意味がない（ Buffer が汚染されると View で html_safe しても汚染された部分の文字列はエスケープ済みになっている）。

kaminari-sinatra も padrino-helpers も本家にパッチを送ると良いのだろうが、職業プログラマーではなくなったのでなかなか腰が重い。 kaminari-sinatra はテストが通らないし、 padrino-helpers は git clone で submodule の clone に失敗するのでテストが実行すらできないかもしれない。

心の余裕ができたらやってみる。

ちなみに Ruby 3 化するにあたり sinatra-cache を完全に捨てたので負荷が上がるかも。オリジナルの gem は 15 年くらいコミットされてなくて fork して使い続けてきたけど Sinatra や Haml の変更に追従できる気がしないのでいったん捨ててみる。

このブログは Ruby 2.7 でずっと動かしていた。コミットログをたどると 2020 年の 1 月から Ruby 2.7 のようだ。 Ruby 2.7 は 2023 に EOL を迎えている。

さすがにまずいと思ったので Ruby 3 にしようと一日頑張ってみたが、なかなかうまくいかない。Ruby 3 の キーワード引数の仕様変更はかなり対応がきつい。どこで ArgumentError が起こっているのかが極めて追いかけづらい。他のメソッドに委譲している場合などは特に。

ガチャガチャやってトップページと個別記事ページまでは Ruby 3 化できたので Ruby 3 でデプロイしてみたが、動かない画面があることに気がついたので Ruby 2.7 に戻した。 Kaminari がちゃんと動かない（具体的には kaminari-sinatra と actionview v6 系の互換性がない）のが原因でページネーションするページがちゃんと動かなそうだったので Ruby 3 化は諦めた。 kaminari-sinatra の ActionViewTemplateProxy#initialize を actionview v6 対応させないと無理っぽい。

kaminari のような有名な gem の派生 gem ならきちんとメンテされてるかなーと思っていたが、 kaminari-sinatra の最終コミットは 4 年前だった。

Not sure how much this buys us, remove it · kaminari/kaminari-sinatra@1e122ed

https://github.com/rubygems/bundler/pull/7222/commits/f8584fb864fc2e7e2527d5ba2c50907a38328c92 This fixes Dependabot security alert

github.com

Ruby で View まで作る人たちはほとんどいなくなってるのだろう。

なお動かないところのデバッグは ChatGPT と対話しながらやった。めっちゃ便利。一人だと気がつかないような部分のコードを見てみろと ChatGPT が言ってくれて、そこにデバッグコードを入れてみるとビンゴだったりする。便利な世の中になった。

忘れないようにやったこと・気づいたことをメモっておく。

• sinatra は v4 にあげないといけないのでパスの正規表現から ^ と $ は消さないといけない
• better_errors の REPL がちゃんと動かないので Backtrace を見たいときはログを開くか better_errors を使うのをやめる
• fork していた sinatra-cache は sinatra 4 では動かないので外した（キャッシュできない部分をどうするかは要検討）
• capistrano-puma も Ruby 3 対応させないといけない（期待される systemd のフォーマットが変わっているので単にデプロイするだけではだめで一部手作業が必要）
• tilt は v2.1.0 に固定（ Tilt::ErubisTemplate クラスが消えるため、 padrino-helper がエラーを出す）
• concurrent-ruby は 1.3.5 未満に固定
• compass は 1.0.3 に固定
• SESSION_SECRET は 64 文字以上にする
• haml の過剰な escape を抑制
• kaminari-sinatra の ActionViewTemplateProxy#initialize を actionview v6.1.7.8 の ActionView::Base#initialize に対応させる

人気記事を確認できるようにしたという記事を以前書いている。もう 7 年も前のことのようだ。

🤩人気記事を表示するようにした

ブログに人気記事を表示するようにしてみた。やり方はめっちゃ雑で、 Nginx の access_log を集計して Bot や Crawler 、 RSS Reader からのアクセス、画像や ...

portalshit.net

調べればこういうログ集約・集計系のサービスはあるようだったが、個人ブログなのでなるべくお金はかけたくない。

OpenTelemetry-native log management | Better Stack

Instrument your cluster without making any code changes. Ingest everything at a fraction of the cost.

betterstack.com

Access Denied

www.papertrail.com

しばらくの間は集計後のログを捨てていたが、 2 年半前からログローテートするタイミングで日付ごとのファイルを書き出し保存するようにしていた。日付ごとのログファイルは Amazon の S3 にアップロードしてさくらの VPS サーバーからは待避させている。現状、 2022 年の 6 月 13 日のログから S3 上にデータが残っているので、その日以後の日ごとの人気記事を確認できるようにした。こんな感じ。

portal shit!

森井ゴンザレス（ morygonzalez ）のブログ。 ブログを書くこと、プログラミング、インターネット、 Mac の便利なソフト、働くこと、ランニングについて書いています。

portalshit.net

日付の選択は最初 React のライブラリを使って作ろうかと思ったが、そういや最近のブラウザーは <input type="date" /> とすると結構ちゃんとしたカレンダー UI と日付選択の機能を提供してくれるので楽をすることにした。

<input type="date"> - HTML | MDN

<input> 要素の type="date" は、ユーザーが日付を入力できる入力フィールドを作成します。 日付選択入力 UI の表示は、ブラウザーやオペレーティングシステムによって異なります。 値は yyyy-mm-dd 形式に正規化されます。

developer.mozilla.org

max と min を指定すると選べない日付は非活性にされるし、無理に選択すると form を submit したときにバリデーションしてくれる。

ブログの閲覧者からしたらいつどの記事が読まれていたかなんて興味ないだろうけど、著者である自分には興味深い情報になる。セルフホストのブログだからできる機能だ。

YouTube の OGP が読み込めない問題があって、回避策をいろいろ考えていた。

YouTube は未ログインで bot っぽい User Agent でアクセスすると OGP のタグが入ってないページを返すようだった。

検索すると facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) という UA でリクエストすれば OGP タグ入りのページを返してくるようだった。

Finding Open Graph tags on youtube

I'm working on a Tampermonkey script to hide related videos on youtube if the og:video:tag contains "League of Legends". When I use the Open Graph Debugger (link) it find many tags (og:video:url, og:

stackoverflow.com

このやり方を試してみようとしたが、使っている gem が UA の上書きに対応していないので面倒くさそうだった。

追加でいろいろ調べてみると、そもそも YouTube は埋め込み用の HTML 片を返す API を用意しているようだった。

Youtube Video title with API v3 without API key? - Stack Overflow

Is it possible to get the video title using the video ID with API v3 without the API key? I could not find any information or example of getting the title in the API documentation.

stackoverflow.com

動画の ID がわかっているなら https://www.youtube.com/oembed?url=動画のURL という風に GET リクエストを投げると、動画のメタ情報に加えて埋め込み用の iframe スニペットを返してくれる。こんな感じ。

{
  "title": "Ride - Vapour Trail (Live on KEXP)",
  "author_name": "KEXP",
  "author_url": "https://www.youtube.com/@kexp",
  "type": "video",
  "height": 113,
  "width": 200,
  "version": "1.0",
  "provider_name": "YouTube",
  "provider_url": "https://www.youtube.com/",
  "thumbnail_height": 360,
  "thumbnail_width": 480,
  "thumbnail_url": "https://i.ytimg.com/vi/9bVS9j8NoZ0/hqdefault.jpg",
  "html": "<iframe width=\"200\" height=\"113\" src=\"https://www.youtube.com/embed/9bVS9j8NoZ0?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen title=\"Ride - Vapour Trail (Live on KEXP)\"></iframe>"
}

結果はこんな感じ。

こういう仕組みは標準化されていて oEmbed というっぽい。そういえば一昔前に聞いたことがあるような気がする。

OGP カードのようにしようかなと思ったけど、 YouTube 動画ならその場で再生できた方が便利かなと思ったので、 YouTube 動画の URL はすべて埋め込みとして表示することにした。

ちなみに YouTube にまつわる何かを検索しようとするとなかなか知りたい情報にたどり着けなくて困った。 YouTube OGP みたいなキーワードで検索すると、大量に OGP について解説している YouTube 動画がヒットする。技術寄りの内容というよりマーケターっぽい人向けの情報。これは地獄みがある。 Google だけでなく DuckDuck Go でも同じような結果だった。相変わらずインターネットは不便になってきている。

1 月

正月早々、山に登った。二年連続阿蘇山。砂千里側から登って仙酔峡に下山した。北面は日が当たらず凍っており、傾斜の急なバカ尾根を下るのは怖かった。

ブログには書いていないが確か正月の初売りで Mac mini の M2 Pro モデルを買った。 Apple Silicon の速い Mac を手に入れたので Whisper CPP を使って Castro を作っていた Supertop の Podcast の文字起こしをしてブログに書こうとしていたが、未完のまままだ公開できてない。年末年始で書き上げたい。

whisper.cpp で英語の Podcast を文字起こし

OpenAIのWhisperを使って英語のPodcastを文字起こししている。Podcastにはフィラーや言い間違いが多く理解が難しいが、whisper.cppのモデル選択で精度を調整できる。A...

portalshit.net

仕事はアプリのダウンロード数をどうやったら増やせるかを延々考えていた。開発をしてダウンロードを増やすなんて無理ゲーだろうと思ってたが、頭を使って何個か施策を考えた。あとは企業向けの機能をテコ入れしていた。

2 月

熊本城マラソンに出てる。サブフォーを狙っていたが練習不足で果たせなかった。一人で出て誰も知り合いのいない熊本城マラソンは孤独だった。来年雪辱を果たしたい。

熊本城マラソン 2024 敗因分析

熊本城マラソン2024に出場し、4時間12分で完走。練習不足や補給タイミングのミスが影響し、目標のサブフォー達成ならず。今後は練習距離を増やし、習慣化を目指す。

portalshit.net

中旬のやたら寒い時期に佐賀と長崎県境の多良岳・経ヶ岳に登山に行った。パラパラと落ちてくる樹氷の下を歩くのは楽しかった。花粉がやたらきつくて寒かったけど楽しい登山だった。

仕事はやたらネットワーク効果について考えてたが、まだ思考が甘かった。その後ハイパー起業ラジオを聞いたり本を読んだりしてネットワーク効果についての知見を深めていく。

3 月

3 月から 6 月にかけてはブログ記事がない（ 3 月に熊本城マラソンの記事を書いているが、それ以外は何もない）。

3 月の頭に糸島であったトレランのレースに出た。ショートレースであまりパッとしない成績だった。まだ 300km も走ってないアルトラのトレランシューズ Outroad が破れて悲しかった。

仕事は新規ユーザーの継続率を伸ばすための A/B テストをやってた。

4 月

平尾台のトレランレースロングに出た。雨降りでコンディションが悪く、関門タイムギリギリのゴールだった。このときからギリギリグセが付いている。

家の近くの山で有名なトレランチームの人たちを招いて緩い練習会をやった。グループ位置共有を宣伝できてよかった。

仕事はどうやって EC を伸ばすかを考えていた。やはり基本はネットワーク効果だと思って、ユーザーがレビューを書ける機能の土台を作っていた。日の目を見るのはだいぶ先のことになる。

あと、ユーザー登録数を劇的に増やす施策をリリースして、毎月の新規ユーザー数をかなり上積みできた。

5 月

南畑里山トレイルというトレランのレースに出た。楽しかったがショートレースは出し惜しみをしてしまう。レース後、体力が有り余っていた。

仕事ではこの頃から組織変更が計画されていて、自分の役割がちょっと変わりつつあった。

顧客起点を本格的に取り入れることになり、 N1 インタビューをやったりもしてた。

6 月

仕事で久住に登山に行った。ミヤマキリシマ終わったあとの平日の久住は静かでよかった。

組織変更の荒波に揉まれたり、 EC のシステムをどうするかを考えたりしてた。もはや単なるプロダクトマネージャーではなくなりつつあった。

7 月

キリエビのロングに出た。こちらも関門 10 分前のギリギリゴール。最後の 15km くらいを近くにいた人たちと励まし合いながら一緒に走った。とても良い思い出。

仕事はなんと平社員からいきなり部長になってしまった。やることが大きく変わり、隣の部長から厳しいご指摘を賜りながら歯を食いしばって働いた。

この頃からハイパー起業ラジオを聴いて積読していたネットワーク効果の本をちゃんと読むようになった。

8 月

脊梁ピストントレイルというトレランのレースに出たが、初めてリタイヤした。登りが急で、また水場がなく、とても消耗するレースだった。折り返し地点の関門時刻に間に合わず、失格となってしまった。めっちゃ悔しい。まだまだ自分は雑魚だと思い知らされたレースだった。来年は完走したい。

仕事では相変わらず EC のシステムをどうするかとネットワーク効果について考えていた。ユーザーインタビューではなく、山を歩いている人に話しかけて話を聞かせてもらうというのもやった。山を歩いてる人たちはほとんど自社アプリを使ってくれているのではないかと思っていたがそうでもなくてショックを受けた。

9 月

PayPay ドームリレーマラソンに出た。リレーマラソン前の二週くらいは休みの日の朝に大濠公園に集まってみんなで練習したりしてた。大濠公園から西公園や南公園に走りに行った。

仕事は相変わらずゴタゴタの整理をしていた。この頃はあまり戦略的な動きができず、目の前の仕事に右往左往していた。

10 月

翌月の福岡マラソンに向けて 30km 走を 2 回やりたかったが 1 回しかできなかった。しかし、初めて一人で大濠公園で 30km 走をやったのは自信になった。一人だと諦めないか心配だったけどちゃんと最後まで走れた。

仕事は相変わらずゴタゴタ処理。この頃から MAU を自分たちの力でどれくらい伸ばせるかにチャレンジすることになって、年末に怒涛の機能リリースをすることに。仕込みを始めた。

11 月

オアシス再結成の報を受けてオアシスをよく聞くようになってた。その流れでアンディー・ベルがオアシス加入前にやってたバンド RIDE の曲を聞くようになった。 Vapour Trail めっちゃよい。

ランニングは福岡マラソンに出てきた、ネットタイムではあるかサブフォーをギリギリ達成した。 8 秒差。

マラソンサブフォー達成人材になった

福岡マラソン2024でサブフォー達成。前年は自己申告の遅いタイムでブロックGからスタートし、今回Dブロックの利を得た。ペース配分で前半速すぎ後半に影響。高温と補給不足が足つりを招きつつも、前半の...

portalshit.net

また 11 月から会社の人たちと週に 1 回大濠公園を走るようになった。部活みたいで楽しい。

仕事ではリリースする機能の狙いや目的を社内で共有するのが難しくて難儀した。プロダクトマネージャー間で認識をそろえるのも難しいし、他部署の人と認識をそろえるのも難しかった。

12 月

11 月に引き続き宮崎であった青島太平洋マラソンに出たが、記録更新はならなかった。初めてレース中にうんこしてしまった。最悪。そもそも想定外に福岡マラソンでサブフォーできてしまったせいでその後のランニングのモチベーションが落ちてしまって全然走れてなかった。

仕事は仕込んでいた機能が次々リリースされた。炎上した割に期待した効果が得られない機能や、そもそも使ってもらえない機能もあったが、一つは結構当たって成果を出せた。加えて失敗のリカバリーで出した機能も大きな成果につながった。例年、 12 月になると利用が落ち込むが、 MAU を自分たちでコントロールすることは出来なくはないということがわかったのは収穫だった。いままで大雑把に捉えていた MAU を細かく分解して、それぞれの要素ごとの継続率なんかを分析してる。まだこれといった施策はないが、来年はこの知見を活かしてさらにサービスを成長させていきたい。

2025 年の抱負

仕事

去年のふりかえりでは「何者にもなれない人生だった」と書いていた（2023 年のふりかえり）が、いきなり部長になってしまった。

プロダクトマネジメントとピープルマネジメントは別物と本には書いてあるけど、人に頼んで何かやってもらうという点ではあまり変わらないとも思う。人から信頼してもらい、自分の言葉や考えを信じてもらって行動してもらうという点は変わらない。

それを言い始めたらエンジニアだろうが営業職だろうが同じかもしれない。仕事をしていく上で人から信頼してもらうことは重要だ。そんなの誰でも知ってそうだけど、意外とそれができない。

たまたま年末に買った『プロダクトマネジメントの教科書』という本が良くて、この辺のスキル（人から信頼される、リーダーシップやオーナーシップを発揮する）ことについて実践的な内容が書かれていた。

いかにリーダーシップを発揮するかやピープルマネジメントについて書かれてるのもいい。PMはミニCEOです（いや、違います）とかなんか言ってそうで何も言ってない本が多いなか、この本はどうやってリーダーシップを発揮するか、どうやってチームから信頼してもらうかが書かれてる。 pic.twitter.com/TsWLvppMGU

— morygonzalez (@morygonzalez) December 31, 2024

役割に応じた働きができるよう、もうちょい戦略的に動きたい。

ランニング

ランニング実は去年に比べて距離が伸びていない。これまで毎年距離を伸ばせていたが、今年は夏くらいから走る距離が短くなっている。毎月 200km は走りたいのに、部長になってからみるみる前年同月比の走行距離が落ちている。

ただ、ランニングのペース（スピード）は上がっている。去年だったらできなかったような、キロ 5 分を切るペースで 20 分間走をやれたりはしてる。なので練習の質は上げられていると思う。

来年こそは距離を伸ばして、月間 200km をコンスタントに超えていきたい。できればマラソンで 3 時間 45 分くらいでゴールできるようになりたい。少なくとも 2 月の熊本城マラソンではサブフォーを再現したい。

ブログ

実はこの記事を含めても 11 記事しか書けていない。もう少し気負わずに日記感覚で気楽に書きたい。クソみたいな記事でも書かないよりは書いた方がマシ。書かなければ何も残らないしふりかえることすらできない。

Twitter が X になったり、 Threads や mixi2 が登場したりしたけど、セルフホストのブログが一番表現力が高く自由度も高い。死ぬ間際に Twitter や Instagram を見返すより自分のブログを見返した方が良いと思える状況にしておきたい。

ソフトウェア開発者（エンジニア、デザイナー）の働き口は大きく分けて二種類あると思う。一つは受託開発の会社で、もう一つは自社開発の会社だ。これまで受託開発の会社は避けた方が良いと感じていたが、実は自社開発の会社も二種類に分類でき、ソフトウェアの強みをいかせる業種とそうでない業種があることに気がついた。

IT 系の専門学校とか大学で情報系の学部にいた人ならどういう業種が有望かを学校で習うのかもしれないが、専門的な教育を受けることなく IT 業界に潜り込んだ自分はこういう業界分析的なことができてなくて、なんとなく働き口を見つけて仕事を始めた。これまでの経験をもとに、どういう会社で働くとソフトウェア開発者が価値を発揮できて、良い報酬を得られそうなのかを整理してみたいと思う。

いま就職活動をしている人の参考になれば嬉しいが、どっちかというと転職者向けの情報になると思う。 IT 業界は転職が当たり前なので、新卒や業界未経験ならここに記載される分類を過剰に意識することなく、ブラックではない会社を選んで働いてみて、 2, 3 年経って技術が身についたらこの記事の内容を加味しながら転職活動をしてみるといいと思う。

ソフトウェアビジネスの特性

大前提として、ソフトウェアビジネスの特性から話したい。

ソフトウェアビジネスの重要な特性として、ユーザー数が増えたときの開発費用が線形に増えないことがある。経済学の言葉でいうと限界費用が限りなくゼロに近いということだ。メルカリのユーザー数が 100 人から 101 人に増えたとき、メルカリというシステムを開発するのにかかる費用は増えない（商品が追加で一個売れたときに発生する費用のことを限界費用という）。ユーザー数が 100 人から 10000 人に増えたら、さすがにサーバーインフラの費用は増えるかもしれないが、 100 倍にはならないし、ソフトウェアの開発コスト自体は（パフォーマンスチューニングなどは必要かもしれないが）基本的には増えない。

ユーザー数が増えても比例して費用が増えないということは、ソフトウェアビジネスは規模が大きくなればなるほど儲けられるということだ。対象とする市場が十分大きく、ユーザーのニーズにマッチする商品を提供できるならめっちゃ大きく当てられるビジネス領域なのだ。

ちなみにビジネスの費用構造によっては、規模を拡大できない業種もあるし、規模を拡大することはできるが限界費用が下がらず儲けられない業種もある。規模を拡大することで儲けられるビジネスは、膨大な初期投資が必要なことが多かった。電力・ガスなどのインフラ企業や大量生産大量消費型のメーカーなどだ。これらの業種は国の事業を土台にしていたり、戦前からの財閥にルーツを持つ会社だったりして、ぽっと出の零細企業が規模拡大型の戦略を取ることは極めて難しかった。

それがソフトウェアビジネスでは数人でやってるような零細企業でも真似できてしまうのだ。 GAFAM が成長したのにはこういう背景がある。このソフトウェアの特性をどれだけ活かせているかで IT 系の会社の種類を区別できる。

受託開発

最初は受託開発について。最も求人の数が多いと思う。受託はきついというのはネットでも見てたし、自分自身も受託の会社で働いたことがあってきつかった。当時の辛かった思い出について記事を書いている。

前働いていた会社の思い出と近況

前の会社では長時間労働やサービス残業が常態化し、精神的に辛い経験をした。労働環境が悪く、離職率も高かった。転職活動を通じて、自分に合った職場を慎重に選ぶ重要性を実感した。現在は新しい職場で楽しく...

portalshit.net

受託はきついはきついのだが、お金を得るのは比較的簡単だ。お客さんがこういうの作ってほしいと言ってるのを作ればよくて、作ったシステムがどのくらい当たるか（お客さんのビジネスの良し悪し）に収益が左右されることはない。お客さんが大コケしても対価はちゃんと支払われるし、お金がもらえるまでの期間が短い。スタートアップなんかだと黒字化するまでに 5 、 6 年かかることはザラにあるし、そもそも失敗して廃業する会社の方が多い。

しかし逆に受託開発は大成功しても最初の取り決め以上に報酬が得られる訳ではないので、ローリスクミドルリターンのビジネスと言える。受託開発は労働者として加わるときついが、経営者として考えたときには結構おいしいビジネスなのではないだろうか。

ちなみに冒頭で言ったソフトウェアビジネスの特性を活かせているかについていうと、活かせていない。お客さんの数が増えたときには新しくシステムを作る必要があり、費用が発生する。つまり限界費用はゼロではない。お客さんに納品するソフトウェア自体にはスケーラビリティがあるかもしれないが、それで儲けられるのはお客さんであって開発を受託した会社ではない。

とはいえ受託開発は自分が昔思っていたよりも悪くはない。どうやって価値を生み出すかはお客さんが考えてくれるので、いかにソフトウェアを最適化するか、スケジュールに間に合わせるかが開発者の腕の見せ所になる。キャリアの最初に、開発のノウハウを得るためと割り切って勤める分にはよいだろう。技術を突き詰めたいという人には実はこちらの方が向いている可能性すらある。ただしブラックではない会社を厳選すること。受託はビジネスの規模が大きくなりづらいのでやばい会社も存在する（自分が前勤めてた会社は本当にやばかった）。おすすめ度★★☆。

自社開発

ソフトウェア開発を自社で行っている会社と定義する。言い換えるとソフトウェア開発者を社員として雇用している会社。自分は受託開発の会社で働いてみてこりゃダメだと思ったので、次は自社開発の会社で働きたいと思って転職活動をした。当時はペパボに転職した。

自社開発にも二種類あって、何のためにソフトウェアを開発しているのかで大きく二分できる。業務効率化のためにソフトウェアを開発している会社と、自社の事業を成り立たせる骨子の部分がソフトウェアになっている会社だ。

業務効率化のためにソフトウェア開発を行うビジネス

このタイプの会社は自社にソフトウェアとは無関係の本業がある。ソフトウェアは本業の業務効率化に利用している。例えば自社で生産したものや仕入れたものを売るために EC サイトを作っているようなビジネスだ。ソフトウェア（ EC サイト）はおまけで、プロダクトの販売経路の一つに過ぎない。この手の会社は昔は受託開発会社の顧客だったりする。以前はどこかの会社に出していた EC サイトの開発を自社でやるようになったタイプだ。

この種のビジネスは本業の部分のスケーラビリティがボトルネックとなってしまう懸念がある。例えば EC サイトの部分は限界費用ゼロでどんどんスケールできるが、本業で作ってるプロダクトは限界費用がゼロではない。サプライチェーンがあって、完成品をどこかの倉庫に在庫しておき、注文が入ったら発送しないといけない。価値を届けるいろんなステップで物理的な制約が挟まり、製品がめっちゃ人気になっても需要を満たす分だけの供給を行うことができない。なのでソフトウェアの特性を活かせないビジネスということになる。

D2C のビジネスがこれに当たると思う。 D2C というと一見、テクノロジースタートアップ的な雰囲気があるが、物理的な制約が足枷となるビジネスなのは注意した方が良い。価値の源泉が本業の物理的な製品にあるので、ソフトウェア開発者の位置付けは低くなる。物理的な製品の開発部門とマーケティング部門の権限の方が強く、報酬もそういった部門の方が高いはずだ。

さらに言うと、 EC のシステム自体は枯れた技術なので、 Shopify とか STORES とか BASE みたいな EC サイトを構築するための汎用的なシステムが存在していて、こういう仕組みで代替することも可能だ。開発しているソフトウェアの対象領域が EC でなかったとしても、例えば労務管理とか給与計算とかだったりしても、いまは SmartHR とか freee のような SaaS があるので依然として置き換えのリスクはある。

なので本業がソフトウェア開発ではない会社にエンジニアが就職するのは結構危ないと思う（よっぽど独自性の高いシステムを開発する場合を除く）。入社してもおそらく二級市民扱いだ。おすすめ度は★☆☆。

ソフトウェア自体が価値を生み出すビジネス

物理的な製品を仕入れたり開発して売ることが主ではないビジネスだ。アメリカのテックジャイアントは全てこれにあたる。 Google や Apple はスマートフォン、 Meta （ Facebook ）は Meta Quest などを売っているじゃないかと思われるかもしれない。しかし彼らはデバイスを売るのが本業ではなく、 Google や Meta であればデバイスを経由した広告収入、 Apple であれば App Store でのサービス収益がかなり大きい。 Apple は最近、サービス部門の利益がデバイス販売（ iPhone など）の利益を超えたと発表している。

Apple’s Profits From Services Are on the Cusp of Surpassing Its Profits From Device Sales

Apple’s success with services is no more a distraction from their core business than their success with their own chain of retail stores has been.

daringfireball.net

日本だとソシャゲの会社やメルカリのような、物理的な製品を作って売るのではなく、ソフトウェア自体が売り物である会社が良い。 LINE もそうだ。ネットで調べれば分かるがこれらの会社は給料が良い。ソフトウェア開発者の待遇も決して悪くないだろう。価値の源泉がソフトウェアにあるからだ。

もうわかると思うが、このタイプのビジネスが最もソフトウェアの特徴を生かしている。規模の拡大が容易で、どんどん規模を大きくして利益を出すことができる。物理的な制約がビジネス成長のボトルネックになることがほとんどない。

デメリットを挙げるなら、これらの会社は人気企業なので入るのが難しいということだ。創業初期なら入りやすいかもしれないが、将来有望な会社を見つけること自体が極めて難しいし、いわゆるスタートアップ的な環境に耐えられる人でないと続けられないだろう。理不尽にも思える方針変更が頻発するし、初期のスタートアップはお金がなくて人手が足りないので、オフィスの掃除を自分たちでやったり、ユーザーサポートをエンジニアがやったりしないといけない。かつてドワンゴのエンジニアがユーザーイベントで焼きそばを作らされて炎上していたが、あれしきに耐えられない人はスタートアップには向いてない。ああいうのがいやなら最初から GAFAM を目指そう（入るのが超難しいけど）。

おすすめ度は★★★で最もおすすめ。

まとめ

いろいろ書いたが、同じソフトウェアを作る仕事でもソフトウェアビジネスの特徴を生かせるものとそうでないものがあるということを覚えておいてほしい。当然、特徴を生かせる仕事の方がおすすめだ。

おすすめの順で整理するなら以下だ。

1. 自社開発: ソフトウェア自体が価値を生み出すビジネス
2. 受託開発: 他の会社のためにソフトウェア開発を行うビジネス
3. 自社開発: 業務効率化のためにソフトウェア開発を行うビジネス

冒頭にも書いたとおり IT 業界では転職は日常茶飯事なので、これからソフトウェアエンジニアになろうという人は 2 か 3 の会社で修行をしてから 1 のタイプの会社を目指すのが良いだろう。もちろん有名大学でコンピューターサイエンスを学んでいておっさんに負けないくらいコードを書ける自信がある人は新卒でいきなり 1 の門をたたいても良いだろう。