チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド"

本棚 #読書
ずっと長い間ほぼ一人で開発してきたのでこのような本のごやっかいになることはありませんでした．でも最近一緒にやる人がいてくれるようになり、私が書いたコードを他の人がメンテして、それをまた私が引き継いでというようなことができてきます．そうすると、今までのように自分で好き勝手にやっているわけには行かなくなります．この本はそういう問題意識をもっていたところに、Amazonの書評がおもしろかったので思わず買って連休中に読んでしまいました．

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド"
池田 尚史 (著), 藤倉 和明 (著), 井上 史彰 (著)

イメージ 1


いや、実に身につまされることが第２章のケーススタディには書いてあります．私の例で当てはめると例えば次のようなものです．

① 朝出社するとメールを見るのがおっくうです．下手をするとメンテナンスや開発をやっている３～４プロジェクトから急な問合せや障害報告が来ています．（朝メールが来ているということは、お客さんは前日の夜それを書いています．お客さんの身になってみれば、それはそれで大変です．）

② 別名フォルダでブランチを管理している．そう、バージョン管理システムはあります．でも今まではコミットするのは自分だけという状況が長く続いていたので、何も使いこなしていませんでした．お客さんが段階的なシステム移行のフェーズに入ったので、複数バージョンを管理しなければならないのですが、実はフォルダを分けるという情けない方法で対応していました．そもそもバージョン管理システムでブランチを切ればいいのです．

③ リファクタリング出来ません．複数の担当者がお客さんの改善要望で別々に修正を起こしていると、どうしても修正がその場しのぎ（というか局所的対応）になりがちです．で、プログラムはだんだん一貫性がなくなります．今後のことを考えればリファクタリングしたいのですが、すでに運用に載っているプログラムだと、よほどの検証テストの準備が出来ていないと、おそろしくてコードを触れません．

④ 何故そうしたのかわかりません．もう10年もお付き合いしているシステムですが、バージョン管理システムが入る前からのものなので、バグ修正の箇所はソースコード上のコメントに頼らざるを得ません．そのコメントを書いたときの自分は十分何をなすべきなのかを理解していたのでしょうけれど、何故そのようなコードを書いたのかは年月が過ぎれば記憶からなくなります．下手をすると何年も前のメールを掘り起こして、障害原因から当たりなおすこともあります．

もちろん、すべてがこのような状態ではありません．

例えば、プロジェクトによってはRedmineを導入して大活躍しているものもあります．去年の開発から導入してもらったのですが、２ヶ月と言う短い期間でこのプロジェクトだけで1000をはるかに越えるお客様とのやりとりはすべてRedmineで行われました．もしメール＋Excelベースでの管理でやっていたらたぶん間違いなく破綻していたでしょう．Redmineのようなチケット管理システムは超重要です．

またオープンソースで出していたあるプロジェクトは許可をもらって社内のSubversionからGitHubに移行しました．これで障害対応、機能アップ⇒デプロィが非常に楽になりました．テストさえ十分にやれば、利用したい方はGitHubから落としてもらえさえすれば良いので極めて手間いらずです．従来よりずっと改良に身が入るようになりました．それまでは管理、配布ともお荷物以外の何物でもありませんでした．

というところですが、この本を読むと、もっともっと自分の携わるプロジェクトを改良できるアイディアがいろいろ沸いてきます．

この本のコンセプトは、「どのように課題に立ち向かうか」で

「チーム開発で直面する課題に立ち向かうためには、ただ頑張るいうだけではダメです．世界中のエンジニアたちがこのような問題に対処するためのツールや方法論を開発してきました．これらを利用しない手はありません．」

で始まっています．この本は出発点となるべき位置づけのなのでしょうけれど、最新の技術を取り入れて、その可能性を指し示してくれるという意味で非常に有用に感じました．