$shibayu36->blog;

プログラミングの話や自分の考えを色々と書いています。特にperl、emacsや読んだ本の話が多いです。

「なんかいいよね」禁止。 - 「広告コピーってこう書くんだ!読本」を読んだ

「なんかいいよね」禁止。 - 「広告コピーってこう書くんだ!読本」を読んだ

前回「クジラは潮を吹いていた」を読んだ - $shibayu36->blog;で、デザイナがどう思ってるのかもっと知りたいと思ってるって話をしたのだけど、それと同様に企画って何を考えているんだろうをもっと知りたくて、今回は同僚におすすめされた「広告コピーってこう書くんだ!読本」を読んだ。

広告コピーってこう書くんだ!読本

広告コピーってこう書くんだ!読本

この本はYonda?などのキャッチコピーを書いた谷山雅計さんが、キャッチコピーを作るための秘訣について平易な文章で教えてくれるという感じの本だった。企画的な心理が知りたいと思っていて読んだのでそういう面も非常に面白かったのだけど、立ち返って自分の職種にも適用できるような良い言葉がたくさんあり、非常に面白かった。


今回も心に残ったところについて書いていく。

  • 100本作る
  • 「書き手」から「受け手」へ
  • 「なんかいいよね」禁止。

100本作る

この本の中に、目安として一つの課題につきキャッチコピーを100本作るのが目安と書いてあった。100本作るって結構大変そうに思えるけど、それでも特に最初の方はそうしたほうが良いと書かれている。

これは根性論で言っているわけではなく理由は明確にあり、コピーを書くときは

散らかす -> 選ぶ -> 磨く

という流れで行ったほうが良く、何も考えずにやってしまうと最初から磨こうとしてしまい、いろんな切り口で物事を考えられなくなってしまうことが多いということらしい。


これはなるほど企画的と感じた。今回はキャッチコピーの話ではあるけど、Webサービスで新企画を考えるときもまずは散らかすという作業をせずに、さて良い物を考えようとなりがちな気がする。そうではなくてまずは付箋にこれからやりたいことに関するアイデアを100個くらい書いてみて、それを元に選んでいき、さらにブラッシュアップしてみるとしてみたほうが良い企画が生まれるのではないかと感じた。

「書き手」から「受け手」へ

この本の中に、キャッチコピーを作る時に、すごくいい作品を作った時にそこでやったいいものが書けた!となってしまう事が多いけど、そこで立ち返ってそれを見る人の観点で考えてみると、あれ微妙じゃないってなることがあると書かれていた。つまり「書き手」にとってすごく良いというものは、総じて「受け手」にとっても良いものではないので、注意する必要がある、書いた後に一度引いて検討する必要がある、ということだ。


これもなんか自分でWebサービスを作っていると、あー同じ所があるなと感じることが多い。例えばたまにこれは良い機能を作ったぞ!って感じることがあってそのままリリースしてみるんだけど、結局その機能はまったくユーザに届かなかったり、これは絶対使いやすいUIだろうと思ってもそのUIには非難が集まったりということがある。これは結局「作り手」には良いが、「使い手」には良くなかったという例だと思っていて、ここはキャッチコピーと似たところがあるなと感じた。


今後、何かを作る時書く時などは「受け手」の方に一度立場を移してみて考えるということを心がけたいと感じた。

「なんかいいよね」禁止。

さてこの本のなかで僕が一番印象に残ったのは「なんかいいよね」禁止。という章と、最後に「繰り返すことができる」がプロという章である。この本は「なんかいいよね」禁止。という章から始まり、「繰り返すことができる」がプロという章で終わる。


まず「なんかいいよね」禁止。という章の方から。著者は、良いキャッチコピーを考えるのはセンスという部分はあるが考える体質を作ることのほうが大事、と言っている。そのため、「なんかいいよね」じゃあこれで行こうという話で終わってしまうと、そこで思考がストップしてしまい、考えることをしなくなり、それでは考える体質を作ることが出来ない。なので毎回なぜいいのかを考える癖を付けたほうが良いと書かれている。

