ハイブリッドアジャイルへ至る道と、その【真】の姿～日本流アジャイルを模索し続けた15年をふりかえる～

1セッション概要（公式サイトから）2002年からアジャイル開発に取り組み始めた英氏は、2008年頃までに様々なアジャイル開発手法を実践し、評価してきました。また、大規模かつ受託開発が主流の日本で、どうやってアジャイル開発手法を役立てるか、試行錯誤を繰り返し、研究を続けてきました。そして考案されたのが「ハイブリッドアジャイル」です。
ウォーターフォールとアジャイル、相反するように見える
２つの手法を、様々な形で組み合わせることで、プロジェク
トの課題に幅広く対応できる、実に奥深い考え方です。
当セッションでは、英氏の15年間の研究・実践でのエピ
ソードを語っていただきながら、日本でアジャイル開発を幅広く活用するヒントを考えます。
2

Q1.１５年前をふりかえる• アジャイルに取り組み始めた頃の状況• 2002～2003年頃• ご自身の周囲の状況• 世の中の動向• アジャイルに取り組み始めたきっかけと苦労• 2000年頃まではどんなことをされていたのですか• 何をきっかけにアジャイルを始めたのですか• その時にどんな苦労がありましたか3

Ｑ１：１５年前をふりかえる© Hitachi Solutions, Ltd. 2017. All rights reserved.

4

1-1．自己紹介

株式会社日立ソリューションズ
業務革新統括本部 IT技術推進センタ
ハナブサ

シゲオ

英 繁雄
私のアジャイル取り組み履歴・2002年 社内システム２件をアジャイル開発し、国内事例発表
・2003～ さまざまなアジャイル手法を評価
2008年 委託開発にはアジャイルは避け、アジャイルプラクティスの良いところをウォーターフォールに取り入れるようにしていた製品開発には、アジャイルを推奨していた・2009年 大規模な委託開発向けアジャイル手法開発に取り組む
海外のアジャイルコンサル企業視察（開発現場や委託開発現状）
・2010年 大規模システム向け日本版アジリティ開発手法発表
・2013年 「ハイブリッドアジャイルの実践」 出版
・2014年 BRMSで自動生成するアジャイル手法 Agile BRMS on Cloud 開発･現在
社内システムをアジャイル手法で継続開発© Hitachi Solutions, Ltd. 2017. All rights reserved.

5

1-2．アジャイルに取り組み始めた頃の状況
2002～2003年頃
・ XP/Scrumで社内システム２件を開発
・ 国内のアジャイル事例として社外発表

周囲の状況
・ アジャイルの取り組みを呼びかけても、反応はあまりなかった・ アジャイル ＝ いいかげん の認識

世の中の動向・ XPが話題、さまざまなアジャイル手法の中Scrumが注目されはじめていた技術的なプラクティス中心のXPに、Scrumは自己組織化するプラクティス
が加わった
・ アジャイルプロセスは勉強段階。アジャイル書籍出版や講演がよく開催されるようになってきた。国内事例はほとんど無し。
© Hitachi Solutions, Ltd. 2017. All rights reserved.

6

1-3．アジャイルに取り組み始めたきっかけと苦労
2000年頃までにやっていたこと
・ 生産技術部で、主にWebアプリケーション開発の開発基盤整備
・ 開発ツール導入、フレームワーク開発、ウォーターフォールプロセス整備、UML設計、見積もり手法（FunctionPoint法、UseCasePoint法）など

アジャイルのきっかけ
・ 開発ツールや自動生成技術での生産性向上に限界を感じていた
・ 全工程に影響するプロセス改善に、生産性向上の余地があると感じた

その時の苦労・ 生産技術部門であるため、アジャイル手法の評価として実施できたが、正式な開発案件には、会社標準の開発手順ではないため承認されない。
・ 設計ドキュメントは、最小限で初期開発を行ったが、数年後のエンハンス
作業委託開発時に設計書作成することになった。
・ 品質保証部門の既存の役割では、参画できない。
© Hitachi Solutions, Ltd. 2017. All rights reserved.

7

Q2.各アジャイル手法の特徴• 様々なアジャイル開発手法を試したとのこと• 部分的なプラクティス導入など• 各手法をやってみて感じた特徴（良い/悪い）• 特に、現在主流であるXP/Scrumの印象は？

• 実践にあたっての日本文化との相性※本セッションでは「契約」にはあまり触れません
8

Ｑ２：各アジャイル手法の特徴© Hitachi Solutions, Ltd. 2017. All rights reserved.

92-1．様々なアジャイル開発手法
アジャイル開発に分類される手法• XP（eXtreme Programming）：Kent Beck，Ward Cunningham，Ron Jeffries，Martin Fowler，Robert C. Martin，James Grenning• Scrum：Ken Schwaber，Jeff Sutherland，Mike Beedle• FDD（Feature-Driven Development）：Jeff De Luca，Peter Coad，
M.A. Rajashima, Lim Bak Wee，Paul Szego，Jon Kern，
Stephen Palmer• Lean Software Development：Mary Poppendieck, Tom Poppendieck• Kanban：David Anderson• DSDM：Arie van Bennekum• Crystal：Alistair Cockburn© Hitachi Solutions, Ltd. 2017. All rights reserved.

