I want to be "I can develop frontend a little"

とあるエンドエンジニアの勉強会や技術系の個人的メモ集。

2019/07/23 モダンフロントエンド勉強会〜進化し続けるUXとDX〜 に参加してきました!

2019/07/23(火)に開催されたモダンフロントエンド勉強会〜進化し続けるUXとDX〜 に参加してきました!

techplay.jp

パネルディスカッションと質疑応答の内容まとめます。

会社紹介&技術スタック紹介

freee株式会社の加藤 慧氏

f:id:matsumana07384:20190730212340j:plain
freee株式会社の技術スタック

  • 2013年頃に技術選定をおこなったため、当時の選択としては妥当

f:id:matsumana07384:20190730212354j:plain
freee株式会社の規模

ラクスル株式会社の水島 壮太氏

f:id:matsumana07384:20190730212423j:plain
ラクスル株式会社の技術スタック

  • ビジュアルや見た目が大切になるので、グラフィック系のJSを使用

サイボウズ株式会社の小林 徹氏

f:id:matsumana07384:20190730212446j:plain
株式会社サイボウズの技術スタック

f:id:matsumana07384:20190730212531j:plain
サイボウズ株式会社の専門的なサポートチーム

  • 専門的にサポートするチームがある

パネルディスカッション

ファシリテーターの方が6つの質問に従ってパネラーの方々に尋ねていく形式でした。

f:id:matsumana07384:20190730212556j:plain
パネルディスカッション形式

1つめ:自社のフロントエンドサービスではどんなフロントエンド技術を使っていますか?

f:id:matsumana07384:20190730212628j:plain
1つめの質問

サイボウズ株式会社の小林 徹氏

  • 技術選定について
    • 例:Closure Toolsについて
      • 当時はVue.jsやReact.jsはなかった
      • 型安全のものを作りたかったので、当時の選択としては妥当
  • 過去からどんな変遷があったの?
    • 現状では固有のシステムになってしまった
    • まだ脱却できていないのでこれから
  • 各技術のメリット・デメリット
    • 選定する技術として、会社では指針は設けていない
    • 作るプロダクト規模感を意識し、型安全な言語を選ぶよう意識している

freee株式会社の加藤 慧氏

  • 技術選定について
    • ノウハウがあった技術を当時は選んでいた
    • Vue.js 1.0を導入したときには、やんちゃな心が残っていた
    • 基本的には長いものには巻かれろな精神
      • メジャーに使われていて、issuseが少ないライブラリ
  • 過去からどんな変遷があったの?
    • メジャーなものを取り言えれることで安定した開発を実現できていることはいい流れ

ラクスル株式会社の水島 壮太氏

  • 技術選定について
    • 2年前
      • モノリシックなシステム
      • 部分的に導入を考えていたのでVue.jsを導入
        • そこからVue.jsに舵切りしていく
    • 最近
      • 新規プロダクト
        • 思い切って技術的チャレンジをしていこう!ということでNuxt.jsを行って、事例を作れたので、横展開を行っている
  • 各技術のメリット・デメリット
    • メリット
      • 新しい技術を取り入れるとエンジニアの人がテンションが上がって仕事してくれる(PO目線)
    • デメリット
      • 既存で入っていたタグが入れれないパターンが多発
        • 分析関係は早めに確認して、マーケ側などと相談して入れる入れないを決める必要がある
+α 新しい技術を使うことを組織的に推奨してるか?
サイボウズ株式会社の小林 徹氏
  • 目的があるならOK
  • フロントエンドの場合、Reactシフトでモチベーションにつながっている
freee株式会社の加藤 慧氏
  • 最近やってみたい技術はありますか?
    • 特にない
  • 新しい技術を追加するのはよいことだが、ノウハウがないものを入れると苦労が伴う(その苦労をした経験者が多い)
    • よく使われているメジャーなものを使うことの方が多め

2つめ:サービスのパフォーマンスを高めるためにしていることを教えてください!

ラクスル株式会社の水島 壮太氏

  • パフォーマンスの定義は曖昧
    • サーバーサイドでキャッシュ効かせる、などは当然のこと
    • toBサービスであることもあり、ピークが平日で、PCメインな面もあり、表示速度を意識することは少なそう
    • 使い勝手の面を意識することが多め
      • APIを同期でなくて、非同期で行う
      • ローディングに時間がかかる必要があるので、ストレス感じないようにUXを設計

サイボウズ株式会社の小林 徹氏

  • BtoBなので、BtoCよりパフォーマンスはクリティカルではない
  • サービスの性質上、ユーザーがJSを書いてAPIを叩くことが可能なため、SQLのチューニングは行う
  • クライアントサイドではパフォーマンスなんなの?を読書会したり、speedcurveをいれたりしており、現状は、パフォーマンスがどうなっているかを知るフェーズ
    • データを元に改善を検討している
  • USのサービスだとネット環境が日本より安定しない環境なことも多いので、ファイルサイズのケアは意識

