Henrik Kniberg さんはスウェーデンに在住し、世界で活躍しているアジャイルトレーナー＆アジャイルコーチです。2012年8月に米国テキサス州ダラスで開催されたAgile 2012 のセッションでHenrikさんはスウェーデン警察の大規模システム開発でリーン開発を適用した事例を紹介されていました。筆者らも、Agile 2012に参加していたのでインタビューを申し込んだところ、Henrikさんはご快諾して下さいました。インタビューでは、1)Henrikさんの経歴, 2)アジャイルコーチになったきっかけ, 3)スウェーデン警察のアジャイル開発導入事例, 4)世界一周の旅の 4 つの分野に渡り、Henrik さんに質問しました。
Henrik Knibergさんの紹介
Henrik Knibergさんは自分のプロジェクトの体験をベースに、以下に挙げるような実践的なアジャイル開発関連書籍を続々と執筆されています。
- Scrum and XP from the Trenches(日本語訳：塹壕より Scrum と XP)
- Kanban and Scrum: making the most of both(日本語訳：かんばんとスクラム 両者の良さを最大限ひきだす)
- Lean from the Trenches: Managing Large-Scale Projects with Kanban(日本語訳：リーン開発の現場 カンバンによる大規模プロジェクトの運営、オーム社、2013)
これらの中で原文がインターネット上で公開されているものもあります。また、これら著書は多数の言語に翻訳され、世界中で読まれています。
2011年10月には、Henrikさんは家族を連れて、世界一周の旅を始めました。その旅の最初の訪問地が東京であり、Scrum Gathering Tokyo 2011で基調講演者としてアジャイル開発の話、家族で世界一周の旅をし、自分を変えていくという興味深い話などをされました。
1.Henrik さんのこれまでのご経歴について
– （Henrikさんがインタビューアーの手元の日本語メモを覗き込んだので）カタカナが読めるのですか?
少し読めます。（紙を見ながら、日本語で）「プロファイル」。
– そうです。Henrik さんのプロファイルを紹介していただけませんか？
私は東京育ちです。15歳まで東京にいました。父親はスウェーデンの会社で働き、また一時期は外交官を勤めていました。私は日本でアメリカンスクールに就学した後、スウェーデンに帰って全寮制インターナショナル・スクールに就学しました。いつも英語を使っていましたので、私はスウェーデン語より英語の方が得意です。
– 確かに、Henrikさんの英語は素晴らしいですね。
卒業後にミュージシャンになろうと思っていました。
– 本当ですか。ピアノですか？
ピアノもやりましたし、ベースギターもやっていました。
しかし、しばらくすると、私は音楽をやるのは楽しみのためで、仕事としてはどうかな、と考え直しました。ミュージシャンは仕事としてやると、多分楽しくないだろうと思ったのです。そして、コンピュータを仕事としてやることに決めました。大学に入って、コンピュータサイエンスを勉強し始めました。大学はストックホルムにある Royal Institute of Technology です。在籍中に、ソフトウェア開発会社向けのコンサルティングを勉強しました。それから、会社を起業しました。
– いつ大学を卒業されましたか？
今でも卒業していませんよ(笑)。残りは多分10%ですが、時間がありません。大学で勉強して、そして1年間仕事して、まだ大学に戻り、それから会社を作って、4年後に会社を残して、まだ大学で勉強というような形です。将来、年を取った頃になって、ようやく卒業できるだろうと思っています。
– そうですか。
私は元来、技術タイプの人間でプログラマーです。ですが、起業した会社が大きくなれば私はマネジャーになるわけです。数人のプログラマーを管理するのでマネジメントに関わるようになりました。
2000年前後、私はアジャイルの開発方法XPを知り、自分のチームに適用しました。これによって、アジャイルとの関わりが始まったのです。その後、コンサルティングの仕事はたくさんの会社に楽しさをもたらすことができると考えて、コンサル業に戻りました。その後、いくつかの会社に関わりましたが、そのうちスウェーデンのあるゲーム開発会社のCTOになりました。この会社では組織として多数の課題が抱えていたので、スクラムとXPを一緒に導入することを推進しました。
結論としては、スクラムとXPの組み合わせからは良い結果が得られました。私はXPについて良く知っていましたが、スクラムは初めての経験でした。スクラムとXPの相乗効果について、自分でもびっくりし、とてもうれしく感じました。そして、このプロジェクトの経験を簡単な文章にまとめようとしたところどんどん長くなり、書き始めて3日後に一冊の本になりました。（笑）
3日間、一所懸命にベッドでタイピングしていました。この本は「塹壕よりスクラムとXP」の初期の版です。特に本を書く計画がなかったですが。
– すごいですね。
本を刊行した後に、しょっちゅう「あなたと同じ道を進んでいます。ちょっと手伝ってくれませんか」というような電話がかかるようになりました。たくさんの会社に助けが必要だったので、私はコーチに変身しました。これも偶然でした。これは2006年頃の話です。その時、私はたくさんの会社に、アジャイルとリーン開発の導入を手助けしました。教えたり、トレーニングを提供したり、本日のようにカンファレンスで話をしたりして、現在に至っています。妻と4人の小さな子供がいます。
2. アジャイルコーチになったきっかけ
– どのようなコーチになられたのでしょうか。一般的に、コーチングとマネジメントは違いますね。マネジメントは一種のスキルであり、コーチングは人的な要素の比重が大きいのではないかと思います。
私の場合、マネジメントを実際にやり始めた頃、マネジメントはスキルであることは知りませんでした。そのため、私は良いマネジャーではなかったかもしれません。しばらくしてマネジメントはスキルであり、そのための知識は勉強を通じて獲得できるものだと分かりました。
コーチングも同じでした。初めはいくつかの会社から「支援してください」と私に声がかかったので、私は言われた通りに支援をしに行きました。私はコーチングを知りませんでした。私は実践することで勉強しました。実際にコーチングをしながら、どうやったらもっと良くできるか考え始めました。そして、周囲を見回して、良い本を探し、トレーニングに参加し、良いメンターをつけて、多くのカンファレンスにも足を運ぶようになりました。本当に実践することで勉強し、その後に知識について考えます。
– そうですか。一般的なコーチングの本を読まれたのでしょうか、あるいはアジャイルコーチングの本を読まれたのでしょうか？
一般的なコーチングの本を少し読みました。最近、この2、3年かもしれませんが、私はコーチングとメンタリングの違いがやっと分かるようになりました。今まで私がやっていたことは、多分メンタリングに近いではないかと思います。私は実際にやりたい仕事はコーチングです。場合によってコーチングはメンタリングよりももっと強力だと思います。今でも自分自身のコーチングの力をつけようとして、トレーニングに参加したり、本を読んだりしています。
しかし、アジャイルコーチの仕事の場合、メンタリングしたり、コーチングしたり、結局は両方共に必要だと思います。バランスを取らなければなりません。
– コーチングに関する良い本がありましたら、薦めていただけませんか？
ありますよ。Lyssa Adkinsの「Coaching Agile Teams」という本ですね。
– 私も読みました。一般的なコーチングの書籍についてはどう思いますか？
あまりお薦めしません。彼女の本の方が良いし、一般的なコーチングやメンタリングの話も網羅しているからです。コーチを目指している場合、自分自身の現在の弱点にもよります。コーチングのスキルが足りない人もいるでしょうし、コーチングに得意でも、スクラムのことがあまり知らない人もいるでしょう。
– 彼女の本に、アジャイルコーチにもコーチが必要だと書いてありますが、Henrik さんにはコーチやメンターがおられるのでしょうか？
そうですね。コーチにはコーチングが必要です。私もメンターがいます。Jeff Sutherlandさんは定期的にスウェーデンに来て、一緒にスクラムのトレーニングを実施しています。私は自分の仕事を説明し、フィードバックを得ています。Mary Poppendieck さんと Tom Poppendieck さんも私のメンターです。私はこれらの人達からたくさんのことを学んでいます。あと、会った回数は少ないのですが、大きな影響を受けたのは Jerry Weinberg さんです。
3. スウェーデン警察のアジャイル開発導入事例について
Agile 2012 で Henrik さんは「Lean from Trenched: Managing Large Scale Projects with Kanban & Scrum & XP」というテーマで、スクラム、Kanban、リーンを用いて、スウェーデン警察のシステムを開発する60人規模のプロジェクトの事例を紹介しました。この事例は「Lean from the Trenches」の本にも書かれています。インタビューではこのプロジェクトの次のような裏話を教えていただきました。
- アジャイル開発導入の背景
- スクラムとKanbanについて
- プロダクトオーナーについて
- ユースケース仕様書とユーザストーリーについて
- アーキテクチャーについて
- チームに対するトレーニングについて
- 中間管理職について
– 次の質問はあなたの本日のご講演で紹介されたスウェーデン警察のプロジェクト事例についてです。いくつかの質問は技術的な質問ではないかもしれません。
分かりました。
アジャイル開発導入の背景
– Henrik さんがプロジェクトに参加する以前に、スウェーデン警察のプロジェクト担当者はアジャイル開発をアウトソースする経験を持っておられたのでしょうか？
アウトソースですか。いいえ、このプロジェクトは内製でした。但し、たくさんのコンサルタントが参加していました。プロジェクトメンバーの半数以上はコンサルタントではないかと思います。
– なるほどそうだったのですね。プロジェクトメンバーの方々にはアジャイル開発の経験があったのでしょうか？
何人かは経験があったかと思いますが、全員ではありません。コンサルタントに何人かのアジャイル開発経験者がいました。ただし、伝統的な組織で、全然アジャイルではありません。政府の組織でずっとウォーターフォールのアプローチで開発していました。したがって、アジャイル開発はプロジェクトチームにとっては新しい経験です。
– なぜアジャイルを導入しようとされたのでしょうか？
主な理由はこの案件が特殊だったことにあります。このプロジェクトはスウェーデン警察の案件です。開発期間が短く、目立つプロジェクトでした。また、マスメディアに注目されており、プロジェクトの透明性が求められています。プロジェクトチームも従来の開発では成功できないことが分かっていましたので、従来と違った新たなやり方を挑戦しようという意欲がありました。このことが背景にあります。
– 分かりました。内製のプロジェクトなので、契約はないですよね。
契約書を見たことがないのですが、どこかにあるでしょうね。
– それがリリースすべきか機能について柔軟性があった理由の1つだったのでしょうか？
計画はありました。従来の開発計画みたいなものです。ただし、今回の開発はアジャイル開発なので、より早い段階で計画変更の必要性を判断できます。ベロシティー、早期のリリースといったテクニックを用いて、定期的に計画をレビューし、変更の必要性を示し、必要に応じて計画の修正を行っていました。顧客の抵抗もありましたよ。
– そうですか。プロジェクト始まる前に、プロジェクトチームに対し、何か原則を作られたのでしょうか？
私がプロジェクトに入った時点で、プロジェクトはすでに開始後半年が過ぎていました。プロジェクトはスクラムに似た形で開発を行っていました。チームのスクラムマスターは優秀で、アジャイル開発の価値と原則をよく理解しています。私の仕事はこれらの原則の適用範囲を拡大することでした。
スクラムとKanbanについて
– スクラムとKanbanは違いますので、抵抗される可能性がありますよね。
そうですね。大多数の人はKanbanのなんたるかを知らなかったです。これが私に声がかかった理由の1つかもしれません。誰かが「Kanbanはこのプロジェクトに役に立つかもしれない」と考えて、私に声をかけたのではないかと思います。私はKanbanを説明し、Kanbanを利用するかどうか、私の支援が必要かどうかを決めてもらいました。Kanbanに関するトレーニングを実施したのはずっと後のことでした。
プロジェクトメンバーのKanbanに対するイメージは、1つのボードがあり、その上に何かがあって、可視化に役立つという程度でした。Kanban を試用して1ヶ月後に、プロジェクトメンバーと話し合って、何をしているか、なぜこのようにするかを説明しました。
– スクラムチームがKanbanを利用する場合にどのようなメリットがあるでしょうか？
Kanbanとスクラムの大きな違いはKanbanの方が少し発展性があるということです。Kanbanは何をするかを教えることより、現在どこにいるかを明示し可視化するものです。仕掛かり作業(WIP: Work In Process)に対する制限により、ゆっくりとよりよいコラボレーションとよりよいフローが生み出すことができます。
スクラムは解決策です。スクラムを利用する場合、スクラムマスターがいて、スプリントを回していきます。スクラムでは早く結果が得られますが、少し急ぎます。このプロジェクトでKanbanを使ったのは、私がこのプロジェクトに入った時に60人もいて混乱が多いことに気づいたからです。
私はすぐには効果のある解決策が見つからず、どうすれば良いかもすぐには分かりませんでした。そこで、ワークフローを可視化すれば、おのずと作業がよく見えるようになり、レビューもでき、そして、問題を発見できるようになるのではないかと考えました。会社によって、スクラムを使うかKanbanを使うかを判断しています。「Scrum and XP from the Trenches」の本に紹介された事例では、より早く結果を得たいのでスクラムを導入しました。
– スクラムは小さなチーム向け、Kanbanは大きなチーム向けという使い分けがあるのでしょうか？
一概にどちらとは言えません。一般的なパターンとしては、Kanbanはスクラムの上位レイヤに位置するのではないかと思います。
スクラムとKanbanの他の利用方法についてはよく知りませんが、経営陣チームがスクラムで自分達の任務を遂行したり、スクラムチームによっては内部でKanbanを利用するといったことも考えられます。異なるバリエーションのように見えますが、私達がやっていることは会社にとっては共通のパターンではないかと思います。スクラムチームがまずあり、Kanbanを用いてすべてを集めるというものです。
スクラムはバリューストリームの中間に注目し、プロダクトオーナーが何を開発するのかを決め、優先順位や開発内容を調整します。しかし、開発前の段階と開発後の段階については、スクラムは何も述べていません。その一方で、Kanbanはバリューストリーム全体を可視化しています。コンセプトからプロダクトまでを可視化するのです。
プロダクトオーナーについて
– このプロジェクトで、プロダクトオーナーの役割は存在したのでしょうか？
誰かがプロダクトオーナーだという明確な役割分担はなかったです。但し、組織には要求分析チームがあって、チームリーダーがいました。彼女は時々プロダクトオーナーとして、要求の優先順位を決めていました。また、プロジェクト管理者はプロダクトオーナーの仕事をしていました。また、優先順位を管理する委員会もいて、彼らはハイレベルの優先順位を提示しています。特定の1人のプロダクトオーナーはありません。プロジェクトの振り返り時に、このような形式で良いのか、悪いのか、誰も言えません。よく分かりません。（笑）
– あなたの講演のスライドに、顧客が1人示されていました。その顧客は要求をまとめるチームのリーダーなのでしょうか？
違います。彼はもっとハイレベルの人です。開発チームがあって、要求をまとめるチームがあって、その上、予算等を握る人がいました。私はあまり関わりませんでした。
ユースケース仕様書とユーザストーリーについて
– チームはどういう形式で要求を定義したのでしょうか？ユーザーストーリーを利用したのでしょうか？
このプロジェクトではウォーターフォールとアジャイルが混在しており、要求管理やプロセスはかなり従来のやり方を取り入れていました。要求定義はユースケース仕様書を利用していました。実際、誰も好きではなかったです。書くのも苦痛だし、開発者はユースケース仕様書を読みたくないですね。テスターはこの仕様書を使っても、うまくテストできないと不満を述べていました。
実際、あまり利用されなかった状況なので、ユースケース仕様書の存在目的を変更しました。補助的なドキュメントとして、作成当時何を考えていたか、どのようなアイデアがあったのかを示すものへと位置づけを変えたのです。当然、ユースケース仕様書を用いてテストすることはありませんでした。
その代わりに、ユーザーストーリーカードを利用しました。「○○として、○○したい、なぜならば・・・」という形式で短いユーザーストーリーを書きました。裏ではテストケースを書きました。「システムを利用し、これをやって、あれをやって、このような結果になる」というような形式です。カードにIDも付けました。Wiki上では、補足するドキュメントもありました。ユースケース仕様書に対する参照、会議への参照などです。
各カードについて、業務分析者、開発者、テスターで会議を持ち、どうやって動くものを作るのか、制約事項は何か、について議論を行います。とてもインフォーマルなプロセスで、会話ベースです。重要なドキュメントは内部ネットワーク上で共有しますが、ドキュメントは小さいままに留めます。
– ユースケースを出発点として利用し、そこからユースケースのシナリオを切り出し、ユーザーストーリーの抽出を行われたのでしょうか？
いいえ。対応付けは行いませんでした。ユースケースそのものがユーザーストーリーになる場合もありますし、1つまたは複数のユースケースシナリオがユーザーストーリーになる場合もあります。私は深く関わりませんので、詳しいことは言えません。分かったのは、このプロジェクトでは、ユースケース仕様書から離れたかったということです。計画、フォロー、テストに対し、ユースケースは機能しなかったからです。歴史的な理由で、ユースケース仕様書を作成しましたが、会話のインプットとしてしか使えませんでした。
– ユーザーシナリオの優先順位付けは誰がやりましたか？
プロダクトオーナーの役割の人たちが会議をやって、決めました。優先順位はその時点のものです。Kanbanには、１回に上位10位のフィーチャーを入れて、それらを消化した後に、次の上位10位のフィーチャーを入れていました。優先順位はジャスト・イン・タイムに決めています。
– このプロジェクトは三つのステージがあり、最初は10人ほどで始まったプロジェクトが、1年後には30人、2年後には60人以上とプロジェクトの規模が拡大したとお話をされていました。初期のチームは何をされていたのでしょうか？
最初のステージには私は参加していません。そのため推測になりますが、プロトタイプを作ったり、要求をまとめたりしたのではないかと思います。私はプロジェクトに入る時、すでに開発が始まっており、チームは30人くらいいました。私の任務は30人のチームを60人のチームに拡大することです。
アーキテクチャーについて
– チームの中で、アーキテクチャーを担当する人がいたのでしょうか？
正式なアーキテクチャー担当者はいません。確かにプロジェクト管理者の1人がアーキテクチャー周りの調整をやっていました。各チームで3人程度がアーキテクチャーに注目して作業をしていましたが、専門なアーキテクチャーチームがありません。アーキテクチャーは皆の担当だからです。
– 開発したシステムはかなり複雑なようですね。
プロジェクト初期に、もしかしてチームの誰かがアーキテクチャー設計を担当し、ハイレベルのアーキテクチャー設計をしていたかもしれません。重要なのはアーキテクチャー設計した人は必ずチームにいて、変更に際してどう対応すべきかが分かることです。
チームに対するトレーニングについて
– Henrikさんはチームが30人から60人に拡大するタイミングでプロジェクトに入られましたよね。プロジェクトメンバーに、開発方法をどのように教育をされたのでしょうか？
教育はしていません。このプロジェクトには、クロスチームというグループがあり、各チームの各役割の人とプロジェクト管理者と私で構成されていました。プロジェクトのチーム間の重なり部分のようなものです。このグループにインフォーマルなワークショップを実施し、指導しました。ということでトレーニングは少し行っています。でもKanbanについてはトレーニングを行いませんでした。そのため、最初は「これはなんだ」と思われました。それでもみんなが混乱状態に不満を持っていたので、可視化ができたことを喜びました。
– 技術的なプラクティス、例えばテスト自動化、テスト駆動開発はどうされたのでしょうか？
混乱のためにバグの解決が遅れてしまうという品質問題がありましたので、制約事項を作りました。例えば、テストコードを書いてからではないとコーディング始めてはいけませんというようなルールです。それでテスト駆動開発を推進したのです。また、完了(Done)の定義を明確にしています。このようにして、ある程度のプラクティスの実践を促したのです。ただ、必ずしもすべての人がこのようなプラクティスを実践するスキルを持っていませんでした。そのために、インフォーマルなコーチングを多数実施しました。チームに少なくとも1、2名はアジャイルプラクティスの経験が少ない人がいたからです。そのため、テスト駆動開発のワークショップを実施して欲しいという依頼がオンデマンドできました。
– 開発者の方々は柔軟だったのでしょうか？
開発者は柔軟でした。というのは、開発者の多くがコンサルタントだったからです。コンサルタントは、様々な経験を積んでいるのでかなり柔軟性がありました。正社員の中には変化に前向きではない人もいました。特定のプロセスに慣れていたからです。コンサルタントには、変化に前向きな傾向がありました。正社員とコンサルタントの混成チームだったことで、柔軟性がありすぎたり、なさすぎることがなく、適度に柔軟になったと思います。
中間管理職について
– アジャイル開発に懸念を持つ中間管理職やプロジェクト管理者を味方につける何か良い方法があるでしょうか？
いくつかの方法があります。最も大事なのは、巻き込んで何をやっているのを見せることです。中間管理職がそこにいるのに、アジャイルをやる時にその人たちを無視すると、多分抵抗されると思います。中間管理職と話し合って、何をやりたいかを説明すれば、おそらく支援してくれます。アジャイルに関してあまり知らないかもしれませんが、そうすることでポジティブになる可能性が高いです。
時として、様々な理由で中間管理職が抵抗します。コントロールを失うことを恐れることもあるでしょうし、エゴだけのこともあるでしょう。そのような場合にコーチングは有効です。その人が求めていること、何が大事かを突き止めるのです。認知されることを求めているのか、コントロールを求めているのかということです。
中間管理職は組織の上にも下にもつながり、変化を起こすための最善の立場にも、変更を阻止する最善の立場にもなり得ます。
– Henrikさんが警察プロジェクトにKanbanを導入したのは、ある意味でマイルドに変化させる方法と考えることができるのではないでしょうか。このような方法は変化に抵抗する人達に有効なのでしょうか？
例えば、警察プロジェクトではっきりと問題として見えたのはボトルネックでした。すべてのコードはテスト待ちに溜まりました。テスターの前にコードが山積みになり、ついていけなくなったのです。プログラマーはどんどんコードを増やしていきました。それが見えたことで、問題がはっきりしました。この点を変える必要性に合意するのは簡単でした。
世界一周の旅
– 最後の質問ですが、2011年のScrum Gathering Tokyoで行われた基調講演の内容に関するものです。基調講演であなたは家族と一緒に世界一周の旅を出ているとおっしゃいました。
そうですね。日本は最初の訪問先です。2011年10月に出発、8カ国を訪問し、2012年の3月末にスウェーデンに帰りました。
– その旅行の前後で何か変わりましたか？
少し変わりました。旅行を可能にするために、仕事を減らさなければなりませんでした。そのために、自分のカレンダーを空っぽにすることにしました。旅行中は、旅行を楽しむために１カ月に2,3日しか働かないようにしたのです。
旅行から帰ってきた時に、自分のカレンダーは空っぽでした。そこでどんな仕事をしたいかを考えて決めたのです。トレーニングや講演はある程度行うが、コーチングは1度に1つの顧客にしか行わないことを。また、自分が好きなプロダクトを作っている会社を顧客にすることにしました。また、先進的にアジャイルに取り組んでいることも条件になります。アジャイルを始めたばかりの会社を支援するのは簡単ですが、あまり得るものもありません。そのために、先進的な会社を支援することにしました。考えを凝らし、いろいろと試さなくてはなりません。そのような支援を行うために、Spotifyというストックホルムの会社で働くことしました。
旅行もしなくてよく、家族とともに過ごせますから。何もかも新しいので仕事は難しいですが、挑戦があって楽しいです。
– 基調講演で自分のライフスタイルを変えることを目指すとお話をされていましたが、現在の目標は何でしょうか？
興味深い質問ですね。目標の1つは、仕事と生活のバランスを取ることです。 ただ、本当は目標ではなく、常に心がけることです。完全に達成できませんが、少しずつ近づくことができます。
お忙しい中でインタビューに応じて下さいましてありがとうございました。
（日本語で）どうもありがとう！
インタビューを終えて
今回のインタビューでは、スウェーデン警察に多数の開発者がおられ、それらの方々とコンサルタントで大規模アジャイル開発を行ったということに非常に驚きました。ここで、「コンサルタント」の意味は日本とは異なり、社員ではない協力会社の開発者を意味するようです。さらに、個人的にはアジャイル開発のコーチングという点で非常に参考になる、お話を伺えてよかったと思います。
なんとなくクラスのみんなを冗談で笑わせるのがうまいクラスの人気者という印象の方でした。
最後に、インタビューの実施から本記事の掲載までに１年間もかかってしまい、大変申し訳ありませんでした。読者の皆さまとHenrikさんにこの場を借りてお詫び致します。
- 編集注)
- フォーマット変更により、冒頭部分の文章の並びを再構成しました。(2017.4)