なぜそうしたほうがいいのか。その答えが僕は「繰り返すことができる」がプロという章に書かれていると感じた。

「繰り返すことができる」がプロという章には次のようなことが書かれている。キャッチコピーという職業はまれに大阪のおばちゃんの方が良い(もしくは面白い)キャッチコピーを作ることがある。でもそれでも僕がプロを名乗っているのは、一定レベル以上の良いキャッチコピーを繰り返し作ることができるからだ。


この二つの章、本当に印象に残っている。どんなプロでも自分の専門分野では一定のレベル以上のものを繰り返せるということが本当に重要であると僕は感じた。また繰り返すためには、確かに良い物を作れる理由を理解しておく必要があり、理解するためになぜそれが出来たのかを常に考える必要がある。そのため、「なんかいいよね」を禁止し、常にどうしてそれをいいと思ったのかについて考える癖をつけるというのは非常に大切だと感じた。

これまで自分の悪い癖を考えてみると、このコードはなんか美しいいいじゃんとか、このUIはなんか使いやすいからいいじゃんと考えてしまっていた。もっと自分で「なんかいいな」とか「なんかいやだな」と感じた時に、なぜそうなのかを考えることをもっとしていきたいと感じた。

まとめ

今回の本は企画の観点について知るためにさらっと読みたいと思ってた本だったが、思った以上に自分の職種にも役に立つことが書かれていて非常に面白かった。おすすめ。

広告コピーってこう書くんだ!読本

広告コピーってこう書くんだ!読本

他にも以下のような本をおすすめされたので、読んでみたいと思う。

コミュニケーションをデザインするための本 (電通選書)

コミュニケーションをデザインするための本 (電通選書)

「クジラは潮を吹いていた」を読んだ

クジラは潮を吹いていた。

クジラは潮を吹いていた。

最近エンジニア以外の職種の考え方みたいなのをもっと知りたくて、そのためにいろんな本を読みたいと思っている。今回の本はデザイン的な考え方をなんとなく覗いてみたくて読んでみた。


まずこの本を読んで感じたことは、すべてのモノにはデザインが関わってるんだなということ。そりゃ当たり前だろという感じなんだけど、今自分が持っているペットボトルにもデザインが、スーパーマーケットに並んでいる食品パッケージにもデザインが、そのあたりに貼ってある広告にもデザインが、薬のケースにもデザインが、それぞれあるということを改めて認識した。自分はWeb系に関わっているので、Webデザインというものにフォーカスが当たりがちだけど、実際には様々なものにデザインがある。そう考えると少し歩いているときに見えている風景が変わった気がする。


次に感じたことは、デザイナは自分の伝えたいメッセージと人がそれを見てどう感じるかをうまく混ぜてプロダクトを作っているのだなと感じた。本を読んでるとすごく人を観察しているし、ものを観察しているし、それがどのように人の感情に影響を与えてるかを観察してるイメージ。そう考えるとデザインしているときはとにかく人を意識して作るのだろうか。成果物に対するフィードバックはそれがリリースされて人に使われて初めて感じることが出来るのだろうか。エンジニアとして過ごしていると、作ること自体が楽しい時もあるので、そのあたり少し意識の違いがありそうと感じた。


またデザインの要素というのも目線を広げることが出来たような気がする。これまではデザインといえば色、形という要素しか自分の中では考えられてなかったけど、実際にはデザインをする上ではもっといろいろな要素がありそうだった。色、形はもちろん、配置、質感、文字、フォント、他にもたぶん僕が感じられていない様々な要素がある。この本の中に、脇役のデザインという話もあって、逆に目立たせないデザインという方向でも考えてたりするところも面白かった。デザインの要素はいろいろある。面白い。


この本を読んでいて、結局「クジラは潮を吹いていた」というのはなんなのだろうと思いながらずっと読んでいたのだけど、それに関しては最後の方に言及があった。この言及が非常に面白くて、なんか夜ぼーっと読んでいたのに鳥肌が立つ思いがした。なんで鳥肌が立ったのかはよく分かってないのだけど、この小さなところからイメージをふくらませて深いデザインを作ることがあるのかと思ったからなのかもしれない。


