【PMスタイル考】第177話 アジャイルを経営に活かす~アジャイルな開発、チーム、組織、そして経営へ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆プロジェクトマネジメントの導入をみていて感じること
日本企業や日本型組織が苦手だとされている考え方の一つに多様性がある。多様性のなさを示唆するエピソードはさまざまで言い尽くされている感がある。日本企業で働いている人であれば、一度や二度は遭遇したことがあるのではないだろうか。
マネジメントの世界でももちろんこの問題はある。典型的なものは、標準化という考えと結びつけ、何がなんでも同じようにマネジメントしようとすることだろう。最近でいえばプロジェクトマネジメントにその兆候が見られる。
プロジェクトマネジメントは日本ではITの分野で導入され効果があったため、プロジェクト(的)な活動であれば、すべて同じ手法で管理するという方向に向かった。そして、これが過剰なプロジェクトマネジメントを行う原因になっていることをよく見かける。
この問題は日本企業のPMBOK(R)の使い方を見ると顕著である。PMBOK(R)は(プロセス)標準ではなく、プロジェクトマネジメントを実践するために必要な要件を明確にし、その要件を満たすツールを探してきて実践するフレームワークである。にもかかわらず、大抵の企業はプロセス標準の発想で活用している。つまり、標準的なプロセスとして導入し、その通りにやることを求めている。これは、マネジメントの発想ではない。
標準化というのはプロセスに適用される考え方で、標準化することによって、プロセスを改善、洗練するといった管理が効果的になることに意味がある。ところが、プロジェクトはもっと複雑な(システマティックな)ものであり、標準化してもメリットが得られるとは限らない。そればかりでなく、標準として想定されているより単純なプロジェクトに適用しようとすれば、必要以上に複雑なマネジメントが必要になり、パフォーマンスを下げてしまう。これは上に述べた通りだ。
◆アジャイルで行われていること
最近の手法で、同様に標準化の問題を感じているのが、アジャイルだ。今回のPMスタイル考はアジャイルについて考えてみたい。
日本でアジャイルが注目されるようになったのは15年くらい前で、比較的新しい分野だ。それ以来、幾度となく、コンサルティングで接点があるが、ずっと気になっていることがある。それは、アジャイルが有効であれば、何とかして水平展開しようとすることだ。水平展開という言葉を使ったのはちょっとした想いがあるのだが、例えば、アジャイルによって一つの開発作業が効率的にできれば、その部門の開発はすべてアジャイルでやろうとするのだ。要するにプロセスの標準化の発想である。
これは、開発(というかテクノロジー)の分野で活用しているのでそういう発想になっていると思われるが、このような発想は本当に正しいのかという疑問を持っている。不確実性の低い開発にアジャイルを使おうとするのは本当に正しいのかという疑問だ。
この疑問、経営的にみれば答えははっきりしている。正しくない。正しいのは、アジャイルに取り組むものと、ウォーターフォール(従来型)で取り組む開発のバランスの問題なのだ。つまり、多様性が重要なのだ。これが冒頭に述べた問題である。
日本では、アジャイルはまずITの開発分野で導入された。顧客やユーザを理解し、彼らを巻き込みながら製品を作り上げていくためには、アジャイルが最良の方法だと考えられたのだ。
◆新たな新製品開発競争とアジャイル
そこに、もう一つの流れもあった。日本には1980年代に生まれた日本の独特の方法である新しい製品開発ゲームのコンセプトがアジャイルの考え方とマッチしたことだ。このコンセプトとは、1986年に「ハーバード・ビジネス・レビュー」誌に掲載された、野中郁次郎と竹内弘高の論文で、タイトルは「新たな新製品開発競争(The New New Product Development Game)」であった。
この論文で野中と竹内は、ホンダ、富士ゼロックス、3M、ヒューレット・パッカードなど、生産性の高い革新的な企業を分析し、NASAに代表される段階的なプログラム開発、すなわちウォーターフォール方式には根本的に欠けているものがあると指摘したのだ。
そしてこの方法は、ジェフ・サザーランドとケン・シュエイバーが1990年代にIT産業の開発の現場で効果的にソフトウェア開発を進める手法として開発したスクラムの原点になったされている。
その後、スクラムがアジャイルの中で注目されたことも追い風になったこともあり、日本のやり方とアジャイルは相性が良かったと考えられる。
◆アジャイルのフレームワーク
その後、アジャイルは組織全体へスケールされるようになる。アジャイルのフレームワークは数十種類あると言われている。そして、米国ではすべてのチームが同じフレームワークを実践しているとは限らない。あるチームはスクラムを利用し、別のチームはカンバン、エクストリーム・プログラミング(XP)、また別のチームはクリスタル・システムズ・ディベロップメント・メソッド(DSDM)を利用するというような実践がされているケースもある。
もちろん、このような実践のためには、コストがかかる。日本では標準的なフレームワーク(スクラムが圧倒的に多い)を決めて、組織的に展開している理由はこのコストを避けている一面がある。
利用されている割合は、スクラムが圧倒的にトップで、2位のカンバンと比べて10倍近い顧客の活用されていると言われている。これはスクラムという手法の持つ特性によると思われる。スクラムは非常に柔軟性があるフレームワークで、カンバンやXPなどと簡単に結びつけることができる。このため、スクラムが選ばれる可能性が高く、それに伴い、トレーニングが充実し、ノウハウも蓄積されている。
◆「アジャイル・アット・スケール」
一方で、アジャイルの対象も製品開発からどんどん組織全体へ広がってきた。これは、End-to-Endという概念で表現されるように、「アイデアを考え顧客に価値を届けるまでの最初から最後まで」、アジャイルにしようとするものである。
このために2010年くらいからアジャイルのコンセプトのアップデートをするスケーリングが考えられるようになってきた。スケーリングはアジャイルを開発チームだけではなく、組織全体に適用することにより学習を多元的に行うものだ。
スケーリングのフレームワークとしてよく使われているのは、スケールド・アジャイル・フレームワーク(SAFe)、スクラム・オフ・スクラムズ、インターナリー・クリエイテッド・メソッド、ドント・ノウなどがある。この分野はさらに新しく、どんどん新規参入がある。例えば、最近注目されているフレームワークに、ほとんと未着手だったメディア・サービスの分野でスポティファイ社が作り上げたスポティファイ・モデルといったフレームワークがある。
スケーリングは小さくても良いので素早く顧客に価値を届け、そこから顧客のニーズを学習することを重視するという流れの考え方である。つまり、アジャイル開発の考え方や働き方を開発チームだけでなく組織全体にスケールさせるものだが、スケーリングして作られる組織はアジャイル組織と呼ばれる。組織のすべての領域で顧客に対し素早く価値を届け、学習を繰り返すようになる。
◆アジャイル組織の考え方
アジャイル組織は、スクアッド(分隊)というチームを基本単位として運営する。スクアッドの特徴として挙げられるのは以下の通りだ。
・9人以下のスタートアップのような雰囲気のチーム
・後述のトライブの優先順位を鑑みて、目的、権限、責務が設定される
・単独で顧客に価値を提供できる「End-to-Endの単位」で区切る
・プロダクトオーナーが設置され、仕事の優先順位付け、プロジェクトマネジメントを行う
そして、アジャイル組織に移行するために重要なのは
・変化に強い組織への移行の意思決定
・素早い学習サイクル
・End to Endの単位での組織設計
・パーパス(目的)ドリブン
・ピープルマネジメント
の5つだとされている。
◆アジャイル組織の経営的課題
ここまでは、製品を中心にしたアジャイルだが、経営という視点からみると問題が2つある。一つは、経営全般でみれば、アジャイル組織をつくり、開発プロジェクトをアジャイル化しても、経営的にみた場合に業務効率が画期的に改善されるものではないという問題だ。
例えば、ある製造業では、開発現場にアジャイルを取り入れたが、製品の展開までの時間はあまり変わっていないし、コストもあまり変化していないという現実に遭遇した。開発自体の時間は短縮されているのだが、戦略的な企画立案、意思決定の承認、予算の確保、人材配置のタイミングなどがそのままだからだ。
これは、考えてみればすぐにわかる。仮に企業における開発作業以外の作業の稼働率が20%だとすると、アジャイルで仮に30%の作業スピードが改善されても、業務スピードが6%しか改善されないのだ。
つまり、アジャイルの効果を経営的に生かす(イノベーションの創出速度を速める)ためには、大局的な取り組みが必要なのだ。
もう一つの大きな問題は、アジャイルの適用範囲だ。日本企業でもそうだが、アジャイルが適用されるプロジェクトは注目されるプロジェクトであり、そこに経営的な関心も集中する。このため、アジャイルにかかわるコストを賄うために業務や業務サポートに充てる人材を減らすことになる。そして、業務のスピードが減少する。これは、上で述べた稼働時間の減少を意味する。つまり、アジャイルにすることによって、却って開発プロジェクトの期間が伸び、イノベーションのスピードが減少するということになりかねない。
しかし、イノベーションを考えてみればすぐにわかるように、アジャイルを適用し開発した製品が収益源になるとは限らない。これはイノベーションにはついて回る問題だが、だからといって保守的になりすぎれば、イノベーションが生まれなくなる。
◆アジャイル経営企業への道
このように、経営的に考えれば、アジャイルをどの範囲に適用し、イノベーションを生み出しながら、収益の確保をするかは非常に難しい課題である。この課題を乗り越えた企業はアジャイル経営企業と呼ばれている。
つまり、アジャイル経営企業は、単に開発作業のスピードを上げることではなく、この経営的な課題を乗り越えて、
・従来型のやり方の業務を効率的に行う
・予期せぬビジネスチャンスに遭遇すればアジャイルの適用によって取り込んでいく
・従来型のやり方の業務とアジャイル業務のバランスをとる
を実現することに他ならない。
以上のように、アジャイルの導入・範囲の拡大は、
アジャイル開発→アジャイルチーム→アジャイル組織→アジャイル経営企業
と行われていく。このように考えてみると、アジャイルの拡大自体がアジャイルな取り組みだと考えることが望ましい。これによって、経営的なバランスが取れるようにアジャイルの範囲を試行錯誤していくことになるだろう。
◆おわりに
日本は慢性的なイノベーション不足だと言われて久しい。
アジャイル開発を導入したい理由は、顧客に声を聞き、そこから新しいデザインや技術などのイノベーションを起こしたいからである。だから、なんでもかんでもアジャイルというのはいいことだと考えるかもしれないが、イノベーションが起こらない理由は、そこではない。
アジャイルを導入すれば、なんでもかんでもアジャイルにしたがるところにある。これが現場主義の弊害だと思われるが、経営的にみれば、それではやっていけないことは今回のPMスタイル考でお分かりいただけたかと思う。
この問題の本質は多様性が受け入れられないことであるが、こういう発想でやっている限り、イノベーションが生まれにくいという状況は変わらないだろう。アジャイルを経営的に生かすには、ここを変えていく必要がある。つまり、アジャイルを組織にスケールしていく中で、従来型の業務とアジャイル業務のバランスを取る必要がある。
このバランスをとるためには、コンセプチュアルスキルが必要になることはいうまでもないだろう。
コメント