書籍転載:エンタープライズアジャイルの可能性と実現への提言(3)
企業でのアジャイル開発の戦略 ― その狙い、注意点、投資効果
――第2章、2.2 エンタープライズアジャイルの関心事――
企業や事業部がどんな狙いでアジャイル開発を使うのか? 注意すべき点は何か? 投資効果をどう考えるか? というエンタープライズアジャイル開発の戦略について考える。
書籍転載について
本コーナーは、インプレスR&D[Next Publishing]発行の書籍『エンタープライズアジャイルの可能性と実現への提言』の中から、特にBuild Insiderの読者に有用だと考えられる項目を編集部が選び、同社の許可を得て転載したものです。
『エンタープライズアジャイルの可能性と実現への提言』(Kindle電子書籍もしくはオンデマンドペーパーバック)の詳細や購入はAmazon.co.jpのページをご覧ください。書籍全体の目次は連載INDEXページに掲載しています。
ご注意
本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどはBuild Insiderのそれとは一致しません。あらかじめご了承ください。
■
2014年度下期を中心にした当勉強会の実行委員の講演には、前節に記した「よく見られるアンチパターンと落とし穴」を避けるためのヒントになるような内容が多く含まれていた。本節では、これらの講演を以下のような観点で整理して概説する。
戦略
- 企業や事業部がどんな狙いでアジャイル開発を使うのか?
- 企業や事業部でアジャイル開発を適用する場合に注意すべき点は何か?
- アジャイル開発の投資効果をどのように考えるべきか?
戦術
- プロダクトやシステムの構想をどう発想するのか?
- プロダクトやシステムの構想を要求にどう落とし込むか?
- チームレベルを越えたアジャイルの実践方法にはどのようなものがあるか?
- ガバナンスに対する既存の考え方を変えるべきか?
普及/育成
- 導入/転換はトップダウンで行うべきか?ボトムアップで行うべきか?
日本固有の問題
- ユーザー企業とSI会社に分かれた産業構造でチームレベルを越えたアジャイルは実践可能か?
2.2.1. 戦略
2.2.1.1. 企業や事業部がどんな狙いでアジャイル開発を使うのか?
この質問に対する回答は、まず「競合他社との差別化を行うために、ソフトウェアの比重に依存する業務、サービス、プロダクトを提供するため」ということになる。さらに、「このような業務、サービス、プロダクトを実現するため時間的制約が厳しい」といえる。
これらの回答を整理すると、以下の点がポイントになる。
- A競合他社との差別化を実現するための戦略を考える
- B戦略の実現手段としてソフトウェア(システム、サービス)の比重が高い
- C戦略を実現するためのソフトウェア(システム、サービス)が稼働するまでの時間的制約が厳しい
エンタープライズアジャイル勉強会(以下、当勉強会)実行委員の依田氏は、企業のアジリティーの実現において、A、Bを考慮した問題解決の領域を3つ設定することを提案している。また、戦略を考える上でマイケル・ポーターが提案した5つの条件*7中の価値提案の以外の4条件に対してシステム開発手法やアジャイル開発などが密接に関連すると述べている。さらに、価値提案を考えるための3つの質問を紹介している。
- *7 依田智夫,エンタープライズ・アジャイル開発が果たすべき役割,https://easg.smartcore.jp/C23/file_details/V2o0RE53PT0=
- *1 ケント・ベック,XPエクストリーム・プログラミング入門―変化を受け入れる,ピアソンエデュケーション,2005
蛇足かもしれないが、マイケル・ポーターが提案した優れた戦略の5つの条件を考えるためのツールとして、ビジネスモデルキャンバス*9などのツールが有効だろう。また、後述するチームレベルからアジャイル開発をスケールするためのフレームワークであるSAFe (Scaled Agile Framework) *10において競争戦略を実現するのに必要なプロダクト、システム、サービスの方向性が「戦略テーマ」として表現されている。
- *9 アレックス・オスターワルダー,イヴ・ピニュール,ビジネスモデル・ジェネレーション ビジネスモデル設計書,翔泳社,2012
- *10 SAFe(Scaled Agile Framework)日本語webサイト:http://jp3.scaledagileframework.com/
- *7 依田智夫,エンタープライズ・アジャイル開発が果たすべき役割,https://easg.smartcore.jp/C23/file_details/V2o0RE53PT0=
言うまでもないことかもしれないが、このように戦略を綿密に考えても、その戦略が期待どおりの成果を上げるかどうかは保証されていない。そのような場合には、戦略の妥当性を裏付けるようなフィードバックをできる早く得ることが大事になる。この点において、システムやプロダクトの基本部分を早くリリースすることで戦略の妥当性を早く確認できるアジャイル開発や反復開発が有効になるのである。
2.2.1.2. どんなシステムの開発にアジャイル開発を適用すべきか?
回答:企業の差別化につながるシステムの開発にアジャイル開発を適用すべき。
当勉強会実行委員の中山氏は、「企業の独自性が強い業務はパッケージでは難しく、”手組み”が必要」と述べ、その部分の業務システムの開発に反復開発やアジャイル開発が適していると述べている。
中山氏の意見と類似した考え方は、文献*12にも目的合わせモデル(Purpose Alignment Model)として記載されている。
- *12 Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald, Stand Back and Deliver: Accelerating Business Transformation, Addison-Wesley, 2009
この文献では、システムを開発する際に「開発対象のシステムがあるために顧客は自分達の会社の製品やサービスを購入してくれるのか?」「開発対象のシステムは基幹系か?」と問いかけて、それらの両者の答えが両方とも「はい」であるものに対してアジャイル開発のような開発を適用すべきだと記している。
- *11 中山嘉之,EA(エンタープライズアジャイル)にはEA(エンタープライズアーキテクチャー)が必要,https://easg.smartcore.jp/C23/file_details/VWpFSU53PT0=
また、取り扱っているものが低価格で価格競争にさらされているような業種であってもITによる付加価値の提供が可能であることが文献*13に示されている。この文献では、ファーストフードチェーンに紙カップ等の消耗品を販売するビジネスにおいて発注元のさまざまな発注書の形式に対応したり、発注実績に関するレポートを提供するなどのシステムで実現することで競争に勝った著者の経験が記されている。また、そのようなシステムを軽量に短期間で開発することの重要性も強調されている。
- *13 Michael H. Hugos, Business Agility: Sustainable Prosperity in a Relentlessly Competitive World, Wiley, 2009
2.2.1.3. 企業や事業部でアジャイル開発を適用する場合に注意すべき点は何か?
この質問に対する回答には、組織全体で注意すべき点とプロジェクト単位で注意すべき点がある。プロジェクト単位で注意すべき点の多くは先の「2.2.よく見られるアンチパターンと落とし穴、その対策」のところで説明したので、ここでは1点を挙げるに留める。
- 組織全体で注意すべき点<br>・ビジネスアーキテクチャーとシステムアーキテクチャーの設計が重要である
- プロジェクト単位で注意すべき点<br>・もっとも注意すべきなのは、前の節で記した「明確な狙いとアジャイル開発を適用する必然性があるか」ということである
ビジネスアーキテクチャーとシステムアーキテクチャーについては、当勉強会実行委員の中山氏、山岸氏、鈴木氏が各々以下の観点の重要性を強調している。
- 中山氏:エンタープライズアーキテクチャー
- 山岸氏:継続的リフォーム
- 鈴木氏:マイクロサービスアーキテクチャー
中山氏のエンタープライズアーキテクチャーの講演では、まずアジャイル開発への懸念として全社的アーキテクチャーが不在になる危険性の指摘があった。つまり、ITアーキテクチャー設計は本来的に「企業のケイパビリティ向上のため、その企業に見合ったシステム構造(アーキテクチャ)の将来像を描き、それに向けた移行計画を立案すること」という役割であるにも関わらず、実装中心にアジャイル開発を進めるとITアーキテクチャー設計が担うべきことが行われなくなるという危険性である。
中山氏が提起した懸念を解消するためには、アジャイル開発を適用する場合にも、ビジネスアーキテクチャーとシステムアーキテクチャーを表現するためのモデルを描き、そのモデルで将来像や移行計画を考えていくことが必要になる。
- *14 山岸耕二,エンタープライズシステムの継続的リフォームにおけるアジャイル開発,https://easg.smartcore.jp/C23/file_details/QkdCV1lBPT0=
山岸氏の提唱する継続的リフォームとは、毎回の業務の変化に対してエンタープライズシステムを一から再開発するのではなく、リフォームのように変化が必要な部分を少しずつ発展させるということである。そのためには、「エンタープライズシステムをサービス指向化しなければならない」と述べている。さらに、そのようなITアーキテクチャーを前提として、以下のような取り組みを行うことで継続的リフォームが実現できると述べている。
- モデリングを活用して業務側のニーズからシステム要求を要求開発する
- チームレベルのアジャイル開発により効率的に開発を行う
一方で、当勉強会実行委員の鈴木氏はこのようなアーキテクチャーとして実際に用いられているものは、トップダウンなサービス指向アーキテクチャー(SOA)ではなく、ボトムアップ的なマイクロサービスアーキテクチャー(MSA)ではないかと述べている。さらに、MSAを構成する機能の性質(フロントエンド、バックエンド)に応じて、アジャイル開発と従来開発手法の使い分けを行うべきではないかと述べている。
- *15 鈴木雄介,エンタープライズアジャイルと全体最適について,https://easg.smartcore.jp/C23/file_details/VkRCV1pBPT0=
2.2.1.4. アジャイル開発の投資効果をどのように考えるべきか?
回答:複数年に渡る精緻な投資効果のモデルを考えるよりは、3カ月から6カ月の期間である程度の開発を行い、その成果が期待を裏付けるかを確認するべき。
つまり、3カ月から6カ月の期間で(少なくとも社内で)リリースをし、そのリリースされたものでさらなる投資に値するかを判断するのである。
アジャイル開発であれ、反復開発であれ、複数回のリリースを通じてプロダクトを発展させる形で開発を進めるが、それらのリリースで提供される機能のまとまりを「市場に出せる最低限のフィーチャー(MMF:Minimum Marketable Feature)」と呼ぶ。MMFという言葉は、反復開発やアジャイル開発の投資効果を論じた文献*16で一躍世に広まった。
- *16 Mark Denne, Jane Cleland-Huang, Software by Numbers: Low-Risk, High-Return Development , Prentice Hall, 2003
文献*16では、反復開発やアジャイル開発の投資効果を以下のような指標でモデル化している。
- 将来のお金の現在価値(PV: Present Value):<br>・PV=$x/(1+i/100)nエヌ<br>・$x:将来価値、i:利率、n:年数
- 割引きキャッシュフロー(DCF: Discounted Cash Flow)<br>・DCF=PVで補正した期間毎のキャッシュ持ち高
- 正味現在価値(NPV: Net Present Value)<br>・NPV=ΣDCF
- 内部収益率(IRR: Internal Rate of Return)<br>・プロジェクトのNPVが0になる利率
これらを計算し、ROIや最終的に得られるIRRの値で投資効果の比較を行う。例えば、表1、表2は従来手法で開発した場合のROI分析とNPV分析の例を示したものである。
この例では、ROIは47%、IRRは12.8%になる。
それに対して、表3、表4がMMFを期間4で早くリリースした場合のROI分析とNPV分析の結果である。この場合のROIは188%、IRRは36.3%になる。
もちろん、これらの数字を単純比較してMMFを早くリリースした方が常によいとはいえない。しかし、前述したようにアジャイル開発や反復開発を用いることで、従来手法で開発が完了する期間内に複数回のリリース(MMF)を提供することが可能になる。このように複数のMMFをリリースできることには以下の2点の潜在的なメリットがある。
- 投資に対する効果をより早く得ることができる
- MMFにより、開発したものの有用性や市場性をより早く確認できる。このことで有望なものに追加投資し、効果を大きくしたり、見込みがないものを早く止めて損失を抑制したりすることができる
このように複数のMMFで成果を確認しながら予算付けを行う方法をインクリメンタルな予算付け手法(IMF: Incremental Funding Methodology)と呼ぶ。文献*16では、ROIを最大にするためには複数のMMFの順序付けをどうしたらにできるかという方法について論じている。
なお、MMFで成果を確認しながら予算付けを行おうとすると、予算付けの判断の頻度が増える。このような、より頻繁な判断をスピーディーに行うためには、予算付けの判断を分散(委譲)することを考える必要がある。
また、このようなROI分析やNPV分析に基づくROIモデルを検討することには以下の2つの留意点がある。
- どのようなROIモデルでも、あくまで1つの仮説にすぎず、数年間に渡るような長期に渡るモデルを構築することの意味が本当にあるかについてよく考える必要がある
- 精緻なROIモデルを作れば作るほど、さまざまな隠れたパラメーターで操作が可能になるため、ROIモデル同士の比較が正当なものにならない可能性がある
これらの留意点を考えた結果、SAFe*10*17では比較的長期間に渡るROIを精緻に考えてプロダクトやシステムの企画を承認するのではなく、以下のような2つの方法でプロダクトやシステムの企画を承認し、その企画の妥当性を継続的に評価する方式が用いられている。
- *10 SAFe(Scaled Agile Framework)日本語webサイト:http://jp3.scaledagileframework.com/
- *17 Dean Leffigwell,アジャイルソフトウェア要求: チーム,プログラム,企業のためのリーンな要求プラクティス,翔泳社,2014
- プロダクトやシステムの企画を、事業の戦略的な方向性と、経済的な成果とプロダクトやシステムを開発するための期間の兼ね合いで評価し、見込みのあるプロダクトやシステムの企画を段階的に絞り込む
- 承認され、開発体制が割り当てられたプロダクトやシステムの企画に対して、8-12週毎に動作するプロダクトやシステムが作成し、それら動作するプロダクトやシステムの有効性を顧客、企画担当者、その他の利害関係者が評価する
後者の有効性は市場への投入(あるいは本番稼動)前は顧客、企画担当者、その他の利害関係者などが評価し、市場への投入(あるいは本番稼動)後は売り上げなどのビジネス成果で評価し、その評価結果により、そのプロダクトやシステムへの開発投資の増減を判断していく。
■
以上、「2.2 エンタープライズアジャイルの関心事」の「戦略」について説明しました。転載は今回をもって完結です。
1. スクラムによるアジャイル開発の進め方、従来手法とのギャップ
アジャイル開発を概説。また、その中の人気手法の一つである「スクラム」の基礎の基礎として、開発の進め方や従来手法との違いについて説明する。
2. アジャイル開発でよく見られるアンチパターンと落とし穴、その対策
日本企業での失敗事例から、企業でアジャイル開発に取り組む際の典型的なアンチパターンを紹介。その原因となる落とし穴と、本来のあるべき姿を明らかにする。