リレーのチームの監督になったとする。早い選手を更に早くするか、遅い選手を少しでも早くするか。総タイムはどちらが容易に縮まるだろうか。
Webサイト開発のチーム作りは、それに似ている気がする。Flashの花形選手の効率を優先するか、HTMLをしっかり仕上げるコーダーを優先するのか。先を行くものを加速させると、その影響が他のパートにまで広がることも多々ある。ドロドロした現場の底上げを図ると総合工期は短縮されるかもしれないが、芸術性や先進性がイマイチで終わってしまうこともある。その辺りのタズナさばきがチームリーダの優劣だろう。
最近のWeb系ツールは、四番打者を更に強打者にする方向を向いている。GUIベースのHTML記述から、DynamicHTML、CSS、そしてDB連携まで一人でこなせるようなツールをこぞって目指す。それはそれで便利なんだけれど、世の中そんなスーパーマンはそうそうコロがっている訳じゃない。チームとしてはある程度の分業を始めているので、どうしても現場とツールの想定しているモノにズレが出る。そして、よく言われることだが、四番打者だけ揃えても優勝できる訳ではない。強打者だけのチームは、技術的にはトップの座につけるだろうが、人的調整で大変な気がする。
"Ridual"は、そうした風潮から外れたツールを目指している。強打者と強打者の間で、目立たないかもしれないが、必要な仕事をキッチリこなす人達を支援することを目的にしている。そういった人達が居なければ実際の仕事は回らないと思うからだ。
「スーパーエンジニアへの道（ワインバーグ著）」の中に興味深い話が載っている。バグ対応をしている4人のプログラマの話だ。各人の行動から「効果的な影響行動」の回数を調べ、開発におけるリーダーシップを考えるという趣旨であった。4人のうち3人が、何回も何らかの「影響行動」をとる。1人だけがログ（?）を見つめ続け、1回だけ発言する。それを起点に一気に問題解決に至る。この場合誰の「影響」が一番大きかったか。何に対して効果的かという問題に絡むが、「そのバグを取る」ことにおいて一番影響力をもったのは、その人の一回の発言であった。それが全体の舵取りになった。
現場の"非"花形選手はそんな立場のように思う。ログ分析は正直いってそれほどエキサイティングな作業じゃない。ページリスト作成もリソース一覧も目立たない。しかし、巧く使えば、品質保証において確実に意味を持つ。しかし、そうした作業を支援するツールが少ないし、そうした作業を評価する風潮もない。けれど、そうした作業をこなしている人達の目で、1ページ1ページを大切に育て上げている人達の目で、サイト全体を見るならば新しいアイデアが出る可能性が高いのではないか。
このツールを「華がない」と評した方が居た。申し訳なさそうに言っていたが、私にはこの上もない誉め言葉だった。華がないが役に立つ、それは地に足がついたツールのことのように思えたからだ。しかしそんな地味なツールがサイトマップを自動生成してくれる。ページ一覧を作成するための情報は、基本的な部分でこのサイトマップを生成する情報と同じであった。基本仕様を決めて開発を進めていて、このサイトマップが目の前に広がったとき、実際息を呑んだ。変な言い方だが、「こーゆうことだったのか」とも思った。サイト構造を決めていく作業の本質に触れたような気がした。
今までの開発経験で、何人もの素晴らしい人達に出会った。でもそんな人達に事務的でツマラナイ仕事を頼まなくてはならないことが多々あった。事務的な仕事を蔑視している訳ではない。けれど、今、貴方に操作して欲しいソフトはEXCELではなく、Photoshopだ..と何度思ったか。それでもギリギリの工期の中で限られた人材の中では、それをお願いせざるを得ない。一生懸命作表している姿を見ながら、或いは出来上がってきた一覧表が綺麗であればあるほど、なんだか割り切れない気持ちに満たされた。そんなことやっている時間があればもっと奇抜で凄いアイデアを出して欲しい、実装する工夫をして欲しい、という言葉を飲み込む。無理難題を言ってそれに従う姿を見ることが目的の人もいるが、そんなことはサイト開発の目的ではない。開発に関わる全ての人が、開発チームメイトであり、それを苦しめることは本来の趣旨に反する。顔も知らない人々のアクセスに一喜一憂するサイト作りだ、チームメイト全員がハッピーになりたい。それは持てる力を精一杯発揮できる「場」だと思ってきた。場を作るには、規則よりもモラルよりもポリシーよりも、ツールが一番有効だと直感した。それで、ツールなのである。
サイトマップ作成やファイル一覧の苦行から開放されたら何をして欲しいか。勿論丸々工期短縮に使っても良い。しかし、もう一工夫する時間や、マーケティング的な活動時間や、更なる勉強時間にして欲しいと思っている。パソコンを仕事の負荷を減らす道具と見るか、仕事の質を高める道具と見るかの違いかもしれないが、私は Ridualには、後者の効果を期待している。よりよいサイトを作るための道具であって欲しい。
勿論この環境にも不自由さがある。なんと言ってもCPUパワーを喰う。1Gクラスのファイルの塊にはインポート/解析とを合わせて約3時間強かかった。CPUモニターを見ていると解析中はずっと100%に近い。でも、それは私のマシン環境にも依存している、Pentium700MHz（Win2000）、G4/450MHz（MacOSX）での話である。そうそうマシンは換えられないが、いずれ低価格でより早いCPUは手に入る。それを待てばよい。
更に、CPUより先に解析の問題も山積みだろう。我々が試しているサイトは全体量に比べて余りにも少ない。ブラウザの過剰サービス気味な能力で、HTMLの書き方も千差万別だ。昔のサイトを解析すると、よくこんなの通るな....と最早感動するファイルすらある。でも、こうした自動解析や視覚化の「種」を蒔けばいつかもっと大きな「実」がなるかもしれない。もしかしたら、今Ridualが行っている作業はOSレベルや違うレベルでサポートできるかもしれない。このツールの未来ではなく、Webに関わる全ての我々の未来を考えるとワクワクしてくる。
問題は多々あれど、地道な部分へ光をあて続けた先に明日があると、今はまだ思えている。共感する方は、この種に水をやってください。一緒に収穫しませう。
(*)スーパーエンジニアへの道－技術リーダーシップの人間学
G・M・ワインバーグ
http://kyoritsu-pub.topica.ne.jp/bookhtml/0102/000025.html
以上。/mitsui