PR

 本連載は,今回でひとまず終了である。最後に,プロジェクトを重ねるなかで生じる課題をリストアップしておく。それらは,顧客との間の問題や,メンバー間の問題というよりも,個々のメンバーの中に発生する疑問や課題だ。それらが乗り越えられる可能性を示して,コラボレーターたちへのエールにかえようと思う。

万全ではない,ユニバーサル化

 「Web2.0」や「Web標準化」が叫ばれ,Webページの構造と表現を分離する傾向が強まっている。また,アクセシビリティの観点から,「バリアフリー」よりも万人にやさしい「ユニバーサル化」が広まってきている。

 例えばalt属性やaccesskey属性などを付けたり,表組みレイアウトを減らすことは望ましい。しかし,対象とするエンドユーザー層によっては,それだけでは済まないことがある。すると,「ユニバーサル化」に対する疑問がわき上がってしまうことがある。だが,対応策を考える必要はあっても,悩む必要はない。

 「ユニバーサル化」は万人にモアベターではあるが,万人にとってのベストではない。「ユニバーサル化」にも限界がある。100人いれば99人は大満足かもしれないが,残る1人はそこそこに満足かもしれない。第13回にも書いたが,「世界の感じ方,とらえ方」は百人百様なので,万人にとってのベストを目指すには「ユニバーサル化」を補足する「バリアフリー」があって当然なのだ。

 背景色と文字色のコントラストを例にとってみよう。黒地の背景色に白い大きな文字は,一般的には,コントラストが強くて読みやすいとされる。これで文字が大きければ,弱視者に歓迎される場合がある。ところが,一部の軽度発達障害では,コントラストの強さはマイナスポイントで,白地に濃いグレーの明朝体ではない(つまりヒゲのない)フォントを使うほうが望ましいとされる。

 実は筆者も,コントラストの強いほうが優れたユーザビリティだと,頭から思い込んでいたのだが,ここ数年,発達障害者対象のアプリケーション開発にかかわり,一般論だけを基準に,エンドユーザー全員の感覚を推測してしまう愚に気づかされた。

 また,動的なユーザー・インタフェースについても,同じことが言えるだろう。Flashを多用したサイトは,ビジュアルによってユーザーをナビゲートできるのでわかりやすいとされる。文字よりも図のほうを理解しやすい人には,Flashは大歓迎だ。一方で,動きのあるコンテンツを敬遠するユーザーもいる。

 特にトップページでは,Flashによるメニュー表示が問題になる。Flashを使った動的メニューはユーザーの判断でスキップできるようにし,メニューをクリックして一度任意のページを閲覧した後は,Flashメニューと静的なメニュー(テキストベースのサイトマップ)のどちらに戻るかを選択できるようにする,といった対応策を講じなければならない。これはFlashだけでなく,スクリプトで動くメニューを実現しているケースでも同じである。

技術進化の速度を恐れるな!

 手がける案件が増えるほど技術的な知識も増え,その深さもわかるようになり,技術進化の速度を恐れるようになる人が多い。だが,これまでの技術進化を振り返ってみると,その進化はゆるやかであることに気づくはずだ(表1)。


表1●開発実務者から見た,Web制作技術の進化
[画像のクリックで拡大表示]

 最近では,XHTMLとCSSで記述するWebページが主流になりつつあるが,これらは取り立てて新しい技術ではない。CSSは,約10年前に登場したIE 3.0で,すでに一部使うことができた。1998年頃から「構造と表現とデータの分離」という概念は少しずつ広がりを見せ始め,1999年~2000年にかけては,XMLベースのWebページ制作がエンジニアの間で大ブレークしている。最近流行のAjaxも,VBScriptによる類似の処理が話題になったのは,2001年~2002年頃だ。

 また,Flashについても,Future Splashの時代から使っていた人たちから見れば目新しいものではなく,プラグインのインストールがユーザーに負担をかけるかどうかという議論が,デザイナーたちの間で噴出していたのは1998年頃である。

 IT技術は,技術の登場からビジネスにおける普及まで数年以上かかるようだ。経営にかかわる人たちやエンドユーザーの間で盛り上がリを見せる数年以上前に,エンジニアの間ではブームが来ているのである。つまり,エンジニアの間でブームになったころから勉強を始めていれば,出遅れることはない。それに,ビジネス界での注目は1年は続く。仮に出遅れたところで,猶予期間は何年もあるのだ。

