| @労働

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

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 円くらいで良心的だった。唯一残念なのは薄いグレーを買ったので汗が目立つこと。頭が禿げてて頭皮が剥き出しだからかもしれない。

| @雑談

天山食堂

しばらくブログを書いてなくてなんか執筆のエンジンがかからないのでただの日記でも。

運転免許の更新だった。今回、 10 年ぶりにゴールド免許に復帰できたので南区の試験場まで行かずに済んだ。最近、渡辺通のサンセルコから千代に移動してきた県の合同庁舎内にある千代ゴールド免許センターに行った。

千代県庁口駅は地下鉄空港線沿線ではなく、中洲川端で貝塚線に乗り換えないといけない。なので遠くはないがちょっと行くのが面倒だ。

駅に着いて合同庁舎まで 3, 4 分歩く。千代の街にはほとんど来ない。福岡市民は天神のアクロスでパスポートが取れるので、県庁に来ることも基本的にないんじゃないだろうか。

合同庁舎前に着くと懐かしい感じの名称が。以前博多駅の筑紫口にあって、勉強会でよく通っていた福岡県Ruby・コンテンツ産業振興センターがここに移動してきていた。免許の更新が目的ではあったがRubyコンテンツセンターの看板をパシャリと撮った。

福岡県Ruby・コンテンツ産業振興センター

ゴールド免許センターは二階だった。優良講習は事前予約制で、予約したときに表示される QR コードを保存して持ってきて端末にかざさないといけない。 QR コードをキャプチャして Fantastical に保存していたのに表示されなくて焦る。 Fantastical の iPhone アプリは添付ファイルを開けない仕様だったのを思い出した。 iOS 標準カレンダーは添付ファイルを開けたが、今度は電波のつながりが悪くてなかなか画像が表示されない。自分が端末を操作する直前になって画像が読み込まれ、 QR コードを無事機械に読み取らせることができた。高齢の人にはこれは難しいだろう。事実、年寄りの人には係員の人がずっと付き添っていて渋滞していた。

優良講習の内容はいつもの内容に加えて、最近は電動キックボードが制度として組み込まれたことと、自転車のヘルメット着用が努力義務化されたことを伝えられた。前の人の頭が邪魔であまり映像がよく見えず集中できなかった。

講習が終わって新しい免許証を受け取ってもまだ 10:20 くらいだった。仕事は午後からやろうと決めていた。渡辺通のゴールド免許センターだったら講習後に寄れる店がいくらでもあるけど、千代はなかなか店がない。朝は急いでいて朝食を抜いていたのでお腹がすいている。どこか入ろうと思ったが時間が中途半端すぎる。合同庁舎の横にスターバックスがあったので、そこに入ってとりあえず時間を潰せばよかったのに、火と人という西部ガスがやってそうなレストランが気になり駅に戻ったら、ランチは 11 時からでまだ食事はできなかった。いよいよ店に入るには中途半端な時間になった。せっかく来たのだからと店名が気になった天山食堂という食堂に行くことにした。 Google マップで写真を見ると実に店構えがいい。 15 分前に店に着いたのでコンビニ行ってコーヒーを買って時間を潰す。千代のローソンはすさんでいて、ゴミ箱は持ち込みゴミ禁止の警告がペタペタと貼られ、ゴミ箱の投入口は木の板を貼られて加工され、小さなゴミしか捨てられなくなっていた。監視カメラ撮影中と至る所に掲示があったが、どこにも監視カメラは設置されてなさそうだった。カフェラテを買って車止め柵にもたれかかった飲む。朝は紅茶しか飲んでなかったので初めてカロリーを摂取する。寒かったのでほっとする。

コーヒーを飲み終わると 11:00 になっていたので天山食堂へ移動する。自分の前に一人先客がいて二番目だった。場所柄、韓国風の店なのかと思っていたが、店内は普通の和食の店という感じ。メニューに韓国風のものは豚キムチくらい。天山はきっと韓国の山の名前なのではないかと思っていたが、そうではないようだった。佐賀にゆかりがある人がやってる店なのかもしれない。

