エンジニアの提案は、なぜ分かりにくいのか。広告制作のロジックで解く「目的起点」の設計術

説明を増やすほど、伝わらなくなる

エンジニアとして働きはじめて数年目に、私はなかなか提案を通すことができませんでした。

先行開発で検討していた方式を採用してもらうために、システム構成図を描き、他方式との性能比較表を作り、十数ページからなる資料をパワーポイントにまとめて用意しました。

技術的には間違っていないと思っていました。それでも、提案は通りませんでした。

あとで評価を聞くと、決裁者からはこのように伝えられました。

当時、私は、技術の正しさを説明しきれば伝わると思っていました。
でも実際には、受け入れる側は正しさよりも、別の視点の説明がほしかったのです。

同様のことは、別の場面でも起きていました。

機能を要件定義どおりに作っても文句を言われました。
便利だと思って作った機能は、顧客には「すごいね」ぐらいで素通りされました。
経営方針が説明されても、あいまいな内容で何を開発すればよいか分かりませんでした。

そのたびに私は説明を増やしましたが、結果は変わりませんでした。
もし今、同じ状況に戻れるなら、私はまず次のことを考えると思います。

その資料は、誰の何を変えるためにあるのか。
その提案は、相手のどんな判断を助けるためにあるのか。
その機能は、ユーザーのどんな行動を変えるためにあるのか。

常に「誰に対して、何のために」を考えるべきだったのです。エンジニア的にいうと、いわゆる、なぜなぜ分析に近い考え方です。
私はこの考え方を、目的起点と呼んでいます。

目的起点とは、何を作るか、何を説明するかの前に、その行為で誰の何を変えたいのかを考えることです。

この考え方を、私は広告クリエイティブから学びました。

エンジニアとして日々、業務をしながら独学で広告を学び、キャッチコピーの公募で広告賞をもらうこともできました。
そこで学んだことは、キャッチコピーを書くためだけの技術ではありませんでした。

広告の考え方は、エンジニアが日々行っている、業務文書の作成や稟議のための提案、先行開発、経営スローガンからの目標設定にも役立ちました。

クリエイティブは才能ではなく、ロジックだった

私は小さいころから、何かを作るのが好きでした。

マンガを描き、簡単なゲームを作り、それを誰かに見せて驚いてもらうのがうれしかったのです。
作ること自体も、作ったものが誰かに届くことも、どちらも好きでした。

絵や映像も好きだったので、美大を受けました。
結果は、あっさり不合格でした。ほとんど勉強していなかったので、当然の結果です。

そのころの私は、絵や広告や表現の世界を、どこか「センスのある人が行ける場所」だと思っていました。

うまい人は最初からうまいですし、思いつく人は最初から思いつきますし、いい表現は才能のある人の頭に突然降ってくるのだろうと、そんなふうに思っていました。

その後、物理やゲーム作りも好きだった私は、工学部で情報工学を学び、物を作れるメーカーに就職してエンジニアになりました。

エンジニアの仕事は、課題を分け、構造を考え、制約の中で動くものを作る仕事です。自分にはこちらも十分楽しいと感じていました。

しかし、後になって、広告に出会い、広告制作の考え方を学ぶ中で気づきました。

クリエイティブと呼ばれ、才能の塊に見え、斬新に見える表現も、センスだけでできているわけではありませんでした。

その広告は、誰に向けるのか。
その人の何の意識を変えるのか。
どのようにメッセージを伝えれば、動いてもらえるのか。

むしろ、センスとは真逆のロジックで綿密に構成されていたのです。そこには、エンジニアの仕事と通じるものがありました。

広告は表現ではなく、解決策である

私がこの考え方を持つようになったのは、偶然でした。

ある日、本屋でたまたま「宣伝会議」という雑誌を手に取りました。
話題の広告を紹介する雑誌で、掲載されている広告にセンスを感じ、面白いなと思いながら見ていました。その中で「宣伝会議賞」というキャッチコピーの公募を知りました。

絵や映像は難しくても、文字なら書けるかもしれない。そう思って応募したら、最初はまぐれで入選しました。

