はじめに

今年はアジャイルソフトウェア開発宣言が発表されてからちょうど20年の節目を迎えます。日本においてもアジャイル開発は広く認知され、多くの開発現場でアジャイル開発が採用されています。
しかしアジャイルが普及したことにより、目的意識を持たない、マインドの低いアジャイルチームも見られるようになりました。たまたま参画したプロジェクトがスクラムを採用していたのでなんとなくアジャイル開発に携わっていた、あるいは、経営層からの「うちもアジャイルを導入せよ」という号令で、スクラムのフレームワークを開発プロセスに取り入れることに奮起してアジャイル導入そのものが目的になってしまった、という現場もあるでしょう。
そのようなマインドの低い状態では、ただ「スクラム」という型に当てはめるだけの開発になり「このイベントは何のため？　意味あるの？　なんかスクラムって思ってたのと違って辛いしダルいな」と感じるメンバーも出てくるかもしれません。アジャイルを「やらされている」チームでは改善も成長も望めません。
では、なぜアジャイルにマインドが必要なのでしょうか？　ウォーターフォールで開発をするときに「ウォーターフォールマインドが必要だ」とは聞きません。ですがアジャイルにおいては、マインドの重要性はアジャイル開発宣言^注1やアジャイル宣言の背景にある原則^注2、スクラムガイド^注3などで繰り返し言及されています。
それは、ウォーターフォールは決まったものを計画どおりに作るのに対し、アジャイルは変動的で不確実、そして複雑であいまいな中で新しい価値を見いださなければならないからでしょう。目まぐるしく変化する時代だからこそ、アジャイルのマインドが必要なのではないでしょうか。

マインドが低いチームの典型的な例

まずは、マインドが低いチームとはどのようなものかを、実際にいくつか例を挙げて見ていきましょう。

アジャイルが目的になってしまっているチーム

1つめは上層部からアジャイルで開発するように言われるなどしてアジャイル導入に躍起になり、アジャイルで開発すること自体が目的になってしまっているチームです。
アジャイル開発手法の1つであるスクラム開発は、ロール・イベント・作成物が明確に定義されており、シンプルで導入しやすいことが特徴ですが、アジャイルの原則を理解していないと、やり方ばかりにとらわれてしまい、意義や目的を見失ってしまいがちです。スプリントを重ねていくうちにイベントが形骸化したり、イベント自体が設定されなくなったりする、という状況に陥ります。また、ストーリーポイントやベロシティといった数字にもとらわれがちです。これらは生産性を測るものではなく、チームが意思決定を下したり、チームが成長したりすることを目的とするものですが、プロジェクト上層部への報告時に数字ばかりが注目されてしまい、チームが疲弊してしまうという状況にも陥りかねません。

主役がいるチーム

2つめは、ある特定の1人の言動で、チームの行動が大きく左右されるような「主役がいるチーム」です。ここでは2つの具体例を挙げます。

● 勇者タイプのスーパーエンジニア

1つは技術力の高いスーパーエンジニアが「勇者」のように振る舞ってしまうチームです。勇者はすべてのイベントを先導し、いつも複雑で困難なタスクを担当します。困りごとを抱えたメンバーにアドバイスをするのではなく、タスクそのものを巻き取って勇者自ら解決してしまいますのでメンバーも成長できません。コミュニケーションも勇者からほかのメンバーへの一方通行となる場合が多いです。メンバーは勇者の命令に従っていればいいのですからマインドも不要になります。より良いものを作るための工夫などは勇者も怠りませんが、そこにはチームワークという大事な要素が欠けてしまっています。この勇者のおかげで、チーム外から見るととくに問題はないように見えるかもしれません。

● チームを支配するゴリラエンジニア

もう1つは、チームを支配する「ゴリラ」がいるチームです。ゴリラというのは独裁者的な振る舞いをする人のことです。ゴリラは経験豊富なシニアエンジニアであったり、テックリードのような組織的に権力を持っている人であったり、さまざまです。何かしらの優位性をもって場を支配します。ゴリラが話すまでほかのメンバーは話しません（発言したくても話せません）。
ゴリラは自分の意見を通そうとします。メンバーはおかしいと思っても意見を言わずに同調し、ゴリラの意見に従います。従いはしますが、メンバーは下された決定を信じません。
また、ゴリラはリスペクトに欠ける振る舞いをし、ほかのメンバーを非難します。ゴリラは人の意見をあまり聞きませんから非難されたメンバーも言い返しはしませんし、ほかのメンバーもかばったりしません。このようなチームではたとえメンバーのマインドが高かったとしてもしだいにチーム全体の意欲が低下していくでしょう。