天山食堂のメニュー

Google マップや Instagram の投稿を見ると、焼肉定食を頼んでご飯をチャーハンに変更するのが通の頼み方のようだが、裏メニューでメニューに書いていないものを一見の客が頼むのは気恥ずかしく、普通に焼肉定食を頼んだ。比較的すぐ出てきた。付け合わせの野菜炒めがとてもうまかった。厨房でガコンガコンと中華鍋を振る音が聞こえたので本格的に炒めてあるのだと思う。ラードで強火を使い短時間で炒めてあり、野菜はシャキシャキしていた。肉は甘辛い味付けで、昔ながらの家で食べる焼肉という感じだった。小鉢の冷や奴が印象に残っている。豆腐の上にネギと鰹節がかかっていた。味噌汁もちゃんとだしをとったやつでうまかった。これで 800 円。最近は福岡も外食の値段が上がっているので、ほとんど手作りでこの値段は安い。 Google マップを見ると以前はもっと安かったみたいだ。

天山食堂の焼肉定食

分量もちょうど良く、食べ終えてあたたかいお茶を飲み、店を出た。ここから歩いて呉服町までも行ける。呉服町は以前のオフィスがあったところなので行ってみるのも一興だったが、午後の仕事が気になったのでおとなしく千代県庁口駅まで戻って地下鉄を乗り継いで会社へ向かった。孤独のグルメのような一日だった。

| @登山/ランニング

Outdoor Running - Sunday, November 10, 2024.jpg

大学は浪人し、就職も浪人し、サブフォーも一年浪人してなんとかギリギリ達成した。先日行われた福岡マラソン 2024 でフルマラソンを 4 時間以内(ネットタイム)でゴールすることができた。

ふりかえり

スタート

去年は自己申告の完走予想タイムをだいぶ遅い時間で出してしまったために、スタートブロックが後ろの方だった。今回はタイム申告をちゃんとやってスタートブロック D に入れてもらえた。 D ブロックに入ったおかげか、スタート待ち時間は短くて済んだ。去年、 G ブロックだったときは号砲が鳴ってからスタートラインを通過するまで 9 分経過していたが、今回は 2 分で通過できた。

サブフォーを自己申告している集団なので周りが遅すぎるということはなく、ちょうどよい感じで走ることができた。ただ、サブフォーのグループだと若干ペースが速すぎるかも。今回も前回同様にネガティブスプリットを狙っていたが、回りにつられて前半少し飛ばし気味になって後半の足つりの遠因になったのではないかと思う。

中盤

スタートから 10km 地点までは時々ペースが 5 分 20 秒台になってしまうのをおさえながら走った。それでも 5 分 40 秒を切っており、想定だと最初の 5km は 5 分 50 秒台で行くつもりだったので最初から速すぎた。ただ、前半の貯金のおかげで最後は助けられた部分があったので結果オーライだったのかもしれない。

10km 地点でペパボ時代の同僚家族が応援してくれて元気をもらった。知ってる人に応援してもらえるとうれしい。家族は牧のうどん今宿店で応援すると言ってたのに結局いなくて応援してもらえなかった。悲しい。折り返しがある九大方面へとぼとぼ走る。

九大の上り坂は難所だが、このあたりで調子をこいて 5 分 20 秒を切るくらいのペースで走ってしまい、心拍数が 170 を超えるようになってしまった。これはやばいかもとペースを落として心拍数を下げようとするが、 5 分 40 秒くらいで走っても心拍数が 160 台に落ちない。心拍数を落とすことは諦めてそのまま行った。

トイレ問題

毎度頭を悩ませるトイレ問題はスタートブロックに入る前に一回行けたのでひとまずは大丈夫だったが、後半に入ってよおしたのでのらん坂の手前( 30km 過ぎ)で一度トイレに行った。ここでトイレに行く人は少ないので待たずに用を足すことができタイムロスは最小限だったと思う。