アプリケーションの運用と更新,プロジェクトの維持

 プロジェクトで多数の案件をこなし,バージョンアップやリデザインを繰り返しながら長期運用するWebアプリケーションが増えてくると,その運用とデータベースの更新,顧客サポートのためのプロジェクトの維持が課題になってくる。

 一度プロジェクトで手がけた仕事は,できるだけメンテナンスまで請負い,継続したいものである。Webは刹那的な媒体だ。メンテナンスやバージョンアップを他のプロジェクトや制作会社に譲ってしまうと,改善や進化ではなく,退行することがある。例えば,Web標準に添ったページが,旧来の表組みレイアウトに置き換えられたり,リデザインの結果が悲惨なビジュアルになったりする。これでは,過去の実績をリンク付きで紹介することすらできなくなってしまう。

 また,同じプロジェクトでメンテナンスしていく場合も,次々と新しい案件が降ってわくので,開発担当者が運用も担当できるとは限らない。メンバーの転職や病気,派遣会社からの通告,独立なども起こりうる。そのため,引継ぎ手順の標準化のためにも,第7回に書いたように,最終仕様書は必ず作成して保管しておく必要がある。

 さらに運用に新規受注が重なると,新しいメンバーの確保が必要になる。運用には真面目なコツコツ型が,新規開発にはベンチャー精神あふれるアグレッシブな人を迎えたい。

 新規開発のプロジェクトには,ITの未来のためにも,技術力のある学生を積極的に採用したいところだ。また,高年齢の異分野のプロも,開発に熱意があれば,多少時間はかかるかもしれないが,戦力になるだろう。ただし,キャリア採用の場合は,小さな仕事でもよいから,自分の力で何かやり遂げた実績のある人が望ましい。履歴書にズラリと列記された,過去に参加したプロジェクトの名前や数よりも,プロジェクトの中で実際に果たした役割のほうが重要だ。いくら勤続年数が長くて参加したプロジェクトが多くても,指示を待つタイプの人では,コラボレーションは難しい。

 また,安定志向があまりにも強すぎる人も難しい。チャレンジ精神ががなければ,「先進性」が「無謀」に見えてしまい,「リスクはないのか?」「それでいくら儲かるのか?」「その程度の利益であれば,最低限の仕事さえしておけばよい」などと言いがちになるからだ。

 これからは,近視眼的にならず,長期スパンで,IT業界の発展の中でのプロジェクトの利益を考える方針が,一層求められる。プロジェクトの方針を安定型が決定するようになっては,目先の利益ばかり追って,顧客へのサービスや新技術の追求,自己研鑽への時間の先行投資を避けるようになる。リスクをすべて回避したのでは,ローリターンどころでは済まずに,プロジェクト解散の危機すら訪れかねない。

 OSやプラットフォームや開発ツール,データ・フォーマットに関する仕様は,次々とバージョンアップを重ねていく。技術進化はゆるやかであっても,ビジネス・チャンスをつかむにはタイミングが重要だ。1分1秒を争うことだってあるだろう。情報の洪水の中で溺れないようにプロジェクトの進むべき方向をしっかりと見定めて,各々のメンバーが各々の目標を明確にして切磋琢磨していかなければならない。

おわりに

 本連載は,今回で,ひとまず終了とさせていただく。

 連載のタイトルが「コラボレーション『を』始めよう!」ではなく,「コラボレーション『から』始めよう!」であることに,注意してほしい。コラボレーションは出発点に過ぎず,決して終着点ではない。自分の限界を決めるのは,自分自身だ。

 「コラボレーションから始めて」異分野や異業種の仕事に触れてみよう。つまづくことがあるかもしれない。必ずしも参加したすべてのプロジェクトが成功しないかもしれない。方向性の違いから袂を分かつことがあるかもしれない。コミュニケーション能力を磨くどころか,逆に,人間不信に陥ることだってあるかもしれない。

 だが,異なる仕事に触れることは,発想の幅を広げてくれる。台風の目の中にいると,台風がわからないように,デザインから離れればデザインが見えてくるし,プログラミングから離れればプログラミングが見えてくる。ITから離れれば,ITが見えてくる。

 ボーダーを消そう,必要以上のセオリーを捨てよう,常識を超えよう,身をもって体験しよう。

 コラボレーションの経験は,社会の中での自分の位置付けを確認し,歩む方向を考えるきっかけを与え,一生の間になすべき仕事の輪郭を,くっきりと浮かび上がらせてくれることだろう。


本稿で述べたことは,複数のコラボレーターたちとの筆者の実務経験や,第三者の立場で見聞きした内容,同業者たちから受けた相談に基づくものである。必ずしも,すべてのデザイナーやエンジニアに当てはまるわけではないことをお断りしておく。


PROJECT KySS(プロジェクト・キッス)
薬師寺 国安(やくしじ くにやす,フリープログラマ)と,薬師寺 聖(やくしじ せい,個人事業所SeiSeinDesign自営,http://www.SeinDesign.net/)によるコラボレーション・ユニット。1996年,聖が勤務先で地域ポータルを企画制作,これを訪問した国安と知り合う。ActiveXユーザー同士で意気投合し,翌年「PROJECT KySS」結成。1999年よりXMLとDHTML利用のコンテンツ開発,2000年にはCMSツール開発と,一歩進んだ提案を行い続けている。XMLに関する記事や著書多数。両名ともMicrosoft MVP for Windows Server System - XML(Oct 2004-Sep 2005)。http://www.PROJECTKySS.NET/