102-2．様々なアジャイル開発手法
アジャイルで最も利用されている手法はScrum
58%

60%
50%
40%

Scrumベースが
８３％

30%
20%
10%

10%

8%

7%

5%

3%

3%

2%

1%

1%

1%

1%

1%

2%

0%

出典：VersionOne-10th-Annual-State-of-Agile-Report（2015年 世界3,880件） から加工（日本語訳、グラフ表示の変更）して作成
http://stateofagile.versionone.com/© Hitachi Solutions, Ltd. 2017. All rights reserved.

112-3．様々なアジャイル開発手法
アジャイルプラクティスの利用は、プロジェクトごとに異なる
デイリースタンドアップ
順序付けされたバックログ
短いイテレーション
振り返りイテレーション計画
リリース計画
単体テスト
チームでの見積り
タスクボードイテレーションレビュー
継続的インテグレーション
プロダクトオーナー
シングルチーム（開発とテストの統合）
コーディング基準
カンバン
オープンな作業エリア
リファクタリング
テスト駆動開発
ストーリーマッピング
受け入れテスト自動化
継続的デプロイ
ソースコードの共有
ペアプログラミング
アジャイルゲーム
ビヘイビア駆動開発

83%
82%
79%
74%
69%
63%
63%
59%
55%
54%
50%
49%
45%
44%
39%
38%
37%
33%
30%
28%
27%
25%
24%
16%
10%

出典：VersionOne-10th-Annual-State-of-Agile-Report（2015年 世界3,880件） から加工（日本語訳、グラフ表示の変更）して作成
http://stateofagile.versionone.com/© Hitachi Solutions, Ltd. 2017. All rights reserved.

122-4．様々なアジャイル開発手法
ＸＰとＳｃｒｕｍ
ＸＰのプラクティス
イテレーション（反復）共通の用語
開けた作業空間
レトロスペクティブ（振り返り）
テスト駆動開発（TDD）
ペアプログラミング
リファクタリング
ソースコードの共同所有
継続的インテグレーション
YAGNI
責任の受入れ援護
四半期ごとの見直し
ミラー
最適なペースの仕事ストーリーの作成
リリース計画
受入れテスト
短期リリース
朱書き：講演者自身が実践したことのあるプラクティス

Scrumのロール
プロダクトオーナー
スクラム開発チーム
スクラムマスター
Scrumの会議
スプリント計画会議
ディリースクラム&スプリント実行
スプリントレビュー会議
レトロスペクティブ
バックログ調整会議

Scrumでは、自己組織化するためのルールが目立つ。
Scrumは、技術的なプラクティスはXPを推奨している。

© Hitachi Solutions, Ltd. 2017. All rights reserved.

132-5．様々なアジャイル開発手法
ＦＤＤのプラクティス
ＦＤＤのベストプラクティス
領域オブジェクトモデリング
ユーザ機能による開発
クラス（コードの個別担当）
ユーザ機能チーム
インスペクション
定期的な構築構成管理
進捗の報告と可視性

キーワード
フィーチャ（機能）フィーチャ・セット
主要フィーチャ・セット
プロジェクトマネージャ
チーフアーキテクト
開発マネージャチーフプログラマ
クラスオーナーテスタ
デプロイヤ
テクニカルライタ

内容
２週間で開発が完了する程度で、粒度が一定となる
フィーチャをグループ化したもの
フィーチャ・セットの上位概念
財務面、レポート面を含め、プロジェクトの管理面すべてを担当
設計セッション、コードレビュー、テクノロジの決定を含め、システムの設計全体を担当
開発チームとその作業の調整、リソース問題の処理など、
毎日の開発作業を引き受ける
進行中の設計および開発アクティビティにかかわるシニア
開発者。1つ以上の機能セットの担当が割り当てられる
チーフプログラマの指示下で機能の実装に従って機能の設計、コーディング、テスト、文書化を行う開発者
各機能が定義どおりに実行しているかどうかの検証を担
当
各種環境へのコードの実際のデプロイメントだけでなく、データの定義/形式間の変換も処理ユーザが必要とするすべてのオンライン文書および印刷文書の作成と保守を担当© Hitachi Solutions, Ltd. 2017. All rights reserved.

14

2-6．様々なアジャイル開発手法
ＦＤＤの進捗の報告と可視性（パーキングロットチャート）
マイルストーン

重み（例）領域ウォークスルー

１％

設計

４０％

設計インスペクション

３％

コード

４５％

コードインスペクション

１０％

構築への統合１％

機能が開発サイクルのどこに位置しているかを正確に把握するには、表の6つの具体的な
マイルストーンを追跡する

顧客管理機能従業員管理機能
担当者Ａ

担当者Ｂ

担当者Ｃ

担当者Ｄ

資格管理
（７）
０％

勤務管理
（9）
３３％

給与管理
（１５）
１００％

給与管理
（１０）
８０％

2017/52017/42017/32017/3

