https://jbug.info/backlogworld2021/ での登壇資料 ■アジェンダ 制作会社ではクリエイティブの方が同時期に複数の案件に関わる事が多いと思います。その際「なぜこれをするの？」「この情報はどこにあるの？」などの共有が問題になります。これらを毎回口頭で説明したり、チケットのコメントに書いたりするのは情報共有コストが膨らむばかりです。それを防ぐため、サービシンクで運用している「プロジェクト憲章」の作り方と、Backlogの使い方ルールテンプレートを元にした使い方をご紹介します。

2. 2
株式会社サービシンク 名村 晋治
PJメンバーで共有する
「プロジェクト憲章」ことはじめ

3. 3
名村 晋治 (なむらしんじ)
株式会社サービシンク(Servithik Co.,Ltd.)
代表取締役 / テクニカルディレクター
94年にインターネットに出会い、
96年よりWeb制作に携わり制作事例は数百サイト
2000年から05年まで不動産検索サイト
「HOME’S」
でディレクター
2005年から2009年まではWeb制作会社の取締役
2010年、
株式会社サービシンクを立ち上げ
2021年3月現在、従業員23名で案件に携わっています
Webに関する講演・セミナー、特に「Webディレクター」育成関連セミナー多数登壇

4. 4

5. 5
Webディレクションの疑問質問 受付中

6. 講演テーマについて
Reason of Theme
6

7. アジェンダ
7
プロジェクト
マネジメンとは？
What is PM?
メンバーが自発
的に動ける条件
Spontaneity
プロジェクト憲章
とフォーマット
Project charter

8. 大前提
1. 正論は正解ではない
2. 自社でチケット管理システムは使っている
3. ゴールはメンバーを「迷わせない」こと
4. 導入には一定の時間が必要
8

9. プロジェクトマネジメントとは？
What is project management?
9

10. プロジェクトマネジメントとは？
プロジェクトマネジメントとは、納期が決められ
ているプロジェクトをどのように遂行すれば成功
するのか、詳しく計画を立ててコントロールして
いくこと
10
https://backlog.com/ja/blog/what-is-project-management/ より

11. 11

12. Web制作・開発26年やってきて困った経験
• 要件定義
• クライアントワーク
• プレゼン
• 進行管理
• クオリティ管理
12

13. Web制作・開発26年やってきて困った経験
• 要件定義
• クライアントワーク
• プレゼン
• 進行管理
• クオリティ管理
13
いっぱいありました

14. プロジェクトマネジメントの観点
14
どのように人に動いてもらうか？

15. ディレクターの愚痴
•自分はクリエイティブの細部まで詳しくないん
だから各自がもっと主体的に動いて欲しい…
•みんな、全部ディレクターに聞いてくる…
15

16. ディレクターの愚痴
•自分はクリエイティブの細部まで詳しくないん
だから各自がもっと主体的に動いて欲しい…
•みんな、全部ディレクターに聞いてくる…
16
でも、それホント？

17. メンバーが自発的に動けない理由
Reasons why members cannot move voluntarily
17

18. ディレクターの愚痴
•自分はクリエイティブの細部まで詳しくないん
だから各自がもっと主体的に動いて欲しい…
•みんな、全部ディレクターに聞いてくる…
18
Webディレクター側に責任があります

19. 動けない理由はなにか？
•そもそもクリエイティブのメンバーは「何をした
らいいのか？」を知らない
•知りたい情報が「どこにあるか」を知らない
19

20. よくあるカンチガイ
20
こうなってませんか？

21. よくあるカンチガイ
21
僕がワイヤーを書くから、デザイナーそれをいい感じにビジュ
アルデザインしてくれ。
マークアップエンジニアはそれをHTMLにしてもらいたい。
クライアントはブラウザで見た時の動きを気にしていたから、
野暮ったくない動きを任せたいと思ってる。
構成要素は僕が責任持って書きこむ。

22. クリエイターの声
欲しい情報、それと違う！
22

23. クリエイティブを発揮するために必要な情報
1. そもそもなぜこれをするの？
2. っていうか、相手はどこの誰？
3. 何ができていたらOKもらえるの？
4. どうやってやるの？
5. いつまでに終わらせるの？
6. 幾らの案件なの？
23

24. 前提条件が分からない中で動けるのか？
• 自主的に動くとは「あの条件であれば、ここまでやった方がいい」
と考えられる情報が必要
• その条件が与えられなければ「言われたとおりする」しかやりよう
がない
• さらに「言われた」情報が少なければ、ディレクターの思い描く
以上のものを作れるはずがない（想像しようがない）
24

25. Webディレクターの責務
仲間への情報整理をし、共有すること
25

26. 動いてもらえる情報とはなにか？
プロジェクト憲章
26

27. プロジェクト憲章とフォーマット
Project charter and format
27

28. プロジェクト憲章とはなにか？
「プロジェクト憲章は、プロジェクトの存在を正式に認可する文書で
あり、プロジェクトのイニシエーターまたはスポンサーが発行する。
プロジェクト憲章は、プロジェクト・マネージャーが母体組織の資源
をプロジェクト活動のために使用する権限を与える。
プロジェクト憲章を通して文書化されるものとして、ビジネス・ニー
ズ、前提条件、制約条件、顧客ニーズの理解範囲、ハイレベルの要求
事項、新しいプロダクト、サービス、あるいは所産が満たすべき要求
事項がある。」（PMBOKガイド 第5版）
28

