「SIの現場で使えるチケット駆動開発」レポート

2013/8/24にグロースエクスパートナーズ株式会社にて開催された、「SIの現場で使えるチケット駆動開発」のレポートです。
SIの現場で使えるチケット駆動開発｜セミナー｜Growth xPartners Corporate Site

スライド資料に無い説明を中心にまとめています。ぜひスライド資料を併せてご覧ください。
【参考】としている個所は私が挿入しています（補足や参考資料など）。発表者の意図したものではありませんので、その旨ご了承ください。

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

グロースエクスパートナーズ株式会社　鈴木雄介さん / @yusuke_arclamp

チケット駆動で加速する顧客と協業するプロジェクトマネジメント from グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.

自己紹介

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

GxP(グロースエクスパートナーズ株式会社)はアトラシアンエキスパート（販売パートナー）です。
GxPでも8年ぐらいアトラシアンを使ってきており、そこでのノウハウを伝えたい。

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

プロジェクトは目的を達成するための活動。
プロジェクトには期限があるということが大きな特徴。

PMBOK

PMBOKは1990年代にリリース。
そのため、1970～1990年代の伝統的なプロジェクトマネジメント手法を整理したものになっている。

PMBOKには以下の5つのプロセスグループが規定されている。

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

計画プロセス、遂行プロセス、コントロールプロセスは何度も繰り返される。
また、遂行プロセスとコントロールプロセスは反復を繰り返す。

PMBOKはどんなプロジェクトでも役に立つので見ておくことをお勧めする。

PMBOKには9つのナレッジエリアが規定されている。

統合管理
スコープ管理（プロジェクトの内容を決める）
時間管理（スケジュール管理）
コスト管理
品質管理
人的資源管理
コミュニケーション管理
リスク管理
調達管理

このリストを基に抜け漏れがないかをチェックすることができる。

『プロセスは「計画して、実行しつつ調整する」』
これはプロジェクトマネジメントの基本的な考え方であり、アジャイルであっても同じ。

重要なポイント

どれだけ早く計画と実行の差に気が付けるかが重要。
その差から『問題を予測」し「調整」を行うが、そのやり方はPMBOKに書いていない。これはPMがやるべきこと。
こうすることでプロジェクトを正しい状態（本来の計画）に導く

プロジェクトマネジメントはPMBOKの通りにやればいいというわけではない。『問題を予測」し「調整」を行う』ことが大切。

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

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

PMBOKの想定している状況と変わってきている。

ステークホルダーの多様化。昔は担当部門が一つだった。今は担当が複数部門で横断している。

早くリリースすることで利益が得られる。

要求の異なるシステムの連携により問題が起こる。

新しい技術の加速。クラウド、HTML5の登場があった。

アジャイルの考え方

アジャイルでは調整が不要なぐらい計画を小さくする。なるべく短いほうが良い。

「できるまでやる」は悪。この原則が残業するな、という考え方につながっている。調整しようとするなということ。

2週間ごとに以下のようなことを振り返る。

終わっていないこと
顧客との間でズレがあったこと

そして、再計画で調整を行う。

ウォーターフォールの調整
- リソースを追加
- 期限を延ばす
アジャイルの調整
- 計画の中では調整しない
- 再計画で調整する

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

わからないことを調整幅として想定する。
⇒空のバケツを用意する。

ウォーターフォールで計画を完璧にするのは諦める。
それよりもバケツを持つ。

ウォーターフォールでうまくできるのか？
同じドメインを何度も繰り返している場合はありえる。
⇒ドメインエキスパートによるパッケージの導入など。
証券取引のような分野ではウォーターフォールが向いている。

プロジェクトの失敗は計画か実行かに問題がある。
このうち、計画に問題のあることが多い。
不正確な計画しかできず、そのまま実行して調整が必要となり、破綻する。

本来はウォーターフォールのほうがアジャイルよりコストを抑えられるはず。
計画がしっかりしていればその中に収まるため。
そのため、計画を軽視してはいけない。

