情報を取捨選択する「条件」

ビジネスというものは常にアウトプットを要します。

アウトプットがなくても成立するビジネスというのは非常に限られています。ほぼ存在しないといっていいでしょう。基本的に契約と呼ばれるものはそれが請負であれ、準委任であれ、派遣であれ、売買であれ、かならず「お金」と交換する「何か」が必要です。

その「何か」をアウトプットとして提供しない限り、対価を得ることはできないようになっています。それが契約であり、ビジネスには必ず求められるものです。

ですから、ビジネスにおいては何よりもアウトプットファーストで考えるようにしなければなりません。「自分が何をしたいか」ではなく、「相手が何を求めているか」を満たさない限りそこにビジネスは存在できないのです。

では、そんなアウトプットを考えるとき、最もたくさんかかわることが多いのは何でしょうか。それは

　情報の取捨選択

の概念かもしれません。

あたりまえのことですが、アウトプットを提供するにはそれをプロセスとして実現できるだけのインプットが必要です。インプットがなければアウトプットは絶対に提供できません。

たとえば商品の売買にしてもそうです。

お客さまの「買いたい」「欲しい」という欲望を刺激し、インプットとしてその感情や欲求を見せてくれなければ売ること…すなわちアウトプットとして商品を提供することすらかないません。商品を提供する機会を得られなければ、お金を手に入れることもできません。

私たちのソフトウェア開発でも同じです。

私たちは「作る」ために必要な様々な技術的ノウハウを有していますが、それもこれもお客さまのなかで現状に課題や不満を持ち、それらを解決するために我々に依頼してくれなければその「作る」行為すらさせてもらえません。

また、依頼だけでは「作る」ことはできません。具体的に「何を作ればいいのか」がわからなければ作ることはできません。こうしたインプットがなければ、我々はビジネスにおいてアウトプットを提供することがかなわないのです。

そんなインプットですが、とにかく様々な種類、様々な形、様々な量が乱雑に存在しているため、それらの中を整理し、適切に取捨選択できなければなかなか相手が望んだアウトプットを提供することはできません。

たとえば資料作りを頼まれたとき、どの情報を優先し、どの情報を資料に盛り込み、どの情報を外すか。提案書を作ってプレゼンするとき、どのポイントを一番に持っていくか。

これら情報の取捨選択を考えるとき、大きなヒントがひとつあります。
それが、「ターゲットを最も満足させる」ことを考えるということです。

ターゲットを満足させることが仕事の最終目的。そうであるならターゲットを軸に情報の取捨選択を考えることが重要になるのは当然です。「納得」が得られるかどうかなんて二の次です。

私の仕事（トラブル解決など）でいうと、限られた時間の中で求められた成果を提供できなければ企業全体の信頼を損ねることになりかねません。それはもう「時限爆弾を止める」のと同じような感覚です。

一方でトラブルを起こすまでに至った経緯に関する情報はたくさんあります。むしろ情報が多すぎて何が原因かを特定できず、問題解決もできないようなカオスな状況だからこそ呼ばれるわけです。

そのような状況で身内（同じ会社の同僚や上司）の感情や納得、プライドなんて気にしている余裕はありません。正直、身内の保身や名誉、プライドなんて二の次です。当然、彼らの言い訳や自己正当化するための話なんて情報としての優先度が低くなります。

このとき

　「どの情報を最優先に詰め込み、どの情報を使わないか」

を検討する中でついついやってしまうのが、自分が知りたい情報を時系列に並べてしまうことです。しかし、全体像を把握するためとはいえ、自分が知りたいと思っていることが必ずしも問題解決にとって最短となるとは限りません。

お金を支払ってくれるお客さまこそが、最優先すべきターゲットです。

だからターゲットにとっての最善をイメージしながら取捨選択していきます。「『期限までに契約時の想定した結果を仕上げる』というゴールのために、現在不足しているものは何か」と考えてストーリーを描いていきます。

要は

　逆算思考（あるいはゴール思考）

を行うわけです。となると結局ターゲットを深く知ることが重要になります。ターゲットの求めるものが理解できていなければ取捨選択の指標がなくなってしまうからです。

そして、ゴールのために必要な情報以外はゴミです。誰かの自己正当化や言い訳情報なんて聞いているだけ時間の無駄、その時間を消費しても何も解決できませんし、人生の無駄です。

ここで意味を持ってくるのが仕様書やＲＦＰ、あるいは上流工程の設計書です。

お客さまとの合意形成に近いところで作成されたアウトプットは、ターゲットとなるお客さまをよく表しています（そうなっていなければ、よほどそれまでのプロジェクト体制は脆弱だったのでしょう）。

だから仕様書やＲＦＰ、あるいは上流工程の設計書とターゲットについてしっかり共有することが重要となってきます。

もちろん、プロジェクトには独自性があるように、ターゲットはプロジェクトごとに微妙に変わります。「人」や「会社」として全く同じであったとしてもプロジェクトごとの特性にあわせて常に変化があるということを意識したうえで接しなくてはなりません。少なくとも私は、どんなに見知った相手でも"初めて対するお客さま"のつもりでプロジェクトに取り組むようにしています。

ターゲットをできるだけイメージすることで、仕様書やＲＦＰ、あるいは上流工程の設計書の本質を見失わずターゲットに合った情報の取捨選択ができるようになるというわけです。

これはソフトウェア開発（トラブル解決）に限らず、他の仕事でも同じだと思っています。

ここで例に挙げた仕様書やＲＦＰ、あるいは上流工程の設計書は、自分の仕事の指針・方針となるものですから、行ってみれば「依頼者」のような存在と考えていいでしょう。

たとえば、一般的なビジネスでも

　上司に資料の作成を頼まれた。

となった場合でも、

　提出先は上司の上司である部長。

となっていれば部長こそが本当のターゲットのはずです。では部長はなぜこの資料を求めたのか。どんな状況にあり、どんなことに関心を持っているのか、上司の課長と一緒に考える。ターゲットを考えることによって、情報の取捨選択ができるようになっていきます。

その依頼された書類が提案書だったならどうでしょうか。

ターゲットは部長の先にいるお客さまとなりますよね。となればお客さまの状況をしっかり分析しなければなりません。こちらが「どう売るか」「どう儲けるか」の前に、お客さまがどういう状況にあるのかを把握しなくては、儲けるものも儲けられなくなります。

場合によっては提案書を出す前に、お客さまの状況をヒアリングする機会を真っ先に設けたほうがいいかもしれないことだってあります（というか、普通はそうしますよね）。それによって提案書作成に対する情報の取捨選択ができるようになります。

アウトプットを考えるときには、ターゲットの存在を強く意識するのです。