担当するチーフプログラマの名前
プロジェクト内の各機能セット
各エリア内の機能の数機能セットの完了率
各機能セットの完了目標年月

白：未着手
黄：進行中で予定どおり
緑：完了
赤：注意（遅延など）© Hitachi Solutions, Ltd. 2017. All rights reserved.

15

2-7．様々なアジャイル開発手法
Lean Software Development ７つの原則と２２の思考ツール
７つの原則
ムダを排除する

学習効果を高める

決定をできるだけ
遅らせるできるだけ速く提供するチームに権限を与える

統一性を作り込む

全体を見る

２２の思考ツール
１：ムダを認識する（未完成作業、余分なプロセス、余分な機能、タスク切り替え、待ち、移動、欠陥）
２：バリューストリームマッピング（工程間の待ち、工程内の実作業時間を見える化する）
３：フィードバック
４：イテレーション
５：同期
６：集合ベース開発
７：オプション思考
８：最終責任時点
９：意思決定１０：プルシステム
１１：待ち行列理論
１２：遅れのコスト
１３：自発的決定
１４：モチベーション（所属、安全、能力、進捗）
１５：リーダシップ
１６：専門知識
１７：認知統一性（利用者に対するユーザビリティ、信頼性、経済性のバランス）
１８：コンセプト統一性（アーキテクチャなどのシステムの基本概念）
１９：リファクタリング
２０：テスティング
２１：計測
２２：契約
© Hitachi Solutions, Ltd. 2017. All rights reserved.

16

2-8．様々なアジャイル開発手法
Kanban はプル型システム
タスクボード（カードウォール）

タスクボード（管理ツール）・Kanbanは、開発プロセスではない
ソフトウェアやサービスの企画から開発、リリースするまでの作業を効率化する仕組み
・カードウォールやタスクボードは、進捗を見える化するためのツール
・Kanbanは、プル型システム（後工程引き取り方式）
その結果、最適ペースを可能にする
・Kanbanによる進捗の管理は、タスクボードによって見える化することができる

プル型システムになっていれば、
Kanbanシステムと言える

委託開発の契約やワークスタイル改革に、たいへん重要な考え方である© Hitachi Solutions, Ltd. 2017. All rights reserved.

172-9．様々なアジャイル開発手法
Kanban Systemの主要目的
主要目的
既存プロセスの最適化
高品質でのデリバリー
リードタイム実現比率の向上
従業員の満足度向上
改善を可能とする「ゆとり」の提供
優先順位付けの簡易化
システム設計と運用への透明性の提供「高成熟」組織の出現を可能とするプロセス設計

内容
見える化や仕掛り制限の導入
品質基準など次の作業段階で引き取る条件のポリシーを定義する
仕掛り量とリードタイムの相関関係により、仕掛り上限を同意する
良いワークライフバランスの提供により、従業員の士気を高め、高いレベルのパフォー
マンスを生み出す「ゆとり」があれば、緊急要件への対応能力が高まり、プロセス改善を考える幅が生まれる
MoSCoW法などの優先順位付け手法を適用する
仕掛り、デリバリー率（スループット）、品質に透明性をもたらす
市場変化に、迅速に対応可能な組織の出現を可能にする© Hitachi Solutions, Ltd. 2017. All rights reserved.

18

2-10．様々なアジャイル開発手法
DSDMの６段階と４つの主要フェーズ（フィージビリティから展開フェーズ）
プロジェクト前段階① プロジェクト前段階
プロジェクトを明確に定義する

フィージビリティ・フェーズ② フィージビリティ・フェーズ
技術的な観点から実現可能か、ビジネス上の観点からコスト効果があるかを確認する

基礎フェーズ③ 基礎フェーズ
ビジネス上の根拠、作成される潜在的な解決策、およびソリュー
ションの開発と提供がどのように管理されるかについての基本的な理解を確立する

進化型開発
フェーズ

④ 進化型開発フェーズ

構築
レビュー
デプロイ

展開フェーズ

反復開発,タイムボックス,MoSCoW法による優先順位付け,モデリ
ング,ワークショップなどのプラクティスを適用して開発を進める⑤ 展開フェーズ
リリースまでに構築、レビュー、デプロイの３つの主要なアクティ
ビティがあり、最終リリースをもって完了する

プロジェクト後段階⑥ プロジェクト後段階予想されるビジネス上の利益がどれだけ満たされているかを確認する© Hitachi Solutions, Ltd. 2017. All rights reserved.

19

2-11．様々なアジャイル開発手法
MoSCoW法で、４段階に優先順位を付ける （図は例）
MoSCoW法による優先順位

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

ｲﾃﾚｰｼｮﾝ

こ
こ
ま
で
で
リ
リ
ー
ス

MUST
必須
SHOULD
できれば
実装すべき
COULD
できれば実装する
と良い

見
送
る

WON’T（WOULD）
将来的にあると良い Backlog List の優先順位付けに便利な手法
 委託開発時のスコープ調整や予算超過防止に重要な考え方である© Hitachi Solutions, Ltd. 2017. All rights reserved.

20

2-12．様々なアジャイル開発手法
DSDMの体制
ビジネス
スポンサ
プロジェクトレベル

