発端
今期初めてマネジメント側を任され、プロジェクトの運用について裁量をいただきました。
そこで、以前から取り組みたかった脱Excelを試験的に運用させてもらうことになりました。
なぜ脱Excel？
未だに社内のドキュメンテーションにExcelを使うケースは多いと思います。
Excelを使うメリデメを挙げてみましょう
（以下の記事から大いに影響を受けています。）
設計書は Excel だけじゃなくて Markdown も使ってほしい - Qiita
EXCELドキュメント
メリット
- 誰でも使える。直感的に操作可能。
- 案件ごとにブックを持てる(１つのファイルで管理できる)。
- 数式を使ったドキュメントが作れる。
デメリット
- バージョン管理ツールとの相性が悪い。(バイナリデータ)
- 参照したいだけなのに編集ロックが鬱陶しい
- ファイル自体が大きくなりがちで、動作が重くなったり、検索に時間がかかるようになる。
- 図や数式に頼ったドキュメント作成をすると、メンテが難しくなる。
自分は特に、どこを変更したかわからない（バイナリデータである）ことが問題と感じていたので、今回脱エクセルを目指すことになりました。
どうやって脱エクセルする？
Markdownを使います。
ちょうど、社内でプロジェクト管理ツールが「redmine」から「backlog」に移ったタイミングだったので、「backlog」のwikiで設計書の管理を試みることにしました。
本当はgitの管理下に置いて、プルリクエストなどの恩恵を受けれるような運用にしたかったのですが、今回はそこまで至りませんでした。
実際に運用してみて
Markdown + Backlogのwikiでの設計書の管理は便利な面もあれば、課題もたくさん見えてきました。
便利だった面
- ブラウザ上だけで完結するのでストレスフリー
- ドキュメントが見つけやすくなった
- 検索がドキュメント内部まで及ぶので見つけやすい。Excelは開くまで目当てのものかわからない。
- ドキュメントの共有もリンクを貼るだけでいいし、環境を選ばない
- 差分が取れるようになった。(Backlogの機能で履歴が見れる)
- 好みのエディターでドキュメント作成できる様になった
課題
- 表現力不足
- 図を挿入したい場合に面倒くさかった
- テーブルが書きづらい（外部エディター使えば緩和される）
- 関数が使えない
- テスト仕様書などに関しては、集計の機能が必要だった
という感じでしょうか。
UMLをMarkdownで書けるようになるツールなどを使えば、表現力不足は解消されるかも知れません。
（直感的でないので学習コストはかかりますが…）
最後に
まだテキストベース管理の真骨頂であるgitとの連携が取れていないので、次はそれを目指してやっていきたいです。