アジャイルソフトウェア開発宣言から既に20年以上が経過し世はすっかりアジャイルの時代。。。と思いきや未だにウォーターフォールが適していないプロジェクトなのにウォーターフォールまっしぐらのチームが多くあることでしょう。
いまさらかもしれないですが、そんなしなくてもいい苦労をしているチームに向けて「なぜアジャイル・Scrumなのか？」ということと「アジャイルとは何か？」ということについていくつかの記事にわけてまとめてみます。
なぜ個人ではなくチームなのか？
何が起きるかわからないVUCAの時代、複雑性の高い時代において、答えがわからない状況。多くの人の協力・知恵が必要で学習しながら答えを探しに行くためにチームが必要。と多くの本が述べています。
それはそれで正しいと思うのですが説得力がまだ足りないと思うのです。一人の優秀なリーダーがいればいいのでは？と。
自分の中で唯一これだ！と思った本があるので紹介します。1回目にも紹介しましたが、「チームレジリエンス 困難と不確実性に強いチームのつくり方（池田めぐみ・安斎勇樹著）」です。
この本は「VUCAの時代、複雑性の高い時代におけるチームのレジリエンス（困難を乗り越える能力やプロセス）」という観点でチームを研究した結果を解説している本です。
研究は「個人」「組織」のレジリエンスという観点でもされており、書籍ではその比較もされています。
組織レジリエンス・・・組織を脅かすような困難から組織のパフォーマンスを回復させる能力・プロセス（倒産の危機とか資産の貯蓄分配の戦略とかそうい面が大きいのでここでは触れません）
チームレジリエンス・・・チームが困難から回復したり、成長したりするための能力・プロセス。
個人レジリエンス・・・個人が困難・挫折など精神的なショックから回復すること、能力。
それぞれは相互に関係し、組織にとってはそれぞれが必要であることを前提に、以下のように述べられています。
個人レジリエンスが高いチームがチームレジリエンスが高いわけではない
この点はチームの困難状況の解決を個々のレジリエンスに任せてしまうことは以下３点の理由から危険であると、チームレジリエンス研究で著名なストプリンクらの分析結果を紹介しています。
レジリエンスの高い個人は、困難に遭遇すると焦点をチームから個人に移す傾向があり、チームより自身を守るような行動に出る可能性が高くなる。
個人レジリエンスが高い人は、自身の生存と成功のために必要なことを行いますが、 その選択肢の中にはチームを放棄する可能性も含まれています。・・・ 異動願を出したり、転職活動を行ったり・・・(チームレジリエンスより抜粋)プロダクトが炎上した後にチームから必要なメンバーが退職したりするのも、個人レジリエンスの高さ故かもです。
解決対応が特定の個人に固定化される
個人レジリエンスに頼るチームは困難なときに、強力なリーダーや個人にまかせてしまう、または自分でやった方が早いとなる傾向にあります。結果的に疲弊していくケースも多いでしょう。１のように離脱するケースもあるかもしれません。
他者の知恵を使わない
これは多くのチームに関する書籍にもよく書かれていますね。一人では解決できないこともメンバー個々の専門性を生かし、良いアイデアが出て解決できる可能性があります。
これらの点から個人レジリエンスが高いがゆえにチームを逆に困難にすることもあるということがわかります。
個人レジリエンスの高め方とチームレジリエンスの高め方は違う
また、困難を乗り越えるやり方は個人とチームではそもそもが違うということです。最大の違いはチームに対する困難に対してメンバーによって困難の解釈が違うという点です。
チームに対する困難は、不確実性が高い状況であることが多く、各人で困難を別角度から捉えていることがあるということです。
「群盲像を評す」のごとく、他の人が見ている景色を見つめなければ全体像は見えてこない。
そのためには、チーム全体で（他人の見ている景色をみるための）学習が必要だったり、（他人の見ている景色をみるために）対話が必要だったり、お互いの考えを可視化していく必要もあるでしょう。（他人の見ている景色を説明してもらうために）心理的安全性が高い必要もあったり、チームがポジティブでないといけない理由もわかるでしょう。つまり「チームを作る」必要があるということです。
以上でいくら優秀な個人が集まってもチームが作れなくては立ち行かない理由が理解できるのではないでしょうか？
ウォーターフォールとアジャイルをチームという観点から比較する
それウォーターフォールでもできるよ？と思うかもしれません。しかし、自分の結論としては「（できないわけではないが）ウォーターフォールはチームにしにくいし必要性が低い、アジャイルであれば（必ずできるわけではないが）しやすいし必要性が高い」です。両者の特徴から考えてみましょう
ウォーターフォール
作ることに集中しなければならないのでチームを作る時間がそもそも取れない
最終的に成果物を作り上げることが目的(第五回で詳しく)なので、チームを作っている場合ではないんです。振り返りなんてワークしている時間があるなら作れと。ステークホルダーまで集めてレビュー会開く時間があるなら次の機能を作れと。そうなると・・・
分業になりがち
仕様を決める人、作る人を分ける、上司が指示してタスクを分担しそれぞれ作業（レビューぐらいはするかもしれませんが）する。作るだけならこれが一番効率的。チームは存在していても、個人プレーで充分となります。
計画通りに行くことが重視されるので、遅延したときなど困難が生じたときにチームができていないとリーダシップに頼るしかない
見積もって、計画通りにことを進め、成果物を作ることが目的なので、計画が狂うと様々な困難が生じやすいです。そのとき最初の２点からチームが作りづらい状態なので、対処するのはチームの中の個人ということになります。つまり強いリーダーシップを発揮するか、離脱するかしか対処の仕様がないことになります。個人のレジリエンスが低いメンバーは我慢する、リーダーについていくしか選択肢がありません。
こういう意味でも2回目（なぜアジャイルなのか② 要求・要件と技術の複雑さから選択する ）で述べた通り「単純な領域」でのみ採用するのがいいでしょう。計画を立てやすい、チームでなくてもうまくいく状況が適しています。
複雑な状況、チームが必要な状況でわざわざウォーターフォールを選択する理由はもうありません。
アジャイル
アジャイルソフトウェア開発宣言から色々抜粋してみます。
プロセスやツールよりも個人と対話を
対話が必要というのは先ほどのチームが必要な理由で説明の通りです。
計画に従うことよりも変化への対応を
いいすぎかもですが、これこそまさにチームでやりましょうの言い換えだと思います。変化＝困難と置き換えるといいかもしれません。
またアジャイルソフトウェア開発宣言にはアジャイルソフトウェアの12の原則というのもあるのでここからも。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
「継続的」と「価値のあるソフトウェア」がポイントで「作って終わりを前提としてない」のです。単に作るのではなく「価値のある」ものを「作り続ける」（第5回で詳しく）のだから価値のあるというものの探索や検証が必要です。そのためには「チーム」としての知恵が必要でそれこそ群盲像を評す状態では足りない。つまり「チーム」を作ることが前提となっているとも言えるでしょう。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
まさに対話が必要。上意下達・資料のやり取りではなく直接話すことを重視する。チームで話すことも重視しています。
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
作り上げることを目的としていなくて、作り続ける（第5回で詳しく）ことを重視しています。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
チームでやるということがそもそも原則として表現されていることがわかるでしょう。それにはチームを作る時間も必要ということです。
そういえばチームに襲いかかる困難さとはなんだろう？
そもそもチームに襲いかかる困難さとはなんだろうというところをいくつか挙げてみます。
競合の台頭
前回ソフトウェアを作るのが簡単になり適用分野が広がったとお伝えしました。 つまり参入障壁が低くなったことを意味します。日本だけでなく、海外も競争相手になっています。アメリカの学者リチャード・ダヴェニはハイパーコンペティション（超競争）時代と呼んでいるそうです。
売れない・使われない・顧客を取り尽くした
自分のプロダクトの売上が上がらない、使われない、これ以上市場が広がらないというのも困難の一つでしょう。競合の問題もそうですが、これを「チーム」の困難とするか、「経営・企画」や「営業」の問題とするかは人によって感じ方が違うかもしれません。「作るだけ」のチームは困難だと感じていないことが多いのではないでしょうか？これこそがチームが必要な理由でもあったりします。「作るだけ」で本当にいいのか考えてみるといいかもしれません。
遅延
プロダクトの遅延は競争にも影響しますが、これもそれぞれ感じ方が違うかもしれません。「作り切る」ことへの遅延か、「価値ある」プロダクトを提供することへの遅延か、大きく違います。解決することで競合に対抗しやすいのはどちらかを考えてみるといいかもしれません。
離脱
メンバーの離脱はわかりやすいですね。長期休暇・病気など理由は様々。良いことではありますが、ひと昔に比べて休みやすくもなった。転職することも普通の時代になりました。メンバーの離脱も今の時代不確実性の高いできごとかもしれません。
また、バス係数問題も関連しますね。すなわちバスに何人轢かれたらプロジェクトが破綻するか？作るだけのチームでタスクを完全に分担していると起こりがちです。
新加入
逆に新しいメンバーを迎えるというのも一つの困難かもしれません。どのように入りやすくするか？オンボーディングどうするか？そもそもの採用のところから困難ということもあるかもしれません。現在は売り手市場でエンジニアが見つからない状況でもあります。
新型コロナ
外部要因の困難さで直近どのチームでも起きた事象かと思います。皆様はどう解決したでしょうか？
と挙げだしたら数え切れないですね。もちろんエンジニアチームであれば技術的な問題というのも数多くあるのはそのとおりです。
（おまけ）チームとグループの違い
ジョン・R・カッツェンバックとダグラス・K・スミスの論文「チームとグループは異なる」では、
チームとは、共通の目的、達成すべき目標、
そのためのアプローチを共有し、
連帯責任を果たせる補完的なスキルを備えた少人数の集合体である。
と説明しています。
チームレジリエンスで説明されている点と一致していますね。
まとめ
- どれだけ優秀でも個人だけではチームの困難を乗り越えることができないため、チームを作ることが必要
- ウォーターフォールではチームを作ることが難しい、というか不要である部分が大きい。
- アジャイルはチームでやることを前提としている。
次回は「どうやってチームを作るか？」、さらにその次は「プロダクトを作り続けることとはどういうことか？」を考えます。