昨年、テスト駆動開発のエバンジェリストである和田卓人(t-wada)さんと共同で、社内で2回のレガシーコード改善ワークショップを開催しました。概要については、以下の記事に詳しく書かれています。
このワークショップの最大の特徴は、実際の製品のソースコードを対象に自動テストの作成やリファクタリングを行うことです。
題材となるコードを探す作業から始めるため、準備には手間がかかりますが、開発チームがレガシーコードに向き合うスキル・マインドを育成するために非常に有効な手法だと感じています。このため、今年も他の製品開発チームを対象に同様のワークショップを計画しています。
この記事では、今後の開催に向けてこれまで運営として取り組んできたことをまとめ、「レガシーコード改善ワークショップの良いところ」と「ワークショップ開催の具体的な流れ」として説明します。
レガシーコード改善ワークショップの良いところ
参加者が手を動かして学ぶ
プログラミングの上達のコツは、文法や手法を暗記し、「いざ」というときに備えることではありません。目の前の課題を解決するために、繰り返し手を動かすことだと思います。知識を頭に入れるというよりも、運動技能を身につけるものとして捉えたほうがわかりやすいでしょう。体育などの実技を重視する科目と同じですね。
ワークショップでは、ただ理論を頭に入れるだけではなく、手を動かして実践し「できる」という体験を積み重ねることで「好きになる」というサイクルを作り、技能として身体化していくことができます。
また、参加者同士の相互作用により、単なる「教えられたこと」以上の新しいものを生み出すことも期待できます。
作問チームがワークショップを作り上げることで学ぶ
このワークショップでは、実際に製品のコードを扱う開発者の中からメンバーを募集し、作問チームを立ち上げます。この作問チームのメンバーにとっては、さらに学習の効果を高めることができます。
教え手こそが、最も学んでいるのです。
また、後述する具体的な流れを体験していく過程では、単にワークショップの題材への深い理解だけではなく、組織や開発チームの課題に注目する機会が増えます。これにより、組織の課題を解決するために自身がリードしていきたいという気持ちが強くなっていきます。
現場のコードを題材にすることで、自信につながる
ワークショップの目的は、単に「参加者が満足すること」「楽しいと感じられること」ではありません。ワークショップを終えた後に、学んだことを現場で活用することです。
これを「行動変容」と言います。そして、行動変容につながる先行要因は、研修直後の自己効力感(自信)であるとされています。
ワークショップという場は特殊で、一般には普段の開発現場の仕事と結びつきづらいです。しかし、このワークショップでは、いつも向き合っている製品のコードそのものを扱います。これにより、ワークショップの場と実際の開発現場の乖離が起きづらいです。このため、開発チームの現場に戻った後でも「学んだことを現場で活用できる」という自信につながりやすいのです。
t-wadaさんも「天然もの」のコードのリアルさを重要視した講演を開催されています。
おまけ: t-wadaさんの活躍を目にするたび、体験を思い出す
t-wadaさんは“テスト駆動開発の第一人者”として、さまざまな場で執筆・講演活動を続けています。
その活躍を目にするたび、参加者はこのワークショップの体験を思い出します。そして、そのときの達成感や決意を思い出し、気持ちを新たにできるでしょう。
いわゆる「テスト書いてないとかお前それ、t-wadaの前でも同じこと言えんの？」効果ですね。
ワークショップ開催の具体的な流れ
ここからは、開催前の準備から開催後までの各ステップで実施しておきたいことを、今後、同様のワークショップの企画を考えている方向けのガイドラインとしてまとめています。
以下、実施済みのものと、未実施のアイデアが混在しています。必ずしも効果が実証できているものばかりではありませんが、思いつく限りのアイデアを並べています。また、必ずしもすべてのステップを踏まなければならないというわけではありません。実際にはワークショップをつくる時間は限られていますから、この中から取捨選択をすることになるでしょう。
また、実際に進めていく中でより良いアイデアに気付いたなら、それを積極的に試すのがよいです。最大の成功の秘訣は「自分たちが思いついたさまざまな実験を取り入れ、自分たち自身が楽しむ」ことです。
Step1. 準備
作問チームの立ち上げ
まず、ワークショップを主催する作問チームとして、対象の製品コードを扱う開発者の中から数名のメンバーを集めます。
実は、このワークショップの恩恵を最も受けるのは、作問チームのメンバーです。私が社内講演を企画したときに感じたことですが、人々に情報を伝えるためにイベントをデザインする過程において、その知識・技能は強く定着します。
また、作問チームのメンバーに強く意識させておきたい点は「ワークショップの開催までがゴールではなく、ワークショップ後にチームの文化を変えていき、実際に製品のコードの品質を上げていくことがゴールである」ということです。
その点を強調した上で、メンバーを募集すると良いでしょう。
実務的なところとしては「ワークショップに割ける時間が十分に確保できそうか」「ワークショップ後、複数の開発チームの行動変容を最大化できそうか」などの観点を元に、出身チームや現担当領域などのバランスを調整してメンバーを構成するのが良いと思います。
ニーズ分析
作問チームのメンバーが集まり、準備に向けた心構えができたら、ワークショップのコース設計を始めていきます。
ここで大事になるのが「学び手自身は、何ができるようになりたいと思っているか」を確認することです。「あるべき姿」と「現状」（実際のパフォーマンス）のギャップを見つける、と言い換えることもできます。
これは、教え手と学び手の立場が大きく異なっていると難しい作業です。しかし、このワークショップでは、学び手の中から作問チームのメンバーを募集しています。このため「自分たち自身が学びたいこと」から整理していくのが近道でしょう。
ゴール設定
次に、挙げたニーズをワークショップのゴールに落とし込んでいきます。このときのコツは「明確に、そして観測可能な形にまとめる」ことです。
ゴールの候補を挙げたら、優先度をつけていきます。手法としては、MoSCoW分析などを利用するとよいでしょう。
| カテゴリ | 説明 |
|---|---|
| Must | 必須 |
| Should | 可能であればすべき |
| Could | 望ましいが必須ではない(MustやShouldの実現を妨げないなら、実現が望ましい) |
| Won't | 対応不要(現時点では取り組むべきではない) |
一例としては、下記のような結果になります。
- Must
- 一日で終わる分量である
- データベース接続を伴うメソッドへの仕様化テストが書ける
- Should
- メソッドやクラス分割などのリファクタリングを試せる程度の複雑さがある
- Could
- 学び手にとって、ドメイン知識が理解しやすい
- 自動テストのサイズダウンが体験できる
題材づくり
実際の製品のコードの中から、設定したゴールを満たすようなコードを探します。選んだコードに対して実際にテストを書いて保護し、内部品質の改善に挑戦していきます。
複数回のモブプログラミングを実施し、t-wadaさんからのナビゲートをいただきながら、作問を進めていきました。作問チームのメンバーにとっては、ここが一番楽しく、スキルアップができるところです。
その結果を作問チームとしての模範解答例としたうえで、当日のワークショップで参加者に手を動かしてもらう範囲を決めます。
施設・設備・物理的な制約の確認
ワークショップの参加者にとって、快適に学ぶことができる環境を用意することも重要です。
コースは一定の制約の中で実施される．たとえば，次のような制約がある．
• 使える施設や設備（教室，会議室，ホワイトボードなど）
• 使える資源（プリント配布，スライド，レクチャーなど）
• 物理的な制約（時間的な長さ，教室の広さ，体を動かせるかなど）
• 一緒に学んでいる仲間
このような制約の中でコースが実施され，その中で学習者が学んでいく
インストラクショナルデザイン ― 教えることの科学と技術 ― Instructional Design : The Art and Science of Instruction 【2012年版】 5.5 コンテキスト分析 より引用
ペア(モブ)プログラミングをおこなう場合は、どのような考え方でチームを決めるのかが鍵となります。一例ですが、私は下記の点を重視しました。
- 2人または3人チームとする
- 3人より2人のほうが手を動かす時間が長くなるため、できるだけ3人チームより2人チームを増やす
- チーム間で比較した際に、現在のコーディングスキルが同じくらいになるようにする
- できるだけ普段と同じキーボード配列（JIS/US）が利用できるようにする
- コンテキストが共有できるように、できるだけ一緒に仕事をしたことがある人同士で組む
- 誰か一人、チームをリードできそうな人を入れておく
- メンバーに初心者が居る場合は、必ず3人チームにする
参加者の属性については、後述する事前アンケートや所属長などへのヒアリングを通して確認しました。
事前アンケートの配布
事前アンケートの目的は、前述したチーム分けのための情報集めと、ワークショップの効果測定のための準備です。このため「参加者の現在のスキル」と「これまでの自身の行動・経験」を中心に確認していきます。
下記のような設問を用意するのが良いと思います。
- 単体テストに対する一般的な知識・経験
- 対象の製品のコードに対して、テストを書いた経験
また、前述したニーズ分析のための情報を、事前アンケートにて集めることもできるでしょう。
最終準備
日程が決まったら、イベントの開催概要についての告知をおこないます。ライブコーディングを行う場合は、当日のドライバーやシナリオを決め、練習を重ねます。
もう一つ大切なことは、ワークショップ参加者の準備を完了させることです。
大人数のワークショップを行う場合、個別の環境トラブルが発生しがちです。せっかくのワークショップの時間を環境トラブルの解消に費やしてしまうと、とてももったいないことになります。
このため、事前にできるだけ対策する必要があります。たとえば、私は対象製品コードのリポジトリから、研修に使う部分のみを分離したワークショップ用リポジトリを作成しました。そこにセットアップの成功を確認するための HelloWorldTest を用意しておき、参加者全員に事前の動作確認を依頼しました。その甲斐あって、当日のワークショップにおける環境トラブルは全くと言えるほど発生しませんでした。
また、後述する「事後アンケート」は開催直後に配布したいものです。このため、必ず開催前までに用意しておくようにしましょう。
Step2. ワークショップ当日・前半(ライブコーディング)
ワークショップの前半は、作問チームによるライブコーディングを視聴することで、参加者が流れを理解するパートになります。
作問チームのメンバーがドライバー、t-wadaさんがナビゲーターとなるペアプログラミング形式で進行していきます。残りの作問チームメンバーはSlackの実況スレッドへの反応や、予期せぬトラブルへの対応に徹します。
ライブコーディングが長時間にわたる場合は、ドライバーに負担がかかり、集中力が切れることも考えられます。この場合、ドライバーを複数人で担当し、駅伝のように交代しつつ進めると良いでしょう。
あらかじめドライバーを交代する箇所を決めておいて、もし予定時間までにドライバーが到達できなかった場合は、用意した状態からの繰り上げスタートをおこないます。これにより、ライブコーディングを予定時間内に終えられるでしょう。
Step3. ワークショップ当日・後半(参加者が手を動かす)
ワークショップの後半は、チームでのペア(モブ)プログラミング形式で、参加者が手を動かすパートです。
学習のために必要な準備状態をつくる
学習の効果を高めるために、ペア(モブ)プログラミングの心得を説明してから開始します。実際に、私が強調したのは下記の点となります。
- ドライバーとナビゲーターに分かれて作業をすること
- ドライバーは考えていることや疑問をナビゲーターに伝えること
- わいわい進めるのが成功の秘訣です！
- ドライバーとナビゲーターは交代していったほうが良いこと
- おすすめは時間での交代。経験上、7～8分での交代がGood
- 適宜、チームで休憩の時間を挟むこと
- 「確実に成功させる」場ではなく、「実験を通して学ぶ」場にすること
- チームで思いついたアイデアは、積極的に試してみてほしいこと
- その体験を通して「安全な実験」のやり方を学べるはず
ほかにも、チームのアイスブレイクのために、たとえば「いまの気持ち」や「どんな時間にしたいと思っているか」をチームメンバーに伝え合うような、簡単なチェックインをしてもらうのも有効であると思います。
ワークショップでは「参加者同士の相互作用」を促進し、単に教えられたことだけではなく、何か新しいものを生み出す時間にすることが重要です。各チームを見回り、参加者同士が協力しあいながら、課題に取り組めているかを観察しましょう。
発表会（コードレビュー）
ワークショップの中間や終わりには、いくつかのチームに取り組んだ内容を発表してもらう機会を設けます。t-wadaさんからは、発表内容への質問や良い点を具体的に指摘いただいています。
発表してもらうチームは、作問チームが見回りをする中でピックアップしました。立候補を募るなど、別の方法でも良いかもしれません。
ワークショップの終わりには、各チームの作成物をそれぞれのbranchにpushすることで、後から詳しく確認できるようにしました。
Step4. 開催直後
ワークショップの開催を終えると、走りきった達成感で気が抜けてしまいがちです。
しかし、ワークショップの開催がプロジェクトの終わりではありません。ワークショップはあくまでも「きっかけ」に過ぎません。学んだことを現場で活用し、自分たちのコードの改善に向かうためには、ここからの取り組みが本番となります。
ワークショップの開催で満足しきってはいけないのです。
事後アンケート
ワークショップの開催直後には、参加者向けの事後アンケートを配布します。
事後アンケートは、単なるワークショップの満足度の確認のためのものではありません。今後の現場での活用に向かって、参加者の意識を高めるための大事な仕掛けです。
事後アンケートでは、ワークショップでの体験に関して、普段の開発業務に照らし合わせての関連度・有用度・自己効力感を質問します。質問フォーマットは、下記のようなものがよいでしょう1。
- 以下の文章について、当てはまる番号に◯をつけてください(5: まったくそう思う ～ 1: ぜんぜんそう思わない)
- ワークショップで学んだ内容は、自分の仕事に関連していると思う
- ワークショップで学んだ内容は、自分の仕事に役立つと思う
- ワークショップで学んだ内容を、自分の仕事に活用できる自信がある
- フリーコメントでご記入ください
- このワークショップで「学んだこと・得たこと」は何ですか？
- このワークショップで学んだことを、いつ、どんな場面で活用できそうですか？
- その他、ワークショップへのご意見などありましたら、お願いします
活用できそうな場面を参加者自身に言語化してもらうことで、現場での行動のイメージが湧きやすくなります。このため、記憶が新しいうちに、できればワークショップの翌日などではなく、当日の終了時に記入をお願いするとよいでしょう。
ワークショップの内容のリマインド
参加者へのお礼を兼ねて、ワークショップの内容のおさらいを含むような投稿をすると、リマインドに繋がります。
作問チーム内のふりかえり
事後アンケートを回収したら、ワークショップ開催の効果確認・改善点を探るためのふりかえりをおこないます。作問チームのメンバーがそれぞれの現場でおこなうアクションについても、具体化していきます。
Step5. 開催から数カ月後、そして…
実践確認アンケート
繰り返しますが、ワークショップの目的は、学んだことを現場で活用することです。
このため、開催から3～6ヶ月後には、参加者がワークショップで学んだ内容を実践できているか、実践できていないのであれば何が障害となっているのかを確認します。具体的な質問フォーマットは、下記になります2。
- あなたの状況として、あてはまるものを選んでください
- ①ワークショップで学んだことを、仕事で活用しなかった
- ②ワークショップで学んだことを、仕事で活用し、良い結果が出た
- ③ワークショップで学んだことを、仕事で活用したが、まだ結果は出ていない
- ①②③のそれぞれあてはまる設問にお答えください
- ①と答えた人に、お聞きします
- 「活用しなかった理由」は何ですか？
- 「どんな支援があれば」活用できたと思いますか？
- ②と答えた人に、お聞きします
- 「いつ、どんな場面で」活用されましたか？
- 「どんな結果」が出ましたか？
- ③と答えた人に、お聞きします
- 「いつ、どんな場面で」活用されましたか？
- 「どんな結果」が出そうですか？
- ①と答えた人に、お聞きします
このアンケートの配布自体が、参加者にとってのリマインドの効果を期待できます。
また、このアンケート形式では、それぞれの回答に対応するアクションが明確になりやすいです。①に対しては、障害を取り除くための取り組みを組織で考えていきます。②と答えた人の中から成功事例をピックアップし、参加者全体向けに発表してもらうことで、さらに実践を促進することができます。③と答えた方には、実践の継続に向けた勇気づけをするのがよいでしょう。
そうして、内部品質の改善を継続的に取り組んでいく文化を、地道に組織全体に広げていきます。
おわりに
昨年は、計2回のレガシーコード改善ワークショップに関して、運営側の立場として携わりました(私は主に2回目の担当でした)。
t-wadaさんとワークショップの準備をする過程で、私は多くのことを学びました。プログラミングテクニックだけでなく、他の人に何かを伝えるための正確な言語化テクニックや、人々の力を引き出すために粘り強く伴走し、勇気づける姿勢についても学ぶことができました。この記事でワークショップの流れをまとめる過程では、「教える技術」に関する理解を深めることもできました。この取り組みに時間を割けたことは本当に幸運であり、一瞬一瞬が非常に貴重な経験となりました。
記事中でも言及しましたが、ワークショップの開催にあたっては、それを準備する作問チームのメンバーが最も成長します。ワークショップの開催から数ヶ月が経ちましたが、作問チームのメンバーは、学んだことの実践をそれぞれが所属するチームでどのように最大化するか、アイデアを実験しながら行動し続けています。
こういった企画を楽しみながら取り組めるメンバーを増やしていき、品質改善を実践し続ける組織をつくっていきたいです。
参考事例
本ワークショップの開催にあたっては、下記の事例についても大いに参考にさせていただきました。本記事についても、同様に技術的負債に向き合い、開発チームの文化の変革に挑戦しているさまざまな開発現場にとっての助けになれば幸いです。
-
参考: 研修開発入門 「研修評価」の教科書 | 「数字」と「物語」で経営・現場を変える 図表25 | ミニマムコース 研修直後アンケートの例 ↩
-
参考: 研修開発入門 「研修評価」の教科書 | 「数字」と「物語」で経営・現場を変える 図表28 | スタンダードコース 簡易アンケートの例 ↩