先週、チームで「仕様書駆動開発」のハンズオンを実施しました。参加者全員が新しい開発手法を体験し、今後の活用について活発な議論も生まれ、ハンズオンとしては良かったと感じていますが、もっと深い学びの場にできたのではないかということを、最近学んでいるワークショップの考え方を使って考えてみたいと思います。
ワークショップは「創ることで学ぶ」活動
書籍『ワークショップデザイン論』によると、ワークショップとは「創ることで学ぶ活動」です。これに対してハンズオンは「決められた手順を体験して学ぶ活動」と言えると思います。
ハンズオンでは、基本的に想定された結果に向かって進みます。一方、ワークショップでは参加者の試行錯誤や相互作用から、設計者も予想しなかった発見や学びが生まれます。
実際のハンズオンを振り返る
実施した内容を簡単に振り返ります。1時間のセッションで以下のような流れで進めました：
- 事前にGitHubリポジトリを用意し参加者にクローンしてもらう
- テスト駆動開発・振る舞い駆動開発・仕様書駆動開発の概要と違いを説明
- 私が画面でプロンプトを実行しながら参加者も一緒に手を動かす
- /specify シンプルなTODOアプリを作成してください
- 要件定義での質問応答
- /planでの実装計画
- タスクの実行
- 完成したTODOアプリを共有し議論する
良かった点
全員が仕様書駆動開発を体験でき、AIコーディングの可能性を実感してもらえました。また、「チームの開発プロセスにどう組み込むか」という実践的な議論も生まれ、知識の共有という点では十分な成果がありました。
物足りなかった点
当初の目的は達成したものの、より深い学びや創造性を発揮できたのではという観点ではいくつかの問題があると考えられます。
まず、私が画面でプロンプトを実行する形式だったため、参加者自身の試行錯誤が生まれにくかったことです。失敗から学ぶ機会や、「こうしたらどうなるだろう」という実験的な姿勢が生まれませんでした。
次に、AIのランダム性による違いはあったものの、基本的には予測可能な結果に収束してしまいました。参加者それぞれのこだわりや工夫が反映される余地が少なく、「みんなで同じものを作る」体験になってしまったのです。
そして最も重要な点として、「なぜ仕様書駆動開発なのか」を参加者自身が発見するプロセスがありませんでした。私が説明するのではなく、体験を通じて理解してもらう機会を逃してしまったように思います。
ハンズオンをワークショップ的にする工夫
では、どうすればハンズオンをより深い学びの場に変えられるでしょうか。
比較して発見する
複数の手法を実際に試して、その違いを体感してもらう方法があります。例えば、最初の20分でテスト駆動開発を体験し、次の20分で仕様書駆動開発を体験。残りの時間で「どちらがどんな場面で有効か」をチームで議論する。このような構成にすることで、「なぜこの手法が必要なのか」を参加者自身が発見できるのではないでしょうか。
創る目標を設定する
活動目標を「TODOアプリを作る」から「AIをより自律的に働かせるルールをつくる」に変えてみるのも一つの方法です。同じ技術を学びながらも、参加者それぞれが工夫する余地が生まれます。
多様性を活かす
参加者の背景や普段の課題を活かす設計も重要です。仕様書駆動開発の背景を理解した上で「各自が普段感じている開発の課題を、仕様書駆動開発で解決してみる」といった課題設定にすれば、それぞれ異なるアプローチや発見が生まれ、共有する価値も高まります。
時間制約があっても、5分10分の工夫で場の質は変わります。完璧を目指さず、小さな実験から始めることが大切だと思います。
チームの他の場面への応用
この視点は、ハンズオンだけでなく様々な場面で活用できる可能性があると思います。いつもの定例会議や勉強会などの設計を見直してみても面白いのではないでしょうか。
何でもワークショップにするのが良いとは思いませんが、より良い場にしようと試行錯誤するそのガイドとしてワークショップデザインが参考になると思いました。