のらん坂と足つり

坂の前でトイレに寄ったことで心拍が落ち着き、坂は止まることなくテンポ良く登れた。サブフォーペースの人たちでものらん坂は歩いてる人が結構多かった。トレランやってたらこのくらいの坂はなんともない。

しかし、坂を登りきって下りに入ったところで左のハムストリングスがピキピキし始めた。心肺的には全然しんどくないつもりだったが足には来てたのかもしれない。給水をあまり取ってなかったのも影響してそう。去年より暑かったのでもっと水を飲むべきだった。

終盤

のらん坂のあとは二見ヶ浦、桜井にかけてはゆるやかな登りと下りを繰り返すのでピキピキがぶり返す。去年は 35km 過ぎで最速ラップを刻んでたのに、それをやろうとすると足がつりそうになる。そんなときウエストパーク練(福岡市の西公園を朝から走ってるトレラン寄りのランニンググループ)の皆さんが応援してくださって元気出た。名前を呼んで応援してもらえるのはとてもうれしい。今回、家族の応援はなかったのでなおのこと。

32km を過ぎて残り 10km になったところでタイムはちょうど 3 時間くらいだったので、論理的にはここからキロ 6 分で行ってもサブフォーできる。足がピキピキしてたのでキロ 6 分近くまでペースを落とそうかなと思ったが、何があるかわからないので足がつりそうになる登り坂以外は極力 5 分 40 秒くらいのペースを維持した。そしたら案の定、残り 4km でピキピキが激しくなり、止まってストレッチをする羽目に。

結局最後は全く余裕がなく、ゴール前のストレートは足をつりそうになりながら執念のスパートをかけてネットタイム 3:59:52 でゴールした。ちょっとでも気を抜いてたら 4 時間超えてたと思う。ギリギリ中のギリギリだった。時計の距離と公式の距離が違うのも盲点。時計の距離よりも公式の方が短く書かれてる(つまり時計では 42.4km くらいになる)ので、その意味でも下手に手は抜かない方が良いと思った。サブフォーイーブンペースの 5 分 41 秒ペースで 100m 走ると 34 秒かかるので、 200m 誤差があると仮定するなら 1 分くらいは余裕を持っておいた方が良い。

補給

前日受付のコイケスポーツの露店でモルテンの完走セット(ドリンクミックス × 2 、ジェル × 2 )を買った。

前日夜にモルテンのドリンクミックスと Mag-on 顆粒、 MAGMA を飲んでから寝て、当日朝起きてから Mag-on 顆粒を飲み、バナナ一本とサンドイッチを食べ、移動の電車の中でモルテンのドリンクミックスを飲んだ。

熊本城マラソンのときの経験からモルテン完走セットだけではハンガーノックを起こすとわかっていたので、 Mag-on のジェル 2 個とアミノバイタルの青も携帯。 10km ちょいで Mag-on をとり、 17km でモルテンのノンカフェインジェル、 23km あたりでアミノバイタル青、 32km あたりでモルテンのカフェイン入りジェル、 38km あたりで最後の Mag-on を摂った。今回はハンガーノックはなし。補給食は梅飴と塩タブレットを一つずつもらって食べた。暑かったので塩タブレットは水とともにもっとたくさん摂ってた方が良かったかもしれない。

ギア関係

シューズは昨シーズンの熊本城マラソンに合わせて買った Magic speed 2 を使った。 NIKE のズームフライ 6 が気になっていたが、とりあえず持ってる靴を履き潰すまでは我慢することに。 Magic speed 2 はかなり靴擦れするのが心配なのだが、今回はドン引きするくらいテングバームを塗り込んでいたおかげでひどい靴擦れにはならなかった。

