久しぶりにテックブログを担当します、会計決済チームのsimonです。
はじめに
ソフトウェアの設計をしていると、言いたいことはあるのに言葉にならないことがあります。
頭の中ではおぼろげに形を持っているのに、口を開くとうまく輪郭を与えられない。「ちょっとうまく言えないんですけど」と前置きして、案の定うまく言えないまま話し終えてしまう。自分にはそのような経験が大いにあります。
この記事では、設計段階で『うまく言葉にできない』と感じる人に向けて、言語化を設計スキルとして捉え、鍛えるための具体的な方法を紹介します。
最近、言語化の重要性を感じる機会が増えました。また、同じ考え方に賛同してくれる人が現れたことで、言語化に対する自分の考えを書いてみることにしました。詳細な設計・実装に入る前の整理を軽くやっちゃってるな、とか、言いたいことがあるけど思ったとおりに言葉にできない、といった人の参考になるなら望外の喜びです。
設計は「5W1Hで答えること」から始まる
誰かの課題を解決するウェブサービスを設計しようとするなら、
- 誰が（Who）
- なにを（What）
- いつ（When）
- どこで（Where）
- なぜ（Why）
- どのように（How）
できるようになるべきなのか、5W1Hの形式で答えられる必要があります。
5W1Hで記述できる、ソフトウェアに対するユーザーの要望をユーザーストーリーといいます。ソフトウェア上でタスクを達成することを通じて、ユーザーの要望がかなえられる。ユーザーストーリーはそういう粒度の話です。
ユーザーストーリーは、設計者が思いつきで整理できるわけではありません。まずはユーザーが使うソフトウェアとユーザーの属性、そしてユーザーがソフトウェア上で達成できるタスクを図示してみると考えやすいです。タスクの整理・議論のためにユースケース図のようなものを作るケースも多いでしょう。本文の趣旨に反するので詳しく取り上げませんが、UMLなどを用いることが多いと思います。
さて、ユーザーストーリーの議論に入って図や文章を書き始めてみると、色々なことに気づきます。この半年ほどで経験した中に、いくつか心当たりがあります:
- ユーザーストーリーの設計の中で、共有の概念も決めてしまってよいのか？
- 「プランを変更する」とは、一言でいうとなにか？
- 売上と債権はどう違う？関連があるのか、ないのか？
このような問いは、もちろん状況によりますが、見落とされがちだと感じます。
設計に登場する言葉が目に見えなかったり、手で触れられないような抽象的な概念を指すサービスほど、概念を表現する言葉の取り扱いの重要性が際立ってきます。ユーザーストーリーレベルの設計に入ったときに、さきに挙げたような問いがチーム内で繰り返し発生したり、実装段階で設計同士の齟齬に気がつくといったことも、ままあります。
そのような事情を鑑みると、設計段階における「言語化」は設計の技術です。技術であるからには鍛錬できるものでもあります。
それでは、設計における言語化の技術は、どうすれば鍛えられるのか。それを「言語化」してみます。
設計における言語化
設計に登場する概念を言葉にする作業は、日常生活におけるそれとは異なる性質を持っていると思います。設計における言語化の技術は2つの要素を要求します。
- 抽象化/具体化の思考技術
- 言語運用能力
2つの技術は不可分に結びついています。考えたら言葉にする、言葉にしたらまた考える。このプロセスを経て概念レベルの設計の練度が高まります。
国語力ではないのか？
言語化というと言葉にする力のことだから「国語力」が想起されるかもしれません。しかしソフトウェア設計の文脈では、抽象化したり具体化したりする思考の技術が同じくらい求められます。
システム開発者は、実現方法を考え、形にすることを生業とします。だから、詳細を緻密に考えることに長けている。しかし、ユーザーの達成したいユーザーストーリーレベルの設計では、ユーザーやユーザーが達成したいタスクを思考しなければならず、思考のレイヤが異なります。
実装段階では最具体、例えば「ユーザータイプAが条件XかつYのときにデータα、βを作れる」ことの達成が求められます。いっぽうでユーザーストーリーレベルの設計では、「利用者属性Aの人が課題Pを解決できる」といった抽象度で設計、議論されることになります。
以上を総合すると、設計の段階に応じて取り扱う対象の抽象度が異なり、その差異を自覚して思考しなければいけない、ということになります。
日本語は難しい
自身の経験からも、言語化が難しいと感じるケースの多くは抽象化に失敗してしまっています。少ない具体から抽象化してしまったり、抽象概念を前提にしてしまっていたり。たとえば、「このデータを管理できるようにする」という要件があったとして、「管理」が閲覧・編集・削除のどこまでを指すのか曖昧なまま設計を進めてしまう、といったことです。
したがって、適切な抽象化・具体化の思考は言語化のための前提条件です。
とはいえ、適切に抽象化できたら適切に言語化できる、とも言い切れません。人間は言語を使って思考し、また多くの日本人は思考の言語を日本語にしています。したがって、日本語を適切に運用することもまた、思考の技術と同じくらい設計の精度を左右する要素だと思います。
日本語で文章を書くことは難しい。こんな記事を書きながら、自分の日本語が良く書けているなどとは到底思えません。そこで、私は昔から発想を変えています。日本語の文章が難しいなら、日本語で文章を書かなければ良い。ただし、日本語を放棄しようという話ではありません。
この発想に立つと、日常生活においては支障が出ようが、設計においてはそうではありません。ソフトウェアの設計はユーザーストーリーや概念を言語化できれば良くて、そのためにはたんに5W1Hの形式で答えられれば十分です。
いきなり日本語で書かないというのは乱暴にすぎるかもしれません。この方法は、後ほど触れます。
言語化力を鍛える
ここまで、私なりの経験を踏まえて、言語化に必要な要素を簡単に説明してみました。ここからは、言語化力を鍛えるための方法を4つ紹介します。
最初に断っておくと、思考・言語化に関する書籍は世の中に腐るほどあります。本格的な学びを得たければそういった書籍を参考にするのが良いです。自分が紹介する方法は体系的なものではなく、個人の経験に基づくちょっとした手掛かりといったところです。
ペンで書く
私はぼんやりとした設計などの考え事をするとき、必ず紙にペンで書きます。
紙とペンを第一の得物とする理由は、まず自由度が高いからです。例えば、「ユーザーストーリーAを達成するのにどのような条件を満たすべきだろう？」という問いから、ぼんやりと紙に書き出していきます。書く前に想定した前提条件X, Yまで書いてみたところで、ふと全く違う要素Eの存在に気づくことがあります。紙だったら、適当に書き出して矢印で繋いで連続した論理を作れます。
そして、紙とペンの第二の優位性は、突如思考が降って湧くことがあることです。自分でも原因はわかっていませんが、紙とペンで書いていると考えたことのない第三、第四の案がふと湧いてくることがあります。これはデジタルサービスでは代替できないことで、NotionやCosenseといったツールではかないませんでした。手を動かすことが思考を引き出す、としか今のところ説明のしようがありません。
紙に書き出してみるときは、細かいことは気にせず、思いついたことをできるだけ短時間のうちに大量に書き出すことを意識します。この作業を通じて「考えを言葉にする」力を鍛えます。一度書いて、もうこれ以上出せないところまで書き出せたと思ったら紙の作業を終えます。そこまで辿り着いたら、おそらく自らの思考限界に達しているはずで、そうしたらNotionなどに清書して終了です。
「つまり？」「例えば？」を繰り返す
人間は問いを立ててそれに答えることで行動、生活する動物だそうです。そう言われてみれば、確かに身に覚えがあります。「今朝もご飯で良いかな？」「そろそろ昼ご飯にしようかな？」「寝る前なにを読もうかな？」と、些細な問いを無限に立てては答え、行動していることに気が付きます。
この性質を利用して、業務にあっては問いの質を意識しています。
例えば、決済ドメインのコードがメンテナブルではなくて、複雑な原因を明言できる状態でもないとします。なお、自分の経験から、金銭を扱うドメインが単純になることはまずありません（笑）。この時点では、最終的になにをすべきか、具体的な手法にまで思考が至らないはずです。そんなとき、自分なら問いからはじめてみます。こんなところでしょう──「メンテナブルとはどんな状態なんだろう？」「メンテナブルな状態に必要な要素はなんだろう？」
自分がよく使う問いは「一言でいうとつまり？」と「例えば？」の2つです。これらはとりもなおさず抽象化と具体化の技術と軌を一にしています。
自分で立てた問いに自信を持って答えられたら良し。うまく答えられなかったら問いを変えてみるか、あるいは思考限界に達しているかもしれません。答えの輪郭は見えているのに言葉にできない、そんなときは頼れる人に話してみます。自分では答えを出せなくても、誰かと話しているうちに自然と導出されることがあるからです。
日本語の語彙を増やす
言語化力を高めようとしているのだから、基礎になる語彙は言語化の基本でしょう。語彙が思考を明瞭にしてくれると感じるのは、「例えば？」に答えるときです。具体例を挙げようとしたとき、適切な言葉が手元にあるかどうかで説明の解像度が変わります。
語彙を増やすために意識していることがあります。それは、技術書以外の本を読むことです。エッセイや文芸評論などを好んで読みます。技術書は正確さを優先するため表現の幅が限られますが、エッセイや評論は同じ事象を多様な角度から言い表しています。こうした文章に触れていると、自分の思考を言葉にするときの選択肢が広がる感覚があります。設計の場でも、語彙が増えることで説明できる概念や事象の幅が広がります。
もう一つ、読書中に見慣れない日本語に出会ったら国語辞書を引くようにしています。大人になると辞書から遠ざかってしまうものですが、語彙は一朝一夕に身につくものではないので、日常の中で少しずつ蓄積するしかありません。設計の言語化に限らず、語彙の引き出しが増えると「あの概念を一言で表すなら」という問いに答えやすくなります。
英文で書いてみる
論理の破綻がないかを問うフレームワークがあると便利です。そして5W1Hは文章に明快な論理が揃っていることを保証してくれます。一文に必要な5W1Hが揃っているかを確かめるために、私は英文で書けるかを考えることがあります。英文が便利な理由は、品詞毎の明確な語法と語順を要求するからです。
例えば、日本語で「管理サイトで決済をかける」という仕様に落ち着いたとします。日本語では主語と客体が抜け落ちており、アクションのみがわかっています。これを英文にすると、例えば
The administrator charges users the fee.
などになるでしょうか。元の日本語では曖昧になっていた主体と客体の関係が明確になることがわかります。
英文を想起するのは、不自然な構造にならないかを確かめる程度に使います。もっとも、元の日本語文の論理が明快であれば、このテクニックは不要です。
超個人的推薦図書
ビジネス書として有名な、問題解決系の書籍は言わずもがな、役に立ちます。そこで、あえてそれらを外して少しニッチだけど記憶に残ったものをご紹介します。
- ゼロ秒思考 頭がよくなる世界一シンプルなトレーニング
- 「紙にペンで書く」習慣を身につけるに至った一冊。書かれているトレーニング法が、そのまま紙とペンで書く習慣の基礎になりました。
- 「好き」を言語化する技術 推しの素晴らしさを語りたいのに「やばい！」しかでてこない
- いつも考えていたことを一冊にまとめたような本でした。この記事は、『好きを言語化する技術』にインスパイアされたといっても過言ではありません。「やばい」です。考えを文章にできなくて難儀している人におすすめ。
- 良い質問をする技術
- 適切な言語化は適切な問いから始まることを学んだ一冊。問いの質を高めることは、単なる技術にとどまらず行動も変えてくれます。
- アナロジー思考
- 本書の主題は類推にありながら、類推の基礎を成す、抽象と具体は無限の階梯であるという性質をよく理解できます。問題解決思考系の書籍で論理の組み立てを学んだ後本書を読むと、抽象化思考の技術の応用可能性を実感できます。
おわりに
設計における言語化は、日常の「言葉にする力」とは少し異なる技術です。抽象と具体を行き来する思考の技術と、それを適切に言葉に落とす言語運用の技術。この2つが噛み合うことで設計の精度は上がります。
紙とペンで書くこと、問いの質を意識すること、語彙を増やすこと、英文で書いてみること。紹介した方法はどれも特別なことではありません。ただ、意識して続けると「言いたいことが言葉にならない」場面が少しずつ減っていく実感があります。紹介した方法のうち、どれか一つでも設計を前に進める手掛かりになれば幸いです。
自分もまだ、自由に言葉を操れるようになる途上にいます。
💁 関連記事
