iot時代に向かい，進化し続けるアジャイル -...

Software Reliability Enhancement CenterCopyright © 2016 IPA, All Rights Reserved

Information-technology Promotion Agency, Japan

IoT時代に向かい，進化し続けるアジャイル

～来たるべき商品／サービス競争時代を勝ち抜くために～

独立行政法人情報処理推進機構(IPA)技術本部ソフトウェア高信頼化センター(SEC)

山下博之

ET/IoT 20162016年11月16日

http://www.ipa.go.jp/sec/index.html

2Copyright © 2016 IPA, All Rights Reserved Software Reliability Enhancement CenterET/IoT 2016 (2016-11-16)

本日の講演内容

1. ICTシステムの進展

2. IoT(Internet of Things)の時代では．．．

3. IoT時代に求められる，アジャイルな活動

4. 組込みシステム開発とアジャイル

5. まとめ







5. まとめ


ICTシステムの変遷と開発スタイル

インターネット

クラウド

(IoT/IoE)

PCモバイル

PC→携帯→スマホ/タブレット→？

センサー

ビジネスを支援するICT

ビジネスを実行するICT

1980年代 2020年代2000年代1960年代

品質価値スピード

ブラウザ

？

SoE

SoRウォーターフォール

(super AI)

アジャイル

SoE: Systems of Engagement

SoR: Systems of Record


1992年12月 IIJの企画会社設立

1993年 5月 (株)IIJに社名変更11月 IIJがISPサービス開始（国内初）

インターネット関連ビジネスの歴史

1993年旧郵政省により日本におけるインターネットの商用利用が許可1994年2月 Yahoo!誕生

1994年7月 amazon.com創業

1995年7月 amazon.comサービス開始 1996年4月 Yahoo! Japanサービス開始1996年12月25日 NTTの「OCN」の開始1997年9月15日 Google検索登場

1998年9月 Google法人化1999年2月22日「iモード」サービス開始

2002年3月29日東京電力「TEPCOひかり」を開始2004年2月4日 Facebook誕生2005年2月15日 YouTube設立 2006年3月31日ニフティのパソコン通信サービス終了2006年6月 Twitter設立 2006年12月12日「ニコニコ動画」サービス開始

2008年7月10日 Appleが「App Store」を開始

2011年6月「LINE」サービス開始

1994年12月 Netscape Navigator公開

1980年代末営利目的のインターネットサービス~1990年代プロバイダ (ISP) が出現

1989年世界初の商用ISP（PSINet）誕生

1997年5月『楽天市場』のサービス開始

2009年「Uber」が配車サービス開始

1984年 Cisco設立1985年 Qualcomm設立

インターネットの黎明期に新会社が設立，

新サービスが続々と登場

インターネットサービスが進化し続ける

<出典> JPNIC: インターネット歴史年表，等 https://www.nic.ad.jp/timeline/

2007年1月 iPhone発売2008年7月 iPhone発売

2014年11月ソラコム設立







5. まとめ


新たな情報革命：Cyber Physical System(CPS)

<出典>「情報経済小委員会中間とりまとめ報告書」，産業構造審議会商務流通情報分科会，平成27年5月21日をもとに加筆．

つながる機器の分野・台数は急増し，従来デジタル化されることなく散在していたデータが

大量にインターネットに流通

より広範囲にビ

ジネス機会の増大

セキュリティ等，

リスク要因も増大

より深く


ＩｏＴ時代のビジネス領域

<出典>

国内IoT市場グローバル主要事業者分析結果を発表2015年6月10日 IDC Japan株式会社プレスリリースhttp://www.idcjapan.co.jp/Press/Current/20150610Apr.html

をもとに作成

システム／デバイス

コネクティビティ

プラットフォーム

アナリティクス

アプリケーション

5つのレイヤ

導入産業分野の拡大

ビジネスの方向

導入目的／導入用途の拡大

導入機器／導入地域の拡大

自社のビジネスはどこか？どの領域を狙うか？

http://www.idcjapan.co.jp/Press/Current/20150610Apr.html


ビジネスのパラダイムシフト

日産自動車の関係者は、「人工知能（ＡＩ）を使うクルマになると、ディープラーニングの機能は車体に組み込むというより、走行中のデータをクラウドで処理し、その結果生まれる新しい機能、性能をクラウドからダウンロードするイメージだ」と話す。（中山淳史「そして、クルマはクラウドにつながる」，日本経済新聞，2016/6/7）

ソフトウエア・デファインド（Software-Defined）の時代です。アメリカのゼネラルエレクトリック社がすでに取り組んでいますが、世界中に設置されている自社製の機械の動きを24時間・365日、クラウドで監視していて、異常や故障の前兆が検知されたら予防保守をするか交換する。ユーザーは実質的に「故障しない製品」を買ったことになるのです。（つくだひとし「【講演採録】派生開発推進協議会代表・清水吉男氏 XDDPから「IoT」に挑む」，IT記者会レポート，2016.6.14）

