CodeIQ MAGAZINECodeIQ MAGAZINE

Movable Type 7(MT 7)へのバージョンアップに見るデザイナーとエンジニアの「協業」

2017.11.14 Category:勉強会・イベント Tag: , ,

  • 15
  • このエントリーをはてなブックマークに追加

CMSツール「Movable Type 7(以下、MT 7)」の開発者向けプレビューが公開された。今回のバージョンアップでは、「コンテンツタイプ」機能が大きく注目されている。10月のMTDDCでMT 7のお披露目が行われ、開発に携わったエンジニアやデザイナーが、そのポイントを語った。 by 大内 孝子

情報設計からウェブサイト制作を始める

コンテンツタイプは、情報設計からウェブサイト制作を始めるために新しくMT 7に導入された概念だ。

ブログツールやCMSツール(以下では、便宜上「CMSツール」と表記する)の登場で、タイトルや本文の入力はHTMLタグを使って自分で編集するよりはるかにラクになった。すぐに見た目のよいページレイアウトができる。

基本的には、CMSツールで作成するウェブサイトのコンテンツは「タイトル」と「本文」から構成される。もちろん実際には、本文の中にさまざまな要素に入ってくるため、スタイル設定を駆使して、それぞれの要素を表現する。

たとえば、ここは記事の地の文です、引用部分です、ここは箇条書きでポイントをわかりやすくしようという感じに。しかし、それは見た目のわかりやすさであって、ページを構成するパーツとして自由に扱えるわけではない。

これは、情報設計の観点では何もされていないに等しく、当然、再利用性は高くない。再利用できるとすれば「スタイル」だ。

一方、今回、MT 7が導入したコンテンツタイプはコンテンツにどんなフィールドが必要か、情報設計の段階から組み立てることができる機能だ。それにより、CMSツール上からもっと柔軟にコンテンツを管理できるようになる。

Six ApartのCTO平田大治さんはコンテンツタイプによるメリットとして次の点をあげる。

  • さまざまな情報をすべて「本文」に入れる必要がなくなる
  • 「エントリー」「ページ」以外の名称を付けることができる
  • タイトルを必須としないコンテンツが作れる
  • コンテンツとデザインを分離できる
  • プラグインやアドオンなしでコンテンツタイプが作れる
  • 特定のメディアアセットの参照ができるようになる
  • 使い回しができるコンテンツの管理がしやすくなる

▲ウェブサイトとコンテンツタイプ(イメージ)[平田大治さんのスライドより]

データを入力するフィールドを「コンテンツフィールド」として作成し、コンテンツフィールドの組み合わせでページを構成する。それをコンテンツタイプとして定義する。つまり、そのページに必要な情報を”情報の粒”の単位で組み合わせる。きちんと情報設計からできるということになる。

“情報の粒”にあたるコンテンツフィールドは、他のコンテンツタイプからも利用できる。データフィールドの再利用がしやすく、柔軟なページ設計が可能になる。

従来のツールが、1つのエントリーとして扱っていたのに対し、コンテンツを構成する「情報」を種類によって分解することで、コンテンツ設計(コンテンツの再構成・再利用)を容易にしようというものだ。

たとえば、ニュース記事の中でも見出しや取材元の発言を引用するスタイル、著者のプロフィール表記など、いくつかの構成要素が考えられる。こうして、情報の”粒”に分けて管理することで、パーツとしていつでも再利用が可能だ。

これは、従来のCMSツールとは大きく変わる考え方になる。

背景には、ネット上のコンテンツに起こっている変化がある。ブログの時代は、ウェブページ同士がつながるのが前提だったが、いまはソーシャルメディアを経由し、ウェブページだけではなく、動画や写真にも直接リンクがされる。PCだけでなくスマートフォンやタブレットがつながることで、コンテンツの幅が広がったのだ。そこで必要になるのは「コンテンツを柔軟に設計できること」だ。

