【CTOmeetup】CTO・テックリードのその先は…に行ってきました

好評につき増席CTOmeetupCTO・テックリードのその先は

https://flexy.connpass.com/event/149487/

に参加してきたので、そのときのレポート

登壇者の方

  • ファシリテーター 株式会社 一休 執行役員CTO 伊藤 直也 様
  • グリー株式会社 取締役 上級執行役員 最高技術責任者 藤本 真樹 様
  • 株式会社メルカリ 執行役員CTO 名村 卓 様
  • ヤフー株式会社 取締役 常務執行役員 CTO 藤門 千明 様

パネルディスカッション1:「CTO・テックリードのその先はどうしたいのか?どうなりたいのか?」

自己紹介兼、今回のテーマについて

伊藤さん

「CTO になって最初はマネジメントしていなかった

しかし、組織体制に問題を感じて、それを壊そうと思ったところが発端です。」

藤本さん

「人数もだけど、プロダクトの数も仕事の仕方に関わるかなとも思っている。

最近プロダクションのコードは書いてない。

エンジニアリングとマネジメントのバランスについては

どっちもやればいいと思っている。

特にバランスをもつことに意味があると思っていない。

ので、分からないことがあれば調べるをずっとしている。

だが、知識がついていなくて不安になることがある。

その不安がどこからくるのかと考えたときに

「自分はこういうマネジメントができます」と自信もっていえることが大事だと思う。

あとは、例えば、むりやり登壇に手をあげて自分を奮い立たせるとかしている。

まとめると、業務ではエンジニアリングは手を出していない。

なぜなら、サービスが多く、それぞれのアーキテクチャを把握するのが難しいから。」

名村さん

「最近までエンジニアリングをやっていたので、バランスと言われると難しいが

最近はコードは書いていない。

最近までは、US のアーキテクチャをマイクロサービスするときに

指揮をとったりしていた。

CTO という肩書きの人が現場に入ってコードを書くと

現場が萎縮してしまうのではないかと思っている。

そのため、現場が機能するための組織づくりをするべきだと考えている。

例えば、マイクロサービスにすると、みんなが自由に動けるのではないかとか、

デプロイフローを刷新してみたらどうかとか、そういうことを考えている。

ので、ヒューマンマネジメントというよりは、テクニカルマネジメントをしている。」

藤門さん

「社員が 3000 人いるのだが、そんなにいると、

自分がコードを書くことはない。

会社としては、新しいことをどんどん始めていこうとしているので

そこで意思決定をするのが、メインの仕事になっている。

バグが起きた時に、どのようにして解決するのかではなく、それをどう意思決定するかとか。

また、PayPayが最近問題を起こしたが、そのプロダクトをどう安定するかとかを考えたりしている。

コードどれくらい書くか?と言われたら、基本まかせているので困っていないが、

現場は未来のことを後回しにしてしまうことがある(足元を見てしまう)ことがあるので

自分で未来に活きるコードを書いて、提案してみたりしている。

また、社内でハッカソンがあるが、それで、一番最初に発表する役とかやっている。

(もの作れることを示さないといけないので)」

お題:「マネジメントは他の人に任せているんですか?」

名村さん

「そうですね。こういうエンジニア組織にしたいんだけど、という抽象的な依頼を

VPoE に頼むようにしている。」

藤本さん

「気をつけていることはありますか?」

名村さん

「熱く語ろうとか、こういうことを浸透させようとか、そういうことをしている。

自分が 300 人とかの単位のエンジニア組織のエンジニアだったときに

こういう組織だったら楽しいだろうということを意識するようにしている。

1on1 はしまくっている。予定がびっしり埋まっている。」

伊藤さん

「藤本さんはマネジメントはしていないんですか?」

藤本さん

「自分が担当する範囲を決めてやっている。

プロダクトや、エンジニアに関してのマネジメントは別の人にやってもらっている。」

伊藤さん

「名村さんは自分ができないことを他の人にやってもらっている感じですか?」

名村さん

「そうですね。例えばバックエンドの人にマイクロサービスのアーキテクチャを見てもらっていたりしている。」

伊藤さん

「藤本さんはどちらかというと、分散させるために分けている感じですか?」

藤本さん

「そうですね。

自分はそういうのはやらないという設定は大事だと思っている。」

藤門さん

yahoo 3つの部門がそれぞれ 1000 人くらいいる

以前、その 1 つの部門をみていた。

そこでわかったのは、1000人をみると、死ぬということ

例えば、何か問題が起こったり、解決したりを 1000 人分やっていくと

CTO の業務ができないということがわかった。

ちょっとの問題が自分のところにあがってくるまでに、すごい問題になったりする。

来た瞬間に絶望することもある。

そこで、社長に懇願して、ピュアな CTO をやらせてもらうようにした。

なるべく、マネジメントとエンジニアリングのバランスをとるためには、

人数を分割するのが大事だと思っている。」

伊藤さん

「自分のところは、なんとなくゆるくで、人数を分割している。

バランスについては、とにかく時間を空けるようにして、開発をするようにしている。

何か技術的な問題があったときには、自分が意思決定したほうがスッキリすることがある。

現場で答えが出ていなくてモヤモヤしているときに、自分がズバッと答えを出すことがある。

自分の時間をどうするかというのが、CTO スキルの一つだと思っている。」

藤門さん

「自分の上司はデータで分析するのが好きなので、

社員の仕事の予定を分析して、可視化して、指摘をしてくれる

例えば、MTG しすぎとか、出張しすぎとか。

そういうところから、時間の使い方を見直すことがある。」

伊藤さん

「自分も、部下の予定をマネジメントすることもある。」

藤本さん

AWS CTO も、金曜日の夜は予定を絶対に入れないなどの工夫をしているらしい。

その時間で何か調べ物をしたりとかしている。」

伊藤さん:「次の質問です。「経営に関わってますか?」

藤本さん

「関わっている。

これはやめたほうがいいとか、そういう指摘をよくしている。

みんな新しいことをやりたがるが、そういうのをやらないように止めるのが最近大事だと思っている。

うちの会社はいろいろやって、伸びるサービスもあれば、ダメになるサービスもある。

そんななかで、勝つべくして勝つという考え方が大事だと思っている。

やらないことはやらないという判断を大事だと思っている。

なので、経営の関わりかたは、これはやらないほうがいいと削ぎ落とすことをしている。」

伊藤さん

「経営メンバーとして、技術担当ではない役員の人とどのように接してますか?」

藤本さん

「分からないのなら、ただ、こうですよということだけ言う。

ただ、そのためにはクレジット(信頼)も大事だと思う。

「藤本さんがこういうなら」という環境にするのが大事。」

藤門さん

「経営で大事なのは、一緒に事業戦略を考えること。

事業が決まってそれをエンジニアが、はいやりますというのはよくないと思っている。

20年後30年後の yahoo はどうなっているべきかというのを一緒に考えられるということ。

そのために、役員の人と一緒にランチを食べ、事業戦略を熱く語ったりしている。

その際に、今世界の技術はこうなっていて、どういうことができるよっていうのを

分かりやすく伝えるようにしている。

なので、普段から話す時間をよくとるようにしているし、CTO としてそれに一番時間をかけていると思う。」

名村さん

「逆にメルカリは、役員が分かってくれやすい。

逆に現場に落とすのが大変。

現場で、「なんでマイクロサービスやるの?」という意見が出たりする。」

伊藤さん

「自分は、信頼を得るようにして、

ナオヤさんがそういうならそうなんでしょ、と分かってもらうようにしたりしている。」

ここで一旦休憩。休憩中の会話

伊藤さん

「採用ってどのくらい関わってますか?」

藤門さん

「新卒には関わらないけど、中途とかは、ビジョンに共感しているかとか、関わっている。」

名村さん

「関わっているけど、あまり落としたりはしない。

というのも、最終的な期待値の認識合わせだけしているから。」

伊藤さん

「僕はみなさんに比べるとめっちゃ関わっているな。

全然落としたりしているんで。」

藤本さん

「こういう場所で、マネジメントを語るのって難しいよね

どう思われているのかって思って。」

伊藤さん

「そうですよね。

技術で間違ったこと言ってても、それは技術の間違いになるけど

マネジメントだったら下手したら炎上しますもんね。」

パネルディスカッション2:「事前アンケートより内容を選出」

伊藤さん

「個人的に話したかったことがあるんですが、、、

「あとから雇われて CTO になったときに気をつけること」はなんですか?という質問について話したいと思います。」

伊藤さん

「僕とみなさんの大きな違いは

システムのことが全く分からないという自体に陥った。

そこで何が起こるかというと、

1, 2 年経って、システムが分かってないと話ができなくなってしまう。

また、周りも 1, 2 年は周りも「知らないんだな」と思うくらいだけど

3 年経っても分かってないと「この人はわかる気がないんだな」と思われてしまう。

だが、そこを切り崩すのは難しいと思う。

自分の場合は、技術的負債をバッサリ落とすというきっかけがあったので

そのときにカバーできたが、きっかけがないと難しいと思う。」

名村さん

「最初からいる人と、途中から入ってきた人の壁があって、

「なんだこの新参者は」と思われてしまうことはあるので、

そういう意味でもマイクロサービス化が大事かなと思っている。

そういうところを切り崩していくのが大事かと思っている。」

伊藤さん

「以前、藤本さんと一緒に仕事しているときに

不具合が起こると、自分は「大丈夫?」しか言えないが、

藤本さんがさっと解決してくれたことがあった

そうなると「自分の存在価値はなんなのか?」と思ってしまう。」

伊藤さん

「自分たちは、また別の企業に中途で入って CTO をやることあると思うが、

最初は頑張らないといけないですよね。

切り込みが失敗すると本当に辛いので。」

藤門さん

「たくさん事業やると、たくさん失敗する。

そのときに、技術のせいにされることがあると思う

例えば、スピードが遅いとか、アーキテクチャが悪いとか

そのときに、自分はいいポイントだと思っていて、

自分が責任をとるということだと思う。

現場には現場の解決を全力で任せて

自分は上の人ことを把握するようにする。

すると、上の意見を全て把握しなければいけないし、

現場の不満も把握しなければいけない。

そういうタイミングが切り込むタイミングだと思っている。」

伊藤さん:「次の質問です。失敗談はなんですか?」

藤本さん

「最初にレイヤー(組織)を作るときに、なんとなく向き合わないで、こんな感じと決めたら

