BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース すべてのマネジメントをアジャイルに - Fin Goulding氏の講演より

すべてのマネジメントをアジャイルに - Fin Goulding氏の講演より

原文(投稿日:2018/07/26)へのリンク

AvivaのインターナショナルCIOであるFin Goulding氏が、先日のDevOps Enterprise Summit Londonで、組織全体のフロー原理(flow principles)によるアジャイル能力向上について講演した。講演で取り上げられた内容のいくつかについて、詳しい説明を氏に依頼した。

 

InfoQ: 講演では“非効率なオフショア”についての言及がありましたが、あなたの経験から見て、オフショア戦略が非効率になる理由は何でしょうか? パートナシップを意図した通りに運用することが難しい場合、CIOや組織は、どのようにして自らを正当化できるのでしょう?

Fin Goulding: オフショアサプライヤを、単に安価なスタッフ増員として扱う企業があまりにも多いのです。私に言わせれば、それは誤った戦略です。私はブエノスアイレスで、長くオフショア部門を率いていましたが、大きな成功を収めたチームは例外なく、製品のオーナシップやデプロイメントなど、製品提供に関するエンドツーエンドの責任を担っていました。ただし、そのためには信頼と現実的な最低限のガバナンス、真のパートナシップが必要です。それには適切なパートナを見つけて、エンドツーエンドの能力を証明する機会を提供する必要があります。規模を拡大するのはそれからです。

InfoQ: あなたはスクラムが嫌いであることを公言していますが、アジャイル的アプローチに新たに取り組む組織が、あなたの言うスクラムの罠に取り込まれることなく、この分野の進化に乗り出すために、どのようなアドバイスができるのでしょうか?

Goulding: スクラムが嫌いな訳ではありません。ただ、スクラムには大幅な改善が必要であって、それが根本的な部分で混乱を起こすであろうことを、ちょっと冗談で言っただけです。ですが、妻が優秀なスクラムマスタであり、アジャイルコーチであることは認めざるを得ません。私たちの議論はいつも有意義です!私の意見としては、スクラム(とそれを若干拡張したDevOps)はスコープが狭すぎますし、テクノロジ偏重なのです。フロー原理はアジャイルをビジネスチームや顧客にまで拡張することで、すべてのマネジメントにアジリティを注入します。ただし、フローのような最新のアジャイルテクニックを完全に理解するには、スクラム方法論を経験する必要があります。それでも、大規模フレームワークを全員に吹き込んだり、あるいはアジャイル的な願望をトップダウンに押し付けることを勧めるつもりはありません。最適な作業方法に向けてチームが自己管理し、共同作業し、改善することを認めてほしいのです。私にとって、優れたアジャイルコーチは非常に貴重な存在ですが、スクラムやかんばん、フロー、バリューマネージメントといった、幅広いスキルを持った人を採用すべきだと思います。

InfoQ: DOESでは多数の講演者が、学習する組織(learning organisation)について語っていましたが、日常の作業に学習を取り込むことの難しさを感じている組織はたくさんあります。あなたのアドバイスをモデルとして、学習の考え方を身に付けるには、どのように行動を変えればよいのか、何かアドバイスはありますか?

Goulding: 自分から始めることです。あなたがミーティングを通じて継続的に学び、さまざまなトピックをカンファレンスやブログ執筆で披露するのをチームや同僚が見れば、彼らはそれに続こうとするでしょう。それと同時に、チームや個人が直面するすべての問題を、批判の機会としてではなく、学習の機会として捉えることも必要です。チームが今週学んだことをスタンドアップで確認するような、ごく単純なテクニックでも、素晴らしい共有手段になります。とんでもない問題さえも学習機会とするためには、帆船レトロスペクティブ(sailboat retrospective)を使ってみるのも面白いでしょう。

InfoQ: “アジャイルは死んだ。アジャイル万歳” – Ron Jeffries氏の記事の読者は、では、どうすればよいでしょうか?

Goulding: RonやDave Thomas、その他アジャイル憲章の原作者らによる記事は、私たちがアジャイルの方向性を失ったことを訴えているのだと、私は解釈しています。私たちはもはやアジャイルになるのではなく、継続的改善のないツールやフレームワークという形で、アジャイルを購入しているに過ぎないのです。ですから、“アジャイルは死んだ”という場合、それは今日の方法論や役割、ツール、リーダシップ行動の悪い面に注目して、ビジネスのアジリティのための最小のフレームワークであるフロー原理を支える、文化的な変革のメリットについて言っているのだと思います。実際、私は常々、フローの中にいる限り、組織にとって価値のある品質の高い結果をもたらすものであれば、どのようなツールやメソッドやテクニックを使っても構わない、と言っています。ですから、今日の制約を逃れる術がない以上、アジャイルは現在も生きている、というのが私の意見です。