freee株式会社の加藤 慧氏

  • toB サービスはネットワーク制限を受けることが少ないので、その点は考慮してない
  • 仮想DOMを正しく使うことが大切なので、どちらかというとクリーンチューニングの世界
  • Reactが出る前はいろんな知識を使ってチューニングしていた
  • 仮想DOMを正しく使うことで賄えそう

3つめ:品質担保するための取り組みを教えてください

f:id:matsumana07384:20190730212647j:plain
3つめの質問

freee株式会社の加藤 慧氏

  • スナップショットテストを導入
  • マニクレーションてすとはメンテコストが高いのでやっていない
  • storybookに追加できるコンポーネント=責務が分解できている
  • Linterやprettierでコードを担保している

ラクスル株式会社の水島 壮太氏

  • 品質管理にもいろんな観点がある
    • ランタイムエラー減らす
    • E2Eのテストの実施
      • TestCafe
        • 際限なくかけてしまうので、ほどほどに
      • CircleCIも回している
    • Eslintは導入
    • 障害はIEに多いので、「IE確認した?」を言うことで品質の意識を高めている

サイボウズ株式会社の小林 徹氏

  • CIやJenkinsを導入
  • QAチームと一緒にスクラムをしているチーム
    • モブプロで一緒にテスト書くチームもある
  • テストピラミッドを用いながら、カバーできる範囲を増やしている
  • プロダクトでチームが分かれているので、色んな人が話し合って品質をあげている

+α:QAチームはありますか?

freee株式会社の加藤 慧氏
  • QAチームあり
    • 人事労務Freee
      • 法律に動くことが必要
      • ドメインプロフェッショナルがテストを作ることが必要

4つめ:ワークフローで工夫していることがあれば教えてください

f:id:matsumana07384:20190730212719j:plain
4つめの質問

サイボウズ株式会社の小林 徹氏

  • 各プロダクトのヘビーユーザーは社内
    • githubのdevelopにマージされると、順に開発環境、社員環境、本番環境へ自動デプロイ
  • 社内でスクラムが流行り、今ではモブプロが流行
    •  Zoomでモブプロしている
    • レビューのコストの削減や属人化が解消できる
  • 最近ではモブプロ勉強会
    • よくないところもあるよね、と反省
      • 上がったデメリット
        • 個人の成長がないがしろにされる( みんなで考えるので、1人で考えて解決するプロセスがなくなる)
        • 単純に疲れる
        • モブプロに適切じゃないタスクもあるので、使い分けが必要そう
    • チームでタスクをこなしていく精神はよい

ラクスル株式会社の水島 壮太氏

  • モブプロ&ペアプロ流行ってる
    • レビューに頼らない体制は結構やってる
  • 1スクラムフロントエンド2名以上にして相互レビューしている
    • フラットに適宜実施
freee株式会社の加藤 慧氏
  • 同じくモブプロを導入
  • ライブコーディングをする頻度が多め
    • 社内はフロントエンド、バックエンドの区切りがなく、アプリエンジニアとして領域は広めに業務を遂行
      • 専門知識が身に付かないデメリットはあるが、いろんな知識が身につく
      • 考えていることを口に出しながら実施
      • ライブコーディングしている人の手先を見て勉強になった!という話はよく聞く話

        +αモブプロ知見

  • 会議室でモニターがおいてある方向(椅子の向きとは違う方向)を向いて実施すると、首が痛くなるので、気をつける
    • 椅子とパソコンの向きに合わせて行うことが大切
  • パソコンに向き合うために、ハングアウトを使ってやってみる

5つめ:フロントエンドエンジニアが働きやすい環境とはどんな環境だと思いますか?

f:id:matsumana07384:20190730212740j:plain
5つめの質問

freee株式会社の加藤 慧氏
  • 社内ではアプリエンジニアとして領域を幅広くやっているため、フロントエンドとしての働きやすい環境は述べにくい
    • サーバー&フロントを見ているので、お互いがどうしているのか気になるところ
  • フロントエンドエンジニア×デザイナーORビジネスサイドとの関わり
    • フロントエンドエンジニアは、デザインを真っ先に知る顧客のうちの1人
    • UIに関する感じた違和感をデザイナーORビジネスサイドに共有するフローは確立済み

サイボウズ株式会社の小林 徹氏

  • Freeeさん同様にフロントやバックの区分けがないため、フロントエンドとしての働きやすい環境はわからない
  • フロントエンドエンジニア×デザイナーORビジネスサイドとの関わり
  • SmartHRさんの事例(※技術顧問をされているため)
    • UIの良さを押していることから、プロダクトとしてよいユーザー体験を作ろうとしている
      • フロントエンドエンジニアは重宝される

