Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

アジャイルの障害

1,067 views

Published on

presentation on 2013-05-16 @PMI-Japan

Published in: Technology
  • Be the first to comment

アジャイルの障害

  1. 1. アジャイルの障害 関口匡稔Image by: (CC)foxypar4 http://www.flickr.com/photos/foxypar4/1004464889/
  2. 2. 発表のテーマ• 金融システム開発を例にとって、アジャイルに合っていない現状のおさらいをします。(たぶん皆さんご存じのことばかりです)• そんなお堅い業界にも変化の兆しが!• どうやって行くのがいいんでしょう?(ディスカッション)
  3. 3. アジャイルの障害 - 金融システムを例にとって
  4. 4. 金融ソフトウェア開発宣言個人と対話よりもプロセスとツールを、動くソフトウェアより包括的なドキュメントを、顧客との協調よりも契約交渉を、変化への対応よりも計画に従うことを、価値とする。すなわち、左記のことがらに価値があることを認めても、私たちは右記のことがらにより価値をおく。※冗談です
  5. 5. プロセス&ツール• 伝統のWaterFallプロセス• 業務自体がWaterFallである - e.g. 稟議書• 個人で仕事をしない。部・課単位で仕事をする• 確立された「プロセス資産」• ツール - スケジューリング技法• PERT , Critical path , Crashing , Fast-TrackingImage by: (CC)robbieredball http://www.flickr.com/photos/robbieredball/4419791542/
  6. 6. 包括的なドキュメント• プロジェクトライフサイクルを網羅するドキュメントの数々• プロジェクト計画書、WBS、ビジネスケース、RFI、RFP• 要件定義書、基本設計書、詳細設計書、テスト計画書、移行計画書、etc.• アーキテクチャ基準書、IF定義書、DB定義書、メッセージ定義書、etc.• 変更依頼書、QA票、障害票、(週次・月次)進 報告書、etc.• 資産管理台帳、入館申請、個人情報保護承諾書、情報セキュリティテストImage by: (CC)alex_ford http://www.flickr.com/photos/alex_ford/4121621598/
  7. 7. 契約交渉• 委任と請負• 委任契約 - 成果物の規定がない。善管注意義務• 請負契約 - 成果物の規定あり。瑕疵担保責任• 基本契約、個別契約、発注書、請書、覚書• 下請法と偽装請負Image by: (CC)nobmouse http://www.flickr.com/photos/nobmouse/4052848608/
  8. 8. 計画に従うこと• 開発プロジェクトは、開発だけではない• 他システムとの連携、ハードの発注、ユーザー教育、etc.• 効果測定があまりなされていない - 良い物よりも、完成を優先• 遅延を認めないチキンレース• そしてデスマーチへImage by: (CC)the national guard http://www.flickr.com/photos/thenationalguard/6883650776/
  9. 9. 変化の兆し
  10. 10. 素早い開発の必要性• Time to marketの短縮• システム予算から部門予算へ• 「早い(速い)者勝ち」の世界• 技術の進歩が早すぎるImage by: (CC)steve.gamer32 http://www.flickr.com/photos/22032337@N02/7427822420/
  11. 11. 複雑化するシステム• 複数部門にまたがる業務• マルチレイヤーシステム• マルチベンダー• ころころ変わる環境• 予測不可能なプロジェクト
  12. 12. 多重下請の減少• 情報漏洩の問題、統制の問題• ノウハウの流出阻止• 内製化 - ユーザー部門エンジニアの地位向上• オフショア - 下請からプライムへImage by: (CC)zeevveez http://www.flickr.com/photos/zeevveez/6026050882/
  13. 13. PMの役割の変化• プロジェクトマネージャ不要論• 御用聞きはいらない• ファシリテーションの重要性• “ベンダー”のプロジェクトマネージャーの価値とは
  14. 14. アジャイルの導入
  15. 15. 二つの進め方• 草食系(ローリスクローリターン)• 表向きにアジャイルというのはやめる• Give & Take / 「貸し借り」の原則• 肉食系(ハイリスクハイリターン)• まず既存のやり方を全否定• 荒野となったところで新手法導入
  16. 16. アジャイル導入の障害 - 人• 一番変化を拒むのは人• ボトムアップでもダメ - 「それ誰の承認があってやってるんだっけ?」• トップダウンでもダメ - 「現場のこと分かってないですね」• 無視したらもちろんダメ - 「断りもなく勝手に進めてもらってもね」• 何もしなくてももちろんダメ - 「指示待ちになってもらっては困る」• ぶつかりながら進むしかない!!
  17. 17. アジャイル導入の要 - 人• 規定の成果物を作りつつ、アジャイルプラクティスを取り入れる• 最重要: 透明性。隠し事をしない。素早いフィードバック• 成果物に「物」は書かないが、物を作って顧客に提供• 並行本番などで使ってもらいつつ改良• 成果物は最終イテレーションでガッっと作る• ステークホルダーマネージメントが重要なスキル
  18. 18. 成功の要因は一緒• ベストを尽くせる関係が大事• ビジョン、ミッション• コミットメント• フェアネス、透明性• プロセスも人の作ったもの。がんじがらめではない。大抵のことはステークホルダーを巻き込めば解決できる。• 現場で汗をかかないと、現場では信用されない。(日本の場合)
  19. 19. 不思議な現象• ある程度規律の厳しい環境の方が、アジャイルプラクティスを導入しやすい• ルール慣れしている?• 連携体制がしっかりしている。コミュニケーション重要• 経験の浅いエンジニアのみの環境や、規律の緩い環境では、アジャイルプラクティスの導入が難しい• そもそもプラクティスにならない• 自律性に乏しい。「自由な」コミュニケーションって実は難しい?

×