エンジニア 10 人くらいで MTG してたら、全員がキレて MTG を退席してしまったことがあった。

これは辛かった。」

伊藤さん

「よくその状態から、今の状態になりましたね。」

藤本さん

「当時、自分がスーパープレイヤーだと思っていたが、

組織がうまく回るために注力するのが自分の仕事だと気づくことができたから、今があると思う。」

名村さん

「このあいだ別の meetup で話したときに、自分たちはグローバルテックカンパニーですって言ったんだけど

言わなきゃよかったと思った。

それを言ってしまって、社員から「自分たちは Google みたいにならないといけないのか?」という不満がでた。

なので、変な背伸びや期待値をあげることはよくないなと思っている。

良い人が離れて言っているフェーズなので笑「こんな会社じゃないと思った」みたいな笑」

藤門さん

「自分が現場に入ってしまって解決してしまうことがあるが、

モノができてしまうのが悪いことじゃなくて、

組織がもめていることが悪いことだった。

なので、こうすればもっと早くできたとか、そういうことはある。

なので、自分の解決策が良いとは限らないということ。

例えば、テックリードの時期とかはそういうことがよく起きるんですけど、

テックリードは自分がとても技術的にできてしまう(イキってしまう)時期でもある。

そういう人に、ここの組織に入って問題解決してよとか言うと、すぐに

「この技術が悪いんだよ」とか言ってしまう。

ので、解決する際に技術から入るのはよくないと思う。」

藤本さん

「そういうテックリードがいたら、CTO としてどうしますか?」

藤門さん

「しばらくやらせてみますね。」

伊藤さん:「次の質問です。事業成果を出せたと思うことはありますか?」

伊藤さん

CTO になると、事業成果から切り離されますよね。」

藤門さん

「自分が CTO なりたてのときに、一休を買収したいと言われた。

そのときに、一休のドキュメントをみたときに全く分からなかった。

(自分たちはこれまで linux ベースのシステムだったが、一休は windows ベースだった)

それに対して、1週間で答えを出せと言われたときが大変だった。」

伊藤さん:「次の質問です。信用を得るためにどうしていますか?」

伊藤さん

「大事なのは、エンジニアの立場に立たないということだと思う。

例えば、エンジニアの立場に立つと勤怠とかにも目がいってしまう

そういうことから切り離すのが大事だと思っている。」

藤門さん

「一旦話を聞く。怒りを受け止めるというのが大事だと思う。」

名村さん

「ビジネスサイドに向き合うことが大事。

エンジニアの正論をぶつけちゃうと会社はなりたたないので、

歩み寄ることが大事だと思っている。」

藤本さん

「(自分は)信用があるのかという問題に気づいた笑」

伊藤さん:「次の質問です。CTO をやめるときはどうしていますか?」

伊藤さん

「普通ですよ。単に辞めたいと言った。」

名村さん

「僕の場合は、言う順番は気をつけた。

まずは社長に言って、現場に落とすときはどのようにコミュニケーションとるかっていうのは相談した。

あと、転職先にも内密にしてくださいとお願いした。」

伊藤さん:「次の質問、メンタルの持ち直しはどうしていますか?」

伊藤さん

「これは、相手がっていう意味ですよね?」

藤本さん

「共感することは良いことではないと思う。

なぜなら相手にプラスにならないから。

一緒に辛くなったら前に進めないから。」

伊藤さん:「次の質問です。情報収集はどうしていますか?」

藤本さん

社内のチャンネルで勝手に流れているから、それを見ている。

伊藤さん

「僕はそこに少し考えるところがあって、

昨今のトレンドを追い続けないと、今後やっていけないのかどうか?と思っている。みなさんどうですか?」

名村さん

「愛読書みたいなものはある。

hacker news とか。

あとは社内の slack に流れてくるものとか。」

伊藤さん

「最近は情報が多すぎて、そこら辺の感覚がよく分かっていない。」

藤本さん

「そこは取捨選択するのが大事だと思っている。」

藤門さん

「一次情報を大事にしている。

特に標準仕様の動き、例えば W3C や WHATWG をよく見ている。

論文だと例えば、facebook research もよく見ている。」

伊藤さん:「次の質問です。セキュリティへの投資はどう言う判断軸にしていますか?」

藤本さん

「昔、そういうところのコストを削っていた時期があったが、

心配されることがあって、そこからしっかりするようにした。」

伊藤さん

「自分は役割を分けている。

セキュリティをやる人と、CTO は別なほうがいいと思う。

CTO がオフェンスをやっているのに、セキュリティをやってしまったら、

それが削がれてしまうと思う。

ので、セキュリティは別な人に任せるようにしている。」

藤本さん

「プロダクションのサーバより、オフィスからやられることのほうが多いので、

そういうのは気をつけたほうがいい。そっちに投資すべき」

伊藤さん:「次の質問です。エンジニアの評価のバランスはどうとっているか?」

藤本さん

「開発とそれ以外で、担当を分けている。

開発は雑に言えば能力の部分を見ている。」

名村さん

「できてない部分が多くて、今作っているところです。

現状だと、マネージャーに任せているので、そこを整理したいと思っている。

なので、メルカリに関しては、バランスが取れていないと思う。」

藤門さん

「相関があって、

ビジネスのことも考えられる人はエンジニアスキルも高いので

そういう意味でバランスをとっている。」

伊藤さん

「うちの会社はまだ 50 人くらいなので

制度をよくするというよりは、僕が立ち会って納得感を出すようにしている。

あんまり問題は起こってないです。」

伊藤さん:「次の質問です。採用・不採用で大事にしていることはあるか?」

藤本さん

「自分の意見と他人の意見を同じ地平で考えられるかどうか。

自分の意見を第三者的にみて、ふらっとに考えられるかどうか、

という人しか取らないようにしている。」

伊藤さん

「それはどうやって見極めるんですか?」

藤本さん

「そういう議論を振ったりしている。」

名村さん

「こういう人はやめたほうがいいなと思う人は

意識が自分に向いている人。

評価だったり、価値だったりを、自分に矢印が向いている人」

伊藤さん

「それはどうやって見極めるんですか?」

名村さん

「期待値を下げると、そういうのをリジェクトできる。」

藤門さん

「カルチャーフィットするかを考えている。

いま、いろんな国籍の人と一緒に仕事することが多いので、

まずはカルチャーフィットを見るようにしている。

あとは、名村さんも言っていたが、期待値を下げるのもある。

例えば、AIエンジニアって綺麗そうな仕事に見えるけど、実は泥臭い世界。

そういう泥臭い仕事もできる人ですか?っていうのを聞くようにしている。」

伊藤さん

「僕は、現場が人欲しさにとっちゃわないかを見るようにしている。

基準がゆるまってないかをちゃんと見るようにしている。」

伊藤さん:「次の質問です。CTO が必要だと思いますか?」

名村さん

「メルカリの場合は、1プロダクトなので、

技術的負債が溜まっていったら会社として危ない。

だが、子会社が 100 社ありますとかいう会社で、全部に CTO が必要かと言われたら分からない。」

~今後とその先についてのディスカッション~

名村さん

「あんまり考えていないが、

会社と事業を伸ばすことを今はずっと考えているが、その先がどうなるかは分からない。」

伊藤さん

「僕らって同年代なんですけど、

これより上の年代の CTO の方ってあまりいない。

そういう意味でも分からない。」

藤本さん

「やりたいことやればいいと思う笑」

電車遅延を slack に投稿する lambda を作りました

以前書いた記事

電車の遅延情報をslackに投稿するbotをつくりました

が、サーバーにインストールして使う形だったので、

もっとお金をかけずに動かそうと思って、AWS lambda で動くプログラムを作成しました。

設定

まずはこちらを手元の PC にクローンしてください。

github:

https://github.com/acchanAlexander/notice-train-delay-to-slack-lambda

 

レポジトリのトップディレクトリで

npm i

とコマンドを打ってください。(npm のインストールが必要です。)

 

次に、落としてきたレポジトリの中にある、target_train.json に通知したい電車の情報を記載していきます。

 

name は、路線の名前です。

ここで設定しないといけないのは https://rti-giken.jp/fhc/api/train_tetsudo/ の路線名に合致する命名でなければなりません。

 

link は、詳細情報が載っているリンクを設定します。

通知されるメッセージ内に詳細リンクを貼るために設定します。

https://www.tetsudo.com/traffic/ にあるリンク先を設定するなどして使ったらいいかと思ってます。

ここの値はなくてもかまわないので、その場合は空文字列 ” などを入れてください。

 

roomId は、通知先の slack のroomIdを設定します。

roomIdについては、ブラウザでルームを開きURL末尾の messages/XXXXXXXXX/ となっている

XXXXXXXXX の部分です。

 

ここまで完了したら、lambda にデプロイする zip ファイルを作成します。

レポジトリのトップディレクトリで

zip -r notice-train-delay-to-slack-lambda.zip *

とコマンドを打ってください。

 

環境設定

lambda の画面の、「関数の作成」から関数を作成します。

関数名は適当な名前をつけてください

ランタイムは Node.js の 10 系を設定してください

実行ロールを設定してください。

lambda を実行できるパーミッションがついたロールなら OK だと思います。

今回は、基本的なロールを選択しました。

lambda の画面に移るので、

「関数コード」の「コードエントリタイプ」を「.zip ファイルをアップロード」に設定します。

「アップロード」のボタンより、先ほどの zip ファイルをアップロードしてください。

 

環境変数を下記のように設定します。

ADMIN_CHANNEL_ID は、エラー通知が飛ぶ部屋の ID です。

SLACK_TOKEN には、slack bot のAPIキーを登録してください

基本設定のタイムアウト時間は、10 秒くらいにしておいてください。

ここまでで、lambda の設定は完了です。

次に、lambda を動かす Cloud Watch Event の設定です。

Cloud Watch Event の画面より、「ルールの作成」をクリックします。

イベントソースを設定してください。

今回は cron 式で設定しました。ここの時刻は GMT になるので注意してください。

今回は 8:00 と 17:00 にしたかったので、下記のようにしています。

名前と説明に適当な内容を入力します。

以上で環境設定は完了です。

何か不具合があった場合は、Cloud Watch Logs にログが出力されますので、そちらをご確認ください。

【再演!エンジニアのためのコーチング入門】に行ってきました

再演!エンジニアのためのコーチング入門

https://coaching.connpass.com/event/143926/

に行ってきたので、そのときのレポート

 

人と話すことが苦手な人の方が、コーチングは上手くなる/三橋 新さん