ラクスル株式会社の水島 壮太氏

  • フロントとサーバーで業種はわかているが、どちらかに歩み寄っている人もいる
  • フロントエンドの働きやすい環境
    • 人数がすくないため、 フロント < サーバー < インフラ の順で意見が通りやすくなりがち
      • フロントエンドが多数派になること
      • よいサービスを作る上で正しいこと、やりたいことを伝えられる環境をつくる
    • フロントエンドエンジニアはデザイナーさんとのディスカッションが多いことは自覚して、コミュニケーションをしっかりとっていく意識するべき

6つめ:自社がフロントエンドエンジニアに期待していることをぜひ教えてください

f:id:matsumana07384:20190731134802j:plain
6つめの質問

  • 弊社に入るとこういうことができるよ

ラクスル株式会社の水島 壮太氏

  • リアル産業なため、リアルな部分(印刷されるデザインなど)を確認してもらうことが多いため、立体的なUXを再現することを求める
  • UXUIにこだわりをもってほしいので、とりあえずJavaScript書きたいよりもプロダクトを大事にできる人がよさそう
  • to C よりも長く使われるコードなので負債を残さないように書けることが大切

freee株式会社の加藤 慧氏

  • 業務アプリケーションなので、グラフィカルな部分もある
    • 破綻しないデザインでできること
    • JavaScriptも強く
    • 技術を楽しく使いこなせると楽しくできる、そんな人におすすめ

サイボウズ株式会社の小林 徹氏

  • プロダクトが大規模なので、気合で書き直す!っていうフェーズではない
  • 技術を使って課題をどう解決していくかを考えるべき
  • 例えば、大量のCSSを削除
  • 技術を使って課題を解決し、OSSやインターネットへ還元していってほしい

会場からのQAタイム!!!

いろんな質問があって面白かったです。

これがなくてはやってけない的なライブラリ、ビルドツールなどありましたら、教えてください!

freee株式会社の加藤 慧氏

  • 社内の中でもいろんなツールを使っている
  • 最新動向は常に追っている
  • 一例
  • webpack × vue.js
  • Linter
  • Sentry はフロントにもいれるべき
    • エラーモニタリング

サイボウズ株式会社の小林 徹氏

  • npmを制御するlibraryなど細かいツールはたくさんある
  • npmの更新管理は問題になりがちだが、gitのpackage検知はわりとおすすめ
  • 一例  - ESLint  - Prettier  - TSLint

デザイナーとの協業の観点として役割がグレーな部分はどう切っているのか?

ラクスル株式会社の水島 壮太氏

  • デザイナーとエンジニアがペアプロでアニメーションをチューニングを行うので、それぞれの得意な分野で共有中
    • デザイナーのデザインからフロントエンドエンジニアがよしなに調整
    • 社内のデザイナーはCSSを書かないので、コンフリクトは起きていない

サイボウズ株式会社の小林 徹氏

  • デザイナーからFigma で共有
  • フロントエンドエンジニアが実装
  • モブプロで最終調整
    • 一緒に作っていってる感がある

freee株式会社の加藤 慧氏

  • デザイナーとエンジニアはペアプロはしない
  • エンジニアはエンジニアのできることを察することが難しいので、エンジニアからできることを提供
  • エンジニアは、ただデザインに沿って実装するのではなく、本当にこのデザインが適切なのか?を考えながら実装していく

フロントエンドエンジニアってどう採用している???

サイボウズ株式会社の小林 徹氏

  • 会社としては、フロントとバックエンドの役職は別れていない
  • 得意な人がフロントやっていく
  • 募集したり、イベントで声かけたり、面接したりを行っている

ラクスル株式会社の水島 壮太氏

  • 会社としては、フロントとして募集
  • 会社で勉強会を実施
    • コミュニティから興味を持ってくださった人を入れる

freee株式会社の加藤 慧氏

  • 面接
    • 抽象的な構造への理解がある人ってを大切にしている
      • どの言語でも大丈夫そう
    • 野良レビューもやる
    • 成長メインで採用している

IEいつ切りますか?

ラクスル株式会社の水島 壮太氏

  • IE推奨な会社もあったり、Windows7IEアクセスログはあったりするので、現状維持
  • 今後のChromiumベースのEdgeに期待
  • IE10は対象外でIE11以降を公式サポートとしている
  • ユーザーのシェアが2〜3%になった時点でサポート外にすることを検討

サイボウズ株式会社の小林 徹氏

  • MicroSoftのサポートに合わせて対応します

