_dip_ユーザーに価値を届けるための_コードレビュー___サービスレビュー_ワークショップ_.pdf

Transcript

2. 田中 雄登
 Tanaka Yuto 
 ディップ株式会社 
 ・CTO室 DevRelユニットリーダー 
 ・採用オウンドメディア dip people 編集長 
 1. 約30カ国でリサーチ活動 
 2. 全15職種の新卒採用を経験 
 3. エンジニアにも挑戦中 
 私のキーワード
 プロダクト組織のDevRelとして 
 人事領域の戦略から広報まで横断的に担当 
 

3. 松田 知也
 Matsuda Tomoya 
 ディップ株式会社
 ソリューション開発本部 プロダクト開発統括部 
 バイトルエンジニアリング部 Web課 
 1. デザイン大好き 
 2. Claude Code / NotebookLMと仕事 
 3. ボードゲーム・ガジェット 
 私のキーワード
 25新卒のフロントエンドエンジニア 
 PO・デザイナーと共にバイトルの企画から開発までを 担当している。 

4. 20年以上続く⼤規模開発の知⾒を あまてくのみなさんに今⽇は還元します 期待値
5. × “誰もが働く喜びと幸せを感じられる社会” Labor force solution company VISION Human work force solution ユーザーファーストな独⾃機能を搭載した、 求⼈情報‧⼈材紹介サービスの提供を通じて、 ユーザーの就業課題を解決しています。 ⼈材サービス事業 Digital labor force solution バイトコミュニケーションアプリ『バイトルトーク』や、 機能を絞ったシンプルなSaaS型の『コボット』を通じて、 職場環境やコミュニケーション課題を解決しています。 DX事業
6. Copyright © DIP Corporation, All rights reserved. 採⽤、定着、ブランディングまで 労働課題のトータルソリューションを実現
7. Copyright © DIP Corporation, All rights reserved. Code Review コードレビュー講座 動くコードから読めるコードへ
8. 個⼈開発をしていてこんな経験ありませんでしたか？ • 1ヶ⽉前の⾃分が書いたコードを開いてみたら、 「え、これ誰が書いたん…？」ってなる瞬間 • この関数、何するやつだっけ？ • 機能を追加したら別のところが壊れた 👉 今⽇のテーマは、このつまずきポイントを減らすコードレビューの話です。
9. コードレビューとは • 他の開発者が書いたコードをチェックし、品質‧保守性‧セキュリ ティーなどを⾼めるためのプロセスです。 • 全てを⼀気にレビューするのではなく、機能単位で区切って実装が 完了したら、PRを出してレビューしてもらいます。
10. なぜコードレビューが必要か • ⾃分では気づけないバグを早期に⾒つけられる ◦ 書いた本⼈は正しく動く前提で読んでしまう • 誰もが読みやすく、変更しやすいコードになる ◦ ⾃分では気づけなかった 読みにくさを指摘してもらえる • 知識の共有‧スキルアップにつながる ◦ 「他の⼈が何を⼤切にしてコードを書いているのか」を知ることができる
11. いいコードの書き⽅ • DRY原則：Don’t Repeat Your Self（繰り返すな）
12. いいコードの書き⽅ • DRY原則：Don’t Repeat Your Self（繰り返すな） 同じ処理はまとめることで保守性が上がる
13. いいコードの書き⽅ • DRY原則：Don’t Repeat Your Self（繰り返すな）
14. いいコードの書き⽅ • DRY原則：Don’t Repeat Your Self（繰り返すな） メッセージの編集は課⾦しているユーザーのみ変更ができるようにしたい 👉 拡張するような要件が出てきた時に共通化しすぎると⼤変 1つの関数には1つの責任にすることで保守性、可読性が上がる
15. いいコードの書き⽅ • 命名規則を決めておく • プロジェクトにあったディレクトリ構成 • スタイリングの書き⽅ • 変更しても、他の部分に影響が最⼩限で済むように疎結合な構成 コーディング規約としてまとめる
16. Copyright © DIP Corporation, All rights reserved. Code Review → Service Review サービス視点のレビュー 『正しく作る』の前に、『正しいもの』を作ろう
17. なぜ「サービス」を⾒るのか ⾃分が作ったその機能、 誰がいつ使うか 即答できる？ ユーザーの価値を考えるのが サービスレビュー です。 陥りがちな罠 技術（Code）に没頭すると、ついつい 「実装できるから実装した」になりがち dipの現場 「本当にユーザーのためになる？」 という議論が毎⽇⾏われている
18. お客さんが欲しいものは？ あなたはホームセンターの店員です。 お客様が「6mmのドリルが欲しい」と来店されました。 さて、そのお客様が 「本当に」欲しいものは 何でしょうか？
19. 正解は... ドリルの機能よりも、 ⽳を何に使うか（価値）を⾒るのが重要 客が欲しいのは「ドリル」ではなく「⽳」 顧客はドリル（⼿段）が欲しいのではない。 ⽳（⽬的）が欲しいのだ。 ドリル ＝ ⼿段 機能‧スペック‧回転数 ⽳ ＝ ⽬的 課題解決‧提供価値 Code Reviewの領域（正しく作れているか） Service Reviewの領域（価値を届けているか）
20. コードレビューとサービスレビュー 「正しく作る」と「正しいものを作る」の違い Code Review How（どう作るか） Service Review What / Why（何を、なぜ） ‧仕様通りに動くか？ ‧バグはないか？ ‧可読性‧保守性は⾼いか？ ‧ユーザーの課題解決になるか？ ‧使いやすいかUI/UXか？ ‧使いたくなる価値があるか？
21. Copyright © DIP Corporation, All rights reserved. 3つのレンズで サービスを⾒てみる 「開発者の視点」から「ユーザーの視点」にスイッチしよう
22. 観点①：Who & Why (誰の‧何の課題か) その機能、誰がいつ使うか即答できる？ アクション：「機能」ではなく「価値」を語る NG: 機能ベース 「検索機能をつけました」 「ログイン機能を実装しました」 主語が開発者 OK: 課題ベース 「『学校帰りに働きたい学⽣』のために、 『現在地から探す機能』をつけました」 主語がユーザー
23. 観点②：First Impact (初⾒の違和感) 開発者の⽬はユーザーとは違う ⾃分たちは仕様を知っているから「使いにくい」ことに気づけない。 チェックポイント アクション：初めて⾒る⼈になりきって触る 説明書なしで操作できる？ 専⾨⽤語が出ていない？ ボタンは押せそう？ 迷⼦になっても戻れる？
24. 観点③：Story (体験の流れ) アクション：⼀連の流れ（シナリオ）を通して触ってみる 点は良くても、線になっていないことがある。 ユーザーの感情の流れ（シナリオ）を確認しよう。 何のアプリかわかる前に 「会員登録」を迫っていない？ 操作中に迷わない？ ⾏き⽌まりになっていない？ 課題は解決された？ 「また使いたい」と思える？ 出会い アクション ハッピーエンド
25. User First dip流‧プロのレビュー視点 「実装が⼤変だから」「技術的に難しいから」 それは作り⼿の都合。ユーザーには関係ありません。 ユーザーにとってのベストを諦めないのがプロです。 レビューの合⾔葉 それでユーザーはどう嬉しいの？
26. 本⽇のまとめ：3つのアクション 価値を語る 「機能」ではなく、ユー ザーにとっての「価値」を 語ろう 初⾒プレイ 開発者の記憶を消して、 「初めて⾒る⼈」になりき ろう シナリオ体験 点ではなく線で。 ⼀連の流れ（ストーリー） を通そう それでユーザーはどう嬉しいの？ を常に問いかけよう
27. Copyright © DIP Corporation, All rights reserved. Code Review → Service Review サービス視点のレビュー 『正しく作る』の前に、『正しいもの』を作ろう
28. アンケート