完全無料で、ゼロからVue.jsを学び倒す！
Vue.jsを、１から無料で学びたい。
みなさま、こんにちは。
本日のテーマは、Vue.js。
というのも。
今プログラミングスクールの講師をしていまして、
その中で新しく「Vue.jsコース」を立ち上げることになりました。
で、そのカリキュラムを作る必要がある、と。
僕自身、Vue.jsは「存在は知ってるけど、ちゃんと触ったことない」存在だったので
これを機に触ってみようかな、と思った次第です。
そして先日、AWSの勉強を、You Tube＋Qiitaで進めている、という記事を載せました。
無料のコンテンツでここまで効率的に学べるのか！！という驚きが大きくて。
「Vue.jsも無料で勉強できないかなー」と、思ったわけですね。
おすすめの動画２選
ということで、
色々と見比べてみた結果、これは効率的に学べる！と思った動画を２つ紹介します。
まずはこの方。
説明がとっても分かりやすくて丁寧です。
動画は全８本で、基本的な構文のみですが、導入にはバッチリと思います。
VueJS入門その30「VueJSとFirestoreでTODOリストを作る(1)」
そして、こちら。
こちらでは、基本的な構文の説明はもちろん、
応用編として、音楽検索アプリやTODOリストの作り方まで、詳細に説明されています。
この動画に沿って同じ操作をしていけば、実際のアプリが完成する、という優れものです。
（解説の方があんまり元気がないのが、気になるところですが。。笑）
どちらも再生回数はそれほど多くないんですが、
コンテンツとしてはめちゃめちゃ優秀だと思います。
初学者にオススメ。
まとめ
今の時代、無料で優れたコンテンツがあるのがありがたいですね。
だからこそ、「コンテンツを選別する能力」はより一層重要になるだろうなーと思います。
Vue.jsを使ったポートフォリオも作成中なので、
完成したらまた紹介しようと思います。
では、
また。
※おまけ 公式ドキュメントのお話
上記のYou Tubeにたどり着く前のお話。
「Vue.js 勉強 無料」で検索して、色々調べてみると
「公式ドキュメントが日本語かつ分かりやすいから、それ見たら大丈夫！」
という声がかなり目立ちました。
なるほど。
ということで、アクセスしてみる。
最初の説明がこんな感じ。
うーん。。。
よく分からん。（笑）
公式ドキュメントって、知らない単語が説明なしにポンポン出てくるから、苦手なんですよね。
というわけで、そういった部分も分かりやすく説明してくれる動画コンテンツは、非常にありがたいですね。
今後も活用していこうと思います。
※ちなみに、動画を見た後だと公式ドキュメントで書いてる内容が分かるようになりました。
動画→公式ドキュメント、の順をオススメします。
それでは、また！
AWSを１から効率的に学ぼう！！ その１-Youtubeでインプット編-
完全に、自分用の備忘録。
仕事でもプライベートでも、AWSを使う必要が出てきまして。
ゼロベースから学んでいく過程を、
備忘録も兼ねて残していこうかなと思います。
勉強方法
よし、AWS勉強するぞー！と意気込んだはいいものの、
何から始めたらいいかよく分からん、ということで
開発仲間オススメの動画を見るところから始めました。
いつから始めるの？Docker、AWS、kubernetes初学者がこっそり1日で先輩に追いつく3つの作戦
この人。
AWSを１から説明する動画を挙げており、
実践としてQiitaで詳細な操作手順も説明しています。
何より、全体を通してとっても分かりやすい。
これにならって、進めていくことにしました。
目標は、「意味を理解しながら、AWSにWordpress環境を構築できること」とします。
まずはこれで基礎を学んで、応用して色んなことやりたいなって感じですね。
さっそくQiitaを見てみたのですが、割と意味不明だったので
- AWS関連の動画を一通り見る
- Qiitaで実践してみる
の手順を踏みます。
私の前提知識
- ネットワークまわりの基礎知識はある（基本情報レベル）
- AWSは触ったことないし、よく分からない（EC2って、聞いたことある！レベル）
こんな感じです。頑張っていきましょう。
動画でのインプット
動画は
- VPC編（６本）
- EC2編（４本）
- IAM編（３本）
の３つに分かれています。（今のところ、書いてて意味不明）
多いなーと思ったものの、１本の動画が５分程度でまとめてあり、かつとても分かりやすい。
スラスラと見ることが出来ました。
で、いろんな知識が出てきたので
備忘録的にブログに残しておこうかな、と。
完全に自分用のメモベースなので、
内容が気になる方は動画を見てみてね。（宣伝）
VPC編
まずはVPC編。
▼VPCとは？
アカウントに紐づく仮想ネットワーク空間。
通常はデフォルトVPC使わずに個別で設定していく
▼AZ（Availability Zone）
リージョン＝国、AZ＝データセンター的なもの。
VPCはAZを跨げるが、リージョンは跨げない。
▼サブネット
大きなネットワークを複数の小さなネットワークに分割管理
→セキュリティレベルを高める！
サブネットはAZを跨げない
サブネットを同じ構成で複数のAZに配置するのが一般的
サブネットの分割単位は/24がおすすめ。
パブリックサブネット：インターネットと直接通信を目的（DMZとも呼ぶ）
プライベートサブネット：内部としか通信しない目的
▼CIDR表記
/16とか。ちゃんと理解してない。
▼ルートテーブルとは？
各サブネットが通信する際に、どこに向けて通信するか？を決めるルールのこと。
最低１つ設定しないといけない。
明示的にルートテーブルを作成して、サブネットに関連付けること。
→インスタンス同士が通信できるようになる
デフォルトゲートウェイとして、IGWが設定されている→パブリックサブネット
されていない→プライベートサブネット、と言える。
▼インターネットと通信するには？
VPCにIGWをアタッチする。
パブリックIP：動的IPアドレス
エラスティックIP：静的IPアドレス
▼IGW（インターネットゲートウェイ）
NAT変換機能
EC2インスタンスはプライベートIPしか認識できない。
IGWでプライベート⇔パブリックを変換する
▼SG（セキュリティグループ）：仮想FW
EC2インスタンス単位で設定
許可ルールを累積していく
▼ネットワークACL
サブネットに出入りする通信の制御を行うFW
サブネット単位で設定
▼セキュリティを保ったまま、インターネット接続するには？
→NAT-GWをパブリックサブネットとして使う。
インスタンス→インターネットの接続は可能、逆は不可。
▼ENI（elastic network interface）
EC2インスタンスやNAT-GWにアタッチして使用。
（NIC：network interface card）
ネットワーク接続のための部品（物理）
Elastic ip をIGWに設定すること。
▼VPCエンドポイント（VPCE）
リージョンサービスとプライベートに接続するためのもの。
ルートテーブルに追加することでアクセス可能となる。
プリフェックスリストID
Gateway型：S3、DynamoDB
Interface型：24種類以上
▼VPCエンドポイントサービス
SaaSサービス等にインターネットを介さずに接続可能
▼ダイレクトコネクト
オンプレ等と接続
企業向けで、使う予定ないので割愛。
▼VPCピアリング
他のVPCと接続するために使用
EC2編
次はEC2編。
▼EC2：仮想サーバーサービス
▼OS=AMI（Amazon Machine Image）
複数のEC2を起動することが可能
色んな種類があるよ
・どのソフトをインストールするかの設定
・AMIを起動できる許可の設定
・block device mapping（どのEBSボリュームを使用するかの設定）
CPU、メモリ→インスタンスタイプ
インスタンスファミリー：スペック構成
SSD→BS（ディスクストレージ）
基本は汎用SSD使う
スナップショット：バックアップとして取得したファイル、S3に保存。
NIC→ENI
キーペア：秘密鍵・公開鍵のペア
EC2にログインするために使用するもの
EC2インスタンスに埋め込まれている自分の情報
Curlコマンドで取得できる
▼ユーザーデータ
▼Cloud-init
クラウド系インスタンスの初期構築を助けるオープンソースアプリ
▼プレイスメントグループ
複数のEC2を論理的にグルーピングすること
複数のコンピュータを繋いで複雑な計算をするイメージ
AZ, リージョンをまたぐことは出来ない
・クラスター
・スプレッド
▼Dedicatedホスト/インスタンス
AWSの物理サーバーのリソースを占有できること
普通はみんなと共用で使っている
IAM編（Identity Access Management）
最後はIAM編。
概要だけ分かればいい人は、ここまででオッケー、みたいに言ってくれたので
細かい内容はそもそも聞いてません。笑
▼デフォルトはルートユーザー
ここからIAMユーザーを作成する
ロールのスイッチも可能（一時的に権限を与える）
▼MFA（多要素認証）
ポリシー：JSON形式のドキュメント
Principal（操作主体）のrequestに対して、権限があるかを突き合わせるドキュメント
まとめと感想
以上、自分用メモでしたー。
ぱっと見、情報量が多いんですが
動画での説明を聞いていると、意外と全部理解出来てる。
素晴らしい動画でした！感謝！
では、この知識をもとに
実際にAWSを触っていきます。
果たして。
AWSマスターになる日は来るのだろうか・・？
それでは、続きをお楽しみに。
オンライン飲み会の面白さと、主催側の苦労。【Zoom, Hangout】
こんなご時世なので。
友達と、オンライン飲み会をしてみました。
これが、割とおもしろい。（笑）
ツールとしては、Hangout と Zoom を使ってみました。
で、感じた利点と問題点。
利点：気軽に出来て、めーっちゃ楽。
１番の利点は、繋ぎたいときにすぐ始められる点ですかね。
２回やってみたんですが、
どちらも「今ひま？オンライン飲み会しよう！」みたいなノリから始まりました。笑
で、フランクに繋いで、グダグダと喋って
好きなタイミングで「じゃあ先に抜けるね〜」みたいなことが出来る。
この辺のフレキシブルさは、めっちゃ良いなーと思います。
あと、話している内容に関するwebページを画面共有したり、画像を送ったり。
zoomであれば、バーチャル背景を使ってみたり。
※こんな感じで、背景を自由に変えられます（笑）
色んな楽しみ方ができるなあーと想います。
課題：無言になったときに困る＆全員が喋れるわけではない
ただ、問題点もあって。
当然ですが、自分から喋り始める人がいないと、途端に無言の時間になります。笑
アナログの飲み会でも同じことは起こると思いますが、
オンラインだと距離が離れてお互いの表情・感情が読みづらい分
無言の時間が際立ってしまうんですよね。
また、同時に発言できるのは原則１人、という問題もあります。
誰かが喋っている間、他の人は聞く側に回らざるをえない。
なので、特定の人が喋りまくると、他の人が介入するタイミングがなくなってしまいます。
結果として、ほとんど発言してない人が出てきてしまったり。
ノープランで開催すると、このあたりの壁にぶち当たるかなーと思います。
今後の改善策を少し。
ただ、オンライン飲み会の需要は間違いなくあって。
いま運営しているバドミントンサークルのメンバーや、
飲み仲間等から、「オンライン飲み会開いて！」という要望が数多く来ています。
外出自粛しているものの、コミュニケーション不足でストレスが溜まっている人は多いみたいですね。
今月何回か主催することになったので、
- 全員が主体的に参加できる
- 全員が発言する機会がある
- むしろ発言できなくても楽しい
ような企画を考えなきゃな、と思っています。
難しい・・・。
そして、主催側からすれば、全然気軽ではない。（笑）
ですが、何らかの場を提供する、ということは
最大限の意図を張り巡らせ、全員が楽しめる場をセッティングする、ということなので。
試行錯誤を繰り返しながら、
「全員楽しいオンライン飲み会」の１つの解を見つけてみようと思います。
試行錯誤の様子は随時ブログにて更新しますので、お楽しみに！（笑）
それでは、また。
「仕事ができる」ってなんだ？ 猿とスマホから考える、ビジネススキルのお話。
どういうこっちゃ？というタイトルから始めていきます。
こんばんは、Gi-noです。
私、フリーランスの仕事とは別に
毎週土曜日に、システムエンジニア育成スクールの講師もしていまして。
受講生としては、
「今後フリーランスのエンジニアとして働きたい社会人」
みたいな方が多いです。
そして、講師という立場上
よくこんな相談をされます。
「仕事が出来る人って、どうやったらなれますか？」
仕事出来ない認定をされたら、即契約を切られてしまうんですね。
フリーランス最高！みたいに言ってる方も多いですが
前提として、とてもシビアな世界なのです。
で、その質問を受けて。
講師としては、当然答えを探すわけです。
私のことを、「仕事できる人」と見て相談してくれてる以上
最大限の答えを提示せねばならん、と。
そして、考えます。
「仕事ができる」って、そもそもどういうことだ・・？
まるで人間のような猿
「仕事ができる」とは？とあれこれ考えている中、
先日見たテレビの内容が、ふと頭をよぎりました。
こちら。
動画すっごく面白いので、ぜひ見てみてください。
日本人男性と猿が、スマホを触りながら
普通に会話しています。
驚きですよね。（笑）
猿が人間そっくり、というか。
あまりにも自然すぎる。
そして、話を戻すと
この驚きに、「仕事ができる」のヒントが隠れているなあと、思ったんですね。
仕事ができる人は、期待値を超えてくる人
「仕事ができる」とは、他者（多くの場合は職場の偉い人）からの評価で。
「仕事できる認定」を獲得した場合に、フリーランスの我々は契約を継続することが出来ます。
では、その偉い人は、どういう時に「こいつは仕事できる！」と思うでしょうか？
ここで、先程の猿の動画と繋がります。
一言で言うと、「期待値を超えてきたとき」に、人は驚き、感動します。
猿がスマホを自然に触るなんて予想もしていなかったから、我々は驚きました。
これ、似たような例はたくさんあって。
赤ちゃんがプログラミングしてる、とか。
女子高生で起業してる、とか。
おばあちゃんがプロゲーマー、とか。
全部、期待値を超えてきています。
これらの主語が「３０代男性」になった途端、驚きは薄れますよね。
あー、そういう人もいるよね、って感じに。
我々は無意識のうちに、期待値と行動を比較して評価を下しています。
これを仕事に置き換えると。
役割を持って職場にいる以上、我々には果たすべき任務があります。
その与えられた役割や業務が「職場からの期待値」であり、
それらを遂行する対価としてお金を受け取ることが出来る、という構図です。
期待値の把握と、それを超え続ける努力が必要
で、結論。
「仕事が出来る人って、どうやったらなれますか？」
の答えは、
「自分の期待値を正確に把握し、それを超え続けること。
もしくは、
超え続ける努力をすること。」
ですね。
シビアな話ですが。
期待値の超え方は、それこそ人によると思います。
仕事のスピードがもの凄く速い、とか。
コミュニケーションが抜群に上手い、とか。
資料のクオリティが高い、とか。
与えられた役割を確実にこなしつつ、
自分の強みを活かしてプラスアルファの仕事をしていくことで、
「仕事のできる人」に、なっていけるのではないかなと。
もちろん、僕自身もまだまだ未熟な社会人の１人なので。
今は「仕事のスピード」「レスポンスの速さ」「円滑なコミュニケーション」で
期待値を超え続ける人間になれるよう、日々努力していきます。
ということで。
また次回の記事で。
コロナウイルスの収束を見極める評価軸とは？？
コロナウイルスが猛威を振るい、
どのニュースをつけても、コロナの情報ばかり耳に入ってきます。
今日は東京で◯人感染！とか、
芸能人の◯◯さんがコロナに！とか、、、、
必要な情報とは分かっていても、不安感は募る一方。
一体、いつ収束するのだろう？と、誰もが思っていることでしょう。
コロナウイルスが拡大してるか？収束してるか？を判断する評価軸として、
面白いニュース記事を見つけたので、シェアします。
この記事の面白い点は、
- 「1週間あたりに確認された新たな感染者数」vs「総感染者数」という評価軸を用いている
- その結果、すべての国が同じ線（指数関数的増加のグラフ）に乗る
という点です。
この線から下に逸れた国が、「コロナが収束した国」という判断が出来ます。
ニュース等で見るのは、「時間軸に対する感染者」のグラフばかりであり、
感染者スケールの異なる他国との比較は出来ません。
その点、この記事の観点はかなり斬新で、かつ納得するものでした。
日本に注目すると、線の若干下にはあるものの、右上に増加していく様子が見られます。
今もなお、拡大傾向にあるということでしょう。
実際のグラフは、下記から参照できます。
こちらで、今後のコロナの動向を追っていくことにします。
はやく収まりますように。。。
※あとがき
この評価軸は、事業成長の度合いを見るときにも応用できそうですね。
例えば、サービスリリースをしたとして
「時系列でのユーザー増加数」ではなく
「累積ユーザー数に対する新規ユーザー数の割合」を見るという考え方です。
爆発的に流行っているサービスや会社の、指数関数的増加傾向を見てみるのも
面白いかなあと思ったり。
余談でした。
では、また。
【読書録】『アジャイルサムライ』に学ぶアジャイル開発 その１-役割分担と自己組織化-
ご無沙汰しております。
ブログの下書きだけが溜まっていき、
全然更新できない日々が続いております。笑
いざ書き出すと、ちゃんと書こう！となって
推敲を重ねていくうちに、疲れてきて
結局断念しちゃうんですよね。。。笑
ということで、
今日は推敲もせずに、ざっくり適当に、勉強内容をまとめて行きます。
今日は、アジャイル開発について。
（開発関連の話は、急に口調が変わります。ご容赦ください。。）
アジャイル開発を知らないとやばい。
きっかけは、仕事でクライアントから言われたこんな一言。
「今回の開発は、ウォーターフォールとアジャイルのMIXみたいな感じでやっていきましょう」
・・・
難しい要求をしてくるなあ。。
まあ、言わんとしてることは分かる。
ウォーターフォールよりはスピード感を持って、
アジャイルよりはしっかりドキュメントに残しながら
みたいなニュアンスだろう。（実際そうっぽかった）
ただ、ここで問題点が。
アジャイル開発に関する知識がほとんどない。
もちろん、経験もない。
なんか細かいサイクルでスプリント回していくやつ、くらいの知識しか持ち合わせていないのだ。
アジャイルを知らないのに、ウォーターフォールとMIXできるわけもない。
ただ、クライアントに「アジャイルやったことないんですよね」なんて
口が裂けても言えない。
クライアントからしたら、高い金を出してプロのPMを雇っているわけで。
その期待には応える必要がある。
ということで、早急にアジャイルを学ぶ必要性が生まれた。
まずは名著から学ぼう、ということで、ある1冊の本を手に取った。
いろいろなところで名前の挙がる本である。
この内容をアウトプットすることで
頭の中を整理し、自分のプロジェクトに落としていくこととしよう。
今回は、その第一弾。
アジャイルプロジェクトの役割分担と、チームの自己組織化について。
アジャイル開発に、役割分担は存在しない
まず最初に、アジャイルなソフトウェア開発プロジェクトでは役割分担がはっきりと分かれていない。これをちゃんと実践しているアジャイルチームに参加すると、小さなベンチャー企業に入ったみたいな感覚をおぼえるはずだ。プロジェクトの成功に寄与することなら何だって協力する。肩書も役割も関係ない。*1
最初の衝撃はここだ。
プロジェクトマネージャーも、デザイナーも、プログラマーも、QAも、
あらゆる役割は「存在しない」としている。
もちろん、チームメンバー１人１人の強みはあるが、
細かく定義された役割は存在しないというのだ。
これの意味するところは、
チームが一丸となって成果を出すことにのみ責任があり、
成果のために、誰でも、何でもするという意識を
チームメンバー全員が持って、ようやく成り立つのがアジャイルチームということだ。
これが理想形だな、と思う一方で
実際の現場との大きな乖離を感じた。
現在私がマネジメントしているプロジェクトでは、
ゴリゴリに役割を決めて体制図を書いているし、
他の人の役割に、あまり介入しないような進め方をしているからだ。
アジャイルチームとして見た時に
そもそも理想像が違ったな、と感じた。
チームメンバーが成果にコミットするチームの作り方について、更に説明していこう。
人に合わせて役割を決め、チームを自己組織化する
自己組織化とは、自らのエゴを押し出しすぎないように気をつけながら、チームで力を合わせるということだ。そのとき、それぞれがチームの一員として（各人のスキルと情熱と資質を発揮しながら）、どう振る舞えば最善の成果をお客さんに届けられるかを考え抜くんだ。*2
チームが自己組織化していることが、理想のアジャイルチームを作る鍵、とのことだ。
では、どうやってチームを自己組織化するか？
そのためには、
役割に人を合わせるのではなく、人に合わせて役割分担を決める
ということが大事らしい。
先の章の話と矛盾するように見えるが、そうではない。
全員が「成果のために何でもやる」という意識を前提に置いた上で
その人が１番活躍できる舞台を用意してあげるのだ。
チームメンバーの１人１人が、
自分の得意な分野・強い領域において
自己責任の下に、最大の成果を生み出す。
確かに、最強のチームだ。
ここでもやはり、自分の現場との大きな差異を感じた。
必要な役割分担に応じて人をアサインしていたからだ。
（ただ、一般的なやり方であることは間違いなく、同じようなことが、多くの現場で起こっているだろう）
このやり方で開発を進める場合、
チームメンバーの各々の強みが活きているか？
全員が主体的に、最大のパフォーマンスを発揮できる状況か？
という問いに関して、ある程度目をつむる必要が出てくる。
最高のチームを作るには。
チームメンバーの能力・スキル・人柄までもを深く知り、
全員が最高の力を発揮できる役割を提供することが不可欠、と解釈した。
決して簡単なことではないが、マネジメントする立場として、理想のチームを作ってみたい、と思った。
まずは、開発メンバーのことをもっと良く知る、というところから始めてみよう。
アジャイルのプラクティスは、まだまだ続く
本日はここまで。
ここまでの内容は、アジャイルサムライという本の、ほんの一部に過ぎない。
全体の15%を読んでいる段階で、個人的に響いた箇所を抜粋して紹介させていただいた。
読み進めていくうちに、同じように書き留めておきたいプラクティスが必ず出てくると思うので
アジャイルサムライシリーズとして、随時更新していくこととしよう。
それでは、また。
メトリクス集計って？ サービス改善のために、見るべき数字を決めよう！
今日はアプリ開発の話でも。
プロフィールにも少し書いたんですが、
いま、前の会社のSE２人と、アプリ開発をしていまして。
目的は「勉強のため」なので、結構シンプルなやつを作っています。
その中での勉強内容を、書いていこうかな、と。
今回の表題は、「メトリクス集計」。
事の発端は、共同開発者のこんな一言。
「メトリクス集計とかやって、サービス改善していきたいね」
ふむ。
・・・
メトリクス集計って、なんだっけ？笑
ということで、今日はメトリクス集計について書いていきます。
※経緯を割と詳細に書いているので、結論が観たい方は「まとめ」に飛んでね。
そもそもメトリクス集計とは？
ということで、もう少し詳しく聞いてみた。
「色んな数字を見える化して、数字を見ながらサービス改善につなげる感じ」
とのこと。
なるほど。
ダウンロード数とか、アプリユーザー数とかのイメージかな？
ここで僕は考える。
「KPIと一緒・・？」
ということで、メトリクスとKPI（Key Performance Indicator）の違いについても調べてみました。
（これは別記事として書きます。いずれ。）
ここでは結論だけ述べると、
メトリクス：サービスに関して取ることができる、ありとあらゆる数字
KPI：メトリクスの内、目標達成に影響する数字
という違い、とのこと。
ちなみにKPIは、KGI（Key Goal Indicator）を元に決めるのが基本らしい。
目標の数字を決めて、それを達成するための数字がKPI、って感じですね。
ただ、今回は勉強のための開発なので、
「サービスを形にし、リリースすること」が目的です。
なので、リリース後の具体的な目標はまったく決めていません。笑
ということで、一旦リリース後の目標は
「たくさんの人に使ってもらうこと」とします。
（ホントは、定量的かつ明確に決めるものなので、
仕事でこんなことやったら、めっちゃ怒られそう）
今回は、目標がゆるふわ〜なため、
- メトリクスをリストアップ
- 目標達成に関係しそうな数字をKPIとする
みたいな流れで考えていきます。
見るべき数字はこれだ！メトリクスとKPI一覧
まずは、メトリクスから。
今回、以下のような仕様のサービスを作っています。
・公式Twitterのツイートに、URLが貼ってある
・ユーザーはツイートを見て、URLからWebサイトにアクセスする
・アクセス先でチャットが可能
（サービス内容はいずれ詳細に書きます）
ということで。
・ツイートから、たくさんの人がアクセスする
・Webサイトをたくさんの人が使う
が叶えば、「たくさんの人に使ってもらうこと」という目標が達成されそうな気がします。
Twitterで取得できる数字は、TwitterAnalyticsというサービスに準拠しました。
このあたりを参考に、取れる数字（メトリクス）をリストアップしてみましょう。
・インプレッション数（＝他ユーザーから見られた数）
・エンゲージメント率（＝ x / インプレッション数）
※ x＝クリック数、リツイート数、返信数、フォロー数、お気に入りの回数
・オーディエンス（見てる人たちの関心・特性など）
こんな感じかな？
で、これらの中から、目標に影響しそうな数字を選んでいく。
・インプレッション数（＝他ユーザーから見られた数）
・エンゲージメント率（＝ x / インプレッション数）
※ x＝クリック数、リツイート数、お気に入りの回数
このへんかなー。
KPI選定については、サービスローンチ後に
実際の数字を見ながら適宜修正していきましょう。
Webサイト
次に、Webサイト。
こちらは、
・Webサイトにたくさんアクセスする
・チャット機能をいっぱい使う
という観点から考えて行きましょう。
Webサイトへのアクセスについては、Google Analyticsを使うことにしましょう。
PV数、UU数、滞在時間、ユーザー特性等が見れる、優れものですねー。
Googleという、巨人の肩の上に乗っかりましょう。
ありがたや。
では、チャット機能について。
チャット機能がいい感じに使われているか？を判断するための数字を取りたいですね。
ここは完全にアイデアベースですが、
メトリクスとして、以下のものを考えました。
・チャットのやり取り数
・チャット開始〜終了までの時間
・チャット間隔（→どんな使われ方をしてるのか）
・よく使われてる時間帯（アクセスされてる時間ではなく、チャット機能が使われてる時間）
こんなもんかな？
そのままKPIになりそうな気がします。
共同開発者の考えも参考に、適宜追加していきましょう。
まとめ：メトリクス一覧と今後の動き
ということで、まとめ。
メトリクス一覧はこちら。
①Twitter側
・インプレッション数（＝他ユーザーから見られた数）
・エンゲージメント率（＝ x / インプレッション数）
※ x＝クリック数、リツイート数、返信数、フォロー数、お気に入りの回数
・オーディエンス（見てる人たちの関心・特性など）
②Webサイト側
・チャットのやり取り数
・チャット開始〜終了までの時間
・チャット間隔（→どんな使われ方をしてるのか）
・よく使われてる時間帯（アクセスされてる時間ではなく、チャット機能が使われてる時間）
（あと、Google Analyticsの情報全部）
まずはこんなところ。
色んな意見を参考にブラッシュアップしていきましょう。
今後のやることは、ざっとこんな感じですかね。
- KPI選定：サービス開始してからかなあ。
- 見せ方を考える：BIツールとか参考にする感じ？
- 分析手法を考える：まずは目標数値を明確に決めて、相関とか取っていく感じかね
ってことで。
一旦、メトリクス集計は完了。
※あとがき
さくっと書くつもりが、約2,500文字。
書きすぎたなー。笑
ただ、思考のプロセスって需要があるんじゃないか？みたいな考えから
できるだけ詳細に書くようにしています。
（このへんの話も、いずれブログで書きたいな。
「思考のプロセス」の価値とは？みたいな。）
では、また次回。