freee株式会社の加藤 慧氏

  • 正式サポートはIE11のため、ある程度続ける
  • クラウド会計を使うユーザーはリテラシーが高いので、ブラウザ乗り換えに応じてもらえるパターンあり
  • ユーザーさんへの啓蒙も大切

感想

今回のパネルディスカッション企業の中ではモブプロが流行されていてびっくりでした。 なかなか導入ハードルが高いように感じているので、いろいろ調べてみたいと思います。 フロントエンドに関して幅広く話を伺えて充実した一日でした!

2019/07/10【シューマイ】Tech Lead Engineerから最新技術を学べ!Vue.js編の勉強会に参加してきました!

2019/07/10(水)に【シューマイ】Tech Lead Engineerから最新技術を学べ!Vue.js編に参加しました。
そのときのメモです。

Vue.jsのslotを活用した汎用的コンポーネント設計について

‌株式会社プラムザの鳩 洋子氏

speakerdeck.com

ざっくり内容

Slotを使う動機

Slotことはじめ

  • Slotは?
    • コンテンツ配信受け口として使用
    • コンテンツ部分にはHTMLやコンポーネントも挿入可能
      • slotコンテンツと呼ぶ
      • 親のデータもOK
    • フォールバックコンテンツ
      • デフォルトのコンテンツを設定可能
    • Named Slot
      • 複数箇所にSlotを使うことも可能
    • スコープ付きslot

Slot活用例

  • モーダル
  • タスクリスト
    • UIパーツ
    • 挙動が同じだけれども見た目がかなり違う
    • 中身を変えればOK

UIフレームワーク

  • UIフレームワークは、slotとscorped slotに基づいて作られている
  • 理解していると使いやすいかも
  • 例:Vuetify

Slotの注意点

  • Vue.js2.6.0以降から新しいシンタックスになる
  • Vue.jsの公式ドキュメントを見ていこう

質疑応答

  • モブプロ会は奪い合い
  • Vue.jsのslotのキャッチアップは大変ですか?
    • 今日のスライドで使えるはず!

ひとこと感想

slot面白そう!

Vue/Vuexを限りなくReact/Redux風に書く話

外資系IT企業の高野 拓貴氏

docs.google.com

ざっくり内容

趣味

typescriptFSA

  • 洗練されている
  • FSA(Flux Standard Action)
    • Reduxが参照している非公式なコーディング規約(=半公式?)
    • Actionとして用いるオブジェクトの型を設定
  • type-script-fsaのactionCreator.async()が便利!
    • 非同期の関数がはじまったとき、失敗したとき、成功したときを機械的に簡単に設定できる
  • 要点
    • ローディング状態とエラー状態をいい感じにしてくれる
    • Vue.jsで書くとややこしめ

createAsyncAction

  • Reduxと同じように書ける
    • 読み込むimportが減らせる

まとめ

  • FSAはアクションとして用いるオブジェクト型の非公式な規約
  • typescript-fsaのactionCreator.async()が非同期アクションのローディング状態とエラーリングを管理がとても便利
  • 同じ書き味でVuexでも単純な関数で書ける
  • 高階層関数 createAsyncAction が便利

質疑応答

  • 気になっている技術は?
    • GRPC
  • Vue.js/React.jsのかきわけは?
    • 趣味はVue.js、仕事はReact.js
      • 安全に書けるのがReact.jsのため、書きやすくて楽なのはVue.jsのため

        ひとこと感想

        よなよな資料を作られたそうですが、充実した内容でした。

 Vue.js書けるAtomic Desine -コンポーネント分割の指針-

GMOインターネット株式会社の成瀬 允宣氏

speakerdeck.com

Vue.jsとAtomicDesignの関係

  • 新規プロジェクトの立ち上げ
    • Vue.js入れたい
      • それに対してJQuey入れてもいいですか?という言葉
      • 困った
  • 何故Vue.jsを使いたい?
  • 人を動かすためのステップ
    • やってみせ、言って聞かせて、させてみせ、褒めてやらねば、人は動かじ
      • ひとつのページを分析
        • ページを担当分けしてみんなでやってもらう
      • データは親が責任持って変えないといけない
        • 子がデータを変更して、親に渡してはいけない
      • 褒めるタイミングはレビュー
        • 指摘するだけがレビューじゃない!
        • 慣れる前は細かい単位で

          まとめ

  • Atomic Designあるべきじゃなくていいよ
  • 実践に道筋を立てることが大切

