ドキュメント改善
- 2. 自己紹介 • 川上 文夫(1988年よりシステム開発に従事) – RPG, COBOL, C, Perl, sh, Java, JavaScript, Python, Scala – 2000年ごろからAgileを取り入れたプロジェクト推 進を実施 – イテレーション、ドキュメント関連が得意(と思っている)
- 3. ドキュメントとは • 開発中のドキュメント • 開発終了時のドキュメント • 開発終了後のドキュメント • 何をどう作るかは重要ではない • 何故どのように作ったかは重要
- 4. 石器時代のドキュメント
- 5. 1970年代まで • 局面ごとに作成 • 作成されたら変更されない • 変化が激しくない時代に向いている – 仕様は変わらない – 環境は変わらない • PC, Smartphone, tablet • Network, Security – 競合も変わらない
- 6. 現代のドキュメント
- 7. 21世紀ドキュメント • 動くコードとドキュメントは同期しなければなら ない – そのドキュメント、古いです。 – あちらは修正したのですが、こちらは忘れていま した。 – Brush up anytime, anywhere
- 8. 検索 • 「あの仕様はどこにあったっけ」 • 「Aフォルダの下のBフォルダの下の...」 • 「ABC機能(DEF受信).xlsxというファイルかな?」 • 「いえ、ABC機能(DEF連携).xlsxだったと思いま す。」 • 「ファイルを選択して、開いてっと。あれ、ない よ。」 • 「Aフォルダの下のBフォルダの下のEフォルダの 下のABC機能(DEF拡張).xlsxだったかもしれませ ん」
- 9. わかりやすさ • ある日 – 「XXX機能ってどんな機能ですか?」 – 「それは、XXXはYYYで....」 – 「どこかに書いてありますか?」 – 「みんな知っているから書いてないんじゃないか な」 • 3ヶ月後 • 「XXX機能ってどんな機能ですか?」
- 10. わかりやすさは固定ではない • 今、わかりやすいと思うドキュメントでも、明日 わかりやすいとは限らない – 読む人によってわかりやすさは違う – メンバーが変更されれば暗黙知は失われる – 他の機能が変更されたため、意味がかわってい た、というケースも
- 12. レビュー済み文書 • レビュー済み文書はよっぽどのことがないと 変更できない • 変更には手続きが必要(!?)、面倒 • 「多分更新しなくても、みんなわかるんじゃな いかなぁ。」
- 14. Regional Scrum Gathering® Tokyo 2014
- 15. 常時レビュー • Wikiを使うことにより、常時レビューが可能 • 開発者は常にWikiを参照、修正しています • わかりにくい箇所、記載漏れを見つけたらそ の場で修正します – 必要に応じて定例会議で報告 – 無限履歴管理
- 16. 修正のしやすさ • ちょっとした修正の積み重ね – Word/Excelだと開くのが面倒 – Word/Excelだと巨大ファイルを開いて1箇所修正、 巨大ファイルを更新 – Wikiなら、ブロック編集
- 17. Wikiで全文検索 • Wikiにドキュメントを集約 – 要件, 設計書, 議事録, 通達事項 – あれはワード, これはメールとならない – 常にみんながWikiを見ることで修正漏れ、最適な 記述を維持できる
- 19. デメリット • 印刷には向かない(レイアウト変更は難易度 大) • 一覧、表計算、グラフ、イメージの添付は工夫 が必要(通常WikiとExcelを併用します) • 別の意味でのドキュメントスキルは必要
- 20. 実績1 • メーカー、常時30人参加プロジェクト – 関連チーム含めると100名以上 – 海外向けパッケージ製品 – 初年度、Wikiを使うことをテーマにプレゼン、条件 付きで認められる(マイルストーン毎にWordへの 転記) – 当初は自分のサブチームが利用の80% – 半年後ぐらいからWord文書化されずWikiのみ – 1年後には30名全員が書き込んで利用していた