bit Labs

はじめに

近年、アジャイル開発はスタートアップだけでなく、大企業でも取り入れられることが多くなっており、その対象もスマホアプリから基幹システムまで様々な対象への適用事例が多く出てきています。アジャイル開発はチームの自主性を重要視しており、適用事例では従来型のマネジメントからチーム自らマネジメントを行っていく「自己組織化」を推奨しているものをよく見かけると思います。一方、マネジメント観点でマネージャが何をすれば良いのかを示している事例はあまり多くないのが現状です。本稿では、アジャイルなチームに対して、組織のマネージャ層がどのように接するべきか、どのようにサポートするべきかを検討します。

アジャイルチームのマネジメントの２つの基本

アジャイルチームに対するマネジメントの大原則は、「Howに口出ししない」と「チームのサポートに徹する」の2つです。まずはこの2つの基本について考えていきます。アジャイル開発に限らずプロダクトはチームによって作られます。そのため、より良いプロダクトを作るためには、チームを強くすることが重要です。では、強いチームとは何でしょうか。強いチームとは、自ら課題を発見し、解決策を自ら見つけ出し、実行していくことができるチームのことです。このような、チームが自ら主体的に活動している状態を、専門用語で「自己組織化」と呼びます。「自己組織化」されたチームは、生産性が高く、組織へのエンゲージメントが高く、自ら最適なソリューションを選択していくという特徴を持ちます。マネージャがHowに口出しすること、つまり、従来型のトップダウン型のコマンドコントロールを行うことは、この「自己組織化」を阻害する直接的な原因になってしまいます。その代わりにマネージャは、チームだけでは解決が難しい問題についてサポートを提供していくことが重要になります。チームが進むべき方向性に悩んでいれば、チームが進むべきビジョンやKPI（重要達成度指標）をわかりやすく示すことが求められますし、大きな組織構造の中でチームが活動しにくい状態になっているのであれば、マネージャがその障害物を除去することを手伝ってあげることも必要となります。

図１：このようなリーダーシップのあり方は「サーバント型リーダーシップ」とも呼ばれており、成功するアジャイルプロジェクトに必要不可欠な要素のひとつです。

“チームの状態”をチェックする３つのポイント

マネージャは、チームが良い状態なのかそうでもないのかを把握し、適切な対策をチームにアドバイスする必要があります。従来のウォーターフォール型のプロジェクトであれば、進捗確認、課題確認、品質確認の中でマネージャがチームの問題点を把握し、その対策を指示することを行っていたと思います。では、チームの自主性を重視するアジャイル開発において、マネージャはどのような点をチェックするべきでしょうか。

① プロジェクトゴールが「明確」かどうか？

アジャイル開発では、小さく作ってその結果を見て軌道修正を行っていくスタイルでプロジェクトを進めていきますが、それは決して事前にプロジェクトのゴールを定めないということではありません。アジャイル開発のよくある誤解として、「アジャイルだからゴールを定めずにすぐに始める方が良い」という意見があります。これは間違った理解で、軌道修正を頻繁に実施するアジャイル開発だからこそ、プロジェクトのゴールを明確に定めてチームで共通認識を持つことが重要です。そうしないと、チームが向かうべき方向を見失ってしまい、結果として「お金と時間を無駄遣いしただけ」という状態になってしまう危険性があります。最近よく耳にする「PoC（Proof of Concept）疲れ」という言葉も、「まずはやってみよう」の掛け声の元で、ゴールが明確ではないプロジェクトを繰り返してしまったことがひとつの要因ではないかと考えられます。アジャイルチームがゴールを明確に定めて進んでいるのか、マネージャの眼でしっかりチェックしていくことが重要です。

図2：アジャイルは少しずつ方向転換し、時にはゴールを変更しながらゴールに向かっていきますが、そもそものゴールが明確でないとチームが迷走してしまいます。

② スコープコントロールが出来ているかどうか？

ウォーターフォール型のプロジェクトでは、QCDのうち、まず開発スコープを定めて、求められる品質（Quality）を保つ前提で、期間（Delivery）と費用（Cost）を見積もります。一方、アジャイル開発では、プロダクトに求められる品質（Q）を保つ前提で、期間（D）と費用（C）を固定し、開発スコープをコントロールすることが基本となります。アジャイル開発では、新たな機能要求や機能変更を柔軟に行っていきます。そこで、元の開発スコープが固定になってしまっていると、変更を受け入れれば受け入れるほどチームの負担が大きくなり、結果、チームが崩壊してしまう危険性があります。マネージャは、チームが経営層やビジネス部門等のステークホルダー側に、「柔軟にスコープをコントロールする」という前提がきちんと理解された上で、プロジェクトが運営されているかどうかをチェックする必要があります。また、スケジュールに遅れが発生しているような場合でも、チームにプレッシャーをかけるのではなく、その状況をまずは受け入れて次にどうしていくかについて、ステークホルダーを含めて協議する必要があります。

図３：アジャイルでは開発した機能の変更を柔軟に実施しますが、機能変更に伴い開発スコープを常に見直していく必要があります。

③ ステークホルダーとのコミュニケーションが適切か？

アジャイル開発では、プロジェクトのゴールを定めてそこに向かって行きますが、どのようにそこに進んでいくかはチームが柔軟に変更していきます。また、環境や状況が変わった場合に柔軟に、ゴールそのものの見直しも行っていきます。その際に、投資元のビジネスオーナーやステークホルダーと進み方の認識合わせが出来ていないと、結果としてステークホルダーが求める方向とチームが異なる方向に向かってしまっている危険性があります。マネージャはチームがステークホルダーと定期的に適切な内容のコミュニケーションを取れているかを確認し、取れていない場合はその原因に対する対策をチームと一緒に検討する必要があります。

図４：アジャイルでは、プロジェクトの進め方についてチームの自主性が尊重されますが、スポンサーであるステークホルダーと目指すべき「ゴール」を常に認識を合わせながら進める必要があります。

おわりに

本稿では組織のマネージャとアジャイルチームとの関わり方について考えてきました。アジャイルに関連する書籍や記事を見ると、マネージャは不要であるかのような書かれ方をしているものもありますが、プレイヤーだけの完璧なチームが世の中には存在しないように、チームをサポートするマネージャの役割は今までと同様に重要になってきます。チームに関わることを恐れずに、アジャイルならではの、新しいチームとの関わり方を実践してみてください。

bit Labsのサービス