質疑応答

  • Atom≠HTMLの最小単位という認識ですが、外すことはありますか?
    • 同義になることがおおいけど、そうでないときもあります
  • ボタンの中にアイコンが入る場合は?
    • iconButtonにする
  • Vue.jsでVuexかpagesでしたらどっち?
    • vuexはメインじゃない
    • 親にデータを渡して子は独立
    • ログインとかは使う
    • Vuexを使うとコンポーネント同士が対話できてしまう
    • 使わない方が良さそう
  • テストどの単位でやったほうがいいですか?
    • 画面はテストをしようとちゃいけない
    • テストをしないといけないViewは作るのはおかしい
    • やるとしたらコンポーネント単位
  • クイックイベントどこでハンドリングする?
    • Organismsより上
    • pagesがおすすめ
  • axiosなどの非同期処理はpagesのみですか?
    • ラップしてエラーや成功のコールバックだけ書くようにする
    • promiseは人のマインドセットによる

ひとこと感想

技術をチームに反映させるには自分が動かないと、ですね!

懇親会

シューマイの勉強会ではシューマイが懇親会に出てくるという噂を聞いていましたが、本当でした…!
技術力不足を感じたので、がんばりたいと思います!

f:id:matsumana07384:20190716220750j:plain

2019/07/06 Battle Conference Under30に参加してきました。

2019/07/06(土)にBattle Conference Under30 に参加してきました!

bcu30.jp

イベント自体は3回目の開催だそうですが、私は初参加でした。

新宿の芸能花伝舎という小学校をリノベーションしたイベント施設で行われたため、オープニングもチャイムと「こんにちはー!」という挨拶で素敵な演出からスタートです。

開会挨拶

株式会社サイバーエージェント取締役の長瀬 慶重氏

ざっくり内容

  • エンジニア以外の人がプログラムを触る機会が増え、小学生がスマホアプリを作る時代になっ てきて、エンジニアのすそのが広がっていく昨今。

  • エンジニアの像としては、「サービスをつくることに長けている人」「コアな技術を生み出す人」「実装だけをメインとするエンジニアの人」に3つに体系化されていきそう。

  • いろんな像があるけれども、今まで500人くらいエンジニア新卒エンジニアとして採用してきて、エンジニアとして輝くために必要なことは「技術に対する興味関心」。

  • 今年は過去一の出来なので、お楽しみに!

技術にまつわる戦略思考

基調講演株式会社AppBrew代表取締役の深澤 雄太氏

内容

創業期

  • 創業前
    • フリーランス
    • フロントエンドからサーバーサイドの一通りのレイヤーはできるように
  • 創業したきっかけ
    • 社会にインパクト生み出せしたい
    • 自分の向き不向きを感じながら進めることに
  • 起業
    • ユーザーニーズを捉えて、技術でサービスを作る苦労を経験
    • LIPSは5つ目のプロダクト
  • 成長期
    • プロダクトを伸ばすためなら採用、ディレクター、開発、事業計画、資金調達…などなど
    • 技術力も大切だけど、選択や運用も大切
      • 個別に判断してもらえるように

エンジニアが成長するためには?

  • 経営視線を身につけること
  • なぜ必要?
    • 技術と経済発展は両輪で進んでいる
    • 片方かなくして成り立たない=技術だけでは足りない!
  • 経営者側に技術力も足りない?
    • 経営者に技術を伝えられる事業理解のあるエンジニアが足りない
    • グローバルでは技術のバックグラウンドを持った経営者が多めな印象

戦略的

  • 目的→課題設定→仮設検証 =方法論
    • 基礎的なことを高いレベルで継続することが大切
      • 現状把握して、課題を洗い出して、この課題を解決する方法を考えて、実装する

現状把握と課題抽出

  • できるだけ数値で客観的&多角的な把握を
    • 会社の目標や利益、滞在時間とかで考える
  • 乖離がなければ目標と時間軸を見直す
    • 目標の中に落とし込む

解決策を考える=仮設を立てる

  • ポイント
    • 自分のこだわり(特定の技術や機能)はできるだけなくす
    • 解決策として成立しているのか
    • コストパフォーマンスが最も良くなっているか
    • 効果は測定できるか

検証は大切

  • データリテラシーは基本
  • ポイント
    • 実際に数値が改善した
    • 本当に意味のある変化になったか(A/Bテストなどの方法論)
  • 仮説が外れたらどうするの?
    • 仮説を再設定
    • ひたすらこれを繰り返す

とはいえ、マッチョすぎない?

  • プロダクトの方針に決める立場になくても理解と意見を持つことが大切
  • ただ技術が好きなだけなんだけど
    • 技術も世の中のプロダクトも生み出せないと消えていく
    • 経済合理性を前提にどう生かしていくかが大切

より大きなインパクトを出すためのポイント

  • 技術の高度化に順応する
    • 1人でできることは多い
    • 特定の技術にこだわらず
    • 目標に向かった学習&運用
  • 環境を選ぶ
    • 自分の目標やキャリアに対して最適な場所を選び探すことが大切
    • エンジニアとして伸びそう
      • 成長性がある
      • 経営陣が理解
      • 風通しよく議論できる