スタート前の寒さ対策ではゴミ袋に穴を開けて被った。今年は去年ほど寒くなかったのでいらなかったかもしれないが、精神的な安心感が違う。次のレースでもやろう。

ウェアは Teton Bros. の ELV1000 のノースリーブにパタゴニアのストライダープロショーツ。補給食は全部ショーツのポケットに入れて走った。昨年同様、 Rush Hip などは着けなかった。全く問題なし。

防寒対策兼ねて腕には Goldwin のアームカバーを着けたが、 35km 地点くらいで暑くなり外した。カーフガードはなんとなく着けなかった。かわりにニューハレの V テープをふくらはぎに貼っていたが貼り方ミスってあまり効果なかったかも。

ゼッケンは Inner Fact のゼッケンベルトにつけた。 PayPay ドームリレーマラソンに出たときに安全ピンでゼッケン付けたらキャプリーンに穴が空いたのが悲しすぎる。ゼッケンベルトでも全然走りにくさはなかった。かなり上の位置で止めるのがポイント。

今回、サングラスを忘れてしまったが、曇りだったのでなくても問題なかった。ラッキー。

去年同様、 iPhone は置いて走った。去年は無一文だったので何かあったときに帰る方法がないなと心配になったので一万円札とクレジットカード一枚だけストライダープロショーツのポケットに入れて走った。 Exped のビスタオーガナイザー便利。

練習・コンディション

去年は 30km 走を福岡マラソンのコースの後半で 2 回やったが、今年は暇がなく大濠公園で 30km 走を一度やっただけだった。 30km 走は 20km までしか足が動かず心配だったが、本番では足は大丈夫だった。

スピード練習は去年はもっぱらインターバル走だったが、今年は LT 走に切り替えた。高い心拍数で 20 分ねばる練習は持久力向上の効果がありそうだ。 20km 以降が心拍数 170 越えでもなんとかなったのは、 LT 走で乳酸性作業閾値が高くなってるのではないかと思う。

そしてもっともでかいのが減量。去年は 70kg ちょいあった体重を、カーボローディングする前の状態で 66.2kg まで落とした。当日の朝は爆食いにより 68kg くらいあったが、それでも去年より 2kg は軽い。体重を 1kg 落とすとマラソンのタイムが 3 分縮まると言われている1が、その通りになった。

総じて

去年の所感でも書いたが、マラソンはギリギリペースを刻んでいてもギリギリタイムでの目標達成は難しい。トイレ、給水、足つりなど想定外の出来事が起こるから。なので 10 秒ずつくらいはギリギリペースよりも速いペースで刻めるようになっておく必要があると思う。今回、前半は図らずも早めのペースで走らされたが、その貯金のおかげでなんとかサブフォーできた。もしネガティブスプリット狙いで前半に貯金がなければサブフォーは達成できてないと思う。

データ比較

スプリット

スプリット 2023年

スプリット 2024年

2023 年は後半にペースを上げるネガティブスプリットだったが(小出監督の本でよい走り方とされている)、 2024 年はポジティブスプリット(後半にペースが下がるあまりよくない走り方)になってしまった。 20km の地点で去年よりも 5 分早く、最も貯金があった 30km の地点ではサブフォーイーブンペースと比べて 2 分 44 秒の貯金があった。 30km から徐々に貯金を切り崩す形になり、 35km で貯金は 1 分 24 秒に。 40km 地点では貯金は 28 秒まで減っていた。こうしてみると薄氷のサブフォーだったことがうかがえる。

心拍数

心拍数 2023年

心拍数 2024年

心拍ゾーン 2023年

心拍ゾーン 2024年

心拍数は去年よりも余裕がない。ゾーン 3 で走ってる時間が去年は 40.8% だったのに対して、今年は 18.1% しかない。 77.7% の時間をゾーン 4 で走っている。去年はゴール前のスパートをかけるまで心拍数が 170 台に上がることはなくずっと 160 台で走れていたが、今年は 20km を過ぎたあたり(九大の上り坂)で心拍数が 170 を超え、その後ずっと 170 台のままゴールまで行ってしまった。

