コンクリートファイブジャパン 菱川です。
concrete5 の東京ユーザーグループによる勉強会／交流会「concrete5 Meetup Tokyo」では、毎回担当者を変えて「テーマ」を設定し、様々なトピックを取り上げて開催しています。弊社では、このようなコミュニティによるイベントの企画運営の支援も行なっております。
8月は私が担当の回でしたので、以前からやりたかった企画「CMSプロジェクトマネジメント標準化会議」を開催しました！
プロジェクトマネジメントという正解のないテーマでしたので、ディスカッションを中心においた構成としました。現役のディレクター達による生々しいトラブル事例が飛び出したり、より良いディレクションのためのアイディアを出し合ったりと、熱い議論が交わされ、久々に「参加してよかった勉強会」を作れたんじゃないかと思います。
終了後も熱の冷めやらぬ参加者が会場に残り、終電までアツい議論が続いていたのが印象的でした。現場の空気を感じたい方は、当日の実況ツイートをまとめたtogetterまとめをごらんください！
https://togetter.com/li/1141702
CMSプロジェクトマネジメント標準化会議とは？
Web制作業界に当たり前のように存在するCMS案件。
しかし、CMSに特化したプロジェクトマネジメント手法はまだ確立されていません。
うまくいくプロジェクトもあれば、炎上案件も多数存在するのが現状です。
勉強会やカンファレンスでは、炎上の鎮火方法は割と共有されますが、
そもそもどうプロジェクトを進めるべきだったのかが分かっていれば、
こんなことにはならなかった…ということ、ありませんか？
作業の途中で追加要望が次々に発生…
標準機能でできると想定していた要件で、着手後にクライアントNGが発覚…
同じテンプレートを作り直すの、なぜかもう３回目…
デザインが自由すぎてページごとに新しいテンプレートを作成中。これCMS化の意味ある？
公開来週だけど、まだデザイン来てない！コーディングして、テンプレート作って、コンテンツ移行は？
今回の concrete5 Tokyo Meetup は、そんな炎上案件を撲滅するためのWebディレクター向けの企画です。
告知文より引用
レポート
ここからは、実際の勉強会の内容をレポートしていきます！
ライトニングトーク
まずは、参加者にCMSプロジェクトマネジメントにおいて、発生する問題点とはどういうものがあるのか？という意識を共有していただくため、数人の方にライトニングトークをお願いしました。トップバッターは、開催場所を提供していただいている株式会社ロフトワーク クリエイティブディレクターの菊地 充さんです。
CMSの実装について、仕様書という形でできる限り縛ろうとしているが、仕様書のミスやお客様の要望で、どうしても変更は発生してしまう。見積もりの根拠となった仕様が変更されたのだから、追加費用がかかるのは仕方ないと思いつつ、最初に想定していたバッファを超えてしまい、最終的にいくらになってしまうのか分からなくなってしまうこともあり得る。もっといい感じに柔軟に開発してもらえないかな〜という心の叫びで会場の共感をさらっていました。
また、昨今のWeb制作事情についても補足。昔はCMSに求められることが単純だったため、仕様書で決めて、決められた方法で更新すれば、決められた箇所に反映されるというやり方でよかったが、最近ではクライアントの要求水準が高まっており、変えられないところは基本的に無くして欲しいという要望が増えていると指摘されていました。そうなると、ますます仕様を決めるのが大変になります。
菊地さんのお話は、仕様書と現実との違いについて、現場からの問題提起でした。敏腕ディレクターの菊地さんの最近公開されたインタビュー記事が面白かったのでリンクしておきます！
「自分でやったほうが早い病」から寛解、ニュートラルで独特だけど、自称「普通の象徴です」。シニアディレクター菊地充インタビュー
次のトークは、株式会社Brassica 代表取締役の古荘 貴司さんです。
古庄さんは野菜を作ったりもしていますが、Brassicaは日報ツールとCMSの開発をやってる会社。古荘さんのSOY CMSは、デザインの凝ったECサイトでも作り込めるようなCMSですが、そもそもCMSを作ろうと思って作った訳じゃないということでした。
どんなに最初に頑張って話を詰めても、最後に仕様を変えろと言われる。しかも、リリース直前の変更が、開発側にとって一番しんどい。であれば、要件定義もそこそこに開発・実装に入り、出来上がったところからお客さんに確認してもらうというワークフローの方が良い！ということで、それを実現したのがSOY CMSということでした。
他のCMSを使っている人にもオススメなのがhouren.so。農場というのは、最もIT化されていない生産現場。農作業でクタクタの状態でも可能なレベルの共有が、スマートフォンで写真を撮って共有するだけというところに落ち着いた。写真にコメントをつけるだけで日報ができる。モバイル時代で最も強力なコンテンツは写真なので、コンテンツが自然と集まるので、他のCMSをやっている人でも、お客さんに提案してほしいということでした！
concrete5 の勉強会ですが、他のCMSの開発者の方が来られたので、当日お願いして急きょ特徴などを紹介いただきました。まさにプロジェクトマネジメントの改善のために産まれたCMSということなので、参加者のみなさんにも参考になったんじゃないかと思います。
次に、参加されていたMT東京・幹事／慶應義塾大学大学院政策・メディア研究科特任准教授の常盤 拓司さんが飛び込みLT！SOY CMSに続き、Movable Typeのお話です。
常盤さんは、大規模なWebサイトの構築から運用まで手掛けておられている方です。今年リリースされるMT7の紹介をしていただきました。気になる方は、MTDDC 2017に参加されると良いと思います。
MT7プレビュー！ MTDDC（Movable Type Developers & Designers Conference）2017 開催
今日の議論の頭出しとして、「共創」というキーワードをご紹介いただきました。紹介された「上手くいく！みんなでつくるウェブサイト」という資料は、こちらのURLからダウンロードが可能です。
http://www.allianceport.jp/process/
最後に、株式会社mgnのメガネさんこと、大串 肇さんが登壇。メガネさんは前職で一緒にCMSプロジェクトを手がけた経験もあり、以前から個人的に信頼しているディレクターですが、今では実力も華やかさも兼ね備えたWeb制作業界のスターのおひとりです！
トークでは、メガネさん謹製の「誰でもできるCMSプロジェクトマネジメント、これでバッチリだ！」という資料を紹介していただきました。5〜6時間分はあるとのことなので、紹介のみでしたが（汗）
資料で紹介されていることを全部やっても、まだ困っているというメガネさん。その理由は、できるディレクターは案件を回せるが故に、どんどん案件が集まってきてしまい、いつまでたっても忙しすぎるからではないか？と分析。今回の企画で、ディレクターが増えれば、解決するんじゃないかと語り、笑いを取っていました。また、どんなに手を尽くしても防ぎようのないちゃぶ台返しなどは、「へこまない」ことが大事と力説していました。
ディスカッション
ディスカッションでは、４チームに分かれて、CMSプロジェクトマネジメントにおけるリスクを出し合い、それに対する対策を話し合いました。各チームで自由に問題の分類を行い、白熱したディスカッションが行われました！
チーム発表
１時間のディスカッションのあと、各チームから話し合った内容の発表がありました。
チームA
このチームは、問題をデザイン、設計、スケジュール、コミュニケーションで分けているのが印象的でした。
デザインでは、納期遅れや、テンプレート化しづらいバラバラなデザインが出てくるなどの問題点が上がったようですが、最初に確認事項をまとめておいたり、ガイドライン（そのサイトで使うパーツをすべて並べたページ）を作成して、デザイナーもエンジニアもそこに立ち返るようにすることである程度の回避ができるのではないかということです。
設計では、機能が山盛りになったり、テンプレート数がどんどん増えてしまう問題については、お客さんの業務を効率化する観点から、お客さんと機能の取捨選択を話し合うことが必要ではないか。スケジュールでは、確認するフェイズを細かく分けることが必要ではないかと提案がありました。
コミュニケーションにおいては、CMSならではの現象として、機能のイメージがつかないためにクライアントとのコミュニケーションが滞ってしまうという問題の共有がありました。これに関しては、積極的にデモを触ってもらうことが効果的とのことです。
最後に、仕様書をゴールにしない、最終的にクライアントと制作側で協力してできあがったものがゴールであるという意識合わせをすることが大事ではないかとまとめられていました。
チームB
チームBでは、問題意識として、CMSが万能だと思われているため、更新しづらいデザインを要求され、うまく実装できずにマニュアルに「触らないでね」と書いて納品するような不幸なケースをなくすという方向で話し合いが行われたようです。
意識合わせを行うために、見積もりのテンプレートを作ればいいのではないか？という結論になったそうで、できた見積もりテンプレートがこちらです！
個人的には、「納品」という見積もり項目があるのが印象的でした。確かに、やる作業も多いですしクオリティにも関係するので、良い整理の仕方だと思いました。
チームC
このチームは、提案、設計、制作、納品・検収に分けて問題を整理していました。
提案時点では、要件の本質を共有することが大事。ヒアリングシート、計画書を作りましょうと提案していました。計画書は仕様ではなく、コミュニケーションや予算管理をどう進めるかを合意するものです。
制作時点では、コーディング規約で無駄なコミュニケーションを削減しつつ、コミュニケーションコストが発生することはあらかじめ想定して人員配置やスケジュール管理を行いましょうと指摘されていました。
あとは、勉強会に出ていろんなCMSに詳しい人と知り合いになろう！予算交渉の話術を磨こう！など、属人的スキルの向上について話が出ていたのが面白かったです。
チームD
最後のチームは、問題点を深く考察したようで、トラブルの理由の多くは、何のために何を作るのか、ゴールの設定ができていない、作るものが分かっていないことに集約される、と発表されていました。専門家しか分からない状態で話をするのではなく、できるだけ早くCMSのデモを動かし、動いているシステムを見ながらクライアントと話をすると意識共有ができて良い、と発表されていました。
まとめ
企画段階では、このようなドキュメントを作ればオールオッケー、というような、ツール論に話が流れることも想像していました。ところが、冒頭の菊地さんの発表のおかげで、仕様書をどんなに細かくしても解決できない、という共通理解からスタートできたことで、もう少し踏み込んだ会になり、参加者の満足度も高かったようです。
実際に、PMBOKなど広く使われるプロジェクトマネジメント手法はすでに存在し、弊社のプロジェクト管理にも参考にしているのですが、あらゆるプロジェクトに普遍的に適用できるものではないと考えています。クリエイティブのみが問題になるプロジェクトでもなく、システム開発のみが行われるプロジェクトでもなく、その中間に位置するCMSプロジェクトのマネジメントには、独特の問題があります。
弊社では、concrete5そのものに詳しいことは当然として、いかにスムーズに、かつ成果を上げる形でconcrete5というCMSを導入していただくかについて、常に試行錯誤を続けております。また、要求通りに実装するというよりは、concrete5というCMSを上手に活用していただくための提案力も重視しています。concrete5を導入するメリットが減ってしまうようなご要望に対しては、あえて反対し、別の方法をご提案することもあります。
今回の勉強会を経て、そのような弊社のノウハウをまとめた「CMS設計ポリシー」を策定し、全てのお客様に見ていただくと良いのかなと考えました。近いうちにまとめてみたいと思います。
今回の企画も１回きりでなく、次のディスカッションに繋げていきたいと考えています。
次回の concrete5 Tokyo Meetup は？
9月8日は、「concrete5導入事例"深掘り"紹介」と題して、弊社も運用のお手伝いをしている武蔵野音楽大学ウェブサイトの事例をご紹介します。
参加登録はこちらのDoorkeeperのイベントページからお願いします。