まとめ

  • 技術より事業を動かせることが大事な局面もある
  • 事業理解ががあれば、必要なときは手や声を上げてみよう
  • 世の中、会社、自分をしっかりメタ認知し、腰が引けないよう積極的に動いていきましょう
  • リアルな課題を理解して、俯瞰的な視点を持てるとよさそう
  • 経営目線を理解し、よりよいエンジニアライフを!

感想

エンジニア×経営視点は大事だなって思っていたのですが、エンジニアは経営は考えなくてよいのでは?な話を聞く機会の方が多かったので、今回のお話で一意見として肯定して頂いた気がしました。(※決して否定されたことがあるわけではないです)
経営者も、エンジニアも、デザイナーもそれぞれの領域を尊重して歩み寄っていきたいです。

事業成長を加速させるフロントエンド改善のお話

ヘイ株式会社 STORES.jpの山下 功介氏

speakerdeck.com

ざっくり内容

  • フロントエンド改善での取り組みをいくつか紹介
    • Rails × AngularJS から Vue.js/Nuxt.jsに移行
    • 長い目で開発スピードを上げるためには基盤構築やルールが必要
      • 3ヶ月間で基盤構築を実行+2ヶ月で実装
    • 見えてきた複数の課題
      • UIコンポーネントのルール
        • Storybookの導入
      • レビュー環境の見直し
        • CircleCI×Lambda@Edgeで1プッシュで1URLを発行し、プレビュー環境を作成
      • テストの効率化
      • 既存とのUIをかんたんに比較できるように REG-SUITを導入
  • いろいろ解決していったけど、課題はたくさんあります

感想

土台がない状態で作り上げた環境を長い目でメンテナンスするシステムに置き換えるのもかんたんではないな、と感じました。 今回この話であったレビュー環境はとてもよさそうだなーと思ったのですが、自社に入れるにはどうしたらよいか思いつかず…。もっと勉強しないとですね。
登壇者の方は入社5日目にしてBCU30に登壇することを決めたとのことで、勇気と行動力に感服でした…!

大規模フロントエンドの技術的負債に戦う

サイボウズ株式会社の外松 俊尚氏

speakerdeck.com

ざっくり内容

  • サイボウズのKintoneプロダクトに関わるフロントエンドエンジニアの方のお話
    • 技術的負債と向き合うためにやってきたこと、なぜ技術的負債に向き合って、向き合ったことのメリットについて
      • チームで「開発系の改善」をテーマにワークショップ
        • ワークショップでわかったこと
          • 必ずしも皆が同じ感覚でいるわけじゃない
          • デファクトだから、は導入するきっかけにはならないので、なぜよいのか、の価値を伝える 必要がある
          • 開発に関するつらみ(課題)からツールを提案すると理解してもらいやすい
      • 最新技術を共有する勉強会を週に1回開催
  • 技術的負債は専門性を高めて時間をかけて向き合う必要がある
    • 小さな問題からコツコツと解決
    • モブプログラミングを活用

感想

自分も長年運用されているシステムを担当しているので、同じ悩みを抱える会社はあるんだなーと改めて思ったのと、小さな問題から片付けていく大切さを改めて実感しました。
社内で月に1度技術共有会をやっていて、学びが多いなーと感じているので、もっと小さな単位でライトに共有できる勉強会もよさそうだな、と思いました。

インフラエンジニアの為のソフトウェア開発手法入門

GMOインターネット株式会社の元内 柊也氏

speakerdeck.com

ざっくり内容

  • なぜ自動化が必要か?
    • 属人的に解決してたけど、そのままでうまくまわっていかない
      • ナレッジやオペレーションでかいけつ
        • SRE
        • noOps
  • なぜ良きコードが必要か?
    • 自動化したコードは作りたてが一番動く
      • 改修のために、解読して、運用する必要がある
        • これをうまくやるためには?
          • CleanCode
  • なぜアーキテクチャが必要か?
    • なにかをただ1度だけ動かすことは難しくない
      • インフラシステムは劣化していく
      • アーキテクチャを整える
        • システムを構築、保守するために必要な人材を最低限に抑えられる

感想

お仕事の領域がフロントエンドなので、内容がわからないかな?と思ったのですが、フロントでもインフラでも開発時に考えることや悩むポイント(設計ちゃんとやっとけばよかった)は同じなんだな、と思いました。
「料理は作りたてが美味しいようにコードも作りたてが一番動きます」という言葉がよい例えすぎたので、今後も引用させて頂きたいです。

東京という海と、コミュニティという島と、私

株式会社いい生活の平尾 元紀氏 speakerdeck.com

