Agile development

© 2019 Core Concept Technologies Inc.© 2019 Core Concept Technologies Inc.© 2020 Core Concept Technologies Inc.
アジャイル導入について
株式会社コアコンセプト・テクノロジー
DXD 安宅彰一朗
2020年11月12日

© 2020 Core Concept Technologies Inc.
アジャイル導入について CONFIDENTIAL
はじめに
アジャイルの手法はわかった。
ていうかそんなに難しいことは言ってない。
でも導入がうまくいかんのですよ、ってことです。
なんでなん？って話です。
※社内開発で導入するのは簡単なので置いときます。
どんどんやってください。（運用が簡単だとは言ってない）

目次
1. 現状整理
2. 根本的な課題
3. ウォーターフォールに向くもの向かないもの
4. ベンダー企業としてのビジネスレンジ
5. 導入において
1. 共通認識
2. 重要キーパーソン
3. 契約モデル

前回のおさらい
「ソフトウェア開発手法について、CICDの基礎から学んでみた」
「BizDevOpsについて」

アジャイルと言っていますが
その他の反復開発も含みます。
（プロトタイピング、スパイラル etc…）
というよりWFだって企業レベルでみれば反復開発です。
「システムリプレース」という名でイテレーション回してるじゃないですか
1周10年ぐらいというだけです…
要はこれが2週間なのか10年なのかという違いです。
（10年だともはや知見者誰もいないですが…）
「色々古すぎてリプレース」案件ですかね
（階段をどれだけ登ってるかはわかりませんが…）
水平に見えてミクロでは変わっています。
日々のメンテナンスとかで

現状整理（ユーザ企業あるある）
* コストを掛けたわりにビジネス課題を解決していない
* こんな歴史
* Phase1
* システム化したいな
* ざっくりした要件でベンダーに発注
* 出来上がったシステムがなんか微妙
* Phase2
* 対策を考える → 要件定義ちゃんとせな！
* 要件定義にすごい時間が掛かる
* 沢山考えたけどやっぱり穴はある
* 机上で完璧に設計するなんて人類には無理なんや…
* ていうか正解なんて分からないですし…
* その間にもビジネス環境は変わってる
* 出来上がったものはやっぱり微妙
* Phase3
* アジャイルとかDXって流行ってるやん。なんか良さそうやん ← 今ここ

現状整理（ベンダー企業あるある）
* スケジュール、コスト、スコープが決まってる
* 要は「いつまでに、いくらで、なにやる」が決まってる（All Fix）
* 仕様変更には消極的、超保守的
* 仕様変更は↑を守れなくなる可能性がある → ハイリスク
* それでシステムが良くなったとして別に儲からない → ノーリターン
* 仕様変更に対応するインセンティブがまるでない
* 追加でお金払ってねという要求はユーザ企業との関係を悪化させる
* だから決まってることしかやらない、仕様変更とかなるべくやらない
* ユーザ企業、ベンダー企業間で「言った言わない論争」になりがち
* そうならない様に沢山ドキュメント作る → ドキュメント地獄
* しかも作成コストが見積もりに乗って高いとか言われる
→ 誰も得していない

根本的な課題
「なんかうまくいかないな…」の根本原因は
「システム開発の不確実性を吸収できていない」ことです。
システム開発の不確実性とは
1. なにを作るか：ビジネス的不確実性
2. どう作るか：技術的不確実性

根本的な課題
2は開発ベンダーが見積もりにバッファを積むことである程度吸収しています。
（ここが色々固定された契約のためバッファが過大という問題は別途あります）
1はユーザ企業が負うべき不確実性ですが、
負っているという意識がない場合があります。
というより「システムを作ること」が目的になっていることが多々あります。
目的は「ビジネスを最大化すること」であって
「システムを作ること」はあくまで手段です。
そして1の正しさを測定するためには
「使ってみないと分からない」という性質があります。
システム開発の最大のリスクは
「時間とお金を掛けて作ったシステムがたいして役に立たないこと」
です。

アジャイルやれば全部解決？
そんなことはありません。
システム開発に銀の弾丸なんてありません。
ぶっちゃけシステム開発がうまくいかない理由は開発手法関係ないです。
主な原因は「要件定義ができてない」ためです。
要するに「システムで何を実現するべきかきちんと決められない」からであり、
開発手法でどれを選んだところで失敗するものは失敗します。
それがWFの「後戻りできない特性」とコンボが成立すると詰みます。
※要件定義は今回のスコープじゃないので以下参照
IPA「ユーザのための要件定義ガイド」

