Scrum Gathering 2014で行ったワークショップ資料です

1. Wiki Wiki アジャイル
2014/01/15 KAWAKAMI Fumio

2. 自己紹介
• 川上 文夫(1962/05/02生まれ)
– RPG, COBOL, C, Perl, sh, Java, JavaScript, Python,
Scala
– 2000年ごろからAgileを取り入れたプロジェク
ト推進を実施
– 「開発の現場」, 「Software Design」, 「PM
Magazine」への執筆
– パートナー(海外含む)とのチームビルドが得
意(と思っている)

3. アジャイル開発でのドキュメン
ト
• ドキュメントはどうしてますか？
– WordやExcelを使う?
– アジャイルだからドキュメントはない?
• 本日は, 効果的なドキュメントの作成/維持
について考えてみたいと思います。

4. アジャイル宣言
• Working software over comprehensive
Documentation
• 包括的なドキュメントよりも動くソフト
ウェアを
– 開発中にドキュメントばかり書いて, 動くソフ
トウエアをなかなか作らなかった過去のプロ
ジェクトへのアンチテーゼ
– ドキュメントは便利なので使っているプロ
ジェクトがほとんどのはず

5. アジャイルの特徴
• イテレーション開発
– ソフトウエアは変化する
•
•
•
•
要求の変更
新たに気付いた仕様の矛盾への対応
バグ対応
リファクタリング
• ドキュメントも変化しなければ

6. ドキュメントの存在意義
• 何を何のために作るか, を明確化
• 意思疎通のため
– 顧客と開発チーム
– 設計者と実装者(※)
• 運用, 保守に必要
– 何が何のために作られているか, いつどこでど
ういう条件でどう動くか
※ 役割がわかれていること自体問題, というテーマは今回は扱いません

7. ドキュメントの問題
• 書くのが大変(書いたら満足?)
• ドキュメントより動くソフトウエア, コー
ドがドキュメントでしょ
• 古い仕様のまま
• 探している内容がどこにあるかわからな
い
• 同じような文書がたくさんある
• バージョン管理が面倒

8. http://www.flickr.com/photos/cogdog/19490596/sizes/l/

9. Wikiで全文検索
• Wikiにドキュメントを集約
– 要件, 設計書, 議事録, 通達事項
– あれはワード, これはメールとならない
• Word/Excelの全文検索
– ローカルだと, 環境によって結果が違う。
– 検索結果が見にくい, 結果を確認するのに文書
を開く時間がかかる(-_-;)

10. ドキュメントよりソフトウエア
• Wikiを使うことでドキュメント作成時間の
短縮
– 気づいた時に気づいた箇所だけ追記, 変更, 削
除(ブロック編集)
– Webブラウザは親友
– 自分のノートが共有される感覚
• つまり, コストはかからない

11. 最新文書はどれ？
• Wikiなら
– いつも, 全員が見ている
– ミス, 漏れを発見しやすくなる
– 発見箇所をその場で修正できる
– 開発者全員が, 同時に見て, 同時に同じ文書を
修正できる(※)
– Version管理されている
※ conflictは当然ありますが致命的になりにくい

12. Wordは最高!
http://www.flickr.com/photos/bobolink/8040135076/sizes/n/

13. システム開発には向いてない
• 設計書にそんなに高機能は必要ない
• Wordは完成した文書を印刷するのに向い
ている
• アジャイルなドキュメントは完成しない
– イテレーションとともに変化する
– そもそも完成したドキュメントを作成できる
開発者, プロジェクトはない(経験で知ってい
る)

14. Wiki vs Word
文書作成コストが少ない
維持しやすい
検索
ハイパーリンク
読みやすい
グラフィカルな表現
一覧表, 集計
出版
Wiki, Word
Wiki, Word
Wiki, Word
Wiki, Word
Wiki, Word
Wiki, Word
Wiki, Word
Wiki, Word

15. 事例紹介：採用Wiki
• PukiWiki, DokuWiki, Backlog, 独自Wiki
– 納品先のサーバー上で運用(納品はサーバーそ
のもの)
• PukiWiki, DokuWiki, Trac
– 自社サーバー上で運用, 顧客も参照
– 納品物はPDF出力のケースも
• Redmine
– 納品物はHTML(wgetで 全html取得し納品)

16. 納品はWordでお願いします, 対
策
• 最新を維持しやすいドキュメントと維持
しにくい納品時のスナップショット, どち
らがお好みですか?
• 全文検索してますか?
• PDFでもいいですか?

17. Wiki浸透を進めるコツ
• 要件, 設計, 手順書, 議事録なんでも書く
– 毎日少しでも書く習慣から
• 通知, 連絡する際のメール
– WikiのURLを送る。「以下に書きました。」

18. さらに効果的に
• 朝会議事録
– 毎日の作業内容, 予定, 連絡, 問題を記載
– 新しい情報を得る, 理解が深まる, 誤解に気づ
きやすくなる
– 参加できない人も知ることができる
– 作業内容, 作業時間を書いておく
• コスト管理, 月報入力などにも利用可能
• 軽量議事録
http://www.objectclub.jp/download/files/event/2008summer/kawakami.pdf

19. C:.
├─010要件
├─020仕様
│ ├─010XXXXXXXX
│ └─020XXXXXXXX
├─030実装
│ ├─010標準化
│ └─020環境構築手順
├─050議事録
│ ├─010朝会議事録
│ └─020議事録
├─070イテレーション
│ ├─001xxxxxx
│ │ ├─010スケジュール
│ │ ├─020メモ
│ │ └─030テスト
│ ├─002xxxxxx
│ │ ├─010スケジュール
│ │ ├─020メモ
│ │ └─030テスト
│ ├─003xxxxxx
│ └─090納品
├─080個人
└─091その他
├─010リンク集
├─020参考資料
└─090用語集
WikiのTree例
• 構造も常に変化するのであくまで参考
• Tree構造は不要な場合もある
(検索,リンクのみ)
• 仕様はイテレーションの内部に入らな
いのがポイント
• 障害管理は専用ツールで

20. ディスカッション
• 自己紹介から
• よいと思う点, 問題と思う点, 改善案を話し
合いましょう
• 思いついたことは付箋に書いて発表