東京のWeb制作会社「キノトロープ」のワークショップに参加した。

ワークショップの内容は、キノトロープで行なわれているワークフローについてである。
キノトロープは業界では有名な会社で、クライアントには多くの大企業が名を連ねている。いわゆる業界トップの会社がどのような考え方で仕事をおこなっているのか？多いに参考になるのではないかと思い、参加したのである。

Web制作には多くの人間がプロジェクトに参加する。「デザイナー」、「エンジニア」、「クライアント」など、それぞれ考え方が全然違うので、いかにして情報を共有し、認識統一すればよいのか？プロジェクトの規模が大きくなればなるほど、難しい。

今回、説明していただいたワークフローは、仕事の段階ごとにドキュメントを作って承認を得ていくというものである。そのワークフロー自体は、組織のしっかりした企業、得に大企業では当たり前のように行なわれていることで、目新しいものではない。しかし、キノトロープが素晴らしいのは、それが会社全体のシステムとして徹底されており、安定して高品質のWebサイトが提供できるということである。

会社のポリシーがワークフローという仕組みに組み込まれているので、スタッフ全員が会社のポリシーを反映した仕事ができるのだ。まさに仕事の標準化である。

私は以前、いわゆる大企業と呼ばれているところに勤めていたので、キノトロープのような仕事の考え方は理解できているつもりである。今の会社でもその考え方は軸となっており、試行錯誤をして資料を作っている。しかし、自分がもし今の会社から去ったとき、その考え方は後の人には引き継がれるだろうかと思うと、引き継がれるところまでいっていない。自分の仕事のやり方として一人で実施しているだけである。

キノトロープはスタッフ全員が「会社の志しに同意し、それを実行できる仕組み」を作り上げることによって、クライアントの信頼を獲得し、お客を選べる立場になっているのだ。

代表取締役の生田さんは
「ページ単価1万円でしか仕事をくれないお客さんは、ページ単価2万円の仕事をくれるようには絶対ならない。そんなお客は切っちゃえばいい。」

とおっしゃっていた。お客を切るということは、自らの品質に自信を持たなければできない。

自信を持つための取り組みを続けてきた結果が、キノトロープという組織を作り上げたのである。

何よりも刺激を受けたのは、説明をしてくださったディレクターをはじめとするメンバー全員の表情が大変印象的であったことである。自信に満ち溢れながらも、謙虚さのある、いわば「ゆとりのある」雰囲気をかもし出していた。

今回、ワークショップには関西を中心とした多くの制作会社が参加していたと思われる。スタッフの多いキノトロープだから、きめ細かいワークフローが可能なのだと感じた人も多いだろう。しかし、そんな考え方を持っていては一生変わることはできない。

我々は日々の締切りと価格競争に追われ、品質を上げていく努力をしているだろうか？惰性で仕事をこなしていないだろうか？今回のワークショップは、私に大きな気づきを与えてくれた3時間半であった。

私のお気に入り度：★★★★★

今回から３回に分けて、私が最近読んだネットコミュニティに関する書籍を紹介する。理由は今の仕事に密着しているからである。

以前の記事で、コミュニティサイトの設計に取りかかっているということを述べた。

コミュニティサイトを設計するのは、私ははじめてである。設計だけで費用をいただけるという案件。設計はまだ要求定義（クライアントの希望をヒヤリングし、まとめること）の段階だが、設計だけでは終わらずに構築を進めることになった。

どうして企業はコミュニティサイトを作るのだろう？

「人の集まるところにビジネスが生まれる。」
理由はこれである。

ビジネスを生むようなコミュニティを作るには、戦略が必要となる。

今回紹介する本は、AOLやAdobe、eBey、Yahoo!など、かなりメジャーなコミュニティサイトを設計してきたエイミー・ジョー・キムという人の著書である。

この本のサブタイトルは【ビジネスに直結した「場」をつくる】。私が求めていた情報とピッタリ一致した。

この本には、コミュニティサイトの設計に必要な「９つのデザイン戦略」が事例を交えながら書かれていた。その戦略は、成功するコミュニティサイトのどれを取ってみても当てはまる戦略である。
どれも分かりやすく、イメージしやすい。自分の仕事に間違いなくプラスになるだろう。

この本は２００１年に出版された本である。３年前の本。Web業界は進歩が早いので、数年前の本はすでに古く読む価値はないという判断をしてしまいがちだが、もったいない話である。