自動車産業における「もの」から「サービス」への流れ．クルマは，所有するものから，移動手段へ．（各種ソース）


ビジネスに関わるIoT時代の特徴

IoT（Internet of Things）時代

モノ，ヒトとネットワークとソフトウェアを組み合わせた強みを活用し，さらにAIやビッグデータ分析等の技術を組み合わせた

商品／サービス競争の時代

インターネット上で時々刻々と新デバイスが接続，新サービスが提供

→現状や未来の全体像を見通すことはできない

顧客のニーズもそれらに誘発されて移ろいゆき，それがきっかけとなってさらにデバイスやサービスが更新

→相互に深く影響し合いながら進展する

ある日突然，新たなセキュリティ上の脅威が発生

→対応の機敏さが死命を制する

取り巻く環境の変化が激しい時代







5. まとめ


企業活動のアジリティ（機敏性）

IoT時代における環境の変化に機敏に応じることが可能な

商品／サービスを市場に投入し続ける

→企業活動そのもののアジリティ

→今や企業活動の根幹を担うICTシステムについては

迅速でかつ確実な開発・更新

アジャイル開発手法

エンタープライズ・アジャイル


A financial model of software product development.

<出典> Ram Chillarege: The Marriage of Business Dynamics and Software Engineering,

IEEE SOFTWARE, November/December 2002.

ソフトウェア製品のライフサイクル・モデル例と開発手法

アジャイルウォーターフォール

参考

ビジネス・ステージと開発手法

ビジネスの黎明期には，競争優位を確保して生き残るために，頻繁に新商品/サービスを投入


<出典>

ガートナー、「バイモーダル」なIT組織に関する調査結果を発表2016年6月1日ガートナージャパン株式会社プレスリリースhttps://www.gartner.co.jp/press/html/pr20160601-01.html

をもとに作成

デジタル・テクノロジを使用したプロジェクトの予定／実績がある企業のうち、

約3割は従来のIT部門とは別に専門組織を立ち上げて

いる

参考データ

日本の現状（１）

従来のIT部門内

専門チーム40.6%

従来のIT組織と

は別の新組織29.4%

プロジェクト・チーム

(ビジネス部門との

タスクフォース)28.1%

その他1.9%

◆デジタル・テクノロジの実装プロジェクトを

担当する組織

調査対象309人のうち，プロジェクトの予定/実績がある160人の回答者の内訳

https://www.gartner.co.jp/press/html/pr20160601-01.html


<出典>

ガートナー、日本におけるモノのインターネットに関する調査結果を発表2016年4月26日ガートナージャパン株式会社プレスリリースhttps://www.gartner.co.jp/press/html/pr20160426-01.html をもとに作成

国内企業のIoTへの取組み姿勢は慎重

参考データ

日本の現状（２）

8.5 10.1

16.7 15.7

0

5

10

15

20

25

30

2015年 2016年

(%)

loTの推進体制を確立させている企業の

割合の変化現在準備中(1年以

内に実施)

IOTの専門部署や

グループができた

0 10 20 30 40 50 60 70

いまだにどこから手を付けるべきか分からない

市場での競争を優位にする

IT部門の新しい価値を発揮できる

ITがよりビジネスに貢献できる

社内の変革を推進する

■そう思う

(％)

loTに対する期待や不安

https://www.gartner.co.jp/press/html/pr20160426-01.html


グローバル

2014年

2015年

34%

32%

2014年

2015年

31%

57%

日本

デジタル投資のlloTに期待する効果のうち，収益へのインパクトを期待している経営者の比率

注：2014年の調査では「デジタル投資」に期待する効果について，2015年の調査では「lloT」に期待する効果について質問

日本の現状（３）参考データ

<出典>

Industrial Internet of Things を価値創造につなげるグローバルCEO調査 2015，アクセンチュアをもとに作成．

デジタル投資により期待する効果として収益へのインパクトを挙げていた割合は，グローバルの経営者では大幅に増加している

が，日本はほぼ変わらず．


グローバル日本

68%

16%

グローバル日本

62%

16%

日本の現状（４）参考データ

<出典>


グローバル企業の経営者は，市場における創造的破壊がさらに進むと考えている．日本の経営者で，競合企業が市場のルールを一変させる

という懸念を持つ者は少ない．

競合企業が市場を一変させるような製品・サービスを打ち出す可能性があると考えている経営者の比率

競合企業がビジネスモデルを大きく変化させる可能性があると考えている経営者の比較


グローバル

68% 32%

43% 57%

lloTがオペレーション効率化/生産性向上に貢献すると回答

lloTが新たな収益源の創出に貢献すると回答

日本

日本の現状（５）参考データ

<出典>


