Hatena Engineer Seminar #18 仕事を通して身につけるはてなエンジニアの振る舞い

by kasu

Slide 1

Slide 1 text

仕事を通して身につける  はてなエンジニアの振る舞い  id: ergofriend Hatena Engineer Seminar #18 2022-01-26

Slide 2

Slide 2 text

はてなのエンジニアは  どのような日々を過ごしてるの？  この発表で伝えたいこと  Hatena Engineer Seminar #18

Slide 3

Slide 3 text

Outline 1. 自己紹介  a. だれ？  b. 入社時のスキルセット  2. はてなでの仕事  a. 新規プロジェクト配属時はどんな環境だったか  b. 仕事でやったこと５選！  3. まとめ  a. はてなの評価とエンジニアバリューズ  b. はてなエンジニアの日々とは 

Slide 4

Slide 4 text

id:ergofriend ● はてなID  ○ id:ergofriend  ● はてな歴  ○ 2019年サマーインターン  ■ ブログチーム  ○ 2021年新卒入社  ■ WEBアプリケーションエンジニア 

Slide 5

Slide 5 text

● ベンチャーのアルバイトでフロントエンドを担当  ○ UI実装や機能実装  ● サービスとして世に出す為の知識はなかった  ○ 運用、WEB配信、セキュリティなど  ● 開発規範への意識  ○ PRで実装やコメント不足についてよく指摘された  id:ergofriend > 入社以前の経験 

Slide 6

Slide 6 text

Work ● 配属チーム  ○ 新規共同開発案件   ○ フルタイムエンジニアが新卒2人  ○ シニアの24時間サポート付き  ● 技術スタック  ○ 社内でデファクトとなりつつあり知見があったものに決定  TypeScript

Slide 7

Slide 7 text

Work > 1.技術選定  開発がスタート。  要件にある機能は...  ● 状態管理したい  ● グラフを描画したい  ● アニメーションをしたい  ● 画面スワイプのジェスチャーで操作したい  ライブラリを選ぶには  

Slide 8

Slide 8 text

Work > 1.技術選定  ライブラリを選ぶときに考えたこと  ● 型が提供されているか   ● 機能要件・非機能要件を満たせるか  ○ 機能が同じなら、インターフェースの使い勝手を比較  ● 運用に支障がないか  ○ メンテ、サイズ、ライセンス  ライブラリを選ぶには  

Slide 9

Slide 9 text

１年程経ったが....技術選定の経過はいかに？  ● 今のところうまくいっている  ○ アップデートを問題なく行えている  ○ 開発に影響のあるライブラリは選ばずに済んだ  ● 選べなかったライブラリもある  ○ Tooltipを自前で実装した    Work > 1.技術選定  ライブラリを選ぶには  

Slide 10

Slide 10 text

まとめ  ● 流行っているからこれにしよう。は出来ない！  ● 要件を満たすものがない場合は自前で実装することも  ● サービスへの影響を考慮する  ○ 数年間に渡るメンテを考慮する必要がある  ○ ライセンスによってはコードを公開する必要がある    Work > 1.技術選定  ライブラリを選ぶには  

Slide 11

Slide 11 text

Work > 2.ペアプロ  使うライブラリを決めたら実装がスタート。  ● フルタイムの新卒エンジニア２人  ○ シニアエンジニアの24時間サポート付き  ● コードは０行  ● お互いにgit initするわけにもいかない  ● ペアプロという手段 

Slide 12

Slide 12 text

Work > 2.ペアプロ  ペアプロとは  ● ドライバーとナビゲーター  ○ 実装者とレビュワー  ● ドライバー  ○ 機能の実装に集中  ● ナビゲーター  ○ レビュー  ○ 議論の先導 

Slide 13

Slide 13 text

Work > 2.ペアプロ  ペアプロしたことで...  ● 実装の進め方を会話しながらやった  ○ その後、分担しやすかった  ● 知見を盗むことが出来た  ○ 実装の進め方やタスクの整理方法など  ● タスクの取り組み方を共有できる  ○ やり方に対してフィードバックがもらえる 

Slide 14

Slide 14 text

Work > 3.実装とレビュー  ペアプロの後は、タスクを１人で担当し始める。  しかし...  ● 機能盛りだくさんコンポーネント  ● 思い込みによる要件の勘違い  ● タイプミス・実装ミス 

Slide 15

Slide 15 text

Work > 3.実装とレビュー  そんな実装のままレビューに出すと...    ● 最後に確認していた仕様と変わっていた  ● PRの説明にタスクの背景や問題を記載していない  ● 仕様が複雑な箇所に注釈をつけていない  ● データ処理の見落としによる実装漏れ  49

Slide 16

Slide 16 text

Work > 3.実装とレビュー  レビューが盛り上がり過ぎないために...  ● レビューされることを意識した実装  ○ コメント  ○ 適度なカプセル化  ● セルフレビュー  ● PRの説明を丁寧に用意する 

Slide 17

Slide 17 text