コーチとして、可能性を選ぶか、評価を選ぶかで、

その後の方針が変わってくる

「なぜ、人と話すことが苦手な人の方が、コーチングは上手くなるのか?」

コミュニケーションとは、上手に話さないといけないのか?

コーチングの場合はそうではない。

究極をいうと、自分は話さなくてもよい。

相手の言うことを引き出すことに徹する。

逆に、喋りたがりの人は、抑える練習をしなければいけない。

3つの現実レベル

  1. KPI
  2. 自分はこう感じるというレベル
  3. 直感や、なんとなくのレベル

仕事では、上(1の方)の会話をよくするが

コーチングにおいては、抽象度を高めてみたほうが良い。

なぜなら、自分の無意識に触れられるから。

人は、話ながら頭を整理していく部分もある。

なので、質問をしてみて、相手に思考を整理させるようにする

まとめ

  1. コーチングで一番大事なことは何をどうするか?ではなく
    相手のことを信じて可能性を引き出すこと。
  2. 抽象的な問いかけをして、相手の思考を整理させてあげることが大事。

エンジニアリング組織の1on1におけるコーチングスキルの活かし方/谷内 真裕さん

「在り方」

1. 自己探求と自己管理

2. 向き合い方

「やり方」

3. 場づくり

4. コーチングのスキル

1. 自己探求と自己管理

1on1 をしていると、コーチングしている側も、自分についても考えさせられる場面がある。

そのため、自己探求はとても大事。

  • 1on1 の最中に、いろいろと考えてしまう。そうなると、相手の話を聞けなくなってしまう。
    • なぜこうなるのか?
      • 誰もが、Belief というメガネをかけている

Belief: 考え方や信念のこと

例えば、1on1 している側は、

「私はこの人をコントロールしなければならない」

「私はこの人よりも優れている」

「この人を変えないといけない」

etc…

ということを考えてしまう。

どうすればいいのか?

コーチングの切り口でいうと、自己探求(内なる声に気づく、暗黙的な Belief を探求する)が、大事。

例えば、日頃当たり前だと思っていることは

なぜなのかを考えずに、ショートカットしてしまう。

 

もう一つ大事なこと

自己管理(自分の内なる声を横におく)

自分のことよりも、相手のことを優先する。

そうすることで、相手の話に耳を傾けることができる。

 

自己探求(自分の内なる声に気づく)  自己管理(自分のことを横におく)

の順で進めて行くことで、相手の声に焦点をあてられる。

まとめ

Belief や囚われに気づくことから始める。

2. 向き合い方

1on1 をしていて/うけていて

暗黙的な何かを感じることはありませんか?

例えば

  • 本音を言っちゃうと、評価に影響するのではないか?
  • 1on1 をする側からすると、この人のレベルはこれくらいかなと思ってしまう。
  • 実は 1on1 に恐怖を感じているとか

etc…

それらは、隠していてもバレてしまう。

なので 1on1 をする側は、1on1 によってどうすれば

良い影響を与えられるか考えよう。

 

良い言葉として

「人はもともと想像力と才知に溢れ、欠けるところのない存在である」

というものがる。

 

それを意識するようにすると良い。

例えば、その人に好奇心と可能性を持つ。

それが、その人を信じることに繋がる。

 

順番としては、

  1. まずは自分を信じる
  2. 相手を信じる
  3. 自分の好奇心を育む
  4. 直感と遊び心を持って問いかける

ということをしていれば、自分も変わるし、相手も変わる。

相手を信じるほど、意外と自分も変わっていきます。

3. 場づくり

1on1 の大半の悩みは、場づくりがされていなくて、困っているはず。

例えば、

  • 話したいことありません
  • 時間が取れない。
  • 変化がない

etc…

こうならないために、1on1 をデザインしましょう。

例えば

  • ある程度形式が決まっていたら、思い切って崩してみよう
  • ネガティヴ / ポジティブ を話しても、安心してできるようにしよう。
  • 相手がとても困っているなら、1on1 を意識せずに、吐き出す時間にしよう

etc…

場づくりは、いつでもその瞬間から

相手と始めることができる。

例えば、1on1 の内容を定義づけしなくても良い。自由にやってもよい。

雑談で終わってもよい。会議室で行わずに、カフェとかでやってもよい。

起こることの全ては、相互理解と信頼関係のきっかけにできる。

順番としては、

  1. 1on1 の目的を説明する
  2. ふたりの関係性を構築する
  3. 相互理解をする。

4. コーチングのスキルについて

  • 反映というスキルは、相手の鏡になること
    • 言われて気づくもの
      • 今日は明るいね、疲れてるね。など

 

スキルは始めから使うのではなく、

相手との関係性が築けてから使う。

その上で、傾聴などを行う。

傾聴のスキルを養うには、やはり練習が必要。

本も大切だが、経験を重ねることが大事。

まとめ

相手にあたえるインパクトがスキルです。(こういうことが言えるからスキル、とかではない。)

遊び心をもって練習してみよう!


エンジニアリングマネージャー育成におけるコーチング~マネージャーにはどんな資質が必要なのか?~/ 安西 さん

例えば、上司が変わると環境がとても変わる。

仕事のやりやすさや、自由度など

そのため、エンジニアリングマネージャーは成長しなければならない。

マネージャーになると、「在り方」が大事になります。

ポイント:オーセンティックであるか?

オーセンティックとは?

日本はまだまだだが、海外では、リーダーシップをとる人はオーセンティックであるべきだと言われている。

オーセンティックとは、

「自分らしさ」を貫いていること。

昨今は、変化が激しすぎて、明確な答えがない。

そのため、「俺がこう言うんだからこうだ、ついてこい!」みたいなリーダーシップでは

人はついてこない。

そのため、自分らしさや、自分の考えをしっかりもつことが大事。

オーセンティックのポイント

  • 自己認識力を高める
    • 自分と向き合う
    • 自分がわかる
  • 他者のフィードバックを受け入れる。
    • 他者とのギャップを埋める。
  • 弱さを認める
    • できないこと、わからないこと、弱いことを自分で認めているか?
  • 弱みや恥を他人に話す
    • できないこと、わからないこと、弱いことを他人に話せているか?

強いリーダであるよりも、オーセンティックであることのほうが勇気が必要である。

べき論、リーダ像の思い込みを外して、探求し続けなくてはならない。


Q & A

Q1. コーチングという名前のイメージが、相手を導くというイメージがあるが、それについてどう思うか?

A1.

三橋さん

そうは思わない。

一緒に探していくものだと思う。

谷内さん

三橋さんと同じ。

その人が本当に望んでいるものを目指して行くのが大事だと思う。

 

Q2. 自分の弱みをさらけ出すのが大事というのも分かるのだが、弱みを出しすぎても威厳が保てなくなって、人をリードすることが難しくなるのではないか?と思っているが、そういうことありますか?

A2.

安西さん

それは、あります。

弱みをさらけ出すのはタイミングが大事。

初対面の人にさらけ出しても、良く思われない。

ので、関係性が築けてからさらけ出して、より良い関係にしていくのが大事。

あとは、弱みをさらけ出した結果、相手(部下)の方が優れていたら、教えてもらうことができる。

逆に、弱いにも関わらず、強いふりをしてしまったら、それは相手にバレて、一瞬で信頼がなくなってしまう。

それよりも、部下に教わって自分を高めることで、「この人は成長する人なんだ」と、部下にも思ってもらえる。

 

Q3. コーチングは基本的に相手にフォーカスして進めていくということだったが、何回コーチングしても相手が育ってくれなかったりした場合に、強めの言葉でフィードバックしないといけない場面があると思うが、そういうときに良いやり方はあるか?

A3.

三橋さん

相手ができない、やりたくないと思っていることがあると思うので、

コーチングの際は裏目的を聞くようにしている。

谷内さん

聞くモードに入るのか、フィードバックモードかを切り替える。

例の状況だったら、フィードバックモードに徹する。

事実ベースで伝えて、それに対して、相手がどうしたいのかを聞くモードで聞く。

よくあるが、全部を 1on1 で解決しようとしない。

1on1 をうまく使って解決するようにする。

安西さん

その人の根本的な課題な何なのか?を探る。

きっと、何か自発的な動機が引っかかってそのような状況になっているはず。

それを探るようにする。

 

Q4. 1on1 の場づくりのところに、「墓場まで持って行く」というのがあったが、それは守れているのか?というところが気になった。というのも、これは誰かに相談したほうがいいというのがあるから。

A4.

谷内さん

たしかに、そういう場面もあるので、

外への出し方も一緒に相談する。

例えば、「○○さんにこのこと相談していい?」という合意をとって進めるようにする。

全てを墓場まで持って行く訳ではない。

 

Q5. 評価をする側になってしまったのだが、コーチングする際に気をつけることはあるか?

A5.

谷内さん

「この会話は評価に影響しません」と約束をしてみるのはいいと思う。

また、会社の人っぽくないことをしてみるのも良いかもしれない。

例えば、一緒に散歩に行ってみるとか、ランチに行ってみるとか。

上司と部下という関係を意識しないようなことをしてみると良いかもしれない。

【コネヒトーク5th「ママリ、クックパッド、BASEのCTOが語る!組織づくりや技術選定について」】に行ってきました

コネヒトーク5th「ママリ、クックパッド、BASECTOが語る!組織づくりや技術選定について」

https://connehito.connpass.com/event/141459/

に行ってきたので、そのときのレポートです。

自己紹介

コネヒト CTO:伊藤さん

クックパッド CTO:成田さん

BASE CTO:川口さん

お題1:「CTO を打診されたときや、就任時の心境は?」

共通点として、それぞれ、2代目 CTO であること。

それを踏まえてのディスカッション。

川口さん

CTO になる前は、漠然と、同じようなテックリードなどを育てていくことになると、キャリアパスを考えていた。

ある日、初代 CTO の方から、CTO やらないか?と言われた。

理由を聞くと「まかなわなければいけない範囲をまかないきれなくなったので」だった。

そこで、技術に特化した範囲を担当する(経営にはあまり触れない)範囲であれば、やりますとなった。

伊藤さん

CTO に、ランチのときに、やってくれないか?と言われた。

CTO は辞めて、新しいチャレンジをしたいという背景だった。

迷ったが、迷ったら一番難しいことをやろうと決めていたので、やりますと回答した。

また、CTO という責任のあることをやるのはやりがいがあると思った。

成田さん

