毎朝15分の設計勉強会で楽しく設計のスキルアップ(#8)

この記事の初出は、Software Design 2022年11月号です。

若手育成のための設計

若手を育成するために設計する機会を与えたいけど、業務の都合上、なかなか若手向けに適切な難易度の設計タスクを与えられないということはないでしょうか。
もしくは、自分が若手で、設計がやりたいけど業務でその機会がなかなか得られないということはないでしょうか。
今回は、そのような場合におすすめの施策を紹介します。

前回は「毎朝15分のアウトプット勉強会(書籍編)」を紹介しましたが、今回はそれから派生した「毎朝15分のアウトプット勉強会(設計編)」を紹介します。
これまで私のチームに入ってきた新人6人にこの勉強会を実施してきましたが、これをやるようになってから、新人の設計・実装スキルがメキメキと上がるようになりました。

経験が少なくてテンパるのは仕方がない

私の経験では、設計・実装の経験が少ない若手は、熟練者からすると思ってもみないような初歩的な問題を含んだ設計書やソースコードを作成します。
過去の私は、そのように経験が不十分な若手に業務で設計・実装をさせた結果、レビューで多くの手戻りを発生させてしまった事があります。
レビューでの指摘内容に対しても、正しく修正できずに差し戻しになる事も多くありました。
これは当時の私のやり方が良くなかったと反省しています。

熟練者からすると「こんな初歩的な事がなぜできないのか」と思う事であっても、それまでにあまり経験したことのないタスクをやっている時は、テンパって(焦って)しまって落ち着いて考えられないため、できなくても仕方がないのです。
また、レビューアからすると「何回も同じ指摘をしているけど一向に解消されない」と思えるような事もありますが、これも経験が少ないとよく起きます。
経験を得ると落ち着いて整理して考えられるようになるため、多くの初歩的な問題は解消されます。
私のチームの場合、20回以上のレビュー有りの設計・実装を経験すれば、かなり解消されました。

よって、経験が少ないうちは、ペアプログラミングやモブプログラミングで育成しながら取り組むか、今回紹介する勉強会などで経験を積むのがお勧めです。

勉強会の実施方法

前回にも紹介した通り、学習は一人で技術文書を黙読するよりも、何かしらのアウトプットを伴った方が学習の質が高く、効率も良いです。
これは、設計・実装のスキルアップにおいても同様で「設計書を書く」「ソースコードを書く」「書いた成果を説明する」などのアウトプットを伴う方法が効果的です。

従って、今回の手法では、事前に学習対象者にサンプルプログラムを作成してもらい、勉強会でその成果をレビューします。
作成してもらう題材は、GoFのデザインパターン(全23種類)の設計パターンとしています。
題材とするのは、他の設計パターンでも構いません。
ただ、オブジェクト指向言語の場合、GoFのデザインパターンは初心者にとってオブジェクト指向の基本を理解するために有効であり、手頃な難易度で23回の設計・実装の経験が積めるので、題材としてお勧めです。

勉強会を開催するにあたって、まず対象とする設計パターンを決めます。
学習対象者は、事前準備としてそのパターンについて書籍などで学習した上で、そのパターンを適用した自分なりのサンプルプログラムのクラス図とソースコードを勉強会までに作成します。
サンプルプログラムは、書籍にある例を少し変えただけでなく、そのパターンの用途に適した別の例を考える事を推奨します(最初はそれを考える事が難しいので、書籍の例を少し変えただけでOK)。
ちなみに、私のチームでは最初にGoFのデザインパターンを学ぶ時の書籍は、結城浩さんの『Java言語で学ぶデザインパターン入門』を利用しています。
タイトルに「Java」と書いてありますが、Javaを知らなくても問題なく理解でき、各パターンのメリットや用途が具体的に書かれていて初心者にとって理解しやすいからです。

勉強会の当日は、学習対象者が作成してきた設計書とソースコードに対して、指導係がそれをレビューして指導します。
学習対象者は1～2名を想定しています(学習対象者が多いと、自分の成果を説明する機会が減ってしまうため、少人数を推奨)。
学習対象者が2名の場合は、その日の発表者を決めます。
発表者は、自分が作成したサンプルプログラムのクラス図とソースコードを説明します。
ここで重要なのは「そのパターンのメリットと用途」を自分なりの言葉で説明することです。
設計初心者の場合、それをいざ説明しようとすると、全然分かっていなかったという事に自分で気付いてくれたりするので、自分の言葉で説明してもらう事はとても重要です。

勉強会の頻度は、毎日が推奨です。
最初の慣れていないうちは、事前準備に何時間もかかったり、勉強会でのレビューの指摘が意図通りに直らなかったりで、1つのパターンのサンプルプログラムが完成するのに1週間かかる事もありました。
ただ、慣れてくれば、1つのパターンに対して、1回目の勉強会でレビューした後に、直した成果を2回目の勉強会で再レビューして完了できるようになりました。
学習対象者の事前準備も、慣れてくると平均1時間くらいになりました(1回目の事前準備に1時間半、2回目の事前準備に30分)。

成長を促進するために

学習活動は、本人のモチベーションが重要なので、学習対象者にこの勉強会を楽しく感じてもらえるように指導係が振る舞うと、成長が促進されます。
いくつかポイントを紹介します。

直接的に問題点を指摘するのでなく、質問をきっかけに自分で問題点に気付いてもらえるように指導する事がお勧めです。
これは、他の人に問題点を指摘されるよりも、自分で気付いた方が、その知識が定着しやすいからです。
それに、問題を指摘されるとがっかりしていたメンバーが、自分で問題に気付いた時は嬉しい表情を見せたりします。
詳しくは本連載の第4回『コーチングプログラミングで楽しく成長する』で、具体的な会話例を紹介していますので、そちらを参照ください。

同様の理由で、学習対象者に成果を説明してもらっている途中で、基本的な問題を見つけても、その時点では指摘せずに、いったん説明を最後まで聴きます。
基本的な問題なら、説明しながら自分で気付く事があるからです。

学習対象者が事前準備をうまくできなくても責めないことも1つの手段です。
例えば、「対象の設計パターンが難しくて事前準備ができなかった」という時は、ペアプログラミングで一緒に考える事も有効です。

あとは、とにかく些細な事でもポジティブフィードバックをたくさん行って、「学習をやらされている」とならず「勉強会が楽しい」と感じてもらえるようにしましょう。

取り組みの効果

デザインパターンを題材にすると、23回分の設計と数千行のコーディングの経験値が得られました。
その結果、「経験が少ないとテンパる」ことによる初歩的な問題は、なくなりました。
この勉強会を始める前と比較すると、設計を任せられるまでにかかる期間が短くなりました。

私のプロジェクトのメンバーは、この勉強会を楽しみながら取り組んでくれましたので、楽しくスキルアップするという点でもお勧めします。

---

連載「ハピネスチームビルディング」の次回の記事はこちら↓

前回の記事はこちら↓