IIoTがビジネスにプラスのインパクトをもたらす可能性として、グローバル企業の半数以上が新たな収益源の創出を挙げる．

日本企業は効率化への注目度が高い．


組織の機敏性とは？ What Defines Organizational Agility?

<出典> PMI Pulse of the Profession In-Depth Report: Organizational Agility, 2012

素早い応答短サイクル変更管理顧客の声を聞くリスク管理

多様なチームサイロ化防止非常事対策反復プロセス技術の活用

参考


組織の機敏性が大きいほど，パフォーマンスはよくなる

Success with new initiatives over the past 2-3 years

Those organizations that are successful report higher levels of

organizational agility—giving them a powerful edge on the competition.


Greater organizational agility leads

to better performance—providing

organizations with a powerful edge

on the competition.

成功率が増大している組織ほど，高い機敏性を有する

参考


組織の機敏性の度合いとプロジェクト成功率


Project Success Metrics by Level of Agility

機敏性の大きな組織競争力強化

高いパフォーマンス

納期内予算内ビジネス目標達成

高い投資効果

参考







5. まとめ


組込み機器・システムとアジャイル開発

組込み機器・システムの開発に対しても，

アジャイル開発手法の適用が必要となってきている


アジャイル開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められている領域：

①大規模開発

・開発者10人程度を超えると、システム分割、チーム分割が必要。その分割方法、及び、分割されたチーム間のコミュニケーションが課題。

②分散拠点（オフショア含む）開発

・開発拠点が分散し、さらに時差によって分断される場合のコミュニケーション手法、また、それをサポートするツールが必要。

③組織（会社）間をまたぐ開発チームによる開発

・共通のビジネスゴールを持ったチームを組むことが難しい。

④組込みシステム開発

・リリース後のソフトウェア修正が極めて困難であり、採用には工夫要。

アジャイル開発の試行領域（当時）

<出典> 非ウォーターフォール型開発WG活動報告書IPA/SEC，平成23年3月31日．


組込み製品開発の特徴

顧客（エンドユーザ）が見えない

経験と想像に基づく要求設定

未来予測の要求への反映

多くの関係者（関連部署）との協力による開発推進

市場からのフィードバックを迅速に行う仕組み

短いサイクルで機能を積み上げ，評価しつつ，製品の価値を高めていく

そもそも開発開始前の

真の要求の確定は不可能


日米における今日のデバイスの比較

＜出典＞クリストファー・テイト「イノベーションを生み出す日本へ、再び

～ソフトウェアとハードウェアの対話が、日本に強さもたらす～」ET-West 2013 ヒートアップセッションHU-5講演，2013年6月14日，大阪．

ハードウェアソフトウェア

ハードウェア

ソフトウェア

インターネットを介した改善

日本米国（シリコンバレー）


IoT時代の組込み機器・システムとアジャイル開発

利用者の購入後にインターネットを介して定期的に機能拡張*

アジャイル開発

クラウド等

* エンドユーザからのフィードバック対応を含む

真の要求

ハードウェア

ソフトウェア

インターネットを介した改善

PLD

エンドユーザ側データ（状態，使用感，等）の収集の仕組み

更新の仕組み

PLD: Programmable Logic Device

フラッシュメモリ等


組込み系とエンタプライズ系の技術者間の協働

機器・システムだけを見ていては不十分（イノベーションに結びつきにくい）

・機能拡張の仕組み（サーバ／バックヤード／クラウド側）の理解

・機能拡張項目選定のトリガ（利用者の声を捉える仕組み）の理解

組込み系とエンタプライズ系の協働／両スキルの獲得

エンドユーザ側データ（状態，使用感，等）

の収集の仕組みと運用

技術者に求められる行動







5. まとめ


★『価値』で決まる

ＩＴプロジェクトの成功は，

もはやQCDではなく，

（顧客側の）価値や満足で決まる

＜アジャイル開発の特徴＞

(顧客)“価値”駆動型

IoTの時代では価値を高め得る要素

が増大


参考データ

ＩＴプロジェクト成功の定義（あるアンケートの例）

<出典> CHAOS MANIFESTO 2014

Triple constraints 15%

On budget 32%

On time 30%

On Target (scope) 26%

On goal 29%

Valuable 52%

Satisfied 41%

All of the above 33%

3 要素(予算，納期，機能充足)

予算

納期

機能充足（スコープ）

目標(*1)

価値

満足

上記6要素の全て

(*1) 組織の戦略目標にどれだけ合致しているか?

6要素のうち，4つまで選択可．(回答数=309)

15%

32%

26%

29%

52%

41%

33%

30%

Ｃ

Ｄ

Ｑ


進化し続けるアジャイル

アジャイル開発手法

適用範囲がますます拡大

手法自身も進化し続けている（モデルやハードウェアをも対象，等）

IoT時代に向かって，つながる機器の分野・台数は急増し，デジタルデータが大量にインターネットに流通

