もっと簡単なチーム開発からはじめよう。

デプロイの自動化とか回帰試験の自働化とか繰り返しする作業は決まっているんだから機械＝コンピュータにやらせよう！というトレンドが広がり始めて数年は経っているけれど、じゃあ、自分のプロジェクトで「やってみる？」って思っても、環境を作ったり、実際どこまで出来るかフィージビリティをみたりしなきゃならないことを面前にすると「『さっきなんでやってみようかな？』ってなんで思ってみたんだろう……。」とプチ後悔してながら「まだ慌てる時間じゃない。」と自分を宥めたりしたりしているのでは？、などと思ったりするのですが相も変わらず手作業でプロジェクトのリポジトリ管理をされているシステムエンジニアのみなさんご機嫌いかがですか。

そうしたインターネットで公開されている情報も、書籍も、ツールの使い方やちょっとしたコツを書いています。当たり前だけれど、自分のプロジェクトのことは一切考慮はしてくれてない。一つひとつのプロジェクトはそれぞれ違うわけで様々なプロジェクトのケースまではやってられないし、それはキミのビジネスなんだから、とあしらわれてしまうのがいい落ちで。

とは言え、今のままでは機能追加をするたびに増えていく回帰試験の試験を毎回手サブ(手でサブミット)するのも人がやるということはどこかに間違い、例えば、回帰試験なら試験データの間違い、環境準備の間違い、試験実施での実施抜け漏れ、エビデンスの取り忘れなどなど心配し始めたらきりがないし。また、プロジェクトマネージャの観点からも、全体コストの中に繰り返しの作業が占めるコストが暫時増加していくことを易々と見過ごすことはできないですよね。

例としては、回帰試験の繰り返し作業の問題について書いたのですが、繰り返しの作業はデプロイや試験ばかりではなくて、日々のプロジェクトの作業の中にだって同じように繰り返す作業があちらこちらにあるものです。そうした繰り返す作業が一人なら若しかすれば気にならないことがチーム開発という複数のメンバでリソースを共有しながら参照したり編集したりすることになると競合の問題が起きたりしてちょっとした運用ルールで競合問題を回避したりすることなったりします。

デプロイの自働化も試験の自働化もできたらいいけれど、今まだチームがそこまで行けていないなら、もっと手前から、でも、プロジェクトを日々まわすために毎日やっていることがあってその作業をする都度エンジニアがちょっとだけでも頭を使っている作業があるなら、そこの部分だけでも機械に任せてみませんか。

チームの情報共有がメールとファイルサーバならクソなプロジェクトだよね
いきなりクソプロジェクト呼ばわりですが、同じチームで同じプロジェクトルームにいてもメールとファイルサーバで情報共有をしているプロジェクトは少なくないです。プロジェクトならプロジェクトをキックオフした瞬間からなんらかドキュメンテーションが始まり、プロジェクト終了までそれが続くのです。そのプロジェクトのライフサイクルの中には、deliverableを作成するための情報だったり、その情報をインプットして目的の設計書やプログラムなどのdeliverableなどのリポジトリを作り続けることになります。

それをメールとファイルサーバだけでやるのは「バカなの？死ぬの？」って突っ込まれそうですが最近でも見かけたのでまだまだ主流なのかもしれません。それともワタシの周りだけなのか。

そうしたプロジェクトに多いのは、情報などをexcelに書いて、メールに添付して、のパターン。excelのファイル名は次第に日付や枝番などの接尾辞が無秩序につけられどれが最新の一覧なのだ科もわからなくなり、最後は聞きまわったり受信したメールの日付の新しいものだと決めつけて更新を続けたりするカオスな事態になるわけです。やっぱりバカっぽい。

情報共有がメールと口頭ならメールなんて送受信者しかエビデンスが残らないし、メールだから読むとも限らないし、間違って消しても気づかない。後から参画するメンバにどうやって情報共有するつもりなのかそうした算段も考えていないし。やっぱりバカでしょう？

初めてのチーム開発にこれだけは準備しておこう
ツールは何でもいいですがこの機能があるものを用意しておこう。その前に、手軽にフィージビリティできるならそれを使ってみよう。やっぱり使ってみないと自分のチーム開発に何がどう有効なのかからないので。

