presentation on 2013-05-16 @PMI-Japan

1. アジャイルの障害 関口匡稔
Image by: (CC)foxypar4 http://www.flickr.com/photos/foxypar4/1004464889/

2. 発表のテーマ
• 金融システム開発を例にとって、アジャイルに合っていない現状のおさらいを
します。（たぶん皆さんご存じのことばかりです）
• そんなお堅い業界にも変化の兆しが！
• どうやって行くのがいいんでしょう？（ディスカッション）

3. アジャイルの障害 - 金融システムを例にとって

4. 金融ソフトウェア開発宣言
個人と対話よりもプロセスとツールを、
動くソフトウェアより包括的なドキュメントを、
顧客との協調よりも契約交渉を、
変化への対応よりも計画に従うことを、
価値とする。すなわち、左記のことがらに価値が
あることを認めても、私たちは右記のことがらに
より価値をおく。
※冗談です

5. プロセス＆ツール
• 伝統のWaterFallプロセス
• 業務自体がWaterFallである - e.g. 稟議書
• 個人で仕事をしない。部・課単位で仕事をする
• 確立された「プロセス資産」
• ツール - スケジューリング技法
• PERT , Critical path , Crashing , Fast-Tracking
Image by: (CC)robbieredball http://www.flickr.com/photos/robbieredball/4419791542/

6. 包括的なドキュメント
• プロジェクトライフサイクルを網羅するドキュメントの数々
• プロジェクト計画書、WBS、ビジネスケース、RFI、RFP
• 要件定義書、基本設計書、詳細設計書、テスト計画書、移行計画書、etc.
• アーキテクチャ基準書、IF定義書、DB定義書、メッセージ定義書、etc.
• 変更依頼書、QA票、障害票、（週次・月次）進 報告書、etc.
• 資産管理台帳、入館申請、個人情報保護承諾書、情報セキュリティテスト
Image by: (CC)alex_ford http://www.flickr.com/photos/alex_ford/4121621598/

7. 契約交渉
• 委任と請負
• 委任契約 - 成果物の規定がない。善管注意義務
• 請負契約 - 成果物の規定あり。瑕疵担保責任
• 基本契約、個別契約、発注書、請書、覚書
• 下請法と偽装請負
Image by: (CC)nobmouse http://www.flickr.com/photos/nobmouse/4052848608/

8. 計画に従うこと
• 開発プロジェクトは、開発だけではない
• 他システムとの連携、ハードの発注、ユーザー教育、etc.
• 効果測定があまりなされていない - 良い物よりも、完成を優先
• 遅延を認めないチキンレース
• そしてデスマーチへ
Image by: (CC)the national guard http://www.flickr.com/photos/thenationalguard/6883650776/

9. 変化の兆し

10. 素早い開発の必要性
• Time to marketの短縮
• システム予算から部門予算へ
• 「早い（速い）者勝ち」の世界
• 技術の進歩が早すぎる
Image by: (CC)steve.gamer32 http://www.flickr.com/photos/22032337@N02/7427822420/

11. 複雑化するシステム
• 複数部門にまたがる業務
• マルチレイヤーシステム
• マルチベンダー
• ころころ変わる環境
• 予測不可能なプロジェクト

12. 多重下請の減少
• 情報漏洩の問題、統制の問題
• ノウハウの流出阻止
• 内製化 - ユーザー部門エンジニ
アの地位向上
• オフショア - 下請からプライム
へ
Image by: (CC)zeevveez http://www.flickr.com/photos/zeevveez/6026050882/

13. PMの役割の変化
• プロジェクトマネージャ不要論
• 御用聞きはいらない
• ファシリテーションの重要性
• “ベンダー”のプロジェクトマネ
ージャーの価値とは

14. アジャイルの導入

15. 二つの進め方
• 草食系（ローリスクローリターン）
• 表向きにアジャイルというのはやめる
• Give & Take / 「貸し借り」の原則
• 肉食系（ハイリスクハイリターン）
• まず既存のやり方を全否定
• 荒野となったところで新手法導入

16. アジャイル導入の障害 - 人
• 一番変化を拒むのは人
• ボトムアップでもダメ - 「それ誰の承認があってやってるんだっけ？」
• トップダウンでもダメ - 「現場のこと分かってないですね」
• 無視したらもちろんダメ - 「断りもなく勝手に進めてもらってもね」
• 何もしなくてももちろんダメ - 「指示待ちになってもらっては困る」
• ぶつかりながら進むしかない！！

17. アジャイル導入の要 - 人
• 規定の成果物を作りつつ、アジャイルプラクティスを取り入れる
• 最重要： 透明性。隠し事をしない。素早いフィードバック
• 成果物に「物」は書かないが、物を作って顧客に提供
• 並行本番などで使ってもらいつつ改良
• 成果物は最終イテレーションでガッっと作る
• ステークホルダーマネージメントが重要なスキル

18. 成功の要因は一緒
• ベストを尽くせる関係が大事
• ビジョン、ミッション
• コミットメント
• フェアネス、透明性
• プロセスも人の作ったもの。がんじがらめではない。大抵のことはステーク
ホルダーを巻き込めば解決できる。
• 現場で汗をかかないと、現場では信用されない。（日本の場合）

19. 不思議な現象
• ある程度規律の厳しい環境の方が、アジャイルプラクティスを導入しやすい
• ルール慣れしている？
• 連携体制がしっかりしている。コミュニケーション重要
• 経験の浅いエンジニアのみの環境や、規律の緩い環境では、アジャイルプラク
ティスの導入が難しい
• そもそもプラクティスにならない
• 自律性に乏しい。「自由な」コミュニケーションって実は難しい？