要求開発×アジャイル開発のポイント

企業価値につなげるアジャイル開発

要求開発×アジャイル開発のポイント
～ビジネスに貢献するシステムを開発するために～

ウルシステムズ株式会社
ディレクター河野正幸

ULS Copyright © 2011 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by

アジェンダ

1. 従来のシステム開発方法の限界

2. 要求開発×アジャイル開発のコンセプト

3. 事例紹介

4. 自社で実践する上でのポイント

ULS Copyright © 2011 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 1

1. 従来のシステム開発方法の限界


システム開発の抱える本質的問題
1.つくり過ぎのムダ（使われないものを作る） 2.不良のムダ（要求の手直しにコストをかける）
ユーザーに提供した機能の利用度合い要求の欠陥の発見時期でみた相対的な修正コスト
全欠陥の60%は要求フェーズで
作り込まれている
64%の機能が
使われていない
テストフェーズでは70倍
運用フェーズでは140倍以
上のコストが必要になる

(出典：Standish group study report in 2000 chaos report)

失敗するプロジェクトにはこの2つのムダが多く発生している。
 機能を盛り込み過ぎてプロジェクトの規模と複雑性が増大しマネジメントが困難になる。
→本当に必要なもの、価値が高いものに要求を絞り込む必要がある（つくり過ぎのムダを取る）
 問題の発見が遅れたために想定外の工数が必要となりマネジメントが困難になる。
→早い時期に要求を正しく定義する必要がある（不良のムダを取る）

ウォーターフォール開発でこの問題を解決するには限界がある。新しいやり方が必要。

問題解決に必要な2つのパラダイムシフト

 「要求定義」から「要求開発」へ
 「計画達成型（ウォーターフォール）開発」から「仮説検証型（リーン/アジャイル）
開発」へ
従来のシステム開発プロセス（線形的、シーケンシャル）
すべての工程を一度でやり遂げる計画に
リソースマネジメント
基づいて作業し、基本的に全部完成して
基本的にユーザが要求するもの
からサービスインする

供給

制御
はなるべく作る

ユーザが要求計画達成型
入力出力システム
語る要求定義システム開発

最初に決めた要件はなるべく
変化させない（フリーズする）

目指すベきシステム開発プロセス（非線形的、スパイラル）システムの一部を
早期に運用できる
リソースマネジメントリソースように計画・作業し、
ユーザが要求するもの尐しずつ作って動くもので PDCAサイクルを短
供給

制御

供給
制御
の価値を測り、優先順仮説を検証し、当初の要件をく何度も繰り返す
位をつけて絞り込む積極的に改善する
ユーザが価値の仮説検証型価値の高い
入力要求開発出力入力出力
システム
語る要求高い要求システム開発
フィードバックフィードバック

2. 要求開発×アジャイル開発のコンセプト


要求開発のねらい

要求開発のねらい
プロジェクト関係者が要求の価値をしっかりと見極め、
本当に必要なものだけを正しく理解して共有する。

必要なパラダイムシフト
「正しい要求はユーザの心の中にすでに在る」
だから、それを聞き出して定義すれば良い（受動的）

「自分の要求を最初から正しく理解している人はいない」
だから、一緒に要求を開発する（能動的）


改善のポイント

Why：わが社の存在意義は何か
A． why ミッション/ビジョンステートメント

要求を構造化してビジョン
追跡可能にする how
What：わが社はどんな価値を生み出すのか
why
ビジョン、戦略、業務、ITをきちんと戦略ビジョンを実現するための競争戦略（ビジネス要求）
つなげることで価値を測定可能にする
how How：競争戦略をいかに実行するのか（業務＋ＩＴ）
why 業務（オペレーション) 競争戦略を実現するためのビジネスプロセス（ユーザ要求）
情報システム業務を支援するための情報システム（システム要求）
how

ビジネスモデリング
B.
業務の本質を「見える化」して
関係者で理解を共有する

参加協調型の意思決定・
トヨタ式「なぜを5回」発明的思考
C. 合意プロセス
より価値の高い要求や
解決策を発見・発明する


仮説検証型（アジャイル）開発のねらい

仮説検証型（アジャイル）開発のねらい
問題をなるべく上流で発見・解決すると共に、繰り返し
解決策を試すことでより優れた解決策を発明する。

必要なパラダイムシフト
なるべく最初の計画どおりに、最後までプロジェクトを進める
ことに注力する（変化は悪）