キメラチーム

3つめは、「プロダクトオーナーは国内メーカーのX社、スクラムマスターはSIerのY社から、開発メンバーはY社およびビジネスパートナーのZ社から……」といった具合に、さまざまな組織の人たちで形成されたチームです。筆者もいわゆるSIerですので、スクラムチームがこのような構成になることはよくあります。
こういったチームで起こりがちなのは、組織構成の力関係がチームに出てしまうということです。たとえばプロダクトオーナー対開発チームという関係だと、発注側であるプロダクトオーナーはバックログにやりたいことをどんどん詰め込み、受注側である開発チームは委縮して発言を控え、ひたすら苦しみながらバックログを消化するといった状況があり得ます。同じチームでありながら会社が異なると、開発チーム内でも発注側の社員が受注側の社員にタスクを振ったり、コミュニケーションが報告のやりとりだけになったりします。このように人のつながりが横ではなく縦になってしまう関係では、チーム全員が同じ目的意識を持って取り組むことも、マインドを高めることも困難になってしまうでしょう。

◆　◆　◆

どうでしょうか？　みなさんのチームにも当てはまったりしませんか？　上記の例は少し極端過ぎるものもありますが、

など、局所的にでもこのようなことが当てはまれば、それはマインドが身についていないか低くなってしまっているかもしれません。

なぜマインドの低いチームが生まれるのか

では、なぜこのようなマインドの低いチームが生まれてしまうのでしょうか。前述の典型的な例をもとに考察していきます。

互いに無関心・無責任である

マインドの低いチームの典型的な例のすべてに共通しているのが、メンバー同士が互いの行動やチームとしての結果に対して無関心になっていることです。「自分の仕事は〇〇である」「自分の仕事の責任範囲でないことは知らない」「自分に与えられた仕事を100％こなすことに集中する」「チームとしての結果は自分の責任範囲ではない」このような考えがチーム内のどこかにないでしょうか。また、何か問題が発生した際に「悪いのはこちらではない」と、原因を自分以外の誰かや環境のせいにしていないでしょうか。
「自分の仕事」にだけ焦点を当てていると、自分自身の行為が職務の境界を越え、全体としてどのような影響がもたらされるのかが見えなくなります。その結果として悪い結果がもたらされた場合に、自分以外のせいに責任転嫁しがちです。メンバーは、自分だけのことを考えるのではなく、チームや組織全体を俯瞰して考え、行動すべきです。また、組織の評価制度としても個人の結果ではなく、チームとして達成した結果を重視するようなしくみになっている必要があるでしょう。

組織にコミットできていない

マサチューセッツ工科大学の上級講師であるピーター・M・センゲ氏は、著書『学習する組織』^注4の中で、組織のビジョンに対する姿勢を図1の7段階に定義し、組織として成し遂げたいことと各個人の成し遂げたいことが重なっていれば、各個人は内面から湧き上がるエネルギーを持って組織へコミットしようとする力を発揮するということを述べています。しかしながら、現実では組織のビジョンや目的は天から降りてきたお告げのようなものとしてとらえられ、個々人のやるべきことまで落とし込めていないことが多いのではないでしょうか。
「アジャイルが目的になってしまっているチーム」の例は、図1の「嫌々ながら」や「形だけ」の追従をしている段階に該当すると考えられます。メンバーは当事者意識を持ってチームの目的をとらえることができず、自分が何をすべきかがわからず、行動するエネルギーも湧かないといったところでしょう。組織としてアジャイル開発の狙いが明確に説明されていないのかもしれませんし、説明されていてもメンバーの中で真に理解できていないのかもしれません。参画やコミットメントの段階までにはほど遠い状態です。

図1　組織のビジョンに対する姿勢の7段階

衝突を回避してしまう

前述の「チームを支配するゴリラエンジニア」の例がわかりやすいでしょう。さまざまな組織で構成された「キメラチーム」の例でも、会社・個人間の契約や取引が常に関係してくるため、衝突を回避しようとすることが多いと思います。
なぜ衝突を避けてしまうのでしょうか？　まず考えられる理由としては、単純にめんどくさいからでしょう。衝突の結果が自分の利益につながらない場合、無駄なエネルギーを使ってわざわざ衝突するようなことはしませんし、自分の立場に不利益が生じるようであれば、発言しなくなるのは当然です。衝突を回避することと、意見を述べることは本来別ですが、「下手なことは言わないほうがいい」という気持ちから無言になります。
組織の成長段階を定義した「タックマンモデル」（図2）では、意見の衝突は混乱期にあたります。チームは混乱期を乗り越えてパフォーマンスを最大限に発揮できる統一期、機能期へと成長するのですが、衝突が起きなければチームは混乱期すら迎えることができず、成長が止まったままになります。

