年間300プロジェクトから体得！"リスクを撃破する"テクニカルディレクション術

今日お話すること

ディレクターのあなたが少し幸せになる

WordPressの案件における

リスクと、そのつぶし方

自己紹介

関井

安藤丹羽

集合写真

loftwork

事例キャプチャ

事例キャプチャ

事例キャプチャ

事例キャプチャ

楽商https://www.rakusyo.jp

販売管理・在庫管理システム

こんなことってありませんか？

とんでもないデザインが

上がってきた！設計の詰めが甘かった

予算もスケジュールも

オーバー

公開直前に

問題発覚！

テクニカル・ディレクションでリスクを撃破!!!

実装に適したデザイン 手戻りのない開発

予算内、期間内で完了 スムーズな公開

楽商https://www.rakusyo.jp

販売管理・在庫管理システム

1. 背景、目的、作業範囲、ステークホルダーをドキュ

メントにまとめる

2. スケジュールの作成

3. Projectメンバーで同じ認識、情報を共有

プロジェクト序盤のポイント

1. 背景、目的、作業範囲、ステークホルダーを

ドキュメントにまとめる

2. スケジュールの作成

○ いつ・誰が・なにをするのか

○ タスクは細分化する

○ お客さんの作業もいれる

○ 修正期間・バッファもいれる

みっちり書きます

3. Projectメンバーで同じ認識、情報を共有

ワイヤー・デザインのポイント

1. 固有レイアウトのページを増やしすぎない

2. 階層が深すぎないようにする

3. 繰り返し・マウスオーバー・文字の増減まで、

デザインが網羅できている

1. LPのような単一ページが増えすぎると

○ 操作性・更新のしやすさの負担が増える

○ 工数が増える

○ WordPressの意味…(´･ω･`)

可能な限りパーツ化し複数テンプレートで利用

2. 階層が深すぎると

○ コンテンツまで到達しづらい

○ 離脱しやすくなる

WordPress実装のし易さ、

SEO視点、ユーザー視点を考慮した階層設計

3. デザインが網羅されていないと

○ パーツ化する際に機能・挙動の把握が

できなくなる

○ パターンを巻き取って開発者に

コーディングをお願いしないと

いけない

文字の増減

マウスオーバー

CMS設計のポイント

1. 固定ページ・投稿・カスタム投稿の使い分け

2. URL構造

3. テンプレートマップの作成

1-1. 投稿

○ ページの親子関係：持てない

○ 分類：（デフォルトでは）カテゴリーとタグ

○ 分類の親子関係：持てる！

1-2. 固定ページ

○ ページの親子関係：持てる！

○ 分類：（デフォルトでは）ない

○ 分類の親子関係：（デフォルトでは）持てない

1-3. カスタム投稿タイプ

○ ページの親子関係：持てる！

○ 分類：いくらでも！

○ 分類の親子関係：持てる！

カスタム投稿タイプで構成した例

この事例では

「投稿」を

使ってないよ

1-4. 使い分けの例

● カスタム投稿

→ほぼ全てのコンテンツ

● 投稿

→「お知らせ」など、基本的なブログコンテンツ

● 固定ページ

→最後の砦。例外的な固有レイアウト・単一

○ 投稿名 or 投稿ID

○ 投稿タイプ・タクソノミー名

○ タームのスラッグ

○ パーマリンク設定

2. URL構造を定める

http://domain/taxonomy/term/

はできるけど

http://domain/term/

にするには一手間いるとか

http://domain/post_type/single/

はできるけど

http://domain/post_type/taxonomy/term/single

にするには一手間いるとか

後からの一言で仕様変更になる事も…早めの策定が重要です。

なんでこのURLにできないの？

3. テンプレートマップの作成

○ テンプレート数の把握

○ サイト構造全体の把握

○ 投稿タイプとテンプレートの照合

テンプレートマップ

開発着手時のポイント

1. LW流カスタムフィールド設計

2. CMS仕様書の作成

3. テンプレートの開発優先順位決め

　 ※移行を考慮

1. LW流カスタムフィールド設計

○ デフォルトのエディタは使わない(削除)

○ コンテンツは基本カスタムフィールドのみで構成

○ 汎用性の高い入力要素を作る

● 複数テンプレートで利用

● 可能な限りフィールドをグループ化

問い合わせセット

記事セット

複数テンプレート

☓

グループ化

2. CMS仕様書の作成

○ 開発者とお客さん双方に実装イメージを共有

○ 動作テスト時の判断基準

○ 引き継ぎ時における、仕様把握の指針

CMS仕様書を通して

クライアント/開発者と認識をすり合わせ

3. テンプレート開発の優先順位

○ 移行ページ数の多いテンプレートから開発

　 優先的に実装～バグフィックスの実施

○ 結果として移行と開発の同時進行で、全体スケジュールを

短縮

スケジュールを加味して

記事登録の多い優先テンプレートを決める

①

②

プロジェクト終盤のポイント

1. 残タスクと公開時のリスク洗い出し

2. 公開手順表の作成

1. 残タスクと公開時のリスク洗い出し

○ 公開2週間前を目安に、社内でミーティングを実施

○ 残タスクとリスクの共有および対策

○ 期限内・予算内かの確認

2. 公開手順表の作成

○ 公開するには、どんな前提条件があるのか

○ いつ・誰が・どんな作業をするのか

公開前日から当日の動きを

時間単位でリストアップ

自分とお客さんの

お昼休憩・終業時間を考慮するのも

お忘れなく(｀･ω･´)ﾉ

お客さんの確認時間を、

自分たちのお昼休憩にするとか

おさらい

○ リスクの洗い出しはやっておこう！

○ CMS設計は画面設計から！

○ WordPressのクセを把握しておこう！

○ 公開作業は計画的に！

Thank you