Canon.jpを立ち上げたWeb仙人 | 書籍『失敗しないWeb制作』特別公開(1/4)
Webを運用する事業者からみた“PMBOK視点のススメ”
Canon.jpを立ち上げたWeb仙人
みどりかわ(以下、みどり) ■ Canon.jpのウェブマネジメントセンターの所長であり、「Web仙人」とも呼ばれるWeb担当者の大先輩でもある増井さんから、PMBOK的なWebサイト制作・運用の考え方を学びたいと思っています。よろしくお願いします。
本書は、もともと、フリーランスや小さな会社の新人社員など、手取り足取り仕事の進め方を教えてもらえず、Webディレクションにおいてクライアント折衝やチーム管理ができていないと感じている人向けに考えました。本を書くにあたって参考になると思ったのがPMBOKで、本書は、PMBOKの考え方を学んで取り入れようというのがひとつ目のテーマで、もうひとつは、さらに私の経験を踏まえたアドバイスまで提供するという2段階の構成になっています。
Webサイト制作をしている者からすると、PMBOKにはなかなか耳慣れない言葉などもあって苦労しました。今日は、いろいろなことを質問させてください。まず、どのようなお仕事をされているかから、うかがえればと思います。
増井 ■ 今日はよろしくお願いします。じつは、私にしてみれば、「PMBOK的でない Webディレクション」というのが逆にあまり想像できないのですよ(笑)。
ではまず、キヤノンWebサイトの成り立ちについて紹介しましょう。Webサイトを統括する組織は、会社によっていろいろな生い立ちがあるものです。私の所属する部署はWebの専任組織として2001年に発足したのですが、当時としてはWeb専任部署が存在するということは、かなり珍しいことでした。そのころのWebサイトは、広報部の一部であったり宣伝部の一部、会社によってはCS部(カスタマーサポート)など、必要にせまられた部門、あるいはやりたい人が自分たちで作ったものが企業サイトのもとになっていることがほとんどでした。
弊社も元々は、1990年代にNifty-Serveにドライバダウンロードサイトを立ち上げ、それをだんだんとWebベースに変えていったというのがはじまりでした。2000年から2001年にかけて大規模なBPRプロジェクト(経営情報改革プロジェクト)があり、その中のサブプロジェクトのひとつがWebプロジェクトでした。このサブプロジェクトの目的は、お客様向けサイトだけでなく、社内のすべての業務アプリケーションもWebアプリケーション(ブラウザベース)になる時代の到来にどう対応するかというものでした。そこでは、インターネットやブラウザベースの技術的な裏付けやマーケティングに活かすための社内コンサルのため、専門のチームが必要では、という論議がなされました。
これはもう誰かが片手間にWebをやる時代ではなくなる、と皆が感じ始めていました。それでこのサブプロジェクトのアウトプットとして、Web専任組織を作ることになりました。組織デザインをした後は誰かにまかせるつもりだったのですが、結局、当時インターネット関連新規事業の企画開発に携わっていた私が新組織の責任者を引き受けることになりました。2000年の10~12月で組織デザインをしたりメンバー招集を行い、経営会議で承認を経て、2001年1月に部署が発足しました。
みどり:増井さんが現職に就かれる前のお仕事は、どのようなものでしたか?
増井 ■ 入社時は営業、現職の直前はインターネット関連新規事業の企画開発部門で今で言うデジタルマーケティングの基盤になるような仕事を担当していました。一番職務歴が長いのはお客さま向けアプリケーション開発のSEや大規模プロジェクトのプロジェクトマネジャーで、15年以上ITの仕事に携わってきました。
みどり ■ SEですと、まさにPMBOKが業務のコアとなりますね。
増井 ■ そうですね。私自身がビジネス、コンテンツ、システムの3つの分野を横断した職務経験を持っていたのでこういったことができたのかな、と思います。
弊社Web専任組織の3つのミッションは、この図のとおりビジネスコンサルティング、コンテンツ集中管理、ITの集中管理という3つの柱から成ります。3つのミッションで立ち上げた組織ですから、メンバーもこのミッションの元に検討しました。3つの職務で構成された部レベルの組織です。
「Webマスター」というとひとりでスーパーマン的になんでもやるというイメージがありますが、企業の場合はサイト規模が大きくそういうことはできません。個々のメンバーを“コミュニケーション”、“コンテンツ”、“システム”の専門職種として位置付け、チームで「Webマスター」として機能するように組織を設計しました。
みどり ■ 部署とWebサイトの規模はどのくらいでしたか?
増井 ■ 人数は協力会社の常駐メンバーを含め約17名の組織ですが、コンテンツ担当が一番多くて、次がシステム担当です。“コミュニケーション”にあたるWebサイトへのお問い合わせ対応や社内コンサルティングは、少数精鋭で対応することにしました。この人員構成で、Canon.jpのお客さま向けコンテンツやサポートコンテンツを含む 約3万ページを担当しました。Canon.jpは、メーカーのキヤノン株式会社とキヤノンマーケティングジャパン株式会社が共同で運営していますので非常に大規模になります。さらにドメイン管理などのWebガバナンスも担当しています。
ブレなくサイト運用・制作発注を行なう
みどり ■ とても大規模なものですね。計画通りに進めるのは大変な仕事ですし、制作会社ごとに、ルールが変わったり、いつのまにか希望していた仕上がりから逸れていた、といった問題もありそうです。
増井 ■ 私たちの組織デザインやワークフロー、コンテンツのモデル、デザインポリシーなどは、最初からずっとこのひし形のWebマネジメントシステム(WMS: Web Management System)のメソッドに当てはめられるようになっています。最初にロジックを作り、フレームワークを設計した上で中身を埋めていくので、「勝手にできていた」のではなく、設計どおりにできあがるのです。
私たちは、Webサイト制作という仕事自体が、プロジェクトマネジメントそのものであると考えています。規模感にかかわらず、1ページの更新作業であっても、すべてPMBOKのメソッドが適用されるべきです。そういう発想でワークフローを設計しています。
みどり ■ このひし形を設計された際のヒントも、PMBOKにあったのですか?
増井 ■ PMBOK以外にも、Webマネジメントの事例や、2000年当時IBM社のEWM(Enterprise Web Management)という組織が使用していたメソッドを参考にしました。7つの視点でWebマネジメントを考えるというのは、海外では当時から支持されているメソッドですが、規模感を弊社の状態に合わせ設計し直しています。
みどり ■ 何か新しいタイプの作業が発生するたびにミッションを定義したりや組織を用意するのでしょうか。
実行責任(R: responsible)
説明責任(A: Accountable)
協議対応(C: Cousult)
情報提供(I: Inform)
増井 ■ そうではありません。ワークフローは自前で開発し、すべてシステム化しています。 Webサイト制作では事業オーナーとWebの担当者、制作会社という主に3つのリソースがありますが、ワークフローのシステムを開発する前に業務分析とRACIチャートの適用を行なって、それをシステムに盛り込みました。こうすることで、たとえばWMSを知らない新人スタッフが担当することになっても、しっかりと、WMSにのっとって仕事ができるように設計しています。社内で制作する場合は経費振替をしているのですが、その労務費清算のところまでシステム化されています。
みどり ■ 制作の途中に変更がでてきたりスコープが変更されるなどした場合、どのように対応するのでしょうか?
増井 ■ ワークフローのシステムは現在バージョン3まで改善が重ねられていますが、設計の時点で、考え得るすべてのWebに関係する業務フローを分析しています。最近だとソーシャルメディアをどう扱うかなど例外的なものは出てくるかもしれませんが、基本的なところはもれなく対応できると思います。たとえばメールニュースの配信、アンケートフォームの作成、大規模なリニューアル、Webアプリケーション開発…等々、様々な制作バリエーションを分析した上でシステム化していますからね。
みどり ■ 組織が創設されてからの最初の取り組みとして、その分析をされたと言われていましたね。モレなく作ろうとしたら、すごい数になると思うのですが。
増井 ■ 分析したものは「運用計画書」にすべて落としこみました。コンテンツの制作のパターンごとにすべてのワークフローを書き出しています。全部で約200ページありまして(笑)、3ヶ月くらいかけて整理しました。
みどり ■ 私がこれまで経験してきた中小規模の案件では、企業独自に細かい約束ごとがいくつかあるという程度のことが多かったです。
増井 ■ システム開発をするときは、必ずワークフローを書き出しますから、Webサイト制作の場合もそれと同じですね。私は、SEとして当たり前のことをやっているだけだと思っています。システム開発する前にワークフローの分析をしないと、お客さまの意図を反映した概要設計も基本設計もできないからです。
Webサイト制作で一番多い問題に属人化があります。属人化を避けるにはシステム化しなければなりません。システム化するには属人化しているところを、まずすべて棚卸してみる必要があるわけです。ワークフローの棚卸や整理については、システムエンジニアリングで一般的に使われるテンプレートも適用できると思います。そこに出てくる登場人物やプロセスは、Web制作独特のものもありますが。
みどり ■ Web業界には最初にワークフローを作る文化があまりないですね 。
増井 ■ 「いつもなんとなく始まって、なんとなく誰かが何かをやってくれる」という状態や、詳しい担当者がいなくなると更新さえされず放置されてしまう、という状況は問題だと感じます。
みどり ■ まさに属人化している問題です。いまご紹介いただいたポリシー類は、2001年から同じもので運用可能なのですか?
増井 ■ 時代の変化に即して改訂はしていますが、同じものを使っています。2001年に組織が発足したとき、最初にまず「規程」を作りました。Webサイト自体のミッションや、事業オーナーの責任や義務、そして Web管理部門の責任や権利、義務をまず規程に明記しています。それを経営会議にかけて「会社規程」としました。
みどり ■ 規程ということは、会社規則に準ずるような、強いルールになりますか。
増井 ■ そうですね。会社の公式な規程、つまり人事規程などと同じようなものですから、ガイドラインなどより強いルールになります。可能であれば、順番としてまず憲法にあたる規程を作ることをお勧めします。 WMSの構築手順としては、上の図にあるように、まずミッションを明確にし組織を明確にします。新規の仕事が入った際、最初に行なう「掲載申請フローの申請」が、5項めの「運用プロセスの再構築と徹底」というところにあたり、システムを開発する前段でワークフローの分析やRACIチャートの適用を行ないます。
みどり ■ 「フローを洗い出してから」は私も強く共感しました。それができていないために振り回されてしまうWebサイト制作者が多いと感じています。私もかつてそうでした。Webディレクターとして経験を積んでいく中でPMBOKという体系を知り、そのような取り組み方を広めたいと思いました。
『失敗しないWeb制作 ~プロジェクト監理のタテマエと実践~』
この記事は、書籍 『失敗しないWeb制作』 の内容の一部を、Web担向けに特別にオンラインで公開しているものです。
Webディレクションをめぐる知識やスキルセットは、さまざまなセミナーで議論されるホットなアジェンダです。本書は、Web制作のプロジェクトマネジメントに特化してキャリアを重ねてきた著者のノウハウを凝縮し、「効果的な仕事の進め方(計画、レビュー、チェック)」にフォーカスを絞り込んだ内容となっています。
下敷きにしたのは、プロジェクトマネジメントの知識体系PMBOKです。ただし、PMBOKに限らずフレームワークの多くは、よほど実経験の中で研鑽を重ねない限り血肉化しません。そこで、著者の体験をもとにしたプロジェクトでの実践方法を解説しています。
ソーシャルもやってます!