「CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする」は案件を選ぶ

スポンサードサーチ

よつばデザイン　後藤さんのブログ「「CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする」を読んで」から知ったコンクリートファイブジャパン株式会社　代表取締役　菱川拓郎さんの「CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする」ですが、私はいくつか違和感を感じました。

「動くプロトタイプを作る」という点においては、全くその通りなんですが、この違和感はあえてなのか語っていない話があるのに「先にCMSを導入」という結論に至っているからだと思われます。

それは、以下の3点です。

• 違和感その1　「クライアントゴールの共有」と「デザインカンプ」の問題は異なる
• 違和感その2　「可視化」の話と「CMS導入」は別
• 違和感その3　「向いている案件」と「向いていない案件」がある

この3点について細かく見て行きましょう。

違和感その1　「クライアントゴールの共有」と「デザインカンプ」の問題は異なる

CMS案件に関わらず、案件で考慮すべきことは、「クライアントゴールが実現できるか」ということです。

クライアントゴールがあって、それを実現するための手段としてCMSの導入があるため、実現したいゴールや業務フローによっては、CMS導入自体の可否も検討すべきです。

また、クライアントゴールを明確にした後に行う、「要件定義」「基本設計」「画面設計」「詳細設計」といった作業も全てクライアントゴールを実現するためのものです。

つまり、各作業段階において、クライアントとチームメンバー全員は、クライアントゴールの共有をしていなければ、最適な結果は生まれません。

ところが、この「デザインカンプをクライアントに確認させるのが最適な手段なのか？」の章で語られるのは以下の話です。

完成形が頭に描けていないまま、とりあえず無いと後ろの工程に進まないから作るワイヤーフレーム。どう動くのか頭に描けていないまま、とりあえず無いと進まないから作るデザイン（しばしばワイヤーフレームと違うデザインを作るな！と怒られる）。デザインカンプでクライアントのOKが出ちゃっているので、CSSでこんなんできるか！と思いながら、無理矢理何とかするコーディング。最後に、こんな機能があるなんて聞いてないよ〜と言いながら無理矢理PHPをコピペしてそれっぽく動作させるCMSへの組み込み。結局、あとから無理した分の余計なCSSの記述やたくさんダウンロードされる細かい画像パーツをダウンロードするはめになるユーザー。みんなが不幸なんです。

これ、デザインカンプの話よりも、クライアントゴールを理解せずにデザインやコーディングしたり、要件定義していない機能が後から追加されたりする方がまずくないですか？

この話は、「デザインカンプでクライアントのOKが出ちゃっている」＝「クライアントはゴールを理解している」と判断しているんだと思いますが、誰もクライアントゴールを認識出来てないですよね？

この、「クライアントとメンバー間で、クライアントゴールが共有されていない」という事の方が問題だと思うのですが、そこはスルーされてしまいます。

そのためこのチームの場合、「動くプロトタイプを作る」ようにワークフローを変えても、いつまで経ってもクライアントがプロトタイプを気に入らないことになると思われますし、これは「デザインカンプを作らない」という話とは全く別の問題です。

違和感その2　「可視化」の話と「CMS導入」は別

引用されている「「今のレスポンシブWebデザインは誤解されている」英の著名デザイナーAndy Clarke氏が話す3つの修正点」では、「モックを事前に作らずにブラウザでデザインする」ということしか書いておらず、CMSの話は出てきません。

私は Andy Clarke氏の話は、「可視化」という点がポイントだと思っています。

つまり、デザインカンプでは実際の端末におけるナビゲーションや動き、情報設計上の重要度等がクライアントに伝えられないので、実際にプロトタイプを作って「可視化」しましょう、という認識です。

確かにCMSを入れることで「モックを事前に作らずにブラウザでデザインする」ことは、制作会社のCMSに対する理解が高く、案件にマッチしたCMSの場合には比較的簡単にできるようになると思いますが、CMSを入れる事で制限が数多く出てしまうこともあります。

また、CMS案件というのは、運用業務フローの改善や効率化がクライアントゴールであることが多く、クライアントにとってはインターフェース設計やユーザービリティ設計の変更を行うのに使うためにCMSを使うことは別に要件ではありません。

