読者です 読者をやめる 読者になる 読者になる

ソフトウェアプロジェクトにおけるツールの活用を考える会( #sgforswtools ) 第2回勉強会に行ってきた。あるいは「プロジェクトに必要なたった一つのリポジトリ」とは何か?

こくちーず
Home Site

まずは勉強会を主催していただいたスタッフの方々、発表者のお二人、会場を提供していただいたMicroSoftの皆様ありがとうございました。

端的に書くと、とてもいい勉強会だった。
参加者は10〜15人くらいだったのだが、これは会の名前が長すぎるからまだ第二回目の開催だからであって今後どんどんと参加者が増えていくんではないか・増えて行ってほしいなぁと思わせる内容だった。

今回はALMとTABOKの二本立てだったのだが、ALMの話の方で非常に感じるところが大きかったのでそちらについて書く。
TABOKもかなり興味をそそられる分野だったのでまた別途エントリーを立てるかもしれない。

とりあえず「TABOK」でぐぐって二つ目のサイトに詳しい話が書いてあるので興味のある人は是非見てほしい。
(TABOKはTEST AUTOMETION BODY OD KNOWLEDGEの略)

また、この記事は完璧に個人的なメモ。
勉強会の全体的な流れはこちらの方がブログにまとめてくれている。

ALMに必要なのはたったひとつのリポジトリ

一番衝撃的だったのが、「ソフトウェア開発の生産性を高めるのに必要なのは、リポジトリをひとつにすること」という話。

これは、今までのソフトウェア開発は

  • 工程で区切られている
  • チームで区切られている
  • ツールで区切られている

ためにどうしても情報が分散していた。リポジトリがバラバラだった。
その結果、分析や情報の共有に余計なコストがかかっていた。
でも本当はおなじソフトウェアの開発なのだからひとつのリポジトリに情報を集約するべきだよね、というような話だった。

自分のイメージで言うと、

1つのスキーマ(ソフトウェア開発リポジトリ)の各テーブルにいろんな作業の情報をそれぞれインプットして、
分析するときは各テーブルをjoinすれば何でも引っ張ってこれるようにするべき。

といった感じ。これなら情報を更新するときもおんなじjoinでデータ引っ張ってupdateするだけ。
(例えがSQLServerじゃなくてOracle Database風だけど...)

これは言われれば当たり前のことなんだけど、実はすごく難しい。
Redmineでいうと前半部分は結構できていると思うのだが、「分析するときは各テーブルをjoinすれば何でも引っ張ってこれる」の部分はまだまだ不足している。
というかプラグインが個別にテーブルやカラムを追加できる特性上、すべての情報を柔軟に引っ張ってくるインターフェースを作るのは不可能なのではないかと感じてしまう。

各テーブルの情報を統合するメタテーブルのようなものがあれば可能なのかもしれないが、それをどうやって実現するのか?どうやって活用するのかなどは考えがまとまらない。
おそらくこの部分についてはTFSに学ぶべき所がたくさんあるのだろう。(講演者の長沢さんもTFSでデモをされていた)

運良く今はTFSをいじれる環境にあるので、がっつり使って情報の統合・活用の方法を吸収したいと思っている。