そもそも「意欲に満ちた人」を集めてチームを作ること自体が難しいんですが、どうしたらいいですか？

アジャイルマニフェストの背後にある12の原則には、「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します」という記述があります。しかし現実の組織においては、会社都合やスキルの一致度合いなどでチームへのアサインが行われたり、人数や能力が不足している場合は外部から人を連れてきたりするため、「意欲に満ちた人」を揃えるのは簡単ではありません。

とはいえ、プロダクトで成功するためには、良いチームを実現することが不可欠です。以下でいくつかヒントを紹介します。

魅力的なゴールを設定する

「こんなもん作ってどうすんだ？」「こんなことをして何の意味があるの？」みたいなプロダクトやゴールでは、意欲を持つのは難しいです。 ゴールに魅力を感じなかったり賛同できなかったりする場合、チームのメンバーは自己の利益を最大化することだけを目的にします。たとえば、会社の目標設定の数値だけ達成するとか、自分が興味のある技術を習得するといったものです。このような状況ではメンバー同士の協力関係も限定的になります。 上から降ってきたよくわからないゴールに、適当に集められた人たちで取り組むというのは勝ち目のない無駄な投資です。

意欲を下げることをしない

「意欲を上げる唯一の方法は、意欲を下げることをしない」です。 最初から意欲が全然ない人というのは稀です。多くの場合、自身が意欲を発揮しようとしたが否定されたり、周りから賛同が得られなかったりといった体験が何度も重なったことによって、「意欲を発揮しようとする行動がムダ」であると学習した結果です。いわゆる学習性無気力と呼ばれるものに由来します。 このような状況を解決するには、意欲を下げるようなことをしないところから始める必要があります。たとえば、チーム外からの干渉、介入、指示、命令をなくし、チーム自身で物事を決めさせるようにします（スクラムで言うところの自己管理です。いつ、誰が、何を、どうやってやるかはチーム自身で決めます）。そうやって自分たちの責任で自分たちが行なったことの結果を見ていくことで改善されます。

実は意欲の有無を見分けるのは難しい

複雑な問題に取り組んでいるときは、実際のところ誰が意欲的に働いていて、誰がそうでないかを見分けるのは容易ではありません。 チームの外側からは尚更です。 設計について深く考え込んでいるプログラマーと、何も考えずにぼーっとしているプログラマーは、外から見ても区別はつきません。 メンバーの意欲が低いというのは、表面的な事象をもとにした「意見」に過ぎません。 しかしそれが事実のように扱われてしまうと、間違った対応が行われ、状況が悪化することもあります。意見と事実は明確に切り分けてみましょう。 また、ソフトウェア開発はチームスポーツなので、個人に焦点を当てる前に、チームに焦点を当て、チームとしてどう問題に取り組むかを改善してみるとよいでしょう。