うれしくなって続けましたが、そこから先の賞にはなかなか届きませんでした。

少しは学ぼうと思い、キャッチコピーの書き方の本を買いました。そこで、一つの考え方に出会いました。

キャッチコピーは、表現するものではなく、解決するものだ。

それまで私は、広告をセンスの世界だと思っていました。
おしゃれな言葉を思いつく才能の話だと考えていました。

でも、広告制作の裏側を知ることで、そうではないと分かってきました。

先にも紹介した通り、広告には綿密なロジックがあります。キャッチコピーという言葉は、その設計のアウトプットにすぎません。

エンジニアリングも、誰のどんな課題を、どんな制約の中で、どんな出力で解くのかを考えます。アウトプットがキャッチコピーかソースコードかが違うだけです。

この気づきから、私はますます広告に興味を持ち、広告クリエイティブや戦略を独学で学びました。何年かして、最初に出会った宣伝会議賞で賞をもらうこともできました。

そして、広告の考え方は、キャッチコピーを書くためだけのものではないと分かってきました。

誰も見たくないから設計する広告の逆算思考

広告には大前提があります。誰も広告など見たくないという前提です。

街にあふれる広告のほとんどは素通りされます。
SNSの広告も、動画の前に流れる広告も、基本的には邪魔なものとして扱われます。

それでも一部の広告は人々の心を動かすものがあります。これはただ目立つからではありません。相手の中にある気持ちや不安を捉え、そこから行動までを設計しているからです。

たとえば、転職サービスの広告を考えます。

よくある広告は、自分の説明から始めます。

もちろん、情報としては間違っていません。
しかし、まだ転職してもいいかもしれないという気持ちが生まれていない人々には、このメッセージは素通りされます。

一方で、少し工夫された広告は、受け手の内側の気持ちから始めます。

この一文を見た人は、「これは自分の話かもしれない」と思います。
そのあとで、今の働き方を見直してもいいという考えが生じ、最後に登録という行動を示します。

一つ目と二つ目の広告の違いは、メッセージの出発点です。

前者の広告は、自分たちが言いたいことから始めています。
後者の広告は、相手の中で何を変えたいのかから始めています。

これが、「目的起点」です。

何を伝えるかの前に、誰の何を変えたいのかを考えます。
そのうえで、相手が気づき、判断し、行動できる順番に情報を置きます。

この考え方は、エンジニアの日々の仕事にも、そのまま使えます。

業務文書では、相手の行動から逆算する

まず、いちばん身近な業務文書で考えます。

業務文書なんか本来だれも読みたくありません。必要だから仕方なく読むものです。

それなのに書き手は、相手が最後まで読んでくれる前提で長く書いてしまいます。詳細を理解しているエンジニアなら、細部まで書きたくなります。

ここで、広告の考え方が使えます。

広告では、読み手の内側の気持ちを捉えるために、いくつかの方法を使います。その一つが、ターゲットインサイトです。

ターゲットインサイトとは、相手が潜在的に何に困り、何を欲しているかを考えることです。

もう一つが、CTAです。CTAは Call To Action の略で、相手に最終的にとってほしい行動を指します。

広告なら、購入、資料請求、登録などです。業務文書なら、承認、返信、確認、判断などにあたります。

たとえば、「点検アプリの異常通知」について、現場部門にログの確認を頼む場面を考えます。

まず、何も考えずに普通に書いてみます。

この例は大きく間違っているとは言えません。背景、事情、依頼の内容がしっかりと書かれており、むしろ、しっかりとしたビジネス文書です。

ただし、最後まで読まないと、受け手の方が、自分が何を頼まれているのかが分からない構成になっています。

この文章は書き手の頭の中において、自然な流れで書かれているためです。これは、読み手にとって自然とは限りません。

次に、「相手にとってほしい行動を伝える」という目的から逆算して並べ替えます。

変えたのは、表現の上手い下手ではありません。
目的から逆算して、情報の順番を変えただけです。

先頭にCTAを置いたので、読み手はすぐ自分の作業を把握できます。
背景も補足も削っていません。相手が行動を理解したあとに置いただけです。

