この記事はドワンゴ Advent Calendar 2024 11日目の記事です。

はじめに

株式会社ドワンゴのニコニコ生放送でフロントエンドを担当している misuken です。

現在のニコニコ生放送のフロントエンドをReactで実装し始めたのが2016年、その後2020年からBCD Designを導入しました。
全体では8年、BCD Designを導入してから4年が経過しました。

BCD Design によるコンポーネントの分類は今でも継続的にいいねとストックが増えており、JSConf JP 2024のKINTOテクノロジーズさんのスライドの中でBCD Designへの切り替えを検討されているという話が上がるなど、興味を持たれる方も増えてきているように感じます。

この記事では、ニコニコ生放送でBCD Designを導入してから4年間の運用で得られた知見を共有していきます。この記事がコンポーネント名や分類に悩んでいる方の助けになると幸いです。

関連記事
2024-12-17公開: ニコニコ生放送でBCD Designを4年運用した知見(基礎テクニック編)
2024-12-24公開: ニコニコ生放送でBCD Designを4年運用した知見(ベストプラクティス編)

要約

名前で消耗する時代は終わりました
コンポーネントを探すときに迷うことがなくなりました
良いコンポーネント名には法則があります
学習コストは低めです(厳密にやらなくても効果を得られます)
新規プロジェクトでも途中からでも導入可能です

名前で消耗しない世界へ

ニコニコ生放送でもBCD Designの導入以前はAtomic Designを採用しており、世間でもよく言われる問題が多発していました。粒度判断の問題、コンポーネントの名に統一感が無い問題、依存関係の問題、目的のコンポーネントがどこにあるかわからない問題などなど。

このまま不毛なことに時間をかけ続けるのはもったいないと感じ、辿り着いたのがBCD Designでした。

命名しない、主観を含めない、全ては要件から勝手に決まっていて、それをただ明らかにするだけという発想を追求していくと、それこそがシステム全体を説明的にすることそのものであり、中立なわかりやすさに繋がるということがわかりました。

導入してからは、チームのメンバーにもメリットを感じてもらえる機会が多く、BCD Designの適用範囲は順調に拡大を続けています。BCD Design化されたプロジェクトでは、Atomic Design時代に起きていた様々な問題が解消されており、粒度に頭を悩ませていたことは遠い過去の記憶になっています。

スケール面に不安なし

ニコニコ生放送は複雑な機能も多く、コンポーネント数の多い大規模プロジェクトです。

去年のアドベントカレンダーの記事ニコニコ生放送のBCD Design導入事例の中で、具体的に大量のコンポーネントの名前を紹介しましたが、今年は結構表示パターンの多い機能が何個もリリースされたため、その数は大幅に増えています。

それでもBCD Designでの運用が安定しているため、スケール面の不安は全くありません。コンポーネントが増えるときに収める場所に迷うこともありませんし、探すときも迷う余地のない理想的な状態が安定しています。

最近はBCD Design導入前に作成されていた名前のブレた古いコンポーネントのリネームなども進み、時間経過とともにクオリティが上がるとても良好な運用が続いています。

ちなみにおすすめの構成は以下のタイプです。
baseとcaseは直下にコンポーネントのディレクトリを配置。commonやdomainは直下にドメイン名のディレクトリを配置することで、commonやdomainを開いたとき、ドメイン名の一覧が並んでプロジェクトの全体を把握しやすくなります。

base
  button
case
  search-form
common
  ad
    ad-banner
  category
    category-label
domain
  site
    site-header
    site-footer
  user
    user-card

良いコンポーネント名の法則

BCD Designは名前の構成自体に型のような効果をもたらすため、単語の順番がどうなるのか、どの位置にどのような単語が収まるのかが明確です。

基本形

(1 or 2)何の or 何を (3)どうする (4)UI

Domain 具象度の高いドメインに相当する単語
Common 抽象度の高いドメインに相当する単語
Case 状況(処理)の種類に相当する単語
Base UIの種類に相当する単語
- UIに該当する単語が二つ並ぶ場合 "UI1(を使用した)UI2" という解釈になります
- 例：XxxListSection は "Xxx(を表示する)リスト(を使用した)セクション"