ウォーターフォールは無茶な計画でもできてしまいそうに見えるのが問題。

アジャイルの危険性

アジャイルであっても、できる範囲で計画をしなければいけない。

ウォーターフォールにもアジャイルにもメリットと危険性がある。それを理解した上で選ぶことが大切。

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

スライドの「ウォーターフォールのアプローチ」に描いたUターンした矢印は調整幅を意味する。ゴールをイメージし、この高さを見抜ければうまくいく。優秀なPMはこの見積もりがうまい。

スライドの「アジャイルのアプローチ」に描いた蛇行した矢印は試行錯誤を意味する。試行錯誤の分無駄はあるが、本当の無駄ではない。

大抵のプロジェクトはプロジェクトのスタートとゴールの中間ぐらいから始まる。ゴールが全て見えているわけではないが、見えているところもある。

以前のブログはチケット駆動開発をdisったわけではない。
【参考】
こちらのエントリの事と思われます。
チケット駆動開発で作業管理はしないほうがいい - arclamp

チケットの適用

チケットの使いどころ

よくわからないことがなければチケットは不要。でも、実際にそんなことはない。

プロセスや方法論によらないのがチケットの良さ。

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

Excelでの管理の限界は印刷した時にA4横2～3ページ程度になる程度まで。
曖昧で粒も大きいなら使えるかもしれない。例えばリスク管理表とか。
注意すべきはExcelの共有機能を信じないこと。

チケット適用の進め方

「問い合わせ管理」にチケットを利用するのはメールを撲滅させるため。
最近のメーラーはスレッド表示できるが、それでもロストする…。

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

タスクが何百個もあり、担当者も期限も決まっている時にチケットを進捗管理に使うのは意味がないと思う。
チケットだと前後関係が見えず、総量的な見方しかできない。進捗管理にはガントチャートを使うべき。

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

チケットは総量的な見方しかできない。
ただ、アジャイルのように短いイテレーションであれば、期間内の整合性はあまり気にしなくて済むのでチケットが向いている。

MS Projectは大きい案件の時に使いこなすと便利。

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

ビューワーとしてカンバンを利用すると、ステータスとか人を基準に見せ方を変えることができる。

チケット駆動とツール

チケット駆動とは

「チケットなしのコミットは禁止」とはトレーサビリティのため。
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

『プロセスの型』とはチケットの処理フローのこと。

チケット駆動とツール

アトラシアンの良さはいろんなツールを組み合わせられること。
JIRA, Stash, Bambooなど。

顧客と協業する

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

ウォーターフォールは計画を立ててしまえば、最後まで突き通すことになる。
アジャイルは次の計画がないので、最後まで到達できるかが見通せない。

ウォーターフォールが有利
- 大規模な構築案件
アジャイルが有利
- 運用フェーズ
- 規模が小さく要件があいまい

ソフトウェア品質モデル

「利用時の品質」はユーザーの感じる良し悪し。これはユーザーのコンテキストや考え方・やりたいことによって変わってくる。なので多重線となっている。
「外部品質」は仕様。これは静的なもの。テストをする対象になる。
「内部品質」は構成や構造など。クラス設計やドキュメント体系も含まれる。いわゆる成果物で、自分たちが作るもの。
「プロセス品質」は成果物を作るためのプロセス。後に残るものではない。

成果物、つまり「内部品質」に問題がある時は「プロセス品質」に問題がある。だが、「プロセス品質」は残るものでないので、何が悪かったか後からわからない。

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

利用時の品質：ユーザーが求める事（要求事項）
外部品質：どういう機能なのか？
内部品質：どういう構造だと作りやすくなるのか？
プロセス品質：どう働くべきか？

「利用時の品質」～「プロセス品質」が一連の流れとしてつながっていることを意識することが重要。
SIerの悪いところは工程を分断して丸投げにし、この品質間のつながりを切ってしまっていること。

