エンタープライズアジャイル勉強会 201604 河野

ULS Powered byCopyright © 2016 UL Systems, Inc. All rights reserved. Proprietary & Confidential
エンタープライズアジャイル勉強会 2016年4月セミナー
エンタープライズアジャイルで成功するために必要なこと
ウルシステムズ河野正幸

Copyright © 2016 UL Systems, Inc. All rights reserved. Powered by
エンタープライズアジャイル
 企業の基幹系業務システムの開発にアジャイル手法を
適用すること
– 私はそういう意味でこの用語をとらえている
– 最近あまり勉強していないのでトレンドはよくわかってない
– ただ2003年頃から13年にわたり基幹系業務システムをアジ
ャイルアプローチで開発してきた経験は豊富にある(UPなど
反復型開発の実践経験はもっと長い)
 本日は私の経験からエンタープライズアジャイルで成功す
るために必要だと思われることをお話ししたい
– 成功に必要な9つのポイントをお話しする
– ぜひ皆さんのご意見も聞きたい。どうすればうまくいくかを教
えて欲しい

私のアジャイル経験(1)
 A社(2003年～2006年)
– 製造業、SCM領域(生産・調達・販売)
– 業務改革&M/Fシステム(20年以上稼働)の再構築
– アジャイル開発採用の動機
基本構想が実現できるかどうか「やってみないとわからない」リ
スクが大きかった
要求に不確定要素が大きかった
経営陣から早く新システムを稼働させて効果を上げることを求
められていた
– 結果
ほぼ並行して別々の事業カンパニーを対象とした2プロジェクト
を実行したが、両プロジェクトともに満足できる成果を上げること
ができた(私のアジャイル[反復型開発]経験でも最も成功した例
だといえる)

私のアジャイル経験(2)
 B社(2006年～2016年)
– 製造業、SCM領域(生産・調達・販売)、原価計算等
– 業務改革&M/Fシステム(30年以上稼働)の再構築
– アジャイル開発採用の動機
ビジネス環境の激しい変化に既存システムでの対応のスピード
が間に合わない
既存システムが巨大過ぎて一括再構築は無理。ビジネスの優
先度の高いところから部分的に刷新せざるを得ない
拠点単位に分散しているシステムをグローバルで一元化したい
。ただし最初から綺麗な構造を考えることは不可能なので、継続
的に改善・進化させていく形を取りたい
– 結果
現在までに10程度のプロジェクトをアジャイルで実行
失敗・苦労を重ねつつ少しずつ前進している最中

成功に必要なこと①
 なぜ自社でアジャイル開発に取り組む必要があるのか
という理由が明確に腹落ちしていること
– プロジェクトのキーマンがアジャイル開発に取り組む根拠を明
確に理解している場合は成功する確率が高い
– 根拠があいまいだったり、納得感を得られていない場合はた
いていうまくいかない
– 導入を支援した経験からするとここはかなり苦労する
A社さんは最初から根拠が明確だったのでスムーズにいった
B社さんはプロジェクト毎に腹落ち度合いがまちまち。数年かけ
て社内に実績を作っていく中でようやく積極採用派が増えてきた
。まだまだ苦戦中
ただし、B社さんはビジネスの要求をIT部門が満たすための手
段を真剣に追求した結果、必然的にアジャイルしかないという結
論にたどりついた(次頁)

成功に必要なこと②
 システムライフサイクルモデルを見直す
初期開発 (維持のための)保守＝コピペ継ぎ足し
初期開発 (継続的改善のための)保守＝再設計
サービスイン
サービスイン
提供価値
提供価値
従来型のシステム・ライフサイクル・モデル
アジャイル型のシステム・ライフサイクル・モデル
時間を掛けて完璧な姿で大きく産むことに注力するが、徐々に退化していく
開発に十分に時間とコストを掛けて最初からフルセットの完璧なシステムをリリースするが、徐々に陳腐化する
保守はビジネスイベントに合わせて実施するが、大きな変化には次回の再構築でしか対応できない
時間を掛けずに不完全でも良いから小さく産み、徐々に進化させて大きく・長く育てる
必要十分なものを開発したらすぐにサービスインして利用者に素早く価値を提供する
保守を十分な体制で実施し、要求の変化に対応しながら継続的に価値を高めて長く利用する
次システム
廃棄
変化への適応を重視しないため価値
の陳腐化が速く短期間で使えなくなる
要求の変化への適応を重視するので
価値を向上・維持しながら長く使える
廃棄

成功に必要なこと②
 ライフサイクルモデルを変えることは以下も変えていくと
いうこと
– 予算(新規開発重視から保守重視へ)
– 開発体制(外注から内製へ)
– 契約形態(一括請負から準委任契約へ)
– システムアーキテクチャ(一枚岩から部品組み合わせ型へ)
– 優秀な人財の確保(短期スポット調達から長期継続・育成へ)
– ROIの評価(短期評価から長期評価へ)
etc…
 これはＩＴ部門の文化を変えるに等しい。なかなかハードル
