Scrum Inc.認定スクラムマスターの局です。
多くのアジャイル開発の経験や成功事例、失敗事例を聞く中で、うまくいっているケースには共通点があると感じています。
その共通点とは、優れたプロセスやツールの導入ではなく、チーム内でいかに早くアジャイル開発に最適な文化を形成できたかです。
そもそもアジャイル開発とは何なのか？
なぜ「文化」が大切なのか？
これはアジャイル開発という手法が生み出された背景を知るとよくわかります。
アジャイル開発の憲章である「アジャイルソフトウェア開発宣言」は、従来型のソフトウェア開発のやり方とは異なる手法を実践していた17名のソフトウェア開発者が、それぞれの主義や手法についての議論を行ってまとめあげ、2001年に公開されました。
その内容は以下の通りです（日本語版）。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
この「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」を見てわかるように、生みの親である彼らは、何かしらのプロセスやツールを提唱したのではありません。
「個人と対話」「動くもの」「顧客との協調」「変化対応」に価値を置くと明確に示しています。
私はこれを「文化」だと解釈しています。
アジャイル的な文化が軽視されがちな理由
一方で、その文化を実践していくために生みだされた数々のフレームワークやツールが存在していて、多くの場合、どんなフレームワークやツールを用いるかの方がチームづくりの際に重視されがちです。
これは「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリース」という原則を実際のプロジェクトに適用するためには、何らかのフレームワークやツールにより開発の思想を具体的な作業の手順に落とし込む必要があるためだと考えられます。
フレームワークやツールを活用すること自体は悪ではありませんが、それを重視する弊害として、文化の形成よりもフレームワークやツールに開発チームを「はめる」ことの方に意識が向いてしまうことがあります。
私自身も、従来の開発手法に慣れている企業にアジャイル開発を導入しようとした際、なかなか文化形成が進まず、チームの意識がフレームワークやツールの方に向いてしまった経験があります。
開発の進捗が芳しくないと、やれ毎朝毎晩状況を報告しろだの、プロダクトバックログをわかる形に整えろだの、本質的でない解決策ばかりがタスクとして下りてきて、さらに開発が遅れるようになりました。
こうなると、典型的な負のスパイラルに陥ってしまいます。
もちろんチームによってはこうしたタスクが必要とされる場合もありますが、そうではない場合も多々あります。
私の失敗経験では、こうした策がチームにとってベストな解決策ではなかったため、チームが困惑しながらタスクを消化していくことでベロシティ（チームが作業を進める速度）も上がらない状態でした。
では、アジャイルの本質である「文化」が形成できているのかどうかをどう判断すればいいのでしょうか？
私は数々のアジャイルプロジェクトの経験から「チームが自立しているか」を意識して見るようにしています。
アジャイル開発に重要なチームの自立
「チームの自立」にはチームメンバーが自らマネジメントできることが必要です。具体的には以下の4点をチェックするようにしています。
- メンバーの心理的安全性が保証されているか？
- ある程度フレックスな働き方ができるか？
- 各自がプロ意識を持っており、自ら解決へ導くことができるか？
- チームの意見に尊厳をおいているか？
なぜこの4点が大切だと言えるのでしょうか？
それは、アジャイルは、スピードと柔軟性が求められる開発であることに起因します。
アジャイル開発の多くはプロジェクトマネージャー（PM）という管理役を置くことをしません。
スクラム開発におけるスクラムマスターがPMに該当するのでは？という意見もありますが、スクラムマスターはあくまでチームにスクラム開発のやり方をコーチし、イベントの実施に責任を負うだけなので、いわゆる顧客との窓口のような役割は担いません。
どうしてもそのような立場が必要な場合はこの限りではありませんが、基本的には開発者とプロダクトの責任者（プロダクトオーナー=PO）が密に連絡を取ることができ、仕様の判断などを直接議論できる体制をとることが重要で、その体制によりスピードと柔軟性を生み出します。
次に、先に挙げた「チームの自立を計る4点」がなぜ大切なのか、ひとつずつの理由をもう少し詳しく解説します。
メンバーの心理的安全性
心理的安全性とは、チームの中で自分の考えや気持ちを誰に対してでも安心して発言できる状態のことです。心理的安全性があることで、POやチームのメンバーと積極的な議論を交わせます。
フレックスな働き方
身体的、精神的な調子を自らマネジメントすることも重要です。
厳しく管理された働き方よりも、リフレッシュしたい時はそれぞれのタイミングで休めるような、ある程度フレックスな働き方が求められます。
各自がプロ意識を持つ
各自が一つの会社のようにプロ意識を持たなければ、プロジェクトはうまく回りません。
例えば、何か問題を発見したら自らその影響範囲を考え、行動し、解決方法を提案し、実行する必要があります。「自分のタスクではないから関係ない」などと考えてはいけません。もしその問題を放置したら自分の会社が潰れるという危機感を皆が持っていれば、自分のタスクでなくてもすぐに行動するのではないでしょうか。
チームの意見に尊厳を置く
チームの意見に尊厳を置くことは心理的安全性と似ているかもしれませんが、こちらは外的障害が取り除かれている状態を指します。
開発がうまくいっていないときに、ステークホルダーの意見が強くなり、管理のための新たなタスクが下りてくることがありますが、問題点は開発チーム自身が一番知っていますし、開発チーム自身が解決策を生み出す必要があります。
ステークホルダーは開発チームの障害にならないよう見守ることが大切です。
アジャイル的な文化を醸成していくために
最後に「自立したチームがスピードと柔軟性を持って自ら課題に取り組んでいく」というアジャイル開発に最適な文化をどのように醸成していけばいいのか、3つのポイントを解説します。
1つ目は、顧客や発注者、開発チームのメンバーなど、すべての関係者がアジャイルの文化を理解することです。
そのためにはキックオフにおいて、チームとしての活動方針をステークホルダーも含めて合意しておく必要があります。
2つ目は、アジャイル開発に慣れているメンバーをチームに配置することです。
いくら会社が環境を整えていても、用意された環境だけで本当の文化は社員各自になかなか浸透してくれないものです。
会社内にアジャイル開発に慣れたメンバーがいない場合は、外部のアジャイルコーチを採用することをおすすめします。外部の人員だと身構えてしまうという意見もありますが、黒船的に創造的破壊を生み出せることはメリットも多くあります。
3つ目は、「このチームでアジャイル開発を始める」という先行役のチームをひとつ決めて取り組むことです。
先行役のチームには慣れているメンバーを配置し、文化の醸成ができてきたら、そのチームをフラッグシップとして次のチームへ展開していきます。
アジャイル開発のプラクティスはさまざまありますが、闇雲に取り入れるのではなく自社に合う方法を見つけ出すことが大切です。一度に複数チームに展開すると現場が混乱してしまう恐れがあるので、まず1つのチームで成功例を作ることがおすすめです。
また、アジャイル開発が初めてのチームでは最初はベロシティが出にくいことを知っておくことが大切です。
従来の開発手法に慣れているチームは従来のやり方や文化を踏襲しがちなので、その習慣を直すには時間がかかります。ある程度長期の取り組みとして、最初から理想通りには進まないことを容認の上、アジャイル開発を導入していく必要があります。
NCDCではアジャイル開発の支援も行っていますので、具体的な進め方のご相談などありましたらお問い合せフォームからご相談ください。
