T-1000の日記

第２回すくすくスクラム瀬戸内勉強会の告知です。

（裏番組で私が講師をするかいらぼ勉強会があるので、参加できませんが。。。）

早めの告知をしておきますね。

第２回すくすくスクラム瀬戸内～身体でおぼえるスクラム～ http://kokucheese.com/event/index/1734/

今回は土曜日開催ということにして、１日コースで主に初心者向けにスクラム
の基礎をみっちりやるという企画です。もちろん、講義形式だけではなく、プ
ロジェクトの疑似体験を含む各種ワークショップを組み込んで、まさに「身体
でおぼえる」勉強会になるよう、企画を進めています。

基礎コースですので、既にスクラムを実践しておられるみなさんには物足りな
い内容かもしれませんが、瀬戸内地域では（おそらく京阪神でも）スクラムを
テーマとしてなかなかこれだけ充実したイベントはないと思います。10:00～
16:45（懇親会を入れても19:00終了）ということで、岡山・広島近郊だけでな
く、京阪神や四国からも十分日帰り可能かと思いますので、ご興味のある方は
奮ってご参加ください。

今、四国Androidの会第３回勉強会の最中ではあるが、
興味深いブログの記事を見つけたので投稿。

無駄なドキュメントは書くな（再考）＠大井町の飲み屋談義

この記事の中で、「詳細設計書の標準化」について語ったということでしたが、
個人的に感じている事がそのまま書かれていました。

今の仕事場でも思うことですが、「とにかくソースコードを読まない」

日本語で書かれている設計書で仕様を語る奴ばかりで非常に萎える事が多いですね。
「詳細設計書がないと…」とか「資料が要る」とか、、疲れますね。
詳細設計書なんて、ソースコードの修正が入ったと同時に修正を入れないと
陳腐化して意味がないものになるのが分かっているはずなんだが。。。
（と言っても、最初に開発する時には考えをまとめるという意味で作成するのはありなのかな？と
思ったりする）

詳細設計ってなんなんでしょうね。

ただ、協力企業さんに発注する場合などは詳細設計書は必要なのかもしれません。
（何も無く、発注しても作れないだろうし。）

まあ、「本当に必要な資料」って言うものが何なのか、よくわかりませんが。。。
私はソースコードがあればそれを読みますから。

ＸＰっていうと「Windows XP」と思われるかもしれませんが、（もうそんな人はいないか）

eXtreme Programming（エクストリーム・プログラミング）

で、今回の業務は納期がすぐそこに迫っていて、とてもじゃないが、
設計→プログラミング→テストのウォーターフォール型での開発では、間に合わない。
（間に合わないと言うよりは、仕様が決まりきっていない状態も現時点ではあるわけですが）

で、ほぼ私一人での作業をしているため、（もうすぐ増員された人が本格的に動き始めるが）
コードが先に出来上がる状態ができてしまう。

ということで、せっかくだから、XPに挑戦してみようかなと思ってみました。
（他のメンバーはなかなかとっつきにくいみたいですけども）

個人的にはXPという手法は「理に適っている」と感じてます。
確かにウォーターフォール型が悪いとは思いませんが、
設計しているだけで全ての仕様が決められるとは思わないし、
結局そこから、「仕様変更」という名のフィードバックも入ってくる。
（実際にはウォーターフォールにも「フィードバック」という段階が実際にはあるみたいなんですけどね。
それが抜けている。）

で、「妄想」して設計書を作ってからプログラム。も悪くは無いですが、
どうやっても変更が発生するなら、動くものを作成してから動作を見て
具体的な設計をしていっても良いのでは？と思いました。

あ、ちなみに「修正した人が分からなくなる」という意見については、
この考え方はコードの責任はメンバー全員で負うという考え方があるため、
範囲がわからない。ではなく、気がついたら直す。という考え方になります。

日常業務に隠されたムダをとことん洗い出す

