Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

チームで「きちんと」Laravel を使っていくための取り組み

749 views

Published on

2018/03/14 開催の「【 ヒカ☆ラボ 】【Laravel5、CakePHP3など】ベンチャー企業のリアルなPHP事情」の資料です。

https://atnd.org/events/95005

Published in: Software
  • Be the first to comment

チームで「きちんと」Laravel を使っていくための取り組み

  1. 1. チームで「きちんと」 Laravel を使っていくための 取り組み 【ヒカ☆ラボ】ベンチャー企業のリアルな PHP 事情
  2. 2. 岡田 正平(おかだ しょうへい)@okashoi • 株式会社ウィルゲート 2015年新卒入社 • 開発室 ソリューションユニット 所属 • PHP, Laravel, Vue.js • 資料は後ほど公開します 2 自己紹介 Slides:
  3. 3. 3 株式会社ウィルゲート
  4. 4. 4 株式会社ウィルゲート
  5. 5. 5 株式会社ウィルゲート
  6. 6. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 6 チームで「きちんと」Laravel を使っていくための取り組み
  7. 7. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 7 チームで「きちんと」Laravel を使っていくための取り組み
  8. 8. • 2017年4月から新規プロダクトの開発がはじまる(Laravel) • web コンサルティングのノウハウをシステム化 • 以降、新しくチームに受け入れた人数 = 5名 • Laravel 未経験者が多い(新卒、業務委託) • チーム内で Laravel に関する理解がもっとも深いのが私 8 背景 | チームの状況
  9. 9. • Laravel は「設計を自力でできないと道に迷ってしまいがち」 9 背景 | Laravel の特徴 ※スライド「PHP 2大 web フレームワークの徹底比較!」より
  10. 10. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 10 チームで「きちんと」Laravel を使っていくための取り組み
  11. 11. 前提: 「きちんと」使う ≠ 全ての機能を使いこなしている • 時として「使う必要がない」「チームでの運用は難しい」 という判断もする • 「使ったほうがいい」と思えば使う 使うからにはチームみんなが理解し、使える状態を目指す 11 解決したい課題 | 前提
  12. 12. 12 解決したい課題 使いたい機能 使わない機能 理解していない 理解している
  13. 13. 13 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供している 機能全体
  14. 14. 14 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供していて 「きちんと」 使えている機能
  15. 15. 15 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能
  16. 16. 16 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 悲しみ のもと • 誤った使い方 • 車輪の再発明 → バグ混入の可能性・メンテコストの増加
  17. 17. 17 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能 時間の経過とともにシステムの開発は進む →「使いたい機能」の領域が広がる
  18. 18. 18 解決したい課題 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能 生まれゆく 悲しみ を減らすために 「チームで」理解している範囲を拡大していきたい
  19. 19. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 19 チームで「きちんと」Laravel を使っていくための取り組み
  20. 20. • ドキュメントの整備 • 実装前の方針すり合わせ(設計レビュー) • 「コーディングに関する相談会」の定期実施 20 やったこと
  21. 21. • 「Laravel のお作法」や「コーディング規約」 あるいは「設計のベストプラクティス」のようなものまで • 必要に応じてチームメンバーが参照できる状態にする 21 やったこと | ドキュメントの整備
  22. 22. • 「ガイドライン」と称した具体的なコード例も準備 • 同一のリポジトリ内に作成(開発環境のみで実際に動く) • ガイドライン作成のプルリク自体がドキュメントにもなる 22 やったこと | ドキュメントの整備
  23. 23. • 実装を始める前に所定のフォーマットで実装方針をまとめる • まとめた実装方針をもとに 所定のレビュワーがレビューし方針をすり合わせる • Laravel が提供している機能で実現できないか? • 提供されている機能を正しく使えているか? 23 やったこと | 実装前の方針すり合わせ(設計レビュー)
  24. 24. 24 やったこと | 実装前の方針すり合わせ(設計レビュー) ※Notifications を活用する例 半分以上伏せてますが……
  25. 25. • 週に1回30分 チームメンバー全員参加(他のチームの人も参加OK) • コーディングについてなんでも(Laravel に限らず)相談できる • 「ここどうしたらいいですか?」 • 「こんな記事を見つけたんですが、どう思います?」 など • コーディングに関する意識のすりあわせ・ノウハウ共有が目的 • 他人に対する批判はナシ(お互いに注意する) ✕「こんなことも知らないの?」 ✕「その考え方はダメ」 25 やったこと |「コーディングに関する相談会」の定期実施
  26. 26. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 26 チームで「きちんと」Laravel を使っていくための取り組み
  27. 27. • チームで初めて使う Laravel の機能や、新しく始めることの 導入がしやすくなった • テストコードや Laravel Mix 導入など • 生まれそうな 悲しみ を未然に防げるようになった • チームメンバー間で「良いコード」について会話するようになった • 作業中にも「ここの実装って~」というような 会話が生じるようになった ➢ 「良いコード」を意識するようになれば Laravel が提供する機能に目が向いていくはず(……という期待) 27 良かったこと
  28. 28. • プルリクのレビューの負担が減った • 実装方針のすり合わせができているので フィードバック→修正 のサイクルが減った • 副次効果として「プルリクを細かく分けて出す」風潮を作り出せた • レビューのタイミングですり合わせる • コーディングに関する相談会に他のチームの人も参加可能にしたこと • 他チームのノウハウ・観点を知ることができる 28 良かったこと
  29. 29. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 29 チームで「きちんと」Laravel を使っていくための取り組み
  30. 30. • 新しく入ったメンバーに全ドキュメントを目を通してもらう必要はない • 現実的にそれができる量ではなくなった • 「最初に最低限目を通してもらうもの」は選出する必要 • 設計レビュワー(1人)の負担が思ったより大きかった • プルリクレビューの負担軽減を相殺して足が出るくらい • 実装者が方針を修正するタイミングが早まったので チームとしてはプラス • ただし、ここがボトルネックになってしまうこともあった • 「自分のレビューは正しいのか?」という終わらない問い 30 学んだこと
  31. 31. アジェンダ • 背景 • 解決したい課題 • やったこと • 良かったこと • 学んだこと • 今後の展望 31 チームで「きちんと」Laravel を使っていくための取り組み
  32. 32. • すでに生まれてしまった 悲しみ の救済 • 規約・ドキュメントを更新していく仕組みづくり • レビュワーの育成 32 今後の展望
  33. 33. • すでに生まれてしまった 悲しみ の救済 • 規約・ドキュメントを更新していく仕組みづくり • レビュワーの育成 33 今後の展望
  34. 34. 34 今後の展望 | すでに生まれてしまった悲しみの救済 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能 (これまで)生まれゆく 悲しみ を減らすために 「チームで」理解している範囲を拡大していく仕組みを作った
  35. 35. 35 今後の展望 | すでに生まれてしまった悲しみの救済 使いたい機能 使わない機能 理解していない 理解している Laravel が提供しているが 理解不足のために 使えていない機能 Laravel が提供していて 「きちんと」 使えている機能
  36. 36. 例)独自実装になってしまった認可機構 • 実装が開放閉鎖原則に反していてる ← 悲しみ ➢ Laravel が提供している Gate, Policy に置き換える 36 今後の展望 | すでに生まれてしまった悲しみの救済
  37. 37. • すでに生まれてしまった 悲しみ の救済 • 規約・ドキュメントを更新していく仕組みづくり • レビュワーの育成 37 今後の展望
  38. 38. レビュワーの負担を分散・ボトルネック解消のために やっていること1 • 実装や設計の参考になる記事を読ませて、感想・意見・疑問を聞く • 「良いコード」に関するより深い対話 • SOLID 原則 • 驚き最小の原則 など • それらのために Laravel はどのような機能を提供してるのか? 38 今後の展望 | レビュワーの育成
  39. 39. やっていること2 • レビューの際に自発的に考えさせるコミュニケーションを取る • 「こうした方がいい」ではなく「どうしたらいいだろう?」と問う • 「自己説得」(=自分で理解した状況)は行動の変化が発生しやすい 参考) 39 今後の展望 | レビュワーの育成 Chapter 2 メンタリングの技術
  40. 40. 「きちんと」Laravel を 使っていくための 戦いはまだまだ続く (‘ω’ )
  41. 41. 一緒に働くメンバーを募集しています!

×