1. はじめに
本稿は、私のプロジェクト(ベテラン1人、開発経験が半年未満の若手2名)で実施している「アウトプット勉強会」の実施方法を紹介します。
この勉強会を実施してから若手の設計・実装スキルがメキメキアップしました。私は過去に新人8人くらいの育成に携わりましたが、これが一番効果的だと思います。
なお、「アウトプット勉強会」の形式は、「書籍編」と「設計・実装編」の2種類がありますが、本稿では「設計・実装編」を説明します。「書籍編」の形式については、以下の記事を参照ください。
毎朝15分の勉強会で若手の行動が驚くほど改善した話
本稿は、以下の方々が対象です。
- 若手を育成するために設計する機会を与えたいが、なかなか与えられないリーダー層
- → 業務と並行して勉強会を実施するといいと思います。
- 設計がやりたいけど業務でその機会が与えてもらえない若手
- → 上司の手間は毎朝15分だけなので、頼めばやってくれると思います。
実際の勉強会でアウトプットしてもらった例は以下です。Mementoパターンのクラス図とC#のプログラムです。
2. 前提
2.1 経験が少ないとテンパる
これは、私の経験による仮説です。
設計・実装の経験が少ないと、経験者視点では思ってもみないような初歩的な問題を含んだ設計書やソースコードを作成します。また、レビューで指摘しても、それを正しく修正できないこともよくあります。経験者視点では「教科書の最初の章に書いてあるような初歩的な内容がなぜできないのか」と思うかもしれませんが、経験が少ないと、頭がテンパるため仕方がないと思います。また、「何回も同じ指摘をしているけど解消されない」と思うかもしれませんが、これも経験不足のためです。経験を得ると落ち着いて整理して考えられるようになるため、多くの初歩的な問題は経験を積むことで解消されます(20回も設計・実装を経験すれば、だいたい解消されます)。
駄目なパターンは、経験不十分なまま業務で設計・実装をさせて、多くの手戻りを発生させることだと思います。経験不十分ならペアプログラミングで育成しながらやるか、本稿で紹介する方法などで経験を積むか、どちらかが良いと思います。
2.2 アウトプットの重要性
一般的に、学習は一人で技術文書を黙読するよりも、何かしらのアウトプットを伴った方が学習の質・効率が高いと言われています。つまり、設計・実装のスキルアップは「設計書を書く」「ソースコードを書く」「書いた成果を説明する」などのアウトプットを伴う方法が効果的です。アウトプットの重要性の詳細は 前回の記事 を参照ください。
3. 勉強会の実施方法
3.1 概要
GoFのデザインパターンを題材に、学習対象者はクラス図作成とコーディングを行います。
指導係は、毎朝15分でその成果物をレビューして指導します。
(題材とするのは、デザインパターンでなくても構いません。ただ、オブジェクト指向言語の場合、デザインパターンは初心者にとって手頃な題材としてお薦めです。)
3.2 事前準備
まず次の日に対象とするデザインパターンを決めます。
そのパターンを適用した自分なりのサンプルプログラムを考え、クラス図とソースコードを、各自が事前に作成します。
紙に書くか電子ファイルとするかは各自の自由とします。私のプロジェクトでは、クラス図は二人とも紙、ソースコードは1人が紙で1人は電子です。
3.3 時間
毎朝15分間で実施します。私のプロジェクトは、朝会15分の直後に勉強会15分を実施します。
(朝会が早く終わった場合は、勉強会の時間をその分多くするなど、調整します)
3.4 実施内容詳細
本日の発表者を決めます。
発表者は、自分が作成したサンプルプログラムのクラス図とソースコードを説明します。ここで重要なのは「そのパターンのメリットと用途」を自分なりの言葉で説明することです。
他のメンバーは、成果を見て、パターンに適していない所の指摘や自分なりの考えを発言します。
3.5 進捗ペース
私のプロジェクトの場合は、学習対象者が2人で発表に2日かかるため、2日で1つのデザインパターンが完了するペースです。
学習対象者の事前準備は1日平均1Hくらいかかります(1日目の準備に1.5H、2日目の宿題で0.5H)。
3.6 指導係の責務
事前準備
デザインパターンを熟知している人なら、事前準備は不要です。
私は全パターン熟知しているわけではないため、適切に指導できるように、書籍やWebの記事で対象のデザインパターンについて毎回復習します。
勉強会の進行
なるべく発表者が考えてきたことは、一通り話してもらえるように進めます(説明の最初で初歩的な問題があっても、とりあえず聴く)。モチベーションが重要なので、加点方式で評価して褒めます。
発表しない方の学習対象者にも集中させるために、「指導係より先に指摘すること」を目標にさせたり、時々問いかけをそっちに振ったりします。
また、自力で考えて分かりそうなことは次回までの宿題とするなど、15分での情報伝達効率を考えて進行します。
強制しない
この勉強会は、学習対象者が「自分がスキルアップしたいから学習する」という想いにより成り立ちます。
従って、指導係は事前準備を強制しません。事前準備ができていない日があっても、それに対して何も言いません。勉強会の主体は、学習対象者です。
私のプロジェクトの若手2人は、とても楽しんで取り組んでいるようで、だいたい事前準備をしっかりやってきます。
3.7 クラス図だけ書いても身に付かない
最初、クラス図だけを書く方法でやってみましたが、うまくいきませんでした。実装経験が少ないと、クラス図からどういう実装になるのか、具体的に想像することができません。そのため、コンパイルも通りそうにないクラス図を書くこともあります。
そこで、クラス図とソースコードの両方を書く方法に変更しました。ソースコードを書くことで、上記の問題に自分で気付いて、自分でクラス図をある程度修正して、勉強会に臨めるようになりました。また、学習対象者曰く、クラス図を書いただけではよく理解できていなかった各パターンのメリットが理解できるようになりました。
4. 効果
デザインパターンを全部実施すると、23回のクラス図作成と、3000LOC程度のコーディングの経験値が得られました。その経験により「経験がなくてテンパる」ことによる初歩的な問題はほとんどなくなりました。
過去の経験上、そういう初歩的な問題がほとんどなくなるまでに、業務だけの経験値では1年以上かかる場合もありました。それと同等以上の経験値を2～3ヶ月で業務と並行しながら得られて、デザインパターンの基礎も習得できました。
5. まとめ
私のプロジェクトの若手2名は、この勉強会で楽しみながら主体的に設計・実装スキルをアップしてくれました。
今回、事前準備で各自がデザインパターンを学習するための参考文献は、諸事情で各メンバーの自由にしました。参考文献が異なることで、メンバー間で異なるメリットや用途の発言が出やすかったと思います。ただ、Webの記事の中には、一部適切でない例もあるため、参考文献とする書籍を決めた方が良かったかもしれません。次に他メンバーで実施するときは、初心者向けで読みやすい「Java言語で学ぶデザインパターン入門」の書籍を用いようと思います。タイトルはJavaですが、C#でもこの本はお薦めです。書籍の詳細は以下の記事を参照ください。
新人時代に読めば良かったと後悔するほど感謝した技術書4冊
2020/8/26 追記
上記の他、1年以上かけて様々な成長するための施策を実施しています。以下の記事にまとめていますので、ぜひ参照ください。
1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
本稿の内容を活用して Lightning Review というレビュー支援ツール を作ったりしています。
Twitterでも情報発信しています → @kojimadev