29. 具体的な内容に落とし込む
1.プロジェクトの目的
2.プロジェクトのゴール（測定可能な成功基準）
3.プロジェクト概要、作業範囲
4.前提条件・制約要件
5.ハイレベル要求事項
29
6.予算（概算から本予算へ）
7.リスク
8.要約マイルストーン
9.ステークホルダー（利害関係者）をリスト化
10.プロジェクトマネージャーの名前

30. なぜ「プロジェクト憲章」がいるのか？
「そもそも何をするのか？」を共有
共有することでクリエイターが動ける
30

31. 「想像から創造」の情報提供
クリエイターは「作業者」ではない
31

32. キーワード
情報共有が
プロジェクトの成功
の鍵を持つ
32

33. プロジェクトに必要なそれ以外の情報共有
「○○ってどこに書いているの？」
33

34. こうなっていませんか？
• ログイン情報がBacklogのチケットの中に書いてて行方不明
• 解凍しようとしたら「前のメールに書いたパスワードと同じです」
• クライアントからの「仕様情報」がチケットのコメントに書いている
• テストで使うメールアドレスを忘れて毎回メールボックスから探す
• 仕様書がチケットに添付されている
• 仕様の取り決めがチャットツール内で行われている
34

35. 毎回調べている時間
調べている＝仕事をしていない時間
35
一年でいったい何時間？

36. 大前提
1. 正論は正解ではない
2. 自社でチケット管理システムは使っている
3. ゴールはメンバーを「迷わせない」こと
4. 導入には一定の時間が必要
36

37. いつ出来ている必要があるか？
37
サービシンク開催「Webディレクター育成講座」カリキュラムより

38. 「共有」がキーワード
ディレクターは絶対に「プロジェクト憲章」を作る
38
それ以上に重要なことがあります

39. 共有を実施する
•「作る」ことではなく「使って」こそ意味がある
• 作ったものは「相手が理解」していなければ無意味
• 共有するまでが「プロジェクト憲章」作り
39

40. 文化を作る
連絡はBacklog
40

41. 3大問題
1.メールで連絡がくる
2.チャットで済ませてしまう
3.Backlogを見ていない
41

42. 情報発信の軸にしてしまう
1.Backlogを見ていない人を切る
2.見ていないと置いていかれる感
3.意地でもBacklogを見せる
42

43. 地道なBacklogへの誘導
• メール連絡
• メールで資料送付
• 電話で連絡での連絡
• 個別チャットで連絡
• 定例で口頭での話
• メールでの連絡時
• 定例での報告時
43
→ Backlogにコメントにコピペ
→ 資料をBacklogのファイルにアップ
→ 電話内容をBacklogに記載
→ チャットの内容をBacklogにコピペ
→ Backlogに記載
→ BacklogのURLと概要説明のみ
→ Backlogの状態変更を依頼

44. 使えるようになるまでの過程
1. 意義・意図の理解
2. 腹落ち
3. 意図的に使い始める
4. 無意識で使いこなす
44

45. Webディレクターの役割
• プロジェクトが動き出したら、ディレクターは「ハブ」
• メンバーの「これって何？」「これってどこにある？」を
どれだけ減らせるか？をになう
• Wikiをどのように整理するか？が重要
• Wikiにどのように記載するか？も重要
45

46. 「第三者が探せる」を意識して書いているか？
• 英語表記とカタカナ表記
• 微妙に正しくない「オレオレ単語」
• タイトルの付け方が雑
46
検索できるライティングが必要

47. 「第三者が探せる」を意識して書いているか？
• プロジェクトごとにwikiの構造が違う
47
共通のフォーマットの策定の必要性
• いつも「ここら辺にある」を作る

48. 48

49. sample_pj_txt
登録日 2020/01/01 00:00:00
プロジェクトドキュメント
49

50. sample_pj_txt
登録日 2020/01/01 00:00:00
プロジェクト用wikiプリセット
50
コピペで使えるMarkdownフォーマット

51. sample_pj_txt
登録日 2020/01/01 00:00:00
プロジェクトドキュメント
51

52. sample_pj_txt
登録日 2020/01/01 00:00:00
プロジェクト憲章
52

53. sample_pj_txt
登録日 2020/01/01 00:00:00
backlogのチケット運用ルール
53

54. sample_pj_txt
登録日 2020/01/01 00:00:00
本番・ステージングのURL・接続情報
54

55. sample_pj_txt
登録日 2020/01/01 00:00:00
プロジェクト用wikiプリセット
55
貼り付けて必要なところを追記する

56. 共通フォーマット化することの利点
• プロジェクトごとにwikiの構造が同じ
• 未記入も含めて構造を同じにする
• いつも「wikiのあそこにある」
• 探す手間の圧倒的な削減
56

57. 全ては良いものを作るために
「そもそも何をするのか？」を共有
共有することでクリエイターが動ける
57
全てはプロジェクト成功のため

58. ご清聴ありがとうございました。
疑問質問は下記にお送りください
Twitter：@yakumo
Facebook：名村 晋治
58
不動産業界特化で
Web制作・開発・保守・改善提案まで
をワンストップで行う
コンサル型のWebシステム会社
あらゆるサービスをシンクする