イノベーションの創出には、スタートアップのような「小さなチーム」を作り、潜在顧客のニーズ探索と小さな製品開発から始めることが必要である。これは、欧米企業がシリコンバレーから学んだことであり、既存の大企業でもこの小さなアジャイルチームを作る動きが活発化している。

制作：JBpress

とはいっても、なかなか既存の文化、組織の中でスタートアップのような活動を行うことは難しい。意思決定のスピードをあげ、試行と学習ループをすばやく回すことは、大企業のこれまでの管理の仕方と組織間のしがらみの中では難しい（年次予算計画との整合、企画と開発の分離、予算承認、調達部門との関係、品質保証部門との関係、などなど）。

以上を踏まえて、既存大企業の中で新しい変革を行っていくための、具体的な提言を行う。提言は次の7つである。

【1】経営陣がアジャイルを理解し、企業文化を醸成すること
【2】既存の情報システム部門と別に、イノベーション部隊を建設すること
【3】イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること
【4】経験のあるアジャイルコーチ、スクラムマスターを招き入れる、もしくは採用すること
【5】アジャイル開発の教育を行い、徐々に経験者をふやすこと
【6】技術力のあるエンジニアを招集すること
【7】コミュニティへのエンジニア参加を推奨し、外部交流を行うこと

以下ではそれぞれについて解説する。
 

まず、イノベーション文化を醸成するには、企画・開発が一体化した組織のあり方、現代のソフトウエア文化を支えるアジャイル開発を理解する必要がある。これは、「ワークスタイルの変革」の文脈で捉えることもできる。エンジニアたちにできる限り自己組織的なチーム運営を任せる。働きやすい環境を与える。ツールやマシンを買い与える。

よく誤解されるが、アジャイル開発は「無規律」ではない。むしろタイムボックスに沿って強く（自律的に）マネジメントされている。定期的な自己改善と計測を行いながら、市場にフィットした製品やサービスを作り出すための、ビジネスとエンジニアリングのコミュニケーション手法である。これを経営は戦略として利用しない手はない。イノベーションは「内的モチベーション」から発生する。世界を変えたい、と思っている人たちに権限と裁量を与えるのが一番だ。

これまでの情報システム部門は、どうしてもベンダーをコントロールして計画どおりの成果を予算以内で作る（QCD）に注力してしまっていた。イノベーションの世界では「つくるべきもの」の定義を、ニーズ探索と小さな製品づくりを繰り返して行う（鶏と卵を同時に育てる）のだから、このやり方ではうまく行かない。

これからは、別途インハウスのイノベーション部隊を新しく組織する必要がある。そこに固定枠の予算をとる。新子会社を作ったり、社長直轄の部署を作ることもあろう。とにかく、小さなチーム（10名以内程度）を、必要であれば複数作る。そして、そのチーム単位で投資する。それをまとめて1つの部署にするのもよい。また、既存事業部署との関係を強くもつチームがあってもよい。むしろ、企業の強みを生かすためにはそうすべきだ。既存事業はその企業の強みであるはずで、そこを生かしながらイノベーションの外部関係を模索して行くのがよい。

また、その部隊は「内製」を目指すべきだ。そのためにはソフトウエアエンジニアが社内に必要になる。まず社内から募ろう。きっとよい人材がみつかる。見つからなくても、外部に単純に委託せず、ともに考えてくれるベンダーと準委任契約することを考えよう。イノベーションは、QCDの達成が目的ではない。ベンダーにリスクを負わせてはいけない。コストや営業力、プレゼンのうまさで選ぶのではなく、ともにアジャイル開発ができるよい人材を持つベンダーを選別し、信頼して付き合える関係を築こう。

そういったイノベーション部隊を、計画達成度の進捗管理のもとに置くべきではない。そもそも計画できないのがイノベーションである。また、新しいアイデアが10出たとして、そのうち成功にまでたどり着くものはせいぜい1つあるかないかだ。これを計画対比で進捗管理してしまったら、確実につぶしてしまうだろう。ファンドを運営するように、小さな投資を複数に行うべきだ。

そのチームは、開発と企画の一体となった組織横断でつくり、品質保証やユーザー体験（UX）づくり、データ分析部隊も含めて一体化させる。そして生き残っていくものにさらに投資する。意思決定を細かく行い、ステージ管理をして少数のイノベーションを育てる必要がある。