前半のペースが去年よりも速いことと、去年に比べ 5 度以上気温が高いことが影響していそうだ。去年は前半を 5 分 40 秒を超えるペースで走っていた。一方で今年は前半を 5 分 40 秒を下回るペースで走っている。 10 秒くらいは今年の方がペースが速い。去年は 5 分 30 秒で走るのは結構きつかったが、今年は 5 分 30 秒で走ってもそこまでしんどくはなかった。ほどよいペースという感じ。 5 分を切るくらいのペースでLT走をしていた効果が出ていそうだ。

天気

天気 2023年 天気 2024年
2023年と2024年の天気

去年はスタート前だいぶ寒かった。アメダスのデータを見ると、何とスタートしてから気温が下がっていたようだ。スタート前は寒かったが 10 ℃台前半の気温は走りやすそうだ。去年、心拍数を低く抑えられたのは気温のおかげもあるだろう。

一方で 2024 年は気温が高い。ゴールする頃は 20 ℃近くになっていた。足つりの原因はこれだと思う。去年はつりそうでギリギリつらなかった。

総括

ギリギリではあったが、またネットタイムではあるがサブフォー達成できて一安心。今年は仕事が忙しくて去年より走れてなかったので心配だったが、 5 分ちょいタイムを縮めることができた。引き続き頑張っていきたい。

来月も青島太平洋マラソンに出るので記録更新したい。そして来年 2 月の熊本城マラソンで雪辱を果たしたい。

サブフォー達成の瞬間
去年よりもさらに必死の形相でゴールに駆け込む著者

  1. 福大の先生だった田中宏暁先生(故人)の本に書いてある 

| @労働

新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。

1. システム構成図を描く

どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。

2. 誰が何をやるかを明確に

タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。

3. リリース日を決める

リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース日を動かして調整する。

4. 確認環境・デモ環境を作る

ローカルではなく、本番と似た環境で動作確認できる環境をまず作る。ローカルで動いたけど本番で動かないをなくす。本番サイトを非公開にできるならリリース前からガンガンデプロイしてもいい。CSSが当たってなかったり、APIがモックでもいい。動くものを関係者間で共有し、早い段階でイメージのズレを補正することが超重要。

CI/CD の仕組みまで初期に整えておけるとなおいい。

5. リスクの高いところから開発する

システムの処理の中で重要かつ難易度が高い、もしくは実現できるかわからない(不確実性が高い)部分から開発する。簡単なところから先にやって不確実性(リスク)の解消を先送りにするのは超危険。

6. APIのJSONのフォーマットを先に決める

こうしておくことでバックエンドとフロントエンドがパラレルで開発できるようになる。誰かの作業が進まないと他の人の作業が進まないというような依存関係を作らない。

7. コードはこまめにリポジトリにプッシュ

他の人が作業状況をわかるようにする。小さくプルリクエストを作ってマージしていくとかは今更言わなくても常識ですよね?

8. 朝会か夕会をやる

超ラフにコミュニケーションしてお互いの進捗を共有する。可能ならオフラインで話す。一緒に寿司を食べるのも効果的。


↑は作るものが決まってからの話なので、作るものが合ってるか(正しいか)はまた別の話(プロダクトマネジメント)。

| @Mac/iPhone

iA Writer

iPad Air を買ったことで iPad で文章を書くときに何を使うか考え始めた。 iOS と iPad で iA Writer は同一アプリとなっているようで、 iPhone 用に買った iA Writer をそのまま iPad Air でも使うことができた。

iPad Air で iA Writer を使ってみて、ファイル管理っぽい機能があることに初めて気が付いた。 iOS では小さく表示されるのでそんな機能があることに気がつかなかった。それで Mac 版を試してみたところ結構良かったので、ブログなどの文章書きを Vim から iA Writer に乗り換えることにした。