工程毎に自分の事しか考えていないと失敗する。例えば、フレームワークを選定するときに（内部品質）、お客は何を求めていて（利用時の品質）、どういう意図で設計されたのか（外部品質）を考えないといけない。流行りだからと飛びついてはいけない。

優れたPMはアーキテクトの資質を持っている。プログラマ出身だったりすることも。

まとめ

計画と実行の差を把握することが大切。
そのために差が出やすくする。

チケット駆動を目的にしない。あくまで手段。

「利用時の品質」～「プロセス品質」を考えないと成功しない。
その実現としてチケットをうまく使ってほしい。

QA

セッション後にお話を伺いました。

Q.
仕様検討にチケットは使えるか？
A.
使ってもいいが、粒度が難しい。ハッキリしていること、曖昧なことをわけて管理した方が良いと思う。

Q.
チケットを登録して満足してしまうメンバーにはどうしたら？
A.
クローズするように働きかけを行う。例えば定例や議事録などでcloseするように働きかける。

チケット管理システム Atlassian JIRA のご紹介

アトラシアン株式会社　大澤俊介さん / @Sean_SF

チケット管理システム Atlassian JIRA のご紹介 from Shunsuke (Sean) Osawa

JIRA 6

チケット管理システムはプロジェクト管理において必須のツール。JIRAはその一つ。

JIRAの利用例
開発チーム：バグ、機能要求の管理
製品チーム：プロダクトマネージメントのタスク管理
会社全体：社内のタスク管理

JIRAの名前の由来。
Gojira ⇒ Bugzilla(Bug+Gojira) ⇒ JIRA

アトラシアンとは？

オーストラリアの会社。

サンフランシスコがマーケティングの拠点。日本法人ができた！

営業部隊はいない。口コミやコミュニティで広まった。営業部隊がいない分、安くできる。

アトラシアン製品は数人の会社～数万人の会社まで幅広く採用されている。

アトラシアンのミッション

ドッグフーディングもしています。
【参考】
ドッグフーディングと頻繁な内部リリース | Atlassian Blogs

パズルの3ピース

アイデア：機能追加・改善、ロードマップ、ドキュメント
アクティビティ：タスク・バグ管理
コード：Git, Mercurial

以下の3つが柱となるツール。
・Confluence（アイデア：チームコラボレーション）
・JIRA（アクティビティ：課題、プロジェクト管理）
・Stash, Bitbucket（コード：DVCS管理）

DownloadあるいはonDemand

Download（オンプレミス）とonDemand（クラウド）の両方で提供している。

JIRAの背景

MarketplaceはAppleのAppStoreのようなもの。プラグインが500以上ある。
【参考】
https://marketplace.atlassian.com/

JIRA Basics

JIRAではIssue(課題)が最も重要な単位となっている。
それがサブタスクに分割されることもある。

プロジェクトに課題が含まれる。

JIRAはマルチプロジェクトに対応しており、複数保持することができる。
プロジェクトを製品単位であったり、部署単位に設定することができる。

新しいJIRA紹介

1.Modern

デザインガイドラインを公開している。
【参考】
- AUI Documentation

これに合わせることで、製品間のルック＆フィールの統一がとれる。
JIRA6からこのデザインガイドラインに対応している。

このガイドラインはプラグイン開発者にも参照してもらっている。

新しいデザインはどの画面からでも課題を作れるようにしたのが特徴。

2.Fast

編集モードに切り替えることなく、インラインで変更できる。

フィルターでの絞り込みがしやすくなった。

操作性の改善。例えば、ピリオドを押下することで課題に対するアクションを呼び出せるようにした。
画面遷移をなるべくせずに済むようにした。

スプリットビューの導入。左で選択した課題の詳細が右に出る。

3.Mobile

【資料のみ】

4.Simple

テンプレートが用意されており、素早くプロジェクトを作成することができる。

Marketplaceからワークフローのテンプレートをダウンロードできる。

