チケット駆動で加速する顧客と協業するプロジェクトマネジメント

Copyright© Growth xPartners, Inc. All rights reserved.

チケット駆動で加速する、顧客と協業する

プロジェクトマネジメント

2013/8/24

SIの現場で使えるチケット駆動開発


自己紹介

• 鈴木雄介

–グロースエクスパートナーズ株式会社

–日本Javaユーザーグループ会長

–日本Springユーザーグループ幹事

– id:arclamp / tw:yusuke_arclamp

1


自己紹介

• グロースエクスパートナーズ株式会社

–社員数：95名

–主戦場：SI（ほとんどプライム）

–顧客：医療機器、百貨店、住設機器など

–技術：Java、.Netなど

2


自己紹介

• GxPはアトラシアンエキスパートです

–自分たちで使っているうちに、これは便利だから皆も使うべきだと思いはじめました

–使ったノウハウを提供します！

3

♡


アジェンダ

• プロジェクトマネジメントとは

• イマドキのプロジェクト運営

• チケットの適用

• チケット駆動のツール

• 顧客と協業する

• まとめ

4


プロジェクトマネジメントとは

5




–相互に関連するタスクから構成され、多くの組織が参画して実施される3年以下程度の期間の活動

» NASA

–独自の成果物、またはサービスを創出するための期限のある活動

» プロジェクトマネジメント協会

6



• PMBOK

–PMBOKは、国際的に標準とされているプロジェクトマネジメントの知識体系（ガイド、手法、メソドロジー、ベストプラクティス）であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供する

–伝統的な手法の整理としてはきちんとしている

–通称：ウォーターフォール

7



• PMBOK

–5つのプロセスグループ

8

スコープ定義

ｽｹｼﾞｭｰﾙ作成

コスト積算

PJ計画策定

PJ計画実施

進捗報告変更管理

計画プロセス

遂行プロセスコントロールプロセス

終結

立ち上げ

ﾘｽｸ管理計画

品質計画

ｺﾐｭﾆｹｰｼｮﾝ計画

調達計画



• PMBOK

–9つのナレッジエリア

» 統合管理

» スコープ管理

» 時間管理（スケジュール管理）

» コスト管理

» 品質管理

» 人的資源管理

» コミュニケーション管理

» リスク管理

» 調達管理

9



• PMBOK

10

立ち上げ計画遂行コントロール終結

統合計画策定計画実行統合変更管理

スコープ（目的と範囲）

立ち上げスコープ計画/定義スコープ検証/変更管理

時間（期間）アクティビティ定義/順序設定/期間見積スケジュール作成

スケジュールコントロール

コスト（予算）資源管理コストの見積/予算化

コストコントロール

品質品質計画品質保証品質管理

人的資源組織計画要員調達

チーム育成

コミュニケーション

コミュニケーション計画情報配布実行報告完了手続き

リスクリスク・マネジメント計画リスク識別定性的/定量的リスク分析

リスクの監視・コントロール

調達調達/引合計画引合発注先選定契約管理

契約完了

計画実行調整



• 重要なポイント

–プロセスは「計画して、実行しつつ調整する」

» アジャイルであっても同じ。このサイクルを、どのぐらいの期間で、何回するかが違う

–まず「計画と実行の差を把握する」ことが大事

» PMBOKは「計画と実行の差を把握する」ための知識群

–その差から「問題を予測」し「調整」を行う

–こうすることでプロジェクトを正しい状態に導く

» プロジェクトマネジメントの本質

11


イマドキのプロジェクト運営

12



• 現場レベルで起きていること

–ステークホルダーの多様化

–短納期＆ Time is Money

–システム連携の増加

–新しい技術の登場が加速

• プロジェクトの不確実性が高い

13



• ウォーターフォールがダメな理由

–計画における問題が起きやすい

» スコープ管理と時間管理の計画ブレが大きい

» 成果物のブレ（顧客認識との乖離）が大きい

» 複雑で不確定なことが分からない

» それなのに時間が無いから計画精度を上げられない

–だから、実行時に想定以上の調整が必要になって破綻する

14


15

調整幅が分からないなら計画を小さくすればいいじゃない。バカじゃないの。

マリー・アントワネット（ヴィジェ＝ルブラン画）


• アジャイルの考え方

–調整が不要なぐらい計画を小さくする

–そして、計画の期限が来るまで調整しない

–期限が来たら「再計画」によって調整を行う

» ＝タイムボックス

» 「できるまでやる」は悪


16



• ウォーターフォールでうまくやる

–計画の中で調整幅を想定できていればいい

–空のバケツを用意する

» PMのポケットマネー

» 分からないことが明確であれば、プロトタイピングなどでフィードバックを得ればいいだけ

–同じドメインを何度も繰り返している場合はありえる

» ドメインエキスパートなエンジニアがいるパッケージの導入

17



• ウォーターフォールのメリット

