プロジェクト管理ツール Backlogに変更した。その②
プロジェクト管理ツール Backlogに変更したレビュー その②
前回はこちら
FileMakerで集約するところまでを書いた。実際にはBacklogは主にFileMakerの開発及び保守案件で利用している。そこで今回はFileMaker開発に合わせた弊社のBacklogの使い方を書きます。
マイルストーンを大切に
FileMakerの大半の開発案件はウォーターフォール的な開発方法ではなくアジャイル的な開発方法を取り入れている。（完全にアジャイルではない）
要件定義を仕様書というドキュメントにまとめるのではなく、実際に動くソフトウェアで確認してもらうという開発手法を多くの場合採用している。クライアントの意図と違った場合、作成したソフトウェアが無駄になるのではと思うのが普通だがFileMakerの場合、このあたりの手戻りは開発初期の段階ではあまり気にならない。そのためにもお客様と頻繁に特に開発初期段階においてはレビューを行う必要がある。そのレビュー会の粒度をマイルストーンで設定している。まぁスプリントみたいなものでしょうか。これを繰り返すことでお客様の意図とソフトウェアの合意形成を行う。また初期の段階から実際にお客様にも触ってもらい要望を吸い上げる。お客様にも負担はかかりますが、ソフトウェアひいては業務の仕組みを一緒に作り上げる工程であり、私はそこをとても大切にしている。ヒアリングシートでチェック項目を埋めながら仕様書を作成してあとは完成までお待ち下さいとの感覚の違いはかなり大きい。Backlogから少し話がそれてしまったが、Backlogのマイルストーンを必ず設定しマイルストーン期間中のタスクの優先度や振り分けが、ガントチャートやバーンダウンチャートで可視化してPM的には容易になった。
ファイルの活用
ファイルが意外と便利である。帳票や写真・ロゴ等を保管でき更にバージョン管理も可能なのでとても使い勝手が良い。またFileMakerはGitやSubversionといった構成管理ツールに対応しづらいというか出来ない。そのために、開発ファイルの最終バージョン管理はかなり苦労する。実際にはお客様先のファイルが最新ということが多々である。手動運用にはなるが、データ無しのファイルを作成しデータサイズを小さくしてBacklogのファイルに上げることで簡易的なバージョン管理は可能だ。ただあくまで手動ベースになるので運用がやっかいで課題である。
WiKiの活用
WiKiはプロジェクト管理ツールには大体付属しているが、Backlogは日本語インターフェイスなのでとても使いやすい。さらに保守対応の場合、担当者不在の場合もそのプロジェクトに対してある程度の対応を可能にするために様々な情報を書き込んでいる。そこを見ればわかるとしてある。会社としては顧客管理や販売管理を別システムで動かしているがあくまで営業目線や経理目線の情報が多く開発担当者レベルの要望に応えられていなかったためこのWikiはかなり便利だ。
Gitの活用
FileMakerにはDDRという機能がある。テーブル定義書やスクリプトの中身をすべて書き出してくれるすぐれたレポート機能だ。開発期間中、きりの良いタイミングでこれをBacklogのGitにPushしている。Pushのタイミングの厳密なルールはないが、終業時や開発プロジェクトを切り替える際に行ったりする。残念ながらいまのところ大きく役立ったことはない。修正箇所等をみたりする程度だ。ここは今後のFileMakerの仕様変更により大きく変化できることを期待する。
