「イケてるエンジニアはココが違う！」をテーマに技術的で意識高い系の記事を投稿しています。この記事が「面白かった！」という方はフォローまたはスキしてもらえると嬉しいです。Twitterで共有ツイート頂ければソッコーでRTします。

これまでの振返りと今回の内容

以前、こちらの記事で私達エンジニアはユーザの課題を解決するストーリーを「ユースケース図」や「ユースケース記述」を使って描く、”脚本家”であるというお話をしました。

今回は、その脚本を具体化するデータアーキテクチャ設計の３つのポイントをお話します。

✅　ユーザに表示するデータこそが解決策である。
✅　ユーザが使う言葉を理解してデータを設計する。
✅　ユーザの深層心理を理解してデータを設計する。

ユーザに表示するデータこそが解決策である。

まず、システムがユーザに提供する解決策とは、具体的になんでしょうか？

それは、画面に表示されるデータに他なりません。データアーキテクチャ設計では、まず、ユーザに表示するデータを決めていきます。

ユーザは自身の課題を解決するために、画面を通してのみシステムと対話します。ほとんどの場合、ユーザの課題は「ある特定の状況において最適な意思決定をすること」です。ユーザは最適な意思決定をするための根拠となるデータを見つけるために、画面にアクセスしています。

そのため、システムはユーザの思いを先回りして、その意思決定をサポートするデータを画面に用意しておく必要があります。

システムがこのようなデータを表示できるようにするために、私達エンジニアは「誰がどんな状態ときに、どんな意思決定をするのか？」を理解し、「何を表示するのか？」と「どのように表示するか？」を設計しなければいけません。

何を表示するのか？

まず、「何を表示するのか？」です。設計のポイントは「ユーザはどんな意思決定をするのか？」を理解することです。

例えば、お天気情報アプリの場合、ユーザの「朝、出かけるときに傘を持っていくべきかどうか？」という意思決定をサポートしています。そのために、その日の天気と降水確率を表示していると考えていいでしょう。

このようにユーザの意思決定をサポートするデータを設計しなければいけません。

どのように表示するか？

次に「どのように表示するか？」を考えます。

個人的には「どのように表示するか？」の設計は「何を表示するのか？」よりも難しいと考えています。その理由は、ユーザの意思決定をサポートするためには「正しい」だけでは不十分であり、「伝わる」ことが求められるからです。

例えば、お天気情報アプリが、その日の天候として「雨雲の動き」のみを表示していたらどうでしょうか？「正しい」データではあるものの、多くの人にとって「伝わる」データでありません。そのため「朝、出かけるときに傘を持っていくべきかどうか？」という意思決定をサポートすることができません。

ユーザにデータを「伝える」ためには、ユーザの知識レベルや置かれた状況を高い解像度で理解し、どのような加工を施すべきかを考えなければいけません。

私達エンジニアはユーザが意思決定する場面、例えば「朝の慌ただしい時間に、30代のサラリーマンが焦りながらスマホをチェックしている場面」をリアルに想像し、「雨雲の動きだけじゃだめだ。もっと簡単にその日の天気がわかるよなアイコンを使って表示しよう。」と、データの加工まで意識を巡らせる必要があります。

「どのように表示するか？」は、高い解像度でユーザを理解し、ユーザに伝わるデータを設計する必要があります。

ユーザが使う言葉を理解してデータを設計する。

ただ、「ユーザの理解」と言われても、どのような状態になっていればユーザを理解したことになるのか？また、どのように理解すればいいのか？実践はとても難しいと思います。

そもそも、私達エンジニアがユーザと対面するとき、それぞれの関心事は違います。エンジニアの関心事は「システムを構築すること」で、ユーザの関心事は「自身の課題を解決すること」です。なので、プロジェクトのキックオフミーティングの時点から、エンジニアとユーザの間にはギャップがあると考えたほうがいいでしょう。

この前提において、私達エンジニアはユーザとのギャップを乗り越えていく努力を惜しんではいけません。

そして、ユーザ理解の具体的な方法が示されているのが『現場で役立つシステム設計の原則』です。