は高いがここを変えていかないと何も変わらない
– ディケイド(10年間)で見るとB社さんは大きく変わられている

成功に必要なこと③
 ウォーターフォールよりもさらに高度なマネジメントが必
要だということを肝に銘じて採用すること
– 正直言って優秀なPMじゃないと成功しない
(それってウォーターフォールでも同じだが…)
– 優秀なPMがウォーターフォールの限界を超えるために採用
する高度な手法だと思っている
– ウォーターフォールもまともに実行できないPMが手を出すべ
きじゃない(厳しすぎる?)
– 身も蓋もない言い方だが「優秀な人が集まれば成功する」
 ここを勘違いしている(マネジメントが苦手な)人も多い
– 「ウォーターフォールより軽量なので簡単なんじゃない？」
– 「規律は緩くて良いんだよね？」
– こんな考えだとエンタープライズアジャイルでは確実に失敗す
る(アジャイルこそ規律が必要)

成功に必要なこと④
 成功にもっとも必要なものは千里眼
– 基幹系業務システムに失敗は許されない。常に先を見通して
ゴールを確実に達成できる力(千里眼)をフルに発揮する必要
がある
– 千里眼は高い「全体構想能力」「トリアージ能力」「計画立案能
力」「リスク検知能力」を備えることではじめて有効に機能する
 全体構想能力
– 「先が見通せないからこそアジャイルでやるんじゃないの？」
– 最初にきちんと構想を練ろうと言うと必ずこういう意見が出てく
る。でも「構想なきアジャイルには未来はない」
– 「アジャイルの本質は農耕型」(B社IT本部長さんの言葉)

 トリアージ能力
– 納期・予算内で全てをやることは無理。ある意味要求は際限
なく存在する
– 「やる価値があるもの」と「やる必要がないもの」を選別できな
いとビジネスの要求を満たすことが難しい
– 適切なスコープマネジメントを実施するためにはトリアージ能
力が不可欠。その前提としてセットで「全体構想力」が重要
 計画立案能力
– アジャイルの方がウォーターフォールに比べて計画立案を重
視する(世間には誤解している人も多いが)
– 最初の計画に固執するウォーターフォールに対して、短サイク
ルで計画ゲームを繰り返し実施するアジャイルの方が計画立
案能力が求められるのは自明

 リスク検知能力
– リスク感度が鈍いとアジャイルをやる価値が激減する
– リスクをなるべく早く見極めて手を打てるのがアジャイルの良
いところだが、それが機能しないとメリットが感じられない
– 将来のリスクを常に予測し細かく計画を見直しながら回避す
る能力が不可欠
– 心配性なくらいに多くのリスクを想定し、その回避・解消シナリ
オをオプションとして複数持っておけば、いざリスクが発現して
も慌てないで対処できる

 私が経験したダメな例
– 早い時期に固い機能を開発し、慣れてきたころに柔らかい機
能を開発する計画を立てる(IID[Iterative & Incremental
Development]のメカニズムを理解していない)
– 計画ゲームを全く実施していない、もしくは実施しているが全
体計画(リリース計画)を全く見直さない
– 現スプリントと次スプリントくらいしか見通していない。半年後
、1年後、5年後を見通したマネジメントを全く行っていない
– スコープの見直しを行っていない。見直したくても優先順位が
付けられないので結局全部引き受ける羽目になって納期が
遅延する
– リスクに対する見通しが甘く、あまりにも楽観的に考えている
。いざ問題・課題が頻出して遅れ始めてから慌てて考えても
既に手遅れで立て直すことができず、納期がずるずると遅延
する

13
成功に必要なこと④：要求の欠陥のコスト
要求の欠陥の修正が遅れれば遅れるほどやり直し作業が増えてコストが増大する
（テストフェーズで約70～80倍、保守フェーズでは140倍以上)
開発コスト全体に占めるやり直しのコストは30～50%にのぼる
(Barry Boehm and Philip N. Papaccio, 1998)
要求の欠陥はやり直しのコストの70～85%を占める
(Dean Leffingwell, 1997)
全欠陥の60%は要求定義や分析の段階で作られたものである
(Jerry Weinberg, 1997)

成功に必要なこと⑤
 期限を切って意思決定する
– 経験上、プロジェクトの遅れの最大の原因は意思決定の遅れ
であることが多い
– プロジェクト計画時に重要事項の意思決定の期限を明確に切
って、そのタイミングで必ず意思決定することが重要
– アジャイルは不確定要素が多い状況で適用することが多いが
、それは意思決定が難しいことを意味する。意思決定プロセ
スと期限がきちんとコントロールしないとずるずると遅れる可
能性が高い
 決められない人、決めたくない人
– そもそも意思決定者が決まっていないケースも多い
– 意思決定の責務を持っているにも関わらず決められない人、
決めたくない人にいかに決めてもらうかが鍵を握る
– リーンの「意思決定を遅らせろ」を誤解している人も多い

成功に必要なこと⑥
 計画にバッファを持たせる