実際、この本には「ブログ」も、「ソーシャルネットワーキング」というキーワードも出てこない。しかし、これらの形態を持っている成功サイトにも「９つのデザイン戦略」は見事に当てはまるのだ。

この本から学んだことはまだある。コミュニティサイトに限らず、Webサイトは「人」があってナンボ。人同士のコミュニケーションツールなのだ。よって設計する前に、まず人（サイトを使うユーザー）について理解しなければいけない。クライアントをヒヤリングしていると、つい

「あのサイトのああいう機能って便利だから組み込んでちょうだい。」
などという話が先行しがちである。

Webサイトを設計するにあたっては、仕組みに溺れてはいけないということを肝に銘じておく。

ネットコミュニティ戦略―ビジネスに直結した「場」をつくる　2,310円（税込）のより詳しい情報はこちら

今日はコミュニティサイト関連の書評シリーズはお休みにして、私の今の状況を残しておくことにする。

最近たびたび話にでてくる、コミュニティサイトの打ち合わせがあった。

要求定義書、簡単な画面遷移図を作成したあと、クライアントの想像力を点火したような感じだった。あれもしたいこれもしたいという状態で、要望が膨らみすぎてしまった。

予算的に可能な範囲はすでに超えていると思われたので、膨らんだ要望と私のさらなる提案も含めて、プログラムのアウトソーシング先に見積もりをお願いすることにした。このまま綿密な打ち合わせによって膨らんだ要望を仕様書にまとめても、見積もりで予算をはるかにオーバーしてしまっては、モチベーションが下がってしまう。

夢を語っているときに現実的な問題を突きつけられ、自分たちの議論が文字通り夢物語になってしまうようなものだ。

見積もり結果
「小林さん、この機能をすべて実現するとなると○百万円になってしまいますよ。」

遙かに予算オーバーであった。そこで、コミュニティを機能させ、他サイトと差別化をはかるための【必要最小限の機能】に絞り、再度数社に見積を依頼したのだ。

その結果、ようやく現実的な予算に収まった。
その中でも、今回は新しい取引先にお願いすることで話が進みそうである。

まずは必要最小限の機能で構築し、ユーザーを集め、ユーザーの声を聞きながら機能を充実させていくという方向で、クライアントには納得していただいた。

アウトソーシング先への発注段階になったので、仕様書を作らなければならない。仕様書とはサイトの設計図である。

機能リスト、機能ごとの画面遷移、全体の画面遷移、ユーザークラスの定義（サイトを使用するユーザーの分類）、そのユーザークラスがどの機能を使用できるのかを示したリスト、サーバー条件、仕様書に出てくる専門用語解説、これらのことを網羅した「要求仕様書」というものを作成した。

発注前の段階でここまでの資料を作成したのは、今回が初めてである。
今までは大まかな見積もりをもとに発注後、クライアントとの間で仕様を決め、その仕様をアウトソーシング先に渡していた。

この流れには大きな問題があった。アウトソーシング先が思い描いていた機能と、こちらが提出した仕様書の機能のギャップである。こちらは大まかな見積もり依頼時に提出していた概要を具体化しただけだと思っているのにだ。

「この部分は別途お見積もりとなります。」
こんなことを言われることもあった。もともとギリギリの予算なので、別途見積もりなどできない。かと言ってクライアントに予算オーバーですと言うのも恥ずかしい話である。それは、いくらで構築しますとクライアントに言ってしまった後に、クライアントと一緒に仕様を作ったからである。

その仕様が予算オーバーってなんでやねん。ということだ。

アウトソーシング先とのギャップを埋めるために
「発注前にできるだけ仕様を固めておき、それを具体的にドキュメント化しておく」というのは、大きな課題だったのだ。

さて、本日クライアントとの打ち合わせにて、こんないきさつで制作した「要求仕様書」は無事、承認を得ることができた。事前に仕様書を提出していたのだが、内容的に難しいので、イチから説明が必要かなと思っていた。しかし、クライアントは読むだけで内容がよく理解できた、よくできていると言ってくれた。

ドキュメントは読むだけで理解できなければならないものだと、以前の職場でたたき込まれた。その訓練の成果は今でも身に染みついているようだ。

今回の承認をもって、来週にはアウトソーシング先と打ち合わせを行う予定である。

年末ギリギリまで仕事は続く。