「正確に説明する」ことと、「相手が動けるようにする」ことは違います。
業務文書で必要なのは、基本的には後者となります。

稟議では、決裁者の不安から逆算する

稟議も、同じ問題が発生します。エンジニアが書く稟議は、つい、技術起点で並びがちです。

書いてあることは正しいです。

でも、決裁者の関心は、性能の数字そのものではありません。
もちろん性能も見ますが、それだけでは判断できません。

決裁者が気にしているのは、たとえば以下です。

費用はいくらかかるのか。
実施しないと、どんなリスクがあるのか。
失敗したときに説明できるのか。
上に報告できる材料があるのか。

これが、決裁者側のインサイトです。

そこで、相手の判断から逆算して組み替えます。

やっていることは、依頼文のときと同じです。

先に、相手にしてほしい判断を置きます。
次に、やらない場合のリスクを示します。
その次に、安心材料を置きます。
技術詳細は、判断材料として最後に添えます。

技術的な正しさを捨てるわけではありません。
自分が説明したい順に並べるのではなく、相手が承認できる順に並べているだけです。このようにすると、同じ内容でも通り方は変わります。

「何を開発するか」の前に「何を変えるか」を考える

目的起点は、文書の作成だけでなく業務全体にも応用できます。

私が最初にいたのは、B2B向けの先行開発部門でした。
数年先に量産する技術を育てるのが役割で、そもそも何を作るべきか、どのようなものを試作していくべきかが、よく問題になりました。

ここで役に立ったのが、広告やマーケティングで使われる購買ファネルです。

顧客は、商品をいきなり購入することはありません。
現状の状態に何らかの不満を感じ、改善したいと思い、商品の存在を知り、他社と比べ、最後に購入する行動をとります。
単純化すると、この顧客行動のプロセスは、以下のようになります。

先の例はB2Cのイメージでしたが、B2Bでも同様に検討できます。例えば、下記のようなプロセスになると思います。

先行開発でも事業開発でも、どこにいてもこの顧客のプロセスは同じものになります。そして企業活動としてこのプロセスのどこかを改善できれば、最終の受注につなげることができるのです。

そのため、先行開発の試作が、プロセスのどの工程を変えるものなのかを決めないまま作りはじめると、アウトプットがぼやけてしまい、効果を発揮することができなくなります。

引き合いを増やすための試作なのか。
PoCに進んでもらうための試作なのか。
コンペで勝つための試作なのか。
受注後の量産リスクを下げるための試作なのか。

目的が違えば、作るべきものも変わります。

引き合いを増やしたいなら、顧客が関心を持つ技術を幅広く見せる必要があります。
コンペで勝ちたいなら、比較表で差がつく一点に絞る必要があります。
量産リスクを下げたいなら、派手なデモよりも再現性や安定性を示す必要があります。

つまり、何を作るかの前に、どのプロセスを変えたいのかを決めます。

ここでも、目的起点が効きます。
自分たちが作りたいものから考えるのではありません。
相手の購買や意思決定のプロセスの中で、自分たちの組織やチームの目標をどこに置くのかを考えます。

あいまいなスローガンを、具体的な設計図にする

エンジニアの組織では、経営戦略があいまいなスローガンで降りてくることがあります。特に研究組織や先行開発組織では多いように思います。

これらの言葉は、言っていることは間違っていないと思います。
しかし、このままの言葉では、開発現場は何をすればいいのか分かりません。

これらのスローガンと、企業の売上や利益という最上位の目標と、日々の設計判断がどうつながるのかが見えないからです。

このような問題においても、広告制作の技術が使えます。
広告では、制作前にクリエイティブブリーフを書くことがあります。

クリエイティブブリーフとは、作ろうとしている広告のターゲットは誰か、そのターゲットの何を変えたいのか、そのターゲットに何を伝えたいのか、その仮説がなぜ信じられるのか、などを整理するための設計図です。
エンジニアの仕事で言えば、要件定義書に近いものです。