ビジネス機会の増大

企業活動に求められるアジリティ（機敏性）

その中で，ICTシステム開発については，

インターネットの黎明期を思い起こす

主に経営層

主に技術者


アジャイル開発に関するIPA/SECの調査・検討結果等は：http://www.ipa.go.jp/sec/softwareengineering/std/ent02-c.html

ご清聴，ありがとうございました


付録


ふり返り：アジャイル開発に関するIPA/SECの取組み

H21(2009)年度 H22(2010)年度 H23(2011)年度 H24(2012)年度

非ウォーターフォール型開発研究会

非ウォーターフォール型開発WG



非ウォーターフォール型開発に関する調査

実証/模擬実験（契約形態）

大規模開発普及要因

プラクティスリファレンスガイド

▲報告書

▲報告書

▲報告書

報告書（公開中）H21年度版 http://www.ipa.go.jp/sec/softwareengineering/reports/20100330a.html

H22年度版 http://www.ipa.go.jp/sec/softwareengineering/reports/20110407.html

H23年度版 http://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html

(大規模開発) http://www.ipa.go.jp/about/press/20120328.html

(普及要因) http://www.ipa.go.jp/sec/softwareengineering/reports/20120611.html

(プラクティス) http://www.ipa.go.jp/about/press/20130319.html

事例収集(1)

課題抽出

課題検討

検証・改善

事例収集(2)

提案

▲報告書

▲報告書

▲報告書

▲報告書

事例収集(3)

http://www.ipa.go.jp/sec/reports/20100330a.html

http://www.ipa.go.jp/sec/reports/20110407.html

http://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html

http://www.ipa.go.jp/about/press/20120328.html

http://www.ipa.go.jp/sec/reports/20120611.html



アジャイル開発プラクティス活用リファレンスガイド



※プラクティス：アジャイル開発を実践する活動項目




ガイドの特徴

•55個*のプラクティス，26個の事例，9つの活用ポイント計224ページ

•日本国内の開発現場からのヒアリングにより収集した知見を，パターン記述形式で取りまとめ

•MS-Wordファイルを公開し，クリエイティブ・コモンズ・ライセンスの下に，改変自由・営利目的利用可で使用許諾

* 類似のものを統合し，最終的には45個

アジャイル開発を実践する活動項目

../../../IPAwork/広報/セミナー/20130805MPUF/AgilePracticesReferenceGuide2013.doc


0%

20%

40%

60%

80%

100%

日次ミーティング

ふりかえり

イテレーション計画ミーティング

イテレーション

紙・手書きツール

持続可能なペース

チーム全体が一つに

バーンダウンチャート

タスクボード(タ

スクカード)

ユニットテストの自動化

インテグレーション専用マシン

集団によるオーナーシップ

自己組織化チーム

継続的インテグレーション

組織にあわせたアジャイルスタ…

スプリントバックログ

リリース計画ミーティング

ファシリテータ（スクラムマス…

迅速なフィードバック

コーディング規約

ユーザーストーリー