さらっと読んだだけなのだけど、自分の目線を広げることが出来て非常に面白かった。デザインのマインドの話結構興味があるので、おすすめ本などあれば教えて欲しいです。

モチベーションと目標設定・教育と褒める叱る - 「1分間マネジャー」を読んだ

1分間マネジャー―何を示し、どう褒め、どう叱るか!

1分間マネジャー―何を示し、どう褒め、どう叱るか!

前回紹介した1分間マネジャーの時間管理が非常に面白かったので、それに引き続き、今回はこのシリーズの第一作目である「1分間マネジャー」を読んだ。今回の本も非常に面白かった。


このシリーズは一貫して小説のような簡単なストーリーを通じて、重要なエッセンスを教えてくれるというものになっている。1分間マネジャーはその一作目。今回の本はマネジャーになった場合の行動の秘訣(一分間目標設定、一分間称賛法、一分間叱責法)について、若者が実際のマネジャーに質問しながら学んでいくという風に話が進んでいく。

僕自身が最初読んでいた時は、前半は結構ざっくりとした話だったので、あんまりおもしろくないなーと思いながら読んでいたのだが、後半部分からなぜそれが大事なのかという話になったときに突然面白くなり始めて、最終的な評価としてはマネジャーになりたての人は是非読んだほうが良いという結論になった。この本は150ページもなく、しかも小説っぽいストーリーにそって進んでいくので、すぐ読める。


今回も自分の中で印象に残った話について話していきたいと思う。今回も自分の解釈で書いていってるので正確性などは保証しない。

  • モチベーションのための目標
  • 教育のために褒める

モチベーションのための目標

この本では目標設定を明確にすべきだと書かれている。その後なぜ一分間目標設定が効くのかという章があり、そこにボウリングの例が出ていた。その話が非常に分かりやすかったので、それを紹介してみる。

ボウリングの話を簡単に要約すると以下のような話だった。

  • ボウリングは10本のピンがあり、できるだけそれを多く倒すという目標が明確である
  • また目標が明確であるおかげで、ピンが多く倒れること、などが良い成果ということがはっきり分かる
  • ではそのボウリングのピンを倒すという目標が曖昧で、ピンの前に幕が下がっていて、どれを倒せばいいかもはっきりせず、どれだけ倒したかも分からなかったら、いつまでボウリングをやる気になるだろう


この話は自分の中では非常に納得できた。もし人に何かをやってほしいときに、その人に何を期待しているか、何をやって欲しいか、どうなったら良い成果なのかが明らかになってなかった場合、上に書いたボウリングの例での目標が明確でないという状態になってしまっている。また目標が明確でないため、その仕事の良い成果とは何か分からない状態になってしまい、フィードバックを正確に得ることが出来ない。このような状態のまま仕事を渡してしまうと、渡された人はボウリングの例と同様にモチベーションがない状態になってしまうということが容易に想像できる。


以上のことからなぜ一分間目標設定が効くのかについて理解を深めることが出来た。人のモチベーションを高めるためには適切なフィードバックがある状態にする必要があり、そのために目標を明確にし、良い成果とは何なのかが明確になっているということが重要だと感じた。

ただしこの部分は言うのは簡単、行うのは非常に難しいものだと感じる。総じて他人に対して言わずとも分かってくれているだろうとか、これくらいは当たり前だろうと判断してしまい、コミュニケーションの量が減ってしまった結果、曖昧なままタスクを渡してしまうということもよくある。その辺りのことを気をつけたい。


これを読んでいて一つ分からなかったのは、目標とはどの範囲のことを指しているのかについてである。目標はいろいろあって、これからやりたい小さいタスクに関する目標、特定のプロジェクトの目標、半年の個人目標などいろいろある。なんとなくでは、今回この本が話しているのはこれらすべてなんじゃないのかなと思っているが、そのあたりまだ深堀りできてないので、時間があるときにもう少し考えていきたい。

