Lean Kanban Benelux 2015カンファレンスでJeroen Molenaar氏は，オーストラリアのワールド・ソーラー・チャレンジで優勝したドイツのソーラーカーチームに，アジャイルコーチとして参加した経験について講演した。
InfoQは氏とのインタビューで，氏がチームをどのように指導したのか，チームはどのようにアジャイルを受け入れたのか，ソーラーチームのコーチングはソフトウェア開発チームのコーチングとは何が違い何が同じなのか，この学生チームの指導を通じて氏自身が何を学んだのかを聞いた。
InfoQ: Nuonソーラーチームでどのようなコーチングを行ったのか，簡単に説明してください。
Molenaar: このチームは毎年，新しい車を作っています。プロジェクトに参加する学生は毎年変わります。正式な企業としてレースチームを運営するために，彼らは１年間にわたって通常の研究を離れます。企業経営にはさまざまな課題がありますが，１年間，そのすべてを学ぶことができるのです。それと同時に，車も開発しなくてはならないのですから，挑戦する価値は十分にあります。
私たちのアプローチ方法は次のようなものです — １年の初め，私たちはまず，アジャイルとリーンプラクティスの簡単なトレーニングを始めました。いくつかの理論を紹介した上で，それらのプロセスを調整して，翌日からプラクティスと原則を実践できるようにしたのです。
彼らのプロセスを改善し，共同作業を促進するために，私は隔週で彼らと作業をしました。レトロスペクティブを採用して，チームがそれを実行できるようにサポートしました(フィードバックや企業間の契約も支援しています)。ノウハウを翌年のチームに継承するための作業も支援していますが，こちらはまだ試行錯誤の状態です。学生たちはどちらかというと理論に偏りがちなので，机上の理論よりも試験や実験を行うように指導しています。
InfoQ: ソーラーカーの開発にどのようにスクラムを適用したのか，いくつか例をあげて頂けますか？
Molenaar: 彼らにとってスクラムとアジャイルは，非常に重要なツールです。彼らは事前の全体計画(Big Upfront Plan)に慣れていたので，個々の担当を決めた不明確な計画を立てていました。作業に対するチームのサポートもありませんでした。そこに私たちは，視覚的な管理を多く取り入れた，アジャイルとスクラムの作業方法を導入したのです。サブチームを作り，スクラムボードを導入し，サブチームごとのスタンドアップを実施しました。さらに週単位のスプリントを設定して，その終わりには内部デモを実施し，さらにレトロスペクティブを行うようにしました。チーム全体が結果を共有することで，彼らは大きな刺激を受けたようです。最も注目された情報のひとつは，各サブチームがその週のレース時間をどれだけ多く勝ち取ったか，ということでした。
レトロスペクティブは，チームを主体としたものを１週間，個人を主体としたものを次の１週間というように，交互に実施しました。この方法で毎週，チームか個人のどちらかに焦点を当てるようにしたのです。この方法には，すべてのメンバがチーム全体からのフィードバックを隔週で受けられる，というメリットがあります。これによって隠れた問題(elephant in the room)，つまり皆がその存在を認識しているにも関わらず，レトロスペクティブでは表立って扱おうとしない問題の発生を防ぎます。
私が新たに設けたのは，ポートフォリオウォールと呼ぶ，計画全体を示すボードです。ここでは，車を作る上で非常に重要な(ソフトウェアよりも重要な)マイルストンを強調しています。ソフトウェアの場合，期限が重要なことは事実ですが，その時点で提供されているものを使うという策もあります。ですが，レースの時に車のボディがなければ，運転することはできません。つまりこちらの期限の方が，ソフトウェア開発チームが設定するものよりも柔軟性が低いということです。
InfoQ: ソーラーチームのコーチングは，ソフトウェア開発チームのコーチングと何が違って，何が似ていましたか？
Molenaar: 彼らをコーチしていると，エンジニアにはある程度の共通点があることが分かります — やや内向的で，どちらかといえば“ディジタル”ですね。コーチングをしていて，それが一番興味深い点でした。違うのは知識のドメインです。ハードウェアはソフトウェアではない，ということを理解しなくてはなりません。彼らの世界で重要なこと — 計算や予測，部品の名前なども学ぶ必要があります。特にアジャイルコーチングの技術的な面については，ソフトウェアチームを対象とした場合と同じ概念をそのまま適用することはできない，という意味で違いがあります。
InfoQ: この経験から学んだことを教えてください。
Molenaar: アジャイルコーチとして何を学んだかということですよね？一応言っておくと，以下の数値に科学的根拠はありません :)
- レース関係の若者や技術者は人の２倍頑固だということ。例えば，現実生活での実務経験をすべて捨てた自分を思い描いてみてください。それに並外れた優秀さを加えれば，それが彼らの姿なのです。
- 私の知っているソフトウェア開発チームに比べて，５倍早く学ぶということ。私の知るソフトウェアチームは，いつもレガシに対処しなくてはなりません。そのことが彼らの足を引っ張っているのですが，ソーラーチームの面々は自分たちの世界を，歴史を持たない，完全な未開地だと思っているのです。このことが現実を意識し続ける上での課題にもなっています。
- ハードウェアはソフトウェアではないということ。
- 必要なことを賢明にテストする — 百万ユーロのカーボンファイバボディがクラッシュに耐えるかどうか，単純にテストする訳にはいきません。
- 必要なことを賢明に実験する — ボディがクラッシュしても，単純に新しいものを作る訳にはいきません。試行錯誤によって見つけ出したものの中には，すぐにテスト可能なものがあります。テストしかできないような仮定は，実際に走行する車では成立しないと分かった時点で無効になります。新たなパーツを構築するためにテストカートを作る理由がそこにあります。そうすることで，可能な限り早い段階でのテストが可能になるのです。
- 実践的かつアジャイルであることは，どのような場面にも適用できます。上の例を見てください。(専門領域を越えた)共同作業は，どこであっても難しいものです。ですから，勝利できる状態に達したチームで重要な役割を担っているスタッフを引き継ぐというのは，チームにとって非常に難しいことなのです。
全体としてはチームだけでなく，私自身にとっても非常に奥深い経験になりました。すべてのアジャイル/リーンコーチに，レースチームを１年間指導することを勧めてもよいくらいです。何を学ぶのかを説明するのは難しいのですが，どのアジャイル組織にも応用可能な，素晴らしいものであることは確かですね。
InfoQ: ソフトウェア開発チーム以外でスクラムを適用しようと考えている人たちに対して，何かアドバイスはありますか？
Molenaar: ソフトウェアの領域で経験を持っているならば特に，ソフトウェア開発とは違うということを意識する必要があります。ソフトウェアでの経験に必要以上に頼らず，彼らの言葉で話すようにしてください。大事なのはただひとつ，とにかくやってみることです！