プロダクトバックログ(優

先順…

ベロシティ計測

リファクタリング

共通の部屋

プロダクトオーナー

スプリントレビュー

自動化された回帰テスト

プランニングポーカー

シンプルデザイン

柔軟なプロセス

テスト駆動開発

オンサイト顧客

人材のローテーション

ペアプログラミング

スパイク・ソリューション

アジャイルコーチ

受入テスト

顧客プロキシ

バグ時の再現テスト

逐次の統合

インセプションデッキ

ニコニコカレンダー

かんばん

システムメタファ

プラクティス適用率 (n=26)

適用プラクティス (全体)

※:適用数は、適用を1件、部分的に適用を0.5件として集計した。※ システムメタファは国内の26事例の中で活用されている事例はなかった。『ガイド編プラクティス解説』では、海外の事例を調査した。

日次ミーティング、ふりかえり、イテレーション計画ミーティング、イテレーションの順に適用率が高く、これらはアジャイル開発を行う上でのほぼ必須のプラクティスであると言える。これらのプラクティスはScrumとXPに共通するプラクティスである。


プラクティス例概要 – 日次ミーティング

状況

チームは、プロジェクトのタスクをこなすためにほとんどの時間を使い、状況や情報の共有のために取れる時間がほとんどない。

問題

情報の共有遅れが問題を大きくする。情報共有の時間が取れないまま、状況認識と問題対処への判断が遅れると、問題が大きくなるなど、より深刻な状況を招いてしまう。

フォース

関係者が多忙なため、情報共有のための時間が取れない。情報共有の間隔が空いてしまうと、情報量が増え、共有に必要な時間が余分にかかる。

解決策

必要な情報を短い時間で毎日共有する。関係者が長時間、時間を取れないようであれば、短い時間(15分を目安に)で済むように、共有を必要な情報に絞る。

利用例

事例(9): 遠隔地にいるメンバーも日次ミーティングに参加するため、チャットツールや電話会議システムを利用した。

事例(17): 1日3回(朝、昼、夕)10分程度のミーティングを実施。問題を報告/解決するためのリズムが開発メンバー全員に浸透して、短期での問題提起ができている。

留意点

必ずしも朝の時間帯にこだわらず、関係者が集まりやすい時間帯に開催する（例えば、終業近い時間帯に開催する夕会）。

リファレンスガイド


プラクティス例概要 – ふりかえり

状況

イテレーション毎に、チームは動くソフトウェアとして成果を出そうとしている。イテレーションを繰り返して、チームはソフトウェアを開発していく。

問題

開発チームは、そこに集まったメンバーにとって最適な開発プロセスを、最初から実践することはできない。

フォース

イテレーションでの開発はうまくいくこともあるが、うまくいかないこともある

解決策

反復内で実施したことを、反復の最後にチームでふりかえり、開発プロセス、コミュニケーション、その他様々な活動をよりよくする改善案をチームで考え実施する機会を設ける。

利用例

事例(25): 当初はKPT[※1]を用いてふりかえりを行っていたが、ファシリテータの技量にふりかえりの質が依存してしまう、声の大きいメンバーに影響を受けてしまうことに気づいた。そのため、意見を集めるやり方として、555(Triple Nickels)[※2]を用いることにした。

ふりかえりにチームが慣れていない場合は、進行で各人の意見をうまく引出すようにしないとうまくいかない。

問題点を糾弾する場にしてしまうと、改善すべき点を積極的に話し合えなくなってしまう。

改善案を出しても、実際に実行可能なレベルの具体的なアクションになっていないと実施されない。

※2 アクションや提案に対するアイデアを出すための手法。5人程度のグループで、各人が5分間ブレインストーミングをしてアイデアを書き出す。5分経過したら紙を隣の人にまわし、新しいアイデアを書き加える。

留意点

※1 メンバー全員で、Keep(よかったこと・続けたいこと)、Problem(問題・困っていること)、Try(改善したいこと・チャレンジしたいこと) を出し合い、チームの改善を促す手法。



プラクティス例概要 – イテレーション計画ミーティング

状況

開発を一定期間のサイクル(イテレーション)で繰り返し行っている。プロダクトバックログの内容を、チームとプロダクトオーナーの間で合意している。

問題

リリース計画は遠い未来の目標のため、それだけではイテレーションで何をどのように開発すれば良いか分からない。

フォース

ユーザーストーリーのまま、イテレーションの詳細な計画を立て、開発を進めていくのは難しい。

解決策

イテレーションで開発するユーザーストーリーと、その完了までに必要なタスクおよびタスクの見積りを洗い出すミーティングを開く。

利用例

留意点

見積りに関してチームが水増しする懸念を持つかもしれないが、チームを信じるべきである。プロジェクトの目的を理解したチームは、見積りが大きく外れるようであれば、自らその原因を分析し、次の見積りに活かすはずである。

G社事例(9): ペーパープロトタイピング[※1]を用いたUIデザインの共有と受入れ条件の確認をイテレーション計画ミーティングで行っていた。そのため、計画にはかなり時間を要していたが、見積りの前提が具体的になったため、見積り作業時間の削減に繋がった。

※1 紙などを使った試作品でユーザビリティテストを行うこと。



事例概要 <<中大規模適用プロジェクトの事例>> 事例(4) C社

プロフィール

既存のサービスのリプレイス開発。単純なサービスのリプレイスではなく、新しい要件も加えながら開発したいとの要望があり、C社から顧客にアジャイル開発を提案して開始した。リプレイスといいながらも、顧客から要件を聞き出しながら開発を進めていった。要件が固められない部分のみアジャイル開発を行い、要件が明らかな部分についてはウォーターフォール型開発を実施した。

特徴的なプラクティス

日次ミーティング: 複数のチームが存在したため、二段階の構成で実施していた。(チーム間→チーム毎)。

ふりかえり: チーム毎に実施した場合には、他のチームへの不満などばかりになってしまい機能しなかった。そのために、複数チームの混成で実施することにより、問題へ集中するように意識を変えさせた。また、反復毎のふりかえりとは別に、四半期単位でも実施して大きな改善点について話しあった。

顧客プロキシ: 当初は顧客に要件管理をしてもらっていたが、機能しなくなったため、C社の社員が顧客の会社へ出向して顧客プロキシとなり全面的に支援した。

システム種別 B2Cサービス

規模

中規模開発者 32名インフラ 4名管理その他 23名計 59名

手法 XP

契約準委任契約 (四半期毎に更新)

期間 2年

開発拠点東京、地方を含めた3拠点



活用のポイント (1)

(1) 短納期、開発期間が短い

開発対象のボリュームに比して、開発期間が短い場合、チームの開発速度を計測し、そのスピード感で、予定している開発量が期限内に完了するのか、常に点検する必要があるため、「ベロシティ計測」と、「バーンダウンチャート」を活用する。ベロシティ計測は、関係者であるプロダクトオーナーが理解できる基準で計測する必要がある(H社事例（11))。バーンダウンチャートは、関係者と定期的に共有する機会を設けることが活用のポイントである(B社事例(2)、J社事例(17)(18))。

