Yunicode

プロデューサー永田ゆにこの日記です

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

株式会社ロケットスタートに入社して、毎週月曜と木曜の二回、始業前の朝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の案について白熱してもしかたないですからね…。そんなバカなことある?って感じなんですが意外にやってしまうんです、、

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

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

これからの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見てもらえばいいか。トップの写真がすごいノーテンキなんですが…

next.rikunabi.com


状況としてはそんな良くはないけれど、いろいろあったことが逆に追い風となり、ようやく「本当にnanapiの価値を提供する」という本質のところにテコを入れられそうです。今まではGoogle検索の延長上に存在していたnanapiですが、これからは「○○だったらnanapi」と言ってもらうものを作りたい。インターネット上に様々なメディアがある中で、こういうところはnanapiだよね、って思ってもらえるところを作り、価値提供していきたいです。いま、いろんな人に協力してもらながら設計・構築中。

nanapiのツイッターの方はなかなか好調だったりします。フォロワーも10万を超え、ユーザーさんともいい感じでコミュニケーションがはかれています。需要があるのはやっぱり季節もの。シーズナルに関するコンテンツがツイッター上では必要とされています。nanapiは生活や暮らしの情報サイトなので、バズったりするような派手さはないものの、必要なときに必要な情報をいい感じに届けること(わたしたちはそれを「実家感」と呼んでいる)が使命なんじゃないかなあと。何か大きなアクションを示したりはできないんですが、実際にこれをどう届ければいいのか、を小さく検証しながら、今後の大きな強みにしていければと思います。

ツイッターを介してユーザーさんとコミュニケーションをとってみると、こちらが発信した情報に対して返ってくる反応の中に、有益なものが含まれていることに気づきます。普通の人の何気ないひとことなんですけど、こちら側では気づけなかった光るものが混ざってる。nanapiとして提供する情報に、そんなユーザーの方からもらった新たな情報を付加価値として追加していけると、そのレシピを次に見た人がもっと良い体験をできるんじゃないかと。ただ情報を発信しコンテンツを消費していくだけでなく、それぞれに価値を持たせて蓄積していく、蓄積したものを良きタイミングで提供する、をnanapiならではのやり方で実現できればいいなあと思っています。

「○○だったらnanapi」を築き上げるのはもちろん大変。きっと時間もかかる。特段派手でもないことを地道にやり続けていくことは一見つまんなくも見えたりもする。でもいまは、メディアもブランドが信頼が大事で、それを獲得するには高い熱量で地道にやり続けるしかない、という時代が来ている気もします。もう量産とかハックとか思いつきとかではやれない時代なんじゃないかなーと。いまはnanapiを理解してサポートしてくれる人たちもいるし、足の長い戦略を理解して日々足元を固めてくれるメンバーもいて、なんかできそうな気がします。自分たちの中の正義を定義して設計し考え抜きやり通す、の繰り返し、をみんなとやりたい。あと、ここまで共にきたんだからという意地と、勝手な責任みたいなものもあったりなかったり。

というわけで、12/20に全面リニューアルした以外、外からはあんまり見えないんですがこんなことを考えて日々がんばっていますよということを書いてみました。本質を考え直すのはすごい楽しいです。これからはそのチーム内でのあれこれや、プロジェクトを進めていく上でのあれこれなんかを、記録という意味も込めてブログに記していけたらいいなあと思ってます。初回なので長くなりましたが、、

【読書メモ】この1冊ですべてわかる コーチングの基本

些細なことでもアウトプットしていこう〜とか言ってたのにだいぶ間が空いてしまいましたが久しぶりに読書メモ。新しいスキルとしてマネジメントを勉強中。

この1冊ですべてわかる 新版 コーチングの基本

この1冊ですべてわかる 新版 コーチングの基本

感想

本当に基礎の基礎から丁寧に書いてある本で、一年生の人は入門書として必読。

マネジメントというふわっとした形のわかりづらいものに対してなぜコーチングをするのか、どのようにするのか、というところから丁寧に解説がある。「相手にする質問でより効果の出そうな質問例はどんなものがあるか」など一通りの流れなど、具体的なアクションまで書かれているのですぐ実践に活かせそう。取り掛かりとしてはとてもよい本だったと思います。紹介していただけてよかった。

