マスターデータとして各所で使えるドキュメント

ドキュメントのことをあれこれ考えていると、結局の所、見える化であったり、共有だったり、そういう所を気にしているような気がする。

プロジェクトを進める中で、色々なドキュメント・資料ができあがったり、共有されるわけなのだけれど、ある程度マスターデータ的な役割を担うドキュメントがある。

WBSが全体像をつかむ上ではそういう役割の1つであったりする。
それを細かなタスクにバラして全体の進捗を把握できるようにするとか。

打ち合わせで説明するためにその WBS が Excel のような形式などで説明される。
打ち合わせ用の資料作りになるので若干無駄感はあるが、それを見て把握、判断するポジションの人もいるのだから必要なのであれば資料作りは仕方ない。

そのWBSが単独で動いていてタスク管理とかと連携していないと、状況のアップデートも手間になるだろうし。
逆にWBSにはみえてきていないものがあって、打ち合わせではなーなーになっている、といったこともあったりする。

WBSを元に別な資料を作ったりすることもあるとは思うが、Excel ファイルを元に作ると、そのエクセルが更新されると、資料も更新する必要があったりする。
Excel や Spreadsheet の機能でなんとかすることができるのかもしれない。
この辺は自分自身のスキル不足もありそう。

できるだけ元資料の更新にあわせて連動して資料もアップデートできる仕組みにしておけると良さそう。
自動で連動できて、調整が必要なところがわかりやすければいいだろうし、せめて更新があったときの差分がわかりやすい形になってるだけでもいいのかもしれない。

資料をアップデートする場合の手間はかかるが、そのあたりは落とし所としては仕方ないかもだし、単にどこが調整する工数を持つのか、というだけの話なのかもしれない。


よく作られる資料の1つであるファイルリスト(サイトマップ)的な資料も似たような話になったりする。

粒度は様々かもしれないが、サイト内のページ全てを一覧にして作られる場合を考える。
これを Excel や Spreadsheet で作るのは正しいのか?と思わなくもないが、現状のツールの中では無難なチョイスなのかもしれない。

ページごとの親子関係とかを明確にもたせるなら、 CMS 的にここにデータとして管理して一覧できるようにした方がいいのでは?とか思ったりすることもあるのだが、それはまた別の話として。

ページ全体のファイルリストがあるのであれば、それはデザインやフロントエンド実装、CMS設計や実装、テストなど各作業フェーズでのよりどころになることがあると思うわけで。
そういうのを考慮して、それぞれのフェーズ・作業で使いやすい、再利用しやすい資料・データの持ち方をしておいた方がいいんじゃないのかなぁ、、、と。

テスト管理ツール「Qase」でスプシによるテスト管理を脱却した件 - Qiita
https://qiita.com/naoki_haba/i...

を読んで似たような事を思った。
テストも Spreadsheet 管理でいいと言えばいいのだけど、テストごとにデータとなっていた方が色々と便利な気もするんだけどどうなんだろうな。


自分もどちらかというと資料、ドキュメントをまとめる方が多いわけで。
それがどう使われているかは意識できているのか?というと足りないところもありそう。