面白いデータが入手できたので、考察して見たい。あるFlash系システムの開発において、役割分担をしたチームがやり取りしたmailの量を集計したものだ。
チームは五チーム。全体コンセプトをまとめたり、情報デザインを行うプロデューサチーム。主にFlashの開発を行ったクライアントエンジニアチーム。サーバサイドの開発を担当したサーバエンジニアチーム。顧客チーム。そして、開発の全体の進捗管理や予算管理を行うマネージメントチーム。
6ヵ月間にやり取りされたmailは、全部で2137通。一ヶ月20日間稼動だとすると、平均毎日18通弱のやり取りを行ったことになる。下記は、その発信者別に集計したものである。
・総数：2137通 / 期間：6ヶ月（17.8通/日）
1) プロデューサチーム： 29.9%（5.3通/日）
2) クライアントエンジニアチーム： 27.3%（4.9通/日）
3) サーバエンジニアチーム： 27.0%（4.8通/日）
4) 顧客チーム： 6.4%（1.1通/日）
5) マネージメントチーム： 4.4%（0.8通/日）
6) その他（上記以外）： 5.0%
mail内容は、簡単な連絡程度から、議事録や仕様書のやりとりまで様々。なので、このデータだけでは正確なことは言えないが、余りに目立つ点がある。マネージメントチームの発信率の低さである。
上記の割合は開発期間内の平均であり、通常は役割によってmailの交換頻度が高まる時期に偏りがあるだろう。開発初期に詰めるべき事柄、後期にならないと詰められない事柄。そうした山谷を考えても、全期間平均で一日一通にも満たないのは、やはり少ないと感じる。
低発信率の原因は幾つか考えられる。常に電話や会議でコミュニケーションを取ったのか、強力な信頼関係が存在していたのか、或いは定期的なチェックで進捗管理ができる程、巧妙な工程管理体制の上で進められたプロジェクトであったのか、それともそもそも機能していなかったか、等など。
このプロジェクトの体制方針は分からないが、大枠から言うと、1-3)までを「開発チーム」と分類し、「顧客/開発/マネージメント」という三本体制を敷いていると思われる（詳細を聞かないという条件で入手したので推測）。
マネージメントチームからのmailが要所要所のみで発せられたのかもしれない。だが、mailというコミュニケーションの形態は、通常「往復」して初めて一つの話題が完結するものだ。「質問」と「答え」で1セット。
だとしたら、このマネージメントチームが能動的に発信したmailは実はもっと少ないのかもしれない。単純に他チームからの質問に対する「答えmail」を含むのだから。
■
マネージメントチームを批判的に見ているのは、直接的にはこのデータをくれた人の顔色が健康的ではないからなのだが、チーム編成として現場と管理部門という分離した構成に感じられるという理由もある。
私にとって、Webの根幹は、「間接部門をなくす」に尽きる。Webは、「担当者同士が直接やり取りすることができる仕組み」に他ならない。如何にデータの受け渡しだけをするような、機械にもできることを排除するかが、サイト構築の暗黙の基盤なのだと思っている。
なのに、開発の現場ではまだまだそんな風にはなって行かない。現場が何をするにしても、管理者にお伺いを立てるようなプロセスが必要だと言われる場合が多い。詳細事項決定権限も予算決定権も現場になく、現場と感覚を共有できないような「管理者」がしばしばボトルネックになっている。
しかも、「火」がついてしまった場合、鎮火するのは現場に任せるしかないのである。家事の現場で、遠く離れた役人から火の消し方を指示されても困る。マネージメントの本質がリスク回避にあるのであれば、そうした非常時に機能しないことが分かっていることを踏まえて在り方を考え直してよい。
もちろん、約束した仕様に変更が生じるような場合には、現場が顧客に何度も折衝するよりは、折衝係という独立した機能が存在した方が効率は良い。火事場で、水を撒く人と、水を調達する人とが独立に動けるほうが良いのと同じだ。
こうした部隊をオンデマンドで編成できるかどうかも、サイト開発のスキルなのだと思う。そして、それを現場主導でやるのか、管理部門主導でやるのかという部分も含めて、そのスキルの高低が見えてくる。
■
プロジェクト全体を見渡せるリーダー的な人を見つけたり育てたりすることは、どんな仕事でもやられている。そして、そうした優れたリーダが現場経験者から生まれることが多いのは、Webにも当てはまる。理屈をどれだけ知っていても、火事場で火を恐れるような人には鎮火活動は任せられない。
しかし、悲しいかな、往々にして「管理のプロ」が指揮権を持っている場合が多い。そして、そのプロが居ることで、燃やさなくていいものまで焼いてしまったという噂話もよく聞かされる。
そうした悲劇を見聞きするたびに、対策はないかと考えていたのだが、このデータを眺めつつ思いついたことがある。このデータで、マネージメントチームからのmailを「0%」にすれば良いのではないだろうか。
一般的に、開発現場には「作れれば幸せ」という人が多い。それが職人芸を手にする基盤でもあるのだが、ある意味自分の首を絞めているとも言える。プロジェクトが、「管理のプロ」に振り回されるのは、自分達が彼らに付け入る隙を与えているのだと考えるのだ。
権限という壁は直ぐには取り払えないが、現場が様々な意味できちんとコミュニケーションできれば、マネージメントチームの存在意義が薄まるのは必至だ。結局のところ、マネージメントチームの主業務は、正確な情報収集とその整理、そして的確な判断とその伝達に他ならないし、その殆どが現場にある。
Webの現場では、プロデューサやディレクタという肩書きの方が、自分のことを「雑用係」だと称することが多い。これは、マネージメント機能を分業化しようと試みつつ、やはり自分で何でもやるしかないという結論の現われなのかもしれない。
Webというコミュニケーションの場を創り出す現場で、コミュニケーションの問題が起こるというのは、やはりどこか矛盾がある。画像処理デザイナや、スクリプトエンジニアやJavaエンジニアである前に、コミュニケーションデザイナやコミュニケーションエンジニアであるべきなのかもしれない。
■
最後に一つ。冒頭のデータを眺めつつ改めて考えたことがある。やり取りされるmailの用途と質にも依存するけれど、一通あたり読んで消化するのに五分かかるとすると、18通読みこなすのに、実に90分かかる計算になる。
八時間を一日としているWeb屋はそういないだろうが、90分は決して短くはない。特に、開発末期のゴタゴタ時の、仕様整理や変更に関わるものならば、もっと多くの時間を必要とするだろうし、書く側ならもっと大変な作業になる。
正確な情報伝達は、当人達のコミュニケーション能力だけでは達成できない域にきている。日頃から情報がスムーズに流れる情報基盤の整理は不可欠だろう。幸いなことに、BlogもWikiもSNSもある。膨大な情報を正確に共有する仕組み。これから隠れたところで「ツールの時代」が来る予感がある。
「ツールの使い方のプロ」ではなく、「用途によるツールの使い分けのプロ」。細かいTips辞書のような人ではなく、業務を見据えて誰でも使えるような深さでツールを使って業務を回す人。そんなポテンシャルを持った人とツールが必要とされてくる。願わくば、Ridualもそんな候補の一つでありたい。
以上。/mitsui"次回最終回"