今だから思う、使えばよかったツールを検証してみる

これまでの基本設計はこんな感じでした。

1. 進捗(タスク)管理: excelで作成日やRV日、ページ数を管理していた。
2. 構成管理: ファイルサーバに置くだけ。バックアップはコピーして.YYYYMMDD
3. ドキュメント形式: 基本はword、計算するものはexcel、図はvisio
4. RV: 紙で印刷して、対面RV

化石なやり方ですねwwww

ひとつひとつ考察してみようかと。あくまでも個人の見解+反省です。

進捗(タスク)管理

初版登録まではこのやり方でもいいと思う。最初からチケット駆動開発的なやり方だと、チケットを発行する手間も大きいし、個人的には辛いかな。
ただ、初版登録後は、チケット管理したほうがいいよね。
チケット管理なんて巷には溢れてるけど、PJの都合上、クラウド上にドキュメントを置くとかできないので、自前でサーバ立てることになる。
redmineとかは高機能だし、プラグインとかもいっぱいあるけど、構成管理との連携とかめんどくさいし、何より構築がダルい。
というわけでは、個人的には構築が楽で、構成管理もできるgitbucketが好きです。

DL: https://github.com/gitbucket/gitbucket/releases

java -jar gitbucket.war

瞬殺ですね。

構成管理

ファイルサーバで管理とか全然ダメですね。今だとgit一択かと。進捗(タスク)管理でも記載しましたが、gitbucketは両方の機能を持つのでgood。
たくさんツールあると、ツール疲れしちゃうので、統一はしたほうがいいですね。

ドキュメント形式

MS製品縛りになってますね。gitの旨味を活かせないMS製品は、苦しいですよね。
ただ、サイジングや見積もりなんかは、やっぱりExcelじゃないと辛い。
なので、(本当に必要な場面だけは)Excel、それ以外はmarkdownだったりasciidoctorでドキュメントを管理し、図はplantumlの組み合わせがいいかな。
ただ、納品形式がword、excelと限定されていたりすると、これはこれできつい。(勘弁してよ・・・・)

なので、

asciidoc -b docbook adocファイル # docbookに変換
pandoc -f docbook -t markdown_strict 変換したxml -o markdownファイル
pandoc markdownファイル -t docx -o docxファイル

で変換できるみたい。
man: http://sky-y.github.io/site-pandoc-jp/users-guide/

この変換はめんどくさいので、シェルとかにしておくか、gitでpushしたタイミングでhookしてjenkinsからスクリプトで変換する、とかかな。
そこまでしなくても、納品前に一括で変換しちゃう、ってのでもよさそう。(普段docxで見ないはずだし)

あと、redpenでpush時に校正をかけるといいかな。

RV

紙とか本当に勘弁です。ドキュメント形式をテキストにすることで、PullRequestで差分がRVできるので、紙が不要になりますね。

終わりに

ツールがすべてではないのですが、ツールで生産性が変わってくるのも事実なので、新しいツールが出ればまた研究しよう