Profile | Tanmen

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

HR（転職サービス）から医療（治験事業）へ領域を移しながら、10 年。いまは事業会社で CTO・技術顧問 として新規サービスを立ち上げています。ただ、どの現場でもいちばん手を入れてきたのは、コードが書かれてからユーザーに届くまでの道と、チームからチームへ仕事が渡る継ぎ目のほうでした。

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

大事にしていること

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

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

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

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

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

作る側の面倒は、コードの外にもあります。CI の待ち時間、デプロイの手順、QA への依頼の行き違い。「そういうもの」として流されている手間ほど、誰にも数えられないまま積み上がっていく。設計と同じだけ、仕事の流れ方にも手を入れているのはそのためです。

やってきたこと

仕事で

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

仕事の外で

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

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