ニコニコ生放送でBCD Designを4年運用した知見(基礎テクニック編)

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

はじめに

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

今回は前回の導入編に引き続き、BCD Designを4年運用した知見に基づき、BCD Designの基礎テクニックを紹介します。 基礎テクニックとは、主に単語選びや精度の高いコンポーネント名を、効率的に明名するための方法です。

エンジニアである以上、単語選びは日常的に行うことなので、BCD Designを使っていなかったとしても、役立つテクニックになるはずです。

要約

• サクッとコンポーネント名を明らかにする方法
• 具体的に明名していく流れを紹介
• コンポーネントの日本語名はとっても重要
• 英語が苦手でも意外と大丈夫
• 公開されている単語表を使うと楽
• AI活用法や単語の探し方
• 少しのコンパクトさよりも積み上げやすさが重要

サクッとコンポーネント名を明らかにする方法

まずはサクッとコンポーネント名を明らかにする方法です。

ニコニコ生放送で使用されている、文脈の深いこのコンポーネントを使ってデモンストレーションします。

まずはそれが何であるか、言葉にして説明してみましょう。

「イベントに参加している放送者の一覧」

しかしこれだと次のような問題があります。

• イベントの意味が広すぎて別の意味と競合しそう
• 一覧(リスト)だけでなく、その周囲も含んでいるのでスコープが合っていない

もうちょっと正確に表してみます。

「企画チームが開催しているイベントに、参加している放送者の一覧を表示するセクション」

この説明が、表示内容を適切に表し、過不足がないかを、表示要素と突き合わせて確認します。

表示要素	解説
バナー	バナーの内容は "企画チームが開催しているイベント" の文脈で包括できている
リスト	リストは "放送者の一覧" の文脈で包括できている
リストのカード	カードの表示内容は "イベントに参加している放送者" の文脈で包括できている
ページネーション	ページネーションはリストに付随して使用できる概念のため、言及は不要
セクション	バナーが見出しに相当し、このコンポーネントが一つの情報のまとまりであるため、これはセクションの型に該当する

ここまで来たら 良いコンポーネント名の法則 の (1 or 2)何の or 何を (3)どうする (4)UI を意識しながら、言葉足らずにならないよう単語(及びパーツ)を抽出します。

パーツ	解説
企画イベント	"イベント" だと意味が広すぎる且つEventがJavaScript的に競合する。 "チーム" や "開催" の部分は無くても他のEventと十分判別できるので省略。
参加放送者	参加している放送者の意味(番組放送者カードで表示)
リスト	"一覧" という単語は関心側に含めると複雑化するため、UI側の "リスト" として抽出
セクション	最も抽象的に捉えるとこれはセクションという単位のものである

※ "参加放送者" を "参加者" にしていないのは、"参加番組" のパターンも存在し、放送者と番組の対称性を保つため

これらの抽出した単語(及びパーツ)を繋げると「企画イベント参加放送者リストセクション」となるので、それをDeepLで翻訳します。

最後に、翻訳された英単語(複数形のものは単数形で扱う)を、日本語側の順序で抽出すれば完成です。

PlanningEventParticipatingBroadcasterListSection

改めて 良いコンポーネント名の法則 に沿って内容を確認してみるとこのようになります。

項目	説明
構成	(1)何の (2)何を (3)どうする (4)UI
詳細	企画イベントの参加放送者(を表示する)リスト(を使用した)セクション (イベントを "企画" で修飾している) (放送者を "参加" で修飾している)
コンポーネント名	PlanningEventParticipatingBroadcasterListSection 企画イベント参加放送者リストセクション

単語の組み立て方や、どう読み解くべきかがわかっているだけで、だいぶ楽になるのではないでしょうか？

一番最初に、それが何であるかを丁寧に説明できれば、あとは単語を抽出して、英語に翻訳して、日本語の順序で再抽出するだけで、精度の高いコンポーネント名が得られます。

具体的な明名の流れ

次は、現実世界に存在する概念や定義を利用して、明名する流れを紹介します。

題材はニコニコ生放送のプレーヤーです。

どこがプレーヤーなのか問題

まずはじめに、プレーヤーがあるのはわかりますが、どこがプレーヤーなのかの問題から始まります。

• 全体がプレーヤー？それとも黒い部分がプレーヤーのような気もする
• 全体をプレーヤーと呼ばない場合、全体はなんと呼ぶ？
• 右側の部分に視聴者数やコメント数が表示されるので、左側との関連性は強そう
• 設定ボタンから詳細設定を押すと右側に詳細設定パネルが表示されるので、責務はまたがってそう
• 責務の境界で言うと全体がプレーヤーの一単位になっていると言えそう

このような考察から全体をプレーヤーとしてみて次に進みます。

プレーヤーの画面の部分はなんと呼ぶのか問題

