アジャイル開発では、ドキュメントを作らない！なんてのは言い訳で、最低限のドキュメントは必要だと思うんですよ。
『ソースコード読め』『ソースコードが正』『今ある動作しているシステムが仕様』だとテスト部隊が困ってしまう。
その時の問題点としては、テストする人のスキルによってキャッチアップできるかできないかが分かれてしまう。
テスト仕様書の期待値は明確である必要があるのです。
一方で開発部隊は実装・単体テストなどやることが多い中で、設計書にフィードバックすることの優先度が下がりがち。というのも理解できる。
問題点としては、ドキュメントが古いので結果ソースコードが正になってしまうのです。
私なりに、両方経験した身として、下記を提案していきたいなと考えています。
設計書の切り分け
開発にて必要な設計書を列挙しMoSCoW分析にて重要度付けを行いました。
さらに設計書の内容についても同様に重要度付けを行いました。
MoSCoW分析定義
| MoSCoW | 説明 |
|---|---|
| Must | 必須の要件。満たせない場合には、認識齟齬が生じる |
| Should | 満たせないと影響が大きい要件。対応要否の影響を考慮して対応可否判断が必要な要件 |
| Could | できれば対応したい要件。コストやリソースによっては対応を見送ってもよい要件 |
| Won‘t | 対応不要な要件。将来的なものとして先送りしても問題ない要件 |
持論をまとめたリスト
あとがき
改めてまとめてみると『Must』が多いように思えますね。
『Must』を減らして気持ちを楽にするとしたら、開発側で必要なドキュメントか、テスト側で必要なドキュメントかでしょうか。
ですがそれはあまり意味がないので・・・。
-
ドキュメントの記載粒度を粗くする
10人中7、8人が同じ解釈になれば、程よい粒度なんじゃないかと考えたりしてます。
内容的には齟齬が発生しやすいと思われる振る舞いなどがあれば、そこを重点的に記載することを意識しています。
『Must』の内容はエンジニアが【苦】にならない粒度感ということが重要だと考えています。 -
共同編集する
結論、エクセルなどのバージョン管理・ファイル管理は往々にして煩雑になりやすく共同編集をすることで、
そのあたりの課題感が解決できると考えています。 -
バックエンド
OpenAPI（Swagger）や『.md(Markdown)』を使用する
※厳密にいえば共同編集ではないのですが、JsonやらYamlなのでコードと一緒にバージョン管理してしまうのがいいと思ってます -
フロントエンド
Notionやスプレッドシート
ワイヤーはXDですかね？（XD使ったことないですが・・・共同編集できたような）
色々書きましたが、受託案件だと納品物として設計書を納品するでしょうから、
一概に絞れるものでもないのが現状だと思います。
ドキュメントの種類・記載内容などの方向性は、しっかり先方とすり合わせを行ってFixさせてくださいね。
（命を守る観点で大事）