（部下にとって耳の痛い）フィードバックする際の流れとしては、SBI情報(シチュエーション=状況、ビヘイビア=行動、インパクト=結果)を事実ベースでしっかりと伝えること。そして問題行動を部下に腹落とし(understood)してもらい、現状と理想のギャップを認識してもらいます。最後に原因探求と行動計画づくりを部下が一緒になって行います。

こうした一連の流れを感情的にならずに行う上で必要なメンタリティの保ち方についてまで言及されてあり、とても勉強になりました。

あと個人的には具体的なフィードバックのシチュエーション別の事例集が参考になりました。

HARD THINGS

HARD THINGS　答えがない難問と困難にきみはどう立ち向かうか

作者: ベンホロウィッツ
出版社/メーカー: 日経BP社
発売日: 2015/04/17
メディア: Kindle版
この商品を含むブログ (6件) を見る

著者のベン・ホロウィッツは「アンドリーセン・ホロウィッツ」というシリコンバレーの著名VCを立ち上げた投資家であり、それ以前はベンチャー起業家として会社を上場させた経歴を持ちます。

一見1on1とは関係なさそうな本ですが、著者は1on1をとても重要視しており、組織の悪い兆候を察知したり情報を透明化する上で1on1はマネージャーの義務であると述べています。

特に以下の具体的な質問リストはとても参考になりました。

- われわれがやり方を改善するとしたらどんな点をどうすればよいと思う？
- われわれのその上で指揮で最大の問題は何だと思う？またその理由は？
- この職場で働く上で一番不愉快な点は？
- この会社で一番頑張って貢献しているのは誰だと思う？誰を一番尊敬する？
- きみが私だとしたら、どんな改革をしたい？
- われわれの製品で一番気に入らない点は？
- われわれがチャンスを逃しているとしたら、それはどんな点だろう？
- われわれが本来やっていなければならないのに、やっていないのはどんなことだろう？
- この会社で働くのは楽しい？

本書の内容としては著者が経験したベンチャー経営におけるリアルなHARD THINGSの失敗経験が述べられています。1on1関係なく特にスタートアップで働く人にはぜひ読んでほしい本です。

HIGH OUTPUT MANAGEMENT

作者: アンドリュー・S・グローブ
出版社/メーカー: 日経BP社
発売日: 2017/01/11
メディア: Kindle版
この商品を含むブログを見る

1980年代に書かれた本で、2017年に復刻され再出版されました。著者はインテル元CEOのアンディ・グローブです。

上記HARD THINGSの著書ベン・ホロウィッツが「世界最高の経営書だ」と評するほどの本で、いろんな経営者、マネージャーに読みつがれています。

マネージャーの仕事は部下や影響下の組織体のアウトプットを最大化することであるという考え方のHOWが詰まった本です。そのための方法の1つとして本書でも1on1の重要性が説かれています。

コミュニケーションが遅れると意思決定の遅れにつながり、そして意思決定が遅れると事業の進捗を遅らせたり、トラブルの兆候を見逃す原因になります。それを防ぐのが1on1であるとして、どのように進めたらいいかについて具体的に書かれています。

個人的には1on1以外にも考え方として参考になる部分が多くマネージャー全員におすすめしたい本です。

エンジニアリング組織論への招待

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

作者: 広木大地
出版社/メーカー: 技術評論社
発売日: 2018/02/22
メディア: Kindle版
この商品を含むブログを見る

第二章でメンタリングについて取り上げられています。目次としてはこんな感じ。

Chapter 2　メンタリングの技術
- 2-1　メンタリングで相手の思考をリファクタリング
- 2-2　傾聴・可視化・リフレーミング
- 2-3　心理的安全性の作り方
- 2-4　内心でなく行動に注目する

本書でのメンタリングの定義としては以下になります。

対話を通じてメンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し成長させていく手法

「相手の思考をリファクタリング」という考え方で対話する手法について説明されています。チームメンバーとして心理的安全性を担保しつつ最大のパフォーマンスを出してもらうために、相手に適切な思考を促す理論と方法論が具体的に書かれています。

この本の特徴としてはとても理論的なことです。悪くいうとアカデミックなとっつきづらさがありますが、丁寧に読めば納得感を持って理解しながら読

エンジニアのためのマネジメントキャリアパス

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
出版社/メーカー: オライリージャパン
発売日: 2018/09/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

エンジニアの管理職のための本です。

階層別に（テックリード、技術部長、CTO、経営層）部下のマネジメントの仕方や話すべき内容についての本で、1on1の重要性、やり方についても随所で触れられています。

本書については先日書いたこちらの記事でも紹介しています。

katsuki.hatenablog.com

まとめ

マネージャーのみなさんはぜひ読んでみていただけると参考になると思います。

2018-12-23

「エンジニアのためのマネジメントキャリアパス」は管理職以外にも読んでほしい良書だった

キャリア書評 Tips

以前から気になっていた「エンジニアのためのマネジメントキャリアパス―テックリードからCTOまでマネジメントスキル向上ガイド」という本を読みました。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
出版社/メーカー: オライリージャパン
発売日: 2018/09/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。

上記の書籍紹介にあるとおり大まかな内容としてはエンジニアの管理職に特化したキャリア本です。各役職においての職責、ぶつかる課題、うまく立ち回るためのコツなどが職務別に紹介されてありとても参考になりました。

ちなみに章立てとしてはこんな感じ。

1章マネジメントの基本
2章メンタリング
3章テックリード
4章人の管理
5章チームの管理
6章複数チームの管理
7章複数の管理者の管理
8章経営幹部
9章文化の構築

この記事では特に参考になった箇所にフォーカスして内容を紹介したいと思います。（参考になった箇所が多かったため分量が多めです）

テックリードについて

［テックリードとは］（ソフトウェアの）開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと。

テックリードには誰より経験豊富でいいコードが書けるエンジニアを採用すべきという誤解があるが、それだけではだめ。実際には以下の役割をこなせる必要がある。

テックリードの役割

システムアーキテクトとビジネスアナリストとしての役割
- プロジェクトを完遂しデリバリするには基幹システムのどこを改変すべきか、どの機能を構築すべきかを見極めること
- 対象システム全体の構造の把握と、ソフトウェア設計スキルが必要
プロジェクトプランナーとしての役割
- プロジェクト管理もテックリードにとって重要なスキルのひとつ
- 作業をデリバリ可能な単位に大まかに分割する
- チームメンバーの中でもとくに事情に通じている人からアドバイスをもらい優先順位の検討を行う
ソフトウェア開発者兼チームリーダーとしての役割
- 自らプログラミング作業をこなしながらメンバーに課題を伝えたり作業を任せたりする任務を果たす
- プロジェクトのリーダー役を果たしチーム全体の向上を図る。

優秀なテックリードとは

アーキテクチャを把握している
- 製品のコアロジック、データの流れをしっかり理解している
チームプレイの大切さを心得ている
- 難しい箇所、退屈な、面倒な修正作業の検討を買って出る
技術的な意思決定を主導する
- 自分が決断すること、より専門知識を持つメンバーに判断を委ねること、チーム全体で決断すべきことを見極める
コミュニケーションの達人である
- チームの生産性のためにコミュニケーションに労力をつぎ込む

人の管理について

人的管理における基本職務

直属の部下との関係構築
定期的な1on1
キャリアアップや作業の進捗状況、改善領域、功績の報奨などに関するフィードバック
各メンバーの研鑽を要する領域の見極めとその領域の能力の強化

短期間で良好な関係を築くために

信頼構築のために質問をする
- 褒められるとき人前でもいいか、1on1のほうがいいか
- 重要なフィードバックの伝え方は書面がいいか、形式張らない口頭の方がいいか
- あなたが不機嫌な時、悩んだりしている時は旗から見てどんな感じか。私が事前に知っておくべき事柄があるなら教えておいてほしいです。
- 耐え難いと思う上司の振る舞いはありますか
- キャリアアップの明確な目標がありますか
- このチームに来てからなにか私に言っておきたいことができましたか。良いことでも悪いことでも
部下に今後1ヶ月/2ヶ月/3ヶ月の計画を立てさせる
- 明確な目標が立てられるほど部署やコードへの理解が進んでいる
- 目標設定を支援する
新人研修用のドキュメントを更新させる
- これによりチームに対する理解を促す

チームの管理

「直属の部下がひとりか2人いる管理者」から「チーム全体の責任を負う管理者」は職位が1段階上がるだけだが職務内容がガラリと変わる。

技術系管理者はチームの技術的な意思決定を主導しなければならない
- 自らの技術力を維持するのも管理者の責任
チームの意思決定を主導するコツ
- 「データ重視」の文化を根付かせる
- 顧客に対する共感を深める
- 将来を見据える
- チームの意思決定やプロジェクトの結果を振り返る
- プロセスと日程を振り返る

複数チームの管理

例えば技術部長
直属のテックリードが複数人いて、彼らが各自のチーム作業を進めることを支援しているような状況
技術部長はコードを書く作業に必ずしも毎日携わらなくてよい
プロダクションコードを書かなくても現場の仕事に精通する方法
- プログラミングの腕が鈍るのを予防する
- コードレビューを（少なくとも「副レビュアー」として引き受ける）
時間管理
- 何はともあれ重要な仕事に照準を合わせる
- 重要と緊急の違いを見極める

技術部長に求めるスキル

純粋な管理スキル以外のものも必要
とくにチーム全体の「健全性」を見逃さない目を養う必要がある
チームの生産性や満足度の予測に役立つ質問
- 会社から求められている自分の職務をきちんと把握しているか
- 自分の職務を遂行する上で必要な機器やツールをもっているか
- 毎日最高の仕事ができる機会を得られているか

複数管理者の管理

2階層以上離れた部下から情報を得るコツ

スキップレベルミーティング
- 階層を飛び越えた部下とのミーティングを「スキップレベルミーティング」という。
- 目的は「各チームの健全度や焦点の絞り方を把握すること」
- 短時間の1on1を四半期に一回など行う
スキップレベルミーティングで聞く質問例
- 今担当しているプロジェクトで最高（最悪）だと思う点は？
- 自分のチームで最近とくにすばらしい働きをしているのは誰ですか
- 何か君の直属の上司に関するフィードバックがありますか。うまく行っている事でも行っていない事でも構いません。
- 今担当している製品にどんな改良ができると思いますか。
- 我々が見落としているのではないかと思えるチャンスがあったら教えてください。
- うちの部の業務活動は全体的に見てどうだと思いますか。改善、増強、削減できるところがあれば教えてください。
- 我が社の経営戦略で、ピンと来ないところはありませんか。
- 今あなたが持ち味を出し切れていない理由は何でしょうか。
- この会社で働くことに満足していますか。
- この会社で働くことに対する満足度を上げるため我々にできることは何でしょうか。

新任管理者の管理

新任管理者のさまざまな兆候に注意し手助けする
- 大変な職責を前にしてチームの管理を怠る
- 前の職位の責任をチームの他のメンバーに託せずに現職の仕事と兼務してしまっている
- 「権力」を手に入れたと思い込み厳しくチームをマイクロマネジメントし、すべて自分で決める

ベテラン管理者の管理

本人がチームの文化に合う人間化どうかを見極める
- 管理者はサブカルチャーを生み出す存在のため、文化的な相性の点で妥協は禁物
自分の職責のうちどれをベテラン管理者に移譲するか検討する。新任管理者との違いは、マネジメントの基本的なことよりも上位の、戦略策定に大きく関わるものになる

経営幹部

技術系幹部を指す。CTO, VPoE, 技術本部長, 技術部門の統括者 etc

経営幹部の職務

第一の仕事はリーダーを務めること
- どの方向へ進むべきかを決め、会社に助言をする
必要な素養
- 情報が十分得られていない状況でも難しい決断を下し、結果に対しても責任を負う
- 自社の事業の現況を把握する能力と将来のさまざまな可能性を想定する能力。組織の可能性に的確に対処してチャンスを確実に捉えられるよう何ヶ月も何年も前から計画する

経営幹部の4つの仕事

情報の収集・共有
- 会議に出席し、メールを読み、書き、部下と1on1を行い、さまざまな意見に耳を傾ける。大量の情報をすばやく集め、そこから不可欠な情報を選り分け、それを第三者にも理解可能な方法で共有する
注意喚起
- 命令ではなく質問をすることで相手に責任事項を想起させる
意思決定
- 相容れない見解や不完全な情報も踏まえて針路を決める。
ロールモデル
- 会社の価値観を内外に知らせ、率先して植樹を遂行し、気の進まない場面でもチームに最良の模範を示す

技術系経営幹部の一般的な役割

研究開発（R＆D）
- 実際の開発を行う部門とは別。特に最先端の技術の開発に注力する企業。
技術戦略・ビジョナリー
- 技術戦略と製品開発を結びつける、。大抵は製品部門の統括者も兼ねる。R&D担当幹部と異なるのは、研究面での可能性には焦点を当てず、業界や技術の動向に基づいて意思決定を導く点
組織化
- 組織構造はもちろん、チームの要員に関しても計画立案の責任を負い、プロジェクトの担当者を配置する。執行と兼務するパターンが多い。
執行
- 各部署での職務執行に関する責任。ロードマップの連携、作業の計画立案、広範な事業の調整。
技術部門の対外的な「顔」
- カンファレンスなどで講演を行う顔など。
社内の技術インフラとその運用
- 社内の技術インフラとその運用の全責任を担う。
事業化
- 何よりも事業そのものに焦点を絞る。自社の属する業界に精通し、自社の技術以外の主要部門も高い視点から把握する。社内での開発ニーズと事業拡大のニーズのバランスをとり、高い視点から優先度付をする。

VPoEとは

技術系管理者のランクの最上位に当たる。般に、人員、プロジェクト、チーム、部課の事情に精通したベテラン中のベテラン管理者。

「できる技術担当VP」は、チームの日々の運営に関する責任者として、作業工程も各工程の詳細もしっかり把握しています。進行中の複数の取り組みを同時並行で追跡、把握でき、順調に進捗するよう計らうことができます。有能な技術担当VPは現場の詳細に通じ、下位レベルの作業完遂を促す影響力をもっています。こうした職責をCTOが担っている企業もありますが、CTOと技術担当VPの2つのポストを設けている会社では、CTOが「より広範な戦略」と「社内での技術部門の位置付け」に、そして技術担当VPが「アイデアの実現」に、それぞれ焦点を絞っているのが普通です。

企業が成長し規模が大きくなるとVPの役割も組織志向から事業戦略志向へと変わっていく。各部署のミニCTOとして戦略と組織管理の仕事を天秤にかけつつ遂行していく。企業の成長に伴い、組織管理の仕事は部課長レベルの部下に任せていく。

CTOとは

CTOではないもの

CTOは技術系の役職ではない。すなわちエンジニアがそのまま昇進を続けていきつく先の最終目標ではない。
コーディングやアーキテクチャ、技術系デザインを愛する人が一般的に楽しめる職種でもない
必ずしも社内でもっとも優秀なエンジニアとは限らない

どんな存在か

「CTOとは、その会社が現在の成長段階で必要としている戦略的技術系幹部」
CTOの職務は「長期的視点に立って考えをめぐらし、事業の未来とそれを可能にする要素とを計画する作業を支援する仕事」
一方、「幹部」という表現を加えることによって表したかった職務は「（上記の）『戦略的な思考』の成果を実現、運用可能にする作業を支援する（そのために問題を細分化し、その対策を部下に実行させる）仕事」です。

CTOの職務

まず何よりもCTOは会社のためを思い、事業を理解し、技術というレンズを通して事業戦略を建てられるようでなければならない。
第一に経営幹部たるべきで、エンジニアであることは二の次。
会社にとって最大の技術的な好機とリスクの在り処を把握し、それをプラスに利用することに焦点を絞らなくてはならない。
- もしCTOが人材の募集、採用、維持、手続きといった人的管理に焦点を当てているのであれば現時点でその会社の技術チームにとってはそれが最重要事項。
会社にとっての事業的な難問を把握すること
できるCTOは管理面でも多大な責任と影響力をもつ。事業戦略の決定において自分の影響力を保持するためには、会社や事業に大きな影響を及ぼす問題の解決に人員を割り当てるようにしなければならない
管理の権限をもたないCTOが何かを成し遂げたければ、自身で動いて組織に影響力を及ぼすしか手がない。重要だとCTO自身が見なす領域に、管理者たちが人員と時間を割り振ってくれなければ、そのCTOは無力も同然。管理の責任を放棄したりすれば、事業戦略に関してそのCTOがこれまでに発揮し得たもっとも重要な影響力まで投げ出すことになり、残されたものは組織側の善意と自身の2つの手だけ、と言っても過言ではない。
最後に、晴れてCTOとなり、意欲に燃えている人たちにあえてアドバイスをするとすれば、それは「何よりも事業戦略に関わる仕事を最優先すべし」である

文化の構築

文化の重要性

文化とは「あるコミュニティで共有されている暗黙のルール」
組織文化の意識的主導はリーダーの役目
文化の重要性
- 集団で意思決定する際、文化的価値感がチームの結束を固める「接着剤」の役割を果たす
企業文化を形作るのは創業時の社員
- 差別と文化
  - 「MIT出身のエンジニア」というくくりは文化ではない
  - 「技術革新、勤勉、知性、科学的なプロセス、データに価値を見出す人々」は文化

文化を育てるコツ

1. 担当部署の文化を定義すること
2. 会社がすでに特定の価値観を打ち出しているなら、それをチームに当てはめてみる
3. チーム独自の価値観を加えたり言い換えたりしてもいい
1. 会社やチームの価値観をプラスの形で体現している社員を褒める
2. これにより文化が強化される
3. コアバリューにまつわるストーリーを全社会議や部署ミーティングで共有する
4. 勤務評価も有用
  - チームメンバーと会社との文化的相性を評価する
  - チームメンバーがチームのコアバリューを体現する言動をしたときにそのこととその経緯を勤務評価に明記し面談でも指摘する
1. コアバリューを採用面接のプロセスに組み込む
2. エアポートテストはあまり参考にしない方がいい
  - 友達選びではない
  - 友達にはなれなくても仕事で最高の関係を築くことはできる
  - 差別色が濃くなる
3. 「明確」を期することが大切。具体的に検討する
  - 自分のチームが重視しているのは何か
  - それはどういった点で勤務評価の対象者や面接の応募者の価値観が合致しているのか
4. 会社の価値観、チームの価値観を書き出してみる
  - 応募者評価や勤務評価の際にそのリストを活用する

キャリアラダーをつくるコツ

チームのメンバーにも応援を仰ぐ
- 自分一人で取り組まず、チームの上級管理者やシニアエンジニアの協力を仰ぐ
- たとえばエキスパート職に要求されるITスキルについては現職のエキスパートエンジニアに検討してもらう
実例を集める
- 資料や雛形、他社事例
詳細な説明と要約の2種類の資料を併用する
- 簡略なスプレッドシートで各ランクの特徴が比較検討できるもの
- それぞれのランクを文章で詳しく説明したバージョン

まとめ

開発組織で働くエンジニアであれば誰にとっても参考になる良書だと思います。特にまだ管理職からは遠いエンジニアにとっても、キャリアパスを描く上でとても参考になるのでぜひ読んでほしいと思いました。

技術系管理職の課題として仕事に追われて技術のキャッチアップが追いつかないというものはよくあると思いますが、そのあたりのコツが多く書かれていた点も非常に参考になりました。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
出版社/メーカー: オライリージャパン
発売日: 2018/09/26
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

2018-12-16

Vue.jsとFirebaseでリアルタイムチャットアプリを実装した

Vue.js フロントエンド書評

フロントエンドのフレームワークについてキャッチアップするために、こちらの本を読みました。

React、Angular、Vue.js、React Nativeを使って学ぶはじめてのフロントエンド開発

作者: 原一浩,taisa,小松大輔,永井孝,池内孝啓,新井正貴,橋本安司,日野洋一郎
出版社/メーカー: 技術評論社
発売日: 2018/05/09
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

どんな本か？

本書では、フロントエンドの最新動向（特にフレームワークについて）をサンプルアプリケーションを開発しながら学べるようになっています。

JavaScriptのフロントエンドフレームワークが今のように複雑かつ大規模になっていった背景について歴史的経緯含めてわかりやすく解説してあるため、フロントエンドについての全体像を整理しつつキャッチアップしたい人にとてもおすすめな内容になっています。

Firebaseも触れる

サンプルアプリケーションではバックエンドAPIをFirebaseで割と手軽に構築できるようになっています。

Vue.jsとFirebaseで作るリアルタイムチャットアプリケーション

概要

Slackっぽいチャットアプリケーションを作ります。

f:id:katsuki1207:20181216183221p:plain

本書ではVue, React, Angularそれぞれのフレームワークで全く同じサンプルコードが用意されていますが、今回はVueで実装してみました。

npmでvueをインストールするところから始まり、VueCLIによる環境構築、単一ファイルコンポーネントの作成、Vuexによる状態管理とVueの基本的な機能をさらいながら実装を進める手順となっています。

プロジェクトの作成

Vueをインストールし、プロジェクトを作成します。

$ npm i vue
...

$ vue init webpack vueChat
? Project name(vueChat) vueChat
? Project description(A Vue.js project) A sample chat of Vue.js
? Author
? Vue build (Use arrow keys)
> Runtime + Compiler: recommended for most users
? Install vue-router? (Y/n) Y
? Install vue-router? (Y/n) Y
? Use ESLint to lint your code? (Y/n) n
? Set up unit tests (Y/n) n
? SetUp e2e tests with Nightwatch? (Y/n) n
> Yes, use NPM

Installing project depeneencies …

$ cd vueChat
$ npm run dev

これで http://localhost:8080 にブラウザでアクセスできるようになります。

f:id:katsuki1207:20181216183118p:plain

プロジェクトのディレクトリ構成

main.jsがアプリケーションの起点でありエントリポイントとなります。

vueChat
├── build
├── config
├── index.html
├── node_modules
├── package-lock.json
├── package.json
├── src
│   └── App.vue
│   └── assets
│   └── components
│         └── Chat
│               └── chat.css
│               └── chat.js
│               └── chat.pug
│               └── index.vue
│   └── main.js
│   └── router
├── static

単一ファイルコンポーネント

単一のファイルにテンプレート、スタイル、ロジックをまとめることで保守性を担保します。今回はそれぞれのブロックごとにファイルを切り出し、index.vueでまとめています。

index.vue

<template lang="pug" src="./chat.pug" /> 
<script src="./chat.js" /> 
<style scoped src="./chat.css" />

chat.js

import { mapGetters, mapActions } from 'vuex'
import {
  GET_CHANNELS,
  // SET_MESSAGE
} from '../../store/mutation-types'
import MessageList from '../MessageList'

export default {
  name: 'chat',
  mounted(){
    this.GET_CHANNELS()
    this.GET_MESSAGES(this.$route.params.cname)
  },
  components: {
    'message-list': MessageList
  },
  computed: {
    ...mapGetters([
      'messages',
      'channels'
    ]),
  },
  beforeRouteUpdate(to, from, next) {
    this.GET_MESSAGES(to.params.cname)
    next()
  },
  methods: {
    ...mapActions([
      // SET_MESSAGE,
      GET_CHANNELS,
      "GET_MESSAGES",
      "POST_MESSAGES"
    ]),
    send_message(){
      // this.SET_MESSAGE(this.message)
      this.POST_MESSAGES({"cname": this.$route.params.cname, "message": this.message})
      this.message = ""
    }
  },
  data() {
    return {
      message: ""
    }
  }
}

chat.pug

el-container
  el-aside
    ul
      li(v-for="(channel) in channels")
        router-link(:to="{name: 'channel', params: { cname: channel }}") {{ channel }}
  el-container
    el-header {{ $route.params.cname  }}
    el-main
      message-list(:messages='messages')
    el-footer
      el-input(type="text" v-model="message")
      el-button("@click"="send_message") SEND

chat.css

ul {
  list-style-type: none;
  padding: 0;
}

.el-header {
  border-bottom:1px solid black;
}

.el-header, .el-footer {
  background-color: #ffffff;
  color: #333;
  text-align: center;
  line-height: 60px;
}

.el-aside {
  background-color: #4a3a4a;
  text-align: center;
  width: 100px!important;
}

.el-aside a {
  color: #ffffff;
  text-decoration:none;
  font-weight: bold;
}

.el-main {
  background-color: #ffffff;
  color: #333;
  text-align: center;
}

.el-container{
  height: 100vh;
}

.el-input {
  width: 50%;
}

誤植に注意

注意点としては誤植により思うように動かない箇所が何箇所かありましたが注意深く読み直せば自力で解消できるレベルのものでした。

公式の正誤表が用意されているようなので、ハマったらチェックしてみるといいかもしれません。

誤植訂正情報 · okachijs/jsframeworkbook Wiki · GitHub

まとめ

同じアプリケーションを複数のフレームワークで実装したときのどのような違いが生じるかという比較ができてとても参考になりました。

2018-12-02

Vuexの概念についての解説メモ

Vue.js フロントエンド vueschool

vueschoolのVuexの解説がわかりやすかったので、学んだ内容についての日本語でのメモを公開します。

vueschool.io

Vuex概要

VuexはFluxアーキテクチャを採用したVue.jsの状態管理のためのライブラリ。Reduxからも影響を受けている。
Vuexの中心にある概念としてストアがある。ストアはアプリケーションの状態(state)を保持する役割を担い、状態管理に関する機能が盛り込まれておりVuexの根幹となっている。
Vuexはアプリケーション内で1つのストアのみが存在するという前提、すなわちストアが信頼できる唯一の情報源であることを前提に実装されている。

Vuexを導入する理由

Vue.jsだけだと困難なこと

アプリケーションに共通の状態を共有する複数のコンポーネントが存在する場合、例えば以下のような場合に状態管理が破綻しやすくなる。
- 1 複数のビューが同じ状態に依存する
- 2 異なるビューからのアクションで同じ状態を変更する
1はコンポーネント同士のpropsの値の受け渡しが大変。2は複数の状態のコピーを変更、同期することになりメンテナンスが困難になりがち。
上記の問題に対し、Vuexではコンポーネントが共有する状態を抽出し、グローバルシングルトンとして管理するためどのコンポーネントにあっても状態にアクセスし、アクションをトリガーできる。
また、状態管理の概念が定義され、設計のルールが敷かれているが故に保守性を担保することができる。
ただし、あまり規模の大きくないアプリケーションにVuexを導入してしまうと、ただ単に冗長なコードの記述を求められることなってしまうので注意が必要。

ストアについて

ストアと単純なグローバルオブジェクトの違い

ストアの状態を直接変更することはできない。明示的にmutationsをコミットすることによってのみストアの状態を変更する。これによりすべての状態変更に追跡可能な記録を残すことが保証される。

ストアのプロパティ

Vuexのストアは構成要素として5つの概念を持つ
state, mutations, getters, actions, modules

「Vuex とは何か？ | Vuex」より引用

state
- ストアで管理する状態そのもの。コンポーネントでいうところのdata。
- gettersから参照され、更新はmutationsから行う
actions
- 非同期処理や外部apiをコールするためのもの
- 複雑になることはあるが、stateの更新はしない
- 最終的にmutationsにデータをコミットする関数
mutations
- stateを更新するための関数をもつ
- かならずシンプルに保つ
- mutationsはデータ取得や複雑な計算はしない代わりにstateを更新する。
- 第一引数はstate, それ以降の引数はpayload
getters
- state内の状態をもとに算出した値を返す関数
- stateのデータを加工して表示したりする
modules
- 上記4つのストア構成要素を分割したもの。
- アプリケーションの肥大化に伴い大きくなるストアに対し、見通しをよく保つためにモジュールに分割する。
- modulesは自身を含め、上記のoptionsをすべて内包できる。

参考情報

vueschool.io vuex.vuejs.org

2018-11-24

VSCodeのJavaScript用拡張機能Quokkaが便利

フロントエンド VSCode

VSCode用の拡張機能「Quokka」が便利だったので紹介します。JavaScriptのコーディングの際にエラーになる箇所を実行前に評価してくれてリアルタイムに表示してくれる拡張機能です。

使い方

エディタ左側のExtensionsにて「Quokka」と検索し、インストールします。 f:id:katsuki1207:20181124180722p:plain

その後、実行したいファイルを開き、 Cmd + Shift + p > 「Quokka.js: Start on Current File」を選択すればOKです。

何が便利なのか

リアルタイムにコードの内容を実行、評価してくれる

コーディングと同時にコードの内容を実行評価してくれて、エラーがある場合はその内容を当該コードの右側に表示してくれます。

また、変数の値をconsole.logなどを使うことなく表示してくれます。

f:id:katsuki1207:20181124180900g:plain

コードカバレッジがわかる

左側の色のついた四角は実行されたコードのカバレッジになります。テスト実行されたコードとそうでないコードがわかるようになっています。

f:id:katsuki1207:20181124181124g:plain

灰色: 未実行
緑色: テスト済で問題なし
黄色: 部分的にテスト済
赤色: エラー

まとめ

大変便利なので、フロントエンドのコードを書く際は利用することをおすすめします。

2018-11-18

UdemyのVue.js入門講座でQiitaAPIを用いた記事検索アプリなどを実装した

技術 Vue.js Udemy

Vue.jsのキャッチアップをするためにUdemyの講座「Vue JS入門決定版！jQueryを使わないWeb開発 – 導入からアプリケーション開発まで体系的に動画で学ぶ」を受講しました。計7時間となかなかのボリュームですが、Vue.jsの基礎を丁寧に解説しながら教えてくれるため初学者にはおすすめの内容でした。

https://www.udemy.com/learn-vuejs/

講座内容

Vue.jsの概要から基礎的な機能までを網羅的に教えてくれます。特に特徴である双方向データバインディングのディレクティブ機能についてはみっちり紹介されています。

Vue.jsの基本的な使い方
テンプレート構文
算出プロパティ
監視プロパティ（ウォッチャ）
クラスとスタイルのバインディング
条件付きレンダリング
イベントハンドリング
フォーム入力バインディング
コンポーネント
トランジション

また、応用編として以下のような簡易的なSPAサンプルアプリケーションを作る内容も含まれており、実践的な内容も学べる講座となっています。

TODO管理アプリ
API連携によるBitcoin価格表示アプリ
QiitaAPIを用いた記事検索アプリ

QiitaAPIを用いた記事検索アプリ

こんなのを作りました。フォームにキーワードを入れると該当のQiita記事をリアルタイム検索して一覧してくれます。

f:id:katsuki1207:20181118183701g:plain

フォーム含むテンプレートはこんな感じ

    <div id="app">
      <p><input type="text" v-model="keyword"></p>
      <p>{{ message }}</p>
      <ul>
        <li v-for="item in items">
          <a v-bind:href="item.url" target="_blank">{{ item.title }}</a> likes: {{ item.likes_count }}
        </li>
      </ul>
    </div>

Vueインスタンスはこんな感じ

var app = new Vue({
    el: '#app',
    data: {
      items: null,
      keyword: '',
      message: ''
    },
    watch: {
      keyword: function(newKeyword, oldKeyword) {
        this.message = 'Waiting for you to stop typing...'
        this.debouncedGetAnswer()
      }
    },
    created: function() {
      this.debouncedGetAnswer = _.debounce(this.getAnswer, 1000)
    },
    methods: {
      getAnswer: function() {
        if(this.keyword == '') {
          this.items = null
          this.message = ''
          return
        }
        this.message = 'Loading...'
        var vm = this
        var params = { page: 1, per_page: 20, query: this.keyword }
        axios.get('https://qiita.com/api/v2/items', { params })
          .then(function(response){
            vm.items = response.data
          })
          .catch(function(error) {
            vm.message = 'Error!' + error
          })
          .finally(function() {
            vm.message = ''
          })
        }
      }
})

監視プロパティ watch を使ってフォームに入力されたキーワードを監視し、入力したら自動的にキーワード検索をする。ただし無駄なAPIリクエストを避けるためdebounceメソッドを使って入力完了後1秒待ってから実行。

    watch: {
      keyword: function(newKeyword, oldKeyword) {
        this.message = 'Waiting for you to stop typing...'
        this.debouncedGetAnswer()
      }
    },
    created: function() {
      this.debouncedGetAnswer = _.debounce(this.getAnswer, 1000)
    },

debounceに呼ばれるAPIリクエスト用のメソッドを定義。APIリクエストにはaxiosを利用。

    methods: {
      getAnswer: function() {
        if(this.keyword == '') {
          this.items = null
          this.message = ''
          return
        }
        this.message = 'Loading...'
        var vm = this
        var params = { page: 1, per_page: 20, query: this.keyword }
        axios.get('https://qiita.com/api/v2/items', { params })
          .then(function(response){
            vm.items = response.data
          })
          .catch(function(error) {
            vm.message = 'Error!' + error
          })
          .finally(function() {
            vm.message = ''
          })
        }
      }

どんな人におすすめか

タイトル通り、フロントはjQueryくらいしか経験ないけどこれからVue.jsを勉強したい人にぴったりだと思います。逆にいえば、基本的にES5で書かれていることもあり既にES6でバリバリコード書いている人はやりづらく感じそうだなと思いました。

まとめ

Udemyの「Vue JS入門決定版！jQueryを使わないWeb開発 – 導入からアプリケーション開発まで体系的に動画で学ぶ」を受講した
まだ学んだことなくてこれからVue.jsを学びたい人におすすめ

2018-11-11

音声入力がブログ記事作成の最速の方法かもしれない

Tips ブログ

いかに効率的にブログを書くかという方法を考えているのですが、最近うまくいってる方法として音声入力があります。

ちなみにMac＆iPhoneユーザー向けの方法となります。

音声入力でブログの下書きをつくる手順

手順は以下です。

Macのメモ帳を開き、タイピングで目次だけ書く
iPhoneのメモ帳を開き、目次ごとに内容を思いつくままに喋る
Macで文章を修正する

1. Macのメモ帳を開き、タイピングで目次だけ書く

最初は音声入力ではなくテキストで目次を書きます。これにはいきなり文章を書き始めるのではなく先に記事の構成を整理するいう意図があります。思考が整理されきってない状態で音声入力から入ると散漫な内容になり結局整理するのに時間がかかるためです。

2. iPhoneのメモ帳を開き、目次ごとに内容を思いつくままに喋る

iPhoneのメモ帳で上記のメモを開き、目次ごとに内容を音声入力していきます。

初めて体験する人はその速さに驚く事かと思います。普段タイピングの速さに思考速度が慣れているので、音声入力だと入力速度が早すぎて頭の回転が追いつかないため、慣れないうちは入力が途中で止まりがちです。しかし、何度もやっているうちに徐々にスムーズに入力できるようになっていきます。

これのポイントはiPhoneとMacがリアルタイム同期されるため、iPhoneに喋った内容がそのままテキストとしてMacのメモ帳に現れることです。そのため喋りながらMac側で内容をカット＆ペーストして順番を入替えたり、細かい構成をつくることが可能です。

ちなみにMacに対して直接音声入力も試みましたが、うまく音声を拾ってくれずに諦めました。そのためiPhoneを使っています。

3. Macで文章を修正する

頭の中にあることをあらかた喋って文章化したら、Macで記事としての体面を整えます。

以上が音声入力での記事作成手順となります。

記事の内容により向き不向きがある

この方法は大変すばやく記事作成ができますが、記事の内容によって向き不向きがあります。がっつりコードを貼り付けるような技術系の記事や、イベントレポートみたいな手書きのメモがそのまま原稿になるような記事にはむいてないです。

どちらかというと以下の記事のように自分の頭の中の考えを吐き出す系の内容が向いています。

katsuki.hatenablog.com

デメリットは時間と場所が限られること

また、この方法の最大のデメリットは人がいるオープンな場所でできない事です。

そのため夜自宅でとかの作業になります。

しかし早い

音声入力のスピードは体感的にタイピングの数倍早いです。

まとめ

ということで、文章を書く機会が多い人にはおすすめです。

2018-11-03

「Vue Fes Japan 2018」で最新のVue.js動向を学んできた

Vue.js カンファレンスフロントエンド

f:id:katsuki1207:20181103185801j:plain

Vue.jsの公式カンファレンス、「Vue Fes Japan 2018」に参加してきました。

今期から公私共にフロントエンドの技術動向から目をそむけずキャッチアップしていく方針にしたので参加しましたが、大変勉強になりました。

キーノートセッション

docs.google.com

セッション概要
- Vue.js作者EvanYou氏によるVue3.0のアップデート内容について
Vue 3.0はメモリ使用量が減り初期化が高速に
Vue.js3の新コアのランタイムはgzipで10KB以下
Tree shakingに対応
カスタムレンダラAPI
リアクティビティAPI
TSXが使えるように
- TypeScriptで書きやすくなる
experimental) HooksAPI
- mixinのだめなところをhooksでなんとかする
- 詳しくはReactのDan氏のプレゼンを参照のこと
experimental) TimeSlicing
- Reactの新機能「Time Slicing」と「Suspense」をFacebookが紹介。非同期レンダリングを活用しUXをサクサクに向上－ Publickey
- レンダリングに字kながかかる処理、通常固まる。TimeSlicingを使えば固まらない
- 同じ処理が連続したらその前の処理をスキップして高速化できる感じ。

Vue2.xからVue3にかけてかなりパフォーマンス向上していて凄く期待できそう。特にTimeSlicingはUX的観点からもインパクトの大きく、これから導入検討するならVue3から入れたいと思った。

事前知識不足で理解が追いつかない部分がいくつかあったので予習しておくべきだったと少し公開。

以下はイベントとは直接関係ない記事ですが、参考までに貼っておきます。 qiita.com

WebComponentsとVue.jsのこれから

セッション概要
- Vue.js と Web Components の関係を整理し、両者がこれからどのように関わっていくべきかについて
WebComponentsとは
- カプセル化されたコンポーネントの再利用を可能にするブラウザのAPI群のこと。現在仕様策定が進んでいる。
- 参考
  - developer.mozilla.org
WebComponentsの技術
- CustomElements
- Shadow Dom
  - DOMのカプセル化を実現するための仕様
  - グローバルのCSSやJSはShadowDOMに影響しない
- HTML Template
  - もう使われない感じ
  - 要素を使用しHTMLドキュメントでHTMLの雛形を扱うための仕様
- ES Modules
  - これを使ってWebComponentsをインポートする
  - HTML Imports
    - ES Modulesの仕様が安定しブラウザ実装が出揃ったため非推奨になった。Chromeからも削除される予定
- HTML Modules
  - HTMLをJSの中に直接Importできるようにする仕様
  - まだGitHubのIssueで議論されている段階
どうやってVue.jsでWebComponentsを作るか
- VueCLI3 Build Targets
  - Vue CLI 3でbuildするときに —target wc というオプションをつけると、Vue.jsのコンポーネントをWebComponentsに変換してビルドされる
  - Vueコンポーネントをラップしてカスタム要素として登録する
WebComponentsをなぜ利用するか
- 1 . UIの使い回しが容易
  - フレームワークを途中で変えてもUIに影響がない
- 2 . Fully Scoped
  - 大きいプロジェクトでCSSの依存関係がわからないような場合に、グローバルなCSSに影響されない実装がしやすい
  - Shadow DOMを使えばよい
- 3 . Micro Frontends
  - フロントエンドを独立した機能の集合体という考え方
デメリット
- 属性値にString型しか渡せない
- 外部から渡されるイベントのハンドリングが難しい
- Dom要素の取り回しが面倒
- CSSの設計を大幅に見直す必要がある
フレームワークの問題
- いつメンテナンスが止まっていつ実装が止まるかわからない
- Vue.jsに依存し続けるのは危険
- 大きいサービスだと数百コンポーネントあるのが普通
- それ、FWを移行するときにめちゃくちゃな負債になる
- WebComponentsであれば、Web標準なため使い続けられる
Vue.jsとWebComponentsの関わり合い
- Vue.jsはアプリケーションをつくるもの、WebComponentsはUIのためのもの
- 上流のデータ構造の管理やデータバインディングはVue.jsが担って、WebComponentsはその末端として入ってくるようなイメージが濃厚
- WebComponentsはHTML要素をカプセル化して可視化するものであって、アプリケーションを作るためのものではない。
まとめ
- WebComponentsはもう使えるけど課題も多い。
- UIをWebComponentsに任せることで負債を減らすことができる
おすすめのインプット元
- W3Cドキュメント
- よくわかるWeb Components
  - 作者: 泉水翔吾
  - 発売日: 2018/10/07
  - メディア: Kindle版
  - この商品を含むブログを見る

FWに依存しない標準化された技術を使おうという考えはとても共感。特定の技術にロックインされるリスクは特にトレンドの盛衰が激しいフロントエンド技術こそ意識すべきな気がする。

Vue Designer: デザインと実装の統合

セッション概要
- デザインと実装を統合させたツール、VueDesignerの話
  - https://github.com/ktsn/vue-designer
デザイナーと開発者でそれぞれの業務が複雑化しだんだんと役割分担されてきた
役割分担により生じる問題
- デザインファイルと実装でファイルが違う
- ちょっとした変更に対して煩雑な管理が必要になる
  - デザインデータから実装して、デザインするまでもない機能追加の時にデザインデータと乖離が起きて、さらにデザインが必要な機能追加があったときに死ぬ
既存プロダクト
- vuegg
  - プロトタイピング
  - https://github.com/vuegg
- Framer X
  - https://framer.com/
ほしいツール
- SFCが実装かつデザイン
- 長期開発、運用に使える
- 動的にデザインできる
Chrome の DevTool 上で style いじってそれをコピペでエディタに戻すみたいなことがやる必要なくしたい
目標
- まずは開発者が便利に使えるツールに
- 将来的にはデザイナーも使えるツールに

エンジニア視点で見ると便利そうなツールなのと、完成すればVue.jsの学習にも使えそうだと思いました。

noteをNuxt.jsで再構築した話

移行のモチベーション
- 開発開始時はAngular.jsを選択
  - UIが複雑なため2-way bindingが魅力的
  - サーバーサイドはAPI専念
  - エンジニアの採用目的
- 課題
  - 初期表示速度の遅さ
  - Angular.js１系はSSRをサポートしていない
  - Railsの上に乗ったフロントエンド
表示速度は正義
- 日経やdev.to
経営視点でのフルリニューアル
技術要件の洗い出し
- SSRサポートあり
- 学習/運用コスト
  - デザイナーへの配慮
  - がちのフロントエンジニアじゃなくてもメンテナブル
  - コミュニティの活発さ
Vue.jsを採用した理由
- 実行速度と開発効率の両立
  - SSRのサポート
- 学習コストの低さ
  - templateがHTMLで書ける
- ドキュメントの充実度
  - 公式ドキュメント見ればだいたい解決
- コミュニティの活発度
  - 情報量が多い
- Vue.jsのエキスパートがコンサルに入ってくれた
Nuxt.js採用の理由
- 規約が手に入る
  - SSRが簡単になる
- モダンな環境が手に入る
  - Vue.jsのエコシステムをビルトイン
移行手順
- ページごとにパスベースでロードバランサーにより振り分け
苦労ポイント
- 並行して現行版（Angular）はメンテしている
Lighthouseでのパフォーマンス評価
AtomicDesign
- 参考
  - https://medium.com/@t_sugawara/vue-js-%E3%81%8B%E3%82%89%E3%81%BF%E3%81%9F-atomicdesign-e90517842801
インフラ
- LambdaでNuxt.jsを動かしている
  - 構成管理やデプロイを担う
まとめ
- パスベースで小さく移行するのが有効
- SSRの導入はすごく簡単でおすすめ

1年間単体テストを書き続けた現場から送るVueComponentのテスト

セッション概要
- Vueで楽にComponentのテストを書けるように現場でやっていること
ペパボでは半分以上のサービスでVue.jsを使っている
テストを書いてない人の声
- UIは変更が発生しやすい
何をテストするか
- 外部からみた振る舞いをテストする
Componentでいうと
- Trigger
  - Lifecycle, Props, VuexState, UserInteraction
- Output
  - HTML, CSS, Event, VuexAction
mount vs shallowmount
- 基本的にmount
- 設計の可動域を確保するため
Props/Vuex Stateのテスト
- 主に見た目に関わる箇所
- 単純なassertになりがちだけどツラミがたまる
  - 表示が変わったらテストも直す必要
  - ざっくりしすぎ
- いい感じにやるには？
  - Snapshot Testing
  - Jestの機能
  - componentのDOM（Snapshot）を比較
- CSSもいい感じにテストするには
  - Visual Testing
  - Snapshot Testingの画像版
  - 画像の差分検出ツールがあらたに必要
  - さいきょうのVisual Testingの方法
    - StorybookとREG-Suit
User Interactionのテスト
- 重要なFormだけでもやっておくといい
- それ以外は難易度高いので諦めも肝心
  - ややこしいテストはしないという割り切り
- User Interaction後のスクショをとってVisualTestingはすごい便利
結論 -Visual Test（HTML/CSSのテスト）は最高
- 副次効果としてレビューの負荷が軽減される。でかい。

フロントエンドのテスト方法はちょうど知りたかったテーマなので非常に参考になった。StorybookとReg-Suitの組み合わせは最強に便利そうなので試してみたい。

まとめ

Vue.jsだけでなく、フロントエンドまわりで知らなかった技術の話を沢山聞けて収穫の多い一日でした。フロントエンドFWとして既にかなり盛り上がってるVue.jsですが、今後ますます盛り上がっていきそうな予感です。

2018-10-28

サブスクリプションサービス運営者必読「優良顧客を逃さない方法」を読んだ

最近グロースハック系の本をいろいろ読んでいるのですが、その中でもかなりの当たりだった「優良顧客を逃さない方法」紹介します。

売上の８割を占める優良顧客を逃さない方法――利益を伸ばすリテンションマーケティング入門

作者: 大坂祐希枝
出版社/メーカー: ダイヤモンド社
発売日: 2018/08/09
メディア: Kindle版
この商品を含むブログを見る

著者はWOWOWで解約防止のために新設された部署の部長として任命された当事者です。

契約数の減少に苦しんでいたWOWOWがどのようにして解約数を減らし業績を回復させたかというリテンション施策が著者の経験をベースにかかれています。当事者だからこそ書ける具体的な施策内容が沢山盛り込まれた良書でした。

新規顧客獲得コストは既存顧客維持の5倍かかる

「1:5の法則」といってマーケティングの分野では一般的に知られているそうですが、新規顧客獲得コストは既存顧客維持の5倍かかるそうです。そのため同じコストをかけるのであれば新規顧客獲得よりも既存顧客維持（リテンション）に力を注いだ方が得策です。

マーケティングといえば一般的に顧客獲得のイメージが大きいと思いますが、本書ではリテンション施策をしっかり行うことこそ顧客満足度を高め、長期的な売上向上に貢献する方法だと説いています。

顧客数が伸びなくなったらしてはいけないこと

本書では、「顧客数が伸びなくなったらしてはいけない５つのこと」として以下が紹介されていました。

割引や無料などの「安い」を売り物にする
「今なら◯◯」とタイミングを強調
プレゼントで目を引こうとする
代理店やフランチャイズ任せにする
自社の商品やサービスの価値を忘れる

ここは、サブスクリプションサービスを運営する人間としてドキッとしたところでした。特に顧客獲得数などのKPIを追いかけている場合、効果が遅れて現れる本質的な商品価値の向上施策は計画に組み込みづらく、即効性の高い割引キャンペーンやプレゼントなどの施策に走りやすくなってしまいます。

しかし、当然ながら安さが理由で加入した顧客は値下げ期間が終了すると解約してしまいます。安さ訴求は価値を理解した顧客の背中を押すために利用するためのものという本書の内容はとてもしっくりきました。

顧客データを活用しリテンションを高める

本書のリテンション施策の中でも特に印象に残っているのは顧客データを使った仮説検証です。

400万件の大量データを集約し、顧客を加入動機や継続年数などでスコアリングすることで62のグループに分けます。それぞれのグループに合わせたトークスクリプトを作成するなど解約抑止施策を行うのです。

これはどんなサービスでも再現性があって効果のありそうな施策だと思いました。本書ではカスタマーセンターが顧客と電話する際のトークスクリプトという形で施策に落とし込んでいましたが、顧客との接点がブラウザであるWebサービスであればUIに反映することで施策を実現できます。

上記の施策により、WOWOWは解約電話の引き止め成功率が20ポイントも向上したとのことでした。

まとめ

ユーザーに寄り添い顧客満足度を高めることの大事さを、具体的な事例とともに理解させてくれる良書でした。特にうちのようなサブスクリプションモデルのSaaSビジネスに携わっている人は必読の書だと思います。

売上の８割を占める優良顧客を逃さない方法――利益を伸ばすリテンションマーケティング入門

作者: 大坂祐希枝
出版社/メーカー: ダイヤモンド社
発売日: 2018/08/09
メディア: Kindle版
この商品を含むブログを見る

2018-10-21

戦略階層にエンジニアの役職と読むべき本を当てはめてみる

キャリア勉強法技術

前回の記事の続きです。 katsuki.hatenablog.com

上記事の内容を一言で表すとエンジニアの成長戦略として自分の階層を把握した上で学習内容を選択することが大事 というものです。

当記事では、戦略階層ごとにエンジニアの職位をプロットし、各階層で具体的に求められる責任範囲と、学習すべき書籍について整理してみました。

戦略の階層	役職	責任範囲	書籍
世界観	創業者	ビジョン, ミッション, コアバリューの策定どのような会社にしたいかどのような世界をつくりたいか	ザ・ビジョン進むべき道は見えているか
政策	取締役	会社全体の舵取り、方向性、カルチャーづくり長期戦略、市場の策定	ビジョナリー・カンパニー ― 時代を超える生存の原則その他経営戦略の本etc
大戦略	CTO, VPoE, プロダクトマネージャー	サービス全体の技術基盤, アーキテクチャー選定エンジニア組織構築, 採用、カルチャーづくり長期的なプロダクトロードマップ	マイクロサービスアーキテクチャエンタープライズアプリケーションアーキテクチャパターン (Object Oriented SELECTION) 組織パターン (Object Oriented SELECTION) なぜ人と組織は変われないのか ― ハーバード流自己変革の理論と実践 Inspired: 顧客の心を捉える製品の創り方プロダクトマネジャーの教科書伽藍とバザールハッカーと画家コンピュータ時代の創造者たち
軍事戦略	開発部長, 事業部長	部署の舵取り、リソース管理、部門予算管理複数のプロジェクトの統括エンジニアの職場環境づくり	ピープルウエア第3版その他事業戦略、予算管理の本
作戦	マネージャー, テックリード, アーキテクト	4〜8人位の中規模プロジェクトのPL 設計に責任を持つチームの生産性プロジェクト横断のアーキテクチャ選定 DevOps スクラムマスター, プロダクトオーナー人材評価	新1分間マネジャー――部下を成長させる３つの秘訣ヤフーの1on1―――部下を成長させるコミュニケーションの技法エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド Team Geek ―Googleのギークたちはいかにしてチームを作るのか The DevOps ハンドブック理論・原則・実践のすべてエッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
戦術	チームリーダー, シニアエンジニア	2〜3人の小規模プロジェクトのPL 機能設計に責任を持つソースコードレビュー新人教育	あなたのチームは、機能してますか？チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ増補改訂版Java言語で学ぶデザインパターン入門 Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
技術	エンジニア	自分の書いたソースコードに責任を持つ	リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 新装版達人プログラマー職人から名匠への道スーパーエンジニアへの道―技術リーダーシップの人間学