次に、プレーヤーの画面の部分はなんと呼ぶのか問題です。

• 画面の部分と一口に言っても、画面とはどこを指すのか？
• 画面は英語で screen、スクリーンとはどこまでのこと？
• テレビで言うなら縁まで入っている部分と、縁の内側の映像を表示する部分の違いもある
• 各部位ごとに適切な名前を知る必要がありそう
• 似たような名称、ディスプレイ？モニター？スクリーン？

それぞれで "◯◯とは" でググって見ると以下のような結果が表示され、結果を見ただけで何となく違いが読み取れます。

ディスプレイとは	モニターとは	スクリーンとは
縁まで入った単位っぽい	縁まで入った単位っぽい 右側にディスプレイの表記	映像を映し出す平面 縁は入ってなさそう

以前はここからwikiや辞書などを見て確認していましたが、今はAIが使えるので確定的な情報を得るような質問を投げかけてみます。

モニターはディスプレイの一種ですか？それとも、ディスプレイがモニターの一種ですか？	ディスプレイとモニターは、スクリーンが組み込まれている、という認識で合ってますか？	液晶パネルはスクリーンの一種ですか？
モニターは、ディスプレイという大きなグループの中の、コンピューターに特化した製品	ディスプレイやモニターは、スクリーンという部品を含んだ製品	液晶パネルは、そのスクリーンを実現するための技術の一つ

これを踏まえると、次のようなストーリーにピッタリ一致します。

昔、ゲーセンの筐体で、ブラウン管のディスプレイを液晶に変える時代がありました。これはブラウン管もスクリーンの一種なので、ディスプレイはそのままでスクリーンだけ交換していたということです。

これで確証が得られました。

結論

ここまで明らかになれば、確実な結論が出せます。

• 赤枠が Player の Display
• 黒い部分が Player の Display の Screen
• 青い部分が Player の Display の Header と Footer いわゆる Display の縁の部分
  • Header には運営コメントや放送者コメントが表示される
  • Footer には Player の Controller やコメント投稿パネルなどが表示される
    • テレビの縁の部分に音量調整等のボタンが取り付けられているイメージ
• 下の白い部分までを Player の Display に含む
  • フルスクリーン時は Footer 部分が一体型に見えるため、 Display の一部として扱う
  • FullScreen はユーザーが使用中のディスプレイの Screen に対して Full という意味
• 緑枠は Player の SidePanel (実装上はまだ別の名称を使用)
  • Side は位置を表す横の意味ではなく副次的なという意味
  • 副次的な意味であれば、将来的に独立して表示させても意味的に問題ない

このようにすべての単語の意味とUIが連動した状態を確認することで、明名が完了したことになります。

命名ではなく明名の大切さ

もし自分たちで命名してしまっていたら、様々なズレが生じてしまっていたことでしょう。

単語が元から持つ意味や性質を違うものに割り当てると、AはBでBはCでCはAというようなことが始まり、複雑になることは確実です。

Playerがプレーヤー自体ではなく、Displayがディスプレイ自体でなく、Screenがスクリーン自体でない世界で実装する難しさを想像してみてください。いかに明名を大切にするべきかがわかることでしょう。

名付けるのではなく 「君は一体何なんだい？」 と問いかける姿勢が大切です。

コンポーネントの日本語名はとっても重要

実装は英語で書きますが、コンポーネントの日本語名はとても重要だと考えています。

日本語名が重視されていないと、英語だけで考えたコンポーネント名を翻訳したら、意味が全然繋がらないといったことが普通におきます。日本語で読むとすごく違和感が生じるのに、英語だから何となく気付かずそのままになっていた、といった感じです。

その場合、どこかで嘘を付いていることになり、嘘の上に新しいコードを積み上げていくことになります。その上にまた嘘を付いたものが現れ、その先に何が待っているかは言うまでもありません。

この問題は回避するには、上述のデモンストレーションのように、先に日本語名を固めてから英語名に翻訳するか、英語で考えた場合は、確定させる前に日本語で確認する癖を付けることが大切です。

これはコンポーネントだけの話には収まらず、関数名とdocの意味が異なるというあるあるにも通じる部分で、あらゆるコーディングの部分でも同じことが言えるため、自分は普段のコーディングから全ての部分で、日本語でも意味が合っているか気にするようにしています。

ニコニコ生放送のBCD Design導入事例を見てみると、英語名と日本語名がしっかり対応しているだけでなく、意味に対して変に斜めのショートカットが発生しないよう、一つ一つの単語でちゃんと角を曲がっているような意思を感じとれるかと思います。

このように、過不足なく正確且つ丁寧に積み上げた名前は、必ずわかりやすさの恩恵をもたらしてくれます。