それにしてもマネジメント(コーチング)を実践するのって本で読むと、そりゃそうだろうな〜ってことも多いのだけど、実際にやろうとすると相手も自分も人間なのでそう簡単にはいかないことばかり。とはいえ、そんなあれこれもこの仕事も面白さだと思うので誠実に向き合っていこうと思います。

以下、自分用要約まとめ。 ※手描き

f:id:yunico_jp:20190728123117p:plain

続きを読む

なぜ技術ブログを書くのか?を考える

少し前にホッテントリ入りしていた【転職後1ヶ月目】ガチ未経験でwebエンジニアになって困ったことという記事について、同僚の小川さんが自分のブログで言及をしていた。
blog.koogawa.com

元の記事の内容は「Webエンジニアになったけど些細なこともわからない!」というかんじで、Webエンジニアっていうか、フロントエンドエンジニアなのかな?

元記事に対して、小川さんは「なぜ技術ブログを書くのか」というテーマで書いていて、その中に

なんとなく書いたTipsが意外にも多くの反応を頂けたりすることもあるので(困っていることはみんな一緒だったりする)、どんな些細な事でもアウトプットしていくことが大事なんだなぁ、と思いました。

というものがあった。この「どんな些細な事でもアウトプットしていくことが大事」に対して、わたしも最近同じことを思ったのでそれについて書きます。

旧nanapiブログに載せていた「本当は怖くない!デザイナーがGitを大好きになった♡5つの理由」という記事を先日Qiitaに移行しました。内容は「デザイナーがGitを使ってみたけど実は全然難しくなかったよ!」っていう体験談で、特に便利なTipsとかを書いているわけではないのだけど、公開した初日から2週間で350くらいストックされました。TwitterやFacebookでの言及も多い。

移行する前、nanapiブログに置いてたときも800以上のはてぶがついていたし、ただの体験談がどうしてこんなに注目されるのかな?と考えてみた。Gitに関する情報って世の中に山ほどあるんだけど、もしかしたらこういう「最初にどういう風に感じて、その後どうやって克服していったか」みたいな超超初心者レベルの序章的なものってあまりない気がする。できるようになった人目線のものは多くあるけど、0から1、みたいなレベルのものは他に比べて実は少ないのかもしれない。みんなここから入るのにね。それがデザイナー向けであれば尚更。

このGitの記事の話に限らず「そんなこと、今更わざわざ聞く?」みたいなレベルの情報って意外となくて、でもネット上で「わからない」って言うと、はてぶ等で意見を言う人やツッコミをする人はいるけど、ストックされるような情報にアウトプットしてくれる人は稀。だから「こんなこと今更すぎるけど一応〜」みたいな感じで書くと意外と反応もらえることがある。「新人必見!倍速かつ高品質なバナーを作るためのコツを全公開します」という記事も、誰でもやっていそうなバナー作成の手順を書いてるだけなのだけど、そんな当たり前そうなことでも書いてみると需要があった。そういう話をslackのblogチャンネルで話していたとき、@wadapが「10人が目にすると2〜3人くらい「今更www」とかいう人がいるけど、1人でも役に立つ人がいるならそれでいいよね」と言っていて、本当にそれに尽きると思った。

ふと「前にもこんな話したな?」とデジャヴのようなものを感じて色々思い出してみたら「自分ではできて当たり前と思っていることが、必ずしも他人も当たり前のようにできるわけではない。だからそれをライフレシピにすることで、世界の誰かの役に立つはず」ってけんすうさんがよくnanapiというメディアについて言っていたことだった。そこに共感してnanapiに来たのだから、こういうアウトプットの考え方になるのはある意味当たり前かもしれない?今更だけど。

社内のQiita:Teamも些細なことでもネタっぽいことでも書いておく。意外とあとで何かのヒントになったりするし。Qiita公式でも「Qiitaで春の新生活を応援しましょう!」みたいなこういうのやってていいですね。あと最近、わからない人目線での説明がうまい、と褒められたので、そういうところを生かしつつ、わたしも小川さん同様些細な事でもアウトプットしていこう〜と改めて思いました。

新年度の抱負風にしておわり。FY16もがんばるぞ!