便宜上階層に当てはめる形で役職を入れてみましたが、ここまで細かく階層化されている組織は大企業くらいだと思います。スタートアップのエンジニア組織であれば、CTO, テックリード, エンジニアの3〜4階層くらいが一般的ではないでしょうか。

戦略階層の上位は3W下位は1H

会社経営における各階層における責任範囲を整理するなかで、下位がHow（どうやるか？）なのに対して上位はより抽象度の高いWhy, Where, Whatの問いに相当することに気づきました。

世界観はWhy（なぜやるのか？）
- 創業者の想い、目的。このレベルになると突き詰めると個人の価値観に突き当たる。
政策はWhere（どこへいくのか？）
- 世界観を実現するためにどの市場にいくか、会社の文化をどうするか。
大戦略はWhat（何をやるのか？）
- 事業として何をするのか
軍事戦略以下はHow（どうやるのか？）

エンジニアのキャリアパスとしての最上位

エンジニアのキャリアパスとしての最上位は政策レベルの取締役CTOになります。このレベルになると経営者として会社全体の方向性に影響をおよぼす意思決定が求められます。

その下の大戦略レベルは、会社のエンジニア組織全体に影響をおよぼす役割となります。職位的にVPoEはCTOの配下ではないかという意見もあると思いますが、役割が異なるだけであり実質的な責任範囲の抽象度的には同一階層であると考えます。

最後に

整理しといてなんですが、自分が階層の少ないスタートアップにいるせいかこんなに階層化するのは動きづらくてやりにくそうだと思いました。

とはいえ、自分の役割として何を求められているのか、何を学ぶべきかを把握するのに階層に当てはめてみるのはおすすめなので、みなさんもぜひやってみてください。

2018-10-14

エンジニアが身につけるべき戦略思考

勉強法技術キャリア

「世界を変えたいなら一度武器を捨ててしまおう」という本を読んだのですが、面白くてとてもためになる本でした。

世界を変えたいなら一度"武器"を捨ててしまおう

作者: 奥山真司
出版社/メーカー: フォレスト出版
発売日: 2012/07/25
メディア: 単行本（ソフトカバー）
クリック: 8回
この商品を含むブログ (2件) を見る

一言でいうと戦略について学ぶための本で、日本人が苦手とする戦略思考をどうやって身につければいいかということについて書かれています。特段エンジニア向けに書かれているというわけではないのですが、エンジニアの成長やキャリア戦略という視点で読むと大きな学びが得られる内容です。

この記事では特に参考になった内容について私見を交えつつ備忘録を兼ねて書こうと思います。

戦略は階層で考える

戦略には階層があり本書ではそれを以下の7つの階層で表しています。

f:id:katsuki1207:20181014224906p:plain （↑本書より引用）

ここで重要なこととして戦略の階層には「上位のものが下位を決定する」という原則があります。言い換えると「両者が同じレベルで均衡している場合に、より上位の階層で力を持っている方が勝つ」ということです。

例えば国レベルの話でいうと、長い間もの作りを経済の柱としてきた日本は技術力で国を支えてきました。日本人は国民性として技術を身に着け発展させることが得意なのです。これは戦略論でいうと一番下の階層に位置します。いくらすごい技術であってもそれ以上の階層レベルで戦略を組み立てている国には勝てません。

これは個人レベルでも言えることで、いくらスキルを磨いても上位の戦略が間違っていたら意味を持ちません。

エンジニアに階層を当てはめると

エンジニアの成長戦略という観点で考えたとき、言語習得やプログラミングスキルを磨くことは「戦略の階層」では一番下であり、それを学ぶ上での上位の戦略を決めておいた方が無駄な勉強をするリスクが低くなります。

　スキルはあくまでも〝武器〟に過ぎません。武器はいくら性能の高いものを手に入れたとしても、また新しい武器が開発されます。するとその新しい武器を手に入れるために、またスキルを磨かなければならない。

これは本書からの引用ですが、まさにエンジニアに対しても言えることだと思います。現在業務で必要とされる技術や自分の好きな技術だけをただやみくもに追いかけているだけだと、いずれ壁にぶつかります。なぜなら、身の回りの環境に応じて必要なスキルは変わってくるからです。

「人は無能になるまで昇進する」というピーターの法則もその典型例です。

今何を学ぶべきかを戦略の階層に応じて選択する

ではどうすべきかというと、まずエンジニアとしての自分が戦略の階層のどこに位置するかを見定めます。その上で現在の階層だけでなく、自分が昇進したら必要となる1〜2つ上の階層を学ぶことです。

f:id:katsuki1207:20181014225019p:plain （↑本書より引用）

新卒エンジニアなら戦術レベル
チームリーダーなら作戦レベル
マネージャーなら軍事戦略レベル
開発部長なら大戦略レベル
CTOなら政策、世界観レベル

といった感じです。

1つ上の階層を学習する理由は2つあります。

ひとつは、昇進してから勉強を始めても遅いからです。ピーターの戦略にある通り人は昇進するとそれまで評価されたスキルとは別の能力で評価されるようになります。そのため昇進した途端無能になるという事を防ぐためにも学んで置くことが重要です。

もうひとつは上の階層に意識を向けることで思考の抽象度が上がることです。現在必要とされているスキルの1つ上から自分を俯瞰することで、いまの自分の学習、行動に無駄なものがないか見直す機会になります。

フリーランスエンジニアはどうすればいいのか

フリーランスエンジニアはある意味一人会社の社長と一緒です。自分がどうしたいのかを大上段から知っておく必要があります。そのため目先の仕事で成果を出すための技術力を鍛えつつも、自らの軸となる世界観を自分で描く必要があります。

ある意味全ての階層を押さえておかなければいけないので大変ですが、その分自分の環境をコントロールしやすいともいえます。

大事なことは、今自分はどの階層の本や情報を必要としているか判断し、何をインプットするのかを見極めることです。

会社員でもフリーランスでもエンジニアである限り、学ぶ時間はいくらあっても足りないと感じることかと思います。限りある時間を有効に使うためにも、戦略的に学習する内容を選択することが重要です。

ちなみに一般的には、上位の人はそれよりも下位の階層のことを理解していることが期待されるので、自分が足りていないと思う下位の階層があるならそれも学習することも必要になります。

特に急成長スタートアップの創業者などは階層があっと言う間に変わっていくので、気づかないうちに自分がいる階層が2段階くらい変わってて大変な思いをするとかはありそうだなと思っています。

創業初期はプレイヤーとしてバリバリコードを書いてた創業CTOが、気づいたらマネジメントを余儀なくされて死にそうになるみたいな話です（僕はそうでした）。状況が目まぐるしく変わるスタートアップ経営者は常に自らの階層を理解しておかなければなりません。

自分にいま足りないと思う階層の能力を自己分析し、磨くことがとても重要です。

順次戦略と累積戦略を使い分ける

上記は何を学習するか(What)の話でしたが、ここからはどう学習するか(How)の話になります。

階層とはまた異なる切り口の話になりますが、戦略には「順次戦略」と「累積戦略」の2種類があります。

順次戦略: 目標からブレークダウンして具体的な施策に落とし込みやるべきことを順番に行うというもの
累積戦略: 小さな成果を積み重ねることで、ある日突然大きな効果が生み出されることを狙ったもの

順次戦略はゴールから逆算して進捗がどれくらいか、あと足りないのはどれくらいかと数値化が可能です。それに対し累積戦略は効果の出方が不確実でどこが限界点がわからないという特徴があります。その代わりあるとき急に効果が現れます。

本書ではこれを「見える戦略と見えない戦略」あるいは「陽の戦略と陰の戦略」と表現しています。

順次戦略	累積戦略
見える戦略	見えない戦略
陽	陰
西洋的	東洋的
合理的	非合理的
数値化可能	数値化不可能
進捗が明確	進捗が不明確
線形	非線形

一般的にビジネスの世界では定量化が可能な順次戦略をとることが多いですが、累積戦略の効果を侮ってはいけないというのが本書の主張です。

たとえば勉強を続けている中でそれまで理解できなかったことが「そういうことだったのか！」と急に理解できる瞬間（いわゆるアハ体験）は、まさに累積戦略の効果が現れた瞬間です。小さな細かいインプットを大量に積み重ねていくとそれが有機的につながって一気にジャンプします。これを「創発」と呼びます。

成果を上げるためにはどちらか一方のみではなく両方やるのが大事で、本書では累積戦略から先にとりかかり土台を固めつつ順次戦略にとりかかることで成果が倍増すると説明されています。

エンジニアの成長戦略でいうと、「資格取得のためにマイルストーンを決めて学習カリキュラムを計画的にこなす」のが順次戦略だとすると、「毎日60分コードを書く」とか「コードリーディングをする」といった習慣が累積戦略にあたります。

たしかに、第一線で活躍されている有名なエンジニアの方が成長のための累積戦略を推奨している話はよく聞きます。

かくいう僕もt_wadaさんの講演資料にある「四半期ごとに技術書」や「毎日コードを書く」は現役エンジニアでいるために習慣として忘れないようにしています。

↓参考資料 qiita.com

まとめ

戦略には階層があり、自分の位置を把握した上で学習内容を選択することが大事
順次戦略と累積戦略の両面から学習することが大事

今までなんとなくの理解しかなかった「戦略」や「戦術」という言葉についての解像度が上がりかなりスッキリした本でした。