※ ただし、ニコニコ生放送でも一部UIの単語が不足しているもの(InformationやSummaryで終わっているものはSectionが不足)があるので、細部にはリファクタ対象が残っています。

英語が苦手でも大丈夫

英単語をちゃんと扱うとなると、英語のレベルが高くないとできないと思うかもしれませんが、決してそんなことはありません。

その証拠に自分は英語がかなり苦手です。それでも、英辞郎 on the WEBやDeepLを活用する程度で実現できているので、英語に苦手意識があっても名詞、動詞、形容詞の意味がわかっていれば大丈夫です。

• 英辞郎 on the WEB
  • 単語が持つ品詞が利用シーンに合致しているか
  • 単語の意味や、使われ方のニュアンスが合致しているか
• DeepL
  • 複数単語 or コンポーネント名全体を翻訳して違和感が無いか

コンポーネント名は、英語の文法より、日本語の 何の何をどうするUI のような文法のほうが合っているので、その点で言うと日本人には向いているように感じます。

ちなみに余談ですが、上述のデモンストレーションのとき、今までは "Participating" ではなく "Participation" を使っていたことに気付きました。AI時代の前に違う方法で単語を選んでいたことが原因になりますが、英語に詳しくないとこういうこともあります 😂

単語表で効率アップ

BCD Designを始めるとき、ゼロから単語の意味を調べたり、英語と日本語の対応を調べたりするのは手間なので、誰でも使える BCD Design 単語表 サンプル を用意しました。

Modifier(修飾語)	Case	Base

これは、一時期プロジェクト内の単語を整理するために、使用中の全コンポーネントから単語を分解し、品詞やUIごとに分類した表を、サンプル用に調整したものになります。

この作業によって、ブレを把握できたり、頭の整理に役立ったので、最初から使えばだいぶ捗るはずです。

関心の単位の文脈の有無の性質上、CommonとDomainといった関心事以外の単語はどのプロジェクトでも共通で使えるため、CommonとDomainのシートを追加して各プロジェクト向けにカスタマイズすれば、より手軽にBCD Designを始められます。

説明の欄も各プロジェクトでカスタマイズしながらご使用ください。

※ Caseの表は、動詞だけ用意して、AIに残りの列を埋めるよう指示すると簡単に作れます

AI活用法

自分が普段活用しているAI活用法を紹介します。

AIで適切な単語探し

AIは高度な使い方はせずとも、例えばこんな感じでも単語探しには十分役立ちます。

目的	質問の例
具体的な単語から総称を見つける (似た系列の単語が何の軸に属しているかを調べる)	単語Aと単語Bの総称はなんですか？
単語Aの総称として単語Bが適切かどうか調べる (ある単語が特定の軸に属しているかを調べる)	単語Aは単語Bの一種ですか？
似た単語にどのような差があるのか調べる (適切に使い分けるための判断材料)	単語Aと単語Bの違いは？
ニュアンス的にどの程度合っているか確認する (辞書にはあるが、使いたい意図と合致するか調べる)	英単語Aは単語Bという解釈で合っていますか？
名前AがUIとして認知されているか調べる (Baseに使えるかがわかる)	名前AはUIですか？

上述のデモンストレーションで使ったものもありますし、最初から「ディスプレイとモニターとスクリーンの違いは？」と質問しても良い回答を得られます。

AIを世の中一般の解釈であると捉えると、AIから返ってきた感触の悪い単語を使用すれば、他人にもわかりにくくなることが確実です。そのため、若干不安のあるときも念の為AIに聞いて確証を得るようにしています。

ちなみに、UIとして認知されているか？の質問に関しては、許容されやすいので、結果は厳しめに受け止めたほうが良いです。UI名が増え始めると、よくわからないUIが乱立し、わかりにくいシステムになっていきます。UI名はある程度絞られているほうが、再利用性が高くまとまったシステムになります。

AIにコンポーネント名から想像される内容を聞いてみる

AIに次にように聞いてみると、コンポーネントの役割に関して説明を始めます。

「Xxx」というコンポーネント名から何を想像しますか？

その返答が概ね正しければ、コンポーネント名の明名に成功していると言えるでしょう。違和感のある返答がきた場合、コンポーネント名に問題がある可能性があります。

以下は、ニコニコ生放送にある、名前が最長クラスのコンポーネントの例です。

項目	説明
構成	(1)何の (2)何の (2)何を (3)どうする (4)UI
詳細	番組の放送者のフォロワー限定コメントモードを紹介するパネル (コメントモードを "フォロワー限定" で修飾している)
コンポーネント名	ProgramBroadcasterFollowerOnlyCommentModeIntroductionPanel 番組放送者フォロワー限定コメントモード紹介パネル

以下の結果を見るとかなり期待通りの返答になっていることがわかります。