図2　タックマンモデル

信頼が欠如している

最後は、すべての例に当てはまる信頼の欠如です。互いに無関心で協調のない職場環境であれば、信頼は生まれません。無条件にお互いを信頼できれば理想ですが、ある程度はできても心から信頼することは困難でしょう。チームとして互いの行動に関心を持ち、それを補うような行動を継続できれば、実践に基づいた真の信頼を築き上げることができるのです。
重要なのは、「チームが誰で構成されているか」ではなく、「チームや組織がどのようにコミュニケーションをとっているか、どう行動しているか、貢献をどう評価しているか」ということです。マインド低下の原因となる個人を排除しようとしたり、責任の所在を探したり、ことなかれ主義を貫いたりしてもチームとしてのマインドは上がりません。

チームのマインドを上げるためのアプローチ

それではチームのマインドを上げるために何をすればいいのかを見ていきましょう。

まずは性善説に立ちチームを信頼する

前述の「チームを支配するゴリラエンジニア」の場合はどうしたら良いでしょうか。ゴリラにチームから出ていってもらいますか？　しかし排除したところで第2のゴリラが出てくる可能性がないとは限りません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

上記のようにアジャイル宣言の背後にある原則にも「信頼します」とありますし、許容しましょう。しかし、許容しただけでは今までどおりゴリラは暴れたい放題ですので、チームの誰もが気兼ねなく発言できるように人間関係の不安を取り除く必要があります。

人間関係の不安を取り除く

人間関係の不安を取り除くというのは対人リスクを排除すること、つまり心理的安全性を高めることです。心理的安全性を提唱したのは、ハーバード大学のエイミー・エドモンソン教授で、同教授は心理的安全性の定義について、

チームにおいて、ほかのメンバーが自分が発言することを恥じたり、拒絶したり、罰をあたえるようなことをしないという確信をもっている状態であり、チームは対人リスクをとるのに安全な場所であるとの信念がメンバー間で共有された状態

と述べています^注5。これはチームにゴリラがいる場合に限ったことではなく、キメラチームであっても、どんなチームであっても、心理的安全性の確保はマインドを高く保つための必要条件ではないでしょうか。
エドモンソン氏は、心理的安全性が低い状態のメンバーには次の4つの不安が存在していると述べています。

「こんな質問したら何もわかってないと思われるかも」「失敗したらこんなこともできないのかと思われるかも」「質問したら作業の妨げになるかも」「間違っていると思うけど指摘したらネガティブな人だと思われるかも」といった不安から、発言や行動を控えてしまうことはよくあると思います。「良いチームを作る」ことよりも「自分の印象を悪く見せないようにする」ことに集中すると、チームの生産性は低下し、学ぶ機会も失い、アイデアも出さなくなってしまいます。ですので、こういった対人リスクに関わる不安をチームメンバーが感じない状態を作ることが重要です。
では、対人リスクを排除するにはどうすればよいでしょうか。まずは、振り返りなどのイベントの際、後述のインセプションデッキなどを使って、メンバー全員に「変動的で不確実、そして複雑であいまいな中で目的を成し遂げるためには、お互いが助け合いながらでないと解決できない問題だらけである」ことを認識させます。一度ではなかなか浸透しないかもしれませんが、繰り返し行うことが大切です。チーム全員がお互いやプロダクトに対して共通認識を持たないことには、心理的安全性を高めようとしても相手の価値観を理解していないので意見をぶつけ合っても軋轢を生むだけになってしまいます。
そして、成果だけでなく相手の存在そのものを承認することです。対人リスクの不安というのは、自分は他者から人として承認されていないと感じるときに大きくなるので、お互いに相手を尊重する行動を心がけます。

こうして挙げてみると、何か特別なことをやるということではありません。人は他人から何らかの施しを受けた場合に、お返しをしなければならないという感情を抱きます。こうした返報性の原理というのは好意だけでなく敵意に対しても働きますので、できるだけ敵意を持たず好意の返報性がチーム内で働くようにできると理想です。ゴリラのいるチームや縦割りなキメラなチームではとくにこのような行動が習慣化されるよう、デイリースクラムなど日々のコミュニケーションの中で実践することで定着させていくのが良いのではないでしょうか。

