Frontend Training Meetup #1 https://gyazo.com/105d32a9ae45ce74e58101c60182b93d
仕組みを変えれば世界はもっと良くなる
産業ごとのプラットフォームをつくる
オフライン広告
トラックと物流
サービス
ラクスル
ハコベル
デザイナー、エンジニア含めた社内ハッカソンも行う
JSerに転職してからの２年間
転職して２年目
ようやく食らいつけるようになった
自動テストしにくいコンポーネント
ライブラリがわからない
当時思ってたこと
ツールが増えた背景を噛み砕いて知りたい
時流に乗った技術選択ができるように
開発者の未来をつくっていきたい
インターンがいた
ツールの多様化が進んだ証拠
昔はいくつかのライブラリを覚えればいいくらいだった
How（手段）/What（ライブラリ）の暗記で住む時代は終わった
過去から今の「なぜ」を理解してみる
なぜ今それを使っているかを考えてみた
たった5年で大きく変わった
モジュール昔話
require / importできない
書きやすいJSをブラウザで動くJSに変換
<script>タグを多重に使う
状態管理
data属性やcookieに諸々突っ込む
どこに何があるかわからない
誰が何を書き換わるのかわからない
Command Query Resource Separation
静的解析
HTTP1.1
並列リクエストが増えて詰まる
パフォーマンス遅延
パフォーマンス最適化
リッチにすると操作がもたつく
高頻度で発生するイベントでリフロー起こすと遅い
Boilerplate create-xxx-app
時流にのりながら役割を考える
ブラウザでの実装状況
ベースにした新しい概念
ツールの洗練され具合
フロントエンドへの製品要求
なんでこれを使うのか？を考えると自ずと問題が見えてくる
いまどんな問題が起こっているのか？を考える
向こう何年枯れるような技術と付き合わなくてす密葬
翻訳できるフロントエンジニアに育ててみるのはどうか
翻訳とエンジニアを育てるのは関係があるか？
技術情報の翻訳できるレベル＝自発的に技術習得できる
そういうエンジニアは戦力である
そうじゃない場合は戦力外になりうる
モダンフロントエンドにおいて英語が読める必要があると言って良いかも知れない
バックエンドもインフラも同様
実例
エンジニア歴３年未満
ほぼ翻訳しながら身につけてた
どんなものを翻訳したか？
React 公式ドキュメントのトップページ
React チュートリアル翻訳 => 検索トップページ
Vue 公式 cookbook の Google Map との連携
React Navi 公式ドキュメント
Udemy React + Redux コース 生徒386人 => ぶっちゃけ英語の記事、コースを見た結果作っている
Q. 英語が得意だからできるのでは？
A. 翻訳する過程で英語力を高めた
翻訳速度：200word / 1h
Q. 何から始めるか
A. 自分が理解しているものから始める
1. 知っている技術が英語でどう説明されているか理解
2. 翻訳を通して技術を習得
Q. 文法がわからない
大学英語レベル
Q. 辞書はなにがいいか
Q. 勝手に翻訳して公開して良いのか？
A. 気にしない（気にするのは日本人だけ）
A. 精度の判断ができるだけの理解力はあったほうがいい
Q. 翻訳せずとも読めれば良いのでは？
A. 翻訳できれば読める速度が上がる
フロントエンド難しくない？
多くのフレームワーク、用語、知識
どこから手をつければ？
とりあえずCLIからはじめる
難しい部分に触れずにHello Worldまでを構築できる
モチベーション
それぞれのフレームワークの思想をCLIを通じて知りたい
前提
@angular/cli 7.5.6
依存性の注入、E2Eのツールyどおおよそのアプリ開発に必要なものが入ってる コマンド
add
build/serve
new
generate
lint/e2e/test
開発ベストプラクティス最初から設定できている
create-react-app 2.1.5
react-scripts
start / build
test
eject
コンフィグをローカルにコピーしてカスタマイズ可能できる
戻れない
最低限の設定のみ
@vue/cli 3.5.0
ドキュメントが豊富、コアライブラリなどのエコシステムが成熟
コマンド
add
create
serve/build
ui
@vue/cli-cervice
@vue/cli-plugin-hogeをvue-cli-pluginで閣僚可能
@vue/cli-plugin-eslint
vue-cli-plugin-storybook
プラグインで追加設定できる
人格とステップに合わせたエンジニア育成
画一的な教育のやり方を考える
余裕が必要
失敗例
同じ
無茶な仕事をやってきたのを楽しんで成長してきた
同じ成長のやり方で後輩にやって疲弊してしまった
人間は実際は同じではない
忙殺
時間的にも精神的にも余裕がない
後輩に感情的に接してしまった
業務アサインについて
レベル感に合わない依頼
=> ギリギリ達成できる仕事をお願いする
本人がモチベーションできない仕事の依頼
=> その仕事が楽しくなる、技術が得られるきっかけづくりが必要
不得意分野を伸ばす意識が先行
得意分野を伸ばすアサインを心がけ
「自分の領分」だと自信を持ってもらう
ティーチングとコーチングの使い分け
教えるだけになってないか？
直接的に教える
「なぜこうするか」を細かく説明して腹落ちさせる
調べ方やコツを慣れるまで教える
自分でできるようになるためにと意識させる
「教えてもらってる」とさせない
その分野においての初心者を意識する
間接的に気付かせる
何で詰まってるのかヒアリング
できない理由を掘り下げる
ほどよいヒントは会話に散りばめる
自分でわかった！という感覚を感じさせる
教える相手のステップに合わせて使い分けることが必要
使い分けが難しい
いまどのステップにいるかを理解する
https://www.youtube.com/watch?v=GA8z7f7a2Pk
Developer Experience
開発者が開発を通じて得る経験や体験
組織構造におけるフロントエンドチームの体制
チームの大きさばらばら
１人だけどチーム
そもそもチームがない
外注してる
横のつながりがない
技術や経験の共有がない
誰に相談していいかわからない
人と繋がりたい
対面で情報共有
LT会
1on1
ボトムアップで交流する場を作ったことで変化が生まれた
いくつかのチームで活動を真似る人が増えてきた
動くより動かないほうが恥ずかしい
越境して情報共有する共同体が形成された！
オフサイトMTGも実施