デザイン制作サイドとしてもCMSを先に入れた場合、そのCMSに対する理解度が高くなければ初期構築や変更等をし難いケースもあります。

つまり、CMSを先に入れる事は、「可視化」を行うための十分条件ではあっても、必要条件ではありません。

違和感その3　「向いている案件」と「向いていない案件」がある

「CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする」で理想とするWeb制作フローは以下の通りだと述べています。

1. クライアントとディスカッションし、コンテンツのアイディアスケッチ、サイトマップを作る。
2. 基本的なグリッドや大まかなレイアウトを規定したワイヤーフレームを書く。枚数は、必要なテンプレート（ページタイプ）の数だけ。手書きのスケッチや、Cacooなどでクライアントとディスカッションしながら。
3. ざっくりしたワイヤーフレームを元にFoundationを使ってCMSに組み込んでしまう。
4. 細かな要素の並び方やテキスト、画像の配置などは、CMS上で組み替えながら作っていく。ここでも、クライアントとディスカッションしながら。このとき、実現したい機能はまだ動いていなくてもよい。アドオンを利用する予定なら、インストールして使いはじめる。
5. コンテンツが固まってくると同時に、追加開発が必要なものを最終的に確定する。と同時に、色彩設計を行う。
6. 必要な追加ブロックタイプを開発するのと同時に、デザインにとりかかる。コンテンツの配置についてはすでにクライアントと了解済みで、CMSにも入力済みで、それからデザインするというフロー。
7. デザインを反映していく。テーマのCSSのアップデート、必要なブロックテンプレートの開発。

これに対して

このフローを一方向ではなく、できるだけ細かく回していく。後の工程に順番に流して行くウォーターフォール型のワークフローでも、結局手戻りは避けられない。新しいワークフローでは、戻らない。常にぐるぐる回り続ける。結果的に、素早く完成形ができあがり、コストも抑えられる。

とあります。

これは、作りながら、運用しながら変えていくことが求められるリーンスタートアップでのWebサービス開発や、アジャイル開発がシステム開発で普及してきたように、デザインの方でも同様の手法が取りいれられるのは自然な流れだと思います。

しかし、システム開発の現場が全てアジャイル開発で行われていないように、全ての案件や全てのフローでこの手法を取り入れる必要はないでしょう。

このワークフローの場合、不具合があれば要件定義まで戻してますので、その戻りが大きければ当初の想定よりも工数もコストも膨らみますし、それがウォーターフォール型よりも小さくなるとは限りません。

また、ウォーターフォール型は「手戻り」と言って、新しいワークフローは「ぐるぐる回り続ける」と言っていますが、どちらも結局は「仕様変更」ですのでここは言い方の違いにしか見えません。

私自身、この新しいワークフローは「向いている案件」と「向いていない案件」があり、CMS導入案件ではデザイン部分以外をアジャイル開発で行う必要はないと考えています。

結論：「先にCMSを導入する」はケースバイケース

デザインについて、「動くプロトタイプを作る」ということは、私自身も今後主流になると思います。

しかし、ワークフローを「先にCMSを導入し、あとでデザインする」にすることは、案件内容、クライアントリテラシー、制作会社リテラシー等によっては大きく制限を受けると思いますので、対応できない案件はウォーターフォール型で行う方がいい場合も多くあるでしょう。

「CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする」というのは確かに刺激的で、CMSベンダーのセールストークとしては正しいのかもしれませんが、実際の案件で使うには、ケースバイケースであり、新しいワークフローの場合、ベンチャーにありがちな「ドキュメントがない」ということにもなりそうで、そのあたりも含めた運用が求められると思います。

菱川さんの記事

CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする

後藤さんの記事

「CMS案件の制作フローは変化する。先にCMSを導入し、あとでデザインする」を読んで

「今だから知っておきたい『スマホサイト構築』＆『CMSとレスポンシブデザインで変わるWeb制作のワークフロー』」のスライド
[slideshare id=28471573&doc=cms-rwd-131120195410-phpapp02]

スポンサードサーチ