iA Writer は iPhone では 6 年くらい前から使ってる。その頃は 1200 円くらいで買えたがいまはめっちゃ値上がりしてて 8000 円もする1( iPhone 用アプリで 8000 円ですよ!)。ドルベースの価格も上がっているが円安が効いていて高くなっている(ドルでの価格は 49.99 ドル)。

iA Writer for iOS は電車の中で文章を編集するのに使ってた。通勤してた頃、混んだ電車の中でパソコンを取り出せず、 iPhone の iA Writer で Vim で書き起こしたポエムの続きを書いたりしてた。

まぁまぁ便利だったのだが、やっぱりスマートフォンのキーボードでは書きづらいしまぁこんなもんかなぁと思いながら、どうしても iPhone で文章を編集したいときだけ起動するような使い方をしていた。

iPad Air で iA Writer を使ってみて、ファイル管理っぽい機能があることに初めて気が付いた。

iA Writer のファイル管理機能

スマートフォルダという機能もあって、バラバラに散らばったファイルをいい感じに整理できることにも気が付いた。 Apple Music のスマートプレイリストみたいな機能だ。 macOS の Finder の機能を転用してるのだと思う。

iA Writer のスマートフォルダ

"メモを取り、書き、編集するための集中できる環境。それ以外には何もありません。"

iA Writer のウェブサイトではフルスクリーン表示できて文章を書くことに集中できることをウリにしているが、自分にとってはファイルを一覧表示・管理できる機能(ファイラー)がめっちゃ便利だと思った。これまで Vim + memolist で書いた文章は一定期間経過したら Day One に取り込みつつ、年ごとアーカイブ用フォルダーを作って Ruby スクリプトでそこに待避していたが、そんなことをする必要なく iA Writer だけでファイルの管理ができてしまう(サブディレクトリに移動させたいファイルをドラッグ&ドロップで移動させればよい)。

Day One のカレンダーで過去の記事を見られる機能は便利だが、Day One はプレーンテキストを捨てて Markdown ベースの独自仕様リッチテキストに移行してしまったし、起動に時間がかかるのも微妙だと思っていて、シンプルにプレーンテキストのファイルとして管理できる iA Writer の方がよい気がしてきた。

Day One のカレンダー UI

iA Writer の良いところを列挙するとこんな感じ。

  1. 起動が速い
    起動してすぐ書き始められる
  2. ファイル管理機能
    Finder とテキストエディターが統合されたような使い勝手
  3. クイック検索
    Vim の Unite 検索のような機能があり、めっちゃ素早く対象のディレクトリ以下のファイルを検索できる

これまで Vim を使い続けてきたのは Unite での検索が便利すぎたからだった。メモ書きディレクトリに移動してテキトーに Vim を起動して UniteGrep すれば書きかけのファイルをぱっと探せる。

iA Writer には UniteGrep と似たクイック検索という機能があって、しかもショートカットで検索 UI を呼び出せるところが良い( + + o)。

iA Writer のクイック検索