ビジネス
ビジョンナリテクニカル
アドバイザ

プロジェクトマネジャ

テクニカル
コーディネイタ

ビジネス
アナリスト

ビジネス
アドバイザ

開発チーム
ビジネス
アンバサダ

チームリーダソリューション
デベロッパ

ソリューション
テスタ

ワークショップ
ファシリテータ

DSDMコーチ
サポート© Hitachi Solutions, Ltd. 2017. All rights reserved.

21

2-13．各手法をやってみて感じた特徴
手法

感想

XP

・アジャイル技術の基本。小規模な内製向き

Scrum

・XPに自律的な組織化の考えが加わり、手法として理解しやすい
・内製向き

FDD

・製品開発向きと思う
・クラス単位の進捗管理方法は、管理しやすい

Lean

・具体的なプラクティスではないが、考え方として重要・委託開発も意識されている

Kanban・単に見える化するための手法ではなく、プル型の考え方は、委託開発やワークスタイル改革に対して、重要な考え方

DSDM

・委託開発を意識している・プロジェクト体制やMoSCow法を推奨とする優先付けは参考になる© Hitachi Solutions, Ltd. 2017. All rights reserved.

22

2-14．実践にあたっての日本文化との相性
日本はITサービス企業に７５％、米国はユーザ企業に７２％
タイプB

タイプA

凡例
① ITサービス企業に勤務② ユーザ企業に勤務

日本は、極端な委託開発傾向
米国は、極端な内製傾向
アジャイル手法には、委託開発を意識したものが少ない
日本は、大手ＳＩベンダが多い
中国・インドのＳＩベンダはオフショ
ア先が多い

タイプC
出典：各国統計資料（米国労働省労働統計局等）
公知情報（NASCOMM、アジア情報化レポート、RUSSOFT、IPA IT人材白書2010）
その他：「ガートナー／Enterprise IT Spending by Vertical Industry Market, Worldwide, 2008-2014, 2Q10 Update」の内部サービスコスト、及び「平均給与単価（後述）」に基づく推計値から（独）情報処理推進機構：IT 人材白書 調査報告書 グローバル化を支えるIT 人材確保・育成施策に関する調査，p.44, 図表3-14,
http://www.ipa.go.jp/files/000010609.pdf（2016年8月1日現在）に纏めたもの© Hitachi Solutions, Ltd. 2017. All rights reserved.

23

2-15．実践にあたっての日本文化との相性
法律は、国によって異なる。アジャイルで委託開発するために考慮が必要

請負契約•契約のための見積もりが必要•業務完成義務•瑕疵担保責任•指揮命令系統

準委任契約•契約のための見積もりが必要•善管注意義務•報告義務•指揮命令系統

指揮命令系統・ユーザ企業からの委託先担当者へ直接指揮命令はできない

資産計上
・リリースすれば、資産となる。内製でも同じ。
© Hitachi Solutions, Ltd. 2017. All rights reserved.

24

2-16．実践にあたっての日本文化との相性

予算化

契約
役割

品質

•年度または期単位に全体予算を申請する（随時予算追加困難）•委託開発では、法律上の作業指示系統の制限（全員同席困難）•請負契約の場合、成果物責任による要件追加・変更に対する契約が必要 （変更受入れが困難）•工程別にマルチベンダ開発や製造工程のオフ
ショア発注など縦割りとなるケースが多い（要件定義、設計、開発の同時進行が困難）•設計者とプログラマという役割分担のためドキュメ
ントベースでの仕様伝達 （ドキュメント省略の限界）•「バグは付きもの」では済まされない。日本では、「バグはあってはならない」という感覚。テスト十分性の結果報告が求められる（テスト工程省略が困難）© Hitachi Solutions, Ltd. 2017. All rights reserved.

25

Q3.教科書アジャイル• 日経SYSTEMS記事「さらば教科書アジャイル」（2015年9月号）• これから初めてアジャイルを実践する現場にとって「教科書アジャイル」は役に立たない？

• 真意を教えてください• 初めてアジャイルに取り組む際の心得とは• お勧めの本
26

Ｑ３：教科書アジャイル© Hitachi Solutions, Ltd. 2017. All rights reserved.

27

3-1．日経SYSTEMS記事「さらば教科書アジャイル」
教科書アジャイルがダメと言っているのではない
・ 教科書アジャイル（義務教育）を習得して、プロジェクト条件（社会）にに合わせて工夫すると良い

基本はScrumを推奨
・ 標準的なアジャイル手法のScrumをまず理解し経験する© Hitachi Solutions, Ltd. 2017. All rights reserved.

28

3-2．初めてアジャイルに取り組む際の心得と推薦図書

提言
・ 既存のウォーターフォールを経験してから、アジャイルに取り組む
何がムダか設計すべきことが分かる。
・ 「とりあえずやってみる」では、効果は解らない。プロジェクトの目的と成果を明確にして行う。

推薦図書
・ 具体的な書名ではないが、Scrumの手法を解説した書籍（まずは、アジャイルの技法を学ぶ）
・ アジャイルの考え方を解説した書籍（リーンソフトウェア開発、カンバンなど） アジャイルの奥深さに気づく© Hitachi Solutions, Ltd. 2017. All rights reserved.

