コーディング外注時の進行ポイント

Transcript

1. コーディング外注時の
   進行ポイント
   Presentations by SKYGUILD
   

   View Slide

2. 外注時に大切なこと
   信頼できる相手かどうかを
   見極めることも重要
   怪しい時は早めのリスクヘッジを
   高圧的な態度や
   コミュニケーションの手抜きは厳禁
   信頼を失えば依頼を断られる
   ↓
   外注先は対等なパートナー
   相手が
   信頼できるか
   自社が
   信頼されるか
   信頼関係
   

   View Slide

3. 最初に提示すべき情報
   

   View Slide

4. 最初に提示すべき情報
   最初により詳細な情報を伝えるほど、後から見積もりが増える可能性が減る
   それでもある程度増える可能性を考慮して予算には余裕をもっておく
   ◆ 予算感
   ・予算が十分なときは伝えず、まずは見積もりしてもらっても OK
   ・予算が少ない時には先に伝えた上で交渉する
   ・コスト削減のための案があれば、合わせて相談する
   　
   （アニメーションを減らす、レスポンシブにしない、ユニークレイアウトを減らす等）
   ◆ スケジュール
   ・詳細に決まっていなくても可能な範囲で伝える
   ・最大でどの程度のズレが想定されるのか、ズレた場合に対応可能か相談しておく
   

   View Slide

5. ◆ 特殊な要件
   ・古い対応環境、他社連携、外部サービス連携
   　
   サーバ成約、コーディング規約　など
   ◆ 公開作業の有無・公開方法
   ◆ 制作内容
   ・デバイス、レスポンシブ or 別 HTML、PC リキッドの有無
   ・ページ数
   ・1 ページ辺りのボリューム感（ワイヤーフレーム または 参考サイト）
   ・JS 実装
   　アニメーション演出／非同期画面遷移／ローディング／動画自動再生
   　SNSシェア／グロナビ開閉／スライド、
   タブ切り替え／モーダルウィンドウ
   　追従ナビゲーション、ボタン等／ GoogleMap カスタマイズ　etc.
   ・プログラム実装（フォーム、CMS 有無）
   

   View Slide

6. 契約時に確認すべき事項
   

   View Slide

7. 契約時に確認すべき事項
   ◆ 公開後の瑕疵・微修正の対応について
   ・公開後の微修正をどの程度の期間、無償で対応するか
   ・瑕疵の場合、どの程度の期間、無償で対応するか
   ・免責事項があるか
   ◆ 運用について
   ・運用が必要な案件の場合、予め継続して依頼できるか確認（費用感も）
   ・もし、運用の対応が不可の場合、別の担当者がいるか
   　別の作業者が編集しやすい構造を意識して構築できるか
   ・場合によっては、運用に必要なマニュアル作成を依頼
   ◆ 機密保持契約
   

   View Slide

8. スケジュール作成のポイント
   

   View Slide

9. スケジュール作成のポイント
   ・クライアント用のスケジュールは大まかなものでも良いが、
   　実装者へのスケジュールは確認タイミングなどを細かく定める
   ・テストアップ前に、自社確認期間・修正期間を必ず入れる
   ・出来る限りバッファを入れる
   ・中～大規模の案件の場合、何回かに分かれて自社確認タイミングを設ける
   ・タイトな案件の場合、デザイン確定前に先行して着手できる部分を探す
   

   View Slide

10. ダメなスケジュールの例
    ・デザインの確認が 1 回と少ない上に、それから実装までの期間に余裕がない
    ・実装の自社確認タイミングが定められていない
    　→ 実装者がテストアップギリギリで提出してきた場合、
    　　フィードバックを直してもらう時間がない
    ・実装期間が長いため、進行順や日程を実装者に任せていると
    　
    実装が間に合わなかったり、修正期間がなくなるなどのリスクが高い
    

    View Slide

11. 理想的なスケジュールの例
    ・段階を分けることで、トップのみ先行スタートし、後半に余裕を持たせている
    ・まずはトップページの自社確認を行うことで、大幅な認識の相違や進行の遅れ
    　がないかを確認することができる
    

    View Slide