CTO になったのは結構前(2016年)

打診を受けたときは、ワクワクした。(「やっていいんだ」と思った)

もともと、CTO になったらやってみたいことがいくつかあった。

前の CTO を見ていても、自分だったらもっと上手くできると思う部分があった。

ただ、数年経って、前の CTO を改めて思い起こすこともでてきた。

お題2:「CTO って何をしているのか?」

川口さん

今日は、採用関係のことをしたり、技術マネージャーと MTG したりとか

リリース関係の優先度の判断をしたりとかを主にしていた。

結構 CTO になってから、採用周りの仕事は増えた。

質問:前 CTO との住み分けはどうしているんですか?

面接に来たひとにとっては、前 CTO が判断したほうがいいときとかもあって、

会社経営に関しても、前 CTO に任せている。

川口さんは、プロダクトに責任をもつようにしている。

成田さん

CTO として、いま困っていることをやるのではなくて

1 年後とか 3 年後とかに困りそうなことを対応しなくてはいけない。

そのためにはインプットが必要で、

あらゆるエンジニアの分報を確認したり、他の CTO の方の話を聞きに行ったりしている。

伊藤さん

経営会議などに出たりしている。

マネージメント業務を意図して自分に寄せている。

コードは書きたい気持ちもあるが、その気持ちは抑えて、

戦略を考える時間を多くするようにしている。

お題3:「事業会社の CTO としての大変さは?」

例えば、事業会社だと、0 -> 1 でスクラッチで開発する機会が少なく、

挑戦だったりモチベーションの対応とかどうやっているのか?

成田さん

クックパッドは 20 年近いシステム

それを改善していくのが日頃の業務。

確かに、技術的なチャレンジをどうするか?

グロースするにしても、CM 打ってもあまり変わらないとか、アプリランキングが上がっても下がっても売上に影響ないとか。

そういうフェーズに来ている。

なので、日頃の業務が楽しいと思える人が活躍できる現場になっている。

成田さんは、そういう中で、現場のモチベーションを保つように意識している。

伊藤さん

ある程度、新しい技術を取り入れる事に関しては

方向性を示していかないといけないのかなと思っている。

川口さん

PHP 界隈では大きなシステムになってきている。

逆に、PHP 書けないと入社できないのかなと思われるのが良くないと思っている。

そこで、新しい技術を取り入れることも考えるが、

PHP で作ったほうがスピードが早かったりもする。

そういう面で、悩んだりはする。

成田さん

そういう時に、マイクロサービスなのかなと思っていて、

マイクロサービスは失敗がしやすいと思っている。

新人が入って来た場合は、既存の技術スタックを学ばないといけない側面があるが、

失敗がしづらいと思っている。

成田さん含め、失敗してきて積み重ねてきたのが今を作っている。

Rails 以外にもバックエンドだと、Go, Rust, Java など使っている。

質問:ハレーションなどはありませんでしたか?

既存のシステム構成だと、デプロイのスピードが早いというメリットがあったが、

マイクロサービスを取り入れると、整っていない環境になってしまうので、

メリットが感じられず、反対意見が多かった。

環境が整うと、誰も何も言われなくなった。

Q & A

Q1CTO をしている上で、決断を迫られるとき、苦境に立たされたときにどのようなモチベーションを保つようにしているか?

成田さん

苦境はメッチャある。

苦境は基本、人にある。

目の前にいる人が働いていて楽しくないとか、そういうことが苦境になる。

そういうときのモチベーションはサービスにある。

会社の中の揉め事は、サービスに関係ない。

川口さん

成田さんとほとんど同じ。

僕らが立ち止まっていても、お客さんは知ったことではない。

サービスを使っているのはお客さんなので、

決断を求められたときの判断材料は、サービスのためになるかどうか。

伊藤さん

二人とほとんど一緒。

最後の判断基準はプロダクトだなぁと思っている。

サービスのことを考えて、意思決定をするようにしている。

成田さん

もともと成田さんはインフラをやっていたので、ログをよくみていた。

それが心の支えだった。(ログの向こうに、ユーザを感じることができる)

エンジニアがクックパッドに入るが、相性が合わずに辞めていくことが残念だと思うが

それよりもサービスが止まっていることのほうが問題。

川口さん

同じく、サービスが止まっていて一番困るのはお客さん。

また、それぞれのエンジニアの中で、サービスが止まっているときの不信感を考えながら

判断をするようにしている。

Q2:「それぞれの理想の CTO はいますか?」

伊藤さん

ないです。

その中で、前職の CTO の人が、どんどん周りを引っ張っていくタイプだったが

その人に「同じようなことができない」と言ったところ

「自分にしかできないことがあるので、同じようにしなくてもよい」と言われた。

なので、明確な理想はなくて、自分で作っていくしかないんだろうなと思っている。

川口さん

ユーザになりきれないサービスを担当していて、困ったことがあったが、

やっぱり、いとうなおやさんはすごいなと思う。

成田さん

従業員がユーザになれるサービスはとてもいいと思う。

伊藤さん

ママリとかは、男はどうしてもユーザになれないが

そこは、ユーザではないからこそできることもあると思っている。

それが、データドリブンだったりとかそういう手段があると思う。

そもそも、コネヒトとして掲げているものがあるので、そこをモチベーションにしていることもある

川口さん

前職で、乙女ゲームをしていたが

会社ではユーザではなくお姫様と呼ぼうと言われていた。

ので、いまだにユーザと呼ぶとドキドキする。

成田さん

自分も同じで、前職はユーザと呼んでいなかったので

クックパッドでユーザと呼んでいるとドキドキする。

Q3:「中長期の技術戦略を考える上で、どういった進め方をしているのか?例えば、製品に直接関わらない技術改革などを、どうしているのか?」

成田さん

あまりそういうことは、現状していない。

いままでの CTO やエンジニアを踏襲しているフェーズ。なので変えてない。

未来に向けて動くというのは、そういうところではなくて、どっちかというと

インサイト:従業員の気づいていないことにどう気づくか?

に目を向けるようにしている。

なので、過去 3 年分の記録を追ったりして、みんなが気づけないことに気づくようにしている。

長期的に見る目線が大事。

伊藤さん

まだ行動に移せていることはないが、

伊藤さんが CTO になったときに、経営陣が刷新された。

新しい経営陣のビジョン等を聞いて、CTO としてどうコミットできるかを考えているところです。

川口さん

経営に関することは、他の人に任せていて、

技術戦略を考えないといけないが、いまはまだできていない。

そこで、3 年後とかのために、材料を集めているところ。

成田さん

採用を通す人が変わった。

この人が入ると会社が変わるのかな?という目線で考えるようになった。

現場にちょっとと思う人でも、会社にとって良い行動を起こしてくれる人なども

採用していかなければなと思っている。

お題4:「CTO として今後やっていきたいことは?」

成田さん

成田さんが CTO をやっている理由が、クックパッドのミッションを達成するのが好きだから。

だが、結局は人だと思う。

成田さんが学生のころ、友達の部屋によく遊びに行っていた。

そういう、みんなが集まるような場にクックパッドもしたいと思うようになった。

そういう文化が、組織を強くして、サービスを強くするんだと思うようになった。

川口さん

いまのサービスを日本で 1 番にしたい。

ただ、その思いは、自分がインターネットが好きだから。

だからこそ、インターネットに貢献したい気持ちがある。

CTO は責任をもらっていて、それが重要だと思う。

最終的な決定権は CTO になると思う。

採用に関しても、インターネットに貢献できる人を採用できるようになったのが良かったと思っている。

伊藤さん

家族を幸せにするサービスを作りたいと思っている。

伊藤さんは自由に育てられた。それをなんとも思っていなかったが

大人になって、恵まれていたと思うようになった。

家族に対して、幸せにしたいと思うようになった。

そこにコミットしていきたいと思うようになった。

CTO として、そういうことをしていきたいと思うようになった。

ビジネスにテクノロジーが貢献している会社がテックカンパニーだと思う。

家族を幸せにしたいというビジョンに対して、テクノロジーを使って貢献していきたいと思っている。

チームの一員の縁の下の力持ちでも、それはとてもカッコイイことだと思う

概要

例えばプロジェクトが成功して、代表して表彰される人がいたとします。

例えばスポーツの試合の中で、点を決める役で周囲から注目される人がいたとします。

 

そうではなくて、

多くの人から脚光を浴びる訳でもなく

よく話題になるような人物でもなく

ただ、チームのために自分のできることをやっていくような人物

そういう、縁の下の力持ちな人は、とてもカッコイイし、誰かに認められると報われるなぁと思うという話です。

(脚光を浴びる人を否定する訳ではありません。)

内容

プロジェクトでとても大きな功績を納め、代表して表彰される人。

スポーツの試合の中で、点を決めて一番盛り上がるし、名前も覚えられる人。

もちろん、その人たちが他者から脚光を浴び、認められるのはすばらしいことだと思います。

ですが、その人たちが活躍できるのは、その人がすごいからだけでしょうか?

その人さえいれば、プロジェクトは成功し、試合にも勝てるのでしょうか?

私は違うと思っていて、

例えば泥臭い雑用だったり、小さな仕事をしっかりと納める人

そういう人がいたからこそ、目立つ人が活躍できているのだと思います。

 

例えば、結果が目立たない仕事をしてくれる人がいない場合

誰がやらなければいけないでしょうか。

きっと、結果が目立つ仕事を本来はするはずだった人がしなければいけないと思います。そうなると、結

果が目立つ仕事を本来通りこなすことができるでしょうか?

 

試合で点を取る人ではなく、防御に徹する役の人がいなかった場合、点を取る役の人にボールは回ってくるでしょうか?

 

泥臭い雑用だったり、小さな仕事をしっかりと納める人がいるからこそ

活躍できる人が活躍できるのだと思います。

 

少し話は変わりますが、

泥臭い雑用だったり、小さな仕事をしっかりと納める人はどのくらいの価値があるのでしょう?

 

私個人の意見ですが、目立って活躍する人、目立たずに仕事を納める人、どちらが価値の高い仕事をした

かは測れないものだと思っています。

理由は、先ほど述べた通り、目立つ人は目立たない人がいるからこそなりたつからです。

 

ここまで話して何が言いたいかというと

そういう、縁の下の力持ちな人は、誰かから賞賛されなくても、とてもカッコイイなぁと思うという話です。

なぜなら、その人がいたからこそ、プロジェクトが成功したり、試合に勝てたりしているので、脚光を浴

