アジャイルを取り入れたい
アジャイルを取り入れてみたい。
でも、わが社はガチガチのウォータフォールだから…。
上司がアジャイルに理解がなくて…。
そんな悩みを持たれているかもしれません。
本日は「アジャイル実務ガイド」より、
アジャイルを取り入れて活用(テーラリング）するためのポイントを、
噛み砕いてご紹介したいと思います。
アジャイル導入のテーラリングガイドライン
大規模なプロジェクトにアジャイルを導入する場合
スクラムなどのアジャイル開発では、1チームのサイズが10人くらいまでが良いとされています。
しかし、大規模なプロジェクトにアジャイル開発を取り入れたい場合はどうすれば良いでしょうか？
アジャイル実務ガイドでは、
大規模なプロジェクトを複数の小さなプロジェクトや複数のチームに編成することをススメています。
フィーチャー(ユーザーストーリー）を頻繁にリリースすることで、
より小規模なチームにしていく。
また、SAFE、LESS(大規模スクラム）、DA(ディスプリンドアジャイル)といった
大規模なプロジェクトにフォーカスしたフレームワークを導入もススメています。
アジャイルを意識していなくとも、
規模が大きなプロジェクトでは、
自然にミニチームのような形を作っていることが多いと思います。
同じ発想ですね。
チームメンバーが色んな所に分散している場合
チームメンバーが一か所ではなく、さまざまな拠点に散らばっている場合、
アジャイル開発はどこに注意すればよいのでしょうか？
2020年以降、テレワークを利用し、さまざまな拠点で活動することが当たり前となりました。
むしろ、このシチュエーションの方が多くなっているでしょう。
それでは、
どのようにアジャイルをテーラリングしていけば良いのでしょうか？
アジャイル実務ガイドでは、
ビデオチャットツール（ZOOMやTeamsなど）や、
情報共有ツール（MiroやGoogleJamBoard)などを、
有効利用することをススメています。
積極的に使っていくことが大事ですよね。
またチームがある程度整ってきたら、なるべく早く対面でのミーティングを行うことをススメています。
顔の表情やボディーランゲージなど、
非言語によるコミュニケーションはビデオチャットツールでは伝わらなかったりすることが多いので、
定期的に対面で会うことは必要ということですね。
（すごくわかります…)
タイムゾーンが違うメンバーがいる場合は、
プロジェクト全体でミーティングを行うより、
同じタイムゾーンの小規模(２～３人）でのミーティングを行う形をとります。
安全性に関わる文書やチェックが必要なプロジェクトにアジャイルを導入できるの？
例えば薬の開発や、航空機のシステム開発などでは、
厳格な文書化やしっかりとしたチェック機構を備えた体制は欠かせないでしょう。
そのようなプロジェクトでは、ハイブリッドなアプローチをとることで、
アジャイルを活用する事が出来ます。
例えば、しっかりと文章に残す必要があったり、厳重な承認が必要なプロセスは厳格に利用しつつ、
必要に応じてアジャイルアプローチが取れるところは組み合わせていくといったイメージでしょうか。
「そりゃそうだ。」という感じもしますが、大切なのはしっかりと厳重なプロセスが必要な所は変えない。
しかし、アジャイルアプローチを用いて改善できるところは変えていく。
何処にアジャイルが適応できるのか？適材適所を考えていくことが大切ではないかと思います。
変更も少なく安定したプロジェクトにアジャイルって必要ですか？
結論から書くと、無理に導入する必要はないでしょう。
変更や改善を行う必要がない場合、
振り返りまでの１サイクルの期間を長くするなど、
状況に合わせた対応を取るのは良いかもしれません。
開発初期では変更を行う頻度などが高い場合はアジャイルアプローチを取り入れ、
そうでない場合はウォータフォールアプローチを採用するなど、
ハイブリットな形をとるのは良いかもしれません。
機能ごとに分れているチームの横の連携が薄い場合どうすれば？
機能横断チームを構成してみることを検討します。
また、自分の所属しているチームの機能の良しあしが報償に影響している場合、
「その機能さえ出来ればよいや！」という気持ちが働き、チーム全体、プロダクト全体のために行動しなくなる可能性があるため、報酬システムを見直してみるのが良いかもしれません。
成功も失敗もオープンにするのが怖い場合
透明性があることで不安になる場合もありますよね。
成功の報告は不安になることはないでしょう。
しかし、透明性を出すということは、失敗もオープンに報告することになり、勇気が必要なっていきます。
その場合は、ホワイトボードなどを利用し、まず率先して例を示していきます。
また、アジャイル実務ガイドには書かれていないのですが、
「心理的安全性」を担保するような風土作りも大切でしょう。
チームメンバーの多くが技術不足の場合
チームメンバーが経験、技術不足の場合は、
チームのメンバーが技術習得を行うまで、技術に明るい人から追加支援を行い、トレーニングしてもらいます。
しかし、あくまでチームを回していくのはチームメンバー。
アジャイルでは自律したチーム行動が求められるので、トレーニングも受け身ではなく、
全てを把握しようと自ら努力させることが必要と書かれています。
経営陣がアジャイルに賛同していない場合どうすれば？
経営幹部からの賛同がないと、協力が得られず、やりずらいですよね。
経営幹部でも把握しやすい、共通の基盤や組織改善に当たるような個所を探していき、
アジャイルアプローチを試行し、振り返りを行い、その成果を理解してもらいます。
また、経営幹部のメンバーに教育やトレーニングを行い、
小さなアジャイルアプローチを体感してもらう方法もありでしょう。
分かりやすいところから小さく始める形ですね。
アジャイルの用語や言語が合わない場合
言語が合わない、分からない場合ですね。
これはよくあると思います。
「ベロシティが下がってきており、今日もスプリントを回して、明日はレトロスペクティブをやりましょう！」と言われても、
アジャイルに関して知らない人は、ポカーンですよ。
組織の言葉や共通認識として分かりやすい言葉に置き換えてあげる方法を検討するのが良さそうです。
「タスクの消化具合は良い感じに消化していますね。今週も頑張っていきましょう。明日は振り返り会をやりましょう！」といった形ですと、アジャイルに関して分からない人でも伝わりますよね。
共通の用語集を作っても良いかもしれませんが、メンバーに合わせてカスタマイズするのが良いかと思います。
状況にあわせてアジャイルをテーラリング
本日は「アジャイル実務ガイド」より、
テーラリングガイドラインに書かれている内容を簡単に紹介しました。
大切なことは状況を見て、状況に合わせる形にテーラリングする事かと思います。
プロジェクトはさまざまな状況にあれ、どれ一つとして同じものはありません。
また、組織の文化や前提条件もそれぞれ違うでしょう。
また「アジャイル実務ガイド」には、
テーラリングをするには、
そもそも本来定義されているアジャイル手法を使用して成功してきた経験豊富な人が取り組みべきである。
と書かれています。
基本の手法の効果がわかっていないとそもそもテーラリング出来ないということですよね。
順序としては正攻法を使いこなすことが必要ということで、
しっかり学習をする必要があるということです。
アジャイルというアプローチは強力です。
しかし、上手く状況に適合させないと意味をなさなくなってしまいます。
私自身も「アジャイル実務ガイド」やその他のアジャイルに関する学習を進めて、
適合させていきたいものです。
アジャイルをうまく活用できるように頑張っていきたいものですね。
参考書籍：「アジャイル実務ガイド」 Project Management Institute