主に使用されるパターンは以下A~Eの5つになります。

構成	例	コンポーネント名
A `(4)UI`	ボタン	Button ボタン
B `(3)どうする (4)UI`	検索するボタン	SearchButton 検索ボタン
C `(1 or 2)何の (4)UI`	サイトのヘッダ	SiteHeader サイトヘッダ
D `(1 or 2)何を (3)どうする (4)UI`	ユーザー名(を表示する)(テキスト)	UserName(Text) ユーザー名
D `(1 or 2)何を (3)どうする (4)UI`	ユーザー(を表示する)カード	UserCard ユーザーカード
E `(1)何の (2)何を (3)どうする (4)UI`	番組の放送者(を表示する)カード	ProgramBroadcasterCard 番組放送者カード
E `(1)何の (2)何を (3)どうする (4)UI`	番組のコメントを投稿するパネル	ProgramCommentPostPanel 番組コメント投稿パネル

※ (1)(1) や (2)(2) から始まる構成もあり得ますが (2)(1) は禁止です
※ "を表示する" のパターンは、コンポーネント名に反映せず省略したほうが自然になります
※ "を入力する" のパターンは、コンポーネント名に反映せず省略したほうが自然になります
※ UIがText Number Valueといったプリミティブなものになる場合は省略可能です

修飾語と絡むパターン

関心が修飾されている場合、修飾語(太字部分)を除くと通常のパターンと同じになるため、修飾語に紛らわされないことが重要です。この性質を活かして、修飾語を抜いた状態でそれの本質が何であるかを確かめ、あとから修飾語を戻すのも優れた手段です。

構成	例	コンポーネント名
C `(1 or 2)何の (4)UI`	サービスで共通のヘッダ (サービスを "共通" で修飾している)	ServiceCommonHeader サービス共通ヘッダ
D `(1 or 2)何を (3)どうする (4)UI`	プレミアムな会員を登録するフォーム (会員を "プレミアム" で修飾している)	PremiumMemberRegistrationForm プレミアム会員登録フォーム
D `(1 or 2)何を (3)どうする (4)UI`	期間限定のキャンペーンを告知するバナー (キャンペーンを "期間限定" で修飾している)	LimitedTimeCampaignAnnouncementBanner 期間限定キャンペーン告知バナー
E `(1)何の (2)何を (3)どうする (4)UI`	サイトの緊急通知(を表示する)バー (通知を "緊急" で修飾している)	SiteEmergencyNotificationBar サイト緊急通知バー

最終確認

コンポーネント名が定まったら、英語名と日本語名で読み直して、コンポーネントが本当にその名の通りであるかを確認するようにします。

BCD Designはこのように型のようなものがサポートしてくれるので、PullRequestで内容を十分に表せていない言葉足らずな名前や、単語の順序がおかしな場合にもすぐ気付けます。

また、BCD Designを続けていくと指摘が発生すること自体が少なくなっていきますが、そのような場面ではレビューに出した人もしっくり来ておらず、すんなり合意が得られるため、名前を巡って消耗するということがありません。

コンポーネントの内容や性質を、BCD Designの方針に沿って "明名" (明らかに)するだけなので、チーム内で主観がぶつかることもなく、とても平和な運用を実現できています。

低学習コスト

BCD Designの学習コストについても共有します。

実際に運用している中で特にBCD Designの勉強会を開いているわけでもなく、チームのメンバーにはBCD Designの記事を共有したうえで、たまにPullRequestで改善ポイントを共有する程度で運用できています。

学習コストは結構低い部類に入るはずで、投資に対するリターンはかなり大きいため、少なくともAtomic Designなどで消耗する時間があるのであれば、BCD Designを試す時間に当てるほうが生産的だと思います。

単語の性質を利用している仕組み上、流行り廃りに影響を受けず、一生使い続けられるスキルである点も魅力です。

