Renee Troughton氏は、企業のアジャイル移行を支援する、南半球で最も経験のあるコーチのひとりだ。ファイナンスや保険、年金、政府機関、テレコミュニケーションなどさまざまな分野において、小さな組織から大規模組織まで、豊富な経験を持っている。“Agile Forest”の著者であり、‘Who is Agile Australia and New Zealand’の共著者のひとりでもある氏は、Agile Forestブログにも多大な貢献をすると同時に、世界有数のポッドキャストであるAgile Podcastsの共同代表も務める。企業のアジャイル移行の他にも、かんばん方式やアジャイルのスケールアップ、ソフトウェア開発以外への適用を専門とする。
近日開催されるAgile Indonesiaカンファレンスで講演予定の氏が今回、システム思考を用いた組織の移行やリーダシップパターンの重要性についてInfoQに語ってくれた。
InfoQ: まずはご自身について、簡単な自己紹介をお願いします。
Renee Troughton: 私はさまざまな事に関心と熱意を持っています。仕事の新しいやり方を見つけ、他の人たちと分かち合うことで、世界を良くしたいと思っているのです。私は自分を単なるアジャイルコーチだとは思っていません – さまざまな方法論やアプローチを用いて、科学的かつ現実に効果のあるものを重視したいと思っています。トレーニングやアドバイス、視覚化支援、ポッドキャスト、(アジャイル関連の書籍などの)執筆活動、そして何よりも、人々の変化をサポートするために活動しているのです。
InfoQ: “The Agile Forest”という本を執筆されていますが、タイトルが意味深ですね。どのような内容のものなのでしょう？
Troughton: この本(まだ執筆の途中ですが)は、アジャイルの知識のない人たちを対象に書いたもので、私たちが普段使っている用語を使わずにアジャイルを説明しています。“Who moved my cheese”や“The Phoenix Project”のように、寓話を通してアジャイルを教えています。
Agile Forestはオーストラリアの有袋動物のグループのひとつで、脅威と技術と原則とを持って自身の状況に対応しています。
InfoQ: ご存知のようにスケールアップは、アジャイルの世界でホットなトピックのひとつですが、インドネシアではまだ注目されていません。スケールアップとそのベストプラクティスないしフレームワークについて、説明して頂けますか？
Troughton: “Scaling Agile Tricks”という一連のブログ記事では、スケーリングに関するベストプラクティスのいくつかについて深く掘り下げています。具体的にはLeadership Cellのコンセプト(大規模なデリバリチームをサポートする人たちの役割と作法)、核分裂的チーム分割、パイプライン管理へのアプローチ、チームの経済構造といったものです。これらはブログでも取り上げた、スケールアップの上で重要なコンセプトなのですが、スケールアップにおいて私が本当に取り組もうとしている究極の原則があります。
ハンドオフと依存関係の削減
フローの改善
“正しいものを正しく作る(building the thing right and building the right thing)”ことの改善
アジャイル、リーン、デザイン思考の統合
これら原則の成果として、特定のフレームワークを使用することは(４原則にすべて対処するものは存在しないので)少なくなりました。その組織の構造において有効なものを試し、幅広いプラクティスやテクニックを集めたツールボックスをシェアすることで、問題に対して適切なツールを提供することが可能になります。ひとつのフレームワークを選択するというのは、ハンマーを手にして、すべてが釘であると思うようなものです。
InfoQ: アジャイルにはたくさんのハンマーがあって、その多くは商業的な利益を動機としていますが、Spotifyの“モデル”はそういった商業目的のないモデルのひとつのように思われます。“モデル”を適用することについて、どのような意見をお持ちですか？
Troughton: モデルとして何を分類するかによりますね。どちらかと言えばそれはアプローチの方で、Spotify自体にとっては動的にただ与えられる類いのものなのですが、それを再現したいと思うのであれば構いません。
私は以前に、ギルド(Guild)、トライブ(tribe)、チャプタ(Chapter)を採用した環境でコーチをしたことがあります。実際に機能させるのは本当に難しいのですが、最終的にモデルとして実現したのはそれだけではありません。
ギルドとチャプタを効果的に活用する上で問題になるのは、ギルドやチャプタの問題に対処あるいは貢献する時間を確保することです。デリバリ作業が多かったり，パイプラインにおけるチームへのプレッシャが原因で，こうした時間を確保できないことは少なくありません。この結果は，“効率を改善している暇はない(we don’t have time to work smarter)”という格言にすべて現れています。
この問題を解決するパターンはいくつかあります – デリバリ以外の時間として9/10日をシステムに組み込んでおく，負荷の大きな作業を支援する余裕を持った要員を各ギルドに割り当てておく，などです。残念ながらほとんどの組織が，ギルド導入時にこのような施策を何も用意しないまま、十分なメリットを実現できなかったことに悩んでいるのです。
ギルドとチャプタは、組織における二重の要求と制約に対処するテクニックです。制約すわなち – チームはエンドツーエンドの価値提供を行なうために最適化されていますが、その構成員は高度な専門性を持つことが少なくありません。加えて、複数のチームが同一システムないしチャネルで作業することから、組織にはエクスペリエンスとルックアンドフィールの両面、およびメンテナンス性において、ある程度の一貫性が必要となります。これらはチームに対する外部的な制約ないし要求です。さらには、システムあるいはチャネルよりも広い一貫性を求める、ガバナンス制約のような制約も潜在的に存在します。このような状況でギルドやチャプタを適用してもうまく行きません。制約に対するソリューションのひとつではありますが、組織システム全体に関わる制約を見た上で、すべてのソリューション選択肢のトレードオフやリスク、問題点を定義しなければならないのです。その上でアプローチやテストを選択し、それが有効であるかを試します。ただし、それに執着してはいけません – もしそれが有効でなかった場合、できる限り早い段階でそれを見つけるにはどうすればよいのか。それを採用するためには、あるいは他の選択肢に方向展開するためには何ができるのか。そういったことを探しましょう。このようなプロセスのエンパワーメント、アダプテーション、インスペクション、ピボットこそが、Spotifyの成功の中核なのです。ギルドやトライブなのではありません。
InfoQ: インドネシアではまだ、スケールアップを検討したり、あるいはSpotifyのアプローチのようなものに注目している企業はほとんどありません。大部分の企業はScrumから始めています。あなたはかんばん方式においても豊富な経験をお持ちですが、おもな違いは何ですか、また、企業が適切なフレームワークを選ぶにはどうすればよいのでしょう？
Troughton: Scrumとかんばんの大きな違いは、おそらく基本的なアプローチでしょう。Scrumには、既存の開発プロセスを置き換える感覚があります – 現在のやり方を捨ててスプリントを始める、というようにです。このことは、Scrumが求めている解ではなかった場合のチームの反応から分かります。彼らは共通問題にアプローチする方法を知らず、これまでの方法を続けていてはいけないと思いながらも、答を見つけられずにいるのです。一部のコーチは、Scrumを実施するからといって、それまで行なっていた“他のもの”をすべて捨てる必要はない、と言うかも知れません。しかしながら、私の経験から言って、早期採用パターンには混乱が付きものです。
かんばんでは、今やっていることを出発点として、プラクティスや原則を追加していく方法を採用しています。このかんばん方式は、代替アプローチではなく追加的なものであり、初期のフラストレーションはそれ程厳しいものではないと言えます。
導入の観点から見ると、第２の大きな違いはタイムボックスです – Scrumに明確で規則的なタイムボックスがあるのに対して、かんばんは継続的で管理されたフローに重きを置いています。
どちらも“コミットメント”、もっと正確に言うならば“計画されたインテント”という概念を持っていますが、Scrumのインテントがスプリント計画jにおいて定義されるのに対して、かんばんではサービスのサイクルタイムのクラスによって定義されます(ただしEnterprise Services Planningでは、定期的なコミットメントのケイデンスも提案しています)。
Scrumとかんばん方式は、継続的な調査と適応を推奨している点や、スループットの計測を重視し、より効果的な適応のために利用している点については共通しています(ただし、実施のメカニズムの強力さという点では、かんばん方式に分があると思います)。
Scrumでは計画のために見積を行いますが、かんばんでは必要ありません(実際には予測のために使用していますが)。
Scrumの視覚的な管理は非常にシンプルなもので、作業はタスクに分割され、各タスクが“To Do”から“Doing”、そして“Done”に移動します。一方のかんばん方式ではタスクへの分割は行なわず、視覚的な管理はサービスクラス別の作業の流れを表すために使用されます。ボードのフローを移動するのはタスクではなく作業です。
組織で何を使用するべきかは、“それぞれ”という答になるでしょう。一週間以内にスコープの変更を継続的に受けていて、それを受諾せざるを得ない状況であれば(１週間保留して１ないし２週間で提供するというのでは遅延コストが大き過ぎる、というような場合)、私はいつもかんばん方式を推奨しています。それ以外の場合、作業期間が有限で中核的な目標があるならば、Scrumの方がよいかも知れません。
個人的には、私はいつも両方のよいところを持ったチーム(いわゆるScrumban)としてスタートさせて、スケールアップしたチームに対する制約が時間とともにフローへと移行するのに従って、よりピュアなかんばん方式へのシフトを試みるようにしています。
Enterprise Services Planningの一員として、このような変革は望ましいものと思っていますし、かんばん方式に対する長年の批判を覆すための強力な試みであると感じています。
InfoQ: ホラクラシ(Holacracy)に関する話もありましたが、この用語を知らない人たちのために、簡単に説明して頂けますか？ホラクラシは企業をどのように救うのでしょう？
Troughton: ホラクラシの提唱者であるBrian Robertson氏によると、組織内における自己管理のためのオペレーティングシステムだということです。ホラクラシについて初めて聞いた人のほとんどは、“ああ、マネージャを持たないアプローチなのか”と考えます。ある意味それも真実ですが、それだけでは本来の力について理解できません。
組織がホラクラシ憲法(Holacracy Constitution)など一連の規則にシフトする時には、変革への極めて強いコミットメントを示しています。移行はまず、権限を憲法に委譲することから始まります。マネージャが解雇されることはありませんが、マネージャという役割はもはや存在しません。マネージャが実行する必要のある機能は、組織の人たちによって新たに確立されます – これはつまり、以前の役割が新たな５つの役割に分割されることを意味します。同じ人が５つの新しい役割をすべて果たすかも知れませんし、何人かの人のものになるかも知れません。
アジャイルが製品開発の検証と適応のためのアプローチであるとするならば、ホラクラシは組織の役割と責任のためのアプローチであると言えます。
アジャイルと同じように、ホラクラシにも検査と適応の検査と作法があります – ガバナンスミーティングと呼ばれるものです。ガバナンスミーティングを通じて新たな役割が生み出され、責任と期待が変更され、役割が取り除かれます。アジャイルの作法に比べると、ガバナンスミーティングはずっと分かりやすいもので、非常に具体的な問題を一度にひとつずつ処理していきます。これはつまり、ひとつの役割が、同じミーティング内で何度も変更される可能性がある、ということにもなります。
このようなアプローチには、次のような非常に明確なメリットがあります。
自身の役割とアカウンタビリティに対する強力な権限委譲。
問題発生時における迅速なアカウンタビリティの適用。
意思決定権とポリシに関する明確なアカウンタビリティ。
コンセンサス構築や変革への賛同獲得に要する時間の排除。
私はコーチとして、エンパワーメントの改善、アカウンタビリティ、意思決定権限の下位委譲、変革に関するコンセンサス構築などに多くの時間を割いてきました – ホラクラシはありがたいことに、こういった毎日の活動を不要なものにしてくれます。
InfoQ: Agile Indonesia 2017でのあなたの講演は、5%がアジャイルの作法に関するものになる予定ですが、観客としてはどのような講演を期待できるのでしょう？
Troughton: 私たちはコミュニティとして、Sprint計画やデイリースクラム、レトロスペクティブ、ショーケースやデモといった能力向上に力を入れています。これらは製品を提供する上で重要ですが、チームがその中で作業するような、完成したシステムではありません。
システム思考の観点からは、既存の重く官僚的なプロセスを軽量かつシンプルなアプローチに置き換えるという当面の作業においては、Scrumが役に立ちます。しかしながら、時間が経つと、ポリシと制約の再適用が始まります。アジャイル導入を成功させる上での課題は、チームがアジャイルやScrumをやることではありません。システムが自身を再導入するよりも前に、システムのポリシや制約を作りなおす、ということです。
講演では、アジャイル移行と並行して実施される、システム移行を重視する方法について話すつもりです。
InfoQ: Reneeさん、明確な意見をありがとうございます！
Troughtonについてもっと詳しく聞きたいのであれば、氏のプロフィールを見るか、あるいはAgile Indonesiaに参加するとよいだろう。
この記事を評価
- 編集者評
- 編集長アクション