本書では、その名の通り「現場で役立つ」オブジェクト指向をもとにしたソフトウェアの設計原則が、実践的かつ具体的に解説されています。エリック・エヴァンスの名著『ドメイン駆動設計』のエッセンスを分かりやすく取り込んみ、実践的な内容がまとまっています。同僚にも薦めまくっている書籍です。この中で、以下のような設計原則が紹介されています。

ここでの「ドメイン」とは「ユーザの業務」、「オブジェクト」とは「データとロジックをまとめたもの」を指し、「ドメインオブジェクト」は「ユーザの業務を実現するデータとロジックをまとめたもの」という意味になります。

つまり、ユーザが業務で使っている言葉を理解し、その言葉をそのまま使って設計および実装を行うことが基本であると述べられています。

ただ、この原則を守ることには、苦心するかもしれません。ユーザが業務で使っている言葉、チンプンカンプンの専門用語をユーザよりも理解し、業務を実現するためのデータとロジックを整理していかなければいけないからです。「はやくシステムを構築したい」という気持ちを抑え込みながら行う、大変な作業です。

しかし、それだけ手間を掛けることで、ユーザの課題を確実に解決するシステムを構築することができます。さらに、ユーザ業務の変更に伴うシステム改修の場面でも、改修箇所を容易に特定できるため、エンジニアにとっても保守性のよいシステムになります。

「ユーザの理解」の第一歩はユーザが使う言葉を理解することです。そして、ユーザを理解し構築されたシステムは、ユーザとエンジニアの両方にとって嬉しいものになると言えます。

ユーザの深層心理を理解してデータを設計する。

ただ、ユーザの言葉を直接聞くことができない場面も少なくありません。例えば、BtoCやユーザが存在していない新規ビジネスの場合、私達エンジニアはどのようにしてユーザの言葉を理解すればいいのでしょうか？

そのアプローチとして、非常に難しいものの効果的であろう思われる方法があります。それは、私達エンジニアが「ユーザの意思決定プロセスを自分自身が再現できるレベルまで理解する」というものです。私達エンジニアが、ユーザの深層心理に共感し、ユーザに憑依している状態になるという方法です。

一般的にこの方法は「デザイン思考」と呼ばれ、マーケティングの文脈で紹介されることも少なくありません。

「じゃ、その『デザイン思考』とやらを体得すれば最強じゃん！」と思われるかもしれません。実際、私自身「デザイン思考」の話を聞いたときは、そのように感じました。

しかし、「デザイン思考」を体得するのはなかなかに難しい。私がオジサンだということを差し引いても、相当の訓練が必要ではないかと感じました。なので、私達エンジニアがいきなり「デザイン思考」を学ぶことはあまり効率的ではないと思っています。

忘れてはいけないのは、データアーキテクチャ設計の目的は「ユーザに表示するデータを決めること」です。「デザイン思考」はその強力な手段ではあるものの、手段の体得が目的にならないように注意が必要です。

まずは、『現場で役立つシステム設計の原則』で紹介されいる手法を実践したり、ER図の作成したりしてデータ設計を行い、システムを実際に動作させるという経験を積むことのほうが先決です。

その上で「デザイン思考」を体得することは有効です。学問的な理解で終わらず、再現性高く実践できる思考法として、大きな武器になるはずです。

そうなれば、私達エンジニアは、ユーザーの深層心理とシステムが心地よく連携、協調している姿をイメージできる境地にたどり着けるんじゃないかと考えています。

そして、この境地に達した「イケてるエンジニア」の関心事は「システムを構築すること」ではなくなり「ユーザとシステムを繋ぐこと」に昇華しているでしょう。ユーザに憑依して、頭の中でユーザの深層心理とシステムのデータアーキテクチャをカチッカチッと丁寧に繋ぎ合わせているはずです。

私もそんな境地に到達したい！では、また！

まとめ

✅　ユーザに表示するデータこそが解決策である。
✅　ユーザが使う言葉を理解してデータを設計する。
✅　ユーザの深層心理を理解してデータを設計する。

参考文献