Yunicode

元nanapiプロデューサー 永田ゆにこの日記

nanapiのレシピの下にユーザーさんのツイートを埋め込む機能を実装しました

nanapiのレシピの下にユーザーさんのツイートを埋め込む機能を実装しました。

サンプル↓ 
nanapi.com

ここ最近のnanapiはTwitterをメインに様々なレシピを紹介しているのですが、ユーザーさんからいろんな反応をいただきます。
「できた!」「おいしかった!」という実際にやってみての感想や、「もっとこうした方がいいよ」や「こういうのもあるよ」など、レシピを補充する情報をいただくこともあります。

「できた!」「おいしかった!」という声や写真は、実際にやってみるとこんな感じになるのかというイメージが湧きやすくなり、「もっとこうしたほうがいいよ」「こういうのもあるよ」はnanapi編集部でも集めきれなかった情報なので、よりレシピの内容を充実させることができます。
ずっと、このような外からもらえる良い情報をnanapiに還元できないかと考えており、まずはレシピの下に埋め込めるようにしてみました。

今後は、

  • レシピの内容に付加情報として有益なもの
  • 実際にやってみた体験談や感想(成功も失敗も)
  • 実際にやってみて気づいたこと

というツイートをいただいたら随時レシピ下に埋め込んでいく予定です。もちろん勝手に埋め込むことはなく、必ず許可を得てから掲載します。

nanapi編集部としてもアウトプットできる情報に限界があるので、ユーザーさんからの声は非常にありがたく、大事に扱っていきたいと思います。
レシピの内容に対しての質問や、内容への指摘は、サイドメニュー(SPの場合はフッター上)に「編集部にリクエスト!」というお便りコーナーがありますので、そちらからお送りいただければ追って対応いたします。

プログラミングを学んでおいて良かったと思う

株式会社ロケットスタートに入社して、毎週月曜と木曜の二回、始業前の朝9:00〜10:00に、nanapi創業者元CTOのwadapさんからプログラミングを教えてもらっていました。

ロケットスタートにはデザイナーとして入社したのですが、始めの頃は本当にめちゃくちゃポンコツで何の役にも立てず「このままではわたしを雇ったことを経営陣全員が後悔してしまう!やばい!」と焦ったのがきっかけです。当時の開発部はわたしとwadapのふたりだけだったので、プログラミングを理解することで少しでもコミュニケーションを円滑にできれば、という切実な願いでもありました。

プログラミングのセンスには全く自信はありませんでしたが、wadapみたいなnanapiをひとりでサクッと作っちゃうすごいエンジニアにプログラミングのことを初めて教えてもらえるなんてラッキーすぎるし(しかも無料)(しかも終わると挽いた豆でコーヒーを淹れてくれる)頑張ってついていったのを覚えています。人生で一番まじめに予習と復習もした。内容はインターネットの仕組みという超初歩的なことから、PHP、DB、SQLまで広範囲に。

いまのnanapiはRuby on Railsですが、当時はPHPだったのでPHPの基礎も学習。ループ処理、if文から始め、最終的には自作の掲示板を作成するところまで一通りやってみました。
ページングをスクラッチで書くのは本当にキツかった。いまだから笑って話せますが、当時は本気泣きしたの覚えてます。DBを作って情報をぶっこみ、SQL叩いてデータ引っ張り出すあれこれはめっちゃ楽しかったです。

f:id:yunico_jp:20190728121137g:plain

↑夜遅くにホワイトボードに書いてもらったページングのヒント。(基礎編なので脆弱性あり)このあとwadapとtakumixが飲みに連れて行って慰めてくれた、という話はまたどこかで。

その後、ロケットスタートから株式会社nanapiになり入社する人数が増えても、入社した人(エンジニア以外)は全員wadapのプログラミング講座を受講する、という流れになりました。編集でもディレクターでもデザイナーでもみんなです。全員がバリバリにPHPを書けるようになる!というよりは、nanapiはどうやって動いているのか、エンジニアはどんなことをしているのか、などを理解して技術の目線を上げる、ということが目的でした。

wadap自身も2014年にブログに書いてます。↓
wadap.hatenablog.com

前提が長くなっちゃいましたが、という昔話をなぜしたくなったかというと、あれから、デザイナー、ディレクター、プロデューサー、と経験してきて「あのときプログラミングを学んでおいてよかったなあ」ということがめっちゃあるなーっていうのと、最近チームのエンジニアと話していてもそう思うことが多いので、ブログに書いてみることにしました。

<デザイナーの頃>

  • 実装についてエンジニアと話がしやすい
  • 主にコーディングなどで先を読んで対応できる

<ディレクターの頃>

  • やろうとしていることの先の処理が想像できる
  • データの扱い方について発想が広がる
  • 開発の工数予想ができる

<プロデューサーの今>

  • 実装イメージの抽象度が下げられる
  • プロダクトで問題が起きたときに対処法を想像できる
  • 所持しているデータについて理解し責任が取れる
  • 各業務のコストダウンに関する発想ができる
  • その他各種コストが計算しやすい