–全体最適化されているから効率が良い

» 実は短納期にできる

–各工程で品質検証をするので品質が段階的に高められる

• 事前にちゃんと計画することのメリットは軽視してはいけない

–ある程度のことが分かっているなら計画からはじめることも良い

18



• アジャイルの危険性

–「計画しても意味がない」ではない

–結果的に無駄になることが多い場合

» 不可逆的な要素のリスク判明が遅い

▸ 要員配置やアーキテクチャ設計が代表的

▸ だから、優秀なエンジニアの勘と経験に頼ることになる

» ステークホルダーからのフィードバックが実装までない

▸ だから、オンサイトカスタマー

–とはいえ、分からないことを無理に計画するよりはまし、ということも言える

19



• ようはアプローチの違い

–ウォーターフォール

» 分かっていることが多いから、そこから始めて段階的に調整していく

–アジャイル

» 分からないことが多いから、実績を積み上げて段階的に分かっていく

• そのプロジェクトにあったものを選ぶべし

–分からないことは成果を作ってフィードバックを得る、という部分は一緒です

20



21

確定したこと

不確定なこと

ウォーターフォールのアプローチ

アジャイルのアプローチ

だいたいこの辺スタートですよね

プロジェクトのゴール

プロジェクトのスタート



• 不確実性が増しているのは確か

–状況に応じた戦略としてマネジメント手法を選択すればよいだけ

–ただ、どんな場合でも分からないことは出てくるので、それを管理する必要がある

22

そんなときにチケットですよ！


チケットの適用

23


BTS


• チケットの使いどころ » 別名：タスク、課題、イシュー、インシデント

–基本的には「よく分からない場面」で使う

» 「やってみた結果、段々分かってきたコト」をチケットとして登録する

» で、そのチケットを管理するのがBTS（バグ管理ツール）

24

よく分からない



• チケットの使いどころ

–予定を立てるのがトップダウンだとすると、チケットはボトムアップのアプローチ

–全知全能のリーダーがいるならチケットは不要

–チームで問題を解決することに最適

–注意：プロセスとは直接は関係ありません。

» ウォーターフォールであれ、アジャイルであれ、分からないことはチケットで管理する

25



• チケットの管理

–チケットは、元々がよく分からないところから出てきたのでお互いに関係もないし、数も多い

• だから、

–タグを付ける

» ステータス、担当者、期限、優先度…

–コミュニケーションの基点にする

» コメント、写真

–トレースする

» そして、変化を忘れない

26



• ウォーターフォールとチケット

–空のバケツ（＝調整幅）がBTS

» テストや要件定義で「このぐらいの作業が発生するはず」を読みますよね

–PMはバケツがあふれないように注視する

» チケットは見積もりをして、全体量を把握する

» 爆弾を抱えていないか定期的に棚卸をする。

–だから、WBS/ガントチャートと組み合わせて使うのが吉

» 予定できることはWBSで。予定できないことは「調整幅」として記載。中身はBTS

27



• 余談：EXCELじゃだめなんですか

–EXCELが良いと思う場面もある

» 数が少ないなら

▸ 個人的にはアクティブ30個、トータル100個まで

» 曖昧で粒も大きい

» リスク管理表とかはいいと思うよ

» ようは全体を見渡せるなら良い

–ただし、管理者を決めて窓口を明確に

» みんなで変更するのはやめましょう

28



• チケット適用の進め方

–王道は「バグ管理」

» テストは「成果物にフィードバックを得る」ということ

▸ いわゆるテストだけではなくて、受け入れテストも含む

» BTSというぐらいですし

–次は保守運用の「インシデント管理」

» 安定した土台の上で発生したこと

–似ているのは「問い合わせ管理」

» プロジェクトの立ち上げから利用可能。メール撲滅

29



• チケットを進捗管理に使うべきか？

–長期的に予定が分かっているなら使うべきではない

» WBS/ガントチャートが最強

–分かっていない予定ならば短期的に取りまとめて、タイムボックスと組み合わせて管理する

–大事なのは「チケットの積み上げが進捗として信用できる状態にあるか？」ということ

» それができないならアジャイルでもダメ

30



• BTSについているガントチャートは何？

–ガントチャートはタスク同士の前後関係を管理

» 計画段階で整合性を確認できる

» 実行段階で調整の影響確認できる

–BTSのガントチャートはビューワーなので、確認できても、その場で変更ができない

» 個別のタスクで変更すると前後関係が見えにくい

–ウォーターフォールなら使うべきではない

» EXCELの方がまし

» MS プロジェクトは使いこなすと便利

31



• ビューワーとしてはカンバン最強

–一度に見る量は限定的で、束にして見れる

32


チケット駆動とツール

33



• チケット駆動とは

–「チケットなしのコミットは禁止」

» まちゅさん “チケット駆動開発 … ITpro Challenge のライトニングトーク (4)”

