写真でふりかえる 2025 年 2 月
ソフトウェア開発者の職探し指南
ソフトウェア開発者(エンジニア、デザイナー)の働き口は大きく分けて二種類あると思う。一つは受託開発の会社で、もう一つは自社開発の会社だ。これまで受託開発の会社は避けた方が良いと感じていたが、実は自社開発の会社も二種類に分類でき、ソフトウェアの強みをいかせる業種とそうでない業種があることに気がついた。
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 を目指そう(入るのが超難しいけど)。
おすすめ度は★★★で最もおすすめ。
まとめ
いろいろ書いたが、同じソフトウェアを作る仕事でもソフトウェアビジネスの特徴を生かせるものとそうでないものがあるということを覚えておいてほしい。当然、特徴を生かせる仕事の方がおすすめだ。
おすすめの順で整理するなら以下だ。
- 自社開発: ソフトウェア自体が価値を生み出すビジネス
- 受託開発: 他の会社のためにソフトウェア開発を行うビジネス
- 自社開発: 業務効率化のためにソフトウェア開発を行うビジネス
冒頭にも書いたとおり IT 業界では転職は日常茶飯事なので、これからソフトウェアエンジニアになろうという人は 2 か 3 の会社で修行をしてから 1 のタイプの会社を目指すのが良いだろう。もちろん有名大学でコンピューターサイエンスを学んでいておっさんに負けないくらいコードを書ける自信がある人は新卒でいきなり 1 の門をたたいても良いだろう。
免許更新&天山食堂
しばらくブログを書いてなくてなんか執筆のエンジンがかからないのでただの日記でも。
運転免許の更新だった。今回、 10 年ぶりにゴールド免許に復帰できたので南区の試験場まで行かずに済んだ。最近、渡辺通のサンセルコから千代に移動してきた県の合同庁舎内にある千代ゴールド免許センターに行った。
千代県庁口駅は地下鉄空港線沿線ではなく、中洲川端で貝塚線に乗り換えないといけない。なので遠くはないがちょっと行くのが面倒だ。
駅に着いて合同庁舎まで 3, 4 分歩く。千代の街にはほとんど来ない。福岡市民は天神のアクロスでパスポートが取れるので、県庁に来ることも基本的にないんじゃないだろうか。
合同庁舎前に着くと懐かしい感じの名称が。以前博多駅の筑紫口にあって、勉強会でよく通っていた福岡県Ruby・コンテンツ産業振興センターがここに移動してきていた。免許の更新が目的ではあったがRubyコンテンツセンターの看板をパシャリと撮った。
ゴールド免許センターは二階だった。優良講習は事前予約制で、予約したときに表示される QR コードを保存して持ってきて端末にかざさないといけない。 QR コードをキャプチャして Fantastical に保存していたのに表示されなくて焦る。 Fantastical の iPhone アプリは添付ファイルを開けない仕様だったのを思い出した。 iOS 標準カレンダーは添付ファイルを開けたが、今度は電波のつながりが悪くてなかなか画像が表示されない。自分が端末を操作する直前になって画像が読み込まれ、 QR コードを無事機械に読み取らせることができた。高齢の人にはこれは難しいだろう。事実、年寄りの人には係員の人がずっと付き添っていて渋滞していた。
優良講習の内容はいつもの内容に加えて、最近は電動キックボードが制度として組み込まれたことと、自転車のヘルメット着用が努力義務化されたことを伝えられた。前の人の頭が邪魔であまり映像がよく見えず集中できなかった。
講習が終わって新しい免許証を受け取ってもまだ 10:20 くらいだった。仕事は午後からやろうと決めていた。渡辺通のゴールド免許センターだったら講習後に寄れる店がいくらでもあるけど、千代はなかなか店がない。朝は急いでいて朝食を抜いていたのでお腹がすいている。どこか入ろうと思ったが時間が中途半端すぎる。合同庁舎の横にスターバックスがあったので、そこに入ってとりあえず時間を潰せばよかったのに、火と人という西部ガスがやってそうなレストランが気になり駅に戻ったら、ランチは 11 時からでまだ食事はできなかった。いよいよ店に入るには中途半端な時間になった。せっかく来たのだからと店名が気になった天山食堂という食堂に行くことにした。 Google マップで写真を見ると実に店構えがいい。 15 分前に店に着いたのでコンビニ行ってコーヒーを買って時間を潰す。千代のローソンはすさんでいて、ゴミ箱は持ち込みゴミ禁止の警告がペタペタと貼られ、ゴミ箱の投入口は木の板を貼られて加工され、小さなゴミしか捨てられなくなっていた。監視カメラ撮影中と至る所に掲示があったが、どこにも監視カメラは設置されてなさそうだった。カフェラテを買って車止め柵にもたれかかって飲む。朝は紅茶しか飲んでなかったので初めてカロリーを摂取する。寒かったのでほっとする。
コーヒーを飲み終わると 11:00 になっていたので天山食堂へ移動する。自分の前に一人先客がいて二番目だった。場所柄、韓国風の店なのかと思っていたが、店内は普通の和食の店という感じ。メニューに韓国風のものは豚キムチくらい。天山はきっと韓国の山の名前なのではないかと思っていたが、そうではないようだった。佐賀にゆかりがある人がやってる店なのかもしれない。
Google マップや Instagram の投稿を見ると、焼肉定食を頼んでご飯をチャーハンに変更するのが通の頼み方のようだが、裏メニューでメニューに書いていないものを一見の客が頼むのは気恥ずかしく、普通に焼肉定食を頼んだ。比較的すぐ出てきた。付け合わせの野菜炒めがとてもうまかった。厨房でガコンガコンと中華鍋を振る音が聞こえたので本格的に炒めてあるのだと思う。ラードで強火を使い短時間で炒めてあり、野菜はシャキシャキしていた。肉は甘辛い味付けで、昔ながらの家で食べる焼肉という感じだった。小鉢の冷や奴が印象に残っている。豆腐の上にネギと鰹節がかかっていた。味噌汁もちゃんとだしをとったやつでうまかった。これで 800 円。最近は福岡も外食の値段が上がっているので、ほとんど手作りでこの値段は安い。 Google マップを見ると以前はもっと安かったみたいだ。
分量もちょうど良く、食べ終えてあたたかいお茶を飲み、店を出た。ここから歩いて呉服町までも行ける。呉服町は以前のオフィスがあったところなので行ってみるのも一興だったが、午後の仕事が気になったのでおとなしく千代県庁口駅まで戻って地下鉄を乗り継いで会社へ向かった。孤独のグルメのような一日だった。
マラソンサブフォー達成人材になった
大学は浪人し、就職も浪人し、サブフォーも一年浪人してなんとかギリギリ達成した。先日行われた福岡マラソン 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 年はポジティブスプリット(後半にペースが下がるあまりよくない走り方)になってしまった。 20km の地点で去年よりも 5 分早く、最も貯金があった 30km の地点ではサブフォーイーブンペースと比べて 2 分 44 秒の貯金があった。 30km から徐々に貯金を切り崩す形になり、 35km で貯金は 1 分 24 秒に。 40km 地点では貯金は 28 秒まで減っていた。こうしてみると薄氷のサブフォーだったことがうかがえる。
心拍数
心拍数は去年よりも余裕がない。ゾーン 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走をしていた効果が出ていそうだ。
天気


