Yunicode

nanapiプロデューサー永田ゆにこの日記 ←この人だれ?はこちら

nanapi更新停止をお知らせしました

2019.06.21

昨日お知らせした通り、2019年6月30日(日)をもちまして、nanapiは更新停止となります。

今回のことの経緯についてはいろいろ事情があり詳細までは書けませんが、2016年の終わりに行ったリニューアルをきっかけに「新しいnanapiをつくる!」と約2年間推進してきた立場としては本当に残念です。

Twitterでもお知らせを出したところ、ユーザーさんから返ってくるリプライを見て「これから伝えようとしていたユーザーさんに、伝えたいことがちゃんと伝わり始めていたんだな」と感じました。たくさんのリプライに対し、心をこめていいねを押しています。nanapiのお問い合わせフォームからもメッセージをありがとうございます。nanapiを使ってくださってありがとうございました。ライフレシピもLINE@のお気に入り機能も残りますので、引き続き少しでもみなさんの生活のお役に立てたらとても嬉しいです。

わたしも6月末日をもってnanapiのプロデューサーではなくなります。もともとわたしはnanapiのユーザーで、夢中でレシピを投稿していたら、ご縁がありロケスタ社(nanapi社の前身)に入れていただいたのが始まりで、そこからずっとnanapiと共に過ごしてきました。自分の手で更新停止のお知らせを出せたのは、残念なことになってしまった中でせめてもの救いであり、償いだと思っています。

ロケスタ社に入社するとき、当時のCTOとCOOに「ベンチャーだけど、遊びではなく、本気でnanapiに参画できる?」と代々木のカフェ・ロリータで聞かれたことを覚えています。9年越しの答え合わせとして「本気で参画できた」と言っていいんじゃないでしょうか。わたしにとってnanapiはただのプロダクトではなく、ロケスタ社・nanapi社での歴史、一緒に働いた人たちとの思い出も含めた、この9年の全部です。

nanapiを応援してくださったみなさま、これまで一緒にお仕事をさせていただいたみなさま、協力してくださった企業さま、最後の最後まで一緒にがんばってくれたチームのみんなに、心より感謝いたします。本当にありがとうございました。

nanapi→Supershipを3年経験してみての振り返り

2018.11.02

2018/11/1でSupershipは3周年

ss

2010年から所属している株式会社nanapiが他の2社と合併して、Supership株式会社になったのはちょうど3年前。祝3周年ということで、会社でもお菓子をいただきました。 良いタイミングなので、少し振り返り、これまでのこと、いま思うことなどを書いてみます。

あっという間の3年間

2015年も2016年も2017年も2018年も、環境や人や事業がどんどん変わり、毎年全く違う年で、まるで4本の長い映画を観てきたような気持ちです。

合併当初は混乱も多く、合併した会社それぞれの文化もバラバラで、Supershipの組織や制度もまだまだって印象でした。 周りは知らない人ばっかりだし、別の部署は何してるのかよくわからないし、新たにやらなきゃいけないことも訳わかんないし、孤独感も強かった。 nanapiのカルチャーや人が大好きだったから、合併していろいろなものが失われたのは本当に辛かったです。経験したことのないことが立て続けに起きたりもして、最初の頃はひたすらに悩んだりめそめそしてばっかりでした。(本当によく泣いていた…) このときに辛抱強く、気持ちの整理に付き合ってくれた当時の上司には一生頭が上がりません。

でも、3年かけていろんなことが落ち着いたり改善されたりして会社も成長し、Supershipもかなり変わったと思います。

細かな制度の改善もちろん、フィロソフィーも何度か練り直されて、先日新しいものになりましたが、1番目に「従業員の幸せの追求」が掲げられていてありがたいです。でも、個人的には3番目の「正しいことを正しくやる」が特に良いと思ってます。 世のネット広告は正しい方へ向かって欲しいし、メディア業界もこれからはちゃんと価値を提供して正しくマネタイズをする時代になって行くだろうし、nanapiもそうありたいと思って日々がんばっているからです。 「syn.」構想も失敗を認めて、ちゃんと終了したのもすごく良いと思います。サービスを作ってる人ならわかると思うけど、そう毎回当たるものでもないから、失敗の中で次のヒントが見つかるなんてとってもいいじゃないですか。

