PR

 前回まで「画面設計書」について書いてきました。今回は,画面設計書も含めた「ドキュメント」を,どのようにとらえるべきかというテーマを取り上げたいと思います。

 今回お伝えしたいのは,ドキュメント作成のプロセスを定めることは,実はかなり大きな決断だということです。ドキュメントは作成に手間のかかるもので,どうしてもコーディングに比べれば後追いの形になります。しかし,記録や技術資産という意味で価値あるものであることには間違いがありません。だからこそ,慎重に取り組むべき事柄なのです。なお,以降でいくつか私流の考え方を列挙しますが,どれが本当に良いかは,もちろん皆さん自身の考え方や環境によります。

ドキュメント記述の責任と分担が明確になりつつある

 ドキュメントを記述するツールにはどういったものを選べばいいのでしょうか。小さな組織であったり,短期間の開発であったりするなら,今まで自分が慣れ親しんできたツールや興味のあるツール,あるいは効率が良さそうだと“勘”がはたらくものなど,様々な基準で選ぶことができます。

 しかし,現実的にWebサイト構築を「仕事」としてこなしていくためには,もう少し別の視点が必要になります。「(開発)チームとして,ドキュメントを書き続けることができるかどうか」という視点です。一個人の趣味や志向性ではなく,“組織”としての視点です。

 私が,エンジニアリングの世界に入ったのは,1990年代初めのころです。そのころの環境は,ドキュメントは書くべき個所の担当が決められ,その責任をほぼ完全に負う,というものでした。誤字脱字のレベルから,修正するのは書いた本人であり,他の人が修正するのは,非常にまれだったと記憶しています。

 その後,いくつもの組織を渡り歩きましたが,基本的には「誰もが,いつでも修正できるようにしよう」という姿勢が,どの企業にも広まっている気がします。つまり,誰もが持っているソフトウエア(例えば,Microsoft Officeや一太郎など)でドキュメントを記述するという方式です。これによって,ドキュメント記述に共通に使われるソフトは,誰もが知っているべき「リテラシ」の一部として,その組織の中で常識化されます。

責任と分担

 一人で全責任を負って記述(執筆)するのではなく,内容に対する責任は執筆者が負うにしても,修正は誰もが可能な状況に分担しておく,というのが主流になりつつあるようです。

Webサイトの開発は「多品種少量生産」

 こうした流れに反対するわけではないのですが,少し気になる状況を私は最近考えています。それは,工業製品の生産ラインについてのテレビの番組を見たときに,何かしら共通点があるように感じたからでした。

 私自身は,様々なものが大量生産される時代に生まれ育っていたせいか,ベルトコンベアに人が並んで,それぞれに決められた単純作業を,それぞれが担当し,それらの集合体として「完成品」ができあがる,という生産プロセスになじんでいます。

 しかしその番組では,ベルトコンベアの横に人が並んで生産していく「ライン生産方式」に対して,少数の人間が製品完成までを担うという「セル生産方式」の紹介をしていました。

 「セル生産方式」は誰でもできるものではありません。何百という部品のつなげ方を正しく理解し覚えるのは,容易ではないからです。しかし,番組中に紹介された事例では,「最後まで責任を持って完成させる」という課題が,作業者のモチベーションを向上させ,生産性や品質が向上させるというものでした。しかも完成した製品には,作業者自身のサインが刻まれます。責任とともに作り上げる喜びがある,と語る作業者の姿が印象的でした。

セル生産方式とライン生産方式

 いきなり工場のセル生産方式の話をするので唐突に思えたかもしれません。しかし私には,セル生産方式とWebサイト開発には「多品種少量生産」という類似点があるように思えます。

 セル生産方式が登場した背景には,一つひとつ微妙に異なる製品を少しずつ作るという多品種少量生産というニーズがありました。実はWebサイトも同じなのです。

 インターネット上に無数に存在するWebサイトは,それぞれ異なります。どんな制作会社にとっても,サイト自体もドキュメントも「唯一」のものです。しかし,業界が同じだったり,近かったりすることで,何かしらの再利用は可能です。この,再利用しながらも「唯一」のものを作るというプロセスが,まさに多品種少量生産そのものなのです。ならばセル生産方式で成功したノウハウが,Web開発でも応用できる可能性があります。

 正確に調査したわけではありませんが,Web開発のドキュメントは最近,誤字脱字の発生やつまらないミスが多発している気がします。それも,冒頭に書いたように,細かく役割分担され,一人が書き上げるという「責任感」が薄まったころから,ミスが増えている気がするのです。

 もちろん,Webサイト開発はきわめて短期間の開発であることが多いので,ミスが起こりやすくなっているのは事実です。しかし,誰もが修正できるということは,誰かが修正してくれる,という感覚を知らず知らずのうちに期待しているような気さえするのです。