ざっくり内容

  • 社会人になるまで考えもしなかったところにいる
    • 今まで
      • 狭い視野で充実していた
    • 勉強会に参加して、コミニティに触れる
      • いろんなエンジニアがいることを理解
      • なりたいエンジニア像を見直し
    • 様々なコミュニティに参加
      • モチベーションが上がる
      • すごいひとがいるけど、自分がすごいひとかどうかは別なお話なので注意
    • 好きなものをやってるところに参加していこう
    • 東京という海に漂うだけでなく自分で島を回って成長していこう!

感想

もともと勉強会やカンファレンスの多さから東京にでたい!と思っていたので、社会人1年目は闇雲にいろんな勉強会に参加してたなーということを思い出しました。 
勉強会で人と話すことで、社内の悩みが意外とあるあるな悩みだと知れたり、いろおな考えを知れたり、学び多い時間が多いなと思います。
これからも成長のためにやっていきたいな、と思いました。

4歳からプログラミングに夢中な"テックキッズ"が開発したアプリ「今日の洋服何着てく?」の紹介

Tech Kids Schoolに通う澁谷 知希氏

内容

経歴

  • 4歳からプログラムにふれる
  • 今まで使ってきた言語
    • HTML/JavaScript/CSS
    • PHP
    • MySQL
    • Unity
    • C#(一番ややこしかった)

      朝、服が決められない小学生のために天気からおすすめの服装を提案するアプリ「今日の洋服何着てく?」を開発

  • 使い方
    • 郵便番号と性別を選ぶだけ
  • 頑張ったところ
    • 2D
    • APIを使って緯度経度を取得
      • 定期的に情報を取得
    • 熱中症予防のための水筒を表示するポイントの検討
  • こだわりポイント
    • UI
    • Unityで背景の設定

      今後の展望

  • GPSを取得して、アプリを立ち上げるだけで確認できるように
  • 服を登録して、コーディネートを提案

感想

「小学生エンジニア」として今回登壇されていたのですが、「小学生」ではなくて、本当に普通に「エンジニア」だな、と感じました。 自分の思う課題に対して、技術で応えることを自然にできてて本当にかっこいいな、と思いました。 彼らのような優秀なエンジニアと共存できるように、頑張っていこうと前向きになれました!元気をもらえましたー!

パラレルキャリアがもたらす相乗効果

ヘイ株式会社 Coineyの内立 良介氏

speakerdeck.com

ざっくり概要

  • パラレルキャリアってなに?
    • 将来への自己投資が目的
      • はじめやすくなった
    • エンジニアの幅を広げるためのキャリア
  • なぜ始めたのか
    • 前提
      • いまの会社で満足している
        • サービス目線で開発できるエンジニアが多い
        • テックとビジネスのバランスが取れている
    • キャリアの悩みがある
      • 転職したくないけど、スキルアップしたい
      • 複数の環境でキャリア積んじゃえ!
  • 各キャリアの相互作用も生み出せている
  • パラレルキャリアで身についたスキルもたくさん
  • 時間に追われることやコミュニケーションコストがかかるのはデメリット

    感想

    カンファレンススタッフもキャリアとして上げられていて、個人的には目からウロコでした。
    イベント運用は好きでやっていることですが、仕事でも趣味でもない宙ぶらりんだなーと個人的に思っていたので、「キャリアの1つ」として見る考えはとてもよいな、と思いました。

Atomic Components

フリーランスの翁 華宏氏のお話。

slides.com

ざっくり内容

  • 昨今話されている「AtomicDesign」って誤解があるのでは?という問題提唱のお話
    • フロントエンド界隈で「AtomicDesign」で解決しようとしている課題は「コンポーネントシステム設計」の話
    • 「AtomicDesign」は、「デザインシステム」であって、「コンポーネントシステム設計」を直接的に解決できるわけではない
    • 根本の考え方が違うため
  • フロントエンド界隈の課題を解決するには「Atomic Components inspired by Atomic Design」の方がよさそう
  • まとめ
    • ある考えから影響を受けた考えには別の名前をつけるべき
    • 現代のコンポーネントシステムを上手く乗りこなしていこう

感想

AtomiDesignの提唱者の方がデザイナーさんだったことやAtomicDesignが「デザインシステム」として提唱されていたことも知らなかったので、びっくりでした。 スライド内であった「molecules?」「Organization?」な会話は見に覚えがあって、笑ってしまいました。 解決したい根本が違えば、なんか合わないな、が発生するのは当然だなーと思いました。やっぱり原著や一次情報源を確認するって大事ですね。
今回話しにあった「Atomic Components」もちゃんと読んで、理解したいです。

エンジニアキャリアにおける焦燥感との向き合いかた