教育のために褒める

この本の中で、一分間称賛法が重要という話が出てくる。こちらもなぜ一分間称賛法が効くのかという章があるのだが、それを読んでいると一分間称賛法というのはつまり教育を目的としているのではないかと感じた。


この本の中に以下の様なことが書かれていた

誰かを訓練して勝者にしようとするとき、もっとも大切なのは、仕事をうまくやっているところをとらえること、それも初めはおおよそでいいから正しくやっているところをとらえ、次第に希望どおりの行動に移らせていくことだ。

この部分、本の中では赤ちゃんに言葉を教えるときの指導という例が非常に分かりやすかったのだけど、少し長めなので割愛する。

これを自分なりに解釈すると

  • 人に何かを出来るようにさせようと思ったら、まずは仕事を大体うまくやれていることを見つけてあげ、良いことであると褒める
  • その後少しずつその仕事が正確に出来るようになるまで続けて指導していく

ということのようだった。


これもなるほどと思った。得てして教育しようと考えた時、どういうことをしているか本人を観察し、意図と少し違ったことをしていたら指摘するもしくは叱るのような方向になりがちである。しかしもしそのように指摘するという方向でやった場合、かつどのようなことが期待されているか曖昧な場合(これは目標設定に通じるところがある)、その人は叱られないようにできるだけ仕事をやらないとしてしまう可能性がある。そうではなく良い所を捉えてあげて褒め、さらに正確になるように指導していくという方向もあるということが勉強になった。気をつけていきたい。


また教育という側面では叱るという方向も一分間叱責法の章で述べられているのだが、こちらは今回は省略しようと思う。気になる方は本を読んでもらえると良さそう。

まとめ

今回この本を読んで、マネジャーとして重要な要素として、モチベーションを高めるということと、教育するという話があり、そのためのエッセンスとして一分間目標設定、一分間称賛法、一分間叱責法というのが紹介されているのだなと感じた。このあたりの話非常に面白いので是非読んでみると良さそう。

1分間マネジャー―何を示し、どう褒め、どう叱るか!

1分間マネジャー―何を示し、どう褒め、どう叱るか!


自分の次の興味としては、ではモチベーションとは何なのかという部分や、良い目標設定とは具体的には何なのかという部分になった。そこで次は以下の様な本をまた読んでいきたいと思う。

働くみんなのモティベーション論 (NTT出版ライブラリーレゾナント)

働くみんなのモティベーション論 (NTT出版ライブラリーレゾナント)

1分間モチベーション

1分間モチベーション

ザ・ゴール

ザ・ゴール

hubotにikachan的な役割を担わせる

最近Hubotの導入をしている。今回はHubotを導入したらikachanというツールの代替も出来たのでそのメモ。

ikachanとは

ikachanとは、HTTPのAPI経由でIRCに対してメッセージを送るように出来るようになるPerlツール。ikachanはdaemonとして動き、特定portでLISTENされるので、そこにcurlなどを使ってPOSTすると簡単にIRCにメッセージを送れる。これまで様々な人がIRC botを作って、投稿する部分を実装していたのだけど、ikachanがproxyとしてHTTP APIを提供してくれるので、それを起動しておいてHTTP APIを叩くだけでひとまずメッセージを送る部分のbot実装は作る必要が無くなった。

IRC -> Slackへ

最近IRCからSlackに移行した。それにより、ikachanはIRC投稿のproxyだったため、使えなくなってしまった。もちろんSlackにはIncoming webhookというのが存在し、HTTP APIを使って投稿も出来るのだけど、発行されるtokenをPOSTの情報に含めないといけないため、少し手軽さにかけていた。

そこでHubot導入もしたので、今度はHubotを使ってikachanとほぼ同様のことが出来ないか考えた。

Hubotでikachan的なことをする

実現したいことは「HTTP APIでmessageとchannel情報を送ったら、そこにメッセージを投げてくれる」だけ。もうどうせ他にそういうのあるだろうと思ったので、探してみると案の定同じような実装が存在した。
hubot-scripts/http-post-say.coffee at master · github/hubot-scripts · GitHub

