アダプタブル・ウォーター　　　フォール開発の事例～ 想定外の作業は　　　　チケットで補完せよ! ～

阪井 誠＠sakaba37

2

あきぴーさんとチケット駆動開発

(TiDD)の本を書いてます

阪井誠

（さかば）

自己紹介

3

ウォーターフォール開発の苦悩

トップダウンなプロセス

　・文書コミュニケーション

　・厳密で手順的な計画

　・柔軟に再計画・管理できない

　・変更を随時受け入れる

⇒計画外の事象が多いと混乱

4

アジャイル開発への期待

現場力の発揮　・コミュニケーション向上

　・リズミカルな開発

　・開発に集中できる

変化への対応　・タスク(カード)単位の管理

　・イテレーション毎の受け入れ

5

アジャイル開発への壁

自社の壁　・開発標準(工程ごとの管理)　・紙ベースの報告(各種報告書)・タスクボードの設置場所

顧客の壁　・契約(仕様＋変更)、窓口とスポンサーが異なる

　・並行開発システムの組合せ(System of systems)

⇒　ウォーターフォール開発を　ベースに何とか改善したい

6

アダプタブル・ウォーターフォール開発

ウォータフォールにアジャイルの

要素を取り込む

　・補完型チケット駆動開発

　・追加のタスクをBTSで管理

　・既存のルールは変更しない

チケット駆動開発（TiDD）とは

• BTS（ITS)を使う

• チケットを用いて作業の管理をする

• チケットがなければ（構成管理上の）更新をしない(No Ticket, No Commit!)

• アジャイ的(XPの4つの価値)• シンプルな管理、見える化によるコミュニケーション改善、未完了作業のフィードバック、実施する勇気が必要

　　　⇒　様々な実施方法がある

TiDDの形態

• 完全チケット方式(Redmineの本ほか)oチケットですべての作業を管理する

o管理が集約される

oプロセスを変更するので社内調整が必要

• 補完チケット方式（アダプタブルWF）o既存の管理は変更しない

o計画外の作業をチケットで管理する

oこっそり開始できる(でも報告は必要<=後述)

9

チケットの管理方法

• ワークフロー型o起票や終了には権限が必要

o仕様の一貫性を保障できる

• オープン型（今回の例）o誰でも起票・終了できる

o機敏さ、自由がある

＊アダプタブルWFでは特に規定しないが

　オープン型が望ましい

10

TiDDの導入範囲

• 工程o全工程、一部の工程

• プロダクトo全体、一部

• メンバーo全員、一部

11

どのように導入するか

• 全体に適用–プロセスがシンプルになるが、チケットが増える

• 部分的に導入–細かなチケットが作成可能、プロセスの強化–作業漏れ防止、コミュニケーション、などに効果

⇒ どちらが良いかではなく、ふさわしい方法がある

12

目次

• TiDDとその分類（説明済み）

• TiDDの経験談

– プロジェクト概要

– 導入時の工夫

– 結果、効果

– 注意点

• まとめと感想

13

TiDDの経験談（概要）

• 文教パッケージのカスタマイズ(最大8人x1年)o 仕様の決定遅れから実質短納期・仕様の大変更

o スキルは高いが経験者が少ない(リーダは途中交代)o 初めての組み合わせ（サブシステム、ミドルのバージョン）

o 義務感と不安、重苦しい雰囲気、閉塞感、、、

o 守りに入るので、コミュニケーションが悪い

システムテストの時期になると、計画外の環境構築やリリース準備作業が明らかになった（環境に関連するバグも、、、）

⇒　そうだ！チケット駆動開発をしよう！

14

総合文教ソリューション UniVision

ＳＯＡによるシームレスな業務処理

【UniVision全体概念図】

学籍管理学籍管理

履修管理履修管理

進級・卒業進級・卒業

成績管理成績管理

入試管理入試管理

就職管理就職管理奨学金奨学金授業料・入学金授業料・入学金

卒業生管理卒業生管理休講

学生呼出

教室変更

アンケート

シラバス情報

レポート管理

e-Learning学校会計固定資産

学校会計固定資産

研究者ＤＢ

評価ＤＢ

研究者ＤＢ

評価ＤＢ

奨学金課外活動施設予約保健管理

奨学金課外活動施設予約保健管理

スクーリング管理科目修了試験配本管理オンライン試験

SOA基盤SOA基盤

UniVisionは入試管理、学籍管理、教務管理といった基幹事務機能を中心に学生

サービスに関する情報全般を統合的に管理する統合文教ソリューションです。

また、2009年度より、新たに法人系システム（学校会計、固定資産）もサービス開始しております。システムコンサルティングから構築、運用支援にいたるトータルサポートサービスを御提供しています。

• 2009 Software Research Associates, Inc

Web Service

Web Service

UniVision Service BUS

UniVision

Web Service

総合文教ソリューションUniVisionの特徴

図書館システム

財務会計システム

人事給与システム

．．．

学籍 教務 就職奨学金管理

健康管理

履修スクーリング

教材管理

教職員管理

卒業生 施設予約 学費 入試

• Strutsベースのパッケージo 複数のサブシステムを組み合わせて構成できますo 個別要件にも柔軟に対応します

• オープンシステムにも対応o お客様の規模、ご予算に合わせて、ハードウェアやミドルウェアの構成が選べます

16

オープンなフレームワークだから、、、

長所• 同じようなコードが減る• 業務要件に固有のコードだけで開発が完了

短所• お約束が多い複雑な作業で、気が抜けない• 工夫できる余地が少ない• 少人数で大規模なシステムが作れてしまう• 実行環境の構成は日々変化

　=>　ややこしくて、しんどい！