アジャイルやれば全部解決？
そうは言っても、今どきのシステム開発は複雑化しすぎていて、
「全ての要件定義を完璧にやることが難しい」という事情もあります。
つまり現実的に考えて
「大きなチャレンジ。失敗したら即死」より
「小さなチャレンジ。失敗しても転ぶだけ」のほうが良くないですか？
というのが「WF以外」の考え方です。
※実際のWFでは炎上しつつ半死ぐらいまで持っていって、
使えなくもないけど微妙、あたりに着地させることが多いです。
※なんでWFまだいるの？というのは以下がわかりやすいです。2009年…
@IT「なぜウォーターフォール開発は捨てられないのか」

ウォーターフォールに向くもの向かないもの
どんなものにも向き不向きがあります。
向かないものに導入しても全員不幸になるのでやめましょう。
「WFに向くもの向かないもの」を整理します。
「WFに向かないものはWF以外で開発するべき」です。
【WFに向くもの】
• システムの要件定義が完璧にできる（ビジネス的不確実性が低い）
• 技術的難易度が高くない（技術的不確実性が低い）
• 全機能が揃っていないと価値がない（法律、税制関係だとあるかも）
を全部満たすものです、満たさないなら「それ以外」です。
※ベンダー企業のビジネスが成り立つかどうかとは違います。
「向いてない開発手法で炎上しつつ微妙な着地」というビジネスもありえる。
ビジネスが成り立つがゆえに日本のITといえばSIビジネスになってしまう。

ユーザ企業ベンダー企業の目指すべき姿
ユーザ企業は、クラウド、モバイル、AI、アジャイル開発、DevOps 等の新たなデジタル
技術や方法を最大限生かすためには、自社のリソースの充実に加え、他社とのパートナーシ
ップを強化していくことが必要となる。
これに対し、ベンダー企業においては、変化の速いデジタル技術にキャッチアップするこ
とによりユーザ企業に価値を提供することの重要性が今まで以上に高まっていく。この際、
ユーザ企業はそれに対して価値を正当に評価する、といった関係を構築していくことが必
要である。
その上で、ユーザ企業がビジネス上の価値向上につなげることができれば、プロフィット
シェアもなされるといった Win-Win の関係を構築することが期待される。
国のレポートってちゃんとしてますよね。
もちろんあなた達実践してるんですよね？とか悲しみが深いので聞いてはいけない…
要は以下です。
ユーザ企業：ビジネス特化
ベンダー企業：技術特化
経済産業省「DXレポート」 3.4 ユーザ企業・ベンダー企業の目指すべき姿と双方の新たな関係