(2) スコープの変動が激しい

開発中に要求の変更が頻繁に発生することが予想されるプロジェクトでは、チームが扱う要求の全体像と状態、直近のイテレーションで何を開発するかが分かっており、柔軟に優先順位を変えられる必要があるため、「プロダクトバックログ（優先順位付け）」、「スプリントバックログ」および「プロダクトオーナー」を活用する。プロダクトバックログ（優先順位付け）は、イテレーション毎に整理を行い、チーム全員で優先順位と内容を合意すると良い(B社事例(2))。プロダクトオーナーは、業務や全社的に全体最適となる判断を行うこと(G社事例(10))。

(3) 求められる品質が高い

品質要求が高いプロジェクトでは、テストに関するプラクティスである「自動化された回帰テスト」、「ユニットテストの自動化」を活用する。自動化された回帰テストやユニットテストの自動化は、プロジェクトの初期段階で、実施有無、実施のための取決め、使用ツールを検討しておくことがポイントである。これを後回しにすると、必ず機能開発が優先され、自動化にたどりつかない(B社事例(2))。




(4) コスト要求が厳しい

必要のないものを作るムダをなくし、必要なものをより素早く提供することがROI（費用対効果）の向上につながり、コスト要求に応えることができる。そのためには、的確に顧客の要求を把握し、認識の相違をなくす必要があるため、「プロダクトバックログ（優先順位付け）」を活用する。また、開発機能がプロダクトオーナーの意図通りになっているか否かの検証のために、「受入テスト」を活用する。「オンサイト顧客」には、優先順位や仕様の確認がその場で確認することができ、迅速に方針を決められるというメリットがある(K社事例(20))。

(5) チームメンバーのスキルが未成熟

スキル的に未成熟なメンバーが成長していく機会として、プロジェクトを計画する必要があるため、「ペアプログラミング」と「ふりかえり」を活用する。ペアプログラミングは、ベテランとメンバーが一緒に仕事をすることで、技術的な指導を行うのに適したプラクティスである(C社事例(4))。ふりかえりは、メンバーの成長の機会として捉えることができる。ふりかえりのやり方自体も見直しながらチームに適したやり方を模索すると良い(E社事例(6))。

(6) チームにとって初めての技術領域や業務知識を扱う

プロダクトの背景にある業界の知識や、要求の理解と実装に必要な業務知識の獲得が必要となるため、「スパイク・ソリューション」と「システムメタファ」を活用する。スパイク・ソリューションを適用することは、リスクとなりそうな技術課題について、プロジェクトの初期段階で実験的に小さく試しておくことであり、チームとプロジェクトを後々助けることに繋がる(C社事例(4))。システムメタファは、開発者にとって、なじみの薄い業務知識を理解する手段として、有効と考えられる。




(7) 初めてチームを組むメンバーが多い

初めてチームを組むメンバーが多い場合、チームが向かう方向を明確にすることと、チームビルディングが必要となるため、「インセプションデッキ」や「ニコニコカレンダー」を活用する。インセプションデッキは、作成を通じて、プロジェクトの目的や目標が明らかとなる(B社事例(1))。ニコニコカレンダーは、メンバーの感情や状況を可視化し、チームメンバーのことを知ることがポイントになる(E社事例(6))。

(8) オフショアなど分散開発を行う

プロダクトオーナーと開発チームが別の拠点にいる場合、オンラインでのコミュニケーション手段を検討し、頻繁にコミュニケーションが取れるようにする必要があるため、「日次ミーティング」や「顧客プロキシ」を活用する。TV会議システムを使った日次ミーティングは、離れた者同士が毎日顔を合わせる機会として、ぜひ活用するべきである(G社事例(9))。顧客プロキシは、分散した環境下でも、迅速なフィードバックが得られる工夫をしなければならない。

(9) 初めてアジャイル開発に取り組む

初めてアジャイル開発に取り組む際には、書籍や文書だけではなく人から人にやり方を伝えることが有効であるため、社内にアジャイル開発に取り組んだ経験のある人がいる場合はその人に、社内にない場合は、社外からアジャイルコーチを頼んで導入の手伝いをしてもらうのがよい。初めて取り組む場合は、イテレーション期間を短くした上で、ふりかえりの中で改善点をチームで考え実行していくことが不可欠となる。



アジャイル開発プラクティス活用リファレンスガイド事例一覧 (1)