29

Q4.ハイブリッドへの想い• 10年以上ハイブリッドアジャイルを考え続けた、
その想いを教えてください• 心に残った英さんの言葉• 異なるものを掛け合わせるからハイブリッド• 同じ方向性のものならブレンド• 異なるものを掛け合わせる → 無限の可能性

30

Ｑ４：ハイブリッドへの想い© Hitachi Solutions, Ltd. 2017. All rights reserved.

31

4-1．ハイブリッドアジャイルの想い
日本の法律に適合した大規模委託開発への対応
初期：アジャイルは、小規模な内製でしか通用しないと感じた
委託開発には、アジャイルのプラクティスのよいところを取り入れて改善できる（継続的インテグレーション、チケット管理、テスト駆動開発など）
海外で大規模開発の事例が出てきた。委託開発の事例もある。
日本の法律に対応した委託開発向けアジャイル手法を研究
海外のアジャイル現場の視察
大規模システム向け日本版アジリティ開発手法開発（ハイブリッドアジャイルに日本の法律に対応することと独自の開発
基盤（ツールなど）を活用した開発効率向上施策を組込んだ
ハイブリッドアジャイル実践（委託開発で変更を受け入れながら行う）© Hitachi Solutions, Ltd. 2017. All rights reserved.

32

4-2．ハイブリッドアジャイルの想い
受託開発へのアジャイル適用を想定したプロセス■ ウォーターフォールに、アジャイルによる反復開発を部分的に適用する（詳細設計～単体テストを適用した場合の例）
要件定義

イテレーション開始前に、可能な限り要件を確定させる

総合テスト

基本設計
結合テスト

契約

仕様確認
レビュー

イテレーション

製作

イテレーション

詳細設計

イテレーション

イテレーション

イテレーション

詳細設計以降をイテ
レーションの範囲とし、要件変更に対応
する

テスト工程を設けることで、品質を確保する© Hitachi Solutions, Ltd. 2017. All rights reserved.

33

4-3．ハイブリッドとブレンド
ハイブリッドアジャイルの定義はない
P11のスライドにあるCustom Hybrid（multiple methodologies) は、特に定義されたアジャイル手法ではなく、さまざまなプラクティスを混ぜ合わせたり、他の開発手法と組み合わせたものなどがある。
開発手法をウォーターフォールとアジャイルに分けるのであれば、次のような表現にした方が良いと思う。
・ハイブリッドアジャイル：ウォーターフォール ＋ アジャイル
・ブレンドアジャイル：アジャイル同士やアジャイルプラクティスの組み合わせブレンド

ハイブリッドアジャイル
ウォーターフォールXP

Kanbanﾌﾟﾗｸﾃｲｽ

Scrum

ﾌﾟﾗｸﾃｲｽ注） ブレンドアジャイルは、今回初めて使用した言葉であり、一般的な用語ではない© Hitachi Solutions, Ltd. 2017. All rights reserved.

34

4-3．異なるものを掛け合わせる
ハイブリッドアジャイルの主なパターン
要件定義

基本設計

要件定義

基本設計

要件定義

詳細設計

製作

詳細設計・製作

基本設計・詳細設計・製作

要件定義

ﾌﾟﾛﾄ
ﾀｲﾌﾟ

要件定義

基本設計

基本設計

詳細設計・製作

詳細設計

製作

詳細設計・製作

結合テスト

総合テスト

結合テスト

総合テスト

結合テスト

総合テスト

結合テスト

総合テスト

結合テスト

総合テスト

© Hitachi Solutions, Ltd. 2017. All rights reserved.

35

Q5.プロセスの組み合わせ方• ウォーターフォールプロセスでの21世紀での歪み• CPU使用料の変化（昔：高価、今：格安）• プログラム設計の意義（アセンブラと高級言語の差）• ウォーターフォールの良いところを活用しつつ時代の変遷により生じた弱点を補完する• アジャイルプロセスへの期待

36

Ｑ５：プロセスの組み合わせ方© Hitachi Solutions, Ltd. 2017. All rights reserved.

37

5-1．プロジェクト条件は常に異なる
アジャイル適用の目的
手戻り防止•エンタープライズシステム

システム
形態

•製品開発

プロジェクトリスク低減
開発コスト低減

利用者満足度向上•サービス開発

エンハンス効率向上
早期リリース

特性•大規模・中規模・小規模•システムの重要度•開発技術（自動生成ツールやスマートデバイスなど）

体制•内製，委託開発（請負契約，準委任契約）•オフショア利用，マルチベンダ開発など© Hitachi Solutions, Ltd. 2017. All rights reserved.

38

5-2．ハイブリッドアジャイル事例１
中規模システムの委託開発
項目

説明

契約形態

請負契約（見積もり価格提示、品質保証、納品日確定）

システム形態

Webアプリケーションとバッチプログラム

規模

中規模

目的

作り直しリスク低減：開発中に動作確認でき、修正対応可能にする
コスト削減：作業のムダ取り、自動化による生産性向上