ニコニコ生放送のBCD Design導入事例も公開しているので、それをヒントに (1 or 2)何の or 何を (3)どうする (4)UI に当てはめ、自分のプロジェクトをBCD Designに置き換えた場合、どのような構成になるかを書き出してみるだけでも、色々な発見や雰囲気が掴めると思います。

導入時の進め方

ニコニコ生放送でも、新しいリポジトリに最初から導入できた場合もあれば、既存のリポジトリをAtomic DesignからBCD Designに乗り換えた場合もあります。

既存のリポジトリでAtomic Designなどから乗り換える場合、最初からPullRequestにはせず、テキストベースか空のディレクトリを使って移行後のイメージを固めるところから始めると良いでしょう。

最初はどうしても収まりが悪いイレギュラーなコンポーネントも出てくるとは思いますが、8〜9割はそれなりに収まるはずで、最初はそれで十分です。ある程度イメージが固まったら、新規のものをBCD Designに追加しつつ、既存のコンポーネントを徐々にBCD Designに移行していくことで、スムーズに進められます。

残ったイレギュラーなもののうち、なかなか名前を明らかにできていないものもあれば、責務が適切でないことが原因な場合もあるので、どこに問題があるか探りながら徐々に潰していくと良いでしょう。新規のものがBCD Designに収まっていけば、これ以上イレギュラーなものが増えることもないので、焦る必要もありません。

BCD Designに慣れてしまえば、ディレクトリは常にキレイに並ぶ前提が身に付くので、コンポーネント以外の分野でも応用が効いて役立ちますし、実装レベルでも単語一つ一つへの意識が高まるので、設計やコードの品質向上に繋がる効果も期待できます。

メンバーからの支持

最近、チームのメンバーがBCD Designを導入する前に作られたアプリケーションを触る機会があったのですが、着手時に「Atomic Designのディレクトリ構成は辛いのでBCD Designに乗り換えます」と声が上がりました。

たしかに、BCD Designに慣れている中で、atoms molecules organisms と遭遇すると「うっ」となります。
Atomic Designを採用すると、ほとんどの場合で独自の運用ルールが必要になるため、ディレクトリの中身を見ると整理されているようで整理できていない場面をよく見ます。

また、BCD Designのようなコンポーネント名の構成に対する規格もないため、コンポーネント名に統一感がなかったり、ディレクトリ内での並び順がバラバラになりがちです。

atoms と molecules は分かれてないほうが探しやすく、organisms はBCD Designのように関心名が common と domain に分かれていたほうが、ファイルの並びもキレイにで依存関係も見やすくなります。

今ではチームのメンバーからもBCD Designは無くてはならない技術として支持されています。

まとめ

いかがだったでしょうか？

良いコンポーネント名の法則や、一つ一つの単語をどのように捉えて組み立てていくかの部分は、気になる方も多かったのではないでしょうか？

BCD Designであれば、大量のコンポーネントが必要な大規模プロジェクトであっても、低学習コストで導入でき、スケール面に不安なく運用できるため、Atomic Designなどでモヤモヤしている方はもちろん、これから開発を始めるという方にもオススメです。

また、流行り廃りに影響を受けない点も特徴で、コンポーネント以外の分野にも応用が効くため、想像以上に広い分野で役立つ技術であると実感しています。

来週は単語探しに役立つ基礎テクニック編、再来週は運用時の迷いに役立つ実践編の記事を公開予定です。さらなる有益な情報をお届けしますので、ぜひそちらも併せてご覧ください。

関連記事
2024-12-17公開: ニコニコ生放送でBCD Designを4年運用した知見(基礎テクニック編)
2024-12-24公開: ニコニコ生放送でBCD Designを4年運用した知見(ベストプラクティス編)

株式会社ドワンゴでは、様々なサービス、コンテンツを一緒につくるメンバーを募集しています。ドワンゴに興味がある。または応募しようか迷っている方がいれば、気軽に応募してみてください。

Discussion