デブサミ2012「仕事のバトン、渡っていますか？」

仕事のバトン、渡っていますか？
プロジェクト管理における
コミュニケーション基盤作り

鈴木雄介
【17-C-2】グロースエクスパートナー
ズ（株）

Developers Summit 2012

GxPのご紹介

 グロースエクスパートナーズ株式会社
 2008年に創業
 SI案件（90％プライム）、自社プロダクト
/Sサービス開発、Webサイト制作
 アトラシアン製品のエキスパート（販売代
理店）

http://www.gxp.co.jp


アジェンダ

 PJでおきていること
 仕事のバトン
 課題管理ツール実践
 まとめ


PJで起きていること

http://www.flickr.com/photos/drift-words/10434156/

PJでおきていること

 明確なことと曖昧なことが混ざり合う
 開発方法論は関係ない
 繰り返している場合は明確なことが多い
 パッケージ適用とか

 明確なことが多い場合はウォーターフォー
ル的で、曖昧なことが多い場合はアジャイ
ル的なほうが向く

http://www.flickr.com/photos/kayaker1204/5741580592/ Summit 2012
Developers


 原則としては、
 曖昧なことは明確にする
 プロトタイピング、フロントローディング
 明確になったら計画を立てていく
 WBS（タスク、見積もり、スケジュール）
 実行する
 進捗管理、変更管理



 どんなに明確でも”不確定”なことが残る
 いつ発生するか分からないし、発生した場
合の対応も様々
 バグ、問い合わせ、仕様変更、課題、リス
クなど「新しく発見したナニカ」



 不確定さを予測する
 このぐらいバグが出るだろう
 これぐらい仕様変更が出るだろう
 「時間枠」の中で、その不確定さの幅に
収まっているか判断する
 タイムボックス型



 そこで「課題管理」が重要
 内容
 発生日
 重要度・影響度
 担当者
 期限
 状態
 どう管理するのがよいか？


 EXCEL最強
 自由にカスタマイズできる
 項目変更だけじゃなくて、マクロやバリデー
ションも可能
 分析機能（フィルタ、ピボットなど）も強力
 多くの人のPCで共有できる
 印刷可能

 だけど、それだけでは足りない

http://www.flickr.com/photos/stewils/484903915/

仕事のバトン


仕事のバトン

 仕事は一人じゃ完結しない
 プロジェクトの構成要素が複雑で、スキル
が広範囲に及ぶ
 成果物を分解し、タスクにして、プロセス
として並べていく

10 5

20


仕事のバトン

 例：テスト工程
 バグを発見する
 修正する
 修正したものをテストサーバにデプロイす
る
 バグの修正を確認する
 修正されていなければ再度、修正…


仕事のバトン

 例：テスト工程（アクター入り）
 [テスターが]バグを発見する
 [エンジニアが]修正する
 [デプロイヤが]修正したものをテストサーバ
にデプロイする
 [テスターが]バグの修正を確認する


仕事のバトン

 例：テスト工程でありがちな問題
 エンジニア
 もう直っているよ
 ていうか、俺の担当じゃない
 テスター
 いつ直ったの？
 誰が担当したんだよ
 デプロイヤ
 どれをリリースすればいいんだよ


http://www.flickr.com/photos/53370644@N06/4975888229/

仕事のバトン

 「仕事のバトン」が渡せていない
 その課題がプロセス全体の中で、いまどこ
にいるのか
 プロセスが非同期に実行されているなかで、
全体として同期すべきイベントがある
 そして、全体としてどういう状況なのか
 EXCELだけでは足りない


課題管理ツール実践



 課題管理ツール
 個別課題のオーナーや状態を管理する
 横断的にくくるフラグを制御できる
 全体をリスト化することができる
課題発生

確認
割り当て
課題1

課題2



 適用への道のり
 まずはテスト工程（バグ管理）がお勧め
 そして、「仕事のバトン」を管理してみよ
う
 課題管理ツールを「コミュニケーション基
盤」として捉える
 チームで共有するタスクに使ってみる



 例：テスト工程（アクター入り）
 [テスターが]バグを発見する
 [エンジニアが]修正する
 [デプロイヤが]修正したものをテストサーバ
にデプロイする
 [テスターが]バグの修正を確認する


1.0に対して 1.2にて修正全体を終了
バグ発見を確認

1.0 1.2 1.2
テスター
発見 1.1がリリース確認ｸﾛｰｽﾞ
済なので1.2に
て修正予定

1.0 1.2
エンジニア
開始修正
作業開始
1.2
1.1
デプロイヤ 1.1
ﾘﾘｰｽ
ﾘﾘｰｽ
ﾘﾘｰｽ
1.2修正予定
1.1をリリーバグをリリース
ス

テストアプリ
1.0 1.1 1.2


