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

概要

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

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

 

そうではなくて、

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

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

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

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

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

内容

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

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

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

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

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

私は違うと思っていて、

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

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

 

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

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

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

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

 

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

 

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

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

 

少し話は変わりますが、

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

 

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

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

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

 

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

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

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

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

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

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

 

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

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

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

 

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

 

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 していきます。

【目標設定の技術を勉強する会 #1】に行ってきました

目標設定の技術を勉強する会 #1

https://engineers.connpass.com/event/113403/

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

 

仕事が長引いてしまい、4つ目の LT から参加しました。

 

2018年目標を達成できなかった私が今年こそ達成するためにしていること

発表者:花井宏行さん

 

目標について、障害が起きたときの

プランを立てておくことが大事。

例えば、減量を目標にしていて、

「お菓子を我慢する」だけではなく、

「代わりにガムを噛むとか歯磨きをする」

などの、お菓子を我慢できない場合の代替プランを考えておく。

これを、ヘミングウェイ方式という。

振り返りをする

前進していることの感覚をつかむ。

どこでつまづいているのかを観測できる。

長期的な目標だと日々の進捗がわかりづらいので

目標に幅を持たせる。

減量を目標にしている場合、例えば、

減量は -7 ~ -13 kg など

まとめ

  • マンダラチャートをつかって、目標ができていない理由の分析をしよう。
  • 目標の建て方はヘミングウェイ方式
  • 見積もり通りに実行するために、あらかじめ時間を抑えて、カレンダーに登録しておくなどしよう。

海外移住を実現するためのこれまでとこれから

発表者:スコーンさん

自己紹介

日英通訳志望から、海外移住のためにエンジニアにキャリアチェンジ。現在エンジニア2年目。

 

今日話すこと

ゴールを決めて、そこからマイルストーンとアクションに落とし込んでいくということ

話さないこと

目標設定のフレームワーク

 

今回のゴールは

永住権を get すること

 

マイルストーンは

  1. エンジニアになる
  2. 現地就職する
  3. 数年働いて永住権ゲット

 

マイルストーン 1 の「エンジニアになる」を達成するために

3つの action を定めた。

  • progate をやってみる
  • スクールで勉強する
  • エンジニアとして就職

マイルストーン 2 の「現地就職する」ということを達成するために

3つの action を定めた。

  • 3年実務経験を積む
    現地では3年以上の経験が求められている
  • 開発スキルと英語を伸ばす
    pramp というサービスを使っている。
    → 英語面接する人が勉強したりしている。
    プルリクのレビューを英語でやったりしている。
    1日に10分は触れるようにしている。
    action のコツは、細く、長く
    1日のやることは小さくても、トータルでみて大きなことに繋げる。
  • 現地に行って就職活動

 

総じて言えることが、逆算で action を明確にしたほうが良いということ。

また、action はより具体的なもののほうがよい。(例えば progate をやる、など)

そしてブレイクダウンした目標は遠いものよりも、近いもののほうがよい。(日々の成長を実感できるから。)


目標設定とその方向性

発表者:小松計之さん

 

コンフォートゾーンというものがある。

  • コンフォートゾーンとは
    自分が心地よい、リラックスした状態
    何かに縛られていない。
  • ストレッチゾーンとは
    少し背伸びした緊張状態
  • パニックゾーン
    慌てふためいて、何をしてよいか分からなくなる。

 

パニックゾーンに落ち入ったら

一度コンフォートゾーンに戻りましょう。

 

これを踏まえて目標設定するには

  • 少しハードルが高いが、自分で手が出せる
    → ゴールが果てしなくならないように

    • ゴールを見失わないようにしましょう。
    • 自分のペースで、他人と競争しない。
      他人と比べてしまうと、ペースが乱れてしまう。
  • 漠然とせずに、具体的にどうするのか
    → 資格であれば、参考書や教材

    • 分からなければ知ってる人に聞く。
      できればメンターをつけましょう。
    • 具体化しにくければ、箇条書きにしてからあとから肉付け。
      そのほうが、思っていたところと、実際に客観的にみたときに自分がどうしたいのかということを見直すきっかけになる。
  • いつまでにやるのか。
    → 期限を決める。

    • 余裕持った時間配分を
    • 仕事しながらとか他のことしながらとかあるので、自分のペースを乱さないために。
    • 期限内にできなくても自分を責めない。
    • できなくても、新たに再チャレンジすることが大事。

まとめ

  • コンフォートゾーン
    自分のモチベーションのありかたを確認しよう。
  • 少し背伸びした目標設定
    果てしなくならないように
  • 目標に対して具体化
    細かくしていくことが大事。
  • 期限を決める

成果をつくる目標管理

発表者:坂井健治さん

 

仕事で目標が達成できないとか、段階が踏めない人向けの発表です。

目標が適切か?

SMART の法則

https://boxil.jp/beyond/a5166/