びている人と同じくらいカッコイイと思うからです。

もっというと、誰かに認められるともっと報われるなぁと思います。

(何度も言いますが、脚光を浴びる人を否定する訳ではありません。)

 

なので、僕はもし賞賛される立場になったとしても、

目立たなかった人のことも一緒に讃えてあげたいし、

もし自分以外の人が賞賛されていて、僕の努力も報われるなら、一緒に同じくらい喜びたいなぁと思います。

 

以上、ただのポエムでした!!

 

P.S.

会社自慢をするつもりではないですが、

弊社では月 1 で MVP が讃えられるのですが、

よく「○○さんのおかげで MVP になれました」って言ってる人がいて

とても良い社風だなぁと思います。

「Google Cloud で実践する Web アプリ開発」に行ってきました!

Google Cloud で実践する Web アプリ開発

https://developers-jp.googleblog.com/2019/05/google-cloud-web.html

に行ってきたので、その時のレポート

 

Web フロントエンド開発最新動向:グーグル合同会社 宇都宮 佑亮

資料

https://cloudplatformonline.com/rs/248-TPC-286/images/Web_application_development_using_Google_Cloud-01.pdf

 

以下、講演を聴きながらのメモ

 

chromeは生誕 10 周年

googleは生誕 20 周年

www ができてから、30 周年

 

いまはそんな時代。

 

そんな時代の中、

ユーザがwebを閲覧する環境が変わってきている

デスクトップ → スマートフォン → Feature Phone

このような環境に我々は対応していかないといけない。

 

現在の web の中央値の話

6sec (FCP)描画されるまでの時間

9sec (TTL)ユーザが使える状態になるまでの時間

 

速度がユーザ体験を向上させる。

それが、CVR の増加などビジネス側の向上にも繋がる。

 

速度改善のやり方として、いろいろなアプローチの方法があるが

「画像の最適化」 から初めてみるのもいいかもしれない

画像の最適化を CDN に任せることで、自社のサービスに集中できる。というメリットもある。

その上で、js, css 等の最適化を行っていってもよい。

 

よくある現象として、速度を改善したが、

半年後に、また遅くなっているという現象がよくある。

そのために、Performance Budget という考え方がある。

Performance Budget とは、これ以上遅くさせてはいけないよという基準のこと。

例えば、ユニクロでは、各スクリプトを 80kb 以下に抑えるという基準を設けている。

 

自社のモニタリングも大事。

その一つのツールとして、

Chrome UX Report

というものがある。

その他にも、

  • Google Seach Console
  • Firebase のパフォーマンスモニタリング
  • Righthouse
    • chrome のエンジニアが開発している

PROXX というアプリを作ってみた。

https://proxx.app/

これは、Feature Phone でもサクサク動く。

使っている技術として、Web Workers などのノウハウを凝縮している
→ オープンソースなので、みんな参考にしてね。

 

その他の工夫の仕方として

あらかじめ次のページを読み込んでおくという方法もある。

 

WEB はモバイルだけの話ではない。

デスクトップでも PWA でホームに WEB アプリを配置できるようになってきている。
 → Desktop PWA という。
  → hulu がすでに実装している。

 

また続々と、Web でできる技術の範囲を広げている。

たとえば、

  • 指紋認証も Web でやりたい
    • Web Authentication という技術を使って実装できる
  • カメラのアクセスもやりたい
    • Shape Detection Api というのを使って実装できる。

まとめると、

新たな API を段階的に公開(予定)
→ 標準化と並行して、デベロッパーに使ってもらう環境を提供していくよ。

JS AMP の話

AMP は 最初モバイル用に作られていたが、

いまではデスクトップ用に実装することも可能。

 

AMP 3年間の歴史がある。

最初はできなかったことが、今ではできるようにもなってきている。

 

例えば、

  • URL の問題
    • domain google.com になってしまう
      • web packagingAMP Packager Cloudflare)を使えば対応できる
  • AMPではJSが使えない問題
    • AMP のページにも js が使えるようにします!
      • トライアルを現在提供している。

AMP の面白い機能として

  • AMP Stories
    • 画面全体に画像を出して、テキストも出して、本を読んでいるような感覚になるような使い方もできる。
      • 没入感もあって、時代にあった使い方ができる。
  • AMP For Email

その他にも、youtube THE AMP CHANNEL というチャンネルがあって

そこで、日本語での今後の AMP などについての配信をしている。


GCP のサーバーレスサービス紹介:グーグル・クラウド・ジャパン合同会社 篠原 一徳

資料

https://cloudplatformonline.com/rs/248-TPC-286/images/Web_application_development_using_Google_Cloud-02.pdf

 

以下、講演を聴きながらのメモ

 

そもそもサーバレスって?

  • インフラの管理がいらない
  • 下のレイヤ(OSなど)はプロバイダがよしなにやってくれる
  • 使った分だけの課金

web アプリケーションを開発する際に考えること

  1. アプリをどこでうごかすか?(コンピュート)
  2. DB
  3. 非同期処理
  4. 静的コンテンツ
  5. コード管理・ビルド・デプロイ
  6. モニタリング・ロギング・APM

今日は時間の関係で、 4 までの話をする

コンピュートの話

  • Cloud Functions
    • 関数を配置する
      • イベントドリブン。いろいろなイベントを受け取ることもできる。
      • サーバ管理なし。
      • 20を超えるサービスと連携することができる。
      • 注意点:サポートされている言語以外は使えない。
  • App Engine
    • 世の中でいう、PaaS
      • スケールアウトが高速
      • アプリのコードに集中できる。
      • Cloud Functions と同じで、ランタイムがある。
      • 柔軟なデプロイが可能。
      • コードに更新をかけてデプロイしたら、「v2」 のようにエディションを提供してくれる。
      • 注意点:ランタイムに種類があるので、注意
  • Cloud Run
    • Knative:oss のツール。k8s の上にサーバレスの実行環境を作ってくれるもの
    • Cloud Run はコンテナのイメージを渡して使うもの。
      • つまり、言語やライブラリの制約がほとんどない。
      • 2種類ある。Cloud Run と、 Cloud Run on GKE というものがある。
        • on GKE に関しては、使った分の課金ではなく、載せる node の数での課金になる。
    • 注意点:コンテナを必ず使わないといけない。ビルドプロセスを決めないといけない。

DBの話

GCP storage option で検索したらユースケースが出てくるよ!

  • Cloud Firestore
  • Firebase
    • リアルタイムにデータを同期
  • Cloud SQL の話
    • フルマネージドDB
    • 高可用性
  • Cloud Spanner
    • リレーショナルセマンティック + 水平スケール
    • RDB, 非RDB, 両方の特徴を持っている。
    • 注意すべき点:既存DBとの互換性がない場合がある。ので、改めてテーブル設計が必要になることも

非同期の話

  • Cloud tasks
    • キューイングして実行したり、スケジュールでの実行もできたりする。

静的コンテンツの話

  • Cloud Storage を使った静的コンテンツ配信

まとめ

  • GCP を使えば、インフラの管理がとても減るよ!
  • コンピュートとDBがいろいろあって、特徴があるので、適材適所で使っていこう!
  • モニタリング・ロギング・デプロイのサービスも GCP にはあるので、ぜひ使ってね!

 

リクルートにおけるWebパフォーマンス改善の取り組み:株式会社リクルートテクノロジーズ 新井 智士 氏

資料

https://cloudplatformonline.com/rs/248-TPC-286/images/Web_application_development_using_Google_Cloud-03.pdf

 

以下、講演を聴きながらのメモ

リクルートでの取り組み

  • ライブラリ・ツール開発
  • 性能改善
  • 教育

今日は「性能改善」について話すよ。

  • パフォーマンス改善に関する勉強会開催
  • Google主催のスピードハッカソン参加
  • 社内スピードハッカソン開催
  • AirSHIFT 性能速度改善

SUUMOでの性能改善の取り組み

  • SUUMO 2009 年から運営されていて、10年越えのサービスだよ。
  • 多くの機能追加開発を続けてきているよ

そこで、

機能を追加する分、ページ表示性能低下の懸念が出てきた。

たびたび性能改善されているが、戻ってしまう。

  • 「改善案件」になってしまう
  • 改善する人が属人化してしまう
    • なかなか定着しない。

WEBパフォーマンスについて」(これまで)

  • レスポンスはどのくらいで帰ってくるか

WEBパフォーマンスについて」(現在)

  • コンテンツがリッチに
  • 低スペックな端末や通信環境
  • 待ち時間の 80-90% がフロントエンド

つまり、サーバサイドの検証だけではいけない。

モバイルユーザが求めるものとしても、スピードが上位になっている。

ので、パフォーマンスはユーザ体験に影響を与える!

SUUMOでのアプローチ」

  • 予防
    • 現状の可視化・共通認識化・案件の企画設計から意識
  • 維持
    • 指標と基準を定めてアラート
  • 改善
    • 基準に満たないページを改善

「性能改善ハッカソン」

  • パフォーマンス改善に向けて、1日くらい時間を使ってハッカソンをする。
  • ポイントとしては、
    • アーキテクチャやビジネス上の制約を無視して点数をあげる!
    • 範囲を狭める(数ページ程度)
  • 効果は
    • 案件リストが作成できる
    • 普段触れない部分に触れる
    • 意識向上
    • ボトルネックが明確になる
  • 結果
    • 短期間で施策提案ができた
    • スコア改善
  • 適用
    • 価値、難度、コストで評価
    • 簡単にできて効果のあるものから順番に実施。
    • テストはもちろんしっかり行う。

効果が出ても、すぐに戻ってしまうので、

パフォーマンスバジェットを定めていこう!

  • レポーティングしよう
  • 一定期間でサマリを出して、全体周知
    • ビジネスサイドにも意識してもらうようにしよう!

まとめ

  • SUUMO では、改善 -> 維持 -> 予防の順で進めている
  • ハッカソンでの改善を入り口に
  • レポーティングで共有し、企画・設計段階から意識できるように
  • いろいろな人を巻き込むことで、属人化を防ぐ

インフラ管理不要の Firebase GKE で実現するモバイルアプリ開発:株式会社Ginco 西川 達哉 氏

資料

https://cloudplatformonline.com/rs/248-TPC-286/images/Web_application_development_using_Google_Cloud-04.pdf

 

以下、講演を聴きながらのメモ

モバイルアプリの技術選定

少数で、期間も短いプロジェクトだった。

