Agile Japan 2010

1. Agile Japan 2010
事例セッション5
変化を受け入れるアジャイルな
プロジェクトマネジメントと現場
＜ツール・環境篇＞
グロースエクスパートナーズ（株）
ビジネスプラットフォーム事業ゼネラルマネージャー/チーフITアーキテクト
日本Javaユーザー会/日本Springユーザー会幹事
アークランプ（http://www.arclamp.jp/）
鈴木雄介

2. 自己紹介
• 鈴木雄介
– 所属
• グロースエクスパートナーズ（株）
– ビジネスプラットフォーム事業ゼネラルマ
ネージャー/チーフITアーキテクト
– コミュニティ
• 日本Javaユーザー会 幹事
• 日本Springユーザー会 幹事
– ブログ/記事/書籍など
• アークランプ
（http://www.arclamp.jp）
• 「ソフトアーキテクトが知るべき97のこ
と」監修
• 「拡張する空間」

3. http://gxp.co.jp

4. 今日のテーマ
Architecture

5. 今日のテーマ
Agile

6. ユーザー企業にとっての
標準化
http://www.flickr.com/photos/cocreatr/4440894876/

7. “ユーザー企業にとっての”
http://www.flickr.com/photos/mhartford/1285459212/

8. 従来の標準化
プロセスの標準化：
・標準プロセスの策定
・同じ手続きと同じ文書フォー
マットによって同じ品質が得
られる
内部構造の標準化：
・標準フレームワークの定義
・同じ構造によって同じ品質が
得られる

9. http://www.flickr.com/photos/sualk61/3116650631/
同じことの繰り返し、が前提

10. 企業内に同じシステムは2つない
http://www.flickr.com/photos/coral/3630575683/

11. 大規模
http://www.flickr.com/photos/digitalart/415921952/
http://www.flickr.com/photos/digitalart/1351407421/
汎用
特殊
http://www.flickr.com/photos/digitalart/3721459363/
http://www.flickr.com/photos/digitalart/3654905233/ 小規模

12. パッケージ
カスタマイズ
スクラッチ
パッケージ
＋ベンダー
自社開発

13. コントロール
重要
リーダシップ
調整重要
重要
試行錯誤
重要

14. http://www.flickr.com/photos/melissambwilkins/2352107323/
開発から保守運用まで

15. 同じモノがないなら
同じコトをしても
同じ品質にはならない

16. “環境”の標準化
“概念”の標準化
“視点”の標準化
http://www.flickr.com/photos/flatbushgardener/261202276/

17. コトそのものではなく、
コトの外側を標準化する

18. 例：開発プラットフォーム
• IDE（Eclipse＋プラグイン）
• 構成管理（Maven2）
• 継続的インテグレーション（Hudson）
• 課題管理（JIRA）
• ドキュメント管理（Confluence）
• バージョン管理（Subversion）
• デプロイ管理
http://www.flickr.com/photos/kamoda/295893828/

19. 事務局重要。

20. 事務局超重要。

21. 大事なことなので2回(ry

22. – 実施計画
• 経営課題として定義
– 導入サポート
• 説明会、ドキュメント
• カスタマイズ、使い方支
援
– 各種申請の受付
• ユーザー新規登録
• 古い情報の削除
– 効果測定
• 定量的な活性度の測定
• インタビューの実施
– 改善支援
• ノウハウの展開
http://www.flickr.com/photos/stejahen/1326013625/

23. アセスメント性の向上
ツールであればプロジェクト外
部からの評価や査定を簡易化で
きる。システムを多様な視点で
評価することでプロジェクトリ
スクを引き下げる。

24. プロセス品質の適正化
AプロジェクトのプロセスがBプ
ロジェクトでも有効とは限らな
い。ツールが同じだけならプロ
セスは品質とコストのバランス
で調整可能

25. 要員流動性の向上
ツールが同じであれば毎回の学
習コストを抑えられる。要員調
整力の向上。さらに人と共にノ
ウハウが移転していく。

26. 個別最適から全体最適
「うちのプロジェクトは特別」
という意識の排除。特別な部分
も大事だけど、共有化するメ
リットを理解する

27. デモ開発プロセス
JIRA+SVN+Maven2
次Ver登録 新機能
アサイン 実装
アサイン タグ打ち デプロイ テスト
※バグ有
V1.1
[JIRA] V1.1 オープン 作業中 解決済 クローズ 再オープン
1.1
[Subversion]

28. 応用例
・バージョン番号やバグ番号のトレーサビリティ
（現場～内部統制）
・JIRAに「バグの種類」の項目を足して、品質監
査の基礎資料に
・Hudsonのソースコードメトリクス、SVNのコ
ミット数などでアクティビティ診断
・Confluenceで環境構築手順（インストール、
設定各種）や運用手順書を記述
・JIRAで問い合わせ管理、仕様管理
※サーバ＋全ソフトで50万円（25ユーザー）、そ
の価値は間違いなくある。

29. まとめ1/3
アジャイルは開発方法論に縛ら
れた議論ではダメ。ノウハウは
様々な視点で活用可能。“ユー
ザーの” 現場で考える

30. まとめ2/3
言うだけでできる人は少ない。
環境を用意して傾向性を与える
ことで自然にやってもらえる。
誰も無理しないのが一番大事。

31. まとめ3/3
でも、環境だけじゃダメで結局
は人。事務局が本当に大事。上
にも下にも、あきらめずに働き
かけて、常に改善していく。

32. 最後に
標準化って新しい仕事のスタイ
ルを考えるってコト。実はクリ
エイティブな仕事なんだよ！

33. Agile Japan 2010
事例セッション5
変化を受け入れるアジャイルな
プロジェクトマネジメントと現場
＜ツール・環境篇＞
グロースエクスパートナーズ（株）
ビジネスプラットフォーム事業ゼネラルマネージャー/チーフITアーキテクト
日本Javaユーザー会/日本Springユーザー会幹事
アークランプ（http://www.arclamp.jp/）
鈴木雄介