オフショアスケジュール確定
会議の日取りを間違えていて、日本でのスケジュールは今日決まるのだが、今週一週間、毎日一時間ずつ行っていた打ち合わせでなんとか開発出来るだけの情報は集めたし、またスケジュールも決まった。
要件定義もSmall Releaseになった。というか、追いつかないので段階的にやろっかという話。
やっぱ期間契約は顧客が楽だよなぁ。要件定義すらまったりやれんだもん。
スケジュール
具体的には4回リリースする。
1回目はGUIのみ、2回目はGUIとデータビューの機能、3回目はデータ編集機能、4回目は予備（追加機能になると思われるが、要件定義がまだなんで未決。Iteration Planningという事で・・。）。
で、このリリースとリリースの間をPhaseと呼称するので、1回目のリリースまでを1st Phase、2回目のリリースまでを2nd Phaseと呼ぶ形とした。
要件定義は現在1st Phaseまでしか終わっていないので、1st Phase中に2nd〜3rd Phaseの要件定義、2nd Phase中に4th Phaseの要件定義をする形。翻訳が入るので、実質的には1 Phase後れる。
リリースに関してだが、VPNが開通していたら1週間ごとでもよかった。ただ、まだContinuous Integrationについてはきっちり出来ていないので、何をリリースするかという話が難しい。今回はこんなところだろう。
スケジュールを組んでみた感想
まだいまいち不慣れな感はあるが、この規模の開発にはやはりXPが向いていると思う。
もっといい加減にやってもよかった。例えば今回は現時点で3rd Phaseまでの内容を決めているが、1st Phaseまでしか決めず、1st Phase中に2nd Phaseの内容を決める等でもいい。これだと人員が浮く危険性があるよというリスク思考型の方には、1st Phaseまでに2nd Phaseまで決め、2nd Phaseまでに3rd Phaseまで決めておくようにするのがいいかもしれないが、いずれにせよ目下の作業が常にわかる状態であれば作業に大した支障は出ない。
XPの特徴はとにかくソフトウェアベースであり、プログラマー向けである事だと思う。
まともなプログラマー*1であれば、ソフトを実際に作ってから「ここはこうした方がいいな」と考えるものだ。そうならないプログラマーは、おそらくロジックを組むことに興味があるのであって、より良いソフトを作ろうとしていない。プログラミングとは手段であり、目的ではない。目的はソフトウェアを作ることである、が、世の中にはプログラミングが目的のプログラマーもいるので、そういうエロい人はここでいうプログラマーをソフトウェア・クリエイターとでも読み替えてもらおう*2。なお、設計時に完璧を求めることも出来るが、それをするのはプログラムより時間がかかる。
で、そういった意味ではもっと「作ってから考える」というやり方を徹底してもよかったかもしれない。これは無計画にやるという事ではなく、3rd Phaseを考えるためには1st Phaseの内容が必要だから、1st Phaseを見てから考えればいいという、Releaseを基にした計画という事である。
と、色々考えてはみるが、いずれにせよ遠方で開発をするには線表やら工程表やら、週報やら日報やら言うものを作るだけでは相手は不安なわけだ。
その不安を取り除くためには実際に作っているものを見せればいい。
そういった事を考えると、リリース頻度の高いXPはオフショア向きではないかと思うわけです。
今後について
もうちょっと大きいプロジェクトに備えてそろそろRUPといった、堅固なIteration型のプロジェクト管理もしっかり学んでおいた方がいいだろうな。
先にあげた要件定義を始めにしないやり方はXPとしては正しいのだが、見積もりなどの作業を考えるとこれだけでは上手に出来ないケースもあるわけで、基本方針は変えずに細部の部品を取り替えられるよう、もう少し引き出しを増やしておいた方がよさそう。
で、その基本方針というのは何かというと、先に言った通りオフショアを依頼してるお客さんってのは不安なんだよ、だからその不安を取り除けるように文章じゃなく、作っているものを見せた方がいいよ、という事。
作っているものを見せるためには実際に動くものが必要で、動くものを見せるためにリリース計画を作る事が必要。そういったリリース計画は、通常Iteration型のプロジェクト管理モデルでなければ難しい。
Iteration型の引き出しが少なければ「いやしかし、これにはIteration Planningという概念がありましてね」等と屁理屈をこねて、顧客の要求しているものが何かを見失ってしまうケースもある。
突然話をわき道にそらすが、知らない人間はわかる事を言う、知っている人間はわからない事を聞く、という私なりの人間観がある。
私のような理屈型の人間には多いと思うのだが、自分に反論出来なければ納得が出来ないという思考タイプには、ある概念を知ってしまうのは諸刃の剣になりうる。よって、私は学習時には常に反対の視点から見た概念の学習をするよう心がけている。
知るという事は知らないという事を知らなくなると同義である。だからこそ知らない子供は無垢で純真で残酷で鋭いが、知っている大人は思慮深く汚らしく優しく鈍い。どちらが偉いわけでもなく、それは単に知識があればそうならざるを得ず、知識がなければそうならざるを得ないのだと思う。
よって、学ぶという事は注意しなければならない。学んだ概念に囚われすぎないよう注意しなければならない。
常に自分の考えに反論が出来、その反論は自分を納得させる事が出来るレベルにまで昇華させなければならない。
既に私は大人であり、無垢で純真で残酷で鋭くなるには知りすぎている。
よって、囚われないためにはより多くの知識を得るしかない。
うだうだと長くなったが、要するに選択肢を増やせるよう、XPだけに満足しないで他の概念も学習せんとあかんね、という事だ。
XPはAnti Unified Processなのだが、これらは要するに下手なプロジェクト管理をしたくないから生まれた概念なんで、やりたい事は同じ。
例えば「見てから考えるよ」という顧客の要望に「今回の顧客は計画性が微塵も感じられない」と憤るのは簡単である。動いているソフトを見て「ここはこうしたいね」と言う顧客にも、よく同様に憤ってる人間を見かける。
ただ、そこでXPのPlanning Gameという概念を知っていたらどうか。それが当然の要求である事を理解出来るだろう。その上で、その当然の要求が今回の計画と照らし合わせて妥当かどうか、妥当でなければ修正することが出来るかどうか、そういった判断が出来る。
知らない人間は、ここでウォーターフォール的な考えをして、「製造という工程は設計という工程を基にしているんです。設計は解析が元で、解析は要求が元なのに、あなたは今製造の最終段階になって要求を変えようとしている。それがどれ程影響を与えるかわかりますか！」なんて、自分の知っている知識を懸命に披露するわけだ。
知っている人間はこんなことは言わない。顧客の要望はよく理解出来るし、それはある概念において正しい進め方であることも理解しているので、現在の計画を遂行する上で知らなければならない、自分の知らない点を聞くだけだ。「それをするにはこことこことここの修正が必要で、あと2週間ほど工期を延ばしていただく必要がありますが、問題ないでしょうか。」などとね。
前者は明らかに知識に囚われている。
顧客の要望を私の無知によって生まれた理屈で踏み潰さないよう、今後とも注意深く学んでいきたい。
今回のプロジェクトは私の負担が大きく、正直憤っていた部分もあるのだが、それを学べたのは収穫だった。自身の怒りが自身の無知が生んだものだとわかった時ほど、恥ずかしい時はないな。