Day One にも似たような検索機能はあるものの、検索窓を呼び出すショートカットがない。いちいちマウスカーソルを動かして🔍マークをタップしないと検索できない。検索窓はマウスやトラックパッドに手を持ち替えることなく表示されないとダメだと思う(一つ前の記事参照

デバイス間のファイル同期は iCloud を使っている。複数の端末で同時に開いてもコンフリクトが起こることはほぼなくファイルが同期される。敬虔な Apple 信者でいる限りファイルの同期のために Evernote や Notion を使う必要はない。

いまは Obsidian や Roam Research のような新手のソフトもあるようだが、自分の場合は iA Writer で満足している。使っていないが Wiki Link 記法も使えるのでファイル同士の繋がりを作ることもできるようだ。

職業プログラマーになって以来、テキストエディターは Vim 一択だろうという気持ちでいたが、 GUI でファイル検索・管理できるという一点で iA Writer を気に入ってしまった。コードを書くならいまでも Vim が良いが、ブログの文章や個人用メモは完全に iA Writer に乗り換えてしまった。世間的に大人気な Notion を使っていたらこのようにエディターを他のものに乗り換えることはできなかったのでプレーンテキスト万歳だ。


ピアソン版の『達人プログラマー』に GUI のファイル検索だと目的のファイルが見つかるのに時間がかかるので grepfind でファイルを探す方が高速だ、という記事がある(第3章)。 Unix 哲学的な話で、小さな機能を持つソフトを組み合わせて使う方が効率的だという話だった。 grepfind で検索して xargs -o vim するより、テキストエディターの中で一覧表示出来る方が便利だ。少なくとも普通の人にとっては。何でもシェルでやるのが良いという時代は終わったのかもしれない。

とはいえ iA Writer は macOS の仕組みの上で達人プログラマー的なやり方を継承しているようにも感じる。例えば先ほどのスマートフォルダは macOS の Finder にある機能だ。ひょっとしたら UI が同じだけでまるっきり別の実装がしてあるかもしれないが、 OS や SDK が提供しているシンプルな GUI を組み合わせて便利なものを作るのが今風の達人プログラマーなのかもしれない。


  1. Mac 版は同一ライセンスになっておらず Mac App Store から別途購入する必要がある。 8000 円は高いので一か月くらい悩んで買った。 

| @労働

アプリの使い方がわからないというユーザーがいっぱいいると、「 UI がクソだからに違いない」というご指摘をされることがある。

しかし、アプリの特性上、どうしても使い始めるまでのステップ数が多くなることはあるし、たまにしか使わなくてなかなか使い方を覚えられないアプリもある(自分はいまだに世界で 15 億人以上が使っている Instagram の使い方が覚えられない)。利用頻度が低いせいでなかなか使い方を覚えられないだけなのに、 UI のせいにされてしまって延々 UI を改善すべしとなってしまうとつらい。

継続率を限りなく上げるべしというのも危険。『ネットワーク・エフェクト』という本で「ユーザーの 8 割は離脱する」と書いてあった。

テクノロジーブログ「テッククランチ」に「ユーザーの約4人にひとりは、アプリを1回利用しただけで離脱している」という記事が掲載された。3万7000人分のデータを調べたところ、多くのユーザーは1回試しただけで使うのをやめていたという。残念ながら、私が実施した調査でも同様の結果だった。私はグーグルプレイの元プロダクトマネジャーであるアンキット・ジェインとともに「モバイルユーザーの80%を失うのは普通」という記事を書いている。 — アンドリュー・チェン『ネットワーク・エフェクト』

でも継続率が 2 割しかないと聞いて「けしからーん」と怒る人たちがいて、継続率を限りなく 100% に近づけろという話になったりする。「けしからーん」と言ってる当人だってインストールしたアプリ全部を毎日は使ってないはず。毎日使うアプリは LINE とか Instagram とかマンガアプリとか PayPay くらいじゃないだろうか。

分析調査会社混むスコアのデータによると、人々はたった3つのアプリに80%の時間を費やしている。 — アンドリュー・チェン『ネットワーク・エフェクト』

現実的な観点で継続率とか利用率の目標を置けたらいいけど、割と勘とか理想論で数値目標が決まったりする。絶対達成できない目標掲げて仕事するのめっちゃつらいので、まずは現状の利用状況調べて妥当な目標を設定するべきだと思ってる。むしろアプリを使う全ユーザーにこちらがやってほしい行動をやらせようとするのは虫がよすぎるというか、傲慢なのではないか。

ユーザーすべてが作り手と同じような頻度、気持ちでアプリを使ってくれる訳じゃないことを前提とした上で UI とか継続率は考えていけたらいいと思う。絶対に一人も脱落させない UI やオンボーディング体験を作ることは難しい。