私が戦略部署にいたときに、まずやったのは、スローガンの各要素が、why、who、what、how のどれにあたるのかを仕分けることでした。これはクリエイティブブリーフを作る骨格になります。

現場に降りてくる経営目標は、経験上、たいていが what か how に寄っています。やっかいなのは、why のふりをした what や how が多いことです。

「一歩先の技術開発」も、「体験価値を訴求する」も、それ自体は目的ではありません。どちらかといえば手段(how)です。

何を達成したいかではなく、達成するための方法を指しています。

手段の一段上には、本当は何を問題ととらえ、どう変えたいのかという why があります。それを明確にできれば、 what と how へ具体化できます。

たとえば、「体験価値を訴求する」というスローガンを考えます。

そのままだと、現場では何を作ればいいのか分かりません。
でも、目的起点で深堀していくと、下記のように整理することができます。

whatの位置を整理するだけで、あいまいだったスローガンが具体的なhowまで落とし込むことができるようになります。
体験価値というものが何か、という議論からも抜け出すことができるようになるのです。

「オンボーディング画面をどう作るか」まで落ちれば、エンジニアの土俵ですし、目的につながる具体案を検討することもできます。

安心感を生むUXとは何か。
それを技術でどう実現するか。
どこまでをUIで吸収し、どこからを設定ロジックで支えるか。

このような、具体的な設計を進めることができるようになります。

また、この例で、なぜ「安心感」が売上につながるのかも、購買ファネルで説明できます。

ユーザーの行動プロセスの最初の起点である「認知」で自社を思い出してもらえなければ、そもそもその後段の比較にも購入にも進みません。
その第一想起を支えるのが、ユーザーが現在感じている不満から企業名を思い浮かべる印象であるブランドです。

「使いこなしが難しそう」を「安心して使えそう」に書き換えることは、この認知を広げる施策です。

同じやり方で、「一歩先の技術開発」も考えることができます。
これを what と見て why を深堀していくと、たとえばこう整理できます。

スローガンも、目的起点で分解すれば、設計判断に変えられます。

AIがHowを担う時代、エンジニアはWhyを作る

生成AIでエンジニアの仕事がなくなる、とよく言われます。

たしかに、how の一部はありふれた作業になっていくと思います。
ソースコードを書く、技術を調査する、文章を整える、アイデアを出すなどは以前より速くなりました。

それでも、エンジニアの役割が小さくなったとは思いません。

エンジニアは、仕組みを理解し、状況を整理し、仮説を確かめる訓練を日々しています。

how に好奇心を持って向き合えます。その手触りを持ったまま、上流の why や what を整理する視点を持つことができます。

生成AIは、条件が整理されていれば、how の検証を速くしてくれます。
好奇心のある人ほど、多くの仮説を素早く試せます。

一方で、誰の何を解決するのか、何を作るべきなのか、どの変化を起こせば、意味があるのか、などの判断は、人間側に残ります。

もちろん、その整理に生成AIを使ってもいいと思います。
ただし、出てきた選択肢が良いかどうかは、自分で決める必要があります。

仕組みを作る力は、エンジニアがすでに持っています。
そこに、人はなぜ動くのかという視点を持てるかどうかで、人材としての希少性を出せると思います。

仕組みを作る力、人を動かす力

広告に出会えたことは、エンジニアとして幸運でした。

その機能は、誰の何を変えるのか。
その資料は、相手のどんな判断を助けるのか。
その戦略は、現場のどんな設計判断に変わるのか。

問題へのアプローチが変わり、作り方が変わりました。

この記事で伝えたかったことは、広告の基本である自分の基準で考えるのではなく、相手の基準で考えるということです。
その目的から逆算して、情報を並べ、機能を作り、資料を書くことで同じ内容でも相手の反応は変わります。

この考え方をつかむために、気に入った広告を一つ選んで次のように分解してみてください。

良い広告は、センスでできているように見えますが、そのセンスの正体は精密な設計です。

そしてその設計は、エンジニアの業務にも応用できます。

仕組みを作る力と、人を動かす力の両方を身に着けることができれば、エンジニアの仕事は、ますます重要になっていくと思います。