ベンダー企業としてのビジネスレンジ
技術的チャレンジ
ビジネス的チャレンジ
Techベンチャー
レガシー企業
モード１のDX(≒守りのIT) モード２のDX(≒攻めのIT）
現状のビジネス環境のスピード感を考えると
内製一択なのですが、それ言ってしまうと
DX事業部要らんやん？
みたいな話になるので必要ですよ、という話
をします。
・システム化
・合理化
・コスト削減
こんな感じになりたいと
ユーザ企業は思っている
ビジネス特性によって
こちらを目指すかもしれない
・ビッグデータ
・AI
・IoT
・DevOps

Techベンチャー
レガシー企業
WF以外向い
てる
WF向いてる
システム開発向
いてない
ざっくり言うと

Techベンチャー
レガシー企業
アジャイル向いてる
システム開発向いてない
投資対効果が低い。
このエリアは大体要件定義がおかしいことが
多いので下エリアにシフトさせる。
（夢いっぱい、無茶なこと言ってる、
論理的に不整合、使うかどうか分からない
機能いっぱいある etc..）
WF向いてる
ここあたりをターゲットにしたい、要は
・従来WFで受注し開発していた
・だいたい炎上しがち
・「思ってたのと違う」問題
★魚をあげるのではなく、釣り方を教える
★当事者意識を持ってもらう
ハイリスクハイリターン
ジョイントベンチャーが推奨されている。
ユーザ企業とベンダー企業の関係が強すぎる。

落ち着いて考えてみる
ということで何はなくても「アジャイル開発だ」となる前に
立ち止まって考えてみることは大切です。
まずビジネス特性に合っているかということですね。
• F1マシンでラリーに出ようとしてません？（適材適所）
• 草野球の助っ人にメジャーリーガー呼んでません？（オーバースペック）
例えば「動くものを見ないとイメージが沸かない」というだけであれば、
他の反復開発（プロトタイピングやスパイラル）でも良いかもしれません。
どう違うのかについては諸説ありますが、、、
外形的な違いは「正式リリースが複数 or 1回」ということですかね。
結局のところアジャイルを選択する目的は以下に集約します。
• 市場に早期に投入したいのか
• 市場から学びを得たいのか

誰からフィードバックを得たいのか、それが問題です。
まだ見ぬ誰か
社内
開発部
担当者
開発チーム
ユーザ企業、ベンダー企業という垣根を超
えてスクラムチームを形成します。
誰からのフィードバックを得たいのか

ただ、どの開発手法を選んだところで根本問題をなんとかしないと
結局うまくいかないわけです。
根本問題とは「ビジネス的不確実性」のことで、
システムを欲している人が「どんなシステムを欲しいのか分からない」であり
要するに「動くもの見てみないと良いか悪いか分からんよね」問題です。
そしてベンダー側としてはスケジュール、コスト、スコープ
All Fixで契約してしまうと仕様変更受けられないじゃないですか。
「作るものも未確定なのに請負で契約してる」という部分が契約上の問題です。
結局これ以下の二択で、前者は難易度が高いのであれば後者しかないわけです。
「要件定義完璧にできる前提で請負」、「スコープ可変で準委任」
※今回は「アジャイル導入について」なのでアジャイル選んだ体で続きます

アジャイルってどんなの？
まず関係者（ユーザ企業、ベンダー企業全員）でアジャイルって何？
という認識合わせましょう。
IPAの「アジャイル開発進め方の指針」がコンパクトにまとまっています。
※実際読むところはそんなにないです。
ユーザ企業側に押さえておいてほしいポイントは以下
P2 ：アジャイル開発のスコープと体制について（前提）
P5 ：アジャイル開発の概要
P8-10 ：ざっとユーザ企業側のやること
P15-16：プロダクトオーナーのやること
※とにかく言葉を統一しないと意思疎通がとれません

重要キーパーソン
* プロダクトオーナー（PO）
実務レイヤーの最重要人物
※ここの人選を間違えると終わります。
* 後ろ盾となる人
役員、もしくは本部長レベルのかなり上位レイヤーの理解者
アジャイル開発はアジリティが生命線です。
大企業特有の内部統制とマッチしない部分もあるかもしれません。
その場合、POといった立場では変えられない場合があります。
例：内部統制でドキュメントや稟議フローが色々決まってる。
→必要に応じてキャンセルできる「適切な権限委譲」が必要です。
ユーザ企業の内部構造をドラスティックに変更するのが本筋ですが…
まあ大抵無理なので特区みたいな形で治外法権エリアを作ってしまう形ですかね。
通称「出島戦略」

ステークホルダー
（利害関係者）
スクラムチーム
重要キーパーソン
プロダクトに対する責任を持つ。
この人が従来的な「御用聞き」だと何も決まらないで詰みます。
意見を聞いたとしても何をやるかを決定するのはPOです。
※ユーザ企業から選出要はこの人です
スクラム全体がうまく回ることに責任を持つ。
※ベンダー企業から選出
※ユーザ企業、ベンダー企業どちらからでもよいが
そもそも外注している時点でベンダー企業の比率が高いはず。
ここは責任上対立する場合もあるので
兼任出来ない。
企業間のパワーバランスが崩れるので
スクラムマスターはベンダーから選ぶ
社内
社外
スクラムマスター
開発者
プロダクト
オーナー

最重要人物：プロダクトオーナー
もはやプロジェクトがうまく行くかどうかは
「ユーザ企業から適切なプロダクトオーナーを選出できるか」次第です。
• ステークホルダーとの調整
• プロダクトがどうあるべきかを決める
→プロダクトバックログ（≒やりたいことリスト）を作成する。
アジャイルの特性上「やりたいこと全てはできない」ため
必然的に「やらないことを決める」ということになります。

最重要人物：プロダクトオーナー
従来のベンダーを使ったシステム開発とは全く異なる開発になるため、
プロダクトオーナーはユーザ企業において変革を主導する人になります。
では、どのような人物がふさわしいのか？
及川卓也著「ソフトウェアファースト」によると
「エイリアンとミュータントを登用する」とあります。
エイリアンとは「我々」です。（外部からの侵略者）
ミュータントとはその企業の中での突然変異種「変わり者」です。
ざっと向いている特徴を箇条書きすると
• 従来のやり方を変えていくモチベーションがある
• そもそも論で考えられる → 良い意味で空気が読めない
• 決断が早い（※何も考えていないわけではない）
この「変わり者」が縦横無尽に活躍するためにも「後ろ盾となる人」が必要です

中間のまとめ
ここまでの「アジャイル導入について」をまとめると
1. ビジネス(≒システム)がアジャイルに向いているか
2. 適切なプロダクトオーナーを選出できるか
3. そのプロダクトオーナーに適切な権限移譲ができるか
ということです。
アジャイル開発する覚悟は良いですか？
では先に進みましょう。

契約モデル
アジャイル開発で行くと決めました。
では契約モデルはどうするの？という話です。
経済産業省「DXレポート」3.4.4 ユーザ企業とベンダー企業間における契約
では以下が記載されています。
• ＜パターン A＞内製モデル
• ＜パターン B＞基本/個別契約モデル
• ＜パターン C＞ジョイント・ベンチャーモデル
というか、もはやB一択です。
Aは契約ですらないですね、自社で作るってことなんで…
Cは「ユーザ企業とベンダー企業が一蓮托生」モデルなので、アグレッシブです。
※このレポートは2018年9月公開で、まだIPAの
アジャイル開発版「情報システム・モデル取引・契約書」がないときのもの

契約モデル
そして2020年3月にIPAから
アジャイル開発版「情報システム・モデル取引・契約書」
が公開されました。
とりあえず解説付きPDFなので詳しくはWebでということなのですが、要約すると
• 第１条：目的と契約形態を明記。「準委任契約」
• 第２条：開発方式を明記。メジャーな「スクラム」
• 第３条：体制を明記。
• 第４条：ユーザ企業の義務。超大事。（※あとで取り上げます）
• 第５条：ベンダー企業の義務。はいがんばります。
• 第６～８条：企業間の契約に関するエトセトラ。飛ばします。
• 第９条：ドキュメント作成は「バックログに加える」
ドキュメンテーションにはコストがかかるので「明確に確保」する。
POが「開発する代わりにドキュメントを作る」と決定するということ。
• 第１０～２５条：一般的なので飛ばします。
（著作権の辺りとかは専門家の人に見てほしい気はする）

プロダクトオーナーの責務
3. 甲は、プロダクトオーナーに次の役割を担わせる。なお、プロダクトオーナーの行為（不作為も含
む。）に関する責任は全て甲が負う。
① スクラムチームに対して開発対象プロダクトのビジョンや意義を示し、開発対象プロダクトの価
値を最大化するよう努めること
② プロダクトバックログの作成及び優先順位の変更を行うこと
③ 別紙第 5 項記載の会議体のうち、出席を要するものに出席すること
④ 開発対象プロダクト（開発途中のものも含む。）に対するステークホルダー（開発対象プロダク
トの利用者、出資者等の利害関係者）からのフィードバックを提供すること
⑤ 開発対象プロダクトの完成確認及びプロダクトバックログに含まれる個々の要求事項の完了確認
を行うこと
⑥ 本件業務を遂行するために乙が必要とする情報提供及び意思決定を適時に行うこと
⑦ 本件業務が円滑に遂行されるよう、ステークホルダーとの調整を行うこと
IPA「アジャイル開発外部委託モデル契約」第４条より抜粋
（※甲はユーザ企業を表します）
要は契約によりプロダクトオーナーの責務を
明確に規定しているということですが…

プロダクトオーナーの責務
3. 甲は、プロダクトオーナーに次の役割を担わせる。なお、プロダクトオーナーの行為（不作為も含
む。）に関する責任は全て甲が負う。
① スクラムチームに対して開発対象プロダクトのビジョンや意義を示し、開発対象プロダクトの価
値を最大化するよう努めること
② プロダクトバックログの作成及び優先順位の変更を行うこと
③ 別紙第 5 項記載の会議体のうち、出席を要するものに出席すること
④ 開発対象プロダクト（開発途中のものも含む。）に対するステークホルダー（開発対象プロダク
トの利用者、出資者等の利害関係者）からのフィードバックを提供すること
⑤ 開発対象プロダクトの完成確認及びプロダクトバックログに含まれる個々の要求事項の完了確認
を行うこと
⑥ 本件業務を遂行するために乙が必要とする情報提供及び意思決定を適時に行うこと
⑦ 本件業務が円滑に遂行されるよう、ステークホルダーとの調整を行うこと
IPA「アジャイル開発外部委託モデル契約」第４条より抜粋
（※甲はユーザ企業を表します）
それWFでもユーザ企業側が
やるべきことちゃうの？
（という声がどこかから聞こえました）

合意事項
契約書はとても大切なものですが、関係者が全員読むわけではないので
最低限の関係者間の合意事項を示します。
1. 何を優先し何を優先しないのか
アジャイル開発としての原理原則です。迷ったら立ち返るところ。
要は「アジャイルソフトウェア開発宣言」です
2. チームの権限と責務
今まで散々出てきたことなので省略しますが、どちらかというと
ユーザ企業側の意識や体制への影響が大きいので
「あなた達にその覚悟はありますか？」ということです。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

参考資料
• 経済産業省：DXレポート
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_repor
t.html
• IPA ：ユーザのための要件定義ガイド」
https://www.ipa.go.jp/ikc/publish/tn19-002.html
• IPA ：アジャイル開発版「情報システム・モデル取引・契約書」
https://www.ipa.go.jp/ikc/reports/20200331_1.html
• 及川卓也：ソフトウェアファースト
https://www.nikkeibp.co.jp/atclpubmkt/book/19/P89910/

Agile development

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Agile development