前回の記事は、孫氏の兵法「孫子曰く、先に戦地に処りて、敵を待つ者は佚（いっ）し、後れて戦地に処りて戦いに趨（おもむ）く者は労す。」を持ち出しました。
競争相手に優位に立つためには、相手を自分に引き寄せるようにすることが鍵です。自分が引き寄せられる戦いは避けるのが鉄則です。
下図の「利得表」は、Ａ社のCRMクラウドサービスが、Ｂ社に先んじて「セキュリティ強化」のバージョンをリリースしたことで、競合するＢ社がＡ社と同じ「セキュリティ強化」をリリースすると惨敗する様子が見て取れます。
| Ｂ社 | |||
| セキュリティ強化 | 操作性の向上 | ||
| Ａ社 | セキュリティ強化 | （48,12） | （60,40） |
| 操作性の向上 | ー | ー | |
先行するＡ社の手を見たＢ社のクラウドサービスがリリースするべき機能は「操作性の向上」です。Ａ社に顧客の多くを奪われ、僅かに残ったセキュリティを重視する顧客（12社）より、「操作性の向上」を望む顧客（40社）を確実に獲得することが、ゲームを続ける鉄則です。
しかし、Ｂ社が既に「セキュリティ強化」をリリースする計画を進めていた場合、話がちょっとややこしくなります。Ｂ社がシステムの要求事項となる「セキュリティ強化」の為に投入した開発コストを無駄にしてしまうかもしれません。
Ｂ社が競争力をつけるには、要求が変更されても柔軟に対応ができるプロダクトの開発体制を作ることが必要でしょう。
注目すべきは、スクラムと呼ばれる開発方法論です。
スクラムはラグビーでよく聞く言葉です。ボールがチーム内で受け渡され、チームがユニットとしてフィールドを進んでいくような開発をスクラム開発と呼びます。
スクラム開発は、バックログとスプリントという言葉がよく使われます。
バックログには、プロダクトに必要な要求事項に優先順位つけて並べたプロダクトバックログと、プロダクトバックログにある要求事項を開発者が作業可能なタスクレベルに落とし込んだスプリントバックログがあります。
スクラム開発では、スプリントバックログに記録されたタスクを基に1週間から2週間という比較的短サイクルでの開発が進みます。
スプリントは、開発期間を短く設定している点が特徴です。顧客から新たな要望が出てきたとしても、次のスプリントで対応するなど柔軟に対応できます。ひとつの開発規模は小さいのですが、小さな改善を繰り返すことで、プロダクトのチカラを強くしています。
スクラムがチームとして進めるために、重要な司令塔となるのが、プロダクトマネジャーとスクラムマスターです。
プロダクトマネジャーは、プロダクトバックログを監督します。プロダクトへの要求事項を管理し、要求事項の優先順位をつけるのはプロダクトマネジャーの判断が必要です。
スクラムマスターは、スプリントの計画をたて、日々進捗を管理しますが、重要なミッションはプロダクトマネジャーと連携しながら、実際の開発を担うスクラムチームの精神的な支えになることです。
スクラムマスターは、開発の進捗を管理することから、プロジェクトマネジャーと同じに見えますが、あえてスクラムマスターと呼ぶのは、スクラム開発の主役はスクラムチームを構成するエンジニアであり、スクラムマスターはある種の裏方として機能するからです。わたしの知っているスクラムマスターで、開発状況が忙しくなると、事務所を出て駅近くのビアードパパのシュークリームを買って、スクラムチームのエンジニアにふるまう人がいるのですが、そういう気配りはスクラムマスターに必要な資質です。
VUCA（ブーカ）時代と呼ばれるいまは、あらゆるものを取り巻く環境が複雑さを増し、将来の予測が困難なときです。
顧客の要求は、ちょっとした空気で変わることを前提として、競争に勝てる企業が生き残るべきなんだと思います。