チームに達成感を与える場を作る

心理的安全性を高めて人間関係の不安を取り除くということを述べてきましたが、これはマインドを上げるための土台作りになります。そのうえで、マインドを上げるためにはどういったアプローチがいいでしょうか。
アジャイル開発のプロセスやプラクティスは比較的導入しやすいのですが、マインドは習慣化した思考に左右され、なかなかすぐには変わらないでしょう。スクラムは「理解は容易だが習得は困難」とよく言われます。アジャイル開発のマインドを理解するためには、時間と経験が必要になってきます。開発現場で実践して経験を積むのが一番ですが、原則を勘違いしたまま実践を積み重ねても「アジャイルが目的になってしまっているチーム」の節で示したようにプラクティスの実践が目的になってしまいます。失敗から学ぶことも多くあるとは思いますが、そもそもの成功体験がないと、何を改善すべきかが見えにくいかと思います。
まずは成功体験が得られるような場を意識的に作ることが重要となります。たとえばエンタープライズ向けのアジャイル開発・ビジネスフレームワークである「SAFe」では、プログラムインクリメントと呼ばれる複数回の反復（スクラムにおけるスプリントに相当）からなる開発サイクルの中に、機能追加をしない特別な反復を含めています。これはInnovation Planning Sprintと呼ばれていますが、この反復ではリファクタリングや今後の開発に備えて新技術の習得などを任意で行います。こういったことをスクラムでも取り入れてみるのも良いでしょう。プロダクトバックログは消化せず、チームを成長させるためのスプリントを取り入れるのです。ときには立ち止まって成功体験を得ることで、チームに達成感を与えることも必要ではないでしょうか。

マインドの実践

また、成長するための機会を作っただけではマインドは上がりません。次のようなことを実践してみるのはどうでしょうか。

● 研修で気づきを得る

プロダクト開発の擬似体験を通してマインドを養うような研修にチーム全員で参加してみるのも良いでしょう。プログラミング以外のお題で行う研修も多いのでいつもとは違った視点で本質を学べるかと思います。

● スクラム熟練者に叩き込んでもらう

アジャイルコーチのような熟練者を呼んでスクラムの各種イベントに参加してもらい、1スプリントを回してみるのもいいかもしれません。熟練者にマインドを徹底的に叩き込んでもらい、一緒に振り返りを行ってフィードバックをもらえば、今後もチームは高いマインドを維持するための行動ができるようになるでしょう。

● インセプションデッキを見直す

スタート時にインセプションデッキ^注6に取り組んでいるチームも多いかとは思いますが、最初に作ってそれきりのチームも結構多いのではないでしょうか？　インセプションデッキはWhyとHowを明確にするためのものです。プロジェクトが進めば、現状とギャップが出てくることもあるでしょう。最初に決めたことが絶対というわけではありませんので、常に見返してみることが大事です。チーム成長のためのスプリントを設けたのなら、その機会を利用してじっくりと見直してみるのも良いかもしれません。インセプションデッキを作っていないチームもプロジェクトの途中でもよいので作ってみることをお勧めします。

● XPのプラクティスを取り入れる

XPのプラクティスの中には、マインドの向上につながるものもあります。たとえばペアプログラミングなどです。アジャイルには「優れた設計が生産性を上げる、優れた設計はお互いに助け合えるようなチームから生まれる」という考えがあります。ペアプログラミングによって強制的にお互いに助け合う環境を作ることで、優れた設計を生み出すとともに、共通理解や知識・技術の共有によってチームの自己組織化の促進もできます。

◆　◆　◆

ほかにもさまざまな施策があるかとは思います。いずれにせよ、擬似的な成功体験や教育でチームの達成感を得て、思考を習慣化することが大切であると思います。

おわりに

アジャイルは「Don’t just Do Agile, Be Agile」です。ただプラクティスを実践するだけのDo Agileではなく、常に自分たちと向き合い、より良くするための改善や工夫を怠らない意思と行動、つまりマインドそのものがアジャイルではないでしょうか。
マインドが定着していないことで「それは後にしよう」「決めてくれないと動けない」「それはもう決まっていることだから」というような声が出てきたら、それはアジャイルではなくなる瞬間です。常にBe Agileなチームであり続けるためにマインドを高く保っていきたいものです。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx