Storybook駆動開発で開発生産性爆上げ

概要

フロントエンドエンジニアの@high_g_engineerです。
最近、社内で生産性向上がホットなワードとして上がっており、自分自身もチームトポロジーの知識などを学習しつつ、フロントエンドの知見を踏まえて、生産性向上に全力で向き合うことをモットーに日々の開発に従事しています。
今回、その一環として、Storybook駆動開発をプロジェクトに導入したことにより、開発生産性が爆上げしたので、その取組を共有いたします。

チームの開発体制についてと取り組んだことと気付き

現在のチームは、PdM1人、バックエンド1人、フロントエンド1人の最小構成です。
チームが最小構成だけでなく、プロジェクトの完了予定スケジュールがタイトめなので、
チームの進捗が滞ったり、お互いの責務を邪魔しあったりすると、
その瞬間にプロジェクトが破綻する可能性をはらんでいる為、
チームトポロジー等を参考に、チーム内で業務ハックを実施しています。

実施中の業務ハック

• Googleカレンダーのスケジュールをロックする（まとまった開発時間を確保）
• Slackを出来る限り見ない（コンテキストスイッチを最小限にする）
• コミュニケーションは必要最小限に済むようにする
  （議題はSlackに投げて非同期にコミュニケーション。必要ならGatherで密に会話。）
• 個人のWIP制限意識する
• チームの責務をはっきりさせ、他タスクが入り込みそうな余地があれば交渉・調整する
• 7時間以上寝る、散歩する、水飲む、休憩する、食べすぎない etc.

ただ、上記を完璧にやったとして、伸ばせる開発生産性は、良くてx1.5〜x2くらいです。
開発生産性をx5, x10を目指すなら、こういった業務ハックでは限界があり、仕組みで対応するしかありません。
そこで、自分の責務であるフロントエンドの領域でStorybookを利用した環境で開発を進めています。

Storybookで受けている恩恵をリストアップ

バックエンド側のフレームワークやDockerの影響を受けない開発環境

• Storybookは完璧に独立したフロントエンドのローカル環境です。
• 他の影響を受けない環境の為、フロントエンドエンジニアは自身の責務に集中ができます。

ホットリロードが効くので、変更内容を即時に確認可能

• プロジェクト本体がバックエンドフレームワーク中心設計な為、それに乗っかって開発を進めるとホットリロードがなく、とても辛い状況に陥ります。
• Storybookでは、ブラウザリロード、キャッシュ削除等が不要になる為、周りの環境に作用されず、開発体験が良い状態が作れます。
• たとえブラウザリロードといえど、チリツモで失う時間が馬鹿にならないので、この辺りの意識は大切にしたいところですね。

Storybook上では、どんな単位のUIでも表現できる

Storybookは自由なプレイグラウンドなので、以下の様な表現が如何様にもできます。

• ボタンやテキストボックスなどの極小単位のUI
• 小さいUI同士を組み合わせた大きめのUI
• 大きめのUIを組み合わせたり、複雑なデータ管理を行う1ページまるごと
  etc.

UIを細かく分けて実装し、デプロイまでのコストを最小限におさえられる

• UIを直接確認できる為、「ログイン→画面遷移→情報入力」といった手順が必要ありません。これらの操作による無駄な時間を省けます。
• Storybookは、Storyファイルの作成の粒度次第でどんな単位のコンポーネントでも画面表示することが可能な為、それに応じてプルリクエストを小さい粒度で作成しやすくなっています。
• また、ビルドファイルを生成せずに確認できる為、デプロイ時に本番環境を壊す危険性がありません。
• 上記により、テスト/レビュー負担を下げ、開発〜PR作成〜デプロイまでのリードタイムを短縮できます。
• 1日で15プルリクエストを作成し、次の日には全PRをリリースした実績があります。

社内作成デザインシステムの利用で生産性を更に高める

• デザインシステムは再利用性の塊です。
• デザインシステムを利用することで、非効率なマークアップの時間を抑え、適切な箇所に時間を割くことができ、実装時間の短縮とクオリティアップを同時に実現できます。

MSWの利用で、モックAPIをフロントエンド側で作成可能

• フロントエンド観点では、データの入出力は最低限のJSONさえあれば良いです。
• モックAPI作成の為だけにバックエンドエンジニアの稼働を奪うことがなく、最低限のコストで立ち回れます。
• APIを経由した細かいテストもフロントエンドエンジニアの責務で対応可能です。

フロントエンドだけで完結した開発体験

• Storybookのおかげで、バックエンドフレームワーク中心設計な現場でもフロントエンド、バックエンドが互いの領域を侵食しない体制を作ることが可能です。
• 責務を完全に分離することに成功しているので、バックエンドと結合するタイミングは、開発終盤のタイミングでもokです。
• 弊社では、プロジェクト本体のバックエンドが十数年の運用によりカオス化している為、
  バックエンドエンジニアの責務でカオス化したコードの対応に全力を注ぐことが可能になら為、結果としてバックエンド側の開発効率も上げられています。

まとめ

以上で、Storybook駆動開発で開発生産性爆上げの共有を終わります。
Storybookを中心としたフロントエンド開発はとても良い開発体験です。
各コンポーネントに対し、Storyファイルを作るのは慣れていないと面倒に感じますが、
一通りのStoryファイルが出揃うと、もうStorybookなしでは生きられない体になります。
まだの場合は、今すぐStorybookを導入し、良きStorybook駆動開発ライフを送りましょう！