他にも、最初は知らない人ばっかり(˚ ˃̣̣̥ω˂̣̣̥ )と思っていたけど、数年同じフロアで顔を合わせたり、プロジェクト横断で関わらせてもらったり、部活制度なんかのおかげでいろんな人と繋がりができましたが、本当にいい人が集まっており、みんなめちゃくちゃ優しいというか、全然関係ないことでも気持ちよく協力してくれてびびります。 毎度ご迷惑をおかけしているみなさん、ご協力いただいているみなさん、支えてくださっているみなさん、いつもありがとうございます。

というわけで、わたしは今のSupershipは結構好きです。大変な時代もずっと見てきたから、いまようやく本当にそう思えるのかなあと思います。

nanapiも変わっていきます

nanapiを取り巻く環境もめちゃくちゃ変わりました。応援してくれる人も増えたし、バックアップしてもらえているお陰で根気よく改善して良い方向に向かっています。

最近のnanapiはというと、いままでnanapiは検索してもらってレシピを見てもらうのが中心のPULL型サイトだったのですが、こちらからタイミングよく情報をPUSHしたくてLINE@を始めました。

nanapiのLINE@始めました

2ヶ月で3万人ぐらい友だちになってもらえました。Twitterも15万人くらいフォローしていただいています。ありがとうございます。 nanapiからちゃんとPUSHできたのは初めてなんじゃないでしょうか。結構歴史的な新しいチャレンジがいろいろできていると思います。 これからも役に立つレシピを、ちょうど良いタイミングと方法で届けていきます。

正直ここまできたらもはや意地って感じのところもあるんですが、やっぱり一番はじめにnanapiのユーザーだった頃からハウツーが好きなので、もう一度ちゃんとしたいいライフレシピサイトにしたいです。nanapiがあったからできることが増えた、と思ってもらいたい。 その上で、PVなどに依存しないマネタイズも同時に考えていきます。

そんなSupership社、月曜日は午後からの出社でOKになるみたいです

01

Supership、毎週月曜午前を有給休暇にする制度「Super Happy Monday」開始

「Super Happy Monday」とは、毎週月曜日の午前中に有給の特別休暇を取得することができる制度です。月曜は午後からの始業を推奨することで、Supershipの新たな働き方を実現する取り組みとなります。

毎週月曜日は午後からの出社でOKになるみたいです(β版として数ヶ月すでにそうでしたが)。

そもそもSupershipという会社では、

  • 普通の有給
  • アニバーサリー休暇(1年に一度、好きな日にお休みできる(なぜか5,000円もくれる))
  • HappyFriday(土曜日が祝日の場合、前日の金曜日が休みになる)
  • 夏休み5日間
  • 年末年始休暇

と以前から休みの多い会社であるのですが、そこに加えさらに毎週月曜午前も(°_°)  でも普通に社会人してると、役所とか病院とか平日の昼間にしかやっていないところへの用事はハードルが高いので、この制度のおかげでだいぶ助かりますね。

というわけで、いろんなことがアップデートされているおもしろいSupershipなのでした。いろいろ採用も募集してるみたいですよ。興味ある方はぜひ。

「生活のたのしみ展」のバイトで、サービス設計やコンテンツについて考えた

2018.06.12

株式会社ほぼ日が主催する 「生活のたのしみ展」というイベントで4日間アルバイトをしました。そこで、サービス設計やコンテンツに関係・共通する体験をしたので、ブログに書いてみます。

生活のたのしみ展とは