計画の変更をあらかじめ想定し、変化に素早く適応できるよ
うに徹底的にムダと遅れを排除する（変化を受け入れる）



D. 計画達成型（ウォーターフォール）システム開発プロセス
フィードバックループシステム開発期間
(PDCAサイクル)を要求定義受入テスト
短く回し、不確定な要求や基本設計システムテスト
リスクに早期に対処する詳細設計結合テストユーザにシステムが
実装単体テスト見えない期間

E.
ユーザーが真剣に
システムを考えられる
状況を早期に作り出す仮説検証型（アジャイル）システム開発プロセス
システム開発期間
反復1 反復2 反復3 反復4 反復5 反復6

次反復（イテレーション）へ
要求定義受入テスト
1回の
F. 基本設計反復プロセスシステムテスト
チームがプロジェクト
詳細設計結合テスト
期間中に継続的に学習しユーザにシステム
成長できる機会を作る実装単体テストが見えない期間


要求開発×アジャイル開発のねらい

要求開発×アジャイル開発のねらい
2つのプロセスをシーケンシャルに実行するのではなく、
反復的に同時進行することで相乗効果をあげる。

要求開発の弱点アジャイル開発の弱点
いくら机上で精緻に検証実際に動くシステムを見
してみても、実際にやってると詳細に入り込んで全
みないとわからない。体像を見失う。

“要求開発×アジャイル開発”
で双方の弱点を相互に補完



G. 要求開発とシステム開発の組合せパターン
要求開発とアジャイル開発を
同時進行することで互いの弱 1. 猪突猛進型（要求開発＋ウォーターフォール開発）
点を補い、相乗効果を得る
RD SD

RD:要求開発（Requirements Development）
SD:システム開発（System Development）

2. 足し算型（要求開発＋アジャイル開発）
SD SD SD SD SD
RD
1 2 3 4 5

「掛け算型」のシナリオが 3. 掛け算型（要求開発 × アジャイル開発）
もっとも優れている RD RD RD RD RD RD
0 1 2 3 4 5

SD SD SD SD SD
1 2 3 4 5


3. 事例紹介


事例プロジェクトのプロフィール
 業種
– 大手製造業

 プロジェクト名称
– SCMシステム構築プロジェクト

 プロジェクトスコープ
– 社内に40程度存在する事業カンパニー、ビジネスユニットの中の1事業を対象
– 財務・会計、人事・給与を除く、対象事業カンパニーの基幹業務すべて
 生産管理、生産計画、需給管理、出荷管理、代理店在庫管理、協力工場生産管理、金型管理、原
料管理、受注販売管理、予算管理、原価管理など
– 協力工場、代理店の業務についても一部システム化対象とする

 プロジェクト期間
– 約4年

 プロジェクト体制
