変数を受け止め、最速で。ネーミング大変問題はカオスの最小化で解決しよう
「マネーフォワード デザインアドベントカレンダー2024」、3日目はharayumiがお送りします！
いよいよ入社4年目に突入しようとしています。
BX・コミュニケーションデザイン領域のデザインマネージャーとして、年々向き合う課題の難易度が上がり、毎日が刺激の連続です。
2024年もさまざまな課題が目の前に立ちはだかりましたが、その中でも特に印象的だったのが「ネーミング大変問題」でした。
本記事では、その解決までの道のりをお話しします。
プロダクト数の多さが生むネーミングの課題
マネーフォワードグループは約50のプロダクトを提供しており、その過半数がビジネスドメイン、いわゆる法人向けのものになります。
当然ですが、プロダクトが多ければ多いほど、サービスの数もコンテンツの数も指数関数的に増えていきます。
機能、画面、料金プラン、導入プラン、イベント、記事サイト、コミュニティなど……数えるのが困難な量です。
そして、それらの"ほぼ"すべてに「名称」が必要です。
「名称」が必要ということは、その数だけ名前をつける作業、つまり「ネーミング作業」も必要になります。
これまでこの「ネーミング作業」は、各施策を担当するチームがオーナーシップを持って行い、独自に各所連携していました。
Speedを大事にするマネーフォワードらしい、素晴らしい文化です。
しかし、事業が多角化し、組織が数千人規模に成長した今、このやり方に潜む課題も顕在化してきました。
ネーミングの壁：多様な観点を捉えきる難しさ
ネーミング作業は、ビジネス、開発、運用管理、知財など、多角的な観点で熟考することが求められます。
観点のいずれかが抜け落ちると、以下のような課題が発生します。
① 名称の整合性がとれない
命名規則を無視した決定がなされる
逆に、命名規則を適用すべき対象ではないものに適用してしまう
複数の対象において、管掌が違うがゆえに同じ名称にしてしまう
逆に、複数の対象において、名称をそろえるべきなのに違う名称にしてしまう
名称をつけるべきものに名称を付与せずリリースする
逆に、名称をつける必要がないものに名称をつけてしまう
② 知財リスクや技術負債など、新たな具体課題を生む
知財観点が漏れ、法的に懸念のある案が有力候補になる
ビジネス観点が漏れ、商談などでお客さまに伝えづらい名称になる
デザイン観点が漏れ、UIをはじめとした様々なタッチポイント上で視認できない文字数になる
開発観点が漏れ、過去にあった名称を再度使ってコード上で混乱をきたす
SEO観点が漏れ、お客さまが検索で見つけづらい名称になる
ブランド観点が漏れ、マネーフォワードらしくない響きの名称になる
何かしらの観点が漏れたまま最終決裁フェーズまで行ったり、リリースされたりすると何が起こるでしょうか……？
当たり前ですが、土壇場で振り出しに戻って各所混乱する状態になります。
これらは、いわば全社的なペインとなっていました。
まさに、組織が大きくなった時に生じる成長痛です。
デザイナーが意思決定に向けての舵を取る
この状況を受け、ネーミングの合意形成と意思決定に向けての舵取り（進行マネジメント）をデザイナーに一任することがボードメンバー間で決定され、私がその役割を担うことになりました。
解決へのアプローチ
結論を言ってしまうと、特別な手法は使いませんでした。
複雑に絡まった糸を解きほぐすように、カオスを最小化すべく、以下のプロセスを丁寧に進めました。
①ネーミング対象の棚卸しと整理
ネーミング対象をすべて棚卸しし、「プロダクト名」「機能名」「導入プラン名」「オプション名」「画面名」などなど、カテゴリに分けました。
②ステークホルダーの整理
カテゴリごとに、どんな観点が必要で、その中でもどの観点が重要で、逆にどんな観点は必要ないか……すべてを言語化しました。
例えば以下のような整理です。
プロダクト名のネーミングにおいてSEO観点は大事だが、各プロダクトの中の細かな機能名称であれば必要ない（ことの方が多い）
国内向けのオウンドメディアであれば英語名称は必要ないが、そのサブドメイン名をつけるのであれば翻訳担当への相談を入れた方が良い
「イベント」とひとことで言っても、集客がオープンorクローズド、毎年行うor単発、協賛企業があるorない、ではステークホルダーは変わってくる
名称のみ決めれば良いのか、プライシングを含めた意思決定が必要か
（他にもまだまだたくさん……）
③ネーミングに関する議論履歴を残すためのドキュメントテンプレ作成
カテゴリごとに、検討〜意思決定の軌跡を記すドキュメントのテンプレを用意しました。
ステークホルダーもテンプレ内でチェックリスト化されています。
これで、誰がどんな観点でフィードバックをしたか、現フェーズはどこか、いつでも誰でも閲覧できるようになりました。
④ネーミング専用チャンネルをSlack上に設置
Slackで起案から決定までを管理するチャンネルを作成しました。
起案時点で「3.」のドキュメントは起案者によって用意されており、それに対して伴走するデザイナーをSlackチャンネル上でアサインする仕組みです。
担当するデザイナーは現在2人のみ。
高い全体解像度と合意形成スキルが必要なため、あえて対応者を絞っていますが、起案自体が結構な数なので、もう1人くらい増やしたいとたくらむ今日この頃😎
変数を受け止め、フレキシブルな仕組みでスピードを担保
仕組み化したことで、ユーザーに届けるスピードが落ちるようなことは本末転倒です。
そのため、完璧に型化された承認フローを構築するような仕組みにはしないことを前提にしました。
なぜなら、ネーミング作業は変数だらけであり、変数を柔軟に受け止められないと、その「本末転倒」が起こってしまうからです。
ネーミング作業に潜む変数の一例をご紹介します。
①部分最適と全体最適の理想バランス
ネーミング対象の性質・目的によって変わってきます。例えば、短期施策or長期施策、単発or継続、オープンorクローズドなど……
②各ステークホルダーを巻き込む順番の最適解
これもフレキシブルに判断した方がスピードが担保できます。
例えば、起案段階でテーブルに上がっている名称案を見て、知財担当やCxOを巻き込むタイミングはその都度変えています。
（懸念が大きい案が有力なら先に、そうでなければ後でOK、など）
また、起案者の習熟度によってもこれは変わってきます。社歴や習熟度によっては、先にある程度合意形成してる場合もあるし、CxOが起案者のケースだってあります。
③最速で、を前提としたフレキシブルなスケジューリング
すべてのケースに当てはまるわけではないですが、経営陣の決裁が必要な種類のネーミングだった場合、決裁のテーブルに乗せられる日は限られています。
起案されたタイミングを見て、次の決裁チャンスはいつか。
まずはこれを確認して、最速での着地を目指します。
場合によってはステークホルダー全員集めて一気に合意したり、それを同期or非同期どちらで行うかも柔軟に選択します。
議論が着地しないときはどうするか
多くの観点を必要とするということは、言い換えると、観点によって正解が変わるということになります。
ネーミング作業も、議論の着地に難航することがしばしばあります。
そんな時は以下のような手法をよく用います。
①プロトタイピングして見せる
デザイナーならではの手法ですね。
「この名称にしたらこんな見え方になるよ！」と、UIやWebサイト、営業資料などを実際にプロトタイピングして見せると、実際にその名称をリリースした先の世界に対する解像度がグッと上がり、自然と議論が先に進み始めます。
②「ユーザーにとっての最善は何か」を問いにする
何事も、逼迫したら原点に立ち戻ることが大事です。
すべての観点の上位に「お客さまがどう感じるか」があります。
観点の違いがうまくまとまらない時、「この名称を目にするときのユーザーは、どんな状態で、どんな感情なのでしょう？」という問いが、着地点を照らした瞬間をたくさん見てきました。
結論：デザイナーにしかできない仕事というわけではない
正直、職種なんて関係なくて、誰が担当してもいいと思います。
大切なのは、目的や相手の背負っていることを理解しつつも、全体を見渡し、多様な観点を尊重した上で、「今何を重視すべきか」を判断できることです。
何年か前のnoteさん主催のオンラインイベント『CXO・CDO超会議』で深津貴之さんが「デザインとは、課題のなかに存在するカオスの量を最小化すること」とおっしゃっていたことに感銘を受けた私ですが、
そう言った意味ではデザイナーは適任だと思いますし、こういった役割を我々デザイナーに委ねてくれるこの組織にもRespectの気持ちです。
来年はどんな新たな難題にエンカウントするかな？
それを考えるだけで今からワクワクしています！
（というか、もうすでにエンカウントしているので、それはまた来年のアドベントカレンダーにでも……笑）
「マネーフォワード デザインアドベントカレンダー2024」はまだまだ続きます！お楽しみに🎄