"Awesome Superproblem"とは、巨大で複雑、かつ永続的で、コラボレーションを通じてのみ解決が可能な問題のことだ、とLuke Hohmann氏は言う。コラボレーションを機能させる上で重要なのは本気のゲームだ。ゲームの参加者には、より優秀で永続性のある結果を生み出すために、自発的にゲームのルールに従うことが求められる。
ConteneoのCEOであるLuke Hohmann,氏は、Lean Agile Scotland 2017で、Awesome Superproblemについての基調講演を行なう予定だ。カンファレンスは10月4日から6日まで、エジンバラで開催される。
[Lean Agile Scotlandは]優れたソフトウェアを開発するために何が必要かを全体論的に捉え、一般的なトピックを幅広くカバーします。思索を拡張して新たなアイデアを取り入れるためのセッションに加えて、リーンとアジャイルへの新たな旅に出る人たちを支援するセッションも用意されています。
InfoQはこのカンファレンスの様子について、Q&Aやサマリ、アーティクルでお伝えする予定だ。
Awesome superproblemの解決とコラボレーションの成立を難しくしているものは何なのか、レトロスペクティブを企業レベルに引き上げるにはどうすればよいのか、Hohmann氏に質問した。
InfoQ: “Awesome Superproblem”とは何なのでしょう？
Luke Hohmann: 現時点では、次のような特徴を持った問題を"Awesome Superproblem"であると定義しています。つまり、畏怖ないし畏敬といった感情を呼び起こす問題であることから"Awesome"であり、自分ひとりでは解決できず、問題解決に協力が必要であるという意味で"Super"なのです。
InfoQ: なぜ解決が難しいのでしょうか？
Hohmann: Awesome Superproblemの解決を難しくしているファクタはたくさんあります。私自身の経験で感じたことをいくつか紹介しましょう。
おそらく最も重要なことは、今の質問の中にあります – 質問の中で使った"解決"ということばです。それはつまり、食べる、眠る、あるいはバスルームに行くという問題を"解決"できるか、というようなことです。すぐに解決できるかも知れませんが、問題は必ずまた舞い戻ってきます。永続的な問題なのです。
永続的な問題をAwesome Superproblemにするのは、そのスコープとスケールです – つまり、都市の予算策定、仕事の未来、希少な天然資源の共有管理、天候変動への対処といった問題なのです。これらはいずれも"解決"不可能ですが、それでも対処しなくてはならない、すなわち、食べる、眠る、バスルームへ行く、という問題と同じです。
InfoQ: コラボレーション作業によって問題を解決するための条件は何でしょう？
Hohmann: コラボレーションが最も効果的なのは、コラボレーションの基盤としてゲームとゲームのセマンティクスを使う時だと思います。ここでは例として、Innovation Game®のPrune the Product Treeを取り上げたいと思います – 読者の皆さんは、ご自身の好みのゲームないしレトロスペクティブのテクニックを、コンセプトのテストとして使用してください。
目標あるいは達成すべきものがあること。Prune the Product Treeの例でいえば、構成要素のニーズを満足する製品ないしサービスを形にすることが目標になります。
参加者それぞれが、処理可能なリソースとその役割、それらリソースを利用する方法(リソースの採用と解放に関わるものを含む、エンゲージメントとインタラクションのルール)を明確に理解すること。同じ例でいえば、Prune the Product Treeの参加者には、製品機能を表すものとして、限られた数のリンゴが与えられます。あるいは、特に説得力のあるアイデアを提示できれば多くのリンゴを"獲得"できるような、Prune the Product Treeのバリエーションも考えられます。
参加者それぞれが、作業をサポートするために、明確に定義されたスペースあるいは"活動の場"を持つこと。物理的なツリーを使って、本人が直接行なう場合もあります。Conteneo Weaveプラットフォームを使ってオンラインに移行することで、分散型チームや規模の大きさに関わる課題に取り組んでいる組織も少なくありません。
目標の進捗状況に関する明確なフィードバックがあること。Prune the Product Treeでは、すべての参加者が結果を見ることができます。
コラボレーションの結果が、参加者に対して重大な影響を持っていること。Prune the Product Treeが最もうまくいくのは、参加者のフィードバックが対象となる製品ないしサービスを補正する、という確証の持てる場合です。
自発的な参加であること。彼らはコラボレーションを強制されてはいません。
ゲームがコラボレーションの基礎であることに注目してください。この基礎を実践することは、コラボレーションの多次元的なデザインの異なるディメンションに対応する、という意味になります。最も一般的なディメンションのいくつかを挙げましょう。
直接会うか、オンラインか: リリース計画に従事する単一のスクラムチームのように、コラボレーションが顔を合わせて行われる場合もあります。数十ないし数百のチームが参加型の予算編成を行なう場合のように、オンラインでコラボレーションが行われる場合もあります。
チーム構成: チームは静的であっても動的であっても、あるいは均質であっても異種混合であっても構いません。いずれであるかは、設計者の目標に基づいてアドホックに構成された既存の状況に基づいています。チームは内部のステークホルダあるいは顧客/パートナ、その他の外部のステークホルダで構成されます。
同期対非同期プレー: 参加者はリアルタイムで同時に作業することも、もっと長い時間を掛けて作業を行なうことも可能です。
InfoQ: 自発性とは、実際にはどのようなものでしょう？
Hohmann: {0}Hohmann{/0}: 自発的な参加が最も簡単なのは、それがチーム文化の自然な部分として起きる場合です。チームの行動規範は文化の一部であって、しばしば労働協約の形で表現されます。例えばスクラムガイド(Scrum Guide)では、スプリント計画というプラクティスを定義しています。これは"自発的"なのではなく、むしろスクラム実践時の"要件"だ、という反論があるかも知れません。しかし実際に私が指導したチームは、適切なスプリント計画セッションの真の価値をすぐ見出して、プラクティスとしての継続を自発的に選択しています。このような自発的な参加は、チームがコラボレーションフレームワークの真の価値、すなわち、目標を実現する上でフレームワークが役に立つとチームが考える限りにおいて継続されます。
InfoQが以前、オンラインゲームを使用した大規模レトロスペクティブについてHohmann氏にインタビューした時、氏は大規模なレトロスペクティブにオンラインゲームが適している理由を次のように説明してくれた。
Hohmann: オンラインゲームは低コストで，結果がすぐに分かるからです。関係するチームが都合のよい時間にレトロスペクティブを実施できるので，データ分析の面でも優れています。さらにオンラインという形式は，内向的な人たちや，主要言語以外を母国語とする国の人たちの考えを表現したり，把握したりするにも好都合なのです。
InfoQ: レトロスペクティブを企業レベルに拡大するには、どうすればよいのでしょう？
Hohmann: 数十から60以上のアジャイルチームのレトロスペクティブを運用するような、スケールアップ可能なレトロスペクティブの先鞭を付けたのはConteneoです。そのプロセスは極めて単純です。
企業のリーダ層に対して、複数のチーム間におけるパフォーマンスを向上する意思のあること、プロジェクトの結果として非常にやっかいで解決の難しい問題が特定される可能性を認識していること、この２つを確認します。
改善の機会を特定する上で有効な、ひとつないし複数のレトロスペクティブフレームワークを選択しておきます。Sailboatは、隠喩的でオープンエンド、かつ障害事項と促進事項の両方の特定に有効であるという面から、優秀な候補のひとつです。
レトロスペクティブを促進する上で、ファシリテータとなるチームを特定します。固有のバイアスに対応可能という意味からは、スクラムマスタが自然な選択です。
各チームとのレトロスペクティブをスケジュールします。私たちはこれを直面形式のレトロスペクティブのテクニックで行なったのですが、時間が掛かって大変でした。ですから、大規模なコラボレーションのために設計されたプラットフォームの使用を強く推奨します。
チーム全般にわたるデータを、以下のディメンションから解析します。
カテゴリ(Category): この障害は人、プロセス、テクノロジ、あるいは他のものに関連しているか？問題とカテゴリに何らかのパターンが存在するか？問題とカテゴリに何らかのパターンが存在するか？
スコープ(Scope): チームが修正可能な(コントロールあるいは責任の範疇にある)障害か、あるいは組織的な関与が必要か？この違いを説明する上で、例えば企業レベルでのレトロスペクティブにおいて、Angular 1.6をAngular 4にアップグレードするなどの重要なインフラ変更が特定されたものとしましょう。チームの数がひとつかふたつならば、変更に関する調整はごく簡単ですが、30、70、あるいは100以上ともなれば、全チームを横断するプロジェクト("エンタープライズスコープ"プロジェクト)を立ち上げる必要が生じます。
コストと影響の見積を含んだ、具体的な変更のリストを組み立てます。
チームを参加させて、取り組みたい障害を選択してもらいます。
さあ、始めましょう！
Rate this Article
- Editor Review
- Chief Editor Action