世田谷某所の飲み会。

中学校の同窓会。

あまりにカオスだったので、Twitterにしきりに「爆発しろ!」とか毒づいてました。
色々思うところはあったけど、色々な人*1がいっぱいいるカオスな場所じゃなくて、本当に当時仲良かった人とだけしみじみ語らう会だったらまた行きたいな、と。

*1:主に知ってる人、知らない人

プロジェクト内にBTSやPMSを持つ意義。

元請の方々に一年くらいあれやこれやアピールして、ようやっと実現しそうです。後は僕がすんなり導入できれば、ようやっとスタートラインに立てます。


元々は、現場での仕様の管理がExcelやWordで行われていた事に端を発しています。
履歴を残そうとした場合、「日付+ファイル名」といった命名でどんどんファイルが増えてしまいます。また、ショートカットでそのファイルを参照している人がいた場合、新しい日付のファイルが出来た事に気付かない可能性も生まれます。これは余りよろしくないので、「いつでも最新の情報を見れて、かつ履歴も管理できる」という環境を作る必要がありました。


また、ExcelやWordで仕様を管理していると、ソースコードとの結び付きが完全に人依存になってしまいます。
全てが把握しきれるサイズのシステムであればそれでも何とかなるかも知れませんが、少しでも大きくなると途端に管理しきれなくなります。その結果、例えば「発注」と「受注」で担当者が別れたり、自分の担当外の業務機能について全く分からなくなったり、といった辛い状況が生まれてしまいます。


更に、ExcelやWordはお客様に納品する際には良いフォーマットになり得ますが、開発者が理解しやすいフォーマットかと言われるとちょっと疑問に思う事もあります。確かに、ExcelやWordに、お客様に納品する形態で記述していき、開発者がそれを見て開発を進められるなら、非常に効率的に思えます。でも、そこで気をつけたいのは、お客様に納品する際の文書の内容と開発者が必要としている文書の内容は、イコールではないという事です。

UnitTestのタイミングで、ステージング環境を設けないのは、問題の切り分けが複雑化してしまうからですよね。それと同じように、仕様を記述した文書についてもなるべく単一の目的に沿って作ったものの方が、分かり易いものになるんじゃないかな、という事です。
納品に合わせて全てをA4に統一したり、と体裁の整った文書より、場合によっては巨大な絵1枚を印刷せずに見る、というケースの方が良い場合が多々あります。ER図やUMLなんかが、まさしくこの部類のものでしょう。


そんな訳で、プロジェクト管理システムとかバグ・トラッキング・システムと呼ばれるものを導入したかったんです。(それがほぼ決まって嬉しかったのでTwitterにあれこれ書いていた結果が、この日のエントリに繋がる、という訳ですね。


今はTracRedMineの2つに絞って機能の比較をしていますが、個人的に「Pythonやるぞー!」(もう全然できてませんがorz)と言っていたのでTrac良いなと思ってますが、仕事が細かい案件を並列で動かしたりする事が多いので、複数のプロジェクトを管理できるRedMineを使うほか無いかな、と思います。RedMineガントチャートを作ってくれたり、所謂「管理をしたい人」には中々良いツールだと聞いていますし。


・・・「やっぱりこっち!」と出来る為に、データ移行が出来るほど余裕が出来たら嬉しい。

タイトルまた変えました。

「IT業界徒然草
Technopolisの夜」
と変えてきましたが、あれから色々ありましてすっかり自信が消えうせた為、ちょっとでも偉そうまたは気取ってるタイトルは止めよう、と思いました。


で、これ。

id:itengineerの思い悩むblog

なにげに一番しっくりくる><