こんにちは。アシアル広報チームです。これまでも様々なメンバーがクライアントとのコミュニケーションについてお話ししてきましたが、今回は「社内一、クライアントニーズを深掘りする」と囁かれるエンジニア“深掘り名人（以下、名人）”が登場。過去の事例に触れながら、自身のコミュニケーション術を紐解きます。

どんどん聞いて明確にし、認識を共有する

「自分としては、深掘りしているつもりはないんです」と言う名人。ただ、「聞いた話の整合性がとれているかとか辻褄が合うかとか、そういったことは気にするタイプですね」とも。よって、クライアントとの打ち合わせなどでも、「辻褄が合わないこと、おかしいなと思ったところはどんどん聞いて明確にしていく。それが結果的に、深掘りといわれるものになっているのかなと思います」。

では、実際に名人がシステムやアプリ開発を進める中でとるコミュニケーションについて、探っていきましょう。

「流れとしては、あたりまえのことなんですけど、まず依頼内容をお聞きして、それを理解することから始めます。ただ、言葉だけでは、理解が食い違う場合が往々にしてあるんです。

そういうときにどうするかというと、お客様が言っていること、システムが対象とするもののドメイン構造＝概念構造を明らかにしていきます。

具体的には、業務の中でどんな単語が使われているのか、その単語がどういう意味で、単語と単語のつながりがどういったものなのか。この言葉の構造、概念を明確にするんですけど、中にはそんなことをしてどうするんだと言われるクライアントも（笑）。でも、それが頭の中にあると、その先の話がすれ違うことを防げますし、辻褄が合っているかどうかの判断もできるんです。逆にいえば、それがずれているとクライアントの期待とまったく違うものができてしまいます。

概念構造とかドメイン構造は言葉と言葉の関係なので、エンジニアじゃなくてもわかる。言葉と図（ドメインモデル）を使って、その構造、お互いの認識を共有するところから始めます」

▼ドメインモデルの例。ユーザーの書籍購入履歴を示しています。

クライアントと考え方や概念を一致させる

ドメインモデルを描き出していくと、「面白いことに、足らない単語が出てくるんです」と名人。それは、クライアントがアシアルに伝えていない単語。もしくは、別の単語で表していることもあるといいます。

また、ドメインモデル上に出てきた複数の単語が、同じ意味を持っている場合も。そういったときは、一つにまとめる。そうして「漏れなく、無駄なく、システムにしたいもの全体の構造を作ってから、画面を考えたり、仕様を考える工程に入っていきます」。

「これら上流の工程の中で、一番大切だと思っているのは、考え方や概念をどうやって一致させるか、認識するか。もれなく無駄なく出てきているかを明確にすること、技術者以外でもわかるような形でお互いに認識していくことが重要だと考えています」

ドメインモデルでより明確に

名人がドメインモデルを作るようになったのは、『ユースケース駆動開発実践ガイド』を読んでからだそう。

とはいえ、「言葉をまとめるとか、その言葉がどういう概念かみたいなことを考えるのは、たぶん昔からやっていたと思います」と言う名人は、「例えばAとBがどうつながっているかを図に描いて理解するということをよくしていたんです」とも言い、考え方のベースは『ユースケース駆動開発実践ガイド』を読む以前からあった様子。

それを「システム開発の中でどうやって活かすのかとか、コミュニケーションをとっていくのかということは、この本の……丸ごと全部これをやると大変なので、全部じゃないですよ？　必要な部分だけを抜き出して、何度も使っているうちに辿り着きました」。

ドメインモデルを作ることで、「この画面はいらないよね、この機能はいらないよね、っていうことが出てきたり、全体としてバーチャルな空間の概念と物理的な空間の概念がごちゃごちゃになっているから別々に、というような話をしても、お客様の中で納得しやすくなります。そこから、次の画面が提案できたり、新しい機能を提案するといったことも可能です」。

頭の中にあるものを具体的な形にする

概念を整理して具体的な形にしていくのが自分の仕事だという名人。実際にどんなことをしているのか、事例を見てみましょう。

【事例１】ALSI様の依頼内容は……

昨年12月に紹介した、アルプス システム インテグレーション（ALSI）様の事例に名人も携わっていました。

・依頼内容：『BIZUTTO経費』モバイル版の一部機能開発
『BIZUTTO経費』は、サブスクリプション方式の業務効率化ソリューションである『BIZUTTO（ビズット）』シリーズの第一弾で、PCとモバイルに対応しています。アシアルは、モバイル版の開発をお手伝いしました。

・名人の役割
ALSI様は、「やりたいことを明確にお持ちでした。APIもあって、PCの画面の形もありますし、スマートフォンの画面遷移もこんな感じにしてほしいというイメージもありました」。ALSI様のように、依頼時点で解決したい課題や目的が明確なクライアントが多いアシアル。

「クライアントがちゃんとした考えを持っている場合は、そんなにいろいろ引き出すことはありません。余計なものを追加すると、逆に邪魔になる場合もありますから。たまに、どんどん提案してほしい、みたいな方もいらっしゃるので、ケースバイケースですけど。

我々は、相手の頭の中にあるものを具体的な形にすることが仕事です。イメージが明確な場合もあれば、まだなんとなく概念が集まっているだけという場合も。そこを明確にしていくことが僕の仕事だと思っています。そこから先の使い勝手をよくするとかUIに関しては、アシアルにはすごいデザイナーがたくさんいるので、そっちに投げちゃいますけどね」

【事例２】S社様の依頼内容は……

それほど引き出すことは多くないという名人ですが、あるクライアント・S社様では、業務フローに誰がどのように関わっているのか、関わる人たちの1日の動き、数字がどのように受け渡され管理されているのかなど、細かな部分まで洗い出されたとか。

・依頼内容：営業状況の統合管理・分析システム開発
　-　データベース(以下、DB)を1から作る
　-　PCとモバイル、どちらからもアクセスできるようにする
　-　外部からもアクセス可能なものと、社内からのアクセスのみ可能なものとを作る

・名人の役割
S社ご担当者様によれば、名人の洗い出しによって気づいていなかったニーズが見つけられた、聞いてもらってありがたかった、とのこと。

「S社様とは、まず担当者の頭の中にあることを見える形にまとめていくという作業がありました。そこで要件として聞いていた業務フローに間違いが見つかったり、僕の言っていることが実際とは違っていることがわかったりして、共通認識を明確にしていきました。その中でユーザーの役割とか関係性って絶対に必要なんです。

使い手が誰で、その人たちがどんな役割を持っているのかを知らないと、そもそもシステムは作れません。DBの構築から始める場合は、そこに入る値がどこからどのようにやってくるのか必ず確認すると思いますが、それも図を作っていく中で出てきます」

結局名人は深掘りしているのか？

今回のインタビューのテーマを名人に伝えた際、「深掘り」の定義を確認されました。

そんなふうに名人は、キーになる言葉に注目し、定義を追求します。また、「ある画面の中にこんなデータを表示したい」という話になったとき、そのデータをどう配置するか、どう見せるかから考える人がいる一方、名人はまずそのデータがどういう状況ででき、どういう流れで存在することになるのかといった、データの作られ方や保存方法まで明らかにしてから画面を考えます。それが結果として深掘りに。

「システムって結局、データをどこから入れて、どう活用していくかなんです。そのやり方を、どうやって相手と認識を合わせるか。それがいちばん大事なことだと思いませんか？」

イラスト／マツキヨコ（アトリエ・マツ）

▼顧客への理解を深めるために工夫しているメンバーのお話はこちらにも。