オフショア一発目

ベトナム

はじまっちゃった、はじまっちゃった。
今回は身内の仕事なんで楽だが、Skypeで打ち合わせとかはやるわけで。
仮想次戦に向けては丁度いい。

今回の仕事の概要

ある種のツールのC#移植。ウェ・・、Webじゃないんだ！？と身内仕事のターゲットにびびりつつ。
期間は4月〜5月末の2ヵ月。そのツールの一部まで移植完了、という流れにする。
見積もりは人月にて。具体的な数字はナイショ。内部的には最初のオフショア案件なので、ちと多めに人員をアサインしている。
仕様書なし、設計書なし、マニュアルなし。
発注書無しに要件定義無しに基本契約書も無しと来たもんだ。
さすが身内仕事。アツイぜ！

プロジェクトの進め方

3月最終週（つまり今週）に私が要求をヒアリングしつつ、要件定義を作成。それを小出しに翻訳してもらいつつ、4月2日からキックオフという流れ。
このヒアリング作業はSkypeで行っている。大分ベトナムの回線も復活してきたのか、昨日やったところそれ程問題はない。
ただ、一週間毎日一時間なので、以下の事に気を付けている。

  1. その日の打ち合わせを無駄にしないため、打ち合わせ前に資料を事前準備
  2. 打ち合わせ終了前には、次回予定を連絡
  3. 次回には必ず前回の打ち合わせ時より進んでいる点を伝える

とにかくオフショアというのは相手の不安感を取り除いてナンボ。
逆に言えば、ちゃんとやってんの？と思われず、もうそこまでやったの、となれば勝ち。
地味だが、この辺は相手に対するアプローチを工夫するしかない。特にスケジュールもない最初の状態では顕著。

今回の開発手法

徐々にAgile的な開発をする下準備が出来つつある。
ここで言うAgileはAgile ModelingでもAgile Unified Processでもなくて、Manifestoの方ですが。
http://www.agilemanifesto.org/


今回はAgileの古豪eXtreme Programmingから以下3点採用。

  1. Test-First Development
  2. Coding Standard
  3. Small Release

Pair Programmingは導入失敗中。Collective Code Ownershipと合わせて来年になりそうかなぁ。商品開発チームでは50％くらい導入しているのだが。
いや、これは別になくてもいい。ペアプロをやりたい理由は、「開発効率を落とさず教育能率を上げる」という点に他ならないのだが、この両方を満たすためには社員の技術レベルが一定水準に達していることが重要。
実績と経験作りが重要で、2〜3人の開発人員が要求されるケースの多い一年目では、まだ早い。メンバーによっては出来るんだけども。


一日8時間やCustomer Testもある程度は満たせそう。
Design Improvementは、実質的にスパイラル的に進むSmall Releaseを採用した今回でも2ヵ月間はウォーターフォール的大工程に沿って進む訳で、あまり前面には出せない。Simple Designと合わせて、今回のチームはもう出来ると思うんだけども。
Small Releaseは2ヵ月4回。実は2週間ごとのIterationというPlanning Game項に関するXPのルールを失念していたのだが（このエントリを書いている時に見た文献で思い出す・・）、なんか2週間ごとペースになってるし結果オーライっしょ、ということで。
まあ、2週間に1回はルールに定めずとも、普通にSmall Releaseを意識して工程組めばそうなると思うしな。

面倒な点

途中で俺日本帰っちゃうんだよねぇ・・。
苦しいといえば苦しいのだが、社員には私が5月に日本から帰ってきた場合は4月上旬までの進め方で、5月に日本から帰ってこない場合はそれ以降のやり方で、二通りのシミュレーションが出来るからいいべという話をしている。
オフショア初めて、Test First初めてで、途中でやり方が変わるのだと、1日8時間という労働ペースはなかなか難しいな。出来れば8月くらいから、いわゆる週40時間こえないようなペースで開発出来るようにもしたいんだけどね。
残業すればいいやと思うと、どうしても通常時間中の集中力が散漫になるしな。


あと解析がしんどい・・。ま、これは俺がなんとかすればいい話なので楽だけど。
久々に見たよ、DBの全部のテーブルに「ID」という同じフィールドがあって、一個PKのないテーブルが混ざってるDB。
外部キー制約もかかってないから、リバースエンジニアリングだけじゃテーブルの関係がわからず、ソースコードがないから中のつくりを確認することも出来ない。
ではどうするかというと、テーブルのフィールド名やテーブル名自体から予想して、「多分こうっすよね、どうでしょ、合ってます？」と確認するという作業を一日一時間の打ち合わせの内、20分くらい盛り込むという形になる。
他、色々と。
まあでも、自分がなんとかすればいいという作業は、人に作業を依頼するよりずっと楽ではあるな。文句言いながらやってりゃいいし、最終的に出来れば自分の成果、出来なければ自分の責任。単純な話だ。