この記事は🎄LITALICO Engineers Advent Calendar 2024🎄 シリーズ2の14日目の記事です。
カレンダーは4枚あるので、ぜひこちらもご覧ください！
- シリーズ1: by @kotsume_373 さん
- シリーズ3: by @nonikeno さん
- シリーズ4: by @darmats さん
はじめに
はじめまして！LITALICO発達ナビというプロダクトの開発チームに所属している中山と申します！
まず最初にタイトルについての申し開きをさせてください。
「お前は"仕事"をしていない」というのは先輩である @ti_aiuto さんに言われた言葉をキャッチーにするためにひどく脚色した言い回しです(笑)
実際は「仕事の進め方について教わる機会がなかったと思うから、こういう考え方で進めてみたらいいかもよ？」くらいの温度感で優しく指導・サポートしてくださいました。
今回はその経験について初めてのQiita記事を書いてみようと思います！ﾄﾞｷﾄﾞｷ
このようなタイトルにすることを笑って快諾してくださったこと、実際に業務でたくさんサポートしてくださったことに特大の感謝を！！
@ti_aiuto さんの素晴らしい記事もあるのでぜひご一読ください〜。
記事の概要
本記事の概要としては、先輩の指導のもと実践した"仕事"の進め方、実践の中においてそのとき感じていたこと、今振り返って良かったなと思うことを書いていきます。
今回伝えたいことの目次はこんな感じ
- "仕事"の進め方（Why・What）
- "仕事"の定義
- 大切にすべき考え方
- 開発プロセスにおける実践（How）
- 腹落ちまでの気持ちの遷移
- 今振り返って良かったなと思うこと
対象読者と目的
本記事の概要としては、先輩の指導のもと実践した"仕事"の進め方と、実践の中においてそのとき感じていたこと、今振り返って良かったなと思うことを書いていきます。
対象読者とその目的については以下とします！
- インターン経験などもない新米エンジニア
→ 開発業務のイメージを持ってもらう - 新米じゃないのに"仕事"ができないと悩んでいる・言われているエンジニア
→ Howの1手札にしてもらう（一緒に頑張りましょう！） - 1, 2 に該当するの人に"仕事"を教える立場のマネージャーやメンター
→ 教えを請うている側の気持ちや腹落ちするまでのプロセスを知ってもらう
それぞれ、
1の方は「開発プロセスにおける実践（How）」
2の方は「"仕事"の進め方（Why・What）」「今振り返って良かったなと思うこと」
3の方は「腹落ちまでの気持ちの遷移」や全体の体験・気持ちの部分（緑のnote部分）
をメインで読んでいただくと目的が達成されやすいかも？
else の方は冒頭の他の記事をレコメンドしておきますね😊
自己紹介
新卒2年目のエンジニアで、入社から同じサービスを担当しています。
入社時の技術力は、Ruby on Rails でとりあえず何かしら動くものは作れるくらいで、チーム開発や実務の経験はありませんでした。
普段取り組んでいる施策は、開発期間が数日〜2週間（大きくても1ヶ月）程度、コミュニケーションを取る必要があるのはプロダクトマネージャー（PdM）＋ 1〜2人程度の規模が主です。
実践した"仕事"の進め方
"仕事"の定義
まず最初に、この記事における引用符付きの"仕事"の定義を共有しておきます。
仕事と作業は違う（*1）
今回の話はこの言葉に集約されるのですが、これだけ「はいはいそれね、全部理解した」となった読者諸兄におかれましては本項は読まなくて良いかもしれません。というかこの記事も読まないで。恥ずかしい。
ひろく何かしらの目的を達成しようとしたときに「課題を明確にして、作業分解してやる/やらないを決めて、実行するのだ」というのはよく言われることですよね。
それでいう「課題を明確にする」「作業分解してやる/やらないを決める」が"仕事"にあたり、「実行する」が当然"作業"にあたります。
開発業務でいうと 設計：コーディング の関係が 仕事：作業 の関係に近いです。
最初は正直「言うてることは納得はできるけど、言葉遊びやな〜」と思ってました。
今は納得した上で次のフェーズとして「"仕事"にコストをかけて"作業"はささっと終わらせたいんやけどなかなか難しい🤔」となっています。シンプルな技術力不足…。
大切にすべき考え方
オーナーシップを持って自走する
オーナーシップとは、個人が与えられた職務やミッションに対して主体性を持ち、取り組む姿勢やマインドのことをいう。(*2)
自走型の人とは？
言われたこと以上の目的を理解し、その目的を実現するために最適な方法を自ら見つけて活動、改善できる人のこと。(*3)
自走というと「自力で解決できる人」みたいなイメージがあるかもしれませんが、そんなことはないはずです。人に質問をすることも自走には大切なプロセスであるはずです。(*4)
目的の完遂に向けて、スムーズに遂行するための計画・管理を自力で行えることが大切です。いうまでもないですが、言われたことを何も考えずそのまますることしかできない→"仕事"をしていない、ということになるからです。
自力で行うというのは主導権を持って進めるということであり、サポートを求めてはいけないということでは決してありません。ここ重要。
サポートを求める際は、観点を整理した上で、自身の理解度や目的に合わせて「インタビュー・質問・相談・レビュー」のどれであるかを意識して会話しましょう。
- インタビュー：ある観点についてざっくり意見が聞きたい
- 質問：ある観点についての疑問があり、それを解消したい
- 相談：ある観点について意見はあるが不安なので、懸念などがないか聞きたい
- レビュー：ある観点について意見があり、最終チェックをお願いしたい
よく考えず「レビューお願いします」とか言うて先輩の工数を奪うことに後ろめたさを感じてた原因はこれをはっきりさせてなかったからや！
どれくらい自分の意見に自信あるかとか温度感はっきり伝えたらレビューコストも適切に抑えることができると言うことか〜オーナーシップ持ってなかったってことやな、反省😞
オープンに仕事をする
調査過程・思考過程や疑問点をアウトプットしながら仕事を進めましょう。
高精度で高コスパな成果物を得るために、チームでサポートし合える環境を作ることができます。
また、トラックナンバーを1にするのを避けることもできます。
はたまた、同じ内容で詰まった未来のチームメンバーの参考になるかもしれません。
突然大きいプルリクエストがどーんと出てきたら、読みにくいし、手戻りのコストもあるから今更ひっくり返しにくいから困るって先輩に言われたのはこれで解消できるわけや
アドバイスも受けられるし未来の誰かの助けににもなれるんやから、最早やらんと損まである！
普段の開発プロセスにおける実践
※ 僕のチームではGitHubのIssueを作りそこに全て書いてくやり方をとっています。
背景・目的・要求・仕様の整理（"仕事"）
まず担当する施策について、現状はどういう課題が？今までの打ち手は？その効果は？そこからどんな仮説がある？などの背景と、どの数値を伸ばしたいのか・何を改善したいのかなどの目的を整理します。
それらについて理解した上で、要求を把握し、仕様・完成の状態を整理します。
必要に応じて図表も用います。
ここはコード書くのの次にエンジニアの"仕事"って聞いてイメージするところやけど、一番難しい
ToDoの洗い出し（"仕事"）
タスクを細かく分解し、やる/やらないの判断を通してToDo化します。
タスクを細かくするということの利点は、「作業・レビューが楽」だけでなく「全体像や依存関係を適切に理解したうえで、それをチームや自分がわかりやすく記述しておける」というものもあります。
施策によって様々なので、例を列挙します。
- 起案者（僕のチームではPdMであることが多い）とのすり合わせ、要件定義
- 先輩への相談事項
技術的なこと、触ったことがない機能の仕様、何から手をつけて良いかわからない - リスク洗い出し
セキュリティ、パフォーマンスなどの懸念はないか - 仕様の検討
起案者が思っている要求を満たしているか - 設計・実装方針の検討
- リリース手順の検討
- レビュー依頼のタイミング
- etc.
当初「こんなん経験が物言うやつやん！むずかし！」
現在「こんなん経験が物言うやつやん！むずかし！ …でも前より気が付くこと増えたな？」
ここまでのレビュー依頼（"仕事"）
タスクが自分の実力に対してストレッチである場合、要求や仕様が複雑な場合、通常と異なるルートでの起案である場合などは特にチェックポイントとしてのレビューの機会を設けましょう。
思いもよらないリスク・考慮漏れ・もっと効率的な進め方があるかもしれません。
進め方に自信が持てへんかったら、できるだけ観点洗い出した上で、このタイミングで相談すれば良かったんか〜まだ何もしてないのに相談するの申し訳ないと思ってた
ToDo内にある設計・実装方針の検討（"仕事"）
DB設計、メソッドやAPIのインターフェース設計、コンポーネント設計などは特に事前の相談を推奨します。
この段階ではできるだけコードを見ずに行い、実装と明確に区別して行います。
必要に応じて図表も用います。
当初「コード見ずに設計は無理やて…無茶言うなよ…」
現在「自分が既に該当箇所の設計が頭に入ってたらできるようになってきた！でも勘所が掴めてない箇所はまだまだできひん」
ToDo内にある上記以外（"作業"）
主に実装や動作確認などのコミュニケーションです。
ここももちろん適宜記録はとっていきます。
腹落ちまでの気持ちの遷移
検討期
先輩が「チーム内の新人が"仕事"できてないから指針を作った方が良い！」と言いはじめたフェーズです。
この段階ではそこまでほぼパブリックではなかったので、なんか小難しいこと言ってるな〜くらいにしか思ってませんでした。
ヒアリング期
先輩がチームメンバーに、現状の開発スタイルや指針の叩き台についての意見をヒアリングしていたフェーズです。
この辺りでは「Issueをもっと書こうね！」「丁寧に作ることは大事だよ！」くらいの解像度でしか伝わっていませんでした。
僕の気持ちは、きっと先輩が言うんだから大事なんだろうな〜くらいにランクアップしました。
導入・指導期
開発時にIssueに書くためのフォーマットを導入し、使い方について指導してくださっていたフェーズです。
当初、フォーマットがあったせいでかえって形式にとらわれてしまい、Issueを書くことが目的になってました。その結果、確かに大事な気はするけど正直面倒な作業だなあと感じていました。今思うと、それをする目的の大部分、つまり丁寧にオープンに作る目的が理解できていなかったのだと思います。
その後、指導を受け実践を繰り返していく中で、なんとなく施策がスムーズに進む感覚を得るようになっていきました。この段階では概ね活動の意義に納得していたと思います。
振り返り期
自分が担当した施策を自分で振り返ったフェーズです。
どんな思考過程でその設計に至ったのかや、実装に詰まったこと、動作確認段階で不備が見つかったことなどが全部Issueに書かれていて、振り返りがとてもしやすく驚いた記憶があります。当たり前と言えば当たり前ですが、ログがなければ精緻な振り返りはできないんだなと実感しました。
実践の中ではまだふわふわしていたプロセスの意義が、ここでしっかり腹落ちした記憶があります。
今振り返って良かったなと思うこと
How を提示してくれた
やる目的はもちろんですが、Issueにこんな感じの情報をまとめて大体こういう段取りで進めてるんだよ、というどのようにやるかの部分も一緒に提示してくださったことは、取り組むハードルをぐっと下げてくれました。
そのやり方が必ずしも正解ではないとしても、ある程度筋の良いやり方であることが保証されているというのは非常に良かったと思います。
先輩自身が実践してくれていた
1つ上の項と近いですが、先輩が既にIssueに全ての情報をオープンにするということを実践されていたので、最初はそれを真似て、徐々に自分なりにやりやすいように修正してくいくのが非常にスムーズでした。
「守破離の守」。「学ぶは真似ぶ」。なんでもいいですが、個人的には組織に属している以上は身近な巨人の肩の上に乗るどころかパパの肩車で済むレベルのことをしないのは損だと思うし、逆説的かもしれないですが自走のためには重要であると考えています。
むしろロールモデルとか真似る対象が全くいないというのは、（必ずしもそれだけが原因ではないですが）独走・迷走に陥りかねないんじゃないかな…と過去の自分を思い返して感じます。
プルリクエストレビュー段階での手戻りが減った
取り組み自体の良かったことですが、実感値としてプルリクエストを出してからレビューの段階などでの修正や手戻りの回数や大きさが明確に減りました。
これは計画を立てて作業分解することでPRも小さなまとまりを複数出すようになった結果、実装者としては小さい単位の変更に集中できること、レビュー者としては注視する観点が絞られることが理由に挙げられると思います。
後者に関する具体的なイメージは、ウォーターフォール開発における各テストで掴めるかもしれません。
- 新規メソッドやコンポーネントを追加するPR：単体テスト的観点のレビュー
- そのメソッドやコンポーネントが単体で役割を果たしているか
- 追加したメソッドやコンポーネントを繋ぎこむPR：結合テスト的観点のレビュー
- 繋ぎ込む部品のインターフェースは単体テストで担保している前提で、それぞれが上手く連携できるか
- リリースPR：システムテスト的レビュー
- 最終的に出来上がったものがおかしくないか
こう考えてみると、要求や仕様からタスクまでブレイクダウンして、小さい範囲からレビューをしていくというのは、縮小版ウォーターフォールV字モデルでもあるのかもしれません（テキトウ）。
さいごに
ここまで長々とポエムに付き合ってくださりありがとうございました！
〆切駆動執筆のおかげで書き切ることができた一方で、拾いもらした学びや当時の感情もたくさんある気がしていますが、現状のまとめとしては一旦及第点かなと思います。
僕と同じように"仕事"ができなくて悩んでいるあなた！一緒に頑張りましょうね！💪
僕のような人を育成しているあなた！どうか甘えだと切り捨てず腹落ちするのに時間がかかるのを許容してあげてください！
LITALICO Engineers Advent Calendar 2024 は明日も記事が公開されます。
記事数は過去最大？みたいですね！わいわい
シリーズ1 @nhnmomonga さん
シリーズ2 @nobook さん
シリーズ3 @itoken1013 さん
引用元
*1 課題を管理して実行して達成するための手順 - そーだいなるらくがき帳
*2 オーナーシップ｜グロービス経営大学院 創造と変革のMBA
*3 自走とは？【ビジネス上の意味】自走できる人材の育成方法 - カオナビ人事用語集
*4 「自走できるエンジニア」とは