Profile | Tanmen

tanmen — 怠惰なプログラマー。バックエンドエンジニアとして新卒入社しましたが、設計の良し悪しが一番響くのはフロントエンドで、そこがプロダクトの寿命を左右する。そう考えて軸を移し、いまはフロントエンドを起点に全レイヤーを触っています。

HR（転職サービス）から医療（治験事業）へ領域を移しながら、10 年目。いまは事業会社で CTO・技術顧問 という立場で、新規サービスを企画段階から立ち上げつつ、開発体制の改善やサービスの方向づけまでを見ています。

「面倒」を見つけたら小さなツールにして片付けるのは昔から変わらなくて、その延長で個人でもいくつか作って動かしています。新しい技術を触った所感や、作ったものの話は、この部屋から少しずつ書いています。

大事にしていること

エンジニアにとって面倒なプロダクトから、顧客にとって良い UX は生まれない。
顧客にとって面倒でない。エンジニアにとっても面倒でない。その両方が揃って、はじめて良い商品が生まれる。

片方だけなら難しくありません。顧客の面倒を消すために運用でカバーすることもできるし、作る側を楽にするために手順を顧客へ押し付けることもできます。ただ、片側に寄せた面倒は必ず戻ってきます —— 運用コストとして、あるいは離れていく人として。

とくに、触っていて面倒なプロダクトは作る速度から落ちます。試す回数が減り、直す気力が削られ、「本当はこうしたい」が実装コストの前で諦められていく。

厄介なのはその先です。諦めた仕様は、そこで止まってはくれません。次の機能はその妥協に合わせて作られ、さらに次はその両方に合わせて作られる。やがて「やりたいこと」ではなく「過去の妥協を壊さないこと」が仕様の中心になり、気づいたときには身動きが取れなくなっています。

そうなる前も、なってしまった後も、やることは変わりません。どちらにとっても面倒でないものを作る。それをモットーに、設計を改善し続けてきました。「どちらかを我慢すれば成立する」案を設計が足りていないものとして扱っているのも、その我慢が一番積み上がるからです。

やってきたこと

仕事で

立ち上げから運用まで一気通貫で — 要求の整理・仕様策定・設計・実装・インフラ構築・移行計画・リリース判断。作って終わりではなく、動き続ける状態にするところまで。
レガシーの載せ替え — EOL を迎えた基盤のリニューアル、負債化した仕様の掘り起こしとデータ移行。どこから手を付けるかを決めるために、自分でコードを触って現物を確かめます。
リリース障害を減らす仕組み — 大きなリリース障害をきっかけにプレモーテムを制度として入れ、本番相当の検証を誰でも回せるフローに整えました。障害率は 7 割ほど下がっています。ほかに CI/CD の整備、カバレッジが下がる変更を止める仕組み、 E2E / ビジュアルリグレッションの導入、SRE としてのエラーバジェット設計。
チームと組織 — 採用の設計から、育成、配置まで。エンジニアリングマネージャーとテックリードは、育てて引き継ぐところまでやりました。誰が何に向いているかで配置を組み替えることも。
事業の判断 — 撤退ラインを先に決めてから始めます。判断できるように、コストは見える状態にしておく。利益が出ないときに新機能を足すのではなく、コアコンセプトそのものに魅力があるのかを調べ直し、方向転換で立て直せるかを見る。外部サービスの値上がりを受けて、基盤を内製へ切り替える判断も。

仕事の外で

OSS へのコントリビュート — react-hook-form / jsPDF / OpenAPI Generator ほかに PR を送ってマージされています。型定義の穴やコード生成の不具合といった、普段使っていて自分が踏んだところが中心です。
OpenAPI まわりの自作 OSS — openapi-automatons。スキーマ 1 枚から axios / fetch / NestJS / Next.js / zod / react-query 向けのコードを生成するツールチェーンを、設計から維持まで自分で。
自作ツールと発信 — 不便を埋める小物が中心。技術メモや所感は Blog / Qiita に。

ご相談は ~/supports から受け付けています。フロントエンド・OSS / ツール開発まわりに限らず、設計や開発体制についてのご相談も同じ窓口へ。詳しい経歴が必要な場合もこちらからどうぞ。