JIRAを使ったフツウのPJ実践
グロースエクスパートナーズ株式会社
ビジネスソリューション事業本部 本部長
鈴木雄介
GxPのご紹介
• グロースエクスパートナーズ株式会社
– 2008年に創業
– SI案件(90%プライム)、自社プロダクト/S
サービス開発、Webサイト制作
2
http://www.gxp.co.jp
アジェンダ
• 「フツウのPJ」とは
• マネジメントアプローチ
• JIRA
• まとめ
3
「フツウのPJ」とは
• ウォーターフォール vs アジャイル
– ウォーターフォール開発
• プロセス主導型
– 対象の構造と構成が明確でプロセスが定義できる。予定
と実績の誤差を管理し、効率を高める
– WBS、調整
– アジャイル開発
• リスク主導型
– 対象の構造も構成も曖昧で不確定要素が多い。タイム
ボックスで棚卸しをして最適化していく
– イテレーション、プロトタイピング
4
規模
「フツウのPJ」とは
5
確定度
マネジメントレス
(気合い)
アジャイル的
ウォーターフォール的
フツウのPJ
5人
10人
20人
「フツウのPJ」とは
• 適切な開発手法を使い分ける
– プロジェクトの中には明確なことと不確定が
混ざり合う
– 明確なことはウォーターフォール的に、不確
定なことはアジャイル的に
• 明確なことはプロセス主導、不確定なことはリス
ク主導
– 新規ソフトウェア開発では、どちらかに寄る
ことは難しい
• パッケージのカスタマイズは内部構造が確定的な
のでウォーターフォールに近づく
6
マネジメントアプローチ
• PMBOK
– 統合管理
– スコープ管理
– 時間管理(スケジュール管理)
– コスト管理
– 品質管理
– 人的資源管理
– コミュニケーション管理
– リスク管理
– 調達管理
7
マネジメントアプローチ
• PMBOK
– 統合管理
• 計画プロセス、遂行プロセス、コントロールプロ
セス
8
要求
要望
作るモノ
成果物
と
タスク
プロセス
遂行とコントロール
(実績把握 > 差分抽出 > 課題認識 > 調整)
計画
マネジメントアプローチ
• PMBOK
– 統合管理
– スコープ管理
– 時間管理(スケジュール管理)
– コスト管理
– 品質管理
– 人的資源管理
– コミュニケーション管理
– リスク管理
– 調達管理
9
マネジメントアプローチ
• 計画立案(時間視点)
– スケジュールの作成
• 「全体」を「部分」に分割
• 「部分」を成果物とするタスクを定義する
• タスクの順番を整合させる
• タスクの工数を見積もる
– 対象物が明確な範囲で可能
10
10 5
20
スコープ管理(WBS) 時間管理(スケジュール)
マネジメントアプローチ
• 計画から予定できないタスクもある
– いつ発生するか分からないし、発生した場合
の対応も様々
• バグ、問い合わせ、課題、リスクなど「新しく発
見されたナニカ」すべて
– 発生してから、それが計画内なのか計画外な
のか判断をするしかない
– だから、「時間枠」は計画しておき、発生し
たナニカの棚卸する
• タイムボックス型
• でも、どうやって??
11
JIRA
• JIRAとは
– 課題管理ツール
• 個別課題に対して発生時間や説明を付ける
• 個別課題のオーナーや状態を管理する
• 全体をリスト化、グラフ化することができる
12
課題1
課題2
課題発生
割り当て
確認
JIRA
• 推奨適用箇所
– テスト工程でのバグ管理
• ほとんどのプロジェクトで適用可能
• テストのフェーズでJIRAプロジェクトを分けても
いい
• 可能であればコードコミット、リリースまで一元
管理まで一元的に。
– 設計~実装工程での「顧客と設計者」「設計
者と実装者」のQA管理
• 遠隔地でコントロールを行う場合に有効
• コミュニケーション相手によって複数を使い分け
るのがオススメ
13
JIRA
• 記載ルール
– 記述内容
• 「現象」と「依頼」と「予想」を分けて記載
• 「現象」には環境、証拠、再現方法などを記載
• 言葉遣いは丁寧に…
• いわゆる「バグの書き方」と同じ
– プロセス
• 誰がクローズするのかが一番重要
– メンバーの教育も必要なので、初期段階では
チェッカーの運用が大事
• 抱えがちな人には棚卸しを定期的に促す
14
実装管理
JIRA
JIRA
15
御社メンバー
設計者
課題
タスク
テスタ
実装者
デプロイヤ
③割り当て
リーダー
④完了報告
⑤バージョン設定
アプリ
⑤リリース
⑥テスト
②実装指示
⑥バグ報告
コード
⑤タグ設定
④コミット
Subversion
QA管理
JIRA
課題タイトル
内容
検討履歴
検討履歴
検討履歴
課題番号
完了タスクをバージョ
ンにくくり、以下を実
施する
1.ソースコードの場
ジョン付与
2.該当バージョンのア
プリをリリースアプリのバージョンを
元にしてバグを報告
①記述
課題を登録し、対応が
決定したら転記
負荷を見ながらタス
クを割り当て
タスクを消化
PM
全体の負荷を調整
QAも課題と同じように
JIRAで管理
※コミュニケーション管理計画として提出
①記述
JIRA
• 運用段階での適用
– 運用段階では計画が「ルーチン化された時間
枠」として存在する
• アジャイルの適用事例の多くが改善フェーズ
– コミュニケーションツールとして機能する
• 「問い合わせ」で必ず課題を作ってもらう
– 電話を使った場合でも必ずやってもらう
• 問い合わせが見積もり依頼や課題などになってい
く
• 月一でサマリ報告と棚卸
– 日常はJIRAで視覚化されている
16
JIRA
• 応用編
– 品質分析.原因、現象、工程などを選択式で登
録し、分析を行う
17
JIRA
• アンチパターン
– 計画的なタスクに使おうとする
• 計画的なものはEXCELやMS-Projectのほうが便利
• 前後関係や工数など時間軸が見にくくなる
– WFやフィールドを設定しすぎる
• 入力や管理が大変になってしまって逆効果
– タスクを階層化しすぎる
• 子供タスクは使いすぎない
– 複数のコミュニケーションツールを使う
• メールや電話での内容も登録する
18
まとめ
• 時間管理は重要
– WBSなきJIRAは失敗する
– ルーチン化した状態(=運用)でもOK
• 計画できないタスクを管理する
– いつ発生するかも分からず、どう対応するか
も様々
• 使ってみるならバグとQAから
– 運用フェーズもオススメ
– 管理は少しづつ複雑にしていく
– 課題番号をずっと使う工夫をする
19

JIRAを使ったフツウのPJ実践