先輩エンジニアとの差が埋まらないのは設計力が足りないと感じた話​ / The difference with senior engineers is system design ability

2024年5月10日
DevLOVE関西 あまり発表したことないエンジニアのみなさん、登壇してみません？
https://devlove-kansai.doorkeeper.jp/events/171858

Transcript

1. 先輩エンジニアとの差が埋まらない のは設計⼒が⾜りないと感じた話 発表⽇︓2024年5⽉10⽇
2. 未経験からコードを書く⼒・読む⼒をつけて できることが少しずつ増えてきた
3. ただまだ先輩エンジニアとの ⼤きな差を感じている
4. 同じチームの先輩エンジニア あともう少しだけど 何かが⾜りない その⼀歩が遠い
5. 登場⼈物の多いWeb API開発に挑戦 ↓ 20H予定の開発で60Hかかってしまった
6. 先輩エンジニアとの差 ↓ 設計をして、複雑なものを⼿戻りなく 作り切ることができない
7. なぜ今回のWeb API開発でこのような課題を 感じたか︖
8. 太⽥奎祐 株式会社PLAN-B 新卒で⼊社してエンジニア3年⽬ バックエンドの開発を担当 今年から運⽤にも挑戦中 北海道→神奈川→静岡→⼤阪と どんどん⻄に進⾏中
9. こんなプロダクトを作っています • 戦略設計から施策ふりかえり までをオールインワンで⾏う ことができるSEOツール • スクラムで開発 • 1週間1スプリント • 2024年に250スプリント突破
10. この発表のゴール 設計⼒ってどうやったら⾝につけられるの︖ どうやったら開発を前に進められるの︖ 皆さんから学びたい
11. みなさんはエンジニア初⼼者のころ 開発を予定通り進められていましたか??
12. 僕がエンジニアになって 常に感じてきたこと
13. 開発とても時間がかかる・・・ ⾒積もりが全然あわない
14. ふりかえりのサイズ感⾒直しにて・・・ この開発は 8hに対して、20h ⾒積もりの⾒直しは必要か︖ 必要ないです 僕の⼒不⾜です…
15. ふりかえりのサイズ感⾒直しにて・・・ この開発は 8hに対して、20h ⾒積もりの⾒直しは必要か︖ 必要ないです 僕の⼒不⾜です… 毎週のふりかえりで「うっ」となる… なぜこんなに時間がかかってしまうんだ…
16. ただ少しずつ改善をして良くなってきた 何を作るのかイメージ をしっかり合わせる タスクを⾒積るときに 細かく分ける 開発時の調査のコード の読み⽅を⼯夫する 開発中も途中確認を ⼊れる MTGでどの開発も⾃分が するつもりで挑む 家でとにかく 作ってみる
17. 初めて複雑なWeb API開発に挑戦 これまでの経験から ⾃信あるぞ︕
18. いままで作ってきたWeb API(例)
19. いままで作ってきたWeb API(例) シンプルなCRUD処理
20. Web APIのINとOUTさえしっかり決めておけば あとは作りながら何とでもなった
21. 開発の前に少しSEOの話 • Google検索で上に来るために は⾃社の記事をリライトする ことが⼤切 • 情報を網羅する • 良く検索されるキーワードを記 事にいれる • 書いたあとに記事の改善を⾏ うことは⼤切
22. 今回開発したWeb APIって何をするの︖ Web API SEARCH WRITEが持っているデータを⽣成AIに渡す 記事の改善案を教えてもらう
23. AWS DynamoDB AWS Lambda AWS S3
24. AWS DynamoDB AWS Lambda AWS S3 多くのサービスやWeb APIと通信を⾏い、 データの変換や保存などが⼊る
25. Web APIのINとOUTは事前に決定
26. まず⾏ったこと • 流れを整理するため、クラスを整理する • そのうえでどこから作るかを先輩に相談
28. 当初の僕の⾒積もりより登場⼈物が多かった クラスをすべて書き出して1つずつ⾒積もり
29. 記事のデータを取得する部分から実装 • 外部Web APIを呼び出して、対象の記事の情報を受け取るデー タ取得部分から作りました Repository Service 記事のデータを取得する 外部Web API
30. 実装完了 • 今までの経験から⼤きくハマる事もなく実装できた • エラーハンドリングに⼀部困って仕様確認などはあったが
31. 記事のデータを取得する ビジネスロジック実装 • データ取得ロジックに記事のデータを渡してデータの取得をし ていくためのビジネスロジックを実装 Repository Service 記事のデータを取得する 外部 Web API
32. あれって思った
33. 実装であれって思ったこと① • ビジネスロジックでどうデータ取得のロジックを呼び出すの︖ どういう形でデータを送るの?? • おそらくこういう形で使われるだろうというイメージでデータ取得ク ラスを作ってしまった Repository Service 記事のデータを取得する AWS Lambda
34. 実装であれって思ったこと① • ビジネスロジックでどうデータ取得のロジックを呼び出すの︖ どういう形でデータを送るの?? • おそらくこういう形で使われるだろうというイメージでデータ取得ク ラスを作ってしまった Repository Service 記事のデータを取得する AWS Lambda ビジネスロジックや更に上の階層でどう処理を呼び出し ていくのか、イメージできていない クラス同⼠のINとOUTが合わない
35. 実装であれって思ったこと② • データを取得できなかったケースをビジネスロジックはどう判 別する︖ • 記事のデータを取得できなかった場合は • できなかったことをビジネスロジックで判別したい • ただ処理は継続する
36. 実装であれって思ったこと② • 外部APIは記事のデータと取得できたかどうかの判定情報も返す • 外部APIから返された判定情報でビジネスロジックで判別しようかと漠 然と考えていた Repository Service 記事のデータを取得する 外部 Web API
37. 実装であれって思ったこと② • ビジネスロジックは「記事の情報取得できた・できなかった」 にしか関⼼がない • そのため記事情報が空だったら、取得できなかったと判別できる
38. 実装であれって思ったこと② • ビジネスロジックは「記事の情報取得できた・できなかった」 にしか関⼼がない • そのため記事情報が空だったら、取得できなかったと判別できる ビジネスロジックで必要な判定をどう⾏うか そのためどういうデータ設計にする必要があるか イメージできていない
39. ⼿戻り発⽣… 受け渡しの オブジェクト修正 ビジネスロジック 修正 単体テスト修正 データ取得 ロジック修正
40. 受け渡しの オブジェクト修正 データ取得 ロジック修正 ⼿戻り発⽣… ビジネスロジック 修正 単体テスト修正 どれも防ぐことができたの ではないか︖
41. ⼿戻りの連続でスプリントゴールを 2週連続で落としてしまう
42. ある⽇の夜 作るときは紙に書いて必ず設計して 作っているよ 太⽥くんは開発するときに作る物の イメージがしっかりできているの︖ APIのINとOUTは決めています ただそれ以上は・・・
43. ある⽇の夜 作るときは紙に書いて必ず設計して 作っているよ 太田くんは開発するときに作る物の イメージがしっかりできているの？ APIのINとOUTは決めています ただそれ以上は・・・ 先輩との差で埋められていないのは 設計⼒かも・・・
44. 今回の開発で⾃分の課題に気づく • 今までの⾃分の開発は設計をしっかりできていなかった • APIのINとOUTが決まっても、更に詳細の設計がない状態で作っていた • ふりかえると新しく作る系は⾒積もりを超えることが多い • 今までの開発も設計が⽢いことで求められている時間で作れていない
45. 開発を終わらせるためのアクション これから作る場所のシーケンス図を ホワイトボードに書いてみてもらう コメントだけ書いて先にプルリク出す
46. アクションの結果 • ⼿戻りが減った︕ • ⼩さな⼿戻りや仕様確認はあるが、明らかにスムーズに前に進んだ • ⾒積もりの精度が上がった︕ • 作るものがより⾒えたことでどれくらい時間を使うか⾒える
47. なんとか実装完了 3週連続スプリントゴールを落とす 事態を回避
48. 今後やってようと思っていること • まずは登場⼈物をまとめる • 開発前にシーケンス図を書いて、設計のレビューを出してみる • やろうと思っていることをコメントに書いてプルリク出すのもあり • 設計に関わる知識のインプットを⾏う • 現場で役⽴つシステム設計の原則を今読んでいます
49. まとめ • コードを書く、読む⼒はついてきた • ただそれでも求められている時間で作り切ることができない • 今回のWeb API開発でそれは設計⼒が⾜りないのではと感じた • 登場⼈物の多い複雑なものを⼿戻りなく作り切ることができていない
50. 同じチームの先輩エンジニア 次のフェーズに ⾏けるかも…!!
51. 複雑なものを⼿戻りなく作りきる⼒ みなさんはどうやって⾝につけましたか??
52. みなさんに聞きたいこと 1. 求められている時間で作り切るために何を意識してきたか︖ 2. 初⼼者だったころ、どう⾒積もりとの開発時間のギャップを 埋めていったのか? 3. 「設計⼒」どうやって⾝につけたのか︖ • 複雑なものを⼿戻りなく作りきる⼒ • コードを書く⼒・読む⼒と違って、⾃⼰研鑽のみで伸ばすのは難しいイメージがある
53. 発表後にダイアログで頂いたアドバイス を紹介します︕ 参加したイベント DevLOVE関⻄ あまり発表したことないエンジニアのみなさん、登壇してみません︖ https://devlove-kansai.doorkeeper.jp/events/171858
54. 設計⼒を上げるためのアドバイス 1. コメントを書くだけではなく、軽く各クラスやメソッドをコメント書くレベルにざっ と組んでみて、レビューしてもらうとより認識のズレや⼿戻りを防げるかもしれない 2. 先輩と⼀緒に設計をして、どうやって開発を進めているのかを実際に⾒てみると新し い気づきがあるかもしれない 3. そもそも設計とはコードを書くよりも時間がかかるもの、ただしここをしっかりやら ないと実装できるはずがない o むしろPBIレベルの設計だけではなく、その下のタスクの設計だったとしても先輩を巻き込 んでいくべき 4. 外部の良い設計のコードをたくさん読んでみる(OSSとか) o 良い設計のコードを読むことで感覚で良い設計とは何か分かるようになる
55. ⾒積もりが合わずに開発が遅れてしまうことのアドバイス 1. そもそも⾒積もりが合わないのはシニアでもよくあること(⾒積もりは技術) o ⾒積もりがズレていたと気づいたときにどうするかが⼤事 2. 開発が遅れていることに対して経験が浅い⽴場だからと「⾃分の⼒不⾜です」と下が らずに、なぜ遅れたのかをしっかり説明すること o 先輩は経験浅いエンジニアがなぜ開発が遅れるのかが分からないことが多く、逆にちゃんと伝えることでお互いの新 たな気づきになり、そのアクションが次の世代への育成にも繋がる o 「⼒不⾜です」と引き下がってしまったらその時点で⾃分もチームも思考が停⽌している、成⻑しない 3. チームで決めたサイズ感(想定⼯数)に対して、⾃分ならこれくらい時間がかかると ちゃんと伝えるべき(そのためにベロシティがあるはず) o 経験が⻑い⼈やそのシステムについて詳しい⼈がやったら早く終わるし、逆に経験浅い⼈やそのシステムを知らない ⼈が開発をしたら時間がかかることは⾄極真っ当なこと o そのためにベロシティも踏まえて、⾃分がやった場合の想定⼯数をしっかり伝える 4. PBIの下のタスクを1⽇以内まで分割して、⾒積もりがしやすい状態を作ってみる o スコープが⼩さくなることで、設計もしやすくなるかもしれない o 各タスクを4時間以内になるまで分割して進めているというケースもあるようです 5. 遅れていることをちゃんと「遅れている」とアラートを出せているだけでも実はすご いこと(良い意味で⾃⼰定義をあげる)
56. 多くの貴重なご意⾒ ありがとうございました︕