これまでのあらすじ

当社では開発未経験の新人さんが入ってくると、
研修の一環として仮想の開発プロジェクトを立ち上げて、
仕様決めからリリースまでの一連の開発作業を体験してもらっています。

計画する、コードを書く、ツールを使う、わからない事を調べる、周りに聞く、トラブルシューティングする、
といった開発における一連の流れを経験してもらいます。

ただ単に知識として理解するというよりも、
経験することでより深く理解してもらえると考えています。

前編では、仮想プロジェクトの入る前の準備や、プロジェクト始動時に、
新人達・先輩達がそれぞれどういったことを行うかを説明しました。

前編はこちら

後編では

仮想プロジェクトを日々どんな風に進めるのか、リリースまでの話しをしたいと思います。

日々の開発作業

コーディング

新人さんたちの思うように自由に書いてもらいます。
質問されたり、コードを見せてもらった時に、良い書き方を教えることはありますが
基本的には好き勝手書いてもらいます。

そのため

命名のセンスが悪い（変数名が英字１文字とか）
ロジックが複雑
コードがコピペだらけで冗長

といったコードになりがちですが

新人たちの手で何とか動くものを作ることが最優先です。

「そんな書き方していたら業務の開発では通用しない！」
という考えもありますが

仮想プロジェクトが進むにつれて
自分たちが書いたコードの可読性の低さが
ブーメランのように返ってくること

また、先輩たちのアドバイスによって
仮想プロジェクトの後半になると
「この書き方より、もっとこうした方がいい！」
といったように

必要性を理解した上で改善に向かう傾向にあります。

Git

事前研修でGitの書籍を読んでおいてもらいます。

参考書籍：いちばんやさしいGit&GitHubの教本

ブランチやコミットのルールはほとんど無しで、コードを共有するために使ってもらいます。
最低限の運用として、担当者別にブランチを切ってそれぞれが開発し、
エラーなく動く状態のものをプッシュし、それぞれがマージして取り込むようにしてもらいます。

「コンフリクトしてる！」
「ブランチ間違えてコミットした！」
「間違ってプッシュした！」
「コードが吹き飛んだ！」

といったことを本番のソースリポジトリを触る前に経験してもらいます。

外部ライブラリ（RubyだとGem）

機能を実現するために新人さんはググって色んな情報を見つけてきます。
その中で良くあるのが外部のライブラリを使う解決法です。

新人さんには事前に「Gemを入れる時は確認してね」と伝えるようにします。

様々なGemがある中、社内で利用実績のあるGemの方が周りのメンバーがフォローしやすかったり、
チーム内で同じようなことを実現するのにAさんはXライブラリ、BさんはYライブラリといったことを防いだり、
ライセンスを確認したりせずに使用したりするのを防ぐためです。

テスト

仮想開発プロジェクトではテストコードは書きません。

プログラムを書き始めたばかりで、機能を実現するのに精一杯の状態。
その上さらにテストコードも書くというのは、スキル的にも期日的にも厳しいからです。

しかし、コードの品質を担保するためにはテストが必要です。
そこでテストコードは書きませんが、テストケースは書いてもらいます。

スプレッドシートなどにテストケースを書き出して、画面をポチポチ操作してテストしてもらいます。
手動テストだろうが自動テストだろうが、
大事なことはテストケースを洗い出すことだということを理解してもらいます。

テストケースやテストコードを書く理由のひとつに、再テストを効率的に行う、というのがあります。

新人さんは最初の内、再テストすることになるとは思っていないので、必要性に疑問を持つかもしれません。
しかし、後半必ず再テストする場面が訪れます。
粒度はともかくテストケースを書いてもらいましょう。

トラブルシューティング

先輩は新人からの質問を随時受け付けます。

よっぽど忙しい時はその限りではありませんが、基本はリアルタイムで質問に答えるようにします。

特にインフラや環境まわりのトラブルについては
全面的に先輩が解決するようにします。

仮想プロジェクトで学んでほしいこととして
モノづくりを経験することにフォーカスしてもらいたいのです。

インフラや環境まわりは後々学んでもらいたいのですが、仮想プロジェクト中ではありません。

デイリーミーティング

新人達だけでデイリーミーティングを行ってもらうこともあれば、先輩が入ってアドバイスすることもあります。

進捗状況
どんなことを行ったのか
今後の予定
気づいた点などの情報共有

デイリーミーティングに必ず先輩が参加するわけではありません。

一番の理由は「まずは自分たちでやってみてもらう」ためです。

例えば、情報共有って言葉では大事なのは新人であっても容易に理解できることなのですが、
実際にどんな情報を共有すべきかという判断軸は人ぞれぞれバラバラです。