ユーザー事情・他プロジェクトや多くのSIベンダがいるオープンフロア（プロジェクト
ルームではない）
・ユーザは常時同席はできない（定期的な打合わせで行う）
・プロジェクト状況の定期報告、仕様変更ルール© Hitachi Solutions, Ltd. 2017. All rights reserved.

39

5-3．ハイブリッドアジャイル事例１
オンラインは、詳細設計・製作工程をアジャイル、バッチはウォーターフォール

オンラインシステム

詳細設計・製作
要件定義

基本設計

バッチシステム

詳細設計

準委任
契約

結合テスト

総合テスト

製作

請負契約
（準委任契約でも可能）

準委任
契約© Hitachi Solutions, Ltd. 2017. All rights reserved.

40

5-4．ハイブリッドアジャイル事例１採用したプラクティス
ハイブリッドアジャイル
委託開発契約
品質確保

Lean（ﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞｬ,ﾃｽﾀ,目標コスト）
見積もり（FunctionPoint法,ﾀｽｸ法）

XP（ﾚﾄﾛｽﾍﾟｸﾃｨﾌﾞ,TDD,ﾍﾟｱﾌﾟﾛ,
ﾘﾌｧｸﾀﾘﾝｸﾞ,ﾐﾗｰ,ｽﾄｰﾘｰの作成,
CI,ﾘﾘｰｽ計画,受入れﾃｽﾄ）
利用者満足度向上
コスト削減
手戻り作業防止

Scrum（ﾌﾟﾛﾀﾞｸﾄｵ-ﾅ-,ﾊﾞｯｸﾛｸﾞ作成,
ｽﾌﾟﾘﾝﾄ,ｽｸﾗﾑ会議,ｽﾌﾟﾘﾝﾄﾚﾋﾞｭｰ）

Kanban，チケット管理
DSDM（MoSCoW法）

要件・課題整理
開発優先順位付け
開発コスト調整© Hitachi Solutions, Ltd. 2017. All rights reserved.

41

5-5．ハイブリッドアジャイル事例１
考慮したこと追加予算確保•仕様変更は追加契約と言われてもユーザ企業も簡単に社内で承認されるわけではない•変更に対する工学的見積もり手法の適用は、無駄に管理コストを増やす

主管部門は、通常業務で多忙•主管部門は、誰もが通常業務に追われている•委託開発では、ユーザ企業が直接委託先の担当者へ指示できない実装を諦める機能もあるという認識を共有する•変更を受入れ、期限までに契約コスト内で実装できるとは思ってはいけない© Hitachi Solutions, Ltd. 2017. All rights reserved.

42

5-6．ハイブリッドアジャイル事例２
大規模製品開発
項目

説明

契約形態

内製による製品開発（オフショア活用）

システム形態タブレットアプリとサーバシステム

規模

大規模

目的

新製品開発（市場確保しながらの開発）
・開発中から営業活動が始まる（展示博覧会出展、デモなど）
・プロトタイプ開発
・実現性を確認しながら開発
コスト削減
・オフショア活用
・作業のムダ取り

プロジェクト事情 マルチステークホルダー
・仕様確定するまでの調整が難しい
企業ルール
・事業化認可プロセス、プロジェクト状況報告© Hitachi Solutions, Ltd. 2017. All rights reserved.

43

5-7．ハイブリッドアジャイル事例２
オンラインは、詳細設計・製作工程をアジャイル、バッチはウォーターフォール
サーバーシステム

基本設計
要件定義

製作

詳細設計
クライアントシステム

基本設計

結合テスト

総合テスト

詳細設計・製作

プロトタイプ

テスト

設計
実現性
検証

製作（オフショア）© Hitachi Solutions, Ltd. 2017. All rights reserved.

44

5-8．ハイブリッドアジャイル事例２採用したプラクティス

Scrum（ﾌﾟﾛﾀﾞｸﾄｵ-ﾅ-,ﾊﾞｯｸﾛｸﾞ作成,
ｽｸﾗﾑﾏｽﾀ,ｽﾌﾟﾘﾝﾄ,ｽｸﾗﾑ会議,
ｽﾌﾟﾘﾝﾄﾚﾋﾞｭｰ）
開発期間短縮
コスト削減

オフショア活用
CI（継続的インテグレーション）

MoSCoW法

プロトタイプ

要件・課題整理
開発優先順位付け
開発コスト調整

実現性確認
マーケティング

ハイブリッドアジャイル
予算見積もり品質確保© Hitachi Solutions, Ltd. 2017. All rights reserved.

45

5-9．ハイブリッドアジャイル事例２
考慮したこと混在する開発手法•プロトタイプ：営業活動や実現性検証•ウォーターフォール：サーバ機能やバッチの開発•アジャイル：複雑な機能を持つクライアントアプリ開発•工程別、アプリ別のハイブリッドアジャイル

スクラムマスタの不足•複数のスクラムチームの体制で行った場合、スクラムマスタを担当できる人材は不足したため兼任させた

ステークホルダーの調整•意見が纏まらず仕様確定に苦労する© Hitachi Solutions, Ltd. 2017. All rights reserved.

