B2B CRMをデザインし、そのチームをリードする。
B2B SaaSスタートアップにて、新規CRMツールの仕様 → UI → フロントエンドを一人で繋ぐ役割として参画。リリース後は、成長フェーズに合わせて要件定義 + 開発リードへロールを切り替えた。
仕様・UI・実装を一人で短くつなぐ。
co-nectは日本のB2B SaaSスタートアップ。新規CRMツールをゼロから立ち上げる役割で参画した。求められたのは「派手さ」ではなく「日常的・反復的に使った時に違和感がないこと」。初期は仕様・UIデザイン・FEを一人で繋ぎ、リリース後はロールが変わる前提だった。
日常使いのUIに残る摩擦を減らす。
- 集中型のデザイン工数を割く余裕がない。仕様・UI・FEを一人で握らなければ、ループがチームの吸収できる速度を超える。
- 日常使いのUIは容赦がない。残った摩擦は、ユーザー全体で多数のフラストレーションになる。
- リリース後はロールが変わる。0→1で機能する形と、成長フェーズで機能する形は同じではない。
まずは出荷できる基盤を選び、判断を短くする。
プロジェクトはビルドモード（仕様 → リリース）と成長モード（リリース後の方向決定）の2モードで進めた。各モードで担う役割は意図的に変えている。
MUI + Storybookを共通基盤として採用
少人数のチームでB2B CRMを立ち上げる以上、すべてのプリミティブを自前デザインするのは贅沢。MUIを信頼できるデフォルトとし、Storybookをデザイナーとエンジニアの単一の真実の源に据えた。Figma → Storybook → プロダクトのループがほぼズレなく回るようになった。
初期は仕様 → UI → FEのループを一人で握る
初年度はすべてのステップを一人で担当。繋ぎ目を一人が握ることで、意思決定が即座に実装現実とテストされる。ロール間のラウンドトリップが発生しない。チームが小さく、プロダクト面が新しい時期にだけ機能する形だった。
リリース後、要件定義 + 開発リードへ移行
プロダクトがリリースされると、ボトルネックは「UIを作る」から「次に何を作るか、チームがどう作るか」へ移った。要件定義と開発チームのマネジメントに移り、仕様ミーティング・優先度判断・実装レビューを担当。デザイン品質はレビューを通じて担保した。
リリース後は、作る人からチームを動かす人へ。
- 仕様 → UI → コードのループが、プロダクトの形が固まる時期に短く保たれた。
- リリース後もチームの出荷品質が一定に保たれた──レビューと構造化された要件定義によって。
- フェーズに応じてロールが変化した──意図的な選択として。
フェーズが変われば、効く仕事も変わる。
0→1では、仕様・UI・実装の距離を縮めることが最も効いた。リリース後は、個人が速く作ることよりも、チームが同じ前提で判断し続けられることの方が重要になる。だからロールを固定せず、レビュー、要件定義、優先度判断へ重心を移した。デザイン品質は自分の手数ではなく、チームの判断の型として残す方が長く効く。