新しい製品やサービスが、既存のシステムと連携することはよくある。いわゆるMode-1とMode-2の連携である。その場合でも、種となる人材を既存部隊から移動し、連携を含めて企画していく必要がある。

まずはチームにアジャイルの教育を行う。できれば、すでに社内のアジャイル開発経験者を中心に、社内勉強会を始めるのがよいだろう。アジャイル実践者には強いモチベーションを持っている人が少なくない。その人を中心にしてチームを育てよう。また、いない場合や、いても教育を加速させたいときのために、外部の教育サービスを利用することもできる。最近、アジャイル教育のサービスを行っている会社が日本でも多く出てきた。そこに教育を手伝ってもらう。

ただし、「唯一の正しい」アジャイル開発があるわけではない。自分の会社に合ったやり方が自社のビジネスや文化から自然と育っていくのがアジャイル開発の本質である。基本的なことを外部から学んだら、自社で自走するように、あとはコーチを作って社内に実践者をオーガニックに増やしていくことが必要だ。

アジャイル開発の実践には、本を読んだり教育セミナーに参加したりするだけでは不十分だ。言葉では伝わらない「経験」がものをいう領域である。一度もアジャイル開発の経験がなければ、自信をもって「こうすべきだ」と言うことができない。本や文書には質問できないが、コーチには質問できる。アジャイル経験者をコーチにしよう。もし、社内にアジャイル経験者がいなければ、外から来てもらおう。長い期間いてもらう必要はない。最初にチームを作りしばらく自力で走れるようになるまでは、外部コーチを受け入れよう。採用を考えるのも、もちろんよい。

イノベーション部隊は内製であることが望ましいが、社内に十分な人数のソフトウエアエンジニアがいない場合もある。もし、デジタルイノベーション（DX）を標榜し、それを企業のコア資産だと考えるなら、すぐに採用を始めよう。そうでない場合、自社の情報システム子会社、関連会社、ソフトウエアベンダーなどから、技術力のあるエンジニアを招き入れる。

ただし、「請負開発」ではないので、完成責任と瑕疵担保責任を明記した請負契約は不適当である。準委任契約によって、優秀な（経験ある）その特定分野のエンジニアを招き入れる。技術力があるエンジニアは、「人月」の一部として安く調達されたエンジニアの優に数倍の価値がある。

そのようなエンジニアを採用したり、契約したりするには、技術が分かり技術者を目利きできるCTO職が必要になるかもしれない。社内な優秀なエンジニアがその候補だ。

【7】コミュニティへのエンジニア参加を推奨し、外部交流を行うこと

社内エンジニア、もしくは外部から招き入れたエンジニアが確保でき、アジャイルを回せる人が出てきたら、そのエンジニアたちに外部コミュニティへの参加を推奨しよう。アジャイル開発は多くの文脈依存（市場・プロジェクト・プロダクト・文化）のノウハウが暗黙知として存在する。それを獲得するには、日本・海外の他のエンジニアたちとの交流が大いに役に立つ。小さくてもよいので、事例ができたら積極的に外部コミュニティで発表しよう。アジャイルジャパンやスクラムギャザリングは国内の大きなコミュニティであるが、それ以外にも多く外部からの発表を受け入れるカンファレンスや勉強会が存在する。

チームは最初、悩みながら自分たちのチームを運営するだろう。そこには技術的な課題、マネジメント的な課題の両方が存在し、日々それらと直面することになる。政治的なこと、人事的なこと、予算的なことも含めたチーム作りの課題等、現実的な問題である。社内だけで解決することは難しい。解決のヒントの多くは社外に存在する。

ソフトウエアの世界では伝統的にこういった技術交流の場が、会社という枠を超えて存在している。その中心にあるのは技術的な興味であり、情熱である。新しいことを突き進めるには、情熱が不可欠だ。

こういった場に頻繁に参加しているエンジニアは、新しい知識を外部から取り入れながら急速に成長し、社内でも活躍するようになるだろう。経営陣としては、このような活動への参加を本来業務ではないとして渋るのではなく、逆に推奨して参加させるべきだ。