その課題に対する解決として、MTが提示したのが「コンテンツフィールドを組み合わせて、自由にコンテンツタイプを定義する」という機能だ。

しかし、既存のプロダクトにここまで大きな変更を加えるというのは、一から作り直すよりもむしろ難しい。すでにできあがっているところにこうした新たな概念を導入するのは、そう簡単なことではない。

開発の中では何が行われていたのだろうか? 

以降では、MTDDCでの長谷川恭久さん(Six Apartデザイン顧問)のプレゼンから、新しい概念を取り入れるに際し、デザイナーとエンジニアがいかに協業していったのか、そのポイントを紹介したい。

デザイナーとエンジニアが組むというと、真っ先に浮かぶのは「デザイン思考」を使った方法かもしれない。しかし、どうやらそれだけではなさそうだ。

▲Six Apartデザイン顧問 長谷川恭久さん[提供:Six Apart社]

デザイナーが果たすべき役割

まず、前提としてデザイナーが果たすべき役割について、長谷川さんはこう述べる。

・外側(ユーザー)に対しては「その人にとって必要なものをユーザー自身が理解できる形にする」こと
・内側(開発する中の人)に対して「何をするかをチームで理解・共有できる形にし、動き出せる関係性を作る」こと

つまり、デザイナーに求められるのは、何を作るのか(何をしたいのか)をチームで共有し、プロダクトとして形にする。形にするだけでは十分ではなくて、「これが欲しかったんだ」という形にしてユーザーに届けるというところまでして、やっと役割を果たしたということになる。

▲「外のデザイン」と「中のデザイン」、この両者をつないでプロダクトを完成させていく[長谷川恭久さんのスライドより]

今回のMTのバージョンアップの場合、「柔軟なコンテンツ管理を提供する」ために既存のフレームを外して新しい概念モデルを作る」のが最終的な目標だ。

しかし、現存プロダクトからどう進化させるか、それがわかっていなかった。コンテンツタイプは、前述のように従来のCMSの枠から越える、新しい概念。そもそも市場にフィットするものなのかどうかもわかっていない。

▲「コンテンツタイプ」の定義[長谷川恭久さんのスライドより]

ここで、前提となるSix Apart社の企業風土についてだが、長谷川さんは「よくも悪くも開発ドリブン」「スモールチーム」「ベテランが多い開発環境なので進め方は決まっている」とする。反面、「デザイン思考の適用が難しい面もある」と言う。

実際、デザイン思考で重要なステップに位置づけられる「ユーザーを知るプロセス」として「メソッドによる、ユーザー調査結果の視覚化」を行った(MT7のイメージビデオも作成し共有する、など)が、その結果は「で、これが一体何なの?」だったという。

要は、伝わらなかったのだ。モチベーションのトリガーは人それぞれだし、抽象度の高い成果物は人や場所を選ぶ。言葉でもグラフィックでもそうだ。よほど長い間、一緒に時間を過ごし、体験を重ねていない限り、抽象度の高いモノから想起するイメージはほぼ一致しないだろう。

会社や組織の文化ができあがってしまっているところに新しいメソッドを取り入れるのは難しい。たとえデザイナーにとって正攻法のやり方でも、その会社における最適解でないのであれば、迷わず別のアプローチを取ることだ。

かといって、視覚化(および共有)を諦めてしまうのはNG。”何となく”でもいいので視覚化し、それを共有化する。議論を始めるため、だ。

長谷川さんはまず画面を作って視覚化した情報で説明することから始めた。これはいるのかいらないのか、議論の元になる部分を提示したのだ。

▲まず作る、見て・さわって確認する、そして改善する[長谷川恭久さんのスライドより]

機能を絞り込んでプロトタイプを作り、そうして視覚化した情報をもとに理解してもらう。フィードバックを得て、必要であれば情報を補足し、改善していく。これは、通常ならユーザーを対象にするステップだが、ある意味、「一緒に働くメンバーもユーザーとしてとらえる」ことで、デザイナーとエンジニア、相互の認識をすり合わせることができる。

