Scrum Inc.に聞く、アジャイル開発がうまくいかない理由と、イノベーションを起こすために必要なこと：DX時代のDevOps／アジャイルヒーローたち（1）（2/3 ページ）

デジタルトランスフォーメーション（DX）のトレンドが進展し、テクノロジーの力を使って新しい価値を打ち出す「企画力」と「スピード」が、ビジネス差別化の一大要件となっている。その手段となるアジャイル開発やDevOpsは企業にとって不可欠なものとなり、実践に乗り出す企業も着実に増えつつある。だが国内での成功例は、いまだ限られているのが現実だ。本連載ではDevOps／アジャイル開発の導入を支援しているDevOps／アジャイルヒーローたちにインタビュー。「ソフトウェアの戦い」に勝てる組織の作り方を探る。

[文:斎藤公二／インタビュー・構成:内野宏信／＠IT]

日本に源流を持つアジャイル開発が、なぜ日本に浸透しないのか？

編集部　しかし、アジャイル開発の源流はもともと日本の製造業にあった考え方です。それなのに、日本ではなぜ受け入れられなかったり、取り組んでもうまくいかなかったりするケースが多いのでしょうね。

「日本企業は『カイゼンという方法論』にばかり目が行きがちで、『カイゼンの実践に不可欠な複数の要素』には目が向いていないことが多いのでは」

シュナイアー氏　おっしゃる通り、トヨタ生産方式は世界中に普及し、ITの世界にも取り入れられました。トヨタは「最高のクルマを作ろう」という考え方をイノベーションに当てはめて考えた。つまり、より良いプロダクトを作るために、人をエンパワーし、チームが一丸となってカイゼンを続けることがイノベーションにつながると考えた。

　カイゼンというと「既存の課題を解決すること」と思われがちですが、新しい方法を生み出す上でも有効なのです。そうした好例があるのに、日本企業の多くは「カイゼンという方法論」にばかり目が行きがちで、“組織をフラットにすること”をはじめ、「カイゼンの実践に不可欠な複数の要素」には目が向いていないことが多いと感じます。

トヨタ生産方式：トヨタ自動車が編み出したモノづくりに関する体系的活動。一般に「かんばん」「多能工」「多工程持ち」「省人化」「少人化」「アンドン」などの各手法を組み合わせた生産方法と説明されるが、「絶え間ない改善の精神」「改善を行う際のものの見方・考え方」がトヨタ生産方式の本質と説明されることもある。

　アジャイル開発の在り方を理解する上では、例えば宮本武蔵の「五輪書」も有効です。実は武蔵はリーン開発の曽祖父と言っていい存在です。英訳されてITエンジニアに広く受け入れられている言葉に、五輪書の「Do nothing which is of no use」（役に立たぬことをせざること）」があります。「ムダなことをしない」という意味ですが、これを現場で徹底するのは実に難しい。

　日本では、必要以上にドキュメントを作らせたり、労働に過大な時間を費やしたりしていますよね。ほとんど誰にも読まれないドキュメントも多い。「役に立たぬこと」どころか、より良いプロダクトを作ろうといったスピリット自体を壊してしまっています。野中郁次郎氏と竹内弘高氏が1983年に発表した論文で、スクラムのベースになった「The New New Product Development Game」も、アジャイル開発の在り方を知る上で必読の作品です。

大規模開発には向かない、という大きな誤解

編集部　一方で、アジャイル開発への関心があらためて高まっている中で、アジャイル開発の適用領域としてSoE（System of Engagement）／SoR（System of Record）を1つの基準とする考え方があります。システムの特性によるアジャイルの向き不向きについては、どうお考えですか？

シュナイアー氏　向く、向かないというのはよくあるフィクションで、実は米国でもよくある誤解です。アジャイル開発は「課題を少しずつ解決する」手段の1つです。どのような業種・規模の企業でも採用できますし、どのようなシステムにも適用できます。もちろんシステム全てにアジャイル開発を適用する必要はありませんが、メインフレームなどのシステムにもアジャイルの核となっているリーンの考え方は適用できます。アジャイルかウオーターフォールかは各社の目的や状況に応じて判断すべきです。

参考リンク：

• 書籍でたどる「リーン」の本質（＠IT）
• 「アジャイル開発」と「リーン」の関係（＠IT）

編集部　しかし、日本国内では「アジャイル開発は大規模開発には向かないのでは」という考え方も根強く残っています。

シュナイアー氏　それもよくある誤解です。アジャイル開発はやり方の違いにすぎず、開発の規模やアーキテクチャに左右されるものではありません。ちなみにアジャイル開発におけるアーキテクチャ設計のポイントはモジュラー化にあります。レゴブロックのように2つのブロックの組み合わせから、どんな大きさにも拡大させることができます。もちろん全てを“レゴブロック”で構成する必要はありません。新たなブロックに既存のブロックをつないでもいい。

「Scrum Inc.認定資格スクラムマスター研修／Scrum Inc.認定資格プロダクトオーナー研修」の模様。分かりやすく力強い言葉に多くの受講者が熱心に耳を傾けていた

　そこで重要となるのがインタフェースです。Contract-First Designと呼ばれる、インタフェースを最初に設計していく手法があります。インタフェースさえしっかりしていれば、システム同士を連携させたり、クラウド上にある新たなサービスにオンプレミスの古い既存システムを連携させたりすることも容易です。

編集部　そうした文脈では、マイクロサービスアーキテクチャも注目されていますね。

シュナイアー氏　そうですね。マイクロサービスアーキテクチャのメリットはiPhoneにおけるOSとアプリの関係を考えれば分かりやすいかもしれません。それぞれのアプリは独立して動作しているが、OSの中でしっかりと管理されている。あるアプリはアジャイルスクラムで作ってもいいし、あるアプリはウオーターフォールで作ってもいい。開発チームごとに異なる開発言語を使ってもいい。ただしiPhone全体としては“プロダクトとしてのイノベーション”を継続的に追求できるというわけです。

編集部　ただ全システムをアジャイル開発で作るわけではない以上、ウオーターフォール型開発チームとの連携の問題もあると思います。両者の連携にはどのような問題が起こりがちだとお考えですか？

シュナイアー氏　問題は「レポーティングの構造」と「使っているKPI」で起こります。これらはウオーターフォールとアジャイルのチームで全く異なりますから、それこそMacとWindowsをつなぐようなもので、お互いの文化や“プロトコル”を完全には理解できないのです。

右はScrum.Inc 所属トレーナー クロエ・オニール（Chloe O’Neil）氏。研修ではシュナイアー氏と共に登壇した

　そこでわれわれが提案しているのが「トランスレーションレイヤー」を設置することです。これは「お互いの言葉をそれぞれが正しく理解し合えるように、部分的に翻訳して伝える役割」のことです。これによって連携は少しずつうまくいくようになると考えています。

　ただし、ポイントはトランスレーションレイヤーをずっと置き続けてはいけないということです。イノベーションが成功したら、直ちに取り去るようにします。そうしないと、いつまでも両者の溝は埋まりません。