特に大事なのは

  • 計量可能かどうか?(Measurable
  • 関連性があるか?(Relevant
    → その目標が何と関連しているか?

なぜ計量可能が大事なのか?

人の意見からは目標達成できたか分からない。

なぜなら、人によって意見が異なるから。

だから、指標を用意してゴールの数値化をしましょう。

なぜRelevant が大事なのか?

何のためにその目標が大事なの?という、共感しない人が出てくるから。

何のために大事で、ということをみんなが共感できるようにしよう。

結果目標の注意点

自分だけでコントロールできない

行動目標のメリット

自分でコントロールできる。

決めてしまえば、あとはやるだけ。という状態にできる。

【サポーターズCoLab勉強会】エンジニア向け – わかりやすい「デザイン」の話 -に行ってきました

【サポーターズCoLab勉強会】エンジニア向けわかりやすい「デザイン」の話

https://supporterzcolab.com/event/674/

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

資料

https://xd.adobe.com/view/8be53b4a-7e8a-4e1d-681d-f4af91c29dbf-fdd4/?hints=off

 

以下、話を聞きながらのレポート

 

デザイン思考という言葉がある。

デザインに必要な考え方と手法を利用して、ビジネス上の問題点を解決する方法。

デザインとは層表的な装飾ではなく、課題解決の手段である。

デザイン思考のプロセスとしては、

  1. 観察/共感
  2. 問題定義
  3. アイデア創出
  4. プロトタイピング
  5. 検証

がある。

活用事例

wii

[観察]

ゲーム機があることで、家族が分裂してしまう現象があった。

それを解決したい。

[問題定義]

家族の関係がよくなるようなゲームにしたい。

[アイディア創出]

誰でも使えるリモコンのようなデザインにした。

[プロトタイピング]

1000回以上も微修正を繰り返す。

 

 

近年、デザインの優先度はとても高い。

なぜなら、開発の導入がこれまでと比べて容易になっいるため、

似たようなものが乱立しているから。

デザインは、上流工程での意思決定がとても大事。

デザインを学ぶメリット

  • エンジニアは特に、デザイナーと両方の気持ちがわかるようになる。
  • ピンチヒッターになれる。
    エンジニアだけのチームの中で、デザイナーとしてやれることもある。
  • 最悪頑張れば自分一人でいろいろできるようになれる。(フルスクラッチでサービス作るとか。)

国内外のデザインのトレンド

slackなども刷新している。

実用的なデザインスキルを身につける最速の方法

  • 0 1でサービスを作る。
  • デザイン本を読む
    Non Designers Design Book
    https://www.amazon.co.jp/dp/B01LW1BC2L/
    これが非デザイナーの人でも読みやすい。
  • デザインガイドラインを読む。
    • ヒューマンデザインとか。
    • マテリアルデザインとか。

これに逸脱しなければ、ほとんど良い感じになる。

ここをみると、だいぶ良い input になる。

  • adobe を契約する。
    これをしないと始まらない。

Q & A

Q1.

デザインの人ってあんまりフリーソフト使わない?例えば gimp とか

A1.

大学の頃は gimp とかも使っていたが、実務になると adobe じゃないと使えなかったりする。

 

Q2.
adobe
製品の中で、これ学べば今後有益だよっていうのはありますか?

A2.

Xd が良い。
スライド作って公開とかもできる。
プロトタイプ作りができたりもする。

aws コマンドで UnicodeDecodeError: ‘ascii’ codec can’t decode エラーが出る

aws コマンドで UnicodeDecodeError: ‘ascii’ codec can’t decode

というエラーが出るようになったので、そのときの対応と少しハマったこと。

 

流れ

  1. aws コマンドで該当のエラーが出る
  2. python のバージョンをあげるために brew pyenv をインストールしようとするが入らない
  3. pyenv python のバージョンをあげる
  4. python のバージョンをあげたが、PATH が通ってない
  5. 無事に aws コマンドでエラーがなく実行できる

aws コマンドで該当のエラーが出る

どうやら、python のバージョンを 3 系にあげるとなおるらしいです。

python のバージョンをあげるために brew pyenv をインストールしようとするが入らない

brew でインストールしようとしたのですが、

`require’: cannot load such file

のエラーが出ます。

いろいろ調べて対象法を試して見ましたが、ダメだったので、

Homebrew をアンインストールして、再度 Homebrew をインストールしたらいけました。

pyenv python のバージョンをあげる

pyenv install 3.6.4

とコマンドを打つことでバージョンを設定できます。

python のバージョンをあげたが、PATH が通ってない

aws コマンドを実行してみましたが、

実行時にまだ python 2 系を参照しているようでした。

export PATH=~/.local/bin:$PATH

とすることで、PATH が通ります。

.bash_profile 等に記載しておけばいいと思います。

無事に aws コマンドでエラーがなく実行できる

めでたく、 phtyon 3 系でコマンドが実行されており、

エラーもなくなりました。