デコボコチームと平均点チーム,どちらを選ぶか

 さらに,もう一つ考えてみたい点があります。それは「ドキュメントの最終的な目的は何か」という点です。それは対象とする読者に一番有効に情報を渡すことだと思います。だとしたら,それを一番有効に実現する方法が何かを考えるべきでしょう。

 Webデザインは歴史の浅い分野なので,古くからデザインという業務にかかわってきた人たちが中核になっているという側面は否定できません。多くの場合,前職で培ってきた「技能」は様々な作業の中に見え隠れします。

 ドキュメント作成術もそのうちの一つでしょう。特定のツール(ソフト)を使えば,説得力のあるドキュメントを作成できるのに,同じような機能をもっている別のツールを使うと,普通の機能なら使いこなせない人がいます。

 例えば私は,Adobe Illustratorが好きで,絵を描くというよりも,情報を整理するのにこのツールを使っています。広いキャンバスにキーワードを自由に並べて,その位置を色々と動かしながら情報のグルーピングをしていきます。同じように絵が描けるツールはたくさんありますが,他のツールでは思考が鈍ります。また,テキスト・エディタにしても,個条書きをする場合にはvivi,HTMLを書くときには,Crescent Eveなどと,同じテキスト記述でもツールを使い分けています。

 そうした,よく言えば「こだわりのある」,悪く言えば「偏屈な」人材の特殊能力を生かしながらチーム体制に組み込んでいくのか,それとも皆同じリテラシにそろえていくのか,というチームの方針決めも大きな意味を持ちます。

デコボコチームと平均点チーム

 昨今の流れは,基本的には誰もが均一なドキュメントを作成できるようにする,という方針の下に形成されているように見えます。それは,ドキュメント作成の「効率」を重視しているためです。しかし,特定の人間の特殊な能力を生かすほうが,ドキュメントの「効果」が出る,という視点も大切だと思えるのです。

 私が今までで一番驚いた提案書は,スケッチブックに描かれたものでした。すべて手描きで,写真のコラージュもありました。まさに「世界に唯一つ」の提案書で,手に取ったインパクトの大きさは,複製可能なデジタルのドキュメントとは重みが違うと思ったものです。しかし,そんなすばらしい提案書を書ける人が,Microsoft Wordで作成した提案書は,これまた驚くばかりにつまらないものでした。

 二つの提案書を見比べて,長所を生かしたほうが効果があるのかもしれないと,思わされたのは言うまでもありません。確かに常にスケッチブックで提案書を作るとなると,それはそれで大変なことがあるのですが,ここぞというタイミングでは使いたいと思わされました。

プロジェクトの性格に応じて人材やツールを有効活用すべき

 では,どのように,そうした特異性のある人材やツールを許していくべきでしょうか(あくまで,基本は標準ツールが存在するという立場であるべきだとは思っています)。それは,その“プロジェクトの性格”によるのではないかと思います。プロジェクトは,何も売り上げを立てるだけのモノではありません。長期的な視点に立つならば,教育的側面や,チームの協調性を育てることを目的にする場合もあります。

プロジェクトの性格

 開発チームとは,様々なタイプの仕事を通して,技術も協調性も磨かれていくものです。したがって,そのプロジェクトの性格を見抜き,自チームの状況や将来ビジョンを見直して,適材適所的に様々なチャレンジがあっても良いのです。

 そうした,プロジェクトの性格,プロジェクト・メンバーの性格,適正,特異能力,未来を見据えた中長期計画――これらを秤にかけながら,ドキュメント作成プロセスを育てていくことが,良い開発を行うことの礎になっていく気がします。そして,もちろん,ドキュメントは「生き物」ですので,常に「配布・修正・管理」というサイクルを繰り返しながら,プロジェクト達成サイクルも回していくのです。

ドキュメントのライフサイクル

 そうした積み重ねをすることで,ドキュメントは開発チームの優秀度を表すバロメータ的な役割さえ果たします。良いドキュメントを書けるチームが必ずしも良い仕事をするわけではありませんが,良い仕事をするチームのドキュメントはどこか人を唸らせるものが潜んでいるものです。常に,クライアントを唸らせるようなドキュメント作りを目指したいものです。


三井 英樹(みつい ひでき)
1963年大阪生まれ。日本DEC,日本総合研究所,野村総合研究所,などを経て,現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と,エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や,RIAコンソーシアム日刊デジタルクリエイターズ等で活動中。Webサイトとして,深く大きくかかわったのは,Visaモール(Phase1)とJAL(Flash版:簡単窓口モード/クイックモード)など。