世界を変えたいなら一度"武器"を捨ててしまおう

作者: 奥山真司
出版社/メーカー: フォレスト出版
発売日: 2012/07/25
メディア: 単行本（ソフトカバー）
クリック: 8回
この商品を含むブログ (2件) を見る

余談ですが、この本自体は先日参加したJulyTechFestaのセッションの一つで紹介されていたことがきっかけで興味を持ちました。紹介してくれた講演者の方に感謝です。

katsuki.hatenablog.com

追記

当記事の続きを書きました。 katsuki.hatenablog.com

2018-10-07

ブログを週に一本書き続けて学んだこと

学んだことブログ

今年の6月から週に一本かならずブログ記事を出すという取り組みを続けているのですが、10月に入り会社個人ともに区切りを迎えたので振り返りがてら記事にしてみようと思います。

ブログを書きはじめたきっかけ

もともと、起業した当初から尊敬する先輩経営者（エンジニア）からブログは採用に効果的だから書いた方がいいとおすすめされていたものの、なんとなくおっくうで数記事書いたっきり数年間放置したままでした。

そんな中以下の記事を読んだことがブログを再開するきっかけとなりました。

kakakakakku.hatenablog.com

とても共感できる内容でブログ熱が再燃したのと、タイミング良く著者の@kakakakakkuさんがメンターとしてブログ継続の指南をすると公表されていたので、深く考えずにブログメンティーとして弟子入りさせてもらいました。

週に一記事リリースするというルールのもと、メンターのフィードバックを受けながら毎週記事を書くことになりました。

やってみてどうだったか

本来ブログを書くこと自体は手段であって目的になるものではないと考えていましたが、習慣化のため継続することを一義的な目的として愚直に毎週リリースしました。

続けることを目的としたときに監視してくれる人がいるというのは効果絶大です。おかげで6月下旬に開始して現在まで一度も欠かすことなく毎週記事を出し続けることができました。

書き続けて得られたこと

当初ブログを開設した目的としては

採用力の強化（ブランディング, ミスマッチの抑止）
文章力の向上

くらいでしたが、継続することを通して以下のことを得られました。

日々の中から気づいたことや学びの機会を探すようになった

慣れないうちはネタを見つけるのだけで一苦労です。しかしネタがないなんてことはあり得ないはずです。

ネタを見つけるコツはいかに自分自身の差分に敏感になるかだと思います。

そもそもスタートアップの経営者をやってて一週間の中で学びが一つもないなんてことありえません。ネタがないのは怠慢か鈍感かのどちらかです。

学んだことや感じたことを記事として可視化するのは、自分自身が一ミリでも前に進んでいる証を残すということであり、その過程を通じて自分を俯瞰して振り返りを行うということです。

そういう意味で記事を書くことは精神衛生上とても良い活動ですし、その習慣を得られたのは想定外に大きなメリットでした。

情報を整理し曖昧さをなくす癖がついた

あるテーマを記事化するためには人に説明するのと同じくそのテーマについて理解している必要があります。その際理解があやふやだととても文章化しづらく内容としても曖昧で主張の弱いものになってしまいます。

そのため必然的に日々のコミュニケーションや記事になりそうなネタに出会った瞬間から頭の中で咀嚼し曖昧さを排除しつつ構造化しようとする習慣ができました。これによりテーマを決めてから記事化するまでのスピードは以前に比べてとても早くなったように感じます。

ブログは履歴書になる

ブログを書き始めてから、出会った人に「ブログ読んでますー」と言われたり久しぶりに会った人に記事の感想言われたりするようになりました。蓄積した記事は自分がどんな人間なのかを知ってもらえる有用なツールになるなぁと思います。

まとめ

ブログじゃなくてもTwitterや登壇でもなんでもいいと思いますが、世の中に学びをシェアしたり意見を投じることによりフィードバックがもらえたり誰かに何かを感じてもらえたり議論が生まれたりするということは、それだけで価値があることだと思います。今後もブログを継続しながらも、より質の高い記事をどんどん出せるように精進していこうと思います。

最後に、3ヶ月半の間メンターとして進捗確認や記事のフィードバック、叱咤激励のメッセージをくれた@kakakakakkuさんには大感謝です。日々仕事の合間の時間をこじあけて記事を書く作業は正直大変でしたがカックさんのメンタリングのおかげで保つことができました。メンティーは9月で卒業となりましたがアウトプットは引き続き継続していきます。

2018-09-30

サーバーレスアプリケーション開発ガイドでLambdaについて学んだ

書評 AWS サーバーレス

積読してましたがようやく読みました。AWSLambdaを利用したサーバーレスアーキテクチャの構築方法が解説してあります。

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

作者: 西谷圭介
出版社/メーカー: マイナビ出版
発売日: 2018/03/16
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

サーバーレスアプリケーションとは何か？サーバーレスのメリットとは？という内容から始まり、AWSを用いてサーバーレスアプリケーションを構築する方法について詳しく書かれています。

サンプルアプリケーションとしては、以下の3つの例がソースコード付きで解説してあり、とても実践的な内容となっていっます。

CloudWatchのアラームをトリガーに自動処理する
Amazon KinesisとLambdaを使ってTwitterデータをDynamoDBへ保存する
LambdaとVue.jsを用いて写真投稿サイトのSPAを作成する

またLambda以外にもサンプルで利用するすべてのAWSサービスについて解説があるため、AWSを使ったことがない人にとっては手を動かしながら入門できるという意味で良さそうと感じました。

今回の記事では、試しに写経してみたTwitterのリアルタイム解析アプリケーションについて記載してみます。

AmazonKinesisでTwitterのデータを受け取りDynamoDBに保存する

Pythonスクリプトを実行しTwitterのタイムラインを取得しKinesisに保存します。それをトリガーにしてLambda関数が呼び出されDynamoDBへとデータが保存されます。

f:id:katsuki1207:20180930003534p:plain

このアーキテクチャではTwitterのタイムラインを処理しますが、大量に流れるデータを処理するという点では様々なユースケースに応用可能です。

以下、AWSの設定や主要なスクリプトのみ記載します。

タイムラインからKinesisにデータを送る

from TwitterAPI import TwitterAPI
import credentials
import boto3
import json

consumer_key = credentials.customer_key
consumer_secret = credentials.customer_secret
access_token_key = credentials.access_token_key
access_token_secret = credentials.access_token_secret

twitter = TwitterAPI(consumer_key, consumer_secret, access_token_key, access_token_secret)
kinesis = boto3.client("kinesis")

res = twitter.request("statuses/filter", {"locations":"122.87,24.84,153.01,46.80"})

for item in res:
    print(item['text'])
    kinesis.put_record(StreamName="twitter-stream", Data=json.dumps(item), PartitionKey=item['timestamp_ms'])

Lamda関数を用意する

ストリームに保存されたツイートのデータから値を取り出してDynamoDBのテーブルに保存します。

import boto3
import json
import base64
import logging
import os

logger = logging.getLogger()
logger.setLevel(logging.INFO)

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table(os.getenv('TABLE_NAME'))

def lambda_handler(event, context):

    try:
        batch_item_list = []
        for record in event['Records']:
            #Kinesisのレコードはbase64エンコードされているためデコード
            payload = base64.b64decode(record['kinesis']['data'])

            data = json.loads(payload)
            item = {
                    'id' : data['id'], 
                    'timestamp' : int(data['timestamp_ms']), 
                    'text' : data['text']
                }

            batch_item_list.append(item)

        with table.batch_writer() as batch:
            for item in batch_item_list: 
                batch.put_item(
                    Item=item
                )
            return
            
    except Exception as e: 
        logging.error("Something went wrong...")
        logging.error(e.message)
        raise

なお、いくつか誤植があり書籍にあるサンプルコード通りに写経してつくっても動きませんでした。今回は理解を深めるために自分でデバッグしましたが、こちらのページから修正版のソースコードをダウンロードできるようです。

book.mynavi.jp

まとめ

サーバーレスについて概念的な話から具体的な実装までひととおり学べる良い本でした。

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

作者: 西谷圭介
出版社/メーカー: マイナビ出版
発売日: 2018/03/16
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

以前参加したサーバーレスミートアップ然りLambdaはいろんな活用方法があるので事例をもっと知りたいと思いました。

katsuki.hatenablog.com

2018-09-23

AWS Innovate Japan 2018を受講してみたら素晴らしかった

カンファレンス AWS 技術

AWS Innovate Japan 2018とはなにか？

全36セッション×約30分のAWS公式オンラインカンファレンスです。初級者から上級者まで、トラックごとに興味のあるテーマを体系的に全て無料で学習できるようになっています。特にAWS始めたばかりで何から学んだらいいか分からないという方にとっては入り口としてすごくよさそう。

aws.amazon.com

上級者向けになると、コンテナやIoT、機械学習などについてハンズオン形式で学ぶことができて学習のとっかかりとしてとても良さそうだと思いました。

f:id:katsuki1207:20180923211235p:plain 公式サイトより引用

試しに、セキュリティについてのセッションとビッグデータ分析についてのセッションを受講してみたので、メモを記載しておきます。

Web システムで押さえておくべきセキュリティの考え方

f:id:katsuki1207:20180923221118p:plain

セッション概要
- Web アプリケーションをAWS上で構成する際のベストプラクティスを紹介するセッション
- AWSはじめてみて運用しているけどセキュリティ面考慮できてるかなんとなく不安な人向け
セキュリティ指針
- IPA非機能要求グレード2018
  - https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
Webシステムに求められるセキュリティ対策
- サービス停止の抑止
  - DDoS対策
- 情報漏えいの抑止
  - 脆弱性対策（インジェクション対策）
  - ネットワークセキュリティ
  - 認証とユーザー管理
  - 暗号化
  - アクセスコントロール
- 攻撃と不正利用の検知
  - ログの取得、補完
  - 検知、分析、対策
サービス停止を狙ったDDoS攻撃の具体例
- SYNフラッド
  - クライアントから意図的にACKを返さないことでサーバーは返答を持ち続ける
- UDPフラッド
  - 発信元IPを偽装して大きなサイズのUDPパケットをランダムに攻撃対象に送り続ける
- HTTPフラッド
  - 多数の端末にBotを仕掛ける。攻撃対象にHTTPのGetリクエストを大量に送信してリソースを枯渇させる
