つくらない職種の人ほど、目的より機能の話をしたがる現象について

先日、アプリ開発の現場で、エンジニアさんと「原因はなんでしょうねー」と、ちょっぴり盛り上がった「つくらない職種の人ほど、なぜか目的より機能の話をしたがる」現象についてを、今日は書きたいと思います。

1.現場あるある 「で、その機能をつける目的は？」

私は、UXデザインを生業としているので、新規サービスの開発や、既存サービスの見直しつつのリニューアルやら機能追加やらのお仕事をする機会が多いのですが、いろいろな職種が関わってひとつのサービスを作ろうとすると、こんな現象をしばしば目にします。

みんながみんな、こんな会話をしている訳ではないと思いますが、こういった会話が発生している現場で発言者を見てみると、前者が営業さんや企画職の方など、つくらない職種の方、後者はエンジニアであったり、デザイナーであったり、いわゆる「つくる人」たち、という具合に分かれがちなので（少なくとも私は逆は見たことがない…）、私はおもしろい現象だなぁと思って、（自分がツッコミ役でない時は）しばらく観察をしています。

2.原因①日常使っている言葉の粒度が違う

原因のひとつとして、日常使っている言葉の粒度が違うことが考えられるのではないかと思っています。

企画職や営業職は、言葉自体で仕事をする人です。「どういった企画なのか」や「販売している商品はどういったものなのか」など、言葉で説明をします。

その企画や商品が、顧客のニーズに合っているか、お金を払うに値するものなのか、納期はどれくらいなのかを、説明することの方に力を割かなければいけません。

その際に、話をする相手も同じ粒度の言葉で話をするケースが多いので、その企画や商品が、具体的にどういった手順でどのように作られるか、詳細な説明を求められることはあまりないでしょう。むしろ、「細かい話をされてもわからないので、要点だけわかればいい」という方が多いのではないでしょうか。

すると、自然、言葉は抽象的なものになっていきます。
例えば、「UXデザインを行い、仕様書、ビジュアルデザインを納品します」というような粒度の言葉です。

対して、エンジニアやデザイナーは、言葉を別のものに変換する人です。

先ほどあげた「UXデザイン」「仕様書」「ビジュアルデザイン」という言葉の粒度のままでは仕事になりません。それぞれの要求を要件に落とし、具体的に仕事を進めなければなりません。

「こんなことをしたい」というやや抽象度の高めの要求を、どういった方法論で実現させるのか、具体的な手段は何を使うのか、自分の専門領域の知識や経験を駆使して変換していきます。

特にキャリアがある人ほど、引き出しの数が多かったりするので、目的さえわかれば、コストや納期、環境、実現可能性などの様々な制約条件を踏まえ、最適の方法と手段を導き出してくれます。

例えば、「音声入力」という言葉にたどり着く前に、こんなことを考えます。
・ユーザーは何をしたいのか
・最終的にどんな状態になったら、達成できたと言えるのか
・ユーザーはどんな状況・環境でそれを使うのか
・どんなリテラシーの人が使うのか
・何の情報を入力するのか
・入力した情報は何にどう使われるのか
・合わせて取得しなくてはいけない情報はあるか
・取得した情報はどういった管理が必要か
などです。

つくる人たちにとって、「音声入力」などの機能名は、こういった、様々な具体的なことを検討した上で、候補の中から最終的にたどり着く手段なのです。

抽象化された言葉で仕事をする人と、具体的に様々なことを検討しつくる人。もし、この両者がコミュニケーションを取らずに、自分たちの領域の仕事だけをするとどうなるでしょうか？

おそらく、この図のように、つくるのに必要なものがない状態になるかと思います。

箱のラベル自体はあってるので、大丈夫だろうと思ったら、細かい内容（要件）が詰められていなかったので、いざ、つくる段階になって、必要な素材が足りていない・検討されていない、なんてことが発覚したりします。必要な素材が足りなければつくれませんから、本来開発がスタートしているべき時点で素材集めや、方法論の再検討が必要になり、そういった不足部分が多いほど、開発工程はデスマーチになっていきます。

日常使っている言葉の粒度がお互い違うので、やり方の型化ができていない現場では、きちんとコミュニケーションを取らないと、こういった齟齬が起きやすくなってきます。

3.原因②つくる際の方法論の引き出しを持っているか否か

それから、もうひとつの原因として考えられるのは、つくる際の方法論の引き出しを持っているか否かです。

上図は、戦略とプロダクトや、機能が繋がっていないクライアントと戦略から目線合わせをする際に説明に使っている図です。

Whyは目的、HowはWhyを達成するための方法論（具体的な手段ではなく、やや抽象度高め）、WhatはそのHowを実現するために具体的にどんな手段を使うかです。

ビジネス（事業）、サービス、プロダクト、機能、それぞれにWhy、How、Whatがあり、左へ行くほど、抽象度が高く、右へ行くほど、具体的になっていきます。この4つのゴールデンサークルをつなげることができれば、全体像と詳細の関係性を把握することができます。

冒頭であげた「音声入力をつけましょう」と「音声入力にする目的って何ですか？」のやりとりですが、先ほどのゴールデンサークルの図に置き換えると、上になります。

ビジネス（事業）、サービス、プロダクト、機能のつながりが見えず、さらに、機能の目的（Why）・方法（How）がなく、いきなり手段（What）の話になったので、一番手前の目的（Why）の部分のヒアリングが行われたという状況です。

ここの機能部分のHowの引き出しを持っているのは、つくる職種の人たちです。ここで目的（Why）を明らかにしないと、方法（How）の部分の検討ができません。もちろん、何（What）をつくるのかはわかっているので、つくろうと思えばつくれますが、その方法論や実現手段が本当に最適なのか、検討・判断ができないので、実は目的からズレた機能だったり、最適な手段が他にあったことに開発が進んで後戻りができない状態になってから気づくなんて、悲しい事態になるリスクがあります。

実はこの、つくる際の方法論の引き出しを持っているか否かが、機能名だけで話をしがちか、目的から話すかの行動の違いにつながってくると思います。ただ、ここはコミュニケーションで、ある程度埋まる溝なので、バッサリ切り捨てずに、ぜひ対話をしてみてください。

それから、縦わり構造の組織で注意したいのが、Good UI,Bad UXになることです。

UIとUXは＝ではないです。機能名を先にあげてしまうと、それ以外の選択肢が見えなくなり、「そもそも、この機能が最適解なのか」の検討がしにくくなります。

一旦、組織の枠組みは一旦脇へ置いておいて、全体像とつながりを確認し、ひとつづつブレークダウンしながら検討していくことが、良いサービス・良いUXにつながります。

特に、様々な職種が関わる場合、先ほど述べた、言葉の粒度の違いから、齟齬が生じやすくなるので、認識合わせをしていくことが重要です。