価格

クラウド版で10ユーザーまでなら$10/月。
ダウンロード版は別価格。
【参考】
お問い合わせはこちらまで。
トップページ | アトラシアン製品ならアトラシアンソリューションパートナーのGxP

チケット駆動開発の知っておくべき大切な事

株式会社SRA　阪井誠さん / @sakaba37

チケット駆動開発の大切なこと（バランス編） from Makoto SAKAI

自己紹介

プロセスプログラマーはプロジェクトマネジメントのプロセスを作っていく。

チケット駆動開発はTracのコミュニティが始めた。

パラダイムシフト

不確実性コーンとは開発が進むと見積もりのばらつきが減るという、ベーム先生の言葉。
以前と比べた不確実性コーンの変化

期間が短くなった
見積もりのばらつきが大きくなった

※スライドの図では実線が以前。点線が現在。

ソフトウェア業界のパラダイムシフト

ネオダマ：
「ネ」ネットワーク
「オ」オープンシステム
「ダ」ダウンサイジング
「マ」マルチベンダー・マルチメディア
【参考】
講演では「マ」をマイクロコンピュータと説明されていましたが、調べてみると上記のほうが適切と思われましたので、修正しています。

ダウンサイジングの問題

これは1995年の発表だったが、この問題は未だに続いている。

技術者の責任範囲

段々とビジネスにも踏み込んでいかなければいけなくなった。

日本のソフトウェア管理・開発の歴史

表の年代は登場した時期ではないので注意。流行った時期で記載している。

表中の記号の意味について：
＝：組織と現場が均衡
＞：組織重視
＜：現場重視

成果物標準化はドキュメントのフォーマットなど。

CMM/CMMI, ISO9000はプロセスの標準化。日本でも一大ブームとなった。

CMM/CMMIを策定したカーネギーメロン大学の研究所ではTSPやPSPも提唱していた。
チームや開発者がモチベーションを高めるにはどうすればよいか？ということも議論されていた。
ただ、日本ではQCサークルの流れもあり、プロセスの標準化に注目が集まった。

CMMIはヘビーなプロセスできついものだった。
それがXPの一部で主張されたようなドキュメントや計画は不要という反発につながった。
他のアジャイル開発手法はあまり盛り上がらなかった。

具体的な課題

アジャイル開発は組織的に可視化されていない。チームの個別性が高く、複数プロジェクトを一貫して管理することが困難。
⇒だが、これが重要なポイントとなる。

チケット駆動開発による開発法の拡張

チケット駆動開発(TiDD)によって開発法の適用範囲を（スライドの図の実線から点線へ）拡張できる。

変更リスクへの対応力

五月雨発注：
メーカーに多いやり方。わかっているところだけ発注する。
わかっていないところのバケツを見積もらなくて済む。
メンバーが増えるとコミュニケーションのリスクが増える。五月雨発注の時はメンバーを安定させることが大切。

ウォータースクラムフォール：
ウォーターフォールをベースに実装だけスクラムで行う。