と、ざっと出してみましたが、たぶんもっとある。学んでいなかったらできなかったことも多いです。
もちろん、プログラムをがっつりと書くことはできませんが、知識として知っているだけでできることはすごく増えますし、円滑にできるコミュニケーションもめちゃくちゃ増えます。
エンジニアと話していて、わたしの知識が足りていないところは今もまだ当然あるけど、話をする上でベースがあるとないとでは全然違うな〜って思います。(まだまだだろ!と思ったエンジニアの人、ごめんね!精進いたします)

本当に学んでおいて良いことしかなかったので、エンジニアじゃない人も知識として一通り薄くでもかじっておくと、のちに自分のスキルの底上げや、サービスを作る上での土台になるのでおすすめです、という話でした。Gitを使っている会社だったら、自分が使ってなくてもGitの概要ぐらいは理解してみるとなんかのときに役立つかもしれないです。

いまはプログラミングを学ぶサービスなんかもたくさんあるので、わざわざ誰かに教えてもらわずとも学べるから良いですよね。(2010年はあんまなかった気がする)

違和感を無視しないで大事にする

最近チームで話すときにファシリテーションで大事にしていることは「メンバーがどこで違和感を感じているのか」を注意深く見る、ということです。

少しでも「( ・⊝・ )?」「( ˘•ω•˘ )?」って顔をするタイミングを見逃さない。

チームのエンジニアは、納得していないとき、何か疑問が残るとき、は絶対に納得していない顔をします。でも本人は最初「何に違和感を感じているか」よくわかっていなかったりするので発言はしない。なのでここで必ず声を掛けます。そうして、その違和感を丁寧に拾い上げて紐解いていくと、実は他のメンバーがそれまで誰も気づいていなかった課題に辿り着いたりする。本人が始めからそれを「課題」として認識していなくても「なんか変だな」という違和感がアラートになり話すきっかけにできる。

ここのシーンで見逃して先に進んでたら、結局後戻りになってまたここに来てたな、ということも少なくない。特に見落としていることがなかったとしても、そこの違和感についてきちんと話すことにより、本人の理解が深まり、腹落ち感がより得られるので、その先のコミュニケーションが少なくて済んだりします。

違和感を大事にするメリット

  • 話が進んでいるけど何か見落としていることに気づける
  • 腹落ちせずに進んでしまうことを避けられる
  • チーム内で大きな齟齬が生まれない
  • 腹落ち・納得することで熱量・コミット感が高まる
  • 結果的にコミュニケーションコストが抑えられる

違和感を大事にするデメリット

  • 時間がかかるのでめんどくさく感じるときもある

本質を理解しているとデメリットはさして問題じゃないので、ほぼメリットのみですね。違和感はすごく大事だと思います。幸い、いまのチームではそれを放置して前に進むことができない人ばかりなので、一見めんどくさく感じることもあるんですが、結果としてはそこがすごく安心できます。

というわけで、長期的な戦略に取り組んでいく上では、こういうコミュニケーションにとことん投資した方が、先でのエラーが少なくて済み良いです、という話でした。

構造的な文章を書くトレーニングはSlackでできる

ロケットスタートという会社の頃、自分の言葉は話すことも書くことも、全く構造的ではありませんでした。

たとえば誰かに何か相談をしても、まず最初に要点の整理を相手にしてもらってから本題、みたいになり、相談内容へ行く前の事前整理にすごく時間を使ってしまっていました。
ここをもっとできると、そのぶんの時間を肝心の相談内容や解決法に時間を割けるのでは、と思い、構造を整理しながら話す、ということを意識し始めました。話すときだけでなく、文章にアウトプットをする場合も同じで構造的になるようにしています。

構造的に文章が書けると、

  • 言いたいことが伝わりやすい
  • 相手に何をしてほしいか伝わりやすい
  • 記録に残しやすい(時間が経っても意味がわかる)
  • 結果自分も相手も時間が節約できる

みたいなメリットがあると思います。

個人的に、マークダウンで書かれた文章が一番理解しやすい。文章を整理するという意味ではマークアップとほぼ同じなので、デザイナーやエンジニアの人には馴染みがあるのかな。文章が整理され、要点をしっかり抑えることができ非常に良いです。いまはそこそこ書けるようになってきたと思います。

構造的な文章を身につける手段としては、

  • マークダウンで議事録をとる
  • Slackでの文章も構造を意識して送る

の2点をやってます。

マークダウンで議事録をとる、は議事録じゃなくてもいいんですが「話を聴きながらマークダウンで構造の整理しながらメモる」をやりまくるとだんだん整理をしながら話を聞く癖がつきます。カンファレンスへ行ったときに実践するとか。余談ですがnanapiはQiita:Teamを導入しており、Qiitaはマークダウンに対応しているので、そのまま議事録をアップできて便利。このブログもマークダウンに対応してます。