LINE株式会社/ElevenBackの花谷 拓磨氏

speakerdeck.com

ざっくり内容

  • 焦燥感
    • エンジニアのキャリアを考える上で重要
    • プラスにもマイナスにもなる
  • プラスになるとき
  • マイナスになるとき
    • 上の立場になったとき
        - 余裕がないリーダーって頼りたいと思えない
      
  • 正しい焦燥感
      - キャリアアップを目指す
      - キャリアチェンジしたい
    

    今、どちらにいますか?

感想

資料も内容も盛りだくさんなのですが、すっと入ってくる内容でした。
「今、どちらにいますか?」という問いかけだったので、自分なりに考えてみると今は「キャリアアップ」を考える時期だな、と思いました。
エンジニア経験が長いひとたちに囲まれているので、 一足飛びには何事もできるようにならないので、コツコツと頑張っていこうと思います。

30代のキャリアを意識した20代のキャリア戦略

サイボウズ株式会社の向井 咲人氏のお話。

speakerdeck.com

ざっくり内容

  • こんな経験ありませんか?
    • 3年後、5年後どうなっていたいとか聞かれたり、将来への投資したらいいよ、とか言われる
  • 正直、5年後、1年後すら不明確
    • 使っている技術もデバイスも違うし、会社の状況や働き方だって変わる
  • どうすればいいの?→あえて30代を予測しない
    • 会社依存ではなくて、個人にフォーカスした時代がくる
    • 個人のちからを磨き、不確定な未来を対応していこう
  • 不確定な未来に向けて土台を作る
    • 経験を掛け合わせよう
    • そのための戦略
  • 好きなこと、ワクワクすることに素直になって、未来に向けて楽しんでいこう

感想

「不確定な未来に向けて土台を作る」という目標を持って、将来へ確実に向かっていく考えが素敵だな、と思いました。 登壇者の方が 「Y社の前取締役の方が「自分株式会社を常に運用していこう」とおっしゃってて、そのとおりだと感じた」とお話を聞いて、私も確かにそうだな、と感じました。
自分をドライブできるのは自分だけですもんね!

サービスメッシュを導入してよかった話

株式会社サイバーエージェントの江頭 宏亮氏のお話。

内容

インフラ

  • マイクロサービスのアンバサダーパターンを採用
  • アンバサダーパターン
    • Envoyのプロキシを採用
      • 昨今ではIstioが話題だが、 2018年4月にはあまり知見がなかった
    • 目的

感想

「サービスメッシュってよくわからないけど、おもしろそう」ベースで参加。 知らない言葉や用語が多くて、理解力が乏しくメを断念…。インフラの知識が乏しすぎます…。 周りの方々はよさそう!とおっしゃっていたので、よいんだなーと感じました。

「グノシー」の新規サービス事情

株式会社Gunosyの山本 舜氏

内容

グノシースポーツ

  • スポーツ特価版
    • 好きなチームの情報をリアルタイムに届けるサービス
    • リコメンドとかいろんな機能があるよ

      新規事業のあるある

  • プロダクトの本質的な改善に時間をかけたくない

    AppSync

  • よさ
    • コード無しでクエリが掛ける
    • フルマネージドGraphQLサービス

      やりかた

  • リアルタイム更新
    • サーバーサイド
      • だけで技術がいろいろ必要そう
      • 負荷試験
      • 同時接続大変
    • アプリサイド
      • 接続不良時どうするよ的な問題もあり
    • AppSync+リアルタイム更新
      • Webソケットの部分

        つらみ

    • APIの仕様と実際のレスポンスとずれている
    • リアルタイムデータのスキーマの共有大変
    • スキーマファースト
      • スキーマ定義 → データスースとの結合の流れしかできない
        • この流れしか作れないのでむしろ便利
    • 複雑なデータ構造
      • RESTだと辛いネストデータ
        • エンドポイントでいろいろ考えられるよね
    • フロントエンドが必要な情報を選択可能
      • UIの細かい改善をフロントだけで完結できる

感想

AppSyncを知らなかったのですが、「フロントエンドが必要な情報を選択可能」で「 UIの細かい改善をフロントだけで完結できる」点はとても魅力的だなーと感じました!技術面白い。

全体の感想

同世代のエンジニアの方の登壇を1日でぎゅっと聞けて、学び多い一日でした。 懇親会でも同世代エンジニアと交流ができて、刺激をもらえました! なりたいエンジニア像に近づけるようやっていきます!
来年は登壇したいので、とりあえず登壇者応募します!(何を登壇するかは考えていませんが…)

おまけ

スポンサーブースでTシャツやパン、お菓子を頂き、最後の懇親会の抽選会で本をいただきました✨
勉強します…!

f:id:matsumana07384:20190710001834j:plain