電車遅延を 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 年生きてきて、全てが完璧という人は見たことがないです。)
すごい人の良いところばかりに目が言って、自分が負けている部分にばかり気になってしまいますが、
その人よりも自分が優っていることがきっとあると思います。
それは些細なことでもよいです。

  • 自分は後輩からしたわれやすい
  • 興味のあることはすぐに実行に移せる
  • ていねいに物事を進めるのが得意

など、自分では当たり前と思っていることでも、意外と他人からみたら評価するに値することだったりします。
ありきたりな言葉になってしまいますが、目立たなくても個人はそれぞれその人にとっての才能を必ずもっていると思います。
なので、自分が全てにおいて、相手に対して劣っているなんて考えはやめましょう。

まとめ

劣等感は、自分の伸びしろの裏返しだと思います。
劣等感を感じる分、自分はまだ成長できる部分があるんだとポジティブにとらえましょう。

エンジニア用語を恋愛に置き換えてみた

最近アラサーになり、周囲の人でも

恋愛の話や結婚の話がチラホラ出てくるようになりました。

エンジニア友達と話をしていると、

何かをエンジニア用語で例えることが多く、面白いなと思ったので

関連表を作ってみました。

環境に関すること

dev 環境 彼氏 / 彼女がいるカップルの環境
staging 環境 同棲している環境
production 環境 結婚している環境
local 環境 妄想 / 片思い / 二次元嫁 / アイドル
close 別れること
sandbox お試しの付き合い
チーム 家族 / カップル

動作に関すること

deploy / release

出産 / 婚約届けの提出など

障害対応 子供の夜泣き / 相手からの深刻な急な呼び出し
お気持ち表明 告白 / 別れ話
ペアプロ 一緒に問題解決
リファクタリング 男磨き / 女磨き

その他

案件がある / ない 彼氏彼女になる可能性のある人がいる/いない
キャッシュ 前の相手をひきづっている
障害 喧嘩
プロジェクト 結婚式 / サプライズバースデイ
タスク デート / 結婚式の準備など
MTG 家族会議

 

他にも何かあったり、こっちのほうがしっくりくるっていうのがあれば

教えてください。

随時 update していきます。