– SCM改革チーム（専任で7名）
業務部門メンバー3名、事業部システム部門メンバー4名
– 利用部門（非専任）
必要に応じてプロジェクトに参画
– システム開発チーム(常時12名程度の規模）
情報システム部門メンバー、開発パートナー、コンサルタント

事例プロジェクトの軌跡
仮説検証フェーズ以降を1ヶ月サイクルで反復してシステムを段階的に構築・リリースした
6ヶ月 6ヶ月 12ヶ月 18ヶ月
事業部のSCMシステム全特定の製品・職場に限定全製品・職場を対象にし出荷管理、受注販売管理、
体した生産管理・計画、需給た生産全般、協力工場管金型管理、予算管理、原
管理業務理、代理店在庫管理業務料管理など残りすべての
業務

Phase 1 Phase 2 Phase 3 Phase 4
基本構想フェーズ仮説検証フェーズ量産＆移行フェーズ1 量産&移行フェーズ2
（目指す姿の策定）（基礎固め・先行試行） (職場横展開と拡張) (全業務展開)
•目標設定 •業務基盤の確立 •新しい仕組みの確立 •全業務への展開
•問題構造分析 •運営体制の確立 •新ルール運用の徹底 •最終的な効果測定
•現状分析 •基盤システムの構築 •全システム構築完了
•テーマ抽出 •モデル職場への適用 •全職場への適用
•解決策導出 •クイック・ヒット
•ロードマップ策定（人間系での試行）
•新しい仕組み作り
•新しいルール作り
•アクションプラン策定
•投資効果分析
- アジャイル開発
•リスク分析
- イテレーション
- プロセスによる経営 - 一人屋台開発方式 - 継続的プロセス改善
- 全体最適/リーン生産 - モデリング - 開発チームのスキル向上 - 生産性・品質の更なる向上
- 自社独自方法論 - フレームワーク - フレームワークの進化 - 別プロジェクトへの横展開


Phase2(仮説検証フェーズ）のイテレーション実施例
システムリリース
Ｐｈａｓｅ２
10月 11月 12月 – 1月 2月 3月
1st イテレーション 2nd イテレーション 3rd イテレーション 4th イテレーション評価期間

工程管理#1 3 工程管理#2 4
生
産リアルタイム実績収集リアルタイム実績収集リアルタイム実績収集リアルタイム実績収集
1 2 3 4
管 #1 #2 #3 #4
動くソフトウェアを
理
工程実績モニタリング#1 2工程実績モニタリング#2 3工程実績モニタリング#3 4 使ってすぐに業務プ
シロセスと情報システ
ス最も大きな懸案事項
テ工程計画#1 2 工程計画#2 3 工程計画#3 4 ムの妥当性を検証で
ム生だった現場でのリアルきることが分かると、
開産タイム実績入力の実現
発スケジューラ連携#1 2 スケジューラ連携#2 3 スケジューラ連携#3 4 最初は乗り気ではな
計可能性を開発開始1ヶ
ス画かった現場部門がプ
ケ工程実績フィードバック工程実績フィードバック
ジ月後に検証できた 3 4 ロジェクトに積極的に
ュ #1 #2
ー関与するようになって
ル需きた
給需給管理#1 2 需給管理#2 3 需給管理#3 4
管
理
現場導入教育現場二次教育
現
場マスタ作成作業実績収集＆問題点抽出 Phase 3計画作成
側各種マスタ（制約・能力など）整備
ス
ケ協力工場環境準備
ジ段取改善活動
ュ小ロット化推進
ー
ル

事例プロジェクトにおける主な効果
 ショーストッパーリスクに早期に対処できた。

 ユーザが本当に必要な機能を初期段階から真剣に考えることができた。

 当初の計画では実現し得なかった価値の高い機能を実現することができた。

 ユーザのプロジェクトへの参画意欲が飛躍的に高まった。

 早く失敗を経験することで、早く成功に近づいた。

 繰り返し学習できることで生産性が飛躍的に向上した。

 真のプロジェクトマネジメントを実施できた。

 基本構想フェーズで計画した予算・納期通りにプロジェクトを完了できた。


4. 自社で実践する上でのポイント


フェーズをきちんと分ける : アジャイルと無計画は全然違う！
基本構想仮説検証量産移行運用/保守
フェーズフェーズフェーズフェーズフェーズ

要求開発 RD0 RD1 RD2 RD3 RD4 要求
プロセス成果物

システム開発システム
SD1 SD2 SD3 SD4
プロセス成果物

ユーザ要求システム要求
ビジネス要求技術要求
要求制約品質要求
業務ルール

プロジェクトをいくつかのフェーズに分け、
それぞれの局面で必要なことに集中する。
 基本構想フェーズ：プロジェクトの全体構想を描く。
 仮説検証フェーズ：特にリスクが高い要求や重要度の高い要求を中心に動くシステムを開発して評価し、
プロジェクトの方向性を確定する。また、アーキテクチャのベースラインを整備して量
産の準備を実施する。
 量産フェーズ：プロジェクトの残りの要求を優先順位の高いものから順番に開発し、段階的に
ユーザにリリースしてフィードバックを得る。
 移行フェーズ：業務と情報システムの両方を新しい環境に全面的に移行する。
 運用/保守フェーズ：継続的に業務と情報システムの両方を進化/発展させていく。


優先順位付けを真剣に行う : 何かを取り入れたら代わりに何かを捨てる！

要求を構造化することで、要求の価値が測り易くなり、優先順位をつけやすくな
る。使われない64%の機能を見極めるためには、要求の構造化が不可欠。

Why(要求の価値）ビジネス要求

ユーザ要求
粗利率を30%に引き上げる
システム要求

品質属性
売上げを増やす原価を下げる
ビトレードオフ要求
ジ
ネ
スリピート受注を増やす廃棄ロスのコストを下げる異常処理輸送コストを下げる
要
求

納期を遵守する欠品を減らす対立製品在庫高を2割削減する

生販在計画を立案する
ユ
ー
ザ受注を記録する受注状況をリアルタイムに把握する在庫状況をリアルタイムに把握する不良の発生を迅速に把握する
要
求
出荷を記録する

シ受注入力画面受注状況確認画面在庫照会画面クレーム報告画面
ス
テ出荷計上画面
ム
要
求レスポンス3秒以内納期自動計算機能インターネット上の機密保護電子メール送信機能

How(要求の実現手段）
ULS 0
Copyright © 2011 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 19

要求を発明する:ユーザの想像を超えた付加価値を提供する
 想像できる範囲のことが実現できても、さほど嬉しくないのが人間。
 「ソリューション重視思考」が要求の発明を妨げている。
 「なぜ？」を繰り返し問うて、問題の本質を掘り起こす。
 要求の発明の例
– ユーザが語る要求（ソリューション重視思考）
 「インターネットのサプライヤーサイトを検索して、もっとも安い部品の価格を表示してほしい」

– 技術要素を排除する
 「もっとも安い部品の価格を知りたい」
 インターネット検索以外の手段へと解決策が広がってくる

– なぜ「もっとも安い部品の価格を知りたい」のか？
 「もっとも安い価格で部品を購入したい」
 相見積を取るなどのソリューションに発展できる

– なぜ「もっとも安い価格で部品を購入したい」のか？
 「もっとも安い価格で部品を入手したい」
 部品の内製などのソリューションにまで発展できる


総合力を高める : 開発プロセスの整備だけでは成功しない！

能力の高い人財、変化に強いアーキテクチャが伴わないとうまく機能しない。


変更容易なモジュール構造を実現する : データモデリングを重視する！

 アジャイル開発を実施する際には必須条件。
– アジャイル開発では、システム開発期間中に何度も繰り返しシステムを進化させていく
開発スタイルをとる。これをムダなく安全に実施するためには、変更容易なシステム構造
にしておくことが大前提となる。
 変更容易なシステムとは。
– 必要な処理(ロジック)が適切なモジュールに重複せずに配置されているシステム。
– このようなモジュール構造のシステムでは、追加・変更の影響範囲が限定されるために
、尐ない工数で安全にシステムを改修することが可能になる。
 最もシンプルで効果の高い設計原則を適用する。
– DRY（Don„t Repeat Yourself）原則。
– コードの重複をなるべく無くす。
 DDD(Domain Driven Design)
– 問題領域の概念構造になるべく忠実にデータとロジックを配置することで変更に強い構
造にする設計手法（プロセスは変化しやすいが、データは変化しづらい）
– 要求開発×アジャイル開発でデータモデリングを非常に重視するのは、ビジネスの本質
的な理解をアプリケーションの実装にきちんとつなげることで、短いサイクルで機能の追
加・変更要求に容易に対応できるようにするため。

人財を育成する : 要求開発力を高める!

1. ファシリテーションの力

2. 目的を明確にする力

3. 要求を構造化する力

4. 要求を発明する力

5. 優先順位付けの力

6. 本質を可視化する（モデリング）力

7. チームを学習させ継続的に成長させる力


最後に
 全てのシステムをアジャイルで開発するという考えは捨てる。
– アジャイルが向いている領域
 要件に不確定な要素が多く、尐しずつ確かめながら仕様を決めないとリスクが高い領域
 SCMやCRMなど
– ウォーターフォールが向いている領域
 要件に不確定な要素が尐なく、最初に仕様を正しく決めることが可能な領域
 会計、給与計算など

– システム化対象領域やプロジェクトの特性に応じてウォーターフォールとアジャイルをバ
ランス良く組み合わせて適用することを考えた方が良い。
 やれない理由を考えているうちはやめといた方が無難。
– アジャイル開発ができない理由
 経験がない
 ユーザや上司の理解や協力が得られない
 ユーザの変更要求を積極的に受け入れるなんてとんでもない
 段階的リリースなんて非現実的
 スキルに自信がない
 社内規定に合わない
 請負契約で外部に全面委託している etc…
– やりたい理由を積極的に見つけて、できる範囲から開始してみる勇気が必要。


要求開発×アジャイル開発のポイント

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie 要求開発×アジャイル開発のポイント

Ähnlich wie 要求開発×アジャイル開発のポイント (20)

Mehr von ESM SEC

Mehr von ESM SEC (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (12)

要求開発×アジャイル開発のポイント