この記事はLITALICO Advent Calendar 2024のカレンダー3の21日目の記事です
https://qiita.com/advent-calendar/2024/litalico
株式会社LITALICOでWEBエンジニアをやっている @ti_aiuto です。
普段は主に個人向けのWEBサービスの開発のサポートを担当していて、特にモノリスなアプリケーションを持続可能な形に保つことや、データモデリング・データ分析に関わる諸々の整備に関心があります。
はじめに
自分は昨年度の4月からPE部基盤グループというところに所属していて、部の各プロダクトが中長期に渡って安定稼働できるよう様々な施策を打っていくことを主な業務としています。
これまでこの基盤グループは中途入社のベテランメンバー＋新卒6年目の自分の計4名だったのですが、なんと今年度4月から新卒のメンバーがジョインしてくれることになりました。
その新メンバーのOJTを自分が担当したのですが、計画・実施の中で検討したことなどを整理しておこうと思い、この記事を書くことにしました。
とはいっても本人が伝えたかったことの大部分を書いてくれているので、改めて自分が書くことはそんなにないような気もしています。
また、今回の新卒OJTの前後で、異動前のチームで働いている別の新卒メンバーたちの簡易的なメンターのようなこともやっていました。同じくこちらの記事でも自分が伝えたかったことを実体験を踏まえて書いてくれています。
計画
前提
メンティー側
入社してくる学生は学生時代から様々な開発を行っていて、技術的にはかなりの知見・センスがあるらしいと聞いていました。
自分も入社前から趣味・アルバイト・個人請負・長期インターンなどで開発の経験があったので、比較的近いバックグラウンドで入社してくると思うと、特に自分が入社してから新たに学んだことやギャップを伝えることを重視していくと良さそうだと考えました。
メンター側
自グループの後輩のOJTメンターを担当するのは初めてなのですが、4年ほど前にOff-JTの新卒研修メンターの経験があったので、カリキュラムの作り方・研修コンテンツの内容そのものも含めて、そのときの資産の大部分を流用しています。
重視する姿勢や考え方の整理
計画を進めていくにあたって、（別件で議論していた異動前のチームでの開発プロセスの整理も兼ねて）研修全体を通して重視する考え方や価値観の整理を行いました。
どのような姿を目指してほしいか？
一言で言えば「信頼されるエンジニア」だと思うのですが、あえて裏返して「信頼できないエンジニア（エンジニア組織）」とは何か？を考えてみたほうが分かりやすい気がしています。
例えば、
- 「これってちゃんと動くんですか？」→「触ってみて動いてるなら動くんじゃないですかね」
- 「これを作るのってどれくらい難しいですか？どれくらいかかりますか？」→「やってみないとわからないですね」
- 「この判断ってどうしてこうなってたんでしたっけ？」→「思いついたのがたまたまそれだったからじゃないですかね」
のような返答しかできないのは、非常に頼りなく思うのではないでしょうか。
ということで、これらを再度裏返して
- 自分が使っている技術を適切に理解して、「なぜそのようにすれば動くのか？」「なぜそのように作らないといけないのか？」を根拠を持って説明できること
- 例えば言語やライブラリの概念であったり、各種インタフェースの定義や仕様であったり、の理解を含みます
- これを達成しやすくするためにソフトウェアを適切に「設計」していくことも含みます
- 自分の仕事の見通しを持って進められること（プロジェクトマネジメント的なところ）
- どんな方法があって今回はどうしてどれを選ぶのか？
- どんなタスクに分解できるか？手伝ってもらうとしたらどこをどうやって？
- どれくらいかかるか？今はどこまで進んだのか？あとどれくらいなのか？
- どんなリスクがあるか？それはどのくらい気にするべきか？どう対処するか？
- オーナーシップを持って仕事を進める中で、周りの力も借りて高水準のアウトプットに近づけられること
- 質問・相談・レビューを依頼するべきタイミングで然るべき相手に依頼できること
- 意思決定の内容を適切に整理して記録できること
- 自身が今やっていることを回りに知っておいてもらう動き（これを「オープンに仕事をする」と言っています）
- 上記のプロセスやアウトプットを別の新たな場面でも再現できること
- うまくいったこと・いかなかったことを振り返って次につなげていく動き
といった点が重要になってくると思います。
「設計」「タスク分解」はだいじ
（これに関して、自分の考えを的確に言い表しているツイートがあったのですが、諸事情で鍵垢になってしまったので引用できません…残念。「仕事の分割はプロジェクト管理の基本であると同時に設計でもある〜」のような内容です。）
例えば「記事ランキングページを新たに開発しよう」となったとき、タスクとしては次のように分解できると思います。
- バックエンド
- （まだなければ）記事ランキングの算出処理の実装
- 記事ランキングAPIの実装
- インタフェース定義
- 記事一件・記事リストをJSONに変換する処理の実装
- 算出されたランキングを取得して返却する処理の実装
- フロントエンド
- 記事リスティングカードコンポーネントの実装
- インタフェース定義
- デザイン当て
- 記事一覧コンポーネントの実装
- インタフェース定義
- デザイン当て
- ページ全体のレイアウトの実装
- インタフェース定義
- デザイン当て
- 記事リスティングカードコンポーネントの実装
- つなぎこみ
- APIを呼び出して結果を必要なコンポーネントに渡す実装
- 効果測定準備
- PV, IMP, CLICKを計測するための実装
この箇条書きというのは、
- ビジネススキル（プロジェクトマネジメント）の観点で見ると「タスク分解」
- タスク同士の依存関係は？どこを早く終わらせないといけない？どこは同時並行で進められる？どうしたら分業しやすくなる？どこが難易度が高い・人に頼ったほうがよさそう？
- 技術スキルの観点でみると「設計」
- どんな処理をどこになぜ実装するのか？どんなインタフェースを定義するのが適切か？どのようにPRを分割するとレビューやリリースをスムーズに・安全に進められるか？
という両面での整理になっています。
そのため開発においては、このタスク分解／設計を丁寧に進めるスキルを高めることは、二重の意味で自身の職務遂行能力を高めていくことにつながるため、極めて重要なことだと思います。
それだけではなく、
- 適切に分割するとタスクが着手しやすい・進めやすい
- 人間なので大きなタスクは心理的にやる気がでないこともあります
- 分割の上で依存関係を整理すれば分業もできます
- 特にPRレビューでは「関心が違う変更は別コミットや別PRに分ける」のような工夫をしてくれるとかなり見やすくなります
- レビューやサポートをする側にとっても全体像を把握できると便利
- 「これまでに何をやった・これから何をやる」が分からないと「ここでなぜこれをやっているのか？」が分かりづらい
- 自分が急病などで倒れても（トラックに轢かれても）他の人に引き継ぎやすい
- いわゆる「トラックナンバー」を増やしておく
- タスクの依存関係を整理して早くリリースできるものを早くリリースすれば価値を早く届けられる
- リリースできていない作業は機会損失でもある
といった利点もあります。
（やり方は何でもいいのですが）手軽に取り組める方法として自分はGitHub Issuesで以下のように整理していくことが多いです。必要に応じてスプレッドシートだったりバックログ管理ツールであったりも使っていくと良いと思います。
この話題に関しては、この記事がとてもおすすめです。
こうした考え方やノウハウについても、研修の中で伝えていきたいと思いました。
つぶやき
後から振り返ると、この「重視する姿勢や考え方の整理」の難しいところは「どこまでが自分自身の個人的な思想・信念で、どこまでがグループ・組織として重視するべき行動・仕草なのか」を切り分けるところだったと思います。
とはいえ今回は幸いなことに（？）評価者である自グループの上司も似たような考え方を重視しているようですし、部全体としても「ちゃんとやる」ことを改めて大切にしている流れだったので、そこまではっきりくっきり切り分ける必要はありませんでした。
余談：「歩いていれば着くでしょう」の精神で喧嘩になった話
こういう話をまとめていていると、先日友人と遊びに出かけているときに、自分が地図を見なさすぎて険悪な空気になってしまったのを思い出します。
基本的には自分は急いでいないときは地図ですごくしっかり予習する・頭の中で道順を思い描くのではなく、散策気分で適当に歩いては看板や案内表示を見つつ、迷うことも楽しみのうちくらいのノリで歩くのですが、事前にちゃんと計画して歩く習慣のある人からすると、相容れないものがあるかもしれません。
（先日神戸へ遊びに行ったときも「行きたいのは三宮駅なんだけど看板には三宮・花時計前駅しか載ってないな…まあたぶんこっちでしょ」と歩いていったら到着できたのを思い出します）
銀のさらでデリバリーのバイトをしていたときは各目的地までの道順をすべて覚えて出発だったのでできないわけではないのですが、日常生活でいつもそれをやるエネルギーはないという感じです。
仕事を「ちゃんと計画する」ということに関して、やらない人の感覚がピンとこない部分もあったのですが（まあ自分も教わる前はやってなかったかもしれないですが当時のことは忘れてしまいました）、この経験からかなり合点が行ったように思います。
目標の定義
研修の計画にあたって、まずは入社3ヶ月後・6ヶ月後・1年後にどうなってほしいのか？の到達イメージを定義するところから始めました。
観点の整理
漠然と考えても難しいので、大きく3つの観点を軸に整理していきます。
- 技術スキル
- 部内のWEBアプリケーション開発で使っている手法・フレームワーク・ライブラリについてはもちろんのこと、データ分析やクラウドの構築運用など周辺知識も必要です
- 単に動くものを作れれば良いということではなく、「技術をちゃんと理解するとはどういうことか？」の目線合わせも含めて行っていきます
- ビジネススキル
- 作業分解や見積もり、成果物をレビューしてもらうときの動き方など、チームの中で・専門職集団のアウトプットとして仕事を進めていくという点で、特に重要な考え方や「仕草」も身に着けてほしいところです
- 事業理解
- 基盤グループは部内のプロダクトの成長を伴走していく役割にあるので、プロダクトに関する理解も欠かせません
- 自社、特に部内で開発しているプロダクトについて、どんなユーザが・なぜ・どのように使っているのか？、どのようなビジネスモデルなのか？、どのような技術で実現されているのか？など様々な面から理解を深めていきます
いざ目標設定
詳細は省略しますが、要約すると次のような内容を設定しました。
| 技術スキル | ビジネススキル | 事業理解 | |
|---|---|---|---|
| 3ヶ月後 |
|
|
|
| 6ヶ月後 |
|
|
|
| 1年後 | (様子をみて考える) |
|
(様子をみて考える) |
コンテンツの整理
実際の研修コンテンツを整理していきます。大きく分けると次のような内容です。
先輩社員の記事や他社の参考記事
社内外にある新人社員に向けたアドバイスの中から厳選して「この記事は読んでおくといいかも」というものを集めました
以下に代表的なものをご紹介します。
課題図書
『達人に学ぶDB設計 徹底指南書』『知識ゼロから学ぶソフトウェアテスト』『Real World HTTP』「安全なウェブサイトの作り方」などなど、業務時間を使っていいのでぜひ読んでおいてほしい本を集めました
社内で蓄積している研修コンテンツ
過去に制作したスキルアップ向けのチュートリアルや問題集も活用していきます。
下記のような公開している記事や、Vue.jsやReactの練習問題のようなものがあったりします。
社内で過去に実施された各種説明会のアーカイブ動画
事業やプロダクトに関しては過去に開催された説明会やLT会の動画のアーカイブも活用していきます。
手を動かして動くものを作る＆理解度を対面レビュー
以前実施していた新卒研修の内容を丸ごと拝借して（といってもその内容にアップデートしたのは自分の世代なのですが）「Ruby課題」「テスト課題」「WEBアプリケーション基礎課題」「Rails課題」「WebApp実務研修（架空のECサイト開発）」の5段階で実施します
今回は「実務研修で開発したアプリケーションにスタイルを当てていい感じのデザインにする」「実務研修で開発したアプリケーションをECS on Fargateにデプロイする」の追加コンテンツも加えました。
各課題では、参考記事や課題図書、公式チュートリアルといった、参考になるリソースを適宜提示しながら進めていきます。
実プロダクトの優先度が上がらない小さめのタスク
様々な事情で優先度が上がらず後回しになっている、軽微なバグの修正、違和感のある実装の修正やパフォーマンスチューニングといったタスクは、急がず着実に実プロダクトでの開発経験を積める貴重な機会です。
実施
全体の進め方
全体の進め方としては、スプレッドシートにまとめた「コンテンツ一覧」を自分のペースで進めていってもらいます。
「手を動かす系」のコンテンツに関しては、準備ができたタイミングでアウトプットの確認＆理解度の確認のためのレビューの時間を設定してもらってディスカッションします。
加えて、日報シートに日々の学びや考え事などの振り返りを記入してもらいます。それに対する返信も毎日欠かさずに書きました。
Ruby課題～Rails課題
全体的に順調だったと思います。
特に「コードの動作をRubyの概念・用語を適切に使って説明できるか」「Railsで〇〇と書いたときにどういうことが起こるか」「WEBアプリケーションの特定の脆弱性が、どのような条件で再現するのか」といった点で、会話の中で理解度を確認していくのは改めて大事だなと思いました。
「説明しようとして初めて分かってると思ってたことが（期待される水準では）分かってないとわかる」ということもありますね。
WebApp実務研修
ここではビジネススキル面では見積もりやタスク分解が、技術面ではトランザクションの活用・メソッドを適切に定義実装する・適切なテストコードを書いていく、といった点が重要です。
自分含めて3人のレビュワーで業務の合間にPRを見ていたのですが、「直さなくてもいいけどこんな論点もあるかもね～」のようなやりとりも含めて各々が好き勝手ツッコミを入れた結果、良くも悪くもかなり盛り上がることとなりました。
そうした指摘でのやりとりや使ったことのない機能に苦戦した部分もあり、本人としては思ったより時間がかかったようでしたが、自分からしたら十分速くこなしてくれたように思います。
～プロダウト内でのOJT
その後はReactの学習・Fargateやcdktfの学習を片手間で進めつつ、とある実プロダクトで小さ目のタスクをどんどん進めてもらいました。
最初は自分のほうで方針の確認であったりタスク分解であったりを一緒にしていたのですが、途中からプロダクトチームの皆さんに 丸投げ お任せすることにしました。
この狙いとしては、自分が間に入らなくても起票者と直接話して十分進めていけそうだったことと、プロダクトチームの皆さんとの親睦を深めていってほしいということがあります。
ここでも全体的に順調に進めているように思いましたが、「起票された課題に対して、どこまで愚直に書かれた通りのことをやるのか？そもそも論で検討するのか？」といったバランスをとるのは難しいよなあと横で見ていて思いました。これが唯一の正解というものもないですしね。
「活躍について語る会」
上期が終わったタイミングで、「 @EXcEption2zero さんの活躍について語る会」と題して、プロダクトチームの関わってくださった皆さまに「よかったところ」「もっとできそうなところ」を伺う会を設定しました。
一部メンバーを除いて任意参加にしていたのですが、ほぼ全員が出席してフィードバックをくださり感謝です。
「相談する際の論点整理の仕方」「タスク・作業の見通しの共有の仕方」など、今後の成長につながるアドバイスを伺うことができました。（もちろん自分もフィードバックはしているのですが、同じような観点でも多様な視点からコメントいただけることで気づくこともあると思うのでありがたいです。）
最後に
といったような流れで、研修メンター・OJTメンターを順調に終えることができました。
それというのも冒頭で紹介したQiita記事を読めば分かると思いますが、ひとえに本人が真摯に取り組んでくれたことに尽きると思います。
技術特化の部署に異動して、育成とかマネジメントとかといったことはあまりやらなくていいものかと勝手に思っていましたが、こうして担当させてもらえたのは貴重な機会でした。
あとは、マネジメントというものにあまり興味はなかったのですが、「チームで高品質高効率にアウトプットを出せる仕組みとは？」のような問いの立て方をすると、途端に興味が湧いてくるというのも新たな発見でした。
その後も難易度が高めのタスクに挑戦していたり、WAF移行に関連するタスクを一緒にやったりと、今後の活躍が非常に楽しみなところです。
次回予告
次回は @m_sugane さんが担当します。お楽しみに！
この記事の他に2つ記事を書いています。よかったらご覧ください！