12. SLAの作り方
    

    View Slide

13. SLAの作り方
    ◆ SLAとは
    Service Level Agreement の略。
    サービスを提供する事業者が契約者に対して、どの程度まで品質を保証でき
    るかを明示するため、サービスのレベル（定義、範囲、内容、達成目標等）
    に関する合意サービス水準、品質保証を提示する契約書類のこと。
    ◆ SLA の必要性
    クライアントへ安心信頼を与えるという目的のみならず、
    自社のリスクヘッジのために大変重要となる。
    SLA（合意に基づいたサービス水準）がないということは、
    「無条件で求められるだけ要求に答える」ということになりかねない。
    

    View Slide

14. SLA に載せる情報
    ・クライアント名、案件名、担当者名
    ・策定日
    ・対応環境（OS、ブラウザ、機種）
    ・対応範囲
    → フィーチャフォンを除外
    → タブレットやスマホ横画面の対応有無
    → 画面サイズ別の対応有無　など
    ・免責事項
    → OS・ブラウザアップデートによる不具合
    → 外部サービスの仕様変更による不具合
    → サーバ要因の不具合（サーバ担当外の時）
    など
    

    View Slide

15. 対応環境の定め方
    ・古いバージョンをサポートする場合、実装費に
    　割増が入る可能性もある
    ・なるべく最新バージョンに近い環境のみに絞る
    　
    ほうが制作効率が良い
    ・現時点の一般的なブラウザシェア率などを調べ
    　て参考にする
    ・既存サイトのGoogleAnalytics などのアクセス
    　
    状況を調べて参考にする
    ・何 % 以下を切り捨てるかはクライアントの要望
    　
    や案件の性質、ディレクター個人の判断による
    　
    （個人的な見解では10% 以下は切り捨てて良い）
    

    View Slide

16. 制作開始時の資料
    

    View Slide

17. 制作開始時の資料
    ◆ 必須の情報
    ・サイトマップ（URLリスト）
    ・スケジュール
    ・指示書
    　→ 簡易にすますのであれば、ワイヤーフレームやデザイン上に指示を書き込んでも可
    ・デザイン
    　→ OGP 画像、ファビコン、各種アイコン画像なども忘れずに用意
    　→ エラーページ、同ページでの出し分けのデザインなど忘れやすいため注意
    ・メタ情報（タイトル、ディスクリプション、キーワード）
    　→ 開始時に揃ってなくても可
    

    View Slide

18. 制作開始時の資料
    ◆ あると尚良い・案件によって必要な情報
    ・デザインガイドライン
    　→ デザイン時に定めた規定があれば共有する　
    　→ カラーコードや、余白の数値の指定、共通パーツの定義など
    ・FTP 情報（サーバアップロードを依頼する場合）
    ・Git（バージョン管理）リポジトリ
    　→ 自社でバージョン管理を採用している場合
    ・コーディングガイドライン
    　→ クライアント指定のルールがある場合に注意
    　→ 画像の書き出し方法、納品方法・タスクランナーの指定、HTML バージョン、
    　　SEOの観点によるタグの指定など、ある場合に詳細に指示する
    

    View Slide

19. 指示書の必要性
    ・メールや電話だけでは、情報が埋もれる & アップデートがわかりづらい
    　→ いつ、誰が、どのメールで言っていたことだったか、口頭だったか、混乱
    　→ やり取りを追うだけで逐一手間がかかり、トラブルの元にもなる
    ・タスク、検討事項、必要素材等の過不足を可視化 & 一覧化できる
    　→ 情報が集約され、指示漏れ・行き違いを防げる
    実装者が作業しやすいのみならず、
    自社が確認作業をする際の指針となる
    記録が残すことで属人化せず、
    後の更新や担当変更の際に仕様を把握できる
    ↓
    

    View Slide