2018年6/7〜6/11に恵比寿ガーデンプレイスで開催された「生活のたのしみ展」。普段ほぼ日で取り上げられる商品や扱われている商品を実際に販売する、というほぼ日がまるっとリアルに飛び出てきたような催しです。前回と前々回は六本木ヒルズで開催され、今回3度目の開催。 1度目は普通に客として参加し、2度目はほぼ日の塾生としてイベントレポートで参加し、3度目の今回はアルバイトとして主催者側での参加。

する方はあってもされる方の面接はめったにないので、バイトの面接はすごく緊張した… 無事採用して頂けてよかったです。

4日目から天候が崩れる

合計5日間の開催だったわけですが、4日目と5日目は雨でした。台風きてましたからね。 会場は一応屋根はあるもののほぼ野外。ガーデンプレイス側ともいろんな調整があったようで、4日目の日曜日は直接雨が当たってしまう約半分ぐらいの店舗を、少し離れた内部の別会場「グラススクエア」に移しての営業となりました。

この日の主な業務は、メイン会場からこの別会場に人を送ること。ここにサービス設計と同じような考察と試行錯誤がありました。

どうしたら別の会場に人を送れるか?

メイン会場の入り口から少し入ったところで、別会場「グラススクエア」への誘導。

ちょっと話が反れますが、前の日、階段の上にもお店があるのにそのエリアへはあまりお客さんが流れず、声がけをして誘導する、ということをしました。階段の上のお店はマップにも記されているし「上にもお店があります」という案内板もあるのに、お客さんは想像以上に「階段の上にあるお店」を認識しません。階段の下から上のお店は見えないので、直接目で見えていないものは非常に認識されづらい。 そのようなことがあったあとだったので、階段の上へ人を送るだけでも結構な難易度なのに、全く別の会場に人の興味を向けるのは更に難しい、という想像はつきました。

しばらく案内板通りに「グラススクエアはこちらです」と声がけをしてみましたが、なかなかお客さんは動いてくれません。

なぜ案内を聞いてもらえないのか

なぜ聞いてもらえないのだろうと考えたとき、そもそも前提として、

  • お客さんは見えている範囲のメイン会場しかないと思いこんでいる(階段の上へ誘導の経験上から)
  • お客さんは雨で半数の店舗が別会場に移動したことを知らない
  • お客さんは店舗が別会場に移動するという発想がない
  • お客さんは別会場の名前がグラススクエアだということを知らない

ということがあるなと思いました。

基本的に、お客さんはメイン会場しかないと思っているので、閉まっているお店を見てもその店舗が別会場に移動しているとは思いません。「ここの店舗が目当てだったのに!」という人以外は、閉まっているお店を見ても、ここは今日やっていないんだな、程度の認識なのかも。 「雨だから店が別の場所に移動する」という、主催者側からすると何でもない情報が、お客さんからするとイレギュラーな発想なので、そこにまずハードルがあるのですよね。そして、別会場の名前が「グラススクエア」だという情報は「雨だから店が別の場所に移動している」のさらに先にあるので、いきなり「グラススクエアはこちら」という案内板を見せられても何のことだかわからないのです。

ほぼ日の塾に通っていたとき、塾長の永田泰大さんから「人は、他の人の言っていること・やっていることに対して初めは、しらんがな、としか思っていない」という話を聞きました。自分に関係がある、もしくは何か興味を惹かれる、というポイントがないと聞いてももらえない、とはまさにこのことだなと。

どうしたら自分に関係あると思ってもらえるか

雨だから別会場があるというイレギュラーな状態であることを伝え、そこには期待するものがあるよ、という言い方なら耳を傾けてもらいやすいのではないか?

そこで、

  • 今日は雨です(雨だよね)
  • 雨なのでお店が移動しています(ここにはないよ)
  • メイン会場以外にお店が移動した別会場があります(移動する必要があるよ)
  • そこにたくさんのお店がある(そしたら楽しいことがあるよ)

