t: マークアップコーダも VCS を使えるべきか

なんとなく中途半端なままになってしまったけれど。Twitter 上で蒸し返すものでもないかな、ということで整理・補足しておきたい。

漸次的な開発に参加する (せざるをえない) なら、マークアップコーダも成果物管理に使われる VCS (git や Subversion など) を利用すべきだよね。そして、プロジェクトとしては合意された開発環境に合わせるのが筋だし、最も開発プロセス全体を最適にできる環境を選ぶべき。コードベースを共有しないで別系統でコード変更をするのでは、VCS を使っている意味がないし。原始的な成果物管理に留まる、というのは開発環境やプロセスの改善を否定することになるのでもちろん賛成できない。

とすると。「svnやgitがさくさく使えるデザイナーはすでにデザイナーの仕事範囲を超えているので」というのは、何かを取り違えているのではないかしらん。例えば、ITS がさくさく使えるプログラマは (プロジェクトマネージャじゃないのだから) プログラマの仕事範囲を超えている、と言われて納得するかしら、という程度に違和感があるかな。それは、協調作業のための基本ツールの話であって。マークアップコーダであることとは独立なので、超えるも超えないもない。やりたくないからやらない、今はできないからやらない、ではなく。やるべきならやる、だよね。もしくは、やるべきではないからやらない。

また、マークアップコーダの仕事が安いというのは契約の問題であって。それは職能の範囲か否かということとは関係ない話。少なくともコードレベルの成果物を共有するのであれば。開発体制にあわせられるスキルを持っているなら、高く売れるように交渉すべきだし、高く売れるように業界の体質を変える方向に持っていくべき。さもなくば、安い契約だから発注側の開発体制にあわせるコストは支払えない、という契約にするのは理解できる。もっとも、変更を度々要求されるのであれば、成果物の提出が面倒だったり、管理ミスが発生したりするので、デメリットも大きい。(マークアップコーダに限らず) 成果物に関わる人は、VCS を使えるスキルを身に付けておいた方がいい。

「コーディングスタートした時点で、デザイン変更という事例は実際は何度も経験ある。ほぼすべてデスマの予兆」というのは。完成するまで要求通りに何でも付き合いますよ、という体制になってしまっていたりはしないかと危惧してしまう。それは、VCS や漸次的開発ではなく、開発プロセスの回し方の問題。そういうのは避けられるように、責任範囲を事前の契約で縛っておくべきなのではないかしら。まっとうな発注元なら該当しにくいけれど、問題を起こす発注元なら該当するような条件を盛り込むとか。極端には、漸次的な開発に参加すること自体を避けて、提出したら当初デザインに従って一定期間内に検収し、バグがあれば直す、それ以外の仕様変更は別料金、とか。

当事者ではないので、いろいろ的外れなことを書いてるかもしれないけれど。業界問わず、一般論として。自分は xx だから xx はしない、という考え方は。責任範囲の明確化には良いけれど、排他的になると弊害が大きくなるよね。「専門家」が、「専門分野に詳しい」ではなく「専門分野しか知らない」になってしまうように。そうはなりたくないという自戒を込めて。

あと、何でもかんでも「デザイナ」って呼ぶのはやめたい。

(時刻昇順)

……