20. 指示書に載せる内容
    例：
    ・アニメーション演出の仕様、参考サイト
    ・追従する要素、追従するタイミングや動き
    ・ユーザの操作によって変化が起きる箇所
    　
    （クリックしてメニューが開く）
    　
    （マウスオーバーでデザインが変化する）
    ・特定の条件で表示が変わる箇所
    　
    （初回訪問時のみポップアップを表示）
    　
    （ブラウザが小さい時にメニューのレイアウトが変わる）
    ・コンテンツの有無や件数が変化する際に、レイアウトをどう変えるか
    ・外部サービスとの連携
    デザインから読み取りづらい要素、動きのある箇所、動的コンテンツの仕様や
    相談点などをページ別にまとめていく
    

    View Slide

21. 進行管理・品質チェックのポイント
    

    View Slide

22. 進行管理のポイント
    ◆ 連絡をこまめに取り合う
    ・締切日に限らず数日置き（全体の日数によりけり）に進捗報告してもらう。
    　
    報告がなかった場合にはこちらから確認をする。
    ・返信は速やかに行う。連絡の遅い発注元は不信感を持たれる。
    　すぐに返答できない内容でも「確認します」
    「○○日までお時間ください」など
    　必ず反応を返すことで相手を不安にさせない。
    ・相手がトラブル時に報告しづらい空気にしない。
    　
    「進捗が厳しければ○○も検討できるので～」など話しやすい雰囲気を出す。
    　ギリギリになって白状されれば案件は大打撃を受ける。
    → 相手に任せきりにせず、適度に疑い、
    　 信頼できるか確かめながら進捗をコントロールする
    

    View Slide

23. 進行管理のポイント
    ◆ 遅延時のリカバリ案を常に考えておく
    ・予め懸念があれば、長めにリソースを確保する
    　
    （クライアントが遅延の常習傾向にある）
    （他社担当分野を待って開始する）など
    ・デザイン、テキスト原稿、仕様決定が遅れた場合に代替スケジュールを立てる
    　
    （代替案無しに実装者に負担を強いない）
    （一部先行着手ができないか検討する）
    　
    （どうしても実装者が対応できない場合に、代替リソースを検討しておく）
    　
    ◆ タスク管理表を用意する
    ◆ 要件の追加・変更は費用発生の有無を確認する
    ・各タスクのステータスや担当の認識共有、タスク漏れを防ぐ、優先順位の整理
    ・案件終了後に予想外の追加請求をされないように、費用発生の有無を曖昧なまま進めない
    

    View Slide

24. 品質チェックのポイント
    ・指示書を元に要件が満たされているか
    ・デザインが忠実に再現されているか（色、画質、余白、行間、文字間、文字太さ）
    ・原稿の入れ間違いがないか
    ・リンクやメタ情報にも間違いがないか
    ・各OS、ブラウザで検証し、バグについては発生した環境を伝える
    ・リキッドサイトの場合、ブラウザの大小でも確認
    ・テキスト量や要素が増減した際に、レイアウトが崩れないか
    ・ページの読み込みスピードが極端に遅くないか
    ・マウスオーバーやクリック等の操作が発生する箇所は、
    　連続で操作した際に挙動がおかしくならないか
    ・非同期画面遷移の場合、他ページから遷移してきた際に挙動がおかしくならないか
    

    View Slide

25. トラブルシューティング
    

    View Slide

26. トラブルシューティング
    運用編
    ・公開後の運用方法について事前に話していなかった
    ・引き続き依頼したものの、なかなかスケジュールが確保できない
    ・簡単な修正で多額の費用を提示された
    ・自社で対応しようとしたが、複雑な技術を採用していて手がつけられない
    

    View Slide

27. トラブルシューティング
    運用編 - 対処・解決
    ・依頼時に公開後の運用が対応可能か、スケジュール・費用感を確認しておく
    ・運用対応が不可の場合は、自社運用、または、別会社への依頼、公開後に運用
    担当の別会社へ引き継ぐ等を検討しておく
    ・自社で対応する場合、更新しやすいような工夫をしてもらえるように実装方
    法を相談する（必要な場合はマニュアルも依頼）
    ・事前にこのような対処ができていなかった場合は、自社で運用できるよう
    に、更新方法を解説してもらうか、別会社を新たに手配する
    

    View Slide

