私たちは、開発プロジェクトにおけるトラブルの多くが「技術」ではなく「コミュニケーションのズレ」に起因すると考えています。そのため、安心してプロジェクトを進めていただくために、コミュニケーションに関するSLA（対応基準）を公開しています。
| 基本情報 | 内容 |
|---|---|
| 適用範囲 | 請負契約のみ |
| 営業時間 | 9:30〜18:30（平日）／土日祝・年末年始を除く |
| 不定期休業日 | 夏季休暇・GW・社内研修日など、事前に判明している不定期の休業日はSlackにて事前にお知らせします |
| 営業時間外の連絡 | 翌営業日の9:30以降を起点として対応時間を計算します |
営業時間内のご連絡に対して、以下の基準で対応します。
営業時間内（9:30〜18:30）のご連絡には、原則4時間以内に一次対応を行います。一次対応とは、内容確認・受付・対応予定の共有を指します。担当者不在など止むを得ない場合は、代理または翌営業日の午前中に対応します。
障害・本番影響が発生した場合は、原則15分以内に初動対応を開始します。営業時間外の緊急連絡については、事前に合意した緊急連絡先への通知を起点として対応します。
仕様確認・技術質問は、原則24時間以内に一次回答または回答予定を提示します。内容の複雑さにより調査に時間を要する場合は、その旨と回答予定日を先にお伝えします。
一次対応とは「完全な回答」ではなく、以下を含む対応を指します。
「未返信状態」を発生させないことを最優先にしています。完全な回答に時間がかかる場合でも、必ず受領と対応予定を先にお伝えします。
連絡手段は状況に応じて以下の通り使い分けます。
| 状況 | 推奨手段 |
|---|---|
| 通常の連絡・質問・報告 | Slack・プロジェクト管理ツール（チケット等） |
| 打ち合わせ | 対面・オンライン問わず、AIによる文字起こしを実施。ヌケモレ・聞き間違いを防止します |
| 緊急時（障害・本番影響） | 電話・訪問（Slackへの併記も推奨） |
口頭・電話での重要なやり取りは、後からSlackまたはプロジェクト管理ツールに内容を記録します。記録のない連絡は仕様変更として扱いません（4章参照）。
認識のズレを防ぐために、以下のルールを徹底しています。
仕様に関する重要なやり取りは、口頭のみでなく必ずテキストで記録します。後から「言った・言わなかった」が発生しない環境を作ります。
口頭での合意は正式な仕様変更として扱いません。必ずテキストや記録に残した形で確認を取ります。
実装に入る前に、仕様の認識合わせを必ず行います。曖昧なまま進めることはしません。
不明な点があった場合、推測で実装を進めることはせず、必ず確認を行います。小さな確認を怠らないことが、後半のトラブルを防ぎます。
仕様変更により、以下の項目をすべて更新します。
口頭のみ・DMのみでの仕様変更は正式な変更として扱いません。変更内容は必ず上記のすべての項目を記録・確認します。
プロジェクト内の未確定事項はすべて一覧化し、以下の4点を明確にします。これにより「決まっていなかった」を防ぎます。
| 管理項目 | 内容 |
|---|---|
| 未決定内容 | 何が決まっていないかを明文化します |
| 判断者 | 誰が決めるべき事項かを明確にします |
| 判断期限 | いつまでに決める必要があるかを設定します |
| 影響範囲 | 未決定のまま進んだ場合の影響を共有します |
毎週1回、以下の内容を共有します。プロジェクト全体の透明性を重視しています。
以下の場合は、定例会議などを待たず即時共有・相談を行います。
障害・本番影響が発生した場合、緊急度レベルに応じて以下の基準で対応します。進展がない場合も定期的に状況を共有し、「何も連絡がない」状態を発生させません。
| レベル | 内容の例 | 一次対応 | 状況報告の頻度 |
|---|---|---|---|
| Lv.1 最高 | 全停止・全ユーザー影響 | 15分以内 | 1時間ごと |
| Lv.2 高 | 重要機能停止（一部ユーザー影響） | 30分以内 | 1時間ごと |
| Lv.3 中 | 機能停止・回避策あり | 1時間以内 | 2時間ごと |
| Lv.4 低 | 軽微な不具合・表示崩れ | 4時間以内 | 翌営業日に1回 |
| Lv.5 対応検討 | 要望・改善提案 | 翌営業日以内 | 別途合意 |
障害を認知してから、レベルに応じた一次対応時間以内に対応を開始します。対応開始の旨と現時点での状況認識を発注者に共有します。
対応中は、レベルに応じた頻度で状況を報告します。進展がない場合も「現在も調査中」など、進捗の有無にかかわらず必ず連絡します。
復旧完了後、速やかに完了の旨を報告します。あわせて、以下の内容をまとめた報告書を提出します。
| 報告項目 | 内容 |
|---|---|
| 原因の特定 | 障害が発生した原因を特定し、技術的な背景を含めて説明します |
| 対応内容 | 復旧のために実施した対応内容を時系列で記録します |
| 再発防止策 | 同様の障害を防ぐための対策を提示します |
納品物に対するフィードバックの期限を以下の通り設定します。検収期限を明確にすることで、プロジェクト全体の遅延リスクを防ぎます。
| 納品の種類 | フィードバック期限 |
|---|---|
| 画面・機能単位の部分納品 | 原則5営業日以内（規模により個別に調整） |
| フェーズ単位・最終納品 | プロジェクト開始時に別途合意した期限に従います |
検収期限内にフィードバックをいただけると、後続タスクへの影響を最小限に抑えられます。期限内の対応が難しい場合は、早めにご連絡ください。調整します。
私たちが定めるこのSLAは、発注者の皆さまに「安心」を提供するためのものです。トラブルが起きてから対処するのではなく、トラブルが起きない構造を最初から設計する——それが私たちの開発スタイルです。
このSLAは、私たちと発注者の皆さまが協力し合うことで機能します。未決定事項の判断期限を守っていただいたり、仕様変更の際にテキストで確認いただけると、このSLAをより確実に守ることができます。一緒に良いプロジェクトを作りましょう。
技術より、コミュニケーション。
STVテックが発注側に立つ理由
このSLAの背景にある考え方を体系的に解説した15分のガイドです。
ガイドを読む →