Work > 4.日々の暮らし方  黙々と実装 -> レビューの繰り返しではない...  ● 日々の仕事を続けるなかでやるようになったこと  ○ 日記やタスク毎のページをScrapboxに記録していく  ○ 仕様の整理やタスクの分解、疑問点の洗い出し  ● チームの目が止まる場所で記録を残す  ○ Scrapboxの更新がSlackで流れるようにしている 

Slide 18

Slide 18 text

Work > 5.コミュニケーション  日々の暮らしでアウトプットしていると...  ● Scrapboxの更新はSlackに流れる  ● チームメイトが反応してくれる  ● コミュニケーションが起きる 

Slide 19

Slide 19 text

Work > 5.コミュニケーション  たとえば、どんなコミュニケーションが起きるのか？  ● 仕様やデザインツールで表していない状態の確認  ○ UIの選択・未選択などのデザインはどんな感じ？  ● デザインツールで表現出来ない「動き」  ○ UIアニメーションはどう動くといい？  ● チームの中で議論のきっかけになる   

Slide 20

Slide 20 text

Work > 5.コミュニケーション  共同開発というのはパートナーがいる。  パートナーさんとのコミュニケーションも発生する。  ● 我々がフロントエンド・パートナーさんがバックエンド  ● フロントエンドから叩くAPIのデータを変えてほしい  ○ こうして欲しい。だけではダメ   ○ 背景や理由を伝える   ○ 要求ではなくコミュニケーションをする。 

Slide 21

Slide 21 text

Summary 仕事では以上のようなことを経験して、  こんなに学びました！  と、終わる前に...  学んだことを振り返り、身につける手段として  はてなには、「評価」がある 

Slide 22

Slide 22 text

Summary > エンジニアバリューズはてなにはエンジニアバリューズというものがある。  1. プロダクト志向  2. コラボレーション  3. おもしろさ  4. 学びとオープンネス  https://hatenacorp.jp/recruit/engineer/values 

Slide 23

Slide 23 text

Summary > エンジニアバリューズ高品質なプロダクトを通じてユーザーやコミュニティの幸福を実現すること

Slide 24

Slide 24 text

Summary > エンジニアバリューズ独りでは出せないアウトプットをチームとして出していくこと

Slide 25

Slide 25 text

Summary > エンジニアバリューズ新しい体験を生みだす「おもしろさ」を原動力として革新を目指していくこと

Slide 26

Slide 26 text

Summary > エンジニアバリューズオープンな態度とフィードバックを通じて成長しつづけていくこと

Slide 27

Slide 27 text

Summary > 評価エンジニアの評価で見ること  1. プロダクト志向  ○ チームやプロダクトの課題を解決できる  2. コラボレーション  ○ 他者との協力を通じて、成果をあげる  3. おもしろさ  ○ 挑戦や変化を通じて、「新しい体験」を知る  4. 学びとオープンネス  ○ 体系的な知識の獲得とそれを他者へ伝える 

Slide 28

Slide 28 text

Summary > 評価評価が上がるごとに  求められる役割が大きくなる  1. プロダクト志向  2. コラボレーション  3. おもしろさ  4. 学びとオープンネス  チーム  個人  評価  低い  高い  会社  業界  役割  小さい  大きい 

Slide 29

Slide 29 text

Summary > 評価個人からチームへ変わる場合は?  1. プロダクト志向  ○ 自分の課題を解決できる　=> チームの課題を解決できる  2. コラボレーション  ○ チームメンバーと協力して課題を解決できる => チームを引っ張って課題を解決できる  3. おもしろさ  ○ 自分で新しい分野を学んでいく=> 学んだことをチームの成果に繋げられる  4. 学びとオープンネス  ○ 仕事に必要なことを学んでいる => 体系的な知識を一般化してアウトプットできる 

Slide 30

Slide 30 text

Summary > 評価評価は年２回、1月と7月にある。  ● なにが良いのか？  ○ 多角的・客観的にみてもらえる  ○ 改善点が分かる  ■ 次の評価を目標にして直すことが出来る  ● 学んだことを振り返り、身につける仕組み 

Slide 31

Slide 31 text

Summary > 評価どんなフィードバックを貰えるのか？  ● プロダクト志向  ○ より良い実装方針についてデザインパターンを学んでみては  ● コラボレーション  ○ 開発合宿DXなどの社内イベントに積極的に参加していて良かった  ● おもしろさ  ○ ライブラリのアプデ対応も果敢に調査・実装修正を行っていたのがよかった  ● 学びとオープンネス  ○ タスクの過程をScrapboxに記録してくれるのはありがたい 

Slide 32

Slide 32 text

Summary > 評価 PDCAの結果は？  ● タスクのコントロール精度が上がった  ○ 仕様の確認、見積もり、撤退判断  ● コミュニケーションをとる  ○ 仕様や疑問点を議論の俎上にあげていく  ● プロダクトを良く保つ  ○ ライブラリのアプデ、コーディング規約の導入 

Slide 33

Slide 33 text

Summary はてなのエンジニアとして仕事をするということ  ● 機能を実装することは大切  ● もちろんそれだけではダメ  ○ タスクをコントロールする  ○ コミュニケーションをとる  ○ プロダクトを良く保つ 

Slide 34

Slide 34 text