アジャイルにおいて、締め切りを「守ること」「強制すること」は必要ではない

はじめに

私のクライアントの多くは締め切りに悩んでいます。そのうちの一人であるブラッドさんは、ダグラス・アダムスの言葉を引用して、顔をしかめていました：

私は締め切りを愛している。締め切りが通り過ぎるときのヒューという飛ぶような音が好きだ。

彼は、締め切りを「守る」「強制する」ために、アジャイルなアプローチが有効だと考えていました。

私は、彼にいくつかの質問をしました：

• 締め切りを守りたくない人がいると思いますか？
• なぜ、締め切りがあるのですか？
• なぜ、その締め切りを守る必要があるのでしょうか？

ブラッドは、「チームの面々が熱心に取り組んでいるようには見えない」と言っていました。会社は、マーケットの要求に応えるために締め切りを設けていました。そして、彼らのガバナンスのために強制していました。

次に挙げるいくつかのマネジメントパターンの質問によって、エンゲージメントについて学べるのではないかと思いました。

チームが、「締め切り」に間に合わない原因となるマネジメントパターン

締め切りに間に合わなかった場合の問題点を大まかに2つのバケツに分けて考えてみましょう。マネジメントがチームをどのように編成しているかという問題点と、マネジメントが指標の「必要性」をどのように編成しているかという問題点です（もちろん、チームの問題もありますが、それはまた別の記事にて）。

まずは、マネジメントがどのようにチームを編成するかについて見ていきましょう。私はブラッドに以下の質問をしてみました：

• 機能横断的で、単体としてリリースできるようなプロダクトチームやフィーチャーチームですか？
  （コンポーネントチームは、相互依存関係が生じて、作業を終えるまでの時間が長くなります）
• シェアードサービスのチームはありますか？
  （シェアードサービスのチームは、締め切りがほとんど不可能になる遅延を生み出します）
• それぞれのチームは、同時にひとつのプロダクトにだけ集中していますか？
  （チームの集中が分散すると、一つの作業を終えるのにより多くの時間が必要となります）

これらの質問はいずれも一つのアイデアに集中しています。マネージャーは、自分たちが何をしなければならないかを知り、その作業をするためのすべてのスキルと能力を備えた機能横断的なチームを作っていますか？そのチームには、共通のゴールがありますか？

単一機能の「チーム」、シェアードサービスの「チーム」、そしてコンポーネント「チーム」は、すべてワークグループなのです。彼らのは共通のゴールを共有しておらず、相互依存的な作業をしているわけではありません。彼らはみな、他の人や他のチームと協力して成果を上げる必要があるのです。

共通のゴールを持った機能横断的なチームは、合理的な時間内に作業を終わらせることができます。もしくは、そうできない理由を理解しています。彼らは、作業やお互いにより深く関わる傾向があるのです。

ブラッドは、「いいえ、コンポーネントチームとシェアードサービスチームを採用している」と答えました。さらに、各コンポーネントチームは、開発と保守の両方において、いくつものプロダクトを担当していました。

このようなマネジメントパターンは、エンゲージメントを損ないます。メンバーが自律性、熟達そして、目的を持ち合わすことができません。これらのパターンでは、締め切りを「守っている」ことが不可能なのです。

なぜブラッドは、締め切りを「強制」したいのでしょうか？それはガバナンスの指標のひとつである「スケジュール差異」のためなのです。

スケジュール差異は、ソフトウェア・プロダクトでは意味をなさない

スケジュール差異は、進捗状況を測るためのものとされています。しかしながら、ソフトウェア・プロダクトの開発は、建設ではありません。ソフトウェアの作成は、学習が全てなのです（詳しくは、こちら）。

アジャイルではないアプローチであっても、スケジュール差異は意味をなしません。スケジュール差異は、プロジェクト内部にフィードバックサイクルがないことや、何も学習しないことを前提としているのです。ソフトウェアプロダクトの開発には、フィードバックループと学習が必要なのです。

会社は、なぜスケジュール差異を使おうと思ったのでしょうか？

• 過去にスケジュール差異でそこそこ成功を収めたから。しかしプロダクトが変わってしまった今では、チームが学ばなければならないことがどれだけあるのか、気がついていないのです。
• 小さいものも提供できない「チーム」は、あまりデモをしません。そして数カ月後には一切デモをしなくなります。
• 誰もデモをみていないので、マネジメントはチームの成果を信頼できなくなります。
• マネージャーは、ファイナンスにとってスケジュール差異が必要だと考えています。

何度か話し合ったあと、ブラッドたちは彼らの行動を変えてみました。

新しいマネジメントの選択

ブラッドは、まず、全員の WIP (Work in Progress; 仕掛り作業) をへらすために、プロジェクトポートフォリオマネジメントを始めてみました。大きな決断のひとつは、大規模な保守活動をいつ行うのかでした。このチームにはまだ本番稼働での保守の問題があったのですが、それは新規プロダクト開発と「同時に」大規模な保守活動を行うのとは違います。

彼らは、私の「Experimental Possibility: Self- Organization to from Component Teams to Feature Teams」を使いました（しかもリモートで）。この活動によって、会社がすべての機能横断的なチームをつくるために、どのような人材を雇う必要があるかをマネージャーに伝えることができました。

マネージャーは、チームが担当するプロダクトを変更してでも、チームを維持すること選択しました。

そこで、マネージャーは、スケジュール差異を測る代わりに、毎週何らかのデモをするようにチームに尋ねました。たとえそのフィーチャーが完全に完成していなくても、デモをしてもらうようにしました。このたった一つの行動が、メンバーの作業に対する考え方を変えました。自分たちは、「フィーチャーの工場である」と感じていたのが、「価値を提供することである」に変わったのです。

マネジメントが変わるのにどれくらいの時間がかかるのか？

共に仕事をするようになって、ブラッドに「マネジメントが変わるのにどれくらい時間がかかると思いますか？」と尋ねました。すると、彼は、「それは落とし穴のある質問ですか？」と尋ねてきました。

私は、笑って「いいえ」と言いました。私の経験では、フィードバックループと学習には、彼が予想していたよりも長い時間がかかるからです。

彼は、「チームのように？」と尋ねました。

そうです。チームのように時間がかかるのです。

ブラッドと彼のマネージャーは、プロジェクトポートフォリオの決定に2ヶ月ほど悩みました。ガバナンスの問題ではさらに苦労をしました。しかしながら、ポートフォリオを整理し、チームにフィーチャーチームを作らせたところ、価値の流れが劇的増加したのです。

デモを見た人は、スケジュール差異のような関連のない指標を聞くことがなくなりました。

ブラッドの会社の変革は、まだ進行中です。しかしながら、アジリティの恩恵を受けたいのであれば、締め切りを気にする必要はなく、マネジメントの行動を気にする必要があることに気がついたのです（彼らは、「Create Your Successful Agile Project」と「Practical Ways to Lead an Innovative Organization」も読んでいます）。

締め切りに追われて、マネージャーが決断することもなくなりました。皆が幸せになり、生産性も向上しました。