【参考】
スライド中に示されている、変更リスクについての参考リンクです。
[#TiDD] アジャイル風開発ラフシミュレーション: ソフトウェアさかば

ツール連携

ITSとバージョン管理ツールを連携させることで、何をきっかけにソースの修正が起こったのかを記録することができる。

TiDDによる自律とリスク低減の実現

履歴は登山でいうところの釘や留め具。先人の残したものを利用できるという点で同じ。また、複数人で作業するときにはロープがあれば迷わない。

事例の概要

文教パッケージの説明。大学向けにカリキュラムや試験を管理するもの。

自分の仕事はここまで、というように守りに入るようになった。

結果

気付いたことをどんどんチケットとして登録していった結果、作業漏れが減少し、納期までに作業が完了した。

目が輝いた！

チケットを使うことで、サブリーダーとパートナー間でもめたときも、リーダーがサポートしやすくなった。

事例のまとめ

手順はWikiにまとめるなど、なんでもチケットにしたわけではない。

バランスと戦略

色々な開発手法はあるが、全てのモデルは単純化されている。
モデルは現実の複雑さを取り除いたもの。

対立から協調へ

グループ・ダイナミックス入門（杉万俊夫）P30にて、集合性（かや）を論じている。

組織とチームの両方のかやに属するリーダーやスクラムマスタ(SM)の動きによって、かやもまた変わる。組織が強くなったり、チームが強くなったり。

実践のバランスと視点

チケットは形式知。
アジャイルは暗黙知を重視している。

TiDDでは形式知ばかりになるので、そのニュアンスを伝えるために長い朝会が必要となる。

パネルディスカッション

株式会社SRA 阪井誠さん
グロースエクスパートナーズ株式会社　鈴木雄介さん、和知右桂さん

ディスカッションの中から、気になった発言をまとめました。

チケットを起票するときに担当者を決めておいたほうがよい。そうでないとゾンビになりやすい。（和知）

チケットだと前後関係のある進捗管理は難しい。（鈴木）
チケットはバケツに入った課題を2週間でできるか？と検討するのには向いていると思う。（和知）

チケットに日付をいれてはいけない。工数をいれてはいけない。リリースバージョンはいれていいが、日付が重要ならガントチャートで管理すべき。（鈴木）

あいまいなものをあいまいなままでチケットにしてしまうとはまる。WBSだとあいまいなまま箱に入れ込める。（鈴木）

ウォーターフォールで無理に全てをチケットにする必要はない。開発で出てきた課題に対してチケットを適用するのが非常に向いている。（鈴木）

いまあるチームでよりよいアウトプットを出せるかがPMの仕事。（鈴木）

プロジェクト運営とはいまある制約（メンバー、日程、予算）の中でどうするか。それを諦めと捉えるかチャレンジと捉えるか。（鈴木）

プロジェクト運営でこれしかない（例えばコマンドコントロール）と突き進む必要はない。その場に応じて他の適切な手段を選ぶことを忘れてはいけない。（阪井）

懇親会

懇親会にて、鈴木さんとお話したことをまとめます。

計画に対する遅れがすぐわかるようにあえてギリギリのスケジュールを設定する。遅れが出たらその遅れの種類を見極める。そして残しておいたバッファで遅れの種類に応じて対応する。
これについては阪井さんからCCPM的とのコメントもありました。
さかば on Twitter: "CCPM的ですね。RT @pato_taityo: … @yusuke_arclamp さん…計画に対する遅れがすぐわかるようにあえてギリギリのスケジュールを設定する。遅れが出たらその遅れの種類を見極める。そしてその種類に応じて残しておいたバッファで対応する。 #gxptech"

PMBOKは備忘録。チェックリストとして使える。実際にプロジェクトマネジメントを経験してから読むと、その有用さがわかる。

（セッション中にお話のあった良いPMはアーキテクト資質を持っているという話について）インフラの話もコードの話も顧客の話も理解できる。そんな全体を見通せるPMというのが理想。

アーキテクトになるにはいろんなことに興味を持つこと。マネジメントに興味を持つことも大切。アーキテクトの道を進んでいけば、マネジメントの必要性にも自然と気が付く。

（パネルディスカッションのあいまいなものをチケットにしない、に関して）明確なタスクに落とし込んでチケットにする。チケットの良さはチケットの単位で優先順位を入れ替えやすいこと。

また後日、PMとアーキテクトの関係についての資料を教えていただきました。

なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from Yusuke SUZUKI

講演中にお話のあった「良いPMはアーキテクトの素養を持っているものだ」ということがわかります。
また、この資料に『「なぜ」を繰り返す』というのがあります。これと同じ言葉を懇親会で@fullvirtue さんからも伺いました。なぜ顧客はこの発言をしたのか考える。そして、顧客の目指すゴールへ導くことがコンサルの仕事だと。