使えるようにする

最近はhubot-scriptsはdeprecatedになっている(https://github.com/github/hubot-scripts/issues/1113)というのと、推奨されているnpmへの移行がされていなさそうだった(?)ということ、実際にhubot-post-sayを利用してみるとちょっとバグってたので、コピーして手直しして自分のHubotのscripts以下に入れるということをした。

diff --git a/src/scripts/http-post-say.coffee b/src/scripts/http-post-say.coffee
index 29ae14a..10ffa96 100644
--- a/src/scripts/http-post-say.coffee
+++ b/src/scripts/http-post-say.coffee
@@ -36,7 +36,7 @@ module.exports = (robot) ->
     envelope.user.type = body.type or 'groupchat'

     if message
-      robot.send user, "#{message}"
+      robot.send envelope, "#{message}"

     res.writeHead 200, {'Content-Type': 'text/plain'}
     res.end 'Thanks\n'

これで手元で/hubot/sayエンドポイントが作成されて、そこにcurlすることで使えるようになった。

実際に使ってみる

まず手元でbin/hubotすることにより、Hubotを立ち上げる。
f:id:shiba_yu36:20141013095630p:plain

続いてcurlで以下のコマンドを叩き、エンドポイントに対して投げてみる。

$ curl -X POST http://localhost:8080/hubot/say -d message=こんにちは -d room='#dev'

f:id:shiba_yu36:20141013095656p:plain

するとHubot側に以下のような文章が表示された。
f:id:shiba_yu36:20141013095709p:plain

使えた。これでmessageとroomを指定してHTTPで叩くだけでHubotがしゃべることが出来るようになった。

注意点

注意点としては、手軽さを重視してtokenなどを入れなくても投稿できるようにしているので、他の人から利用できる場所にエンドポイントを置いてしまうと、悪用されてHubotに投稿される可能性があること。きちんとアクセス制限をかけたり、それが面倒だったらSlackを使う分には素直にIncoming Webhookを利用するのが良さそう。

まとめ

今回はSlackでikachan的なことをするためにHubotを利用してみました。最近のhubot scriptはどこを探せばよいかわからないですが、npmを探せばよいのだろうか、というところが気になりポイントでした。

Asana使ってみた

最近タスク管理ツール何がいいかと思っていろいろ使ってみている。今回はAsanaのメモ。


Asana · Teamwork without email

良い所

  • Asanaはチーム利用としてはセクション分けしたりコミュニケーションがし易いように思えたので良さそう
  • チーム > プロジェクト > タスクといった階層でプロジェクトを作れるので、特定チームに所属し、その中でプロジェクトが複数走っていて、それらを別で管理したいというときには使えそう
  • タスクじゃなくてセクションもちゃんと区切れて、意外とそれが便利に使える
  • アサインしている人ごと、締切ごと、みたいな感じでいい感じにソートできるのは便利。どういうふうに整理されるとタスク管理しやすいかがよく考えられている
  • サクサク入力できる(イメージ)
  • iOSアプリが良く出来ているように見えた
  • Due Dateの繰り返し設定が結構細かく出来そう

悪いところ

  • 日本語利用していると結構な頻度でバグにぶつかってだいぶ辛い
  • Sunriseとのカレンダー連携が使えそうだったので連携してみたが、何故か同期されなかった -> 出来るって話もあるので、やり方ミスってるだけかも
  • 締切を決めるときに日付でしか決められず、時間の指定はできない
  • Mac用のアプリは無い

感想

自分としては個人のTODO管理に利用しようとしていたので、締切を日付でしか決められないなどといった問題点が致命的になりそうで使うのは諦めた。ちなみに最近はProducteev、Trelloといったツールも使っているが、今のところは

  • チームで利用するなら Trello = Asana > Producteev
  • 個人で利用するなら Producteev >>> Asana > Trello

という感想です。

あとは 【決定版】無料で使えるチーム向けタスク管理ツールを超厳選してみた | SEKAI LAB TIMES(セカイラボタイムス)が参考になるので読むと良さそう。

その後のTwitter



















問題 => 原因 => 解決方法という順で物事を考える

今日LIGのブログを読んで、直近自分の中で課題に思っていることと近いことがそのまま書かれていたので、非常に参考になった。そこで自分の思考を整理するためにも、以下の記事を読んでそのあたりについて思うところを書いてみる。


プロジェクトでトラブルが発生したときにWebディレクターがとるべき3つの手順 | 株式会社LIG

自分自身の課題

最近の自分自身の課題としては、「問題が発生したときに、すぐに解決手法を考えてしまう」というものだった。それには全く自分自身では気づいてなかったのだけど、最近はあるところで

  • 問題を見つけた時、いちどその原因はなにかを考えたほうが良い
  • 問題 = 原因ではない、そこを意識した方がいい

との指摘を受けて、確かに自分は問題だと思ったときに、それが本質的な問題か別の問題なのではないかと考えてはいたと思う一方、問題の原因とは何かについては深く考えてなかったということに気づいた。

問題 => 原因 => 解決の順で考える癖をつける

その課題に気づいたときにまずどうしようかと考えた。その時同時に、「考える力が無いのではなくて、原因を考えるという部分が癖になっていない」と言われたので、ひとまず癖をつけようと考えた。そこでひとまず癖をつけるためにどうしたら良いかを考えた結果、一番シンプルに以下のような言葉を自分の仕事場のディスプレイの下に貼り付けるということをした。

問題を発見 => 原因を考える => 原因を取り除く解決策を考える

この貼りつけた言葉は正にプロジェクトでトラブルが発生したときにWebディレクターがとるべき3つの手順 | 株式会社LIGで言われていることだと思う。

ディスプレイの下にシンプルな言葉を貼っておくと大体目に入るし、何度も目に入れておけばさすがに覚えるし、それによって今の問題 => 解決方法とすぐに考えてしまう課題を、問題 => 原因 => 解決とかんがえる癖に変化させることができると考えた。まだ初めてみて2日だけど、これは現状のところ直感的にうまくいきそうという風に思った。


またこの言葉を貼り付けたときに、最近勉強したやり方を使うとうまく出来ないかと考えたら、具体的なアクションを考えることが出来た。それは以下の二つのことである。

  • 問題が、事実なのか解釈なのか、を意識する
  • 原因把握には5回のなぜ、whyツリーを使ってみる

そこでこの二つについても軽く紹介してみる。

問題が、事実なのか解釈なのか、を意識する

最近勉強した考え方の一つとして空雨傘というフレームワークがある。

これが問題を考えるときに役に立つのではと考えた。つまり問題と思っていることが、「事実」か「解釈」のどちらかの可能性があるので、まずどちらなのかを一度考えるようにする。事実であればそれは本当に起こっている問題だし、解釈なのであればもしかしたら問題の「事実」があり、それを自分の主観に直しているのかもしれない。

これを一度考えることで問題に対する自分の理解を深められると考えたので、意識することにした。

原因把握には5回のなぜ、whyツリーを使ってみる

こちらも最近5回のなぜ、whyツリーという二つの手法を勉強したので、原因把握の精度を上げるためにこれを使ってみようと考えた。

原因把握をするときに単に浅く考えてしまうと、それが根本的な原因ではないものを原因と判断してしまうことがある。そこでそれをもうちょっと深く考えるためになにかしらツールを使ってみようと思った。

使えそうなツール

というものがありそうだったので、これを使ってみようと考えた。

まとめ

問題 => 原因 => 解決を考える癖を付けたいという話題で幾つか自分の頭を整理するためにブログを書いてみた。他にこういう考え方がある、癖を付けるならこういうことをすればよいのではないかという話があれば教えて欲しいです。

参考書籍

トヨタ生産方式

トヨタ生産方式

あと更に理解を深めるために以下も読んでみたい。

twitter
hatena
rss
Social Icon ブログパーツ