余裕がないときほど手段の目的化に走りがちになる
先週、謎の焦りを感じていて、ふと「やっぱ自分でもちゃんとSQL書けた方がいいな」と思い立ち、SQLの学習方法を検討していました。
FY17のnanapiは主に立て直しや裏側の整理が中心でしたが、4月からのFY18は実際に数字を動かしていくことになるので、ツールを使う言語を習得しておいたほうがいいだろう、という考えの元でした。SQLの基礎知識はありますが、実務としてはできないレベルなので。
でも、ある程度学習方法を絞り、なんとなくそれをエンジニアに共有したとき「欲しいもの（データ）を言ってくれればすぐ出しますよ」と言われて我に返った。自分でデータを見にいくより（意思疎通のとれた）優秀なエンジニアに頼んで出してもらった方が何倍も速いし正確、圧倒的に工数もかからない。だとしたら自分でSQLを叩く理由って何？勉強する時間の意味って？
改めて自分の役割とやるべきことを考えると、生のデータをどうこうすることより、もっと今後の戦略について考えなければいけないことは歴然で、そこがないとそもそもデータをどうこうもできない。SQLは書けた方がいいけどその時間でやるべきことは別にあるし、今じゃないよなー、と。
スキルを勉強するのは「何かを得ようとしている」ことに正義を感じるし、「勉強している自分」が気持ちいいから、安易に思いつきなんですよね、わたしの場合。（このブログもmiddlemanを使ってslimとsassを習得することが目的だったので、作ってるときはめちゃくちゃ気持ちよかったです。）
「何に焦りを感じているのか（課題）」「それをどう解決すべきか（手段）」を整理すればすぐわかることですが、余裕がないときはなかなか冷静にそれを考えられず、とりあえず全てを飛ばして手段の目的化に走りがちです。焦っているときほど「がんばっているような気になれる」ものに流れてしまいがちだなーというのを痛感しました。一人だとクサクサしがちなので、もっと他の人と対話しつつ、冷静にやるべことと最適な手段を選択していきたいものです。
余裕がないときこそ、手段の目的化に走らず冷静に課題整理をしたほうがいいですね、という自戒を込めた普通のお話でした。
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叩いてデータ引っ張り出すあれこれはめっちゃ楽しかったです。
↑夜遅くにホワイトボードに書いてもらったページングのヒント。（基礎編なので脆弱性あり）このあと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メンバーでミーティングをするときにやってることを書いてみます。
いつも新しい何かを話すときは、最初に↑の図を書いて、これから何の話をしようとしているかを、一番上段の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の案について白熱してもしかたないですからね…。そんなバカなことある？って感じなんですが意外にやってしまうんです、、
そこはファシリテーターとかプロジェクトを引っ張るリーダーがズレのないように牽引せえよ、とも思いますが、誰かひとりだけがわかっててもみんながついてきてないとあんまり意味ない。プロジェクトはチームで進めるものなので、全員の腹落ちのためだったり、意識を揃える意味でも、毎回こういう丁寧な確認をしていく方が、結果無駄な時間を抑えられるんじゃないかなーと思います。
今のチームのメンバーはこの辺の理解があり面倒臭がらず確認してくれるし、手段の目的化もやめようと意識しあってます。どのプロジェクト、チームにも応用できるものかはわかんないですが、今のチームではこのように進めていて結構うまくいっています、という話でした。
これからのnanapiを考える
暮らしの情報サイトnanapiは、2009年9月から始まり、2018年の9月で丸9年です。
わたしは、今いるSupership株式会社、の前身、株式会社nanapi、の前身、株式会社ロケットスタート、に入社してから、2018年で9年目になりました。ほぼnanapiと同じく時を過ごしているということになります。
もともとnanapiは、ユーザーにレシピを書いてもらうというCGMスタイルで、わたしはそのうちの熱心なユーザーの一人でした。受託デザインしか経験のないなか、熱量のみでデザイナーとして5人目の社員として迎え入れていただき、最初の3年ぐらいはとんでもないポンコツでしたが、たくさんの人に支えられながらここまできて、今はnanapiのプロデューサーをしています。ずっとnanapiとともに、たくさんの人に出会い、いろんな歴史をみてきました。
2015年にnanapi社がM&Aされ、カルチャーや事業内容に大きな変化が起き多くの人が去る中で、まだここにいます。いまだにぬるく残ってる、などと言われたりもしますが、実際そういう時期もありました。でもぬるく残るにはつらすぎることもたくさんあった。辞めたいと思って辞めようとしたこともあります。それらを乗り越えてここに残り、そしてずっとそこにあったnanapiを、もう一度このタイミングで、自分が中心となり再起させようと思っています。
なぜ再起か。いまのnanapiはとても好調とは言えない状況で、それは昨年の年末にリニューアルしたときにCodeIQさんでも取材していただき別に隠してもないんですが、とにかくそんなにいい状態ではないです。数字的には、調子が良かった頃にいた人が見たらびっくりするぐらいかもしれない。2016年は本当にいろいろあったので。その辺もCodeIQ見てもらえばいいか。トップの写真がすごいノーテンキなんですが…
状況としてはそんな良くはないけれど、いろいろあったことが逆に追い風となり、ようやく「本当にnanapiの価値を提供する」という本質のところにテコを入れられそうです。今まではGoogle検索の延長上に存在していたnanapiですが、これからは「○○だったらnanapi」と言ってもらうものを作りたい。インターネット上に様々なメディアがある中で、こういうところはnanapiだよね、って思ってもらえるところを作り、価値提供していきたいです。いま、いろんな人に協力してもらながら設計・構築中。
nanapiのツイッターの方はなかなか好調だったりします。フォロワーも10万を超え、ユーザーさんともいい感じでコミュニケーションがはかれています。需要があるのはやっぱり季節もの。シーズナルに関するコンテンツがツイッター上では必要とされています。nanapiは生活や暮らしの情報サイトなので、バズったりするような派手さはないものの、必要なときに必要な情報をいい感じに届けること（わたしたちはそれを「実家感」と呼んでいる）が使命なんじゃないかなあと。何か大きなアクションを示したりはできないんですが、実際にこれをどう届ければいいのか、を小さく検証しながら、今後の大きな強みにしていければと思います。
ツイッターを介してユーザーさんとコミュニケーションをとってみると、こちらが発信した情報に対して返ってくる反応の中に、有益なものが含まれていることに気づきます。普通の人の何気ないひとことなんですけど、こちら側では気づけなかった光るものが混ざってる。nanapiとして提供する情報に、そんなユーザーの方からもらった新たな情報を付加価値として追加していけると、そのレシピを次に見た人がもっと良い体験をできるんじゃないかと。ただ情報を発信しコンテンツを消費していくだけでなく、それぞれに価値を持たせて蓄積していく、蓄積したものを良きタイミングで提供する、をnanapiならではのやり方で実現できればいいなあと思っています。
「○○だったらnanapi」を築き上げるのはもちろん大変。きっと時間もかかる。特段派手でもないことを地道にやり続けていくことは一見つまんなくも見えたりもする。でもいまは、メディアもブランドが信頼が大事で、それを獲得するには高い熱量で地道にやり続けるしかない、という時代が来ている気もします。もう量産とかハックとか思いつきとかではやれない時代なんじゃないかなーと。いまはnanapiを理解してサポートしてくれる人たちもいるし、足の長い戦略を理解して日々足元を固めてくれるメンバーもいて、なんかできそうな気がします。自分たちの中の正義を定義して設計し考え抜きやり通す、の繰り返し、をみんなとやりたい。あと、ここまで共にきたんだからという意地と、勝手な責任みたいなものもあったりなかったり。
というわけで、12/20に全面リニューアルした以外、外からはあんまり見えないんですがこんなことを考えて日々がんばっていますよということを書いてみました。本質を考え直すのはすごい楽しいです。これからはそのチーム内でのあれこれや、プロジェクトを進めていく上でのあれこれなんかを、記録という意味も込めてブログに記していけたらいいなあと思ってます。初回なので長くなりましたが、、