– 最初からバッファの無い計画でアジャイルを実行するほどしん
どい事はない。可能な限りバッファを持たせるべき
– バッファを持たせ過ぎると「パーキンソンの法則」が発動して
生産性が悪化するリスクがある。妥当なバッファを妥当なタイ
ミングで挿入するのがPMの腕の見せ所
 バッファを顧客が認めてくれるか？
– 生産管理やプロジェクト管理に理解のある顧客は妥当なバッ
ファなら認めてくれることが多い
– 「バッファ＝代金の上乗せ」だと解釈される場合は困難。スコ
ープ調整が可能な状況なら最悪機能を落とすことで対処
– 要求を最初からあまり選別せず玉石混淆でスコープに入れて
おくと、石がバッファとして機能する(A社事例での学び)

成功に必要なこと⑦
 当たり前のことをちゃんとやる
– 優秀な人でもアジャイルに惑わされて当たり前のことができな
くなることがある(浮足だってしまう)
要求開発→設計→実装という手順でしかシステムは開発できな
い。ところが、焦って実装をして後から大きな手戻りを繰り返すと
いう泥沼にはまる
機能の開発だけでなく、環境準備・基盤（アーキテクチャ)整備・
運用設計・データ移行などシステム稼働までにやるタスクは山
ほどあるのだが欠落する
どんな仕事でもマネジメントは必要。形骸化、儀式化はムダなの
で削除すべきだが、必要なことまで省略してしまう
– 「当たり前のこととは何か？」を始める前にちゃんと確認しよう

成功に必要なこと⑧
 おかしいと思ったらすぐ止まる
– おかしいと思っていても止められない
止めてしまうと進捗が大きく遅れるというプレッシャーに負けて惰
性で進んで問題を修復不能にしてしまう
– 勇気を持って止めて、根本から手を打つ
一度立ち止まり、問題の原因を根本から解決するよう対策を講
じる。それには勇気が必要
この時点で既に進捗は大きく遅れている。ここで当初の計画に
いくら固執してもリカバリは難しい。ゴールを達成するための最
良のシナリオを考えて思い切って計画を見直す。これを実施す
るにはポイント④に述べた「千里眼」が不可欠
基本的にはスプリント、イテレーションといったタイムボックスの
切れ目が止まるチャンス。にもかかわらず止められずに惰性で
突き進むのが失敗パターン

2014年の要求開発アライアンスでの所感
 エンタープライズアジャイルは難しい
– 難しいからこそチャレンジする価値がある。他社と差別化する
ためのコアコンピタンスとなり得る
– そもそも扱う問題が超難しい。パッケージを適用したり、ウォ
ーターフォールで開発することで十分対処できる問題はそうす
れば良い。それでは対処できないからアジャイルを適用する
訳で難しくて当たり前
– だから誰でもできるものではない。できる人を選ぶものだと考えてい
る。TPS(トヨタ生産方式)を多くのメーカーが模倣しようとしているが
できない。難しい。それと同じようなものだと思う。
– 要求開発も、もしかするとそういうものかもしれない。誰もが簡単に
価値と質の高い要求を開発できるようになったら、差別化ができな
い

2014年の要求開発アライアンスでの所感
 個々の要素はシンプルかつ普遍的なもの
– エンタープライズアジャイルは総合的に見ると難しいものでは
あるが、それを構成する個々の要素はシンプルかつ普遍的な
もので成り立っている
– ソフトウエア工学やプロジェクトマネジメントの原理・原則に忠
実に仕事をできる人であれば実行できる。基本動作をきちん
とできるように鍛錬することが重要
– 難しいのはプロジェクトの環境・状況や先の見通しを踏まえて
、それらをどうアレンジして問題を解決するかという部分。千
里眼を持って基本的なプラクティスをうまくアレンジして使いこ
なせる人がエンタープライズアジャイルを制することができる
ように思う
 残念ながら今の私（河野）はその域には全然達していま
せん。まだまだ精進が足りません

成功に必要なこと⑨：その後追加したこと
 システム開発は難しい、だったら簡単にすればいい
– うまくいかないのは結局開発側の問題、ビジネス側ではない
約30年のシステム開発屋の経験を経て、苦労しているのはほと
んど開発側の問題だということを痛感している
ビジネス価値を創造することがアジャイル採用の本質的な目的
のはずだが、開発で四苦八苦してそこに辿りつく前に力尽きて
いる
開発をもっと簡単にできないか？そうしたらもっと広く普及する
– 開発者のためではなく、ビジネスピープルのためのアジャイル
ビジネスを設計する人が短サイクルでTry&Errorを繰り返しな
がら最適解を導ける。これがエンタープライズアジャイルが本質
的に目指す価値ではないか？
「超高速開発」という言葉は胡散臭くて大嫌いだが、ビジネスを
知っている人がアプリケーションを簡単に作る環境を提供するこ
とで現状をブレークスルーするしかないと考えている

エンタープライズアジャイル勉強会 201604 河野

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to エンタープライズアジャイル勉強会 201604 河野

Similar to エンタープライズアジャイル勉強会 201604 河野 (20)

エンタープライズアジャイル勉強会 201604 河野