46

5-10．ハイブリッドアジャイル事例３
小規模社内システム
項目

説明

契約形態

内製による社内システム開発

システム形態

Webアプリケーションとバッチプログラム

規模

小規模

目的

早期リリース
・必要な機能から段階的にリリース
・リリース間隔は３～６ヵ月
ユーザ満足度向上
・人間中心設計、テスティングラボで検証
コスト削減
・作業のムダ取り・自動化
ワークスタイル改革・担当者は週２日自宅勤務
・分散拠点のメンバ１名も時々参加

プロジェクト事情 企業ルール
・予算確保、資産計上© Hitachi Solutions, Ltd. 2017. All rights reserved.

47

5-11．ハイブリッドアジャイル事例３
プロトタイプでユーザビリティを確保、テスト観点別にテスト実施

人間中心
設計
要件定義

結合テスト
設計・製作

プロトタイプ

総合テスト© Hitachi Solutions, Ltd. 2017. All rights reserved.

48

5-12．ハイブリッドアジャイル事例３採用したプラクティス（全員同席は古い、ワークスタイルも改革）
リーンスタートアップ
リリーススピードアップ

DevOpsScrum（ﾌﾟﾛﾀﾞｸﾄｵ-ﾅ-,ﾊﾞｯｸﾛｸﾞ作成,
ｽﾌﾟﾘﾝﾄ,ｽｸﾗﾑ会議,ｽﾌﾟﾘﾝﾄﾚﾋﾞｭｰ）

CI（継続的インテグレーション）

人間中心設計Kanban，チケット管理
MoSCoW法

要件・課題整理
開発優先順位付け
開発コスト調整

ワークスタイル改革（タイム&ロケーション フリー）

利用者満足度向上

プロトタイプデザイナーによる画面デザイン
テスティングラボ© Hitachi Solutions, Ltd. 2017. All rights reserved.

49

5-13．ハイブリッドアジャイル事例３
考慮したこと予算確保•予算の考え方にKanban （予算内でできたところまでをリリース）•予算と実績に差が出ない

開発標準（内部統制）•ウォーターフォール型の標準をアジャイルにテーラリング•設計書は、ストーリーカード，操作マニュアル，FAQで代用•UT，CT，STの観点でテストケースを作成し、テスト実施

資産計上•資産として登録はフェーズ単位（数ヵ月）•アジャイルのように数週間単位で資産計上をするようでは、財務部門が堪らない© Hitachi Solutions, Ltd. 2017. All rights reserved.

50

Q5.プロセスの組み合わせ方• ウォーターフォールとアジャイルは、どちらか一方しか選択できないものではない• プロジェクトの課題に応じて、双方を様々に組み合わせることでプロジェクトを成功させたい
アジャイル

B

C

ウォーターフォールA

51

Q5.組み合わせ方
A • 実現時の異常を検知することを目的• 要件と基本設計は最初に決める• 実装工程での問題を早く見つけるB • 要件の一部調整も許容することを目的• 主要な要件は最初に決め、詳細な要件は調整対象• 主に概要設計～結合テストの繰り返し

A

繰り返し範囲

B
要件
定義

基本
設計

詳細
設計

コーディ
ング

単体
テスト

結合
テスト

システム
テスト
52

Q5.組み合わせ方C • スプリントの中をミニウォーターフォール• 開発チームはウォーターフォール工程で開発する• POチームは設計書を作成して渡す• 手待ちが出ないように複数ストーリーを並行させる

スプリントをまたいだストーリーの動き

スプリント１
開
発
チ
ー
ム
Ｐ
Ｏ
チ
ー
ム

ストーリーA
要件定義
概要設計

スプリント２

スプリント３

スプリント４

ストーリーA
詳細設計
実装
単体テスト

ストーリーB
詳細設計
実装
単体テスト

ストーリーC
詳細設計
実装
単体テスト

ストーリーA
結合テスト
リリース

ストーリーA
結合テスト
リリース

ストーリーC
要件定義
概要設計

ストーリーC
要件定義
概要設計

ストーリーB
要件定義
概要設計

53

Q5.組み合わせ方• ハイブリッドカーを参考に• エンジンとモーターを状況に応じて切り換える

D ベース作り+機能追加
ウォーターフォール（ベース作り）

E

アジャイル（機能追加）

1st release
アジャイル（機能追加＋保守）

方向性決め＋横展開＋保守（機能改善）
1st release
アジャイル（方向性決め）ウォーターフォール
（横展開）

アジャイル
（保守＋機能追加）
54

Q5.組み合わせ方F • ウォーターフォールとアジャイルを並行させる→

例：斥候としてのアジャイル開発（細谷氏）

引用：「斥候としてのアジャイルプロセス活用の提案（p.8）」細谷 泰夫 氏（三菱電機）SPI Japan 2012 55

Q5.組み合わせ方【課題】
大規模な開発はリスクが高く、初期段階で精度の高い仕様を決めたり、仕様の整合性を確保するのが難しい→

大規模開発にはアジャイル開発をする動機がある→