テスターリーダーエンジニアデプロイヤ

1.0 1.0 1.0 1.0 1.0
1.0
割り当て割り当て修正 1.2 割り当て 1.2
1.0
1.1
1.1
リーダーエンジニアエンジニアデプロイヤデプロイヤ
デプロイヤ
オープンオープン進行中解決済みデプロイヤ
解決済み
解決済み
解決済み

リリース
1.0
1.0
確認依頼 1.0
1.2
1.1
1.1
テスター
デプロイヤ
デプロイヤ
解決済み
解決済み
解決済み
1.2
確認NG
エンジニア
確認OK 再オープン
凡例
1.0
1.2 影響バージョン
テスター修正バージョン
クローズ担当者
状態



 ポイント
 担当者の割り当てと状態の遷移
 バージョンの活用
 課題が発生したバージョン
 課題が修正される予定のバージョン
 そして、修正予定バージョンをリリースモード
にする



 テスト工程以外の適用箇所
 QA管理
 顧客との会話
 オフショア先やチーム間など。遠隔地に有効

 「顧客とのQA用」と「チーム内のバグ管理」を
分けるのも良い方法
 立場が違えば、見えない方が良いことある
 課題番号は引き継いでリンクさせる


全体の負荷を調整
負荷を見ながらタス
タスクを消化
クを割り当て
PM

リーダー実装者
③割り当て Subversion

課題を登録し、対応が ④コミット
決定したら転記コード
QA管理 ④完了報告
顧客メンバー JIRA タスク
①記述 ②実装指示
課題 ⑤タグ設定
実装管理 ⑤バージョン設定
①記述
JIRA
課題番号設計者デプロイヤ
⑥バグ報告完了タスクをバージョ
課題タイトル
⑤リリースンにくくり、以下を実
内容施する
⑥テスト 1.ソースコードの場
ジョン付与
検討履歴テスタアプリ 2.該当バージョンのア
検討履歴アプリのバージョンをプリをリリース
検討履歴元にしてバグを報告

QAも課題と同じように
JIRAで管理


課題管理ツールのコツ



 管理のコツ
 起票のルールを決める
 気遣い重要。例えば言葉遣いは丁寧に
 事実を書く（いわゆるバグの書き方を参照）
 プロセスを決める
 誰がクローズするのかが一番重要



 運用のコツ
 初期はメンバーの教育も必要なので、
チェッカーの運用が大事
 抱えがちな人には棚卸しを定期的に促す
 リーダーが状況を把握するのに使う
 複数プロジェクトで使う場合は事務局が重
要



 応用編
 品質管理
 いわゆるバーンダウン
チャート
 コンポーネントや独自
フィールド（バグの原因な
ど）を利用した分析



 注意点
 計画タスクへの適用は難易度が高い
 いわゆるチケット駆動。チケットを発行して回
るぐらいアーキテクチャとプロセスが安定して
いる必要がある
 チケット駆動にしたからといってプロセスが安
定するわけではない
 「計画はされているが曖昧なタスク」になりが
ち
 運用・改善フェーズは良い



 コミュニケーションツールとして考える
 あくまでもチーム内でのコミュニケーショ
ンツールとして考える
 仕事のバトンを渡すことに注力
 「個人のタスクはいれさせない」などの
ルールもあり
 個人PCで課題管理すればいい



 アンチパターン
 計画に使おうとする
 計画的なものはEXCELやMS-Projectのほうが便利
 前後関係や工数など時間軸が見にくくなる
 ワークフローやフィールドを設定しすぎる
 入力や管理が大変になってしまって逆効果
 タスクを階層化しすぎる
 子供タスクは使いすぎない
 複数のコミュニケーションツールを併用する
 メールや電話での内容も登録する


まとめ

http://www.flickr.com/photos/ddyates/3367008166/

まとめ

 そもそも「時間管理」は重要
 WBSなき課題管理ツールは失敗する
 ルーチン化した状態（＝運用）でもOK
 時間枠の中で不確定なことを管理する
 いつ発生するかも分からず、どう対応する
かも様々


まとめ

 使ってみるならバグとQAから
 運用フェーズもオススメ
 管理は少しづつ複雑にしていく

 「仕事のバトンを渡す」ことを意識して、
コミュニケーション基盤として活用する
 例：課題番号を長く使う


仕事のバトン、渡っていますか？
プロジェクト管理における
コミュニケーション基盤作り

鈴木雄介
【17-A-2】グロースエクスパートナー
ズ（株）


デブサミ2012「仕事のバトン、渡っていますか？」

More Related Content

Viewers also liked

Similar to デブサミ2012「仕事のバトン、渡っていますか？」

More from Yusuke Suzuki

デブサミ2012「仕事のバトン、渡っていますか？」