そこで、重要な部分に集中したいので

Firebase GKE を選定した。

ブロックチェーンとは

  • 履歴データの保存(トランザクション)
  • 特定の管理者によって操作されないというメリット

ブロックチェーンで大事なことは

  • 可用性
    • node が落ちないように
  • バージョンアップのしやすさ
  • 作って壊してをやり易い
    • 未知な部分が多いので、あとから構成をばっくり変えたいということがおこるため

ここでぴったりな技術が、K8Sだった。

そこで、GKE を使った。

ブロックエクスプローラを作る際に大事なこと

  • 可用性
  • リアルタイム性
  • 作りやすく、壊しやすい

Firebase を導入して変わったこと

  • サーバ管理コストなし
  • スケーリング対応
  • リアルタイムアップデート

Cloud Firestoreにしてよかったこと

  • APIが減る
  • リアルタイムにできる
  • インフラの複雑性が下がる

Firestore を導入するにあたって

  • クライアントから直接アクセス可能
  • APIキーはクライアントが持っている
  • そのためのルールが必要

まとめ

  • firebase 内での連携が簡単で工数低い
  • サーバレスなのでメンテコスト低い
  • クライアントエンジニア主体の開発に専念できる。

人を嫌いになりにくくするために

概要

私は、「この人が嫌い」というのが
周りの人と比べて、少ないほうだなぁと思います。
嫌いな人が少ないと、メリットも多いと思っています。

  • どんなメリットがあるのか
  • どうやって人を嫌いにならないのか

を書いていこうと思います。

嫌いな人が少ないメリット

メリットが多いというよりは、デメリットが少なくなることのほうが多いかもしれません。

嫌いな人がいると

  • この人とは一緒にいたくないなぁ
  • SNSで見かけるたびに、少しモヤっとする
  • 嫌いな人とどうしても接さないといけないときに、ストレスがたまる
  • また、接したあとにいろいろと不の感情が湧く

と、ストレスや不の感情が発生してしまうと思います。
嫌いな人自体が少ないと、そのようなことが少なくなります。

メリットとしては

  • 本来嫌いになるような人を完全に遮断しないので、その人の良い部分にも気づける
  • 良い部分に気づけると、自分のためになる(取り入れられる)
  • 友達が増える

などでしょうか。

では、どのようにして私はあまり人を嫌いにならないのかを書こうと思います。

人を一側面だけで判断しない

例えば、ある人があなたに対して気に障ることを言ったり
明らかにおかしなことを言ったとします。
人間は感情的な生き物ですから、そうされた瞬間に相手を敵だと思ったり
「この人は自分とは合わない性格なんだ」と思ったりしてしまいます。

ただ、ここで一度冷静になってみましょう。
もしかしたら、相手も「あっ、いまの発言ミスった」と思っているかもしれない
もしかしたら、まだその人のことをよく知らないのに、相手の性格を決めつけているかもしれない。
もしかしたら、相手も今発展途上で、いい性格になろうとしている最中なのかもしれない。
もしかしたら、相手の悪いところだけを見ていて、良いところにまだ気づけていないのかもしれない。

そう思うようにしたら、
「この人は私とは合わないから嫌い」と決めつけるには早過ぎると思いませんか?
もしかしたら、「嫌い」と決めつけてしまうことによって
例えば

  • 本当なら仲良くなれた
  • 良いところがあって、それを学ぶことができた

という機会損失につながる怖れもあります。
「まだ判断するには早い。もうちょっと様子を見てみよう」
と、焦らずに相手のことを判断するようにしましょう。

相手はまだ発展途上なのかもしれないと思う

人は年齢を重ねていったり、いろんな経験を積むことで、
人当たりの良さだったり、人に好かれるにはどうすればいいのかだったりを知っていきます。
相手にはそれがまだ足りていないのかもしれません。
相手がまだ発展途上の段階で「嫌い」と思うのは、ちょっと寂しい気がします。
もしかしたら、その人も時が経つにつれて、人格が変わり、嫌いではなくなるかもしれません。
上から目線になる必要はありませんが
「この人はまだ、人に嫌われないためにどうすればいいのかがまだ分かってないんだな」
くらいに思って、長期的な目線で判断するのもよいのではないでしょうか。

相手の良いところを見つける

これは小学生の道徳で習うようなことですが、改めて大事だと思っています。
一度嫌いになった人でも、
「あ、実はこの人こんな良いところがあったんだ。それなら仲良くなれそう。」
と気づくことがあると思います。
上で書いた「人を一側面だけで判断しない」にも少し重複しますが、
相手の良いところを見つけてみましょう。

ただ、これは少し難しいかもしれません。
なぜなら既に「その人のことが嫌い」という固定観念があるので
「この人にはこういう良いところがあるかも。でもこういう嫌なところもあるしなぁ」
と打ち消してしまいそうになります。
ただ、良いところを複数探しているうちに
「あれ、意外とこの人良いところがいっぱいあるぞ。総合的に見たらそこまで嫌な人じゃないかも」
というくらいになれれば OK だと思います。

都合の良い関係になる

都合の良い関係というのは聞こえが悪いかもしれませんが、言いたいことは
どうしても関わらないといけない相手とは、
「嫌い」な面では関わらず、「嫌いじゃない」面だけで関わるようにすることです。

例えば、雑談をしているときは嫌いじゃないんだけど
仕事の話になると急に嫌いな面が出てくるような人とは
極力仕事の話はしないようにする、などです。
嫌いな面がはっきりしていて、限定されているときは
この方法もありだと思います。

が、どうしても嫌いな面でも関わらなければならない関係の人がいた場合を
次に書きます。

逃げる、相手に合わせる

これは結構最終手段です。
どうしても好きになれず、合わない相手と関わらなければならない状況であるならば
我慢せずに逃げましょう。
例えば、仕事だったら部署移動をするなどです。
複数人の仲間内で 1 人だけ嫌いな人がいる場合は
その人が来る飲み会には参加しないなどです。(ちょっと寂しいですが)

「我慢は美徳ではない」と、
とある著名な方もおっしゃっていました。

どうしても嫌ならその環境から逃げましょう。
無理して我慢して耐えるだけのメリットがないのなら、スパッと関係を切りましょう。
ただ、関係を切る前に、これまで書いたような「なるべく嫌いにならない方法」を試してみてからをおすすめします。

もう一つの更に最終手段は、「相手に合わせる」ことです。
先ほどの「我慢するべきでない」と矛盾するかもしれませんが、
逃げることもできない状況であれば、
相手が変わることを待っていても状況は変わりません。
「相手に合わせる」というのは、聞こえは悪いですが

  • ご機嫌取り
  • 自分の意見よりも相手の意見を優先する(納得していなくても)

のようなことです。
これはストレスがたまりますが、この方法の目的は
「相手と対立する」を避け「相手のことが正しい」と見せかけ上同意することで
相手もそれほど自分に対して嫌なことをしてこなくなるということです。
相手からしても、「自分と意見が合わない」「相手が対立してくる」
というところから感情的になって、嫌なことをしているのかもしれません。
それを回避するための方法です。
良い例をあげると、「子分」のような存在になることですね。

気にしない

最後になりますが、
これは私ができていることで、一番効果のあることですが、
これを読んでいる人も実践できるかと言われると、難しいと思うので最後に書きました。

何か相手に対して「嫌だな」と思うと同時に
「あ、はいはい。人生嫌なこともあるよね。まぁいっか。」
と思うことです。

これはどうすればできるようになるのか、私自身わかりません。
いつの間にかできるようになりました。

強いてやり方を説明するとしたら、 脳天気 になることです。
嫌な人に対して、

  • どうでもいいと思う
  • 自分とは関係ないと思う
  • まぁいっか。死ぬわけじゃないし

と思うことかなと思います。

最後に

いろいろ書きましたが、
もしかしたら賛否両論あるかもしれませんが
これを読んで少しでも「人があまり嫌いにならなくなった」という人が増えると幸いです。

抽象的な指示や課題をゴールに持っていく方法

前提

最近、私は部署移動したことにより、担当する仕事の内容が大きく変わってきました。
これまでは、1 つのサービスを 50, 60 人くらいのアプリケーションエンジニアで改修する内の一人で

  • ボタンや画像の位置を変えたい
  • ここに表示しているものを、こっちにも表示させたい
  • CMS のフォームに新しい項目を作って、表側にも表示させたい

ということを 4 年間ほどやってきました。
社内で使ってるフレームワークを触る月日が増すごとに、

  • この案件の場合は大体ここを触れば解決するな
  • ここは調整が必要だから事前にやっておこう

ということがだんだん分かるようになり、
「この要件を満たすためには、何をすればいいのか」
と言う答えが、少し調査するだけで大分明確になるようになってきました。

そして最近部署移動した現場では、
複数のサービスを 2,3 人で回すという環境にいます。
更にいうと、成熟した大きなサービスではなく、
小さいサービスで、どういうことをすれば良いのかがはっきりしていない場合が多いです。

これまでは、
「これを実現するためには、このくらいの日数が決まっていて、決まったことをやる」
だったのですが、今は
「大体こういうことができるようになりたい。日数は大体で決まっている。何をすれば良いかは自分で考える」
ということが多くなってきました。

そこで、抽象的な課題や指示に対して、自分がどう動いたらよいのか
最近学んだことを書こうと思います。

要件をちゃんと把握する

当たり前かと思いますが、これがとても大事です。
「そもそも何がしたいのか」「何ができればよいのか」を分析することで
次の一歩に進むことができます。
逆にここをしっかり把握していないのと、後からいろいろ計画したことに変更が出てしまい、手戻りが多くなると思います。

その際、要求を出す側も

  • 「大体こんなことがしたいんだよね」と明確に決まっていない
  • 先輩や上司が、”あえて” はっきりとした要求をしてこない

ことがあると思います。
その時は、

  1. 現状の課題の本質は何なのかを調べたりヒアリングしたりして
  2. 市場でどのような事例があるのかを調べ
  3. 今回どのように活用できるか、あてはめられるのか

を調べて提案してみましょう。ググるのはエンジニアの得意分野だと思います。

まとめると、

  • 要求をしっかり把握しよう
  • 要求自体が抽象的だったら、具体的な形になるまで調査、仮説、提案を続けよう

です。
エンジニアリングとは
「曖昧さを減らし、具体的な状態にもっていくことだ」と、とある本でも書いてありました。