と、あなたに関係あることですよ、を伝えるため「本日雨のため、たくさんの店舗が中の別会場に移動しています」という言い方に変えました。ポイントは「たくさんの店舗」「別会場」「移動」 という単語です。

その結果「ここ以外にもあるんだって〜」という声が聞こえるようになり、直接場所を聞かれることが多くなりました。グラススクエアという会場の名前は、実際に案内するときに伝えればいいので、声がけの情報として入れませんでした。案内板も「グラススクエアはこちら→」というものではなく、パッと伝わる「雨のため店舗が別会場に移動しています→」とかの方が良かったかもしれないですね。

案内板を目にしてすぐ案内の内容がわかる人もいると思うけど、生活のたのしみ展に来ている人たち全員がそうとは限らないので、できるだけ情報を伝えるハードルを下げた方が、あらゆる人に伝わるのではないかと思いました。

【追記:2018/6/14/17:00】

上記の一文を、

「ほぼ日の読者はある程度、情報の受け取り方に対してリテラシーの高さがあると思うけど、生活のたのしみ展に来ている人たち全員がそうとは限らないので、できるだけ情報を伝えるハードルを下げた方が、リテラシーが低い人にも高い人にも伝わるのではないかと思いました。」

という記載にしていましたが、「ほぼ日の読者」「リテラシーの高い・低い」という言葉から、 ほぼ日の読者と今回のイベント参加者にリテラシーの差があるような表現になってしまったこと、 そして運営側が解決すべき会場の問題を来場者のリテラシーに頼るような誤解を招く表現になってしまったことをお詫びします。 そのような意図はなかったため、該当箇所の撤回と修正をいたしました。 不快な思いをさせてしまい申し訳ありませんでした。(追記ここまで)

どういう動線での案内が最適か

同時に、伝える場所もいくつか試してみました。

最初は入り口から少し入ったところで案内していたのですが、そこだとすぐ奥にこれから向かうつもりの並んでいるお店が見えるので、お客さんの興味はそっちにいってしまい、別の会場があるなんていうアナウンスは耳に入っていないようでした。

ではどこなら一番聞いてもらえるか。会場を一周回ってきて、奥の集合レジに辿りつき「ここで終わりかな?」って思ったタイミングで案内をすれば「お、まだあるんだな」と思ってもらえるのでは?と想像し、レジ前で案内してみると効果があり、会場を尋ねられる回数が増えました。

最初に案内していた入り口付近の方が別会場に近いのですが、もう一人別のアルバイトの人にわたしのいるレジ前から別会場までの途中に立ってもらい、まずはその人までを案内し、続きの案内はその人にお願いしました。おかげで少し離れた場所を長々と説明しなくて済み、この連携は結構うまくいったと思います。

コンテンツとUX設計に共通すること

というわけで「どのような単語を使ったり、どんな情報を先に伝えると、続きに興味を持ってもらえるか」の話はコンテンツでも同じことが言えるし(この辺はかなりほぼ日の塾で学びました)、「どういうタイミングと場所で伝えると効果的か」という場所の話はUX/UI設計と同じだと思いました。

普段は画面に向かってこういうことを考えているのですが、実際にユーザー(今回でいうとお客さん)の反応を見ながら、細かくPDCAを回せる環境でやってみるとめちゃくちゃ勉強になりますね、、基本的な本質の部分の考えは何事も同じなのだな。

学ぶことが多かった

他にも、エリアマネージャーたちの、会場をいかにうまく回すか、の動きはマネジメントの勉強になったし、次々起こる予想外の出来事を目の当たりにして、イベントを主催するっていうのはすげー大変なんだなっていうことがいろいろ見られてよかったです。

5日中4日の参加で、しかもそのうち金曜日と月曜日は有給、土日も返上、それで時給1,000円っていうと「なんで会社休んでバイトなんかすんの??」と不思議がられたりもしましたが、あれだけでかいイベントの裏側を見られることには大きな価値がありましたし、上記のような学びもあり、良い経験になりました。