開発を進めると、情報共有できていないことで問題が生じることがあります。

ルーティングを勝手に書き換えて、他が動かなくなるとか
ふたりで同じコントローラーを編集しまくって、コードのコンフリクトの解消に時間がかかったとか

情報共有しないと、こんなことが起こるということを実体験してもらった上で

「このレベルは情報共有した方が良いよね」 といった判断軸が養えると良いです。

こういった判断軸が養われてくると、
情報共有は内容によっては
「リアルタイムに共有した方が良いね」 といった方向に進化していきます。

1 on 1

毎週30分程度、先輩と1on1ミーティングを行います。

新人さんは

会社に新しく入ったばかり
未経験で上手く開発できるか
仮想開発プロジェクトチームメンバーと上手くやれるか

というような、技術的、メンタル的な不安を抱えています。

こういったお困り事・悩み事を聞いて
不安を解消して、仮想開発プロジェクトに集中できるようにサポートします。

スコープ調整

リリース日を変更せず、残業や休日稼働せず
開発する機能を取捨選択することで、リリース日を守れるように調整します。

スコープ調整です。

日々の進捗管理していると、進捗が遅れることがあります。

ある部分の開発に想定以上に時間がかかったとか
さらにもっと時間がかかりそうとか
別の機能を作る必要性に気づいたとか

リリースを遅らせる要因は日々見つかります。

ここで改めて仮想開発プロジェクトの方針を確認します。

納期優先

作業時間を積み増しすることで解決してはいけません。

もちろん深夜残業したり休日勤務することって
ここぞという時には、自分の成長に大事な場面はあると思います。

しかし「時間の積み増しで解決」することだけを覚えると
それ以外の方法で解決する力が養われませんし
常態化して疲弊するのは目に見えています。

スコープ調整の例

must：必達。これがないと本質的な価値が提供できない
have to：あると価値が高まる、ないと価値が減る
want：あったらいいな、便利

こんな感じで開発する機能に優先度割り振って
再スケジューリングするようにしてもらっています。

これを行うためには機能・要件の一覧を作っておく必要があります。

レビュー

開発が進んで、ステージング環境などである程度テストが終わったものを
マネージャーや先輩にレビューしてもらいます。

開発した新人達は、
この段階で 「ほとんど完成！」 と思っているけれど

見る人が見ると

「ここって動きおかしくない？」
「デザイン崩れてるね」
「こういうパターンの時ってどうなるの？」

レビューをマイルストーンに置くこと
レビュー後の修正とテストもスケジュールに含めることが大事です。

リリースに向けて

仮想プロジェクトの後半になると
追加したい機能や、修正したい機能が出てきたり

コードが汚くてもっとキレイに整理したいけど
といった具合に、リリース日は迫ってきてスケジュール的にきついけど
やりたいことが増えていきます。

機能の追加や修正を行うと
追加修正する工数だけでなく、テストも必要になりますし
それ以外の場所にも波及することも考えられます。

後半は、よりシビアにスコープ調整することをオススメします。
新人さんはこの辺りを判断するのが難しいことが多いです。
新人として頑張り過ぎないように

例えば
「これはレアケースなのでデータベースを直接メンテすることで乗り切ろう」
みたいアドバイスを先輩からしたいものです。

リリースできる MVP（Minimum Viable Product）　
を目指しましょう！

終わりよければすべて良し

日々、すべてが計画通りに進むことよりも、
たくさんの軽い失敗と、それらを乗り越えたり軌道修正したりしながら、リリースを目指すような状況を作りたいですね。

最終的には「動くものリリースすること」が大事です。

開発プロジェクトの本質はモノを作ることではなく「価値を提供すること」なので
先輩達はそれが実現できるように全力でサポートしましょう。

本番環境での最終調整を行って リリース します。

デモ・説明会

「リリースできた！」と思ったのも束の間
開発部門内でデモ・説明会が待っています。
もちろん、これも新人さんに行ってもらいます。

資料の準備
デモスクリプトの用意
大勢の前で発表することの緊張感
先輩達からの質問

このデモ・説明会を乗り越えるとようやく終了

最後に

こうやって書き連ねてみると
仮想プロジェクトは、色んな粒度が荒いプロジェクトなので、やっぱり仮想なんだということが分かります。

ですが、新人さん達がこの仮想プロジェクトを通して得られる経験は

「仮想じゃなくホンモノ」

なのです。

これからも一人でも多くの人が
仮想プロジェクトを通じてエンジニアになってくれると良いなと思っています。