対象のコンポーネント	AIの返答	AIの返答の続き

長い名前であることは誰の目にも明らかですが、先頭以外のどこか一単語が欠けたら別物になってしまいますし、Programだけ抜いたところでほとんどメリットもなく、依存関係やディレクトリの並び順がややこしくなるだけです。

ここまで正確だと、もしかしたらニコニコ生放送の文脈をAIが解釈している可能性もゼロではありませんが、この方法の有効性を自ら証明してしまう事例が発生したので紹介します。

記事を書いている最中に見つかってしまった問題

悲しいことに、この記事を書いている最中に、この方法で一つの問題を見つけてしまいました。

上述のデモンストレーションで扱った PlanningEventParticipatingBroadcasterListSection について確認すると、まさに違和感のある「イベントの計画：イベントの企画段階で〜」という返答がきました 🤔

なんかおかしいなと思ったら、"Planning" の "企画" が "企画中" や "計画" の意味で解釈されていることに気が付きました 😂

たしかに言われてみればですが、英語が得意な方は記事を読みながら気付いていたかもしれませんね。。。AIが誕生する前に作成されたコンポーネントだったので、当時は気付けないまま採用していました。

気になって他のドメインを羅列して、AIにドメイン名から推測で説明を追加するよう指示したところ、不適切なものはほぼこれ1つだったので一安心。

PlanningEvent の代わりに OfficialEvent にすると普通に問題ない返答がきたので、ピンポイントの問題だったと言えます。

この使い方が精度向上に役立つことが伝わりましたでしょうか(笑)

対称性とパズル

ここでは、BCD Designの考察を深める話をしていきます。

ここまでの説明でおわかりのように、BCD Designの明名というアプローチを使用すると、すべてが説明的且つ体系的になっていきます。この状態でコンポーネント数が増えると、単語を使ったパズル的な側面を帯びてくるのも面白い点です。

仕組み的に、すべての単語が成果物に正確に連動していくので、単語を交換すれば、それに応じて、機能や表現が変化する結果を予測できます。そのためには、対称性を意識することが大切になります。

対称性

対称性とは、ArticlePostFormがあるとき、CommentFormよりも、CommentPostFormとなっていたほうが対称性が高いということです。Articleという単語には記事の意味での動詞がないため、ArticleFormとはできません。さらに、コメントの編集が必要になったとしたら、CommentEditFormとなるので、CommentPostFormと対になるほうが安定することがわかります。(ここも突き詰めると奥が深いのですが、いずれ詳細な記事を書くと思います)

他にも、上述のデモンストレーションで扱った、"企画イベント参加放送者リストセクション" の "放送者" が "番組" になったら、ProgramCard が並ぶことがわかりますし、"ユーザー" になったら UserCard が並ぶことがわかります。これは "参加者"(Participant) ではなく "参加放送者" を使うことで、対称性が生まれるているためです。

一単語長くなるというデメリットはありますが、必ずしも短い名前が正義ではなく、名前が短いことで失うものがあることを忘れてはいけません。体積が小さい四角錐よりも、体積が大きい立方体のほうが単純で、安定して積み上げられるのです。

複雑化するサービスで重要なのは、少しのコンパクトさよりも積み上げやすさであると思います。

単語と作用の連動

対称性の流れで、"企画イベント紹介パネル" というコンポーネントができたら、上述のパネルに放送者向けの企画イベントの紹介文が入ることがわかります。このように様々なコンポーネントを作る中で、一つ一つの単語やそれらの組み合わせが、どのような作用と連動するかが見えてくれば、単語パズルで解決できる領域が生まれます。

すると、良いコンポーネント名の法則 に照らし合わせて、1~4のどこをどれくらい変更すれば良いのかだけでなく、言葉足らずの欠けた単語さえも見えるようになり、これまで何も無かったところに、マス目が引かれているような感覚さえ生まれてきます。

実体験として、このようなパズルの要領で考えると、結構な数のコンポーネントは自動的に単語がハマっていくため、普通に考えたら苦慮するようなコンポーネント名が「対称性から察するに、きっとこのあたりの名前！」で一瞬で明らかになって笑ってしまったこともあります。

まとめ

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

BCD Design及び明名の、具体的な基礎テクニックが伝わっていると幸いです。

これらのテクニックはコンポーネント名以外の部分でも役立つものですので、応用して日々の設計や実装に活かしていただけるのではないでしょうか。

ニコニコ生放送のフロントチーム数人で行った、この記事のレビュー会では、日本語名の大切さや、具体的なAI活用法が特に好評でした。BCD Designは、自分のように英語が苦手な人でも、キレイなディレクトリ構成を手に入れられることが証明されているので、同じ悩みを抱えている方の参考になると幸いです。

来週は運用時の迷いに役立つ実践編の記事を公開予定です。