人的要因によるミス発生時の対応方針です。技術的な確認事項は着手前確認リスト、品質管理シートで行います。
| 作業状況 | リスク要因 | 重大性 | 可能性 | 発生してしまった場合の対応 | 私はこうする(対策・リスク除去・軽減) | |
|---|---|---|---|---|---|---|
| 1 | デザインからページのコーディング | 作業中、仕様の認識ズレが発覚 | 軽 | 中 | • 急ぎの問題であれば、整理した後すみやかに連絡、判断を | |
| • かえって手間になってしまう細かい問題は、一度仮説で制作。初稿時に、対応した策と他の考えられる選択肢を提示提示します。その上で間違っていれば修正いたします。 | • 着手前に仕様確認シートを作成、提出( 必要な場合 )、 | |||||
| OKをもらってから制作開始 | ||||||
| • コーディング内容以外に、ファイル構成やスラッグなども確認 | ||||||
| 2 | WordPressの機能実装時・ | |||||
| 複雑な演出実装時 | 承諾後、技術的に実装が難しいと発覚 | 中 | 中 | • 当日～翌日に代替え案を複数提示、判断を仰ぐ | • 技術的な不確実性が高い箇所を優先的に構築する。デザインやバリデーションよりもまず技術実装性を担保する | |
| 3 | WordPressやCMSの本番サーバー適用・更新 | **適用後、画面が真っ白になる。 | ||||
| 調査と復旧に時間がかかり、すぐに対応できない。 | ||||||
| DBが壊れる。** | 重 | 中 | • 状況を整理し、すみやかに連絡。 | |||
| • FTPログインがわからない場合、管理画面に入れれば、そこからファイラープラグインなどを導入。WPトップのwp-config.phpを確認し、WP_DEBUGをtrueに書き換える。 | ||||||
| • エラーが確認できれば、該当ファイルを確認し修正。 | ||||||
| • プラグインが原因であれば無効化。 | ||||||
| • 修正後はwp-config.phpのデバッグを元に戻す。 | • まずバックアップをとりローカルに保存 | |||||
| • 事前にFTPを教えてもらっておく( セキュリティは考慮するが、作業の安全に必要なため。必要であれば作業後はパスワードを変えてもらう ) | ||||||
| • テストサーバーが本番と同じ条件か確認する | ||||||
| **• 要因がPHPの場合、PHPファイルの最後の空白が、xserverではOKだがlolipopではNGでエラーが発生、WordPressのデバッグがOFFのためエラーが見えず真っ白。という事はある。 | ||||||
| • 対策として、機能のみのphpは最後の”?>”を書かない。** | ||||||
| • 責任が重いなら夜中作業を提案して時間確保も考慮する。 | ||||||
| 4 | 初稿提出後・納期が近い | 先方都合で急な仕様変更 | 軽 | 大 | • 影響範囲と工数概算を出して報告 | |
| • 間に合わせるため実装方法の代案を出すか、先方都合の予定外であれば、納期を何日か伸ばしていただくよう相談 | • 発生予測自体は困難なため、想定した上で納期よりも数日早めの初稿を計画する。 | |||||
| 5 | • スケジュールの都合や体調不良等で進捗に影響が出た | |||||
| • 経験した事がないものを事前調査せず実装しようとした | ||||||
| • ECなどwebサービスが絡み、個人完結しない作業で情報を聞きそびれて休日に入り進まなくなった | 納品に間に合わないと発覚 | 重 | 中 | • 発覚した場合は即座に連絡。代案を出すか、まず致命的な部分を聞き優先して終わらせて先行提出。 | ||
| • 遅れても被害が少ない箇所を確認し、続いて提出していく。 | ||||||
| ※人の気持ちとして一言謝罪は必要ですが、謝っても誰も助るわけではないため、どうしたら現場は収まるのかを前提に動きます。建築業界の教訓です。 | • 不確実性を考慮し、状況が安定するまではスケジュールを常に前倒しで詰めていく(想定ページ数終わっても、余力で残りのページを進める ) | |||||
| • あまりに短期間(1-2日等)の話はよほど慣れた会社からの依頼でなければ請けない。 | ||||||
| • 実際に実装できると想像する1.5～2倍の納期で見積もる。 | ||||||
| 6 | バックアップを取らずに長期間作業 | 作業途中のPCやプロジェクトがクラッシュしてデータ紛失・すぐに作業続行困難 | 重 | 大 | • まず連絡、自分で再構築可能な状態なのか、他者に任せた方がよいか判断し、その旨を伝える。 | |
| • 後にPC復旧。必要であれば再度プロジェクトデータをいただき、確定していた内容を再構築する。 | • メインPC以外での連絡手段の確保 | |||||
| • 可能であればサブで仕事PCを持つ | ||||||
| • 定期的にgithubにプッシュ、一定のまとまりや資料はzipでまとめてフラッシュメディアかgoogleDriveなどにも退避。ローカルストレージを過信しない。 | ||||||
| • 可能であれば信頼のある同業者を繋がりをもち、緊急時に代行してもらう手段を確保。ただし秘密保持上の問題が発生する。 | ||||||
| 7 | zipでの受け渡しをしており「こちらで修正したプロジェクトをマージしてください」と言われた | 上書きした際に、納品済みページに関わるCSSやhtmlが崩れたがどこが変更されたか気づかず最終納品後に発覚 | 中 | 低 | • 気付いた部分については随時修正対処していく。 | |
| • 「過去のページが崩れている」といった連絡を行う。 | • マージ前にバックアップ。githubにプッシュ。 | |||||
| •「 WinMerge」を使用して差分を目視確認しながらマージする。 | ||||||
| 8 | • 作成したサイトをステージング環境にアップした | |||||
| • 連絡をするためNotionを共有状態にした | ||||||
| • ファイルの受け渡しをするため、一時的なファイルをアップロードした | ||||||
| • 効率化を考え、生成AIに顧客とのやりとりを無差別に投げた | 公開されてはいけない情報が漏洩する | 重 | 低 | • 状況を整理し、何が公開状態かすみやかに連絡。 | ||
| • 公開されているものがあれば、公開状態を取り下げる。 | ||||||
| ※ただし、発覚するケースでは連絡をするよりも、連絡が来るパターンが想定される。 | • ステージング環境にはBASIC認証を設ける | |||||
| • Notionは一定期間後に公開OFFにする、Web検索ONにしない、共有URLをオープンな場に貼らない。共有されているページの上に辿れないか公開範囲を確認する。 | ||||||
| • プロジェクトzipファイルのやりとりは、chatworkなど指定された場所を使い、なるべくパスを付ける。 | ||||||
| • 頻繁で工数が増えてしまう場合は考慮するが、近年はクライアントから「セキュリティ管理体制の徹底」を求められるケースもあるため、ルールとして共有し、自然に行うようにしておいた方がよい。 | ||||||
| • 生成AIには実装と関係ないものは渡さない。必要な場合でも個人情報・固有名にマスキングするか、ローカルLLMを使用する。 | ||||||
| ※一般的な世に公開済みの情報は別とする |