特定部分にアジャイル開発を採用する「斥候としてのアジャイル開発」を実施

引用：「斥候としてのアジャイルプロセス活用の提案（p.5,6,12）」細谷 泰夫 氏（三菱電機）SPI Japan 201256

Q5.組み合わせ方• 第３軸を追加してみる
？？？

アジャイル

ウォーターフォール57

Q6.そしてDevOpsへ• ハイブリッドアジャイルからDevOpsへ• 社内実践の感想を教えてください58

Ｑ６：そしてＤｅｖＯｐｓへ© Hitachi Solutions, Ltd. 2017. All rights reserved.

59

6-1．ハイブリッドアジャイルからDevOpsへ
フェーズ１（４か月）

イメージ
づくり

画面
イメージ
作成

人間中心
設計
レビュー

フェーズ２（４か月）

テス
ティング
ラボ

プロト
作成

アジャイル
開発（２ヵ月）

テスト
（１ヵ月）

試行
（２W)

テスター
４名

試行
全従業員
６０００名

１ヵ月
プロダクトオーナー（仕様決定） １名
システム設計者（インフラ手配、方式検討） １名
プログラマ（方式検討、プログラム） １名
デザイナー １名
人間中心設計者 １名

人間中心設計者 ２名

ラボ協力
９名

動作するものを見ながら仕様を決めていく

ラフな仕様書、操作マニュアル、
FAQが設計書替わり

テスター
が参加
UT,CT,ST観点

DevOpsCI© Hitachi Solutions, Ltd. 2017. All rights reserved.

60

6-2．ハイブリッドアジャイルからDevOpsへ

運用
フェーズ１開発

ﾘﾘｰｽ

要望対応

フェーズ２開発

運用

ﾘﾘｰｽ
フェーズ３開発

リリースサイクル

３～６ヵ月
あまりに頻繁にリリースすると資産計上作業がたいへん

スケール

フェーズ１は最低限必要な機能のみ、フェーズ２以降順次機能
拡張

人材

開発者と運用者は同一人物© Hitachi Solutions, Ltd. 2017. All rights reserved.

61

6-3．ハイブリッドアジャイルからDevOpsへ
チケット管理（タスク、仕様、バグなど）

開発言語・フレームワーク

コミュニケーション

ＣＩ環境

実行環境

ＧＩＴ
© Hitachi Solutions, Ltd. 2017. All rights reserved.

62

6-4．ハイブリッドアジャイルからDevOpsへ
設計・開発・運用が同じチームのため決断が速い、CI環境よる作業効率化⑤ リリース① 要望受付④ 実装・テスト・バージョン管理・テストコード自動実行
・手動テスト② 対応検討
要望対応
（数時間の
１日以内
作業）

③ 仕様作成© Hitachi Solutions, Ltd. 2017. All rights reserved.

63

6-5． 社内実践の感想
利用者に驚きを与え、不満が１日で感謝に変わった
１０月某日

２月某日

10:08

9:19

管理機能に□ □ □ □できるよう改善してください。

画面遷移先を変更できませんか？

11:31
ご要望は、□ □ □ □ □ □ □ □ □で、よろしいでしょうか？
□ □ □ □ □ の仕様としたいと思います。
12:52
早々の回答ありがとうごございます。
□ □ □ □ □ で結構です。
17:34□ □ □ □ □ようにいたしました。ご確認
よろしくお願いいたします。
17:44
早い！！ありがとうございます。多謝です。
感激です。

10:06
さまざまなご意見がありますので、総合的に判断します。
10:34
今の仕様ですと管理者側からみて不便
です。
17:11
検討の結果、ご意見を反映させていただ
きます。

17:44
はやい対応で驚きました。ありがとうご
ざいます。
© Hitachi Solutions, Ltd. 2017. All rights reserved.

64

Q7.会場のみなさんへ• 最後に一言お願いします。

65

Ｑ７：会場のみなさんへ© Hitachi Solutions, Ltd. 2017. All rights reserved.

66

7-1．会場のみなさんへ

1. 開発手法
 Ｓｃｒｕｍは、基本知識として習得することを推奨 プロジェクトに合わせた開発手法を選択する
 さらに改善すること（オリジナルプラクティス）を考えよう ハイブリッドアジャイルは、委託開発に対応するために採用した
目的は、変更受け入れ／リスク対策／利用者満足度向上のため
 アジャイルの具体的な手法だけではなく、本質の理解が重要

2. 日本の事情・企業の事情
 外国生まれのアジャイル手法には、日本の事情は考慮されていない
 日本では、委託が主流。アジャイルで委託契約の場合は、法遵守に注意する
 企業のルールがアジャイル導入の支障となる場合があるが、これを乗り越えなければ、定着はできない Kanbanの考え方が、IT技術者のワークスタイル改革の鍵
無理な残業をしてまで、全てを完成させなくてもよい。健康的な業務時間内にできるところまでにするという考えを発注者と受注者間で理解が必要。
できれば完成させる、できなければ見送る機能を共有しておくことが必要。
© Hitachi Solutions, Ltd. 2017. All rights reserved.

67

おわり

ご参加ありがとうございました！

68