「調べる考える」だけでは終わらないし、「調べる考える」は無限にできる

  • より最適な解が出せるように
  • より間違わないように

と、「調べる考える」ことをするのは大事です。
ですが、答えが 1 つではないことに対して「調べる考える」は無限にできます。
仕事において時間は有限ですし、なにより「調べる考える」だけでは何も生み出せません。
逆に、調べれば調べるほど選択肢が増えて何が良いのか分からなくなることだってあるでしょう。
ある程度調べたら、区切りをつけて行動に移しましょう。
ある程度というのは

  • 時間
  • 理解度
  • 「あとは試してみないと分からない」と思う

などで判断するように私はしています。
しかし、最初の頃はどこまで調べたら区切りになるのか難しいものです。
理解度が浅く、もっと調べたほうがよいのではないかと不安になる気持ちも分かります。
なので、そんなときは先輩に
「これこれこういうことを、このくらいの時間かけて調べて、こうしようかと思っているのですが、進めちゃってもよいですか?」
と、聞いてみましょう。

曖昧な状態だからこそ、他人にレビュー(意見・指摘)をしてもらおう

曖昧な状態を、より具体的な状態に移行していこうという話をしましたが、
それを個人で実行した場合、それは個人の主観で決まったことです。

曖昧な状態であればあるほど、答えは 1 つではなく複数存在します。
個人で考えたベストな解があったとしても、
どうしても考慮漏れや、要求されていること自体の勘違いが生まれてしまいます。

そこで、他人の目線で意見や指摘をもらうことで、
案をブラッシュアップさせていきましょう。

こうすることで、成果物の質が大きく上昇するだけでなく
これまで自分が盲点になっていた部分に気づくことができ、次回に活かせることができます。

なので、(悪魔で例ですが)

  • 要件定義が終わったタイミングで一度レビュー
  • 設計が終わったタイミングで一度レビュー
  • 工数を考えた段階で一度レビュー
  • 何か困ったことや他者の意見を聞きたいときは相談

などのように、複数回、他者の意見を仰ぎながら進めていくのが良いと思います。

最初は理想系を考えよう

  • 顧客の要望にバッチリ対応できている
  • 今後何か変更があった場合でもちゃんと対応できる。
  • 今後何か起こった場合でも、人の手を入れずに自動で対応できる

などなど、完璧さを追い求めて理想の形を考えることはとても大事です。

慣れていない頃は、何か要求があった場合は
どういう完成形が理想なんだろう(工数や制約は度外視して)ということから考えましょう。
そこから、工数や運用時の現実などの制約を満たせるように、
理想系から現実的なものへと少しずつ変化させていきましょう。

まだ経験の浅い人にとって理想を最初に定義しておくことは

  • 何かスケールしたい時に対応ができる
  • スケールすることを前提に考えたミニマムな設計ができる
  • 仮に大きなシステムを設計することになったときの練習ができる

というメリットがあります

最初から工数や制約との兼ね合いを気にして計画を立てられるような、
経験値の高い人はそれでもよいでしょう。

このように、何か抽象的なことを始める際には

  1. 要求が何かを分析する
  2. 最適な理想形を考える
  3. 時間的な制約などから、現実的に実行できそうな解に落とし込む

というフローが必要だと思います。

予想される完成物について、定期的に連絡を入れる

完成物が全て完成してから、求めていた人に見せると

  • 完成物が思っていたものと違う。
  • 完成物が出た段階で、なんか違うことが分かった

ということが起きかねません。

また、抽象的な問題や課題は、
過程を踏むごとに具体的になっていくため
解決されるまでの過程で完成形が少しずつ変わっていきます。
そのため、

  • この方針で進めて良いか?
  • このまま行くとこういう完成物になるけど良いか?

ということを、区切りのいいタイミングで求めている人に確認してもらいましょう。

まとめ

  • 仕事において、正解は 1 つではない。(抽象的な問題であればあるほどなおのこと)
  • 抽象的な問題の正解は、落とし所(着地点)を自分で決めていこう
  • そのためには、たくさん調べて、たくさん経験して、たくさん試してみて、比較検討を行おう(ただし、時間的制約もあるので、ここまで調べたら終わりという区切りもつけよう)
  • またその際には、区切りがついた段階で、1 ステップずつ、他者にレビューしてもらおう

「ママリ、ミラティブ、PARTAが語る!今の時代で勝ち残っていくSNS活用術」に行ってきました

ママリ、ミラティブ、PARTAが語る!今の時代で勝ち残っていくSNS活用術(大湯・赤川氏・鈴木氏)

https://connehito.connpass.com/event/117450/

に行ってきたので、そのときのレポート

今回のパネルディスカッションで話すこと

  • サービス立ち上げやグロースにおける活用術
  • どのようにユーザーをファン化させるコミュニケーションをとっているのか
  • SNSから発見する、ユーザーのニーズや新サービスの機会
  • SNSプロモーション激戦時代においての勝ち方

まずは自己紹介

ママリの大湯さん

ママリでの SNS との関わり方について

Q & A のコミュニティがあって、長い文章でやりとりしてもらってたりもする。

インスタとか LINE, Facebook でファンをだいぶ獲得している

今となっては、インスタで「ママ」と検索するとママリが検索候補で出てくる。

mirrativ の赤川さん

mirrativ について

100万人以上ゲームの配信プラットフォームいる

国内だと最大プラットフォームになっている。

そういうところを先取っているサービス

 

SNS との関わりについて

メディアを作っているつもりはない

twitter の次を作っている感覚。

twitter やインスタに上げないともったいないという感覚を拾って

それを補助するような形をとっている。

PATRA の鈴木さん

インスタを軸にした

D to C という環境でやっている。

自社ブランドの mellowneon という環境について

去年の1月に初めて1年くらい

今は 10 万人くらいフォロワーがいる

週に 1000 ~ 5000くらい増えている。

フォロワーを集めて、そこから服を売ってコンバージョンに繋げるというビジネスモデル。

丁寧に11つのインスタの機能を使ってやっていっている。

詳しくは本編で。

 

インスタグラマーというセンスを持っている人が

職業でやっていける世界を使いたい。

お題

SNS とは

利用者が個別に分別できて

フォローや DM が可能なサービス。

と、一旦定義する。

ここからパネルディスカッション

ミラティブの事例

twitter との連動が大きいサービス

観察しているユーザが twitter をどのように使っているかという話

特に日本人だと、「リアルの会話でドヤるとちょっとやりすぎなんじゃないか」

というのを中和しているのが SNS の使い方だと思っている。

いきなりサービスを押し付けるというよりも

SNS のラダーに乗っていく、溶け合っていくという文脈が一個あると思う。

PATRA の鈴木さんに、ママリの大湯さんから質問

「どのように深掘って行ったら物が売れるんですか?」

PATRA の鈴木さんから

立ち上げのタイミングでは、全然売れなかった。

最初はインフルエンサーの人が宣伝してくれたので、その人にポイントを与えて、

好きな服を買ってもらって、それがバズって、ってなったのが最初で、

そこで売れる感触を掴んだ。

インフルエンサーが着れば売れるというわけではなくて、

SNS で売れるものの特徴というものがあって、その特徴を抑えるようにしている。

フォローを増やしても売れなければ意味がないので、

そこを意識している。

例えば、「この商品あと2枚で終了です」ということを出すと

すぐに売れたりもする。

 

ここ最近インスタライブも使っていて、

100 件くらいコメントがつく。

ライブだと、直接ユーザーと会話できるので、それには全部答えるようにしている。

最近だと、「私の身長でも大丈夫ですか?」って質問が多いので、

複数の身長の人をライブに出して、安心させている。

また見てくれている人もいるので、

そういう人には、「いつもありがとうございます」と言ったり、

DMがきたら、丁寧に全部返したりしている。

 

まとめると、物の売り方をハックをしているというよりは

丁寧に一つ一つのことをやっているという感触。

それをやっていったら、着実にフォロワーが増えて言ったと思っている。

mirrativ の赤川さんから

「人はどのくらい接点を持てたかで好感触になるかどうかになっているので、そういうのは大事だと思う。」

コミュニケーションの深さも大事だと思う。

DM をちゃんとした文章で返すとかも、

深さと量をしっかり抑えているからよいのだろうなと思った。

ママリの大湯さんから

ライブで接するというのがとても良いんだろうと思っていて、

実際に店舗で店員に接するよりも、

インスタ経由で接しているのが心地よいというのをちゃんと抑えていると思う。

 

最近だと、iPhone があって当たり前の世代の人が増えてきて、

人同士がスクショを共有しまくるというのが当然になっていて

そういう、ネットを使ったコミュニケーションというものがなめらかになっている。

mirrativ の赤川さんから

SNS というのは、承認欲求を満たすツールにもなっている。

対面で話をするときは、人は自分のことを 30% しか話さないが

インターネットだと 80% 話すという研究結果もある。

人間が持っている、ソーシャルな、誰に対して話すという欲求をサポートしているのが SNS

それを意識して SNS を扱うのが大事。

ファンを大切にするための距離感ってありますか?

PATRA の鈴木さんから

mellowneon は一方的な発信というのがメイン。

あとは DM やライブのコメントなど。

一番頻度が高いのでいうと、ライブのコメントが一番大事にしている。

 

ライブを作り込んだものにしているかというと、そうではなくてラフな感じにしている。

その人たちには、何を話すのかを用意しているわけではなくて

等身大のライブ配信を大事にしている。

私たち(運営側)がライブ配信しているんだけど、

ユーザも一緒にライブ配信しているような気持ちになるように気をつけている。

ファンを獲得するにはどうしたらいいんですか?

PATRA の鈴木さんから

一概にはこれが良いとは言えない。

総合力が大事。

可愛いとかそういうのも大事だけど、例えば配送が遅れたらクソと言われたりもする。

強いて言うなら、細かいコミュニケーションが大事で、

DM も一件一件丁寧に返してもらうというのが大事。

ミラティブではどういうファンがつくんですか

mirrativ の赤川さんから

リアクションをしっかりする人が大事だと思っている。

例えば、AKB のライブよりも地下アイドルのほうが

自分に反応してくれて、それが好印象ということがある。

なので、こちらからしっかり反応してあげることが大事だと思う。

逆に 100 人を大事にできない人に 10000 人を大事にできない。

 

僕がいつもいっていることは

一番最初にやることはスケールしないことをやれということ。

例えば11つの返信にちゃんと返すってスケールしたらやれないことだけど

小さいときはそれを一個一個丁寧にやれと思っている。

 