去年はスタート前だいぶ寒かった。アメダスのデータを見ると、何とスタートしてから気温が下がっていたようだ。スタート前は寒かったが 10 ℃台前半の気温は走りやすそうだ。去年、心拍数を低く抑えられたのは気温のおかげもあるだろう。
一方で 2024 年は気温が高い。ゴールする頃は 20 ℃近くになっていた。足つりの原因はこれだと思う。去年はつりそうでギリギリつらなかった。
総括
ギリギリではあったが、またネットタイムではあるがサブフォー達成できて一安心。今年は仕事が忙しくて去年より走れてなかったので心配だったが、 5 分ちょいタイムを縮めることができた。引き続き頑張っていきたい。
来月も青島太平洋マラソンに出るので記録更新したい。そして来年 2 月の熊本城マラソンで雪辱を果たしたい。

-
福大の先生だった田中宏暁先生(故人)の本に書いてある ↩
iA Writer for Mac
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 を使ってみて、ファイル管理っぽい機能があることに初めて気が付いた。
スマートフォルダという機能もあって、バラバラに散らばったファイルをいい感じに整理できることにも気が付いた。 Apple Music のスマートプレイリストみたいな機能だ。 macOS の Finder の機能を転用してるのだと思う。
iA Writer のウェブサイトではフルスクリーン表示できて文章を書くことに集中できることをウリにしているが、自分にとってはファイルを一覧表示・管理できる機能(ファイラー)がめっちゃ便利だと思った。これまで Vim + memolist で書いた文章は一定期間経過したら Day One に取り込みつつ、年ごとアーカイブ用フォルダーを作って Ruby スクリプトでそこに待避していたが、そんなことをする必要なく iA Writer だけでファイルの管理ができてしまう(サブディレクトリに移動させたいファイルをドラッグ&ドロップで移動させればよい)。
Day One のカレンダーで過去の記事を見られる機能は便利だが、Day One はプレーンテキストを捨てて Markdown ベースの独自仕様リッチテキストに移行してしまったし、起動に時間がかかるのも微妙だと思っていて、シンプルにプレーンテキストのファイルとして管理できる iA Writer の方がよい気がしてきた。
iA Writer の良いところを列挙するとこんな感じ。
- 起動が速い
起動してすぐ書き始められる - ファイル管理機能
Finder とテキストエディターが統合されたような使い勝手 - クイック検索
Vim の Unite 検索のような機能があり、めっちゃ素早く対象のディレクトリ以下のファイルを検索できる
これまで Vim を使い続けてきたのは Unite での検索が便利すぎたからだった。メモ書きディレクトリに移動してテキトーに Vim を起動して UniteGrep すれば書きかけのファイルをぱっと探せる。
iA Writer には UniteGrep と似たクイック検索という機能があって、しかもショートカットで検索 UI を呼び出せるところが良い( ⇧ + ⌘ + o)。
Day One にも似たような検索機能はあるものの、検索窓を呼び出すショートカットがない。いちいちマウスカーソルを動かして🔍マークをタップしないと検索できない。検索窓はマウスやトラックパッドに手を持ち替えることなく表示されないとダメだと思う(一つ前の記事参照)
デバイス間のファイル同期は iCloud を使っている。複数の端末で同時に開いてもコンフリクトが起こることはほぼなくファイルが同期される。敬虔な Apple 信者でいる限りファイルの同期のために Evernote や Notion を使う必要はない。
いまは Obsidian や Roam Research のような新手のソフトもあるようだが、自分の場合は iA Writer で満足している。使っていないが Wiki Link 記法も使えるのでファイル同士の繋がりを作ることもできるようだ。
職業プログラマーになって以来、テキストエディターは Vim 一択だろうという気持ちでいたが、 GUI でファイル検索・管理できるという一点で iA Writer を気に入ってしまった。コードを書くならいまでも Vim が良いが、ブログの文章や個人用メモは完全に iA Writer に乗り換えてしまった。世間的に大人気な Notion を使っていたらこのようにエディターを他のものに乗り換えることはできなかったのでプレーンテキスト万歳だ。
ピアソン版の『達人プログラマー』に GUI のファイル検索だと目的のファイルが見つかるのに時間がかかるので grep
や find
でファイルを探す方が高速だ、という記事がある(第3章)。 Unix 哲学的な話で、小さな機能を持つソフトを組み合わせて使う方が効率的だという話だった。 grep
や find
で検索して xargs -o vim
するより、テキストエディターの中で一覧表示出来る方が便利だ。少なくとも普通の人にとっては。何でもシェルでやるのが良いという時代は終わったのかもしれない。
とはいえ iA Writer は macOS の仕組みの上で達人プログラマー的なやり方を継承しているようにも感じる。例えば先ほどのスマートフォルダは macOS の Finder にある機能だ。ひょっとしたら UI が同じだけでまるっきり別の実装がしてあるかもしれないが、 OS や SDK が提供しているシンプルな GUI を組み合わせて便利なものを作るのが今風の達人プログラマーなのかもしれない。
-
Mac 版は同一ライセンスになっておらず Mac App Store から別途購入する必要がある。 8000 円は高いので一か月くらい悩んで買った。 ↩
whisper.cpp で英語の Podcast を文字起こし
OpenAI の文字起こし AI Whisper を簡単に利用できる whisper.cpp を使って英語の Podcast を文字起こししている。めっちゃ便利。
英語の Podcast 、特に会話主体の Podcast はリスニングがかなり難しかった。ニュースの Podcast などは比較的聞き取れるのだけど、テック系の Podcast などは特に意味がわからない。語彙の問題かと思ってたが、文字起こしをしてみて初めて理由がわかった。フィラー(意味のない場繋ぎのための言葉)が原因だった。文字起こしされたものでも読みにくいのだ。
フィラーとは一般的には "Uh" とか "Um" 、 "Well" みたいなやつだが、人によってだいぶフィラーには違いがある。いま聞いてる Podcast の話者たちは "I mean" とか "as well" 、 "like" や "that" を多用するが、このようなフィラーっぽくない単語を口癖なのか場繋ぎ的に使う。なのでそのまま文字に起こして読んでも意味が通らない文章になっていたのだ。
音のまま会話文を理解するためには「あ、いまのはフィラーだからスキップしてよいな」というのが瞬時に判断できなければならない。フィラーに加えて言い間違いの訂正もある。ニュースのアナウンサーは基本的にフィラーなしで喋るし、言い間違いして訂正することもほとんどない。英検のリスニング問題もそうだ。
しかし生身の人間は、日本語でもそうだけど、話していて考えている最中に「えー(Uh)」とか「あー(Um)」とか言ってしまう。ネイティブの日本語話者である自分は「えー」や「あー」、言い間違いや言い直しは瞬時に頭の中で意味がないものと判定できているが、英語ではそれができないので会話文の理解が難しいのだ。なので英語の会話文を理解するためには、まず①文章として筋の通った英語をわかる必要があり、その上で②フィラーや言い直しなどを瞬時に判定できるようになって音を聞きながらそれらを除外して頭の中で文章を組み立てていく力が必要になるということだ。
whisper.cpp では文字起こしする際に利用するモデルを選べる。名前が小さいモデルほどダンウロードするファイルが小さく、文字起こしの処理も速くなるようだ。英語ならば small でも充分な精度だが、 small は音に忠実に文字起こししようとしてフィラーがたくさん入ってしまう。 medium あたりからフィラーが除去されるようになり、 large だと結構アグレッシブにフィラーや言い間違いを除去してくれて読みやすい英語になる。
Whisper は ChatGPT と同じで、人間っぽいことをやろうとしている。音声からの文字起こし自体なら YouTube にもあるし、音声認識は iPhone や Android 携帯にも付いている。ただ、これらは聞いた内容をそのまま文字にするだけなのでフィラーや言い間違いを除外しない。なので出てきた最終系は意味の通らない文章になってしまう。 Whisper の large モデルあたりは人間が会議の議事録を取るのと近い感じで、言い間違いやフィラーを取り除いてきちんと文意が通るかたちで文字起こししてくれる。さらにそれを ChatGPT に投げて要約させたら議事録係とかいらなくなってしまう。すごい。
whisper.cpp を使う上での注意点としては Apple Silicon の Mac でこそ真価を発揮するので Intel Mac ではかなり遅いということだ。 iMac 5K 2017 で 40 分のエピソードを文字起こししたら 1 時間半くらいかかったのが、 M2 Pro の Mac mini では 20 分もかからずに終わってしまった。 whisper.cpp を使うために Mac を買い換えても元が取れるくらいに便利なので是非 Apple Silicon の Mac を買って whisper.cpp 使ってみてほしい。