調査先 No. 採用手法[※1] 特徴システム種別契約関係[※2] 開発言語

A社0 Scrum+XP B2Cサービス (広告配信) 自社開発 Java, PHP, Perl

1 Scrum+XP B2Cサービス (広告配信) 自社開発 Ruby

B社2 Scrum+XP B2Cサービス (SNS) 自社開発 Java

3 Scrum+XP B2Cサービス (メール配信) 自社開発 Java

C社 4 XP+WF 中規模 B2Cサービス (メール配信) 受託開発 (準委任) Java

D社 5 XP B2Cサービス (SNS) 自社開発 Java, PHP, Ruby

E社6 Scrum 初導入社内システム自社開発 C#

7 Scrum+WF 中規模社内システム受託開発 (請負) Java, COBOL

F社 8 Scrum+WF 中規模社内システム自社開発 C#

G社9 Scrum+XP 初導入社内システム実証事業 Ruby

10 Scrum+XP 社内システム受託開発 (請負) Ruby

H社

11 Scrum B2Cサービス (音楽配信)自社開発 + オフショア(準委任)

Java, C#, Objective-C

12 Scrum B2Cサービス (エンターテイメント)自社開発 + オフショア(準委任)

Java, C#, Objective-C

13 Scrum 社内システム自社開発 + オフショア(準委任)

Java

14 Scrum B2Cサービス (ヘルスケア)自社開発 + オフショア(準委任)

C#


アジャイル開発プラクティス活用リファレンスガイド事例一覧 (2)

※2:自社開発 → 自社組織内に開発部隊あり、一部パートナー(派遣)受託開発 → 自社組織内に開発部隊なし、外部ベンダに発注している

※1:XP:エクストリームプログラミング、Scrum:スクラム、WF:ウォーターフォール、UP:統一プロセス、もしくは、これらの手法の組み合わせ

中大規模(30名以上):6件初導入:2件

調査先 No. 採用手法[※1] 特徴システム種別契約関係[※2] 開発言語

I社 15 Scrum中規模(組織展開)

B2Cサービス (広告配信) 自社開発 Java, Objective-C

J社

16 XP B2Cサービス (スマートフォンアプリ) 受託開発 (請負) Java

17 XP B2Cサービス (クラウド基盤) 受託開発 (請負) Java

18 XP B2Cサービス (クラウド基盤) 受託開発 (請負) Java

19 XP B2Cサービス (PaaS) 受託開発 (請負) Java

K社 20 Scrum B2Cサービス (ECサイト) 受託開発 (請負) PHP

L社

21 Scrum+UP 社内システム受託開発 (請負) Java

22 Scrum+WF 大規模社内システム受託開発 (準委任)

Java

23 Scrum+WF 技術評価受託開発 (請負) Java

24 Scrum パッケージ自社開発 + オフショア (請負)

C#

M社 25 Scrum大規模(組織展開)

B2Cサービス (ソーシャルゲーム) 自社開発 Perl

全26事例


アジャイル開発プラクティス活用リファレンスガイドプラクティス一覧 (1)

カテゴリサブカテゴリプラクティス説明

プロセス・プロダクト

プロセス

リリース計画ミーティングプロダクトリリースのためのリリース計画ミーティング

イテレーション計画ミーティングイテレーション（スプリント）ごとのリリース計画やアクティビティなどを計画するミーティング

イテレーションゴールや結果にアプローチするプロセスを繰り返すこと

プランニングポーカースプリント計画時のタスクを見積もるためのプランニングポーカー

ベロシティ計測プロジェクトベロシティの計測

日次ミーティング現在の問題を解決するための短いデイリーミーティング

ふりかえり前のスプリント（イテレーション）から学ぶためにふりかえる

かんばんジャストインタイムの継続的なデリバリを強調した管理手法

スプリントレビュー完了した仕事を表明するスプリントレビューミーティング

タスクボード（タスクカード）ボードに貼られたメンバーが継続的に更新するタスク

バーンダウンチャートスプリント進捗をモニターするためのバーンダウンチャート

柔軟なプロセス状況や環境の変化に対応できる柔軟なプロセスにしている、もしくは、プロセスを柔軟に変更している

プロダクト

ユーザーストーリー要求についての会話を行うときの開発チームとプロダクトオーナーの間の合意事項

スプリントバックログプロダクトオーナーとチーム間でのスプリントバックログへの相互コミットメント

インセプションデッキ 10の質問によりプロジェクトの属性を明らかする

プロダクトバックログ（優先順位付け）

プロダクトオーナーによる優先順位（プロダクトバックログ）の管理

フィードバック迅速なフィードバック迅速なフィードバックを得られるような取組みを行っている




技術・ツール

設計開発

ペアプログラミングすべての製品コードはペアプログラミングで開発している

自動化された回帰テスト自動化された回帰テストを行っている

