Re: yozik

[Web標準の日々レポート]転ばぬ先のプロジェクトデザイン?Web標準への準拠を見据えて?（木達一仁氏）

転ばぬ先のプロジェクトデザイン（木達一仁氏）

1日目最後のセッションはミツエーリンクスの木達さんです。
木達さんとはWaSP Cafeなどで何度かお会いしているんですが、去年のWeb標準の日の基調講演以外、まともにお話を聞いたことがなかったのでぜひ聞いてみたかったセッションです。

木達さんは日本で（というかアジアで）唯一のWaSPのメンバーで、現在は国際リエゾングループ（ILG: International Liaison Group）に所属しているそうです。

本セッションのテーマ

  • プロジェクトデザイン
    • ゴール、コスト、スケジュール、ワークフロー、スタッフアサイン
    • ワークフローとスタッフアサインはこちら側でコントロールできる。
    • ゴール、コスト、スケジュールについては、クライアントの意向に拠る部分が大きい。
    • 今日はワークフローとスタッフアサインの部分を中心にお話。
  • Web標準準拠サービスを始めたときにJesse James Garrett氏のアイデアに影響を受けた。

基本的なワークフロー

  • 現状把握・要求分析→要件定義→基本/詳細設計→実装→検品
    • プロセスがそれぞれ独立して分断しているのではなく、重なりがある方が理想的
  • 現状把握/要求分析
    • 各種ヒアリング
      • きちんとしたヒアリングをしておかないと、Web標準に準拠した後が続かない。
    • アクセスログ解析
      • ターゲットブラウザの把握など
  • 要件定義
    • マークアップ言語/CSS/JavaScript
    • ターゲットブラウザ（Yahoo! UI Library: Graded Browser Support）
    • XML宣言の有無はかなり大きな問題。
    • 対象メディア（Media Typeの設定）
  • 基本/詳細設計
    • モジュール・テンプレート設計
    • 設計内容の文書化
      • ページ単位にくんだ時に論理構造的に破綻がないか（H1要素をどこにあてるかなど）
      • 設計を文書化→ノウハウを共有可能な状況にしておく
  • 実装
    • 原稿とモジュール/テンプレートに従いマークアップ
      • スピードが重要
      • 文書をどの要素、モジュールでマークアップするか
      • 代替テキストの内容、リンク先などはすべて原稿とともに用意されるべき（マークアップ担当の役割ではない）
      • Dreamweaverのテンプレート、スニペット機能を利用
    • 大規模プロジェクトでは新規モジュールの制作や既存モジュールのバグ修正を同時進行
  • 検品
    • マークアップの文法的妥当性
    • ブラウザチェック
    • リンクチェック
    • 文言チェック
    • 必要に応じアクセシビリティチェック
      • JS,CSS,画像をOFFにする。ディグダグチェックなど。

ワークフローで「転ぶ」時

  • 段取り「二分」
    • とにかく時間がない
  • コミュニケーションルールが不十分である。
    • プロセス/スタッフ間で「いつ・何を」どのようなフォーマットでやりとりするか
      • MLで,MTGで,ドキュメントで
      • 何を何のためにやるのかをしっかり定義する
  • 中間成果物の品質
    • ビジュアルデザイン仕様
      • カンプだけ見ても分からないインタラクション部分の確認など
    • コーディング仕様
      • ミツエーではタブインデントはあまり使わない
  • 不十分なプロセス間の重なり
  • プロジェクト内レビューやクライアント承認の不履行
    • きちんとしたレビューをする前に社外に出てしまうと事故のもと。

スタッフアサイン

  • The Nine Pillars
    木達氏がワークフロー・スタッフアサインを考えるときのベースになっている。図の下側が戦略、上側が戦術。

    • User Research（ユーザーの動向・環境）
    • Site Strategy（サイトの戦略・目的）
    • Technology Strategy（技術的な戦略）
      • どんな技術・仕様を利用するかなど
    • Content Strategy（コンテンツの内容、ターゲットユーザー）
    • Abstract Design
      • 戦略を戦術に転換していく
    • Technology Implementation（コーディング・実装作業）
    • Content Production（コンテンツの作成・原稿執筆など）
    • Concrete Design（有形デザイン）
      • 最終的にデザインに組み上げる作業
    • Project Management
      • プロジェクトのエンジン
  • Pillar同士の隣接部分でコミュニケーションルールや中間成果物を定義
  • フロントエンド・エンジニアはtechnology implementation、technology, strategyの２つを受け持つ

スタッフアサインで転ぶとき

  • 専門領域や守備範囲が不明確
    • 誰がいつまでに何を
    • お見合い、ぶつかり、誰もボールを取りに行かない
  • アサインが完全でないままスタート

転びそうになったら？

  • 古いWebブラウザ対応を求められた
    • クライアントが本当にWebコンテンツについて理解しているか
    • セキュアでない
  • 現行のガイドラインとWeb標準がバッティングする
    • ガイドラインの改定も視野に入れて
    • ガイドラインが守られていない場合、その原因から突き止めていかないと最終的にうまくいかない
  • Strictで進めていたけどtarget属性を使いたい
    • 無理にStrictにこだわる必要はない
  • 作成後にデザイン修正
  • 実装フローに入ってもいつまで経っても新規モジュールの追加デザインが発生してしまう。
  • CMS導入時におさめたテンプレートのマークアップにシステム担当者から異議が
    • DTDの前にプログラム的に文字が入ってしまうなど
  • 実装の制作スピードがなかなか上がらない
    • 原稿の適切な準備、オーサリングツールを利用するなど
  • サイト公開後に知らないうちにinvalidになっていた
    • 公開後の運用方法の確認を徹底する。運用担当側にどういうツール、どの程度のスキルがあるのか。

まとめ：プロジェクトデザインで転ばないために

  • 基本的なワークフロー＋段取り八分←「何度でも言います」
  • 「The Nine Pllars」を参考に
  • クライアントの意思決定層も含め、関係者全員がWeb標準に一定の理解を。
  • ワークフローとスタッフアサインをプロジェクトごとに最適化
  • 常に[Plan-Do-Check-Act]サイクルを小さくまわし続ける

いろいろ職場を渡り歩いてきましたが、意識してこういったワークフローを組み立てているところはほとんどありませんでした。これはプロジェクトに関わる人間全員が高いレベルで意識を共有する必要があるのでなかなか難しい問題です。自分はマークアップエンジニアですが、プロジェクトに関わる人すべてが理解してほしい内容だなぁと思いました。

コメントを残す