Agile Japan 2010

事例セッション5

変化を受け入れるアジャイルなプロジェクトマネジメントと現場＜ツール・環境篇＞

グロースエクスパートナーズ（株）ビジネスプラットフォーム事業ゼネラルマネージャー/チーフITアーキテクト

日本Javaユーザー会/日本Springユーザー会幹事

アークランプ（http://www.arclamp.jp/）

鈴木雄介

自己紹介

• 鈴木雄介– 所属

• グロースエクスパートナーズ（株）– ビジネスプラットフォーム事業ゼネラルマ

ネージャー/チーフITアーキテクト

– コミュニティ• 日本Javaユーザー会 幹事• 日本Springユーザー会 幹事

– ブログ/記事/書籍など• アークランプ

（http://www.arclamp.jp）• 「ソフトアーキテクトが知るべき97のこ

と」監修• 「拡張する空間」

http://gxp.co.jp

今日のテーマ

Architecture

今日のテーマ

Agile

標準化

http://www.flickr.com/photos/cocreatr/4440894876/

ユーザー企業にとっての

“ユーザー企業にとっての”

http://www.flickr.com/photos/mhartford/1285459212/

プロセスの標準化：・標準プロセスの策定・同じ手続きと同じ文書フォーマットによって同じ品質が得られる

内部構造の標準化：・標準フレームワークの定義・同じ構造によって同じ品質が得られる

従来の標準化

同じことの繰り返し、が前提

http://www.flickr.com/photos/sualk61/3116650631/

企業内に同じシステムは2つない

http://www.flickr.com/photos/coral/3630575683/

大規模

汎用

特殊

小規模

http://www.flickr.com/photos/digitalart/1351407421/

http://www.flickr.com/photos/digitalart/415921952/

http://www.flickr.com/photos/digitalart/3721459363/

http://www.flickr.com/photos/digitalart/3654905233/

パッケージスクラッチ＋ベンダー

自社開発

パッケージカスタマイズ

調整重要リーダシップ

重要

試行錯誤重要

コントロール重要

http://www.flickr.com/photos/melissambwilkins/2352107323/

開発から保守運用まで

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

“環境”の標準化“概念”の標準化“視点”の標準化

http://www.flickr.com/photos/flatbushgardener/261202276/

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

例：開発プラットフォーム

• IDE（Eclipse＋プラグイン）

• 構成管理（Maven2）

• 継続的インテグレーション（Hudson）

• 課題管理（JIRA）

• ドキュメント管理（Confluence）

• バージョン管理（Subversion）

• デプロイ管理

http://www.flickr.com/photos/kamoda/295893828/

事務局重要。

事務局超重要。

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

– 実施計画• 経営課題として定義

– 導入サポート• 説明会、ドキュメント• カスタマイズ、使い方支援

– 各種申請の受付• ユーザー新規登録• 古い情報の削除

– 効果測定• 定量的な活性度の測定• インタビューの実施

– 改善支援• ノウハウの展開

http://www.flickr.com/photos/stejahen/1326013625/

アセスメント性の向上

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

プロセス品質の適正化

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

要員流動性の向上

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

個別最適から全体最適

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

[Subversion]

[JIRA]

新機能

アサイン

作業中オープン

実装

解決済

アサイン デプロイ

V1.1

タグ打ち

1.1

次Ver登録

V1.1

テスト

クローズ 再オープン

※バグ有

デモ開発プロセスJIRA+SVN+Maven2

応用例

・バージョン番号やバグ番号のトレーサビリティ（現場～内部統制）

・JIRAに「バグの種類」の項目を足して、品質監査の基礎資料に

・Hudsonのソースコードメトリクス、SVNのコミット数などでアクティビティ診断

・Confluenceで環境構築手順（インストール、設定各種）や運用手順書を記述

・JIRAで問い合わせ管理、仕様管理

※サーバ＋全ソフトで50万円（25ユーザー）、その価値は間違いなくある。

まとめ1/3

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

まとめ2/3

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

まとめ3/3

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

最後に

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

Agile Japan 2010

事例セッション5

変化を受け入れるアジャイルなプロジェクトマネジメントと現場＜ツール・環境篇＞

グロースエクスパートナーズ（株）ビジネスプラットフォーム事業ゼネラルマネージャー/チーフITアーキテクト

日本Javaユーザー会/日本Springユーザー会幹事

アークランプ（http://www.arclamp.jp/）

鈴木雄介