BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース アジャイルとリーンを組み合わせる

アジャイルとリーンを組み合わせる

ブックマーク

原文(投稿日:2014/01/14)へのリンク

アジャイルとリーンはソフトウエア開発を改善する方法だ。マネージャはどちらが自分たちの組織に適しているか判断しなければならない。しかし、解決しなければならない問題によっては複数の方法を組み合わせることもできる。

agile for building, lean for learningと題した発表でRégis Medina氏はこのふたつの手法を学んだことについて話している。InfoQは氏にインタビューし、アジャイル、リーン、人と学習への着目について話を聞いた。

InfoQ: あなたは"開発のためのアジャイル、学習のためのリーン"について語りましたね。この組み合わせを奨める理由を教えてください。

Régis: アジャイル宣言から10年たって、アジャイルは開発サイクルの短縮、品質の劇的な改善、チーム内の垣根の撤去に効果があり、マネージャの仕事を楽にしてくれることが明らかになりました。しかし、実践でアジャイルtチームが直面する課題を考えると、3つの新しい課題が浮き上がってきます。

  • 正しい製品を作る: プロダクトオーナの仕事を改善し続ける必要があります。イテレーションの最中に方針を変えたり、使われない機能を実装するように頼むプロダクトオーナをたくさん見てきました。ユーザのニーズや要求を集めるということ以上の能力を持つようプロダクトオーナのスキルを開発するのが課題です。これは必要な機能だけを開発するのに必要なスキルなのです。
  • イテレーションの終わりに多くの機能を提供する: 機能の提供がクライアントをいらいらさせることはよくあることです。というのは開発チームとどのように交渉しているかに関わらず、クライアントはクライアントで納期を抱えているからです。このような場合、アジャイルチームには解決策がありません。品質を保ちながら、長時間残業することなく、素早く開発する方法をしらないからです。
  • ほかの部門と良い関係を気付く方法を学ぶ: 企業内には価値の流れがあります。マーケティングチームがより素早く機能を提供して欲しいと考えている場合があります。また、価値の流れのもう一方の終端点である運用チームがあります。運用チームはDevOpの勃興によって機会が生まれています。しかし、アジャイルチームが両者の要望を引き受けるのは難しいです。スケジュールが遅れたり、インシデントが発生してしまったりします。アジャイルチームにとってマネジメントとやり取りをすることの難しさが障害になっているように思います。

このようなトピックを巡って、アジャイルチームは新しいアイディアを探り、試してきました。個人的には、10年間のアジャイルの経験を経て、少し後退してほかのITの領域のリーンから学ぶ機会を得ました。本物のリーンの先生から学んだのです。様々な領域の目覚ましい成果を見ることで、アジャイルコミュニティにとってリーンは大きな可能性を秘めていることに気付きました。

リーンとアジャイルは完全に互換性があるものの、元々はかなり違います。リーンはプロセスを改善するためのプロセスやツールではありません。エンジニア個人が先生の助けを借りながら開発するマネジメント法です。リーンを実践するマネージャとチームリーダーは次のことを学びます。

  • 顧客満足の改善方法。期待を上回る方法。
  • 計測可能な著しいパフォーマンス改善を得て、チームを企業のニーズに結びつけるための機会を見つける方法。物事を正しく終わらせ、人々の間の仕事の流れを改善し、ある特定のタスクが素早く完了する方法を見つける。
  • チームのメンバが正しいスキルをより素早く身につけ、どうしたらパフォーマンスを改善できるかしっかりと考えることができる職場環境の作り方。

InfoQ: リーンとアジャイルの組み合わせによって、顧客に提供する価値がどのように向上するでしょうか。

Régis: アジャイルは反復的な性質を持っていますので、顧客、少なくとも顧客の代表者をプロジェクトに巻き込むことが多いです。顧客の視点からプロジェクトを見ると完全の余地があります。これは簡単なことではありません。顧客の要望は必ずしも本当に欲しいものではないのですから。

