ネーミング とは名前を付けることです。。SSE でつくるのは概念ですが、概念には内容（Content）と名前（Caption）があります。内容に対して名前をつけることで、その概念を扱いやすくなります。
SSE においてネーミングは重要な活動ですので、本章にて詳しく解説します。
そもそも名前とは何でしょうか。何のために付けるのでしょうか。SSE における扱い方を見ていきます。
そもそも名前をつける意味はあるのでしょうか。
本書にて QWINCS を紹介しましたが、こんな造語をつくらずとも「チャット以外にもコミュニケーションツールは 5 つある」でも通じます。なぜわざわざ QWINCS というネーミングを行うのでしょうか。
理由は一つで、再利用性のため です。名前をつけた方が言及しやすく、言及しやすいほど利活用しやすいのです。毎回「チャット以外にもコミュニケーションツールは 5 つある」と書くわけにもいかないでしょう。QWINCS と書けば 6 文字で済みます。開発者であれば変数名や関数名、あるいはファイル名といった形でネーミングには親しんでいるはずです。何十文字以上の説明的なフレーズをつけることは基本的にないはずです。なぜ名前の方が言及しやすいかはわかりませんが、人間の認知能力の問題だと思います。
また名前は、内容を端的に表現したサマリーでもあります。内容自体の理解は避けられませんが、理解を支援したり、理解した後の想起を支援したりするのに名前は役に立ちます。QWINCS は単純に 6 つの単語のイニシャルを並べたものですが、Q&A、Wiki、Issues といった構成要素を思い出しやすいと思います。ただし S については Sticky boards であり、Miro のようなデジタルホワイトボードを指すのですが、強引なため思い出しづらいでしょう。QWINCS という名前の読みやすさを優先した結果ですが、私もまだまだです。
名前とは何でしょうか。QWINCS は名前ですが、「チャット以外にもコミュニケーションツールは 5 つある」は名前ではありません。この違いは何でしょうか。
SSE では名前とは名詞（単語）または名詞句（フレーズ）を指します。
名前は対象をしっかりと表現するニュアンスがあり、何を指しているかの輪郭を比較的はっきりと示せます。SSE では概念という抽象的なものを扱いますから、名前を使って明確に表現していくことが重要となります。でないと解釈がブレすぎてしまい、思考や議論を積み上げることができません。
名前に絶対的な正解はありません。後に普及度の違いや権威性の付与によって標準化することはありますが、SSE の段階では扱いません。また、開発や提出や運用をする際は、最終的には（どの名前を使うかを）統一せねばなりませんが、SSE では 複数の名前が乱立することがよくあります。
たとえば QWINCS についても、以下のようなネーミングが考えられるでしょう。
別にどの名前でも良いのです。どこかで一つに決めて統一せねばなりませんが、それまでは複数の名前を挙げて、どれを使えばいいか迷ってもいいのです。むしろそうして揺さぶった方が、良い名前にありつきやすくなります。
ちなみに名前の乱立は、ひとりのときよりも複数人のときに発生しやすいと思います。特に A さんがつくった概念の名前 N1 が気に入らない場合、B さんとしては自分用に名前 N2 をつくって、普段は N2 を使う――といったことがよくあります。
N1 ---> (A's content) <--- N2
最終的には N1 か N2 か、はたまた別の名前 N3 になるのかはわかりませんが、何かしら統一しなくてはなりません。しかし初期の段階では、各自が使いやすい名前を使えばいいですし、各自が良いと感じる名前を提案すればいいのです。
小難しく聞こえるかもしれませんが、開発者の皆さんなら「エイリアス」の一言で理解できるでしょう。名前は概念（概念の内容）のエイリアスにすぎません。
SSE と実践する上で避けては通れない「造語」について解説します。
造語は嫌われがちですが、SSE においては重要な営みです。
造語とは 既存ではない新しい名詞 を指します。名詞句ではなく名詞ですので、QWINCS は造語ですが、Five Alternatives は造語ではありません。しかし Five Alternatives To Chat とした上で FAC と略したり、5 Alternatives To Chat とした上で 5AC と略した場合、FAC や 5AC は単語ですので造語です。
すでに述べたとおり、SSE では名前（名詞的な単語またはフレーズ）をつけることが重要ですが、開発した概念を指し示せる既存の名前か、それを組み合わせた新しいフレーズが常に見つかるとは限りません。SSE の初心者は「似ているから」と無理やり既存の名前を当てはめがちですが、それではその概念の内容が表現する差異と詳細を殺してしまいます。殺していては SSE は成立しません。既存の名前で表現できる「綺麗な理想論」ではなく、もっと汚くて現実的で私達に寄り添ったものを扱いたいのです。
扱うためには名前、特に単語が必要だが、既存にはない――そういうわけで 造語は普通に発生します。むしろ造語が発生しない方が不自然なくらいです。ですので、本項では「必要性」と書きましたが、むしろ「必然性」と書いた方が即しています。
造語に身構える必要はありません。造語が何を示すかをきちんと表現できていれば、造語であっても困ることはありません。無論、概念をつくる側として、造語ごとに明快な定義や説明をつくる必要がありますから負担は大きいですが、この手間は避けられません。この手間を惜しんでいては、その造語は誰にも通じないゴミとなってしまいます。
造語とセットで扱われる論点が「内容の新しさ」でしょう。典型的には「造語は新しい内容に対して付けるべき」といわれます。また「既存の内容を言い換えたり再構成したりしただけの改変」は「新しいもの」ではなく、「新しいもの」に比べると価値は薄いとされています。特に博識な者は、様々な知識と関連付けることができるので、新しいとみなすハードルが非常に高いです。生成 AI 相手だとさらに高くなります。
このあたりの議論は多くの人が抱くポイントなので、ここで整理します。私は造語マトリックスと呼んでいますが、まずは全体像を示した後、SSE に従事する者がどのように発想を変えねばならないかを述べます。
造語マトリックスですが、内容の新旧が 2 通り、ネーミングの仕方が 4 通りで計 8 パターンあります。
| 既存の内容 | 新しい内容 | |
|---|---|---|
| 既存の単語 | 1（既存） | 2（誤解） |
| 既存の単語の組み合わせ | 3（再構築） | 4（造語の回避） |
| 新しい単語（造語） | 5（弱い造語） | 6（強い造語） |
| 新しい単語も含んだ組み合わせ（造句） | 7（困難な造句） | 8（許容可能な造句） |
順に見ていきましょう。
1 は既存の内容を既存の単語で表現したものという当たり前のことを示しているだけです。たとえば「開発者にとって重要なのは生産性だけではない。開発者各々が感じる体験の質や主観的な満足度も重要である」という内容があり、これには「DevEx」という名前がついていますが、どちらも既存です。
2 については、新しい内容なのに既存の単語を当てはめているので、既存の単語の使い方が間違っています。たとえば上述の 1 の内容に対して「QoL」という名前をつける、などです。QoL にはすでに別の意味があって、これは QoL という単語の意味を取り違えています。
3 については、既存の内容に対して、既存の単語を組み合わせたフレーズを名付けています。たとえば上述の 1 の内容に「開発者体験」という名前がついていますが、「開発者」「体験」という二つの既存の単語を使っています。単語一つでは表現できないので、複数個使ってフレーズとして表現しています。しかし新しい単語は使っていないため、まだ通じやすいです。
4 については、新しい内容に対して、既存の単語を組み合わせたフレーズを名付けています。名前はフレーズですが、既存の単語から構成されているので比較的馴染みやすいはずです。造語のような忌避感がなく、造語を回避できている点で優れています。たとえば上述の 1 の内容をベースに、具体性を持たせて再現性を確保できるレベルの理論を構築したとしましょう。これに対して Engineering Effectiveness と名付けたとします。これは実在する概念で、Thoughtwork 社がつくったものです。この Engineering Effectiveness が示す内容が新しいかどうかには議論の余地がありますが、ここでは理論に落とし込めている点を評価して「新しい」とみなしています。
5 については、既存の内容に対して造語――つまりは新しい単語を名付けています。よくあるパターンは二つで、一つは単に無知すぎて、すでに名前がついているのに造語しているパターン。もう一つは、既存の内容を組み合わせた応用をつくって、それに対して造語しているパターン。たとえば私は、開発者体験まわりの概念を表現するのに「Speeriece」「管理 3.0」「体験性（Experiencity）」といった造語をつくったことがあります。Speeriece は Speed + Experience からつくったもので、体験の本質はスピードにあるとしたものです。管理 3.0 は、過程を管理する 1.0、結果を管理する 2.0 の次のパラダイムとして、理想状態をモニタリングする 3.0 があるよねとしたものです。体験性については、単に Productivity に代わる単語がほしかったので新しくつくったものです。いずれについても、開発者体験や Engineering Effective が示す概念の焼き増しにすぎず、それに造語をつけているだけですので、5 と言えると思います。いずれにせよ、新しくない内容にわざわざ造語をつけている点で未熟であり、弱い造語 であると言えるでしょう。
6 については、新しい内容に対して造語をつけています。新しい内容は、新しいがゆえに表現も難しいです。4 のように既存の単語だけで表現できるのがベストですが、できるとは限りません。造語はありえます。この場合は比較的正当でしょう。造語としては強いと思います。
7 については、既存の内容に対して、造語を含むフレーズを名付けています。 5 のとおり弱い造語でも最低だったのに、その造語を使ったフレーズを使っているのです。最悪です。私は造句（Coined Phase）と呼んでいます。
8 については、新しい内容に対して造句を名付けています。大きな概念――たとえば体系や理論といったものをつくる場合は、避けられないことも多いです。そういう意味で許容可能な造句と呼んでいます。
次に、造語マトリックスに対する一般的な解釈と、SSE における解釈を比較しましょう。
まずは一般的な解釈です。忌避される部分に ❌ をつけます。議論の余地アリには🔺をつけます。
| 既存の内容 | 新しい内容 | |
|---|---|---|
| 既存の単語 | 1（既存） | ❌2（誤解） |
| 既存の単語の組み合わせ | 🔺3（再構築） | 4（造語の回避） |
| 新しい単語（造語） | ❌5（弱い造語） | ❌6（強い造語） |
| 新しい単語も含んだ組み合わせ（造句） | ❌7（困難な造句） | ❌8（許容可能な造句） |
見ての通り、造語そのものを受け付けません。内容が新しいかどうかにかかわらず、です。そもそも内容が新しいかどうかを判断できる知識がないか、検証や議論を行うだけの時間的・認知的な余裕がありません。したがって半ば本能的に回避します。
3 については🔺をつけていますが、これは特に「既存の内容」が何らかの再構成だった場合に、受け付ける人と受け付けない人がいるということです。たとえば「開発者体験」が示す内容の一部を抽出して再構成し、それに「仕事の質（Quality of Work, QoW）」と名付けたとします。この名前を見たときに、なるほどと理解を示す人もいれば、「いや既存の再構成に新しい名前をつけただけよね……」と難色を示す人もいます。
次に SSE における解釈を見ていきます。一般的な解釈では ❌ や 🔺 だが、SSE ではそうではない部分には ⭕ をつけるとします。
| 既存の内容 | 新しい内容 | |
|---|---|---|
| 既存の単語 | 1（既存） | ❌2（誤解） |
| 既存の単語の組み合わせ | ⭕3（再構築） | 4（造語の回避） |
| 新しい単語（造語） | ⭕5（弱い造語） | ⭕6（強い造語） |
| 新しい単語も含んだ組み合わせ（造句） | ❌7（困難な造句） | ⭕8（許容可能な造句） |
いかがでしょうか。SSE でも許容しないのは 2 と 7 だけです。それ以外は許容しますし、積極的に使います。
つまり SSE は造語に関して寛容 です。もっと言えば、以下のスタンスを取ります。
これでようやく結論を言えます。
SSE に従事する者は、概念ラガードと造語アレルギーから脱する必要があります。
このとおり、SSE の従事者――ソフトスキル・エンジニアは概念を自在につくる視座を持ちます。しかし、そうしてつくった概念の新しさが疑わしかったり、その名前が造語だったりするとウケは悪いでしょう。下手すると相手にすらされません。この構図を以下のようにたとえます。
SSE は天界で概念をつくる。しかしそのままでは下界には通用しないので、下界向けに翻訳しなければならない。
そういうわけで、どこかで下界のための翻訳が必要です。これを デトランスレーション（De-Translation） と呼びます。SSE は天界にて、造語も駆使して行うわけですが、これはいわば下界の事象を天界向けに翻訳して作業していると言えます。開発を終えて、限界に戻す際は、この天界向けの翻訳を解除しなければなりません。そういう意味で de + translation と名付けています。
シリアライズとデシリアライズのようなものだと考えてください。現実の複雑なデータを、コンピュータでも扱えるようにシリアライズします。そうしてコンピュータで処理した後は、また現実の複雑なデータに戻さねばならないためデシリアライズします。あるいはエンコードとデコードと考えてください。現実のデータを扱うためにエンコードします。処理をし終えたら、元に戻すためにデコードします。
同様に、SSE においても、下界の複雑な有り様――特に概念ラガードと造語アレルギーの理に従っていてはろくに動けませんから、天界用に動きやすくします。これを翻訳にたとえています。そうして SSE を行って概念をつくり、下界に渡すときに、もとに戻します。翻訳を戻すのです。
では、デトランスレーションはいつ行うのでしょうか。ソフトスキル開発は開発 → 提出 → 運用から成るのでした。典型的には開発の終盤で行います。デトランスレーションは、ソフトウェア開発で言えばデプロイやリリースに相当します。
もちろん SSE が通じる相手であればデトランスレーションは不要です。私達開発者も GitHub にあるソースコードを直接取得して使ったりしますが、同様に、ソフトスキル・エンジニアであれば、デトランスレーションされていない状態の概念を扱えます。
ここからは SSE において重宝する Technique（全体的に Thought 寄りではあります）を雑多に紹介します。
ネーミングの方向性は以下の 5 つに分けることができます。
どの方向性にも一長一短があります。また向き不向きもあります。すでに述べたとおり、名前に正解はないので、自分に向いた方向性に頼ることで「ネーミングにあまり時間をかけず」「しかし使いやすい名前をつくる」とのバランスを確保できると良いでしょう。
大まかには芸術肌と学術肌に分かれ、芸術肌タイプは Authoritative や Attractive といったセンスが問われるネーミングを好みます。学術肌は Collective や Descriptive を好みます。Figurative については、できる人はできますし、できない人は逆立ちしてもできないでしょう。そういうわけで、思っているよりも適性が分かれます。
名前はわかりやすいものであるべき です。
わかりやすさとは「認知コストがかからない度合い」と「未来の自分を含む関係者の誰が読んでも一意の解釈ができる度合い」のことです。開発者向けに言えば可読性と冪等性ですね。言葉で言うのはかんたんですが、本当にわかりやすい名前をつくることは非常に難しいか、不可能なことも多いです。そもそも前提知識、思考体系、文化からして誰一人被ることはまずないので、基本的に全員にとってのわかりやすさは不可能と考えてください。
ひとりで開発する場合は、無論自分にとってのわかりやすさを優先します。未来の自分――たとえば一週間後の自分、一ヶ月後の自分、一年後の自分が見てもすぐに理解できるかどうかが目安になります。この素養も適性が大きく分かれますので、できない人はとことんできません。できなくても嘆く必要はありません。
複数人で開発する場合は、その概念の提唱者や主担当にとってのわかりやすさを優先するといいでしょう。理想論は全員にとってわかりやすい「奇跡のような名前」ですが、通常は非現実的です。コピーライティングなどネーミング自体が目的でもない場合は、奇跡を求めるのはやめましょう。
さて、わかりやすさがあればいいかというと、そうでもありません。私達は人間であり、怠惰で身勝手なので、わかりやすいだけでは興味や愛着を持てないことがあります。これらを持てないと、その名前が指す概念に触る機会もなくなるため何にもなりません。
そういうわけで、実は 名前は興味や愛着を引けるほど面白いものでもあるべき なのです。
面白さについては、関係者全員の同意を得るのはそこまで非現実的ではありません。大変かもしれませんが、わかりやすさほど無謀ではないのです。しかし同時に、関係者間のバックグラウンドが異なりすぎると決して交わることはありません。年間 100 本以上の映画を見る者と、ほぼ毎日アーケードで音楽ゲームに勤しむ者と、図書館で哲学の本を読むのが趣味の者とでは、面白さの指標も違うでしょう。全員が同意する面白い名前を出すのは不可能だと思います。
と、ここまで皆で揃える話をしてきましたが、面白さについても、まずは自分ひとりの目線で確保するのが良いでしょう。SSE は創造的かつ孤独な営みであり、概念という抽象的な代物をどこまで言語化し、整備できるかは、あなたの粘りにかかっています。エンターテイナーやエンジニアとは違って、目に見える反応や動作もないですからモチベーションを保つのが難しいのです。だからこそ、少しでも自分にとって面白いと感じるネーミングが非常に、非常に重要になります。
もちろん、自分にとって面白い名前が他の人にとってもそうであるとは限りません。どこかで「皆に通じる面白さ」や「わかりやすさ」に寄せた名前を再検討することになるでしょう。それでも、その段階に至る前の、孤独な営みのお供として「自分にとって面白い名前」は最適なのです。
このように名前にはわかりやすさと面白さの軸があり、最適なバランスを探らねばなりません。
名前駆動開発 とは、先に名前を決めてから、その内容を考えたり構成要素を整備したりする開発の仕方を指します。
例として、私が開発したソフトスキル・ツリー「5C」を見てみましょう。再載しますが、5C は以下のとおりです:
A <-> BA <-> Output <-> Bこの概念も名前駆動開発でつくっています。
まず私は Communication、Collaboration、Consolidation の 3C をつくっていました。コミュニケーションという「1 対 1 の直接的なやりとり」だけでは限界があると思っていて、パラダイムシフトが必要と考えたからです。そうして、わかりやすさのために C- 始まりの言葉を使って、第三世代までつくることにしました。そうして Communication → Collaboration → Consolidation という 3C をつくりました。
さて、ソフトスキル・ツリーをつくるにあたって、私はこの 3C をベースにしようと考えたのです。3C だけで広域なソフトスキルをカバーするのは明らかに難しいので、もう少し増やしたい、しかし統一性も欲しい――というわけで 枠を二つ追加して 5C にしました。そうなると、あとは C- から始まる要素を二つ考えるだけです。
いかがでしょうか。C- から始める根拠もないですし、5 要素でなくてはならない絶対的な論理もありません。単にわかりやすくて、収まりも良さそうだから、くらいの軽い理由です。これでいいのです。
SSE には正解が無いのでした。ベストエフォートでそれなりの概念をつくれればそれでいいのです。根拠だの論理だのと完璧主義を患っていると何もできませんし、実際そのせいで人類は未だに概念をつくる視座に立てていません。開発した概念はその後の提出と運用で検証すればいいだけです。ソフトウェアやビジネスと同じで、最初から完璧なものをつくるくらいなら、さっさとつくって出すべきなのです。もちろん科学や哲学には厳密な論理が必要ですが、SSE はそのどちらでもありません。
SSE に慣れ親しみたいのであれば、名前駆動開発を試すのが一番です。
名前を先につくりましょう。そして、自らの創造性を総動員して、その内容を詰め込んでいましょう。そうしてつくった概念を共有してみましょう。使ってみましょう。議論してみましょう。そうすることで、SSE という新しい世界の営みに慣れることができます。
ネーミングを考える上では、言葉の正確な意味やニュアンスを知る必要があります。これを 定義の収集 と呼びます。
例:
以下トリガーリストもご活用ください。
- あなたが考える、その言葉の定義を書いてみましょう
- その言葉の辞書的な定義は調べましたか？
- その言葉の、オリジナルの定義や由来は調べましたか？
- その言葉の、主要な人物や団体の定義は調べましたか？
- 定義を収集した上で、あなたはどのような意思決定をしたいですか？
- 既存のいずれかの定義に従いたいですか？
- 既存の定義を上手く良いとこ取りしたいですか？
- 独自の定義をつくりたいですか？なぜその必要があると考えますか？
ある言葉 W1 と W2 のどちらを使えばいいのか、といった迷いはよく生じます。このようなときに使えるのが、ニュアンスの違いを比較することです。
生成 AI に尋ねるだけで良い です。ソフトスキル開発は絶対的な正解や論理をつくりたいのではなく、ヒントを集めた上で、有益そうなものをつくりたいのです。ヒントがわかればいいので、回答の正しさはさほど気にしなくてもいいですし、正しさに関してもすでに大多数の人間よりも正しい可能性が高いです。
例:
違いを尋ねていくことで、細かいニュアンスを比較できます。ご自身のネーミングをどうつくればいいかの方向性が定まるでしょう。厳密なニュアンスや定義は、その後に調べたり聞いたりすれば済みます。
SSE で扱うのは概念であり、概念は抽象的なものですが、抽象だけでは開発は上手くいきません。抽象と具体を行き来することで、より理解しやすく精度も高い概念に仕上がっていきます。
問題は具体を集めるのが難しいことです。理想論を言えば顧客を捕まえて検証させることですが、これはビジネスやエンジニアリングの発想であり、概念は常に検証できるとは限りません。むしろ「検証できる概念」は、概念全体のごく一部でしかなく、これがそのままビジネスやエンジニアリングの限界となっています。SSE はこの限界を打ち破り、概念の世界で思考と検討を行うための、新しい武器です。検証の呪いにとらわれないでください。しかし、それでも具体は必要なのです。
アプローチは三つあります。
これだけとわかりづらいので、具体例を一つ挙げた上で実践してみましょう。
たとえば私は DevEx（開発者体験）、DevRel（開発者との良好な関係性の構築）の他に、DevDEI（開発者のDEI）という概念をつくっています。では DevDEI とはどのようなものでしょうか？どうやってこの概念をつくりこんでいけばいいのでしょうか？――無論、具体と行き来するわけですが、この作り方が三つあるのです。
1: 自分の体験を当てはめる
具体: 私はニューロダイバージェントであり、職場やチームの配慮が足りないと感じる事が多いです。特にチームは長いコアタイムや頻繁な会議を要請しますが、私は 6:00 ～ 15:00 という朝型のライフスタイルに最適化しており、これを崩したくはありません。わがままではなく、この最適化がないと仕事にならないのです。しかし通じることはありませんでした。
ちなみに、この具体から抽象に戻ると、たとえば「朝型のメンバーにも配慮したチームづくり」「複数の勤務時間パターンが共存できればいいのではないか」「長いコアタイムと頻繁な会議に頼るという “一つのあり方” がある」といったことを導けます。
2: 自分または他人の想像により具体をつくる
たとえば「DevDEI が浸透したチームの一日」をテーマにブレストをしたり、軽い SF プロトタイピングをしてみたりするといいでしょう。おそらく DevDEI の捉え方からして人それぞれなはずで、だからこそ多様な意見が出るはずです。
3: 生成 AI に具体をつくらせる
GPT-5.2 に「DevDEIの具体例をつくって」をお願いしてみました。その結果を軽く見てみます。
一見すると当たり前の内容にしか見えませんが、だからこそ理解しやすく、さらに思いつくこともたくさん出てくるでしょう。また自分が知らない言葉が出ることもあり、追加で調べることで知見が広がります。たとえば Architecture Decision Record が何かを知らない場合は調べてみてください。
ちなみに上記を見た私の感想は「読み書きベースのあり方を追加でインストールすれば良さそうだ」です。
より大胆に踏み込むなら、DevDEI を「読み書きだけでも仕事と評価を完結させるという考え方、また方法論」のように定義できるでしょう。そうなると、次は具体として「読み書きを上手くやるための技術や方法」を出せます。