Slackで送るような短い文章も、構造を意識して書くようにしています。特に誰かに何かを依頼する場合。

xxxで使われているyyyに関して、zzzしたいと考えておりまして今プロトタイプを作成しております。そのプロトタイプに関してご確認いただきたいのですが、aaaa日の午前11時〜お時間をいただくことは可能でしょうか?プロトタイプの内容に関してはその打ち合わせ前日にはお送りするようにします

xxxで使われているyyyをzzzしたいと考えております。

プロトタイプを作成しましたので確認させてください。

確認いただきたいポイントは以下です。

  • ほげほげ
  • ふがふが
  • ぴよぴよ

mtgの日程は、aa日11:00はいかがでしょうか?

より詳細は追って前日にはお送りします。

みたいな感じでしょうか。

伝えたいことをだらだら書くのではなく、どうしたら簡潔にできるか。日々意識し積み重ねていくと、相手にも一層伝わりやすくなりますし、自身のトレーニングにもなり一石二鳥です。nanapiチーム内でも、伝わらない文章だと相手の時間を無駄にしてしまうので、なるべくロスタイムを生まないような伝え方をしよう、と共有しています。

しかしながら、すべての会話を構造的に意識してしまうと、それはそれでchannelが殺伐としてしまうので、適材適所というのはある。
エモい気持ちを伝えたいとき、エモいコンテンツをつくるときは、逆になにも意識しない方が伝わったりする場合もあるので、構造的な文章のすべてが正義というわけではないかなと思います。

しょうもない失敗をしてメンバーに許してもらいたいときは、わざとバカな感じの発言をして許してもらってます!

どこの話をしているのか確認しながら話すと結果無駄な時間を抑えることができる

nanapiメンバーでミーティングをするときにやってることを書いてみます。

f:id:yunico_jp:20180219135240p:plain

いつも新しい何かを話すときは、最初に↑の図を書いて、これから何の話をしようとしているかを、一番上段のAから確認します。最初の5〜10分くらいです。特にC、具体的な手法の話をしようとしているときは特に意識してこの確認をします。

目的は以下。

  • 上段にあるAとB「目的」「やり方」から順に確認していくことで「なぜやるのか」を再確認
  • 手段の話で盛り上がりすぎるのを防ぐ(Cの話をする場合)
  • 全員の熱量と目線の高さを合わせる

よく見かける、戦略・作戦・戦術っぽいですが、そこまでちゃんとしたものでなくてもよくて「目的からちゃんとブレイクダウンした上で、これから何を話そうとしているか/何を話すべきか」だけわかれば良い。この図があると、より可視化できるのでサッと書いてます。

これからCの具体的な施策(新機能の実装や、なんかキャンペーンとか)について話そうとしている場合、Cより上のAかBに空白、もしくは不透明なままの箇所があるなら、そこを埋めてからCの話したほうが良くない?というアラートにもなる。そこを空白にしたままそこより先の話をしてしまうと、すすんでからズレがわかり、場合によってはすごい後戻りになってしまうので。密なコミュニケーションをとってる同士でも、あとになって齟齬が発覚して無駄な時間が発生する、ということがわりとあります。

AとBのところが明確になって、じゃあ具体的なCの話をしようか、というときも、

  • AとBを実現するCは今から話そうとしているaでいいの?
  • その他にbやcになりうる案はないか検討した?
  • aとbとcがあったら本当にaが最適って明確なんだっけ?

も、一応話しとく。「aを実装したらBが実現しそう」っていう手段やアセットから逆算で考えるのとか、勢いで「一旦aをまずは実装してみますか」みたいなのをやりがちなんですが、サービス開発ってそんなに簡単なものじゃないし、経験上ほとんどうまくいかない印象。趣味やサークル的な集まりだったらいいけど、自分は天才でもないんで仕事ではあんまりやっちゃだめなやり方だと思ってます。

あと時々ブレストが白熱すると、どっか一箇所にフォーカスしてめちゃくちゃ話込んじゃったりするんですが、一旦落ち着いて↑の図で「今どこの話してるんだっけ?」を確認すると、いまそこの話をすべきかどうかが冷静にわかっていいです。Bを固めようとしているのに、まだ決まってもないbの案について白熱してもしかたないですからね…。そんなバカなことある?って感じなんですが意外にやってしまうんです、、

そこはファシリテーターとかプロジェクトを引っ張るリーダーがズレのないように牽引せえよ、とも思いますが、誰かひとりだけがわかっててもみんながついてきてないとあんまり意味ない。プロジェクトはチームで進めるものなので、全員の腹落ちのためだったり、意識を揃える意味でも、毎回こういう丁寧な確認をしていく方が、結果無駄な時間を抑えられるんじゃないかなーと思います。

今のチームのメンバーはこの辺の理解があり面倒臭がらず確認してくれるし、手段の目的化もやめようと意識しあってます。どのプロジェクト、チームにも応用できるものかはわかんないですが、今のチームではこのように進めていて結構うまくいっています、という話でした。