お世話になったみなさん、ありがとうございました。

余裕がないときほど手段の目的化に走りがちになる

2018.03.19

先週、謎の焦りを感じていて、ふと「やっぱ自分でもちゃんとSQL書けた方がいいな」と思い立ち、SQLの学習方法を検討していました。

FY17のnanapiは主に立て直しや裏側の整理が中心でしたが、4月からのFY18は実際に数字を動かしていくことになるので、 ツールを使う言語を習得しておいたほうがいいだろう、という考えの元でした。SQLの基礎知識はありますが、実務としてはできないレベルなので。

でも、ある程度学習方法を絞り、なんとなくそれをエンジニアに共有したとき「欲しいもの(データ)を言ってくれればすぐ出しますよ」と言われて我に返った。 自分でデータを見にいくより(意思疎通のとれた)優秀なエンジニアに頼んで出してもらった方が何倍も速いし正確、圧倒的に工数もかからない。 だとしたら自分でSQLを叩く理由って何?勉強する時間の意味って?

改めて自分の役割とやるべきことを考えると、生のデータをどうこうすることより、 もっと今後の戦略について考えなければいけないことは歴然で、そこがないとそもそもデータをどうこうもできない。 SQLは書けた方がいいけどその時間でやるべきことは別にあるし、今じゃないよなー、と。

スキルを勉強するのは「何かを得ようとしている」ことに正義を感じるし、「勉強している自分」が気持ちいいから、安易に思いつきなんですよね、わたしの場合。 (このブログもmiddlemanを使ってslimとsassを習得することが目的だったので、作ってるときはめちゃくちゃ気持ちよかったです。)

「何に焦りを感じているのか(課題)」「それをどう解決すべきか(手段)」を整理すればすぐわかることですが、余裕がないときはなかなか冷静にそれを考えられず、 とりあえず全てを飛ばして手段の目的化に走りがちです。焦っているときほど「がんばっているような気になれる」ものに流れてしまいがちだなーというのを痛感しました。 一人だとクサクサしがちなので、もっと他の人と対話しつつ、冷静にやるべことと最適な手段を選択していきたいものです。

余裕がないときこそ、手段の目的化に走らず冷静に課題整理をしたほうがいいですね、という自戒を込めた普通のお話でした。

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

2018.03.14

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

サンプル=>   税金戻ってくるかも!アルバイト(フリーター)の方向け確定申告のやり方 | nanapi

ここ最近のnanapiはTwitterをメインに様々なレシピを紹介しているのですが、ユーザーさんからいろんな反応をいただきます。

「できた!」「おいしかった!」という実際にやってみての感想や、「もっとこうした方がいいよ」や「こういうのもあるよ」など、 レシピを補充する情報をいただくこともあります。

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

ずっと、このような外からもらえる良い情報をnanapiに還元できないかと考えており、まずはレシピの下に埋め込めるようにしてみました。

今後は、

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

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

nanapi編集部としてもアウトプットできる情報に限界があるので、ユーザーさんからの声は非常にありがたく、大事に扱っていきたいと思います。

レシピの内容に対しての質問や、内容への指摘は、サイドメニュー(SPの場合はフッター上)に「編集部にリクエスト!」というお便りコーナーがありますので、 そちらからお送りいただければ追って対応いたします。

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

2018.03.07

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

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

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

内容はインターネットの仕組みという超初歩的なことから、PHP、DB、SQLまで広範囲に。

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

01

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

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

wadap自身も2014年にブログに書いてます。→ 技術そのものがリスペクトされる風土がこれからは大事なんだと思う - UNIX的なアレ

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

<デザイナーの頃>

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

<ディレクターの頃>

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

<プロデューサーの今>

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

と、ざっと出してみましたが、たぶんもっとある。学んでいなかったらできなかったことも多いです。

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

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

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

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

2018.02.27

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

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

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

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

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

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

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

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

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

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