InfoQ: DevOpsチームを組織しているということですが、DevOpsは全員のジョブなのだからDevOpsチームはアンチパターンである、という意見もあります – これについてはどう思われますか?

Goulding: 当社にはDevOpsプラクティスを使うフローチームがあります。これは進化だと思っています。DevOpsには10年の歴史があり、その本来の目的は開発者(Dev)と運用担当者(Ops)との問題の解決にあった、ということを忘れてはなりません。今日のDevOpsは、ビジネスチームと技術チームを含んで、より広く展開されています – 私がDevOpsやDevOps 2.0ではなく、“フローチーム”という言葉を好んで使うのはそのためです。将来的にはこのような総合チームが、最も成功した企業の中核をなすようになると、基本的には考えています。

InfoQ: 多くの企業が、適切なメトリクスの獲得に苦慮しています。講演では、リードタイムとサイクルタイムにのみ関心を持てばよい、という説明がありましたが、どのようにしてその結論に至ったのでしょう、また、それらのメトリクスはどのように可視化し、共有し、利用すればよいのでしょうか?

Goulding: 直接的に改善を示すことのできるメトリクスと、それができないメトリクス(コンバージョン率、NPS、利益など)があるので、重要な指標に対象を絞っているのです。一方で、これらのメトリクスは生産性を目標としているため、チームや、さらに悪い場合には個人の責任追及に使われる危険性もあります。私はいつも、作業項目やストーリがサイズ的に一定であるように注意を払っているので、改善の必要な作業フロー上の問題を容易に特定することができます。場合によっては、新メンバがヘルプを必要としたり、あるいはストーリが複雑過ぎて単純化が必要なこともあるかも知れません。サイクルタイムとリードタイムでは、これが強調されるのです。DOESでの講演では待ち時間も取り上げました。これは真の生産性キラーであり、時には過度のコンテキスト切換につながります。思い起こせば、開発と運用の間の待ち時間が、そもそもDevOpsを生み出す上での原動力でした。

InfoQ: リーダがDevOpsを理解できず、私たちがDevOpsの世界で期待しているような行動(ブロッカの排除など)を見せない場合は、どうしたらいいのでしょう?

Goulding: ハイパフォーマンスな組織が行っていることに関して、“Puppet Labs State of DevOps”レポートが強力な情報源になります。同じような組織のユースケースをリーダと共有するのもよいでしょう。さらに、ビジネス価値に関する明確な言明のない技術用語は、DevOps採用の大きな妨げとなる可能性があります。ほとんどのリーダは、自分が何かを理解していないと認めるのを嫌うので、サポートを得るためには彼らを支援するとよいでしょう。ただし、DevOps導入成功の暁に、彼らが手柄を独り占めすることは覚悟しておいてください!DevOps導入の真っ最中であれば、週次のスタンドアップにリーダを招待して、直接ブロッカを割り当てるのもよいでしょう。

InfoQ: 講演では櫛形人間(comb-shaped people)について言及されていましたが、これはどの程度の一般性があるのでしょう? 誰でも櫛形人間になれるのでしょうか?

Goulding: 私は何年も前からHR 2.0というものを推奨しています。T型、π型、櫛形人間に関しては、多くのHR専門家と議論してきました。テクノロジの世界では、アプリケーションの設計とコーディング、データベース構築、テスト、アプリケーションのデプロイのできる人がたくさんいます。なぜこれらの職種が分割されるようになったのか、私には疑問です。確かに多くの企業では、責任分担図がきれいに描かれていますし、おそらくはそれをスケールアップしようと努力しています。しかしながら私は、ギグエコノミ(gig economy)のような新たなパラダイムによって、私たちは単一スキルセットを離れて、マルチトレーダの人生を選択することになると考えているのです。このことが、DevOps 2.0ないしフローチーム(DevOpsをビジネスチームやテクニカルチームにまで拡張したもの)と相まって、これらの人々を最も価値のある雇用対象者にするでしょう。そう、彼らを従来の職歴以外の業務に従事させることができさえすれば、櫛形のプロフェッショナルをあなた自身で育てることが可能になるのです。

AvivaのインターナショナルCIO以外に、Fin Goulding氏は、“Flow – A Handbook for Change Makers, Mavericks, Innovation Activists and Leaders”や“12 Steps to Flow: The New Framework for Business Agility”、“From DevOps to Flow: Creating Teams That Win the Future”といった書籍も著している。

 
 

この記事を評価

採用ステージ
スタイル
 

この記事に星をつける

おすすめ度
スタイル

BT