上記の記事は設計段階での話なので基本設計、詳細設計などの経験が少ないので
どうしても実装、テストでの無駄を省くと言う話になりますが…。

プロジェクトが終わった後になら大体思いつく「今思えば、あんな事しなくても良かったね…」的な事が
良くあると思いますが、全てが見えた後だから言えることはたくさんあるような気がします。
では、また次に新しいプロジェクトでそういう無駄というものが省けるかどうか考えてみると…。

多分、そんなに思うほど無駄って省けないんだろうなと思います。
逆にしっかりと時間が削減できる可能性もあるかもしれません。

私の場合は、つい昨年「苦い思い」をしました。それによりわかった事は、「いかに無駄な作業を省くか。」
ではなく、「いかに、手戻りの作業量を減らすか」では無いかと考えます。
やはり、システムを開発している時に、「動きが気に入らない」「ちょっとした仕様変更」
「不具合」なんていうのが多々発生すると思います。
と言うよりは、実際には設計段階では開発経験者でなければ、なかなかどういうものか
想像できると思えません。具体的な物が見えてきて初めて理解でき、意思を伝える事ができるように
なるのではないでしょうか。
家とか車の設計とは違うものですから、絵で見せることもできない。
（※画面設計書と言うものが存在するが、それを見せられてもやっぱりぱっとしないのが
私の経験です。全てが動いてから初めて話が始まるような気がします。）

そこで、仕様変更やら、不具合などは受け止める事を前提として考えたなら、
アジャイル開発は理に適っているのではないかと思います。
アジャイルで失敗する場合とは評価段階に入っても要望を受け入れたり、
ソースプログラムに変更コメントを入れたり…という事をするからコードの難読化が進んでしまうのかも
しれませんね。（昔はそれをしないと変更した場所がわからなかったから仕方が無いとして、
現時点ではいろんなバージョン管理システムが存在しているため、一気に作り直してしまえば
良いのです。変更点はいつでも取れるのですから）

さて、本題から逸れてしまいました。
では、どうやって手戻りの作業量を減らすか。
一番は「手戻りを作らない」これなら、０です。
それが無理だという事を前提にしたならば、処理の共通化。
メンバー間の意思疎通をしっかり取っておく事。

処理が共通化されていれば、修正部分が減ります。また、メンバー間の意思疎通をしっかり
取って、コードの理解も共有化しておけば、コピペでコードが分身していく可能性も減ります。
（私は昨年これで死にました:-)）
それに加えて、「同じ処理を追加する時は共通関数化する。」といったルールを定めておく事。

あとは、コードレビューをしっかりする事。（これもコードの知識を共有化できるため
分身を防ぐ事が出来ます。）

これまでの内容からまとめると結局は「チーム内でしっかりコミュニケーションを取れ」
これに尽きるような気がします。

上記の事をしっかりしていれば、作業がかなり減るのではないかと推測します。
それを全くやっていなかったために失敗したのかも知れません。

これは（その１）としておきます。続きはまた次回へ…。

最近、だんだんとブーム（？）になりつつある、Bug Tracking Systemの
tracを使ってみたいなと思い始めました。

どんな機能があるかを調べているうちに、結構簡単にインストール＋環境構築が
できるらしい記述を見つけました。
特に、aptを使用しての手順は本当に簡単であるように思います。

僕もプロジェクトのリーダーをやってみて思ったのが
スケジュールの管理とか、問題点、進捗状況の把握、
ドキュメント、ソースの管理が非常に困難だったように思います。

これを使えば（メンバー全員が使いこなせれば）プロジェクトの管理に
費やす時間が減るのではないかと期待しています。

使ってる? Issue Tracking - trac 楽々ことはじめ
http://journal.mycom.co.jp/special/2006/trac/index.html

Trac をインストールしてみたよ
http://espion.just-size.jp/archives/05/297225719.html

明日、明後日とtracのセットアップをやってみようかなと思ってみました。