Scrum Inc.に聞く、アジャイル開発がうまくいかない理由と、イノベーションを起こすために必要なこと:DX時代のDevOps/アジャイルヒーローたち(1)(1/3 ページ)
デジタルトランスフォーメーション(DX)のトレンドが進展し、テクノロジーの力を使って新しい価値を打ち出す「企画力」と「スピード」が、ビジネス差別化の一大要件となっている。その手段となるアジャイル開発やDevOpsは企業にとって不可欠なものとなり、実践に乗り出す企業も着実に増えつつある。だが国内での成功例は、いまだ限られているのが現実だ。本連載ではDevOps/アジャイル開発の導入を支援しているDevOps/アジャイルヒーローたちにインタビュー。「ソフトウェアの戦い」に勝てる組織の作り方を探る。
今、企業が取り組むべき「変革」とは?
金融、製造をはじめ、各業種でデジタルトランスフォーメーションの取り組みが進む中、ITシステム開発・改善の在り方が収益・ブランドを左右する状況になって久しい。特に昨今はUberやメルカリのようなディスラプターの例を引き合いに出すまでもなく、“全く新しい利便性”をいかにスピーディーに創出できるかが勝負の鍵と広く認識されている。
だが経営環境変化が速い現在、“何が当たるか”正解を予測することは難しい。従って、新たなサービスを開発する上では、いち早くリリースし、市場からのフィードバックを得て、スピーディーにサービスを改善するため、アジャイル開発やDevOpsのアプローチが必然的に不可欠となる。これを受けて、外注によるウオーターフォール型開発が主流の日本企業においても、アジャイル開発やDevOpsの実践に乗り出す動きが着実に高まりつつあるようだ。
特にアジャイル開発については、導入支援を行うサービスも注目を集めている。中でもアジャイル開発のスタンダードな手法である「スクラム」の教育やトレーニング、コンサルティングを提供している米Scrum.Incはよく知られるところだが、日本国内でもKDDI、永和システムマネジメントと連携し、共同で教育サービスを展開している。
ただ周知の通り、アジャイル開発の実践はスキルやノウハウだけではなく、企業の文化、組織も絡んでくる問題だ。これが障壁となり、実践できない、あるいはチャレンジしてもうまくいかないケースが多い。ではビジネスが「ソフトウェアの戦い」の変容している今、ウオーターフォール型の文化を続けてきた一般的な従来型企業は、どのような考え方、スタンスに切り替えていく必要があるのだろうか?――
2017年9月23日〜26日に都内で開催された「Scrum Inc.認定資格スクラムマスター研修/Scrum Inc.認定資格プロダクトオーナー研修」のために来日した、Scrum Inc.のトレーニング&オペレーション担当バイスプレジデントのアヴィ・シュナイアー(Avi Schneier)氏に話を聞いた。
参考リンク:Scrum Inc.認定資格スクラムマスター研修
多くの企業が取り組むアジャイルスクラム
編集部 昨今、日本国内でもデジタルトランスフォーメーションのトレンドが進展し、「ビジネスがソフトウェアの戦いに変容している」という認識はかなり広がってきたと感じます。シュナイアーさんは昨今の状況をどのように見ていらっしゃいますか?
シュナイアー氏 アジャイル開発やその一手法であるスクラムの価値がより高まってきたと感じています。Scrum Inc.においても、多数の企業がトレーニングを受講するようになりました。例えば、TMNA(Toyota Motor North America)、Bain & Company、3M、Coca Colaなど業種も多岐にわたります。ITベンダーやシステム開発会社だけではなく、一般企業がデジタルトランスフォーメーションの観点からトレーニングを受けているのです。もちろん日本企業の顧客も多くいます。
ただ、イノベーションを創出するためには、ITだけでは不十分です。トレーニングと並ぶScrum Inc.のもう1つの事業であるコンサルティングを通じて、ITとビジネスの両方を支援しています。例えば、あるアパレル企業のケースでは、IT部門だけではなく、営業部門や製造部門におけるスクラムの導入も支援しました。その結果、新しい服を48時間でリリースできるようになりました。そうしたケースは他にも多数あります。スクラムは、システム開発のためだけのものではなく、“イノベーションのためのフレームワーク”なのです。
より噛み砕いて言えば、従来の組織に見られる多くの階層構造の中で行われる、たくさんのコマンド&コントロール(指揮命令系統)とマイクロマネジメント(過干渉)の弊害を取り除き、チームにビジョンを与えて変化を成し遂げていくためのものです。
イノベーションのモデルにはさまざまなものがありますが、その1つがスクラムの祖父である野中郁次郎氏が提唱したプロセスモデル「SECIモデル」でしょう。日本の企業は1970〜80年代にSECIモデルを使ってイノベーションを起こしましたが、それと同じように、今、米国の多くの企業がスクラムを使ってイノベーションを起こしているのです。
参考リンク:SECIモデル(@IT)
企業のイノベーションを阻むものとは?
編集部 ただ、経営層や現場層がイノベーションの必要性を実感していても、なかなか実践に踏み出せないケースが多いようです。日本企業において実践を阻んでいるものとは何だと思いますか?
シュナイアー氏 必要性を実感したなら試してみることが何より大事ですが、実践の障壁が高ければそれも難しくなります。その障壁の1つが「礼儀」や「組織の階層」だと考えます。礼儀は日本の誇るべき文化ですが、礼儀が邪魔をしてものを言いにくくしているようなら、それは障壁です。
また、アイデアがあっても実践するまでに乗り越えるべき階層が多いほど行動は遅くなってしまいます。フラットな組織にして、ものを言いやすく、行動しやすくすることがポイントです。例えば、従業員が1万人以上いるある米国企業では、一般社員からCEOまでの階層を2つしか設けていません。チームが自律的に動いてイノベーションを生み出すためには、組織はフラットである方が良いのです。
もう1つの障壁は「変化を恐れる勢力」です。階層が多い場合、たいていは中間管理職が抵抗勢力になります。スクラムの目的は「結果を出すこと」であり、「レポートを出すこと」ではありません。中間管理職が多いとレポートを出すことが目的になりやすい。その結果、行動が遅くなるのです。また、中間管理職は階層のどこにいるかでサラリーが決まることが多い。「フラットな組織に移行すると、自分たちの仕事がなくなるのではないか」と考えるため変化を恐れるのです。でもよくよく見渡してみると、管理職といいながら実際にマネジメントしている人はごくわずか、ということも珍しくないのではないでしょうか。
イノベーションを起こすためには、「組織のどこにいるか」ではなく、「もっと良いプロダクトを作るにはどうすればいいか」に頭を使うべきです。サラリーについても、ポジションではなく、イノベーションを起こすことに貢献した人を手厚く遇するようにすればいい。ピーター・ドラッカーも「企業の価値はマーケティングとイノベーションの2つからしか生まれない」「イノベーションは新しいアイデアを作ることで、マーケティングは新しい売り方のこと。それ以外はコストだ」と言っていますよね。
イノベーションに取り組むためには、会社を挙げて障壁を低くしながら、新しいことにトライできる組織に変えることが大切です。会社全体をいきなり変えることは難しいものですが、1つのチームで行った成果を受けて、2つのチームに、3つのチームにいった具合に取り組みを広げていけば、会社全体が変わります。
編集部 そのためには経営層の理解とリードがあることが前提になりますが、現場に「IoTをやれ」「X-Techをやれ」などとイノベーションを求めながら、言いっ放しであるために現場が困っているという話をよく耳にします。
シュナイアー氏 確かに、現場に「変われ」と言いながら「自分たちも変わらなければ」と考えているトップは少ないと思います。われわれもトレーニングやコンサルティングにおいて「イノベーションを起こすためにはCEOこそ変わるべきだ」と強く訴えています。
会社全体で変わっていくために、経営層にとって最も重要な要素はストラクチャとストラテジーの立案・実現です。そのために、米国企業では組織をマネジメントごと入れ替え、新しいリーダーシップのもと戦略を実行しているケースもあります。経営トップは自ら「変化すること」を受け入れ、リーダーシップを発揮しなければなりません。
一方、現場側も「こうしろ」と言われて命令に従うことに慣れてしまっている部分があるのではないでしょうか。現場にも、自らアイデアを考え、口に出して言う勇気が必要です。トップはアイデアを試す環境を与え、失敗させ、その失敗を正しく評価していけばよいのです。
編集部 そのためには評価指標も見直す必要がありますね。
シュナイアー氏 そうですね。「プロダクトの成果」を基に、個人単位でボーナスを出すのではなく、チーム単位で一定のボーナスを支給する仕組みに変える方法が最もシンプルだと思います。「私が頑張れたのはあなたのおかげ。あなたの成功は私の成功。だからチームみんなで等しく対価を受けましょう」という考え方です。
このように成功を分かち合う発想は、イノベーション創出の最も重要なファクターであるチームコラボレーションを活性化します。実際、米国では「プロダクトの成果」で評価する企業が多く、中には社員全員が同じボーナス額を受け取っている例もあります。全社員が協調して「プロダクトの成功」に貢献しているのです。
スクラムに限らず、アジャイル開発は単に方法論だけ取れ入れて、一時だけ、局所的に取り組むようなスタンスではうまくいきません。技術だけではなく、ビジョン、文化、制度、組織など、さまざまな要素を含めて“持続可能なペース”で全社的に変えていく必要があるのです。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 『The DevOps 逆転だ!』著者に聞く、「DevOps」や自動化よりも大切なこと
前回は国内DevOpsトレンドをけん引してきたベンダーキーパーソンによる座談会により「DevOpsとは何をすることか」を明確化した。今回はそこでの話も基に、『The DevOps 逆転だ!』の著者の一人、ジョージ・スパッフォード(George Spafford)氏に話を聞いた。 - 製造業がアジャイル開発を実践するには? デンソー デジタルイノベーション室長に聞く「イノベーションの前提条件」
ITでビジネスに寄与する「攻めのIT」という言葉が叫ばれるようになって久しい。だが多くの企業において、成果に結び付かない単なる掛け声に終始してきた傾向が強い。では、この言葉の真意とは何か――デンソーで「攻めのIT」を実践、リードしているデジタルイノベーション室長 成迫剛志氏に、今、企業とエンジニアが持つべきスタンスを聞いた。 - エンジニア視点で説明する「メルカリ」、リリースから4年の道のり
2017年6月、執行役員 Chief Business Officer(CBO)に、元Facebookのバイスプレジデント ジョン・ラーゲリン氏を迎えるなど、国内はもちろんグローバル展開も加速させているメルカリ。世界に支持される同社サービスはどのように作られ、支えられているのか?――2017年9月に開催された技術カンファレンス「Mercari Tech Conf 2017」にサービス開発・運用の舞台裏を探った。 - 米Google SREディレクターに聞く、運用管理の意義、価値、役割
デジタルビジネスの競争が激化し、システム開発・運用の在り方がビジネスの成果に直結する状況となっている。こうした中で、運用管理者の役割も「担当システムの安定運用」から大きく変わりつつある。今回は、Googleの巨大なサービス群とインフラを支えているSRE――Site Reliability Engineer(サイト信頼性エンジニア)に、今、運用管理者が持つべき視点、マインドを探ってみた。