| @技術/プログラミング

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

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

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

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

ドキュメントでは

= 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 年前だった。

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.8ActionView::Base#initialize に対応させる

| @ブログ

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

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

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

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

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

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

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

| @技術/プログラミング

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

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

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

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

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

動画の 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 の文字起こしをしてブログに書こうとしていたが、未完のまままだ公開できてない。年末年始で書き上げたい。

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

2 月

多良岳から見る雲仙方面の山

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

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

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

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 秒差。

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

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

12 月

会社からの景色

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

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

2025 年の抱負

仕事

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

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

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

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

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

ランニング

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

年間走行距離

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

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

ブログ

2024年のブログ執筆状況

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

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

| @労働

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

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

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

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

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

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

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

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

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

受託開発

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

受託はきついはきついのだが、お金を得るのは比較的簡単だ。お客さんがこういうの作ってほしいと言ってるのを作ればよくて、作ったシステムがどのくらい当たるか(お客さんのビジネスの良し悪し)に収益が左右されることはない。お客さんが大コケしても対価はちゃんと支払われるし、お金がもらえるまでの期間が短い。スタートアップなんかだと黒字化するまでに 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 など)の利益を超えたと発表している。

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

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

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

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

まとめ

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

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

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

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

| @散財

2024 年買って良かったものをつらつらと。

Kindle Paperwhite

Kindle Paperwhite

動作が速くてビックリ。これまで使っていた 2020 年のモデルは動作がもっさりしていて線を引くことすら難しかったが、 2024 年のモデルはキビキビ動く。また 2020 年モデルはバッテリーの減りが早く、あまり使っていないのに読もうと思って開いたらバッテリー切れになっていることが多かった。しかも充電が micro USB というのがイライラした。充電端子が USB-C になり、ケーブルの問題とバッテリー持ちの問題が同時に解決されて満足。

今回、初めて純正ケースも買ってみたけどなかなか良かった。バッグに入れてるといつの間にかスリープが解除されててページが移動したりバッテリーが減ってることもあったがそれがなくなった。液晶も傷つかない。

Kindle Paperwhite ケース

おおむね気に入っているが値段に関しては不満が大きい。 10 年前に買った初代 Kindle Paperwhite は 7800 円だったのに今回のは 30000 円近くしたので 4 倍近く値上がりしてるのにはちょっと閉口。比較的発売されたばかりなのに 1 月 3 日からの初売りで 5000 円引きになるらしい。この前のプライムデーでもセールしてたしやっぱり値付けが高すぎるのだと思う。

Apple Watch Series 10

Apple Watch Series 10

Series 6 からの買い換え。 Ultra も持ってるけどこっちはドナドナすることに。 Ultra は重すぎてランニングで使うにはしんどかった(登山では良いと思う)。

実は今年 COROS の Pace 3 も買っている。 Pace 3 は軽くて電池持ちよくて GPS の精度が高いのもよいが、ランニング時に取れるメトリクスが Apple Watch よりも少ない。具体的には Ground Contact Time (接地時間)と Vertical Oscillation (上下動)が取れない。これらを計測するためには追加で COROS Pod を買わないといけない。

センサーの性能や Apple Pay とか音楽再生のコントロールとか日常生活での利便性を加味するとやっぱり Apple Watch が最強。シリアスに走るとき(マラソンのレースとか、 30km 走とか)やトレランのレースでどうしても Apple Watch だとバッテリーが足りなくなることが想定される際には COROS を使うが、普段は Apple Watch で問題なし。

TAZO ORGANIC CHAI

TAZO ORGANIC CHAI

会社でサンプル品のチャイのティーバッグをもらって飲んだらうまかったが、自分で買うには値段が高すぎて買えなかった(ティーバッグ一つあたり 280 円くらいする)。代わりになるものを探していて、ハーブティーといえば TAZO だなと思って調べてみたら何といまは TAZO は日本国内では取扱がないようだった。 20 年以上前、自分がアルバイトしていた頃のスターバックスのお茶は TAZO だったのだが、スターバックスは傘下に収めていた TAZO を手放したらしい。

仕方なく楽天で探したらアメリカから発送してくれる会社があった。それでもティーバッグ一つあたり 80 円くらいするので結構高い。でも味は期待通りだった。

ちなみに TAZO のティーバッグが切れたので代わりに Amazon で安く売られていた他のチャイを試してみたら、香りが薄くてイマイチだった。 TAZO のやつの方が生姜とスパイスの香りがガツンときてうまい。高いとは思いつつも引き続き楽天で TAZO のやつを追加購入した。

Patagonia エアシェッドプロプルオーバー

Patagonia エアシェッドプロプルオーバー

ウィンドシェルと化繊シャツのハイブリッドみたいな素材のプルオーバー。胴体はナイロン生地、腕とフードの部分はポリエステルの化繊(キャプリーンクールライトの生地)。防風性と通気性のバランスが絶妙。値段は高い(ウィンドシェルのフーディニジャケットよりも高い!)がめっちゃよい。

冬のランニング、着るものが難しい。化繊シャツの上にウィンドシェルを着ると途中で暑くなって脱がなければならずかさばる。エアシェッドプロプルオーバーは最初から最後まで着たまま走れる。暑くなったら胸のダブルジップのところを開ければ換気できるし、袖は伸縮性があるので簡単に袖まくりできる。ドライレイヤーのシャツの上にエアシェッドプロプルオーバーを着て体感気温1℃の大濠公園を走ったがちょうど良かった。

Smartwool のメリノビーニー

Smartwool メリノビーニー

ランニングとかトレラン用の薄手のニット帽。冬のランニングは耳が痛くなるのでニット帽がないと厳しいが、厚手のやつは暑い。薄手のビーニーだとちょうどよい。ふんわりした被り心地も優しくてよい。値段も 3000 円くらいで良心的だった。唯一残念なのは薄いグレーを買ったので汗が目立つこと。頭が禿げてて頭皮が剥き出しだからかもしれない。