28. トラブルシューティング
    スケジュール編
    ・
    「今週中」と指示した内容が日曜に連絡が来た
    ・テストアップの当日に完成、しかしクオリティが低く、抜けも多い
    　打ち合わせで指示した仕様と全く違う
    ・修正を依頼するものの、窓口の担当から「エンジニアと連絡がつかずすぐには
    　
    対応できない」と言われた
    ・結果的にテストアップできず、大幅にスケジュールが遅れた
    

    View Slide

29. トラブルシューティング
    スケジュール編 - 対処・解決
    ・期日に関する連絡は曖昧な言葉を使わない。 ○月○日○時まで、など明確に。
    　悪い例「数日以内」
    「早めに」
    「明日中」
    「お手すきの際に」
    ・テストアップ前に自社で確認する日を決めて伝えておく。
    　特に大規模の案件では、最初の数ページができた時点で確認すると大きな認識の
    　相違が起こりづらい。
    その後もこまめに確認タイミングを設ける。
    ・タスク管理表で残タスクを共有し合い、認識の相違・漏れのないようにする。
    ・窓口の担当が直接作業するエンジニアでない場合は、相手の社内体制や対応の
    　
    スピード感など事前に懸念を確認する。
    ・既に遅延している場合は、社内での対応や別会社への依頼が可能かも検討
    

    View Slide

30. トラブルシューティング
    費用編
    ・案件を進める中で、ちょこちょこと要件の追加があったが、金額について
    　
    何も触れていなかったら、最終的に請求が大きく増え予算オーバー
    ・途中自社でカバーして実装を担当した箇所があったにも関わらず、減額
    　されずにそのまま請求された
    ・先方のミスで見積もり項目に不足があり、追加の請求をされた
    

    View Slide

31. トラブルシューティング
    費用編
    ・事前に要件の増減が多いと予測できる場合には、最初から余剰費を確保し、
    それ以
    上になりそうな時には相談してもらうように取り決めておく
    ・要件が増えたり、逆に担当箇所が減った際には、必ず都度メール等の記録に残る形
    で費用の確認をする。
    ・見積もりは最終金額のみでなく、項目に過不足がないかしっかり確認する
    見落としていたこちら側にも非はあるため、実際に行った作業に対しては支払いを
    行うのが望ましいが、予算不足の場合には丁寧に交渉する
    

    View Slide

32. トラブルシューティング
    指示編
    ・最新のデザインや仕様の指示を都度メールで送っていたが、完成したも
    のがところどころ古い内容が混ざっていた
    ・途中で担当の変更があったが、仕様のやり取りを口頭でしか行っておら
    ず今までの決定事項が全くわからない。
    ・認識のすり合わせを行うミーティングで無駄に時間がかかった。
    

    View Slide

33. トラブルシューティング
    指示編
    ・最新のデザインが常にわかりやすいようにダウンロード URLの一覧表を作る、
    　クラウドサービスで共有し常に最新をダウンロード可能にする、など工夫する
    ・仕様の指示は、指示書を用意して常に最新の情報を集約する。
    ・口頭でのやり取りは、必ずメールなどにも備忘録を残し、指示書にもまとめる
    ・とにかく「担当者にしかわからない」という状態を無くすように心がける
    

    View Slide

34. まとめ
    

    View Slide

35. まとめ
    ・外注先は対等なパートナーと心得て、信頼関係を大切にする
    ・最初になるべく多くの情報を伝えること、制作中の仕様変動、運用後の
    　
    ことまで意識して依頼することが大切
    ・スケジュールは確認タイミングをこまめに明確にすることが重要
    ・SLA、指示書などドキュメントに情報を集約することが大変重要
    ・進行は相手に任せきりにせず、常に遅延の可能性とリカバリ方法を意識
    　
    しながらこまめに進捗確認、コントロールをする
    

    View Slide

36. コーディング外注時の進行ポイント
    ご静聴ありがとうございました。
    Presentations by SKYGUILD
    

    View Slide