ASDoQ大会2014(3)：講演3「アジャイル開発における ドキュメンテーションの考え方」

2014/10/17(金)に開催されたASDoQ大会2014の聴講内容を紹介します。 前回は、講演２「ここがダメ！日本人技術者の文書力」でした。今回は、講演３「アジャイル開発における ドキュメンテーションの考え方」です。

講演３「アジャイル開発における ドキュメンテーションの考え方」細谷泰夫（三菱電機株式会社)

[1]アジャイル開発

・様々なコンテキスト

1. ドキュメントを書かないコンテキストもある
2. アジャイルソフトウェア開発宣言の文をミスリードもある

[2]ドキュメントのユースケース

・誰のため

　開発/テスト/保守など

・時間軸

　ドキュメントにアクセスするタイミング：開発、テスト、保守の立場

[3]ドキュメント

・エビデンスもあるが、コミュニケーション手段が目的

1. 相手に意図するアクションするため
2. ドキュメント以外：メール/Face to Faceなど
3. 議論内容を全部記憶できない→議論内容を思い出すためにドキュメントとして残す
4. ホワイトボード等とドキュメントで組み合わせることができる

[4]アジャイル開発

・全体を分析

1. 分析結果を何らかの形で残す
2. 議論の出発点を思い出すため→要求分析でT.B.Dが分かればよい

・機能を詳細化する

　プロダクトバックログ：優先順位付け
→PO(プロダクトオーナー)が状況によって優先順位を変える)

・ユーザストーリー

1. アンチパタン本がある(洋書)
2. 例：画面設計：要求を○○の方法で簡単にいかないか？と提案するような議論
3. 次のイテレーション(2週間後)には動くソフトウェア

・ドキュメント化

1. リリース毎
2. 数イテレーション後

[5]必要最低限のドキュメントとは？

・情報を分類

　誰が使う？
→チーム内/外(理由：実装/保守/合意形成のため)

・チーム内×実装

　期間が長い：形式化する

・チーム内×保守

　ロゼッタストーンのような役割

・合意形成

1. 間違ったものを作らないため
2. 契約や投資

[6]論理性をいつ高める？

・論理性のギャップ

　ベテランと中堅と新人で理解度合いが異なる

・要求の詳細化

　形式手法など

[7]実例

・保守用ドキュメント

1. 未来の担当者のために作成。
2. 架空の仕様変更でコードの学習過程を支援するためにチュートリアル資料として作成→学びをもたらすドキュメント
3. OSSの新たなフレームワーク：他人のblog記事をネタ

[8]開発規定でドキュメント

1. 誰かに何をしてもらうため
2. プロセスが想定している担当がいる

[9]アジャイル開発

1. ルールが厳密でなく、チームで自律的に動く
2. ドキュメンテーションスキルを高める必要がある

[10]Q＆A

Q1：暗黙知な合意形成はあるか？

A1：暗黙的な合意形成はあります。要求はPOとのすり合わせが必要。先に進むには不安なときに集まって議論して、不安を解消する。

Q2：派生開発でのデグレードで細かいところで漏れが存在するが、気がつかないときの工夫はあるか？

A2：デグレードはほとんどないが、XDDPのTM(トレーサビリティマトリクス)でスペックアウトしたり、レビューなどで工夫している。

[11]参考

(1)電子・組み込み技術の総合サイト『Tech Village』「組み込みネット」：アジャイル開発におけるドキュメンテーションの実際(1) ―― 本当に必要ですか？ そのドキュメント

(2)電子・組み込み技術の総合サイト『Tech Village』「組み込みネット」：アジャイル開発におけるドキュメンテーションの実際(2) ―― ドキュメントの「必要最低限」の見つけ方

所感

　私の職場では、ソフトウェアテスト関係や社内外とやりとりするための様々なドキュメントを書いたり内容を改訂したりしているが、必要と思うドキュメントがある一方、

• 「あまり使わないのに(検印が必要な)ドキュメントを作成するのはどうなのか？」
• 「誰のためのドキュメントなのか？」
• 「ISO9000があるからドキュメントを作成するのではなく、自分たちが後々困らないためのドキュメントを作成すべきだが...」

と疑問に思うことがあります。
　無駄なドキュメントを作成していないか、メンバーで見直す必要があると思いました。