Marketectの主な役割と責務は、開発チームがいったい何を作ろうとしているのかについて、十分に確かな理解を得ることだ。 そのための具体的なアプローチには、さまざまなものがある。
たとえばMarketectは、紙と鉛筆でプロトタイプを描くこともできるし、もう少しきちんとした要件定義的なモノを用意することもできる。 一方それを受けた開発チームは、UMLのモデル図やER図、DFDなどを用意できる。 これらを使って、お互いのコミュニケーションを行う。
適切な構造・プロセス・そして成果を定めるうえで最重要なのは、チームの規模、そして、必要となる外部とのインタラクションの数だ (詳細は、若き日のワシが書いたこの本を参照すること)。 大きめのプロジェクトなら、それなりのフォーマルさが必要だろうが、 それと同じものを小さなプロジェクトに求めると、息が詰まってしまう。 あと、チームの文化を考えることも重要(→あとでコラムにまとめる)。
Marketectは、開発チーム以外に対しても、役割と責務がある。 見込み顧客に対しては、そのシステムがどんなインパクトを与えるのかを明確にしなければいけない。 プラグイン的な仕組みがあるのなら、そのAPIも公開しなければいけないだろう。 サーバー系のソフトウェアなら、パフォーマンスやスケーラビリティに関する資料を公開するのも一般的だ。
Marketectにとっては、Tarchitectから適切な情報を受け取れるかどうかが死活問題だ。
ぎりぎりになって、顧客向けのドキュメントや販促グッズの修正が必要になった。その原因は、MarketectとTarchitectの認識にずれがあったから
残念ながら、こんなことがよくありがちだ。
Tarchitect(すまなそうな顔をしながら)「ごめん。あの大事なフィーチャー、間に合わなさそうなんだ…」
これもまたよくあるパターンだ。こんなことにならないよう、うまくとりまとめるのもMarketectの役割のひとつだ。
これまで、ロシア人やドイツ人、インド人、イスラエル人、中国人、日本人、韓国人、ポーランド人、カナダ人、そしてメキシコ人など、いろんな人たちと仕事をしてきた。
国をまたがる開発組織の管理には問題も多い。たとえば時差もそのひとつ。ミーティングひとつ開催するにも気を遣う。 あとはコーディング規約や命名規約なんかの問題もあるけど、このあたりは、意識の高い人たちなら何とかクリアできる。
問題は、文化的な違いだ。私は個人的にはアジャイルなプロセスやプラクティスを推しているけれど、中にはウォーターフォールモデルのほうがうまく進められるという文化もある。 民族的なものなのかどうかはわからない。
すみません。きちんと読み込めていないので、多少雑なところがあるかも。「???」というところがあれば、原文を見てやってください。