外側の顧客だけがユーザーなのではないということなのだ。
特に、新しい概念や未知の使い方を提示する(=ゴールのイメージが明確になりにくい)プロダクトの場合、こうした意識を持つことで開発が進めやすくなる。

デザインのブラックボックス化を避ける

実際にページレイアウトを作っていくと、デザイナーとエンジニアの思考のギャップが浮き彫りになる。

▲デザイナーは全体から細部を考える(部品からはいきなり作れない)、エンジニアは土台を作ってから積み上げていく[長谷川恭久さんのスライドより]

どうしても「この画面が必要なので作って」という形で作っていくと、その場その場で最適化してしまうので一貫性がなくなってしまう。

ウェブサイトにはさまざまな画面の状態がある。コンテンツ量も一定ではないし、ウィンドウサイズも変わってくる。しかし、開発途中ではそのデータもない。すべてを想定しきれないため、二度手間が増えてしまうことになる。そもそも、1つ1つ作り込んでいくのでは時間が足りないし、実装し動かしてみないとわからないことが多すぎる。

ただ、最近はUIデザインのガイドラインを最初に作るのがセオリーになっている。

ガイドラインによって、初期段階から一貫性のあるデザインを考慮しながら、実装のプロセスと並行で作ることができる。これは、デザイナーの側の「全体から作る」プロセスをエンジニアの思考に寄せているとも言えるアプローチだ。ただ、作りながら改善するので完成形が見えにくいという懸念点もある。

デザインのガイドラインはMTの開発チームにはなかったので、今回、それを作ったという。ガイドラインの中では目的を明確にし、ベストプラクティスを提示するというように、プロセスをドキュメントにしていく環境を作り、エンジニアだけでも動けるルールを設けた。

デザインのブラックボックスを解消する

もう1点、長谷川さんがあげたポイントは「デザインのオープン化」だ。プロセスの途中の段階で共有したり、プロセスをドキュメントに落とし込むことで、(どうしてもなってしまいがちな)デザインのブラックボックス化を解消しようという。

自身がデザイナーである長谷川さんがこう述べたことが非常に興味深い。
いくら途中経過のデザインラフを共有してもらっても、最終的な完成イメージはデザイナーの頭の中にしかない。判断基準がデザイナーの頭にしかない。完成までの間に何が起こっているか、外からはわからないのだ。

そうした場合に、どう品質管理していくのか?
長谷川さんは開発とデザインのフローを次のように比較する。

▲開発フローとデザインフローの違い[長谷川恭久さんのスライドより]

ある程度の精度になった状態で共有されるデザインと、途中経過も常に共有され、オープンな状態で進む開発。これでは、エンジニアのスピードについていけない。

そのため、画面遷移を作ったらすぐにガイドラインに落とし、途中経過を見せることを習慣化していった。また、コミュニケーションの方法もSlackやGitHubを使うというように、デザイナーをエンジニアへ寄せていった。

デザインのオープン化には、

  • 途中経過を見せる習慣作り
  • アイデアを共有できるツールの整備

ことが重要な要因といえる。
あとは、「作り込み」と「早く見せるために十分な精度」のせめぎ合いだ。

このように、「コンテンツタイプ」などの言葉の使い方から共有し、実装しながら協業で作るための環境を作ることから始めて、新しい概念を製品に取り込んでいったのだ。

扱うプロダクトや企業の文化などによっても”最適解”は違ってくるため、ここで紹介したやり方がすべての場合でベストであるというわけではないだろう。しかし、デザイナーとエンジニアの協業における考え方として、いくつかのヒントがある。

今後は、主要操作の画面遷移やデザインの詳細を詰めていくとともに、スタイルガイドの充実を測っていくという。

  • 15
  • このエントリーをはてなブックマークに追加

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