–個人的な解釈はチケットを中心にプロセスを創発する取り組み

» プロセスの型は決めてあっても、具体的な形は事後的に現れる

» タスクの軌跡が事後的に表れる

34

http://www.machu.jp/diary/20070907.html












35

事例とかは、このあとの阪井さんの講演で！

http://sakaba.cocolog-nifty.com/sakaba/2013/08/tidd-gxptech-cd.html

[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない #gxptech

※講演後のブログエントリを追記










• チケット駆動とツール

–BTSは重要ですが、VCSやCIと組み合わせるのが吉

» ユーザーのフィードバックはデプロイしてから得られる

» チケットの発生からフィードバックまでをトレースする

–でも、RedmineにGitやJenkinsを組み合わせていくとかってレベル高いんでしょ？

• 奥さん、そこで、ですよ！

36



37

課題ソースコードモジュール実行環境

v1 済 ☑タスクA ☑タスクB

v2 未 ☑タスクC □タスクD

残 □タスクE □タスクF □タスクG □タスクH

v1

v2.b2

v1

v2.b1

v2.b2

☑タスクA ☑タスクB

☑タスクC

本番

受入T

開発

検証

v2.b1



• バージョン一覧

38

※課題管理ツール側では、未来も含めてバージョン一覧を確認できる



• バージョンサマリ

39

※課題管理ツール側では、あるバージョンに含まれている課題の確認が出来る



• デプロイプロジェクト-リリース一覧

40

※CIツール側では、それぞれのバージョンが、現時点でどの環境にいつデプロイされたのかが確認できる



• デプロイプロジェクト-リリースサマリ

41

※CIツール側でも、それぞれのバージョンに含まれる課題へのリンクを見ることができる


顧客と協業する

42



• なんのためのプロジェクトマネジメントなのか

–良いものを作りたいんですよね

–アジャイルは、それ自体が目的になりがち

–チケット駆動も目的にしちゃダメ

• 顧客のやりたいことを適切なコストで実現する

–分かることが多いよね：ウォーターフォール

» 大規模だと調整幅が大きくできるから、こっちが有利

–分からないことだらけだね：アジャイル

43



• ソフトウェア品質モデル

44

影響を与える

依存する

JISX0129-1 ソフトウェア製品の品質第１部品質モデル

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質



• ソフトウェア品質モデル

45

特徴例

利用時の品質・利用状況によって評価が異なる

・ユーザーＡさんとユーザーＢさんで評価が異なる

外部品質・システムの振る舞い・誰がテストしても同じ結果・一般的な仕様策定の対象

・テストケース・外部仕様

内部品質・システムを構成している要素すべて（含ドキュメント）

・後に残り、評価が可能・エンジニアがこだわるところ

・クラス図・フレームワーク・ドキュメント

プロセス品質・後に残らない行動・コミュニケーション・作業手順



• プロジェクトの活動は「利用時の品質」からスタートし、また、戻ってくる

46

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質



47

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

なにを、どのような構造で、どのような手順で作れば、利用者にとって価値があるソフトウェアとなるか



48

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

今やっていることが利用者の価値につながっているのかを確認し、調整する



• どれだけ線を太くできるのか

• そして、途中で切らない

49

利用時の品質

利用時の品質

プロセス品質

内部品質

外部品質

利用時の品質

アーキテクトの主戦場

PMの主戦場



• チケット駆動も開発者の中だけではつまらない

–チケットのトレーサビリティは重要

• 顧客を巻き込もう！

–意外にみんなチケットが好き

–「やったら終わる」快感が大事

–問い合わせ、バグ、インシデントはやりやすいはず

• そうすることで顧客と協業しよう

–顧客と持続的な関係を築く＝サステイナブルSI

50


まとめ

51


まとめ


–プロセスは「計画して、実行しつつ調整する」

–「計画と実行の差を把握する」し、そこから「問題を予測」し「調整」を行う

–こうすることでプロジェクトを正しい状態に導く

• イマドキのプロジェクト運営

–不確定なことが多くなっているけど状況に応じてマネジメント手法を選択すればよいだけ

–分かっていることが多いならウォーターフォール

–分からないことだらけならアジャイル

52


まとめ

• チケットの適用

–基本的には「よく分からない場面」で使う

» ウォーターフォールの場合は空のバケツ。ガントチャートと組み合わせて使う

–王道はバグ、インシデント、問い合わせ

» 進捗管理に使うかは良く考えてから

• チケット駆動

–チケットをコミュニケーションの起点にする

–BTSだけではなくて、VCSやCIを組み合わせて

53


まとめ

• 顧客と協業する

–チケット駆動を目的にしない

–顧客を含めてみんなで使っていくと効果的

• どこにも銀の弾丸はないので、きちんと考えて使っていきましょう！

54

チケット駆動で加速する顧客と協業するプロジェクトマネジメント

Technology