第36回 プロの洗礼、開発者の憂鬱 ～メルマガ連載記事の転載（2013/12/11 配信分）
連載 「データ・デザインの地平」 第36回 プロの洗礼、開発者の憂鬱
打たれて強くなる人、諦める人
クライアント企業からデザインの依頼があったとき、デザイナーは、ひとつのテーマにつき複数のプランを用意します。
いわゆる「捨てゴマ」があることによってお勧めプランが引き立ち、受注が確定しやすくなるからです。デザイナーは、それぞれのプランを見せる順序や説明方法も考えてプレゼンテーションを行います。
受託業務において「優先順位の高い」ことは、まずは「採用される」ことです。
そして、採用されることよりも「重要度の高い」ことがあります。それは「成果を上げる」ことです。成果がかんばしくなければ、デザイナーの評価は下がりますし、責任も問われます。
ですから、デザイナーは、採用され、且つ成果を上げるプランを用意するために努力します。
ところが、「優先順位の高い」ことと「重要なこと」ことは、必ずしも同じではありません。採用基準と、デザイナーが想定する成果とは異なる場合があります。
時には、捨てゴマのプランが採用されることもあれば、すべてのプランを破棄しての出直しを言い渡されることもあります。
クライアントから明確な指示を引き出すことは、しばしば困難ですが、それでも、デザイナーは、クライアントの真意を推し量ろうと試みます。練り直し、作り直し、再アタックします。粘り強く制作と折衝を繰り返すのです。
そういった経験をあまりしたことがない人は、クライアントの対応にとまどい、真意を探る前に、常に、クライアントの判断が誤っていると考えがちになります。
しかし、どちらが正しいかを考えることは無意味です。
デザイナーにできることは、ひとつしかありません。それは、着地点が見つかるまで呻吟することです。諦めず、考え続けると、不足している要素が浮かび上がってきます。
もっとも、そのような経験を重ねるにつれ、良く言えば賢くなる、悪く言えば小さくまとまってしまいます。
それはデザイナーだけではありません。クライアント側の担当者も同じです。とくに不況下では、ハイリスクハイリターンを恐れて、無難なプランが採用されがちになり、ブレイクスルーは生まれず、悪循環に陥ります。
クリエーティブな仕事を継続するには、クライアントの意向を尊重する姿勢を持ちつつも、天衣無縫であり続けることがもとめられます。
プロの洗礼に直面する開発者
クライアントの無碍な態度は、新人デザイナーにとって、プロの洗礼ともいえるものです。
それは、ひとつの通過儀礼です。
最初の洗礼で、デザインと芸術の区別を知ったデザイナーが「自分のもとめているものと何か違う感」を覚えて、方向転換します（※1）。それ以降、採用と成果の着地点を見つけられないデザイナーが諦めていきます。
残るのは、着地点をすばやく見つけられる優れた人か、生みの苦しみと達成感に喜びを感じる人か、仕事に対して冷静で淡々と取り組む人か、別の分野に軸足のある人です。
YouTubeやニコニコ動画のような開かれた場と異なり（※2）、受託業務のように評価される側と評価する側が明確な閉じられた場においては、プロの洗礼はあって当然ですから、乗り越えるしかありません。
プロの洗礼は、執筆でも開発でも、クリエーティブな側面をもつ仕事では、よくあることです。
広告原稿なら企業、記事なら出版社（編集者）に認められて初めて、消費者や読者やユーザーに成果を問うことができます。筆者自身、サラリーマン時代には、1行単価の高い広告コピーにおいて、クライアントの社長に突き返されたことは一度や二度ではありません。ずいぶん鍛えられたものです（※3）。
そして、今では、プロの洗礼は、アプリケーション開発者にも、しばしば起こります。アプリ開発では審査担当者に認められて初めて、公開して、ユーザーに成果を問うことができます。
インターネットが普及し、開発ツールが進化し、日本語の技術情報も増えて、開発への敷居が低くなると、クリエーティブな業務経験のない人や低年齢者が、取り組むケースも増えていきます。
すると、アプリ開発によって初めて、プロの洗礼に直面するということが起こります。
そうした人たちの頭の中は、プログラミングの楽しさとアプリが動いた喜びに満たされており、他の要素が入り込む余地はありません。クライアント側のストライクゾーンを考えず、きわどいところに投げていたとしても、それに気付きにくいことでしょう。その結果、ボールと判断されてしまい、戸惑うことがあるかもしれません。
そのとき、開発者にできることは、ひとつしかありません。
クライアントの真意を見抜き、不足する要素を調べてクオリティを高め、最上級のアプリに仕上げてみせる、という「気迫」を持つことです。
それは、開発者自身のその後の人生にとっても、IT業界にとっても、プラスになりこそすれ、マイナスになることはないでしょう。
報酬系の差異は受容するしかない
開発者とクライアントの判断が異なるからといって、どちらが正しいかを問うことは、無意味です。
なぜなら、完全に正しい状態か、完全に間違っている状態のどちらかしかない、という考えそのものが、幻でしかないからです。
開発者とクライアントのどちらかが成果を読み間違っているとは限らないのです。
多くの場合、「未来のどの時点までを、成果の対象とするか」―――その時間のとらえ方が、異なっているのです。拠って立つ時間が同じでなければ、判断の結果は異なってしまいます（※4）。
たとえば、アプリ開発の目標には、次のような段階があります。後のものほど、時間的に先のことになります（※5）。
(1) 目的の動作をするアプリ。（開発者が想定している操作をする限り、正しく機能するアプリ）
(2) 目的外の動作をしないアプリ。（想定外の操作に対するエラー処理が万全のアプリ）
(3) ユーザーに受け入れてもらえるアプリ（ダウンロード数や購入数の多いアプリ）
(4) ユーザーインタフェースの練られたアプリ（操作性やビジュアルデザインも考えられ、作りこまれたアプリ）
(5) ユーザーが満足するアプリ。（多くの星マークが付いたり、良いコメントが多数投稿されるアプリ）
(6) ユーザーに期待させるアプリ。（次回作を待望されるアプリ）
(7) ユーザーの人生観を変えるアプリ。（独創性のある、従来にはないアプリ）
これら７つのあいだに明確な境界線はなく、グラデーションになっています。(1)と(2)の間にも、無数の段階があります。(2)を少し超えたところで十分と判断するクライアントもいれば、(5)の手前までは頑張りたいと意気込む開発者もいるでしょう。この時間のとらえ方を、完全に一致させることは難しいものです。
開発者が判断基準としている時間は、クライアントのそれと完全に同一になるでしょうか？
拠って立つ時間の差異を無くすことはできません。なぜなら、それは個体の報酬系の違いに因るものであり、何人も他者の身体を操作して報酬系を変えることはできないからです。
報酬系が短期であるほど、目先のハードルのクリアが重要になります。アプリが目的の機能を果たせば十分と考えます（※6）。
長期になるほど、はるか遠く先のハードルが気になり、開発後の遠い先の評価まで考えがちになります（※7）。
おそらくは、多数の星マークの獲得を目指すという姿勢が、標準的なところではないでしょうか（違うかもしれませんが）。
そして、自分より短い報酬系の考え方は受け入れがたく、自分より長い報酬系の考え方は理解しにくいものです（※8）。
報酬系は、同じ個体の中でも、マトリョーシカのように入れ子構造になっています。
長期報酬系のヒトの中にも短期報酬系はあり、短期報酬系のヒトの中にもさらなる短期報酬系があります。
たとえて言えば、それは、為替チャートに似ています。為替チャートは波形を描き、時間によって区切れば、その中にもさらに小さな波形があります。
同じ経済アナリストでも、短期・中期・長期の予測は、異なることがあります。拠って立つ時間によって、判断は異なるのです。同様に、開発において、同じクライアント担当者であっても、拠って立つ時間が異なれば、その判断は異なります。
開発者とクライアントのどちらが正確に先を読んでいるか、大きな成果につながる未来へ舵を切ろうとしているのか、何が賢明な判断であるかなどは、どの時間で評価するかによって異なります。
ましてや、（為替相場を読む側のアナリストが読まれる側の世界に属しているように）開発者もクライアントも、読む側でありながら、読まれる側でもあるのですから。（※9）。
開発者がプロの洗礼をクリアするために必要なことは、クライアントの報酬系を知り、その報酬系を満足させる企画を考えて形にすることです（※10）。
自由意思に基づく正しさという錯覚
我々は、個体の報酬系の差の前には、無力です。
なぜなら、現時点では、我々は自らの意志で、自らの報酬系を設定できないからです。
我々は物質の集まり、おだやかな結合にすぎません。自分とそれ以外の境界など、きっちり線引きできるものではありません。
たとえば水を飲むと、コップの中の水は「私」ではありませんが、喉を流れ落ちる水は既に「私」の一部です。まさに水を飲もうとしたその瞬間、口に水滴が当たる時、その物質の所在を、その都度ヒトが意識することはありません。
私の意志の力によって水素と酸素は私の一部となるのでしょうか？否、私の意志のおよばないところで、都度、私が構成されていきます。私が認識する私とは、構成された断面にすぎません。
私の中では、私を構成する諸々の物質が、生存し続けるために、その形を維持し続けるために、押し合いへし合いしています。それらの、存続する長さはことごとく異なり、すぐに消滅するものもあれば、長くとどまるものもあります。それらのバランスが、報酬系を形作っているとは考えられないでしょうか。だとしたら、個体を構成する物質は完全に同一ではないのですから、各個体の報酬系が一致するはずがありません。
にもかかわらず、我々は、自らの主張を正として、相手を論破しようとします。
対する相手（と認識されるもの）があれば、我々を構成する物質たちの外交の舞台は整います。
相手が、友人であろうと、プレゼン相手であろうと、苦手な上司であろうと、やる気のない部下であろうと、尊敬する経営者であろうと、政敵であろうと、すべての分子たちがそれを認識して働きを変えるでしょうか。
ヒトが、自分を構成する物質の統率者であるかのように感じるとしたらそれは錯覚で、自分を構成する分子たちを生きながらえさせるために、ただ、突き動かされているにすぎないのかもしれません。
開発者とクライアントの見解が分かれるのは、互いの主張の礎にある報酬系を構成する、物質たちの饗宴の結果なのでしょう。
そして、個体の基本的な報酬系は、一定ではなく、時代と共に変遷していきます。筆者は、ヒトの報酬系は、両極化しつつあると感じています。短い人はより短く、長い人はより長く。それは、ヒトの意志の及ばないところで、着々と進められます。
世界は新しい報酬系に覆われていくでしょう。
その変化も受け入れつつ、我々は、報酬系の異なる相手に歩み寄り、すり合わせ、ディスコミュニケーションを少しでも減らすべく、もがくしかないのです（※11）。
※1 社会的なデザインと、個人的な芸術は、しばしば重なることもありますが、基本的に表現する対象が異なります。デザインは「クライアントに指定された」「作家以外の」対象物を表現するものであり、芸術は「作家が指定した」「作家も含む」世界の一部を表現するものであることが多いと考えられます。
※2 売上や評価などよりも数世紀～数十世紀先を見る、異常に長い報酬系の者には、後世に残る作品を生み出す可能性があります。
「データ・デザインの地平［15］芸術家、大量発生の時代」参照。
※3 筆者が技術書や技術解説記事を書き始めたのは開業後ですが、サラリーマン時代には工業系の広告原稿やコピーやマニュアルなどの無署名原稿を多数書いており、突き返されてクリアした経験だけは数多くあります。
※4 短期間で進める距離は少なく、長期間で進める距離は大きいように、長期報酬系であるほど、判断のために意識する領域も広くなるように思われます。
※5 (1)～(7)は、ソースコード非公開の場合の段階です。ソースコード公開の場合、「カスタマイズやメンテナンスがしやすかったり、データを流用しやすいアプリ」という目標が必要になることもあります。また、「アプリに対してではなく、開発者自身に対してファンが付くアプリ」という目標もあるでしょう。さらには、「コードによって世界を変える」という目標もあるでしょう。
※6 「採用」を目標として「成果」までは考えず、公開はされたものの反応が少なく、つまらなくなって、やめていくケースもあるでしょう。
※7 作り手とクライアントが双方とも長期報酬系に基づいて、それが必要だからと合意の上で、数十年先の成果を期待して企画するケースもあります。その成果だけを見て、先を読んでいないと判断するのは早計です。この社会には、期待できる成果が低くても、それ以外の理由で実行しなければならないことがあるからです。
※8 もっとも隔たりが大きいのは、ヒトの報酬系は同じであると思いこんでいる長期報酬系の経営者と、短期報酬系の社員でしょう。1km先の給水器を見つける視力を持つ経営者は、10ｍ先の水溜りに足を突っ込んで靴を濡らして歩けと命じます。かたや10ｍ先の水溜りを見ている社員は、浄水器を手っ取り早く工面しようとします。1km先を見る経営者は、10ｍ先しか見えていない社員に、なぜ付いてこないのかと詰め寄り、10m先を見る社員は、いますぐ水を飲める方法があるのになぜですかと抵抗します。
※9 「観測する者が、観測される世界の中にあって観測される側でもある」ことからは目をそらし、我々は、自分こそが観測者であってシュレディンガーの猫の生死を知っている、と思い込みがちなのかもしれません。
※10 筆者は、これまで、Windows Phone アプリは、8本を開発し、3本の企画をし、Windows ストアアプリは3本に企画協力をしていますが、すべて一度もリジェクトされていません（もっとも、自分が今後、Windows ストアアプリを開発したときには、単純ミスなどによりリジェクトされる可能性は捨てきれませんが）それは、開発におけるアプリの審査担当者は、デザインやコピーライティングにおけるクライアント側の決定権を持つ人と同じ立場にある、という考えのもとに企画しているからです。
※11 報酬系の異なる相手にプランを通す方法については、日経IT Pro の過去連載「Webプランニングから始めよう！～SOHO，小模事業者編」（2006年10月～2007年5月連載。PROJECT KySS名義、筆者単独執筆）の第14回、社会における報酬系の差異の必要性については、第15回も参照。