こんなときにリーンが役に立ちます。

  • リーンは“行って見る”という習慣を生み出します。リーンでは“現地、現物”と言います。現場に行って、顧客の文脈を理解し顧客が解決しようとしている課題を定式化することです。
  • リーンは製品やサービスに対する顧客の理解や期待を分析する枠組みを提供します。価値と無駄を見つけられるようになります。これは顧客の経験を理解し、製品を改善して可能な限り無駄が少ないようにするのに役立ちます。
  • 目的に応じてプロジェクトのメンバを配置するのにも便利です。開発するべき機能のリストに注力するのではなく、問題を解決するのにフォーカスを当てるためのメンバです。
  • 製品の進化を、顧客の文脈をよりよく理解するために役立つ継続的な実験の流れ、として見ることができます。

InfoQ: アジャイルもリーンも人に着目します。なぜ人に敬意を払うのでしょうか。

Régis: アジャイルは利害関係者のコラボレーションをコミュニケーションを強化し、チームが受領可能なペースでよりよい仕事をするのを支援する環境を作ります。そしてこのようなアジャイルの態度はリーンの“人に対する敬意”に近いです。しかし、リーンはアジャイルと比べてよりトレーニングに重きを置きます。

大野耐一氏は、日々組織で生まれる無駄とは誤解の結果であると考えていました。リーンでは、スキル開発への投資と判断力の改善が鍵です。リーンは次の問いに答えるものです。すなわち、“会社の成功のために誰が何を学ぶ必要があるか”です。

実際、リーンは人のスキルをのばすための実践と訓練の組み合わせなのです。

  • "Plan-Do-Check-Act"サイクルを使った問題解決手法は考えを明確にするのに役立ちます。正しい問題を選び、信念ではなく、事実に基づいて意思決定を下すために考えを明らかにする必要があります。
  • トヨタ生産方式のふたつの柱、つまり、ジャストインタイムと自動化はスキルを継続的に向上させることで、継続的に解決する必要のある典型的な問題を定義します。すなわち、正しいペースでともに働くということとすべてをはじめから正しく行うということです。
  • 基準を示して継続的にトレーニングをすることで、スキルの開発は進み、ノウハウも広く共有されるようになります。

そして、これらの実践はアジャイルの世界にとてもよくなじむのです。

InfoQ: 組織はアジャイルから始めて、その後にリーンやほかの手法を導入するべきでしょうか。それとも、両方のアプローチを混ぜて同時に実践するべきですか。

Régis: あなたの問いに対するリーンの回答は、別の問いになります。

アジャイルはソリューションです。一方、リーンは「直面している、アジャイルで解決できる問題とは何なのか」という問いです。問題がないのにソリューションを適用するのは時間の無駄で、本当の問題を看過してしまいます。

私がマネージャに奨めるのは、次の目的で上述したような問いを発することです。

  1. 解決するべき問題が何なのかを明示し、企業にとってその問題がなぜ重要なのかを明らかにする。
  2. チームのメンバ全員が困難に立ち向かうようにする。
  3. 成功への道筋を邪魔する実践上の主な障害を特定する。
  4. 特定の問題を克服するのに役立つ実験を主導する。
  5. チーム、さらに組織でノウハウを身につけ共有する。

...このようなことを始めるのがリーンということです。

InfoQ: リーンは学習のためということですが、アジャイルの振り返りはどうでしょうか。チームに反省と学習を促すと思うのですが。

Régis: そうですね。アジャイルの振り返りは学習の最高の機会です。振り返りをリードするコーチの手腕によって結果が大きく異なることをふまえても、最高の機会と言えるでしょう。私にとって振り返りは次のような問いを立てることで建設的で意味のあるものになります。

  • チームはどのようにして正しい問題に取り組んでいるということを知ったか。何を学びたいかではなく、何を学ぶ必要があるか、をどのように知ったか。
  • 学習はどの程度チームのメンバのスキルアップに役立ったか。
  • 学習が顧客や会社に与えた利益をどのように評価するか。

振り返りはある程度まとめて行う改善手法で、普通はイテレーションごとに行います。または数が限られた問題に取り組んでいるときに行われます。一方、リーンは日常のカイゼンを支援し、皆が毎日改善に貢献するようにします。オーベヤモデルに基づいて、問題を可視化しチームが継続的に協力して問題を解決するようにします。ある種の“継続的振り返り”ですね。

Lean IT Summit 2013でのRégis Medina氏のLean & Agileのビデオはここで見られる

この記事に星をつける

おすすめ度
スタイル

BT