みせあいの開発スピードを支える、3 つの小さな工夫

派手な仕組みではなく、地味な習慣の話

「○○ツールを導入したら生産性が 10 倍になった」 — そういった種類の話ではありません。

みせあいは小さなチームで運営しています。それでも継続的にアップデートを出し続けられているのは、いくつかの 地味な習慣の積み重ね によるものです。今日はその中から 3 つを紹介します。

設計議論で意見が割れた時、私たちは長く議論しません。代わりに、30 分だけ手を動かして動くプロトタイプを作ります。

不思議なことに、動くものを目の前にすると議論はあっさり収束します。机上で延々と検討していた論点の半分は、実装してみると問題ですらないことが分かる。残り半分は、実装してみて初めて見える本当の論点です。

「動くものは千の議論に勝る」 — どこかで聞いた言葉ですが、私たちはこれを 小さな実践として日常に組み込んで います。

「金曜のデプロイは禁止」という業界の通念があります。私たちはあえてこれに反対します。

私たちのチームでは、むしろ金曜の朝に大きめのデプロイを集約しています。理由は単純で、もし問題が起きても 金曜の午後 + 週末準備時間 で対処できるからです。

「金曜禁止」という方針は、本質的には テスト体制が脆弱なチームの自衛策 です。私たちの場合、デプロイ前のステージング検証と、デプロイ後の早い切り戻し手順が整っているため、金曜午前は最も適したタイミングになります。

ただしこれは、すべてのチームに勧められる習慣ではありません。自分たちの体制に応じて、通念を再評価する ことが大事だと考えています。

新機能を追加する Pull Request には、レビュー時に 必ずこの問いを 1 行入れる ことを習慣にしています。

「これ、本当に今必要ですか?」

実装した本人にしてみれば、必要だと思って書いたコードです。けれども改めて問われると、「まだなくてもいい」「3 か月後に判断したい」となるケースが、想像以上に多い。

私たちは、100 機能を作って 30 に絞り込む方が、最初から 30 だけ作るより良いプロダクトになる と信じています。捨てるためには、まず生まれていなければいけない。けれど、生まれかけのまま勢いで本流に入れない。

この問いはコードの追加を抑える効果もありますが、それ以上に 「自分たちの判断軸を毎週確認する儀式」 として機能しています。

新しいツールでも、特別な手法でもありません。毎週 1% の積み重ね。それが私たちのチームの開発速度を支えています。

派手ではないけれど、私たちはこれが一番効くと信じています。