サービス停止の抑止対策
- AWS Shield
  - 全パケットを検査
  - DDoS攻撃の約96%を軽減
  - 全ユーザーに無料提供
- AWS CloudFront
  - コンテンツ配信用のキャッシュCDNとしてフロントに配置
  - レスポンス向上、負荷軽減
脆弱性攻撃の例
- SQLインジェクション
  - 意図しないSQLを実行させる
脆弱性対策
- AWS WAF
  - CloudFrontやELBと組み合わせて利用
  - トラフィックを監視（HTTP, URL, Cookie, クエリ文字列）
  - 不正なアクセスを遮断しレポート
    - サードベンダーが提供しているマネージドルールをインポート
  - IPアドレスのルールを登録することができる
    - ホワイトリスト、ブラックリスト
ネットワークセキュリティ
- Amazon VPC（Virtual Private Cloud）
  - サブネット
  - セキュリティグループ
    - 一般的なファイヤーウォール
認証とユーザー管理
- Amazon Cognito
  - 既存のセッション管理による認証ではない
  - 認証をAWSのマネージド・サービスで実施
    - サインアップ、サインイン、サインアウトといった認証機能を提供
    - ユーザー管理、パスワード管理機能を提供
暗号化
- AWS Certificate Manager（ACM）
  - 証明書発行サービス
  - 無償で提供、自動で更新
- AWS Key Management Service（KMS）
  - 暗号化キーを発行
  - EBSを暗号化
  - AWSのクラウド上に自社のデータを預けるのが不安なお客さんにとって使えるサービス
アクセスコントロール
- AWS Secrets Manager
  - 必要なシークレットの保護
    - データベースの認証情報やAPIキー
  - ex. EC2のオートスケール時にシークレットを取り出し拡張するときとかに使う
- AWS IAM
  - 各リソースへのアクセス権限
不正利用の検知
- Webシステムで取得、分析すべきログ
- アプリケーションログ
  - Web/APサーバー、DBサーバー、CloudFront、ELBのログ
- インフラストラクチャーログ
  - AWS内のネットワークログ
  - AWSサービスの操作ログ
ビギナー向けだと思ってどんなものかと思って聞いてたけどかなり具体的でしっかりした内容だった。一般的なセキュリティの攻撃手法のおさらいと、それぞれの脅威に対してどのような対策をAWS上で行えばいいのかさらうことができていい勉強になった。

何から始める？ビッグデータ活用

f:id:katsuki1207:20180923221115p:plain

ビッグデータ分析を始める前に
- どんな分析をすれば効果があるかはやってみないと分からない。
- 必要な情報は変わっていく
- すばやく結果を出して改善していくことが重要
巨大なデータを扱うには以下が必要
- 巨大なストレージ容量
- 非定形データへの対応
一般的なデータ分析のフロー
- 収集 -> データレイク（保存） -> 処理 -> 可視化
データレイク
- 規模や形式にかかわらずすべてデータを加工することなく保存する単一のデータストア
- AmazonS3に一元化して保存
- 保存したS3データを用途別に加工、分析する際必要なときだけ専用のマネージドサービスを起動、プロビジョニングする
分析の目的が分からない場合
- 事前に確認すべきこと
  - どんなアウトプットを出せばいいか
  - どんなデータをどう加工したら求める結果が得られるか
各ステップとAWSサービス
- 収集
  - AWS Snowball: オンプレミスからの物理的データ移行が可能
  - AWS DMS: 既存DBからのデータ移行やレプリケーションが可能
  - Amazon Kinesis: ビデオやクリックログ等のストリーミングデータを連携可能
  - AWS IoT: デバイスからのセンサー情報などを連携可能
- 保存
  - AmazonS3: 非定型データを蓄積できる。安価。できるだけ生データを保存する。
- 処理
  - AWS Glue, Amazon EMR: データの事前加工。
  - Amazon RDS: RDBMSのマネージドサービス。
  - Amazon Rdedshift: データウェアハウス、データマート用。分析に特化したアーキテクチャ
  - Amazon Athena: S3に保管したデータを直接クエリする
- 可視化
  - Amazon QuickSight: BIサービスとして連携してグラフなどに可視化が可能。
すばやく試すのにおすすめな構成
- 手元のデータをS3にアップ→QuickSight経由でAthenaから可視化する
- 安くミニマムに試せる。
ビッグデータ分析って主語が大きくてとっつきづらいイメージだったけど、具体的なAWSサービスでどう扱うかについて聞くことでかなりイメージがわいた。まずは試しにおすすめ構成を試してみたくなった。

まとめ

ハイクオリティなAWSの講義が完全無料で受けられるの本当有り難い。期間限定（10月10日（水）まで）なので、普段忙しくて後回しにしている人もこれを機に学習してみるといいと思います。
余談ですが
- 忙しい人はVideo Speed Controllerなどの拡張機能でスピード上げて聞くのがおすすめです
  - どの講師の方も丁寧にはきはきしゃべってくれるので2倍速でもはっきり聞き取れます
受けたい方はこちらから申し込めます

2018-09-10

CTOmeetupでフロントエンド技術のトレンドをキャッチアップしてきた

イベント勉強会フロントエンド

buildersconの興奮冷めやらぬ一昨日の今日ですが、今日も今日とてイベント参加してきました。「CTO meet up〜JavaScript（Angular, React, Vue）〜」という、フロントエンドの技術についてのミートアップイベントです。

flexy.connpass.com

フロントエンドのフレームワークの技術選定や技術課題などについてパネルディスカッション形式で現場の先端を行くエンジニアの方の意見を聞けるというもの。以下メモになります。

技術選定の基準

使う人が多い
- 話として上がってくる
- 日本語のQiitaとかでよく書かれている
- 書き心地はよく見ている
何を選ぶかは組織に依存する
- ReactかVueかAngularかは些細な問題
- メンバーのスキル構成に合わせる
React, Reduxでデータフローまわしていると型定義の強力さを感じる
- React, Reduxのflowtype、typescriptはすごい強力
- リファクタリングがしやすい
サードパーティーに頼らない
- モデル、レビューレイヤーの流れがきちんとできていれば要らないケースも多い
npmのパッケージよく使うと思うが、サードパーティーライブラリのバージョンのメンテとかってどうしてる？
- greenkeeper.io使ってる
- 2週間に一回は改善dayみたいなの設けて、バグfixなどと一緒にやる
- 計画を立てて一定のタイミングでバージョンアップする

今の技術の課題・つらみ

フリーランスでフロントエンドの顧問とかやってると、相談がすごいくる
- メインでやってる人が抜けちゃってどうにもならなくなっちゃったパターン
- パフォーマンス、バグが多すぎて何かあるとすぐ壊れちゃうパターン
勉強の仕方、キャッチアップの仕方を教える
- 面談をしてご飯を食べながらキャッチアップする方向に気持ちを向かせる
React周辺はエコシステムのライフサイクルが早すぎる
- 以前は年に1回だったのがいまは半年に1回くらいリファクタリングしなきゃいけないくらいの感覚
- チームがエコシステムについていけるのかが重要
- いつまで付き合う？
ドキュメントを読んでなんとなくできる風になっているプロダクトが凄く多い
- ex. コンポーネントをぶわーっと羅列してるようなプロダクト
- 表面だけじゃなくて設計、動き、パフォーマンスを理解して使うのがすごい大事

これからのフロントエンドの動向

Webコンポーネント
- 夢見てる人多いと思うけど、パフォーマンスそんなに出ないと思うしビジネスインパクトは薄い
PWA(Progressive Web Apps)
- オフラインで見えるようになったときに嬉しいやつと嬉しくないやつがある
- 例えばホットペッパービューティーは予約できないと意味がない
guess.js
- Google製
- AにアクセスしたユーザーはBにアクセスしやすいという先読み技術
- ユーザー体験の向上
リアルタイム通信
- React, Angular, VueのようなSPAのリアルタイム通信がくると思う
- WebRTCはまだハマりどころがある

今現場にもっともほしいフロントエンドエンジニアとは

フレームワークとか関係なしに描画まわりで基礎力の高いエンジニア
- 「表現のためのエンジニアリング」と「機能実装のためのエンジニアリング」
- アーキテクチャをつくるフロントエンドエンジニアとインタラクションをつくるフロントエンドエンジニア
  - だいたい足りないのはインタラクション
  - 触り心地にコミットできるエンジニアが凄く希少
React, Vue, Angularなど使う上でその裏側で何をやっているか知ってる人
- フレームワーク使って「作ってみました」レベルの人凄く多いけどそれだけだと判断できない
  - 運用の泥臭い部分を含めて苦労やドラマをきちんと語れる人
技術プラスアルファで何か持っている人
- 技術+デザイン, 技術+マーケティング etc…
- その上で技術選定、判断ができる人が求められている。特にスタートアップでは。

フロントエンドエンジニアはやることがいっぱいある中で若い人にどうアドバイスするか

「なんでもいいからアプリケーション作った方がいいよ」というアドバイス
- 実際に技術に深く入り込んで経験値をためる
- フロントエンド含めたパフォーマンス
つくって人に見せる
- 悩む時間をいっぱい作る
プロトタイプバトルというのをやってる
- 話し合って結論出ないので、両方つくってみる！
モブプロはひとつのソリューション
- コストかからないしお互いに知識を共有できる
- お互いに苦手な部分をやってみたりする

フロントエンドエンジニアのキャリアパス

React, Vue, Angularとかで何かをつくれるってだけだとコモディティ化してきている
プラスアルファで強みが必要

質疑応答

Q.ベンチャーでスピード感出したい組織において、どのようなエンジニアを採用するべきか？
- A1.組織によるとしかいえないけど、本当に人数少ないときはフルスタックエンジニア一択。ある程度大きくなってきたら専門性を重視した方がいい。
- A2.スタートアップだと、技術的難易度がどこにあるのかとどこを強みにしていきたいかによって決めるのが大事。

まとめ

うちもJavaScriptごりごりのSPAなので、話を聞いていてとても参考になったのと課題感やつらみは凄く共感した。React周辺のライフサイクルが早くて辛いというのはそのとおりで、スタートアップにとってフロントエンドのキャッチアップどうするかはうまくやっているいろんな会社の事例をもっと沢山聞きたいなと思った。

結論、フロントエンドは楽じゃない。