社内にエンジニアをもたない“ロフトワーク流”Webサイト構築プロジェクトの進め方を、WordPress導入の具体的な事例・アウトプットをベースにご紹介。 いかにリスクを減らし、スムーズにプロジェクトを進めるか？ テクニカルディレクターの目線でコツをお話します。

2. 今日お話すること
ディレクターのあなたが少し幸せになる
WordPressの案件における
リスクと、そのつぶし方

3. 自己紹介

4. 関井
安藤丹羽

6. 集合写真
loftwork

8. 事例キャプチャ

9. 事例キャプチャ

10. 事例キャプチャ

11. 事例キャプチャ

12. 楽商
https://www.rakusyo.jp
販売管理・在庫管理
システム

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

14. とんでもないデザインが
上がってきた！
設計の詰めが甘かった
予算もスケジュールも
オーバー
公開直前に
問題発覚！

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

16. 実装に適したデザイン 手戻りのない開発
予算内、期間内で完了 スムーズな公開

17. 楽商
https://www.rakusyo.jp
販売管理・在庫管理
システム

21. 1. 背景、目的、作業範囲、ステークホルダーをドキュ
メントにまとめる
2. スケジュールの作成
3. Projectメンバーで同じ認識、情報を共有
プロジェクト序盤のポイント

22. 1. 背景、目的、作業範囲、ステークホルダーを
ドキュメントにまとめる

23. 2. スケジュールの作成
○ いつ・誰が・なにをするのか
○ タスクは細分化する
○ お客さんの作業もいれる
○ 修正期間・バッファもいれる

24. みっちり書きます

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

28. ワイヤー・デザインのポイント
1. 固有レイアウトのページを増やしすぎない
2. 階層が深すぎないようにする
3. 繰り返し・マウスオーバー・文字の増減まで、
デザインが網羅できている

29. 1. LPのような単一ページが増えすぎると
○ 操作性・更新のしやすさの負担が増える
○ 工数が増える
○ WordPressの意味…(´･ω･`)

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

31. 2. 階層が深すぎると
○ コンテンツまで到達しづらい
○ 離脱しやすくなる

32. WordPress実装のし易さ、
SEO視点、ユーザー視点を考慮した階層設計

33. 3. デザインが網羅されていないと
○ パーツ化する際に機能・挙動の把握が
できなくなる
○ パターンを巻き取って開発者に
コーディングをお願いしないと
いけない

34. 文字の増減
マウスオーバー

36. CMS設計のポイント
1. 固定ページ・投稿・カスタム投稿の使い分け
2. URL構造
3. テンプレートマップの作成

37. 1-1. 投稿
○ ページの親子関係：持てない
○ 分類：（デフォルトでは）カテゴリーとタグ
○ 分類の親子関係：持てる！

38. 1-2. 固定ページ
○ ページの親子関係：持てる！
○ 分類：（デフォルトでは）ない
○ 分類の親子関係：（デフォルトでは）持てない

39. 1-3. カスタム投稿タイプ
○ ページの親子関係：持てる！
○ 分類：いくらでも！
○ 分類の親子関係：持てる！

40. カスタム投稿タイプで構成した例
この事例では
「投稿」を
使ってないよ

41. 1-4. 使い分けの例
● カスタム投稿
→ほぼ全てのコンテンツ
● 投稿
→「お知らせ」など、基本的なブログコンテンツ
● 固定ページ
→最後の砦。例外的な固有レイアウト・単一

42. ○ 投稿名 or 投稿ID
○ 投稿タイプ・タクソノミー名
○ タームのスラッグ
○ パーマリンク設定
2. URL構造を定める

43. http://domain/taxonomy/term/
はできるけど
http://domain/term/
にするには一手間いるとか

44. http://domain/post_type/single/
はできるけど
http://domain/post_type/taxonomy/term/single
にするには一手間いるとか

45. 後からの一言で仕様変更になる事も…
早めの策定が重要です。
なんでこのURLに
できないの？

46. 3. テンプレートマップの作成
○ テンプレート数の把握
○ サイト構造全体の把握
○ 投稿タイプとテンプレートの照合

47. テンプレートマップ

49. 開発着手時のポイント
1. LW流カスタムフィールド設計
2. CMS仕様書の作成
3. テンプレートの開発優先順位決め
※移行を考慮

50. 1. LW流カスタムフィールド設計
○ デフォルトのエディタは使わない(削除)
○ コンテンツは基本カスタムフィールドのみで構成
○ 汎用性の高い入力要素を作る
● 複数テンプレートで利用
● 可能な限りフィールドをグループ化

51. 問い合わせセット
記事セット
複数テンプレート
☓
グループ化

52. 2. CMS仕様書の作成
○ 開発者とお客さん双方に実装イメージを共有
○ 動作テスト時の判断基準
○ 引き継ぎ時における、仕様把握の指針

53. CMS仕様書を通して
クライアント/開発者と認識をすり合わせ

55. 3. テンプレート開発の優先順位
○ 移行ページ数の多いテンプレートから開発
優先的に実装～バグフィックスの実施
○ 結果として移行と開発の同時進行で、全体スケジュールを
短縮

56. スケジュールを加味して
記事登録の多い優先テンプレートを決める
①
②

58. プロジェクト終盤のポイント
1. 残タスクと公開時のリスク洗い出し
2. 公開手順表の作成

59. 1. 残タスクと公開時のリスク洗い出し
○ 公開2週間前を目安に、社内でミーティングを実施
○ 残タスクとリスクの共有および対策
○ 期限内・予算内かの確認

60. 2. 公開手順表の作成
○ 公開するには、どんな前提条件があるのか
○ いつ・誰が・どんな作業をするのか

61. 公開前日から当日の動きを
時間単位でリストアップ

63. 自分とお客さんの
お昼休憩・終業時間を考慮するのも
お忘れなく(｀･ω･´)ﾉ
お客さんの確認時間を、
自分たちのお昼休憩にするとか

64. おさらい
○ リスクの洗い出しはやっておこう！
○ CMS設計は画面設計から！
○ WordPressのクセを把握しておこう！
○ 公開作業は計画的に！

65. Thank you