テスト駆動開発単体テストを書き、そのテストを通るようなコードを実装する

ユニットテストの自動化ユニットテストの自動化

受入テスト受入テストの実施と、その結果を公開している

システムメタファ関係者全員が、そのシステムがどのように動くかについて伝えることができるストーリー

スパイク・ソリューションリスクを軽減するために、隠れた問題を探索するための簡単なプログラム（スパイク・ソリューション）の試作

リファクタリング定常的なリファクタリング

シンプルデザイン設計をシンプルに保つ

逐次の統合一度に統合するコードはひとつだけとする

継続的インテグレーション継続的インデグレーション、または頻繁なインテグレーション

集団によるオーナーシップ全員がすべてのコードに対して責任を持つ

コーディング規約同意された標準のためのコーディング規約

障害対応バグ時の再現テストバグが見つかったとき、そのテストがまず最初に作られる

利用ツール紙・手書きツールポストイット（付箋紙）やCRC（class-responsibility-collaboration）カードなどの使用




チーム運営・組織・チーム環境

人

顧客プロキシ要件や仕様をまとめるために顧客の業務に精通した顧客プロキシの設置

オンサイト顧客顧客といつでも／定期的にやりとりが可能である

プロダクトオーナープロダクトオーナー役の設置

ファシリテータ（スクラムマスター）

スクラムマスターによる開発プロセスとプラクティスのファシリテーション

アジャイルコーチアジャイルコーチがプロジェクトに参加している

自己組織化チームチームメンバーがタスクに志願するなど自律的なチームになっている

ニコニコカレンダーニコニコカレンダーを用いてメンバーの気持ちを見える化している

進め方持続可能なペース継続的なペースで開発している

組織導入組織にあわせたアジャイルスタイル

組織にあった適切なアジャイルスタイルを用いるようにしている

ファシリティ・ワークスペース

共通の部屋オープンスペースがチームに与えられている

チーム全体が一つにチーム全員がひとつのゴールに向かうような取組みを行っている

人材のローテーション多能工の育成などのため人材のローテーションを行っている

インテグレーション専用マシン特定のインテグレーション用コンピュータ


出典：「IT人材白書2014」，IPA，2014年4月25日．http://www.ipa.go.jp/jinzai/jigyou/about.html

業務において最もよく用いられる開発プロセス（技術者別）

参考データ

アジャイル開発を用いる技術者


業務改善ニーズ業務運営業務設計

顧客・サプライチェーン環境変化（顧客・市場・技術・政策）

組織的支援

構成情報構成情報

企業価値企業

価値

機能

業務改革等への参加

改革・改善サイクル

SLA管理

サービスデスク

インシデント・問題管理

キャパシティ管理

オペレーション管理

IT運用 IT取得

SLCPでカバーしているプロセス

設計

開発/構築

テスト

移行

ＩＴプロジェクト管理

経営(CIO含む) 経営(CIO含む)

業務改革企画

IT企画

要件定義/SLA定義SLA

業務開発業務の改革・改善経営・業務の運営

ITの運用 ITの改革・改善 IT開発

②サービスマネジメント

①業務改革プロジェクト

経営

業務

システム

SW

環境

移管/移行

教育/移行

新規開発

拡充開発(完全化保守)

保守開発(適応保守)

出典：共通フレーム2013

全体最適『“運用→開発→運用”

という流れで全体を捉えるべき』

このサイクルを短期間でまわす

参考

業務運用とアジャイル開発


<出典> James Lewis: Microservices, ThoughtWorks, 25 March 2014.

http://martinfowler.com/articles/microservices.html

複数の小さな“サービス”を組み合わせてアプリケーションを構築各サービスは独立にデプロイされ，疎結合で独立動作．

従来の“モノリシック”タイプマイクロサービス

参考

要求変化対応ソフトウェア・アーキテクチャ（マイクロサービス１/２）


俊敏な変更が可能

独立チームで特徴を活かす

＜課題＞不得手な制御もあるトラブル時の対応に配慮要開発・運用の効率化のための支援環境が重要

マイクロサービスの特徴

必要なサービスのみ，変更・置換他のサービスへの影響の考慮不要

制約が少なく，工夫・挑戦する意識の高まり責任の明確化

サービス3

サービス2

サービス1

サービス5

サービス4

軽量な，標準インタフェース置換対象

参考

要求変化対応ソフトウェア・アーキテクチャ（マイクロサービス２/２）


DevOpsとマイクロサービスへの関心の高まり

図１キーワード：“DevOps”と“microservices”の使用数の増加（a Google Trends reportに基づく）

<出典>

Armin Balalaie, Abbas Heydarnoori and Pooyan Jamshidi:

Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture,

IEEE Software, Vol.33, No.03, pp: 42-52, May-June 2016.

参考

iot時代に向かい，進化し続けるアジャイル -...

Documents