チーム開発に必要な機能
　掲示板　……　情報共有のために
　構成管理ツール　……　設計書、プログラムなどのリソースのバージョン管理のために
　チケット管理システム　……　WBSのタスクの進捗管理や経緯のあるベンダへの問い合わせのログ保管などに

この3つの機能を持っていればツールは何でもいいです。ここでは慣れているtracで話を進めますけど。なんでtracなのかと聞かれれば、Trac LightningというWindows PCにオールインワンで導入できるパッケージがあって、それを自分のPCにいれて自分が担当するプロジェクトでどう使ってみたらいいか運用を試行錯誤したから、です。

チームで掲示板を使おう
ワタシのプロジェクトでは、tracのトップページのwikiをプロジェクトポータルのように使っていました。リンク集とか、プロジェクト全体に関連して全員が知らないといけない告知や通知とか。子どものwikiにはシステム環境のサーバ情報とかソフトウェアのバージョン、ライセンス情報、管理者情報などのページを設けたり、データセンタへのアクセス情報のページを設けたりしていました。

兎に角、共有する情報はこのwikiに書いて、そのタイトルとURLをメールに書いて「プロジェクト内のメーリングリストに送れ！」と言う運用をすることで、メール添付はなくなるし、wikiのページに行って「キーワード検索すればいいや。」とメールボックスの中を探すことを止めてもらいました。

チームで構成管理ツールを使おう
プロジェクトで作るもの＝deliverableをメンバのローカルディスクにおかれることはそのメンバが休んでしまうと最新のファイルにアクセスできない事態になります。これはそうそうないのですが起きると地味に痛い。あと、間違って消してしまったり、後進したりする事故も度々起きるんですよね。それをsubversionのような構成管理ツールでまずは作ったものをセンター管理するんです。

センター管理する、と言う考え方が大事なのです。一人ひとりのPCで、ローカルでさせない。更新するための一時的な中間ファイルならローカルに置いてもいいですが、それはあくまでも中間ファイルであってプロジェクトとして最新なのは構成管理ツール上のコミットされたファイルの方が最新として扱う運用ルールとします。コレも大切な考え。

オリジナル、最新がサーバで一元管理されることになりますから、メンバは必要都度pullしてローカルを最新化して作業をすることになります。こうした作業の仕方は不慣れなエンジニアが多いですが1-2週間もすれば慣れます、というかワタシのプロジェクトのメンバは実際使ってみて慣れる手間に文句を言うよりローカルで管理しなくていいと言うメリットの方を乾燥で話していました。

チームでチケット管理システムを使おう
WBSをガントチャートで見たいという場合は、tracのチケット管理システムではちょっとつらいのでプラグインを探すか、redmineか何かを選択した方が良いかも。

でも、チケット管理システムがしくみとして必要なのは、一つのWBSを一つのチケットとして登録して、WBSを担当するエンジニアに渡して、そのWBSのチケットのステータスの更新をメンバにデレゲートできるところが一つのメリットなのです。それはどういうことかと言うと、excelでWBSを作ってプロジェクトマネージャがコツコツと最新情報をラウンドロビンして聞きまわったり、excelのWBS一覧のファイルのどれが最新化を管理することをしなくていいということを意味しています。

WBSをチケット管理システムを使うとき、すこし工夫した方が良いことがあって、それはチケットを一覧としてチケット管理システム上のビューの画面で見るときのこと、です。簡単に言えばビューで閲覧するときにある項目で昇順降順で並んでほしかったら、並んでほしいようにチケットの情報を登録しましょうね、ということです。

excelのWBS一覧では、WBSのID、つまり通し番号を採番していたハズです。それをビューで使える項目に振っておきましょう。これで使いやすくなりますから。

あと、パッケージを使うシステムの場合は、製品ベンダに問い合わせをすることがあるものですが、そうしたQAもチケットに登録して、その遣り取りをチケットに記録しておくことをお勧めします。何せ、昨日のワタシはワタシじゃないし、あとから参画するメンバに「ベンダにQAを投げる前に同じ質問が無いかそこを見て。」と教えてあげらるので。

wikiの掲示板、subversionの構成管理ツール、そして、tracのチケット管理システムの3つの機能をプロジェクトに導入するだけで大分情報の流量が変わりますし、慣れると情報がそこにあるからこそにある分だけコンテキストが高くなるのです。そして、情報が全てtracなどのしくみにデジタルデータとして残るので、再利用も再資源化もできるようになるのです。