例えば、インスタグラムのマネージャーの方は

インフルエンサーに会いに言っている。

twitter とか facebook ってデータドリブンなことをしていないわけはない

だが、直接会うということも大事にしているのがすごいと思った。

PATRA の鈴木さんから

イベントやライブのスクショをとってくれて、

それを大事にしてくれたりしている。

ということが実際に起きている。

もともと、ライブにコメントをよくしてくれている人に

「どう?」と聞いたら、スタッフの手伝いとかしてくれたりもしている。

スケールしないことをやろうぜという話があったが、その中からどれをやるのかというのはどういう基準でやっていますか?

mirrativ の赤川さんから

そこの拡声器としてテクノロジーを使うのが大事だと思っています。

例えば、コメントをまとめてブログにしてポストするなど。

それを、配信者が自分の声でまとめるとか。

なので、テクノロジーと掛け合わせてもっとよいことができそうかということを考えている。

結局その、道しるべ(実際にどうしたらよいのか)を欲しいという人がここの会場にもいると思う。そういうのはありますか?

mirrativ の赤川さんから

ユーザが、「マジでクソだよね」ということをちゃんと言ってくれるので

それを吸い上げて、PDCA の回転を上げていって、精度を上げていくのが大事。

PATRA の鈴木さんから

結構商品を企画するときとかに

質問機能とかアンケート機能というのを設けている。

そこで、知見をもらったりしている。

例えば、仕入れするタイミングで「こういう商品を仕入れたらみんな買いますか?」

ということを素直に聞いたりする。

そうすることで、ユーザも自分で作っている感が生まれるので良い。

クオリティについてどう考えていますか?

mirrativ の赤川さんから

いままでだと成立しなかったけど、

雑に作っても良い感じになるというツールを使うこと。

例えば SNOW とか、リラティブとか。

 

あとは、 SNS にあるユーザの意見を取り入れるのだが、

例えば、既にやろうとしていた施策が既にあったとしても

「こういう施策やろうと思っているんですが、どうですか?」

ということをユーザに聞くようにしている。

あえて、その後に実際に施策をやることで

ユーザを巻き込んでいる感がある。

PATRA の鈴木さんから

インスタのクオリティって難しいなと思っている。

プロのカメラマンに撮ってもらっても売上が上がんないが、

逆にスマホでとった画像のほうが売れているとかもある。

 

あと、ライブでいうと、作り込んだライブというよりも

本音で喋ってもらったほうが売上が上がるということがある。

なので、よりユーザが暮らしの中で感じることができるようなコンテンツのほうが

クオリティが良いという判断に最近なっている。

Q & A

Q1. ママリでコミュニティサービスにおける部分についてです。

ママリは SNS のサービスじゃなくて、「ママリ」ってハッシュタグをつけるとかそういうのがあるけど

今後どう考えているか?

A1.

ママリの大湯さんから

SNS を使うのにはその特徴を捉えて、どう使うかを大事にしている。

ママリは広告ビジネスなので、想起率を増やしたり

マインドシェアをとる上での手段として使っています。

Q2. twitter に乗っかる形できっかけを作っていったと思うが、

ユーザがコンテンツを投稿するモチベーションをどう設計していますか?またその機能は?

A2.

mirrativ の赤川さんから

Youtuber にならない理由って、

はじめしゃちょうとかヒカキンとかが200マン再生!となっているなかで

いきなりメジャーリーグに入るのはハードル高いみたいな感覚があると思います。

なので草野球からでも始められるよという環境を用意してあげるのが大事だと思う

Q3. 距離感を近づけていくでいうと、逆にこれはやらないみたいな判断があれば教えて欲しい

A3.

mirrativ の赤川さんから

SNS っていきなり熱量があがるとよくないと言われている。

分散させることを意識していく。

人間ってヒエラルキーを作りたがるので、分散させるようにしている。

濃い人が濃いままで楽しめるのであればそれでもよいし。

そうじゃない人も楽しめるようにしたい。

例えば、誰も来ない配信者のところにユーザが集まるようにしていたりする。

なので、古参というものをできるだけ産まないようにしている。

Q4. ミラティブの初期ユーザの獲得はどうしたか?

A4.

mirrativ の赤川さんから

バイユーザ(配信も閲覧もするユーザ)がくることになっているのが重要だと思っている。

サービスをリリースしたときに、サービスのユーザを取りにいくのはよくない。

逆にユーザに見つけてきてもらって、そのユーザがどのようにきたのかを観察するのが大事。

ある種、自分の欲望もありつつ、他の人の欲望も満たせるという状況が大事。

なので、探してきたユーザをちゃんと観察して、それを満たせるようにするのが大事。

感想

  • SNS の特徴はいろいろある。
    • 例えば、ユーザの生の声がききやすかったり、
    • ユーザと運営を繋ぐ役割にもなったり、
    • ユーザに販売意欲を促進させる効果だったり、
    • ユーザ自身がサービスを大きくしてくれたりする。

 

  • SNS の活用術はいろいろある。
    • 例えば、ユーザに認知してもらうことだったり、
    • ユーザに意見を仰ぐことができたり、
  • SNS を活用する時に気をつけたいこと
    • 一方的なやりとりにならないようにする。
    • ユーザを巻き込んだサービス運営をするとよい。
    • 小さな意見や DMM でも、一つ一つを大切にすることが、今後につながる。

 

  • SNS を活用する上で
    • SNS で何ができるんだっけ?自分たちは何がしたいんだっけ?ということを考え  やりたいこととマッチしているかをちゃんと見極めよう。
    • SNS から聞こえる生の声はとても重要なので、そこから PDCA を回していくというやりかたもあり。
    • ユーザの意見が聞きたいときは、素直に「これどう思いますか?」と聞いてみるのもあり。
    • ユーザを巻き込んで、一緒にサービスを作っている感を出すとよい。
    • 親みやすさが大事。作り込みすぎたものよりも、等身大で身近に感じられるような情報のほうが、ユーザの反応もよい。

すごい人を見て見習うことはあっても、自分を卑下するメリットはあまりない

前提

すごい人やできる人を見て、

  • 「あぁ、この人みたいになりたいなぁ」
  • 「この人みたいになるにはどうしたらいいんだろう」
  • 「この人みたいになるために頑張ろう」

と思うことは生活の中でよくあると思います。
が、同時に

  • 「自分ってなんてダメなんだろう」
  • 「自分とあの人は才能が違う」
  • 「自分はあの人に比べるとクソ」

と思ってしまうことがあると思います。

自分の至らない点を確認・分析できることは良いことだと思いますが、
ネガティブにとらえすぎて、あきらめたり、行動できなくなったりするのはよくないので、思考の切り替えをしたほうが良いと思う。という話です。

思考の切り替え

私はすごい人をみて、自分も頑張ろうと思うことはあっても、萎縮してしまうことはあまりなくなりました。
だんだん自然とそうなっていったのですが、改めてどういう思考の切り替えをしていったのかを自己分析してみようと思います。

自己成長感・自己実現感を得ることを覚える

「自分はダメだ」と思う感情よりも、「あのすごい人に近づけている」という自己実現の感情が勝るようになれば、とても楽です。

自分の成長を感じることで
「あの人に近づけている」という充実感・達成感を得られることができます。
その感情を覚えることができたら、「くよくよしてる暇があったら、前に進もう」という考えに少しずつシフトしていくと思います。

前に進むにはどうするかを考える。もとからすごい人なんていない。

すごい人も努力してすごい人になっています。
まだ何もしていない自分とすごい人を比べて落ち込むなんて、そりゃそうだろって思います。
それよりも、この人はどうやってすごくなったんだろう。
自分がいま近くためにすることはなんだろう。
と考えるようになりました。

すごい人になることが、すぐに要求されることは少ない。

すごい人に比べて、今自分が劣っているからといって、
直近で身の回りに不都合が起こることがあるでしょうか?
意外とあまりないと思います。
「この間こんなすごい人がいたよ。だからお前もやれ」なんて言う上司はいないと思います。
すごい人になりたいという気持ちがあるのはとても良いことですが、
すぐになれないからといって、直近で不都合が起こることってあまりないので
そんなに「どうしてもならなきゃ」って思う必要はあまりなかったりもします。
長期的な目線で実力をあげるのはすばらしいと思います。

長期的な思考に切り替える

すごい人も、いろんな努力をしてすごくなりました。
自分は、そのすごい人のすごくなった姿しかみていません。
そうすると「この人は元からすごい人なんだ」と錯覚してしまうことがよくあります。
そうではなくて、すごい人はそれを始めたのが自分よりも早かっただけで
自分も時間をかけて努力すれば、同じようなスキルを身につけられるのではないか、と考えるようにしましょう。

それでもやっぱり、才能のある人はいるとは思う。

社会人になっていろんな人と接していると

  • 少しの情報ですぐに全体を理解できる人
  • ちょっとやっただけで、すぐにマスターしてしまう人

がいると思います。
いわゆる個性だと思います。
個性が違うことを嘆いても、何も起こりません。
その人を参考にすることはいいことでも、個性を比べて変えられないことに嘆いてもしょうがありません。
と、言ってもやっぱり気になってしまいますよね。
そこで思うのですが、個性は完璧ではないと個人的に思っています。
例えば

  • すごく勉強はできるけど、コミュニケーションに至らない点がある人
  • 自分の仕事は早いけど、周りと一緒に仕事をするのが至らない人
  • 仕事熱心だけど、性格が悪い(周りから受け入れられない)人

と、すごくできる面がある一方、同時に至らない点もあります。
(少なくとも、僕が 28 年生きてきて、全てが完璧という人は見たことがないです。)
すごい人の良いところばかりに目が言って、自分が負けている部分にばかり気になってしまいますが、
その人よりも自分が優っていることがきっとあると思います。
それは些細なことでもよいです。

  • 自分は後輩からしたわれやすい
  • 興味のあることはすぐに実行に移せる
  • ていねいに物事を進めるのが得意

など、自分では当たり前と思っていることでも、意外と他人からみたら評価するに値することだったりします。
ありきたりな言葉になってしまいますが、目立たなくても個人はそれぞれその人にとっての才能を必ずもっていると思います。
なので、自分が全てにおいて、相手に対して劣っているなんて考えはやめましょう。

まとめ

劣等感は、自分の伸びしろの裏返しだと思います。
劣等感を感じる分、自分はまだ成長できる部分があるんだとポジティブにとらえましょう。