いざ！導入

• 補完チケット方式• WBSと併用（と言っても更新作業は全てチケットあり）

• オープン型

• だれでもチケットが作成できる

• システムテスト以降

• システム全体

• メンバー全員

• trac（単独）

　　・・・ SRA共通開発環境（trac,subversion,mailmanの仮想環境）

18

はじめの一歩

• 宣言と実行o バグだけじゃなく、ソースを触るときや、WBSにない作業をするときは、チケットを登録してください！

• 環境の準備o レポート(チケットの一覧)の作成

bugのみ、 taskのみ、 その他、など

抽出条件や表示項目は自由に変更できる

o 権限の追加 tracの権限の設定は堅いので、チケットを修正できるようにmemberにTICKET_ADMINの権限を与えた

　（リスクを考慮して設定してください)

19

結果

• チケットの数o システムテスト：３１

データの準備、環境準備、BUG関連で増えた作業、細かな仕様変更など、手順書にない1回だけの作業

o 本番環境構築：４２

• 作業漏れ減少！納期までに作業が完了！

　(知らないこと、気付かないことはできませんでした、、、orz)

それ以外にも、メンバーに変化が、、、

目が輝いた！サブリーダクラスなのに遠慮をしていたメンバーが、生き生きしだした

• 「チケットを切ってもいいですか？」⇒ 義務的な作業からの解放(指示が苦手だったのに)

• 「チケットを切っておかないと忘れてしまう！」⇒ すくに使いこなしていた

• 「ちゃんとクローズしてね」

⇒ 他の人に指導をしていた！

• 「残っているチケットが多くてわかりにくいから整理しますね」⇒ 今後のことも考えている

21• 玉ちゃんの文化系入門より

TiDDしんどい状況

控え目

やり手

しまった！

• 上司への説明をしていなかった

o通知メールが多いので、不具合が多いのかと心配された

23

注意すべき点

• チケットの登録忘れo チケットがルーチンワークになっていないと忘れがち

• チケットの実施忘れo 他のチケットがないときにチェックを忘れる

　⇒粒度の大きいチケットの後で発生

　⇒粒度が小さいとリズムが生まれて、発生しにくい

　　　(リーダが管理すれば防げますが、自主性が大事)

• 上司への連絡　 (^_^;

TiDDの効果(XP的な表現)

• 変化を抱擁できるo当初想定しなかった作業を管理できた

• コミュニケーションo見える化され全員が状況を把握

o他の人のチケットも自由に登録o それまではサブシステム間の連絡はリーダが担当

oお互いに相談・協力するようになった

25

TiDDの効果(スクラムの価値で)

• コミットすること– 自主的にチケットを発行し、実施した

• 集中すること– 担当チケットの作業に集中できた

• オープンであること– 通知メールやレポートで、プロジェクト全体を見渡せた

• 敬意を払うこと– 守りに入らず、助け合うようになっていた

• 勇気を出すこと– 前向きになる勇気が得られた！

K. Schwaber, M. Beedle, アジャイルソフトウェア開発スクラム, ピアソン・エデュケーション, pp.165-174.

26

まとめと感想

• システムテスト以降にTiDDを導入

• 計画できていなかった作業が管理できた

• 前向きになり、プロジェクトが元気になった

• 感想– 意外と簡単！(備忘録のつもりで)– もう少し上流でも使ってみたい(技術的な問題だけでなく仕様変更もうまく扱いたい)

– 大学のH君を思い出した

27

大学の友人H

• 切符をどこに入れたのかを忘れてしまうからと

「ズボンのポケットに入れたから覚えといて！」

⇒ 「それぐらい覚えておけよ！」と内心思っていた

今から思うと– 何かのトラウマがあったのかもしれない

– 本当に覚えるのが、苦手なのかもしれない

– 人に話すと覚えるという記憶法なのかもしれない

実はチケット駆動開発に似ている

28

みんなで協力すれば楽しい！

• 忘れそうなことをみんなと共有することで– 緊張から開放されて安心できた

– 忘れていたときは、教えてもらえた

– もしものときは助け合った

– トラブルは起きなかった

　「楽しいし、元気が出た」

★ソフトウェア開発が、そういう仕事であってほしいです。ぜひ、みなさんもTiDDを実践してください！

29

チケット駆動開発のコツ

リズムを作って、情報共有を習慣にする

– データの一元化

– 粒度が大きくてはいけない！

– 備忘録化(プライベートチケットも有効かも)– 習慣になるようなルール(朝会、進捗更新)– 見やすいレポートの準備

– 問題意識の共有(作業数、作業量)

おまけ

アダプタブル・ウォーターフォール開発の事例

～想定外の作業はチケットで補完せよ!～

おわり

KPT• Keep：

• 情報の共有、コミュニケーション、協力• チケットの自由な発行

• Probrem：• リズムがなくなると手抜きになる

• Try：• 要件管理との連携、スクラム(内乱だけでなく、外乱も扱いたい)

• Redmine• 定量的な発表

32

スクラム的な使い方

• イメージ(内乱だけでなく、外乱も扱いたい)• バグでも要望でもとりあえずチケットを切る

o切り分け⇒要望リスト(プロダクトバックログ)• 納期を決めてマイルストーンを設定　　⇒要件リスト(スクラムバックログ)• 必要なら作業を分解

• 小さな要望なら簡単

• 大きな要件はタスクレベルではなくなるので、カスタムフィールドを用いるなど、別の管理が必要

33

ひとりチケット駆動開発の経験

• タスクからスケジュールができるのは便利

– そのまま客先に出すには、ちょっと、、、

– 計画を考える道具にはなりにくい

• 楽しくなかった