バベルの図書館は完成しない

Extended outer memory module
for my poor native memory.

Posts:
2026/01/06 前回記事から4年が経過しました、現状報告
2022/02/13 クラビスの CTO になりました
2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った
2020/09/13 ISUCON10 の予選を 7 位で通過した
2019/12/01 Puma の内部構造やアーキテクチャを追う
2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む
2019/04/29 InnoDB の B+Tree Index について
2019/04/29 InnoDB における index page のデータ構造
2019/04/28 InnoDB はどうやってファイルにデータを保持するのか
2019/01/06 Designing Data-Intensive Applications を読んでいる
2019/01/03 年末年始に読んだ本について、など
2019/01/01 Ruby から ffi を使って Rust を呼ぶ
2018/11/10 ブラウザにおける状態の持ち方
2018/07/01 Rust で web アプリ、 或いは Rust における並列処理
2018/05/14 なぜテストを書くのか
2018/05/13 Rust で wasm 使って lifegame 書いた時のメモ
2018/03/12 qemu で raspbian のエミュレート(環境構築メモ)
2018/03/12 qemu で xv6 のエミュレート(環境構築メモ)
2018/03/03 Ruby の eval をちゃんと知る
2018/02/11 Web のコンセプト
2018/02/03 Rspec のまとめ
2018/02/03 Ruby を関数型っぽく扱う

前回記事から4年が経過しました、現状報告

前回の投稿から4年近くが経過した。2022年2月にクラビスのCTOに就任したことを報告して以来、このブログは更新されていない。あまり放置し続けたくないという思いと、自身への記録のために、この4年間の変化を整理しておく。

この4年間の経緯になるが3年ほどはクラビスのCTOとして、開発組織とシステム、プロダクトの改善に取り組んできた。当初は新規プロダクトの開発を中心に進めていたが、次第に組織全体の課題に目が向くようになり(向かされるようになり)、開発体制の整備やアーキテクチャの改善に注力するようになった。

2024年11月末、クラビスは親会社であるマネーフォワードに吸収合併された。詳細は省くがクラビス時代の開発組織、システム、プロダクトはそのままマネーフォワードに移管され、私も同社に戻った。 2025年6月より、SMB向けのプロダクト開発組織の副本部長という形になり、現在はクラウド会計の開発組織などを管掌している。 現在の役割は組織マネジメントが主であり、プロダクト開発には間接的に関与している形だ。規模の大きい開発組織の管掌をしているため、組織マネジメントの比重が大きい。

担当プロダクトは歴史のあるプロダクトであり、多くのユーザーに利用されている。そのため、安定稼働が最優先であると同時に、継続的な機能開発も求められる。典型的だがこの両立が組織運営における大きな課題である。 開発組織が直面している課題は、アーキテクチャ負債の返済と技術スタックの更新である。長い開発の歴史の中で蓄積された技術的負債は、新機能開発の速度を低下させるだけでなく、安定運用にもリスクをもたらす。 一方で、既存の機能を維持しながら新機能を提供し続ける必要もある。アーキテクチャの刷新とプロダクト開発、安定運用のバランスを取ることが、現在の組織運営における最大の焦点である。 具体的には、段階的なマイグレーション戦略の策定、技術的負債の優先順位付け、開発生産性の向上施策などに取り組んでいる。

振り返ってみると4年前にCTOに就任した時点では、自身の能力に対する過信というか、求められる責任に対する解像度の低さがあった。実際にポジションに就いてみて、自身の未熟さや思慮の浅さを痛感することになった。これを知れたというのは私の20代の挑戦の価値の一つであったと思う。 また、組織内の力学や想いを過度に(人並みに?)気にする傾向があったが、徐々にそうした姿勢から脱却しつつあるのかなと感じる。組織の中での立ち回りに神経を使うよりも、本質的な価値創出に集中する方が結果的に良い成果につながり、その結果として継続性のある組織運営ができるのではないかと考えている。つまみを40にするか60にするかみたいな話なので今後の経験によってバランスは変化しそうだ。 さらに、この数年でAI技術が急速に進化し、エンジニアリングの価値のあり方が変わりつつあることも大きな変化だろう。間接的にブログ執筆の動機につながっているかもしれない。かつては技術力そのものが明確な差別化要因であったが、現在ではそれだけでは不十分であり、技術を使って何を成し遂げるか、どのようにビジネス価値に変換するかが、より重要になっている。言い換えると、現在の待遇を肯定するために必要な努力は増えたと感じている。技術的な深さだけでなく、ビジネス理解、組織運営、戦略立案など、求められる能力の範囲が広がって対価は減ったように思う。

2026/01/06 10:35
tags:
This site is maintained by furuhama yusuke.
from 2018.02 -