SLA(Service Level Agreement、サービスレベル合意書)とは、サービスの提供者と利用者が「どの水準を、どう測り、届かなかったときにどうするか」を取り決めた文書です。 項目名と数値だけを並べた SLA は、月末に「守れたのかどうか」で意見が分かれます。測定方法・集計期間・除外条件まで書いて初めて、同じ数字を見て同じ判定ができます。

この記事では、6つの項目について測定方法と目標値の記入例を付けた一覧表、稼働率ごとの許容停止時間、計画停止を除外したときの稼働率と減額率の計算、SLI・SLO との違い、そのまま貼って使える合意書のひな形を載せます。題材は架空の「社内の備品予約システム」です。契約条項に関わる部分は一般的な項目の例であり、最終的な文言は各社の契約書式と法務の確認に従ってください。

確認環境:Ubuntu 24.04 / Python 3.11.15(計算はすべてこの環境で検算、確認日 2026-10-05)。SLI・SLO・SLA の定義は Google の公開書籍「Site Reliability Engineering」第4章を今回開いて確認しています。

この記事の結論

  • SLA の1項目は「指標・測定方法・集計期間・目標値・除外条件・未達時の扱い」の6点セットで書く。 どれかが欠けると、守れたかどうかを判定できない。
  • SLI は測る値、SLO は内部の目標、SLA は未達時の扱いまで含めた約束。 SLO は SLA より厳しく置き、その差を対応の余裕にする。
  • 稼働率 99.9% は月30日で 43.2分、年365日で 8時間45.6分の停止まで。 対象時間を平日9〜18時に絞ると 10.8分になる。
  • 計画停止を除外するかどうかで、同じ月の稼働率が 99.95% にも 99.40% にもなる。 除外の条件(何日前に通知したものか)を必ず書く。

SLAの項目例と目標値の早見表

目標値はすべて記入例です。数値はシステムの重要度と体制に合わせて置き換えてください。

項目 指標(SLI) 測定方法 集計期間 目標値の記入例 除外条件の例
可用性 稼働率(%) 外形監視が1分ごとにログイン画面へアクセスし、3回連続で応答が無い時点から復旧までを停止時間とする 暦月 99.9% 以上 5営業日前までに通知した計画停止、利用者側の回線・端末に起因する停止
応答時間 画面応答時間の95パーセンタイル(秒) アプリケーションサーバーのアクセスログから、予約一覧画面のリクエストを集計する 暦月(サービス提供時間内) 2.0秒 以内 一括出力などの重い処理、合意した同時利用数を超えた時間帯
障害通知 検知から第一報までの時間(分) 監視の通知時刻と、連絡用チャンネルへの投稿時刻の差 障害1件ごと 30分 以内(サービス提供時間内) サービス提供時間外に検知したものは翌営業日の開始から起算
復旧時間 障害発生から復旧までの時間(時間) 障害管理票の発生時刻と復旧確認時刻の差 障害1件ごと 重大な障害は4時間以内、それ以外は翌営業日中 利用者の確認待ちの時間、広域の災害
問い合わせ対応 一次回答までの時間(営業時間) 問い合わせ管理票の受付時刻と最初の回答時刻の差 暦月 4営業時間以内の割合が 90% 以上 受付時間外の問い合わせは翌営業日の開始から起算
バックアップ 取得の成功率(%)と、戻せる時点(RPO) バックアップジョブの終了コードと、月1回の復元テストの結果 暦月 成功率 100%、RPO 24時間、保管 30日 利用者が削除を依頼したデータ

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

(記載例)出典:株式会社RJC「SLAの項目例と目標値一覧 SLO・SLIとの違いと合意書ひな形」

表計算ソフトに貼るときは、次のタブ区切りを使ってください。

項目  指標  測定方法    集計期間    目標値 除外条件    未達時の扱い
可用性 稼働率(%)  外形監視が1分ごとにアクセスし、3回連続で応答が無い時点から復旧までを停止とする    暦月  99.9%以上 5営業日前までに通知した計画停止    月額料金の減額(別表)
応答時間    画面応答時間の95パーセンタイル(秒) アクセスログから予約一覧画面を集計   暦月  2.0秒以内  一括出力などの重い処理 改善計画を翌月の定例で提示
障害通知    検知から第一報までの時間(分) 監視の通知時刻と投稿時刻の差  障害1件ごと  30分以内   サービス提供時間外は翌営業日の開始から起算   原因と再発防止策を報告
復旧時間    発生から復旧までの時間(時間) 障害管理票の発生時刻と復旧確認時刻の差 障害1件ごと  重大な障害は4時間以内 利用者の確認待ちの時間 原因と再発防止策を報告
問い合わせ対応 一次回答までの時間(営業時間) 問い合わせ管理票の受付時刻と回答時刻の差    暦月  4営業時間以内が90%以上   受付時間外は翌営業日の開始から起算   改善計画を翌月の定例で提示
バックアップ  取得の成功率(%)とRPO   ジョブの終了コードと月1回の復元テスト 暦月  成功率100%、RPO24時間、保管30日   利用者が削除を依頼したデータ  再取得と原因の報告

SLI・SLO・SLAの違い

3つは「測る値」「目標」「約束」の順に積み上がる関係です。Google の「Site Reliability Engineering」第4章では、SLI を「提供しているサービスの水準を表す、慎重に定義した定量的な尺度」、SLO を「SLI で測る水準の目標値または範囲」、SLA を「SLO を満たした(満たさなかった)ときの結果を含む、利用者との明示的または暗黙の契約」と説明しています。

SLI SLO SLA
正式名称 Service Level Indicator Service Level Objective Service Level Agreement
ひとことで 測る値 内部の目標 契約上の約束
中身 稼働率、応答時間、成功率などの測定値 SLI に対する目標値と集計期間 目標値に加えて、未達時の扱い(減額、報告、改善計画)
決める人 開発・運用の担当者 開発・運用のチーム 提供者と利用者の双方
見る人 運用担当者 チーム内 利用者、契約の担当者
届かなかったとき (値そのものなので、届く・届かないは無い) チーム内で優先順位を見直す 合意した扱いを適用する
備品予約システムでの例 外形監視で測った月間稼働率 99.96% 月間稼働率 99.95% 以上 月間稼働率 99.9% 以上、下回った月は月額料金を減額

同書は、SLO と SLA の見分け方として「SLO を満たせなかったら何が起きるか」を問うことを挙げています。明示的な結果が決まっていなければ、それは SLO です。

SLOをSLAより厳しく置く理由

SLO を SLA と同じ値にすると、SLO を割った時点で SLA も割っています。 内部の目標を一段厳しく置いておけば、その差が「利用者との約束に触れる前に手を打てる時間」になります。同書も、利用者に示す値より厳しい内部 SLO を使うと、慢性的な問題が外から見える前に対応する余地ができると述べています。

備品予約システムの例で、月30日の許容停止時間に直すと次のとおりです。

区分 稼働率 月間の許容停止時間 意味
SLO(内部目標) 99.95% 21.6分 ここを超えたら改善作業を優先する
SLA(約束) 99.9% 43.2分 ここを超えたら減額を適用する
差 0.05ポイント 21.6分 約束に触れる前に対応できる余裕

どれを決めるかの判断基準

状況 決めるもの
まだ何も測っていない まず SLI。1か月測ってから目標を考える
測っているが、どこまで良ければよいかの基準が無い SLO。直近の測定値より少し手前に置く
社内の利用者向けで、料金のやり取りが無い SLO を公開する、または未達時の扱いを「報告と改善計画」にした SLA
社外の利用者に料金を受け取って提供する SLA。未達時の扱いまで合意する
SLA の数値を先に求められている 測定した SLI を示し、SLO より緩い値を SLA に置く

稼働率と許容停止時間の早見表

稼働率の目標を決めるときは、パーセントを時間に直して「この時間で検知から復旧まで終えられるか」を考えます。次のコードで計算しました。

# 稼働率ごとの許容停止時間(月=30日、年=365日)
def fmt(minutes):
    h, m = divmod(minutes, 60)
    d, h = divmod(int(h), 24)
    parts = []
    if d: parts.append(f"{d}日")
    if h: parts.append(f"{h}時間")
    parts.append(f"{m:.1f}分")
    return "".join(parts)

MONTH = 30 * 24 * 60      # 43,200分
YEAR = 365 * 24 * 60      # 525,600分
print("稼働率   月間(30日)        年間(365日)")
for p in (99.0, 99.5, 99.9, 99.95, 99.99):
    rest = (100 - p) / 100
    print(f"{p:<6}%  {fmt(MONTH * rest):<14}  {fmt(YEAR * rest)}")

# 対象時間を平日9〜18時(月20日)に絞った場合
biz = 20 * 9 * 60
print()
print("24時間365日 :", MONTH, "分 → 99.9%の許容停止", round(MONTH * 0.001, 1), "分")
print("平日9〜18時 :", biz, "分 → 99.9%の許容停止", round(biz * 0.001, 1), "分")
稼働率   月間(30日)        年間(365日)
99.0  %  7時間12.0分        3日15時間36.0分
99.5  %  3時間36.0分        1日19時間48.0分
99.9  %  43.2分           8時間45.6分
99.95 %  21.6分           4時間22.8分
99.99 %  4.3分            52.6分

24時間365日 : 43200 分 → 99.9%の許容停止 43.2 分
平日9〜18時 : 10800 分 → 99.9%の許容停止 10.8 分
稼働率 月間(30日) 年間(365日) 体制の目安(例)
99% 7時間12分 3日15時間36分 営業時間内に人が気づいて対応する
99.5% 3時間36分 1日19時間48分 監視の通知を受けて営業時間内に対応する
99.9% 43.2分 8時間45.6分 夜間・休日も通知を受け、手順書で復旧する
99.95% 21.6分 4時間22.8分 冗長構成で自動的に切り替える
99.99% 4.3分 52.6分 人の操作を待たずに切り替わる構成が前提

同じ 99.9% でも、対象時間が「24時間365日」なら月 43.2分、「平日9〜18時」なら月 10.8分です。 対象時間を絞ると夜間の停止は数えなくなる一方、1回の停止が稼働率に与える影響は4倍になります。SLA には「サービス提供時間」を必ず書きます。

計画停止を除外した稼働率と減額率を計算する

計画停止(事前に通知して行うメンテナンス)の扱いは、稼働率の計算式そのものを変えます。月30日、計画停止4時間の月を例に、除外する場合としない場合を比べます。減額率の段階は例です。

MONTH = 30 * 24 * 60          # 集計期間:30日 = 43,200分
PLANNED = 4 * 60              # 計画停止:4時間 = 240分

def availability(total, down, planned, exclude_planned):
    if exclude_planned:
        base = total - planned            # 計画停止を分母から引く
        return (base - down) / base * 100
    return (total - down - planned) / total * 100   # 計画停止も停止として数える

# 減額率の例:(稼働率の下限, 月額料金に対する減額率)
CREDIT = [(99.9, 0), (99.0, 10), (95.0, 25), (0.0, 50)]

def credit_rate(avail):
    for lower, rate in CREDIT:
        if avail >= lower:
            return rate

print("障害停止  除外あり    減額  除外なし    減額")
for down in (20, 43, 44, 120, 440):
    a = availability(MONTH, down, PLANNED, True)
    b = availability(MONTH, down, PLANNED, False)
    print(f"{down:>4}分   {a:.4f}%  {credit_rate(a):>2}%   {b:.4f}%  {credit_rate(b):>2}%")

print()
print("除外ありで99.9%を守れる障害停止の上限:", round((MONTH - PLANNED) * 0.001, 2), "分")
障害停止  除外あり    減額  除外なし    減額
  20分   99.9534%   0%   99.3981%  10%
  43分   99.8999%  10%   99.3449%  10%
  44分   99.8976%  10%   99.3426%  10%
 120分   99.7207%  10%   99.1667%  10%
 440分   98.9758%  25%   98.4259%  25%

除外ありで99.9%を守れる障害停止の上限: 42.96 分

この結果から読み取れることは3つあります。

  • 除外しない計算では、4時間の計画停止だけで稼働率が 99.44% まで下がります。 障害が20分でも 99.9% には届きません。計画停止を行うサービスで 99.9% を約束するなら、除外の取り決めが前提になります。
  • 除外する計算では、分母が 43,200分から 42,960分に減ります。 99.9% を守れる障害停止は 43.2分ではなく 42.96分までで、43分の停止は 99.8999% となり目標を下回ります。
  • 99.8999% は小数第3位で四捨五入すると 99.900% と表示されます。 判定に使う桁数と端数の扱い(切り捨てか四捨五入か)を書いておくと、境界の月でも判定が1つに決まります。

減額の取り決めは、稼働率の段階と減額率の対応表にするのが分かりやすい形です。

月間稼働率 減額率(例)
99.9% 以上 なし
99.0% 以上 99.9% 未満 月額料金の 10%
95.0% 以上 99.0% 未満 月額料金の 25%
95.0% 未満 月額料金の 50%

社内向けのサービスで料金のやり取りが無い場合は、減額の代わりに「原因と再発防止策の報告」「改善計画の提示」を未達時の扱いにします。

守れたか判定できる書き方に直す

項目ごとに「第三者が同じデータを見て同じ結論になるか」を確かめます。直す前と後を並べます。

項目 直す前 直した後 補った点
可用性 稼働率 99.9% を目標とする 暦月ごとに、外形監視で測った稼働率が 99.9% 以上。稼働率は(対象時間 − 停止時間)÷ 対象時間で求め、対象時間から通知済みの計画停止を除く 集計期間、測定方法、計算式、除外条件
応答時間 画面は3秒以内に表示する サービス提供時間内の予約一覧画面について、サーバー側で測った応答時間の95パーセンタイルが暦月で 2.0秒以内 対象画面、測る場所、平均ではなくパーセンタイル
障害通知 障害時は速やかに連絡する 監視が障害を検知してから30分以内に、連絡用チャンネルへ第一報を投稿する。第一報には発生時刻・影響範囲・次の連絡予定時刻を書く 起算点、時間、手段、内容
復旧時間 早期に復旧する 重大な障害(全利用者が予約を登録できない状態)は、発生から4時間以内に復旧する 障害の重さの定義、起算点
問い合わせ対応 問い合わせには迅速に回答する 平日9〜18時に受け付けた問い合わせのうち、4営業時間以内に一次回答した割合が暦月で 90% 以上 受付時間、一次回答の定義、割合
バックアップ 毎日バックアップを取る 毎日2時にデータベース全体を取得し30日間保管する。月1回、検証用の環境へ復元して件数を照合する 対象、保管期間、戻せることの確認

応答時間に平均ではなくパーセンタイルを使うのは、少数の遅いリクエストが平均に埋もれるためです。「95パーセンタイルが2.0秒以内」は「100件のうち95件が2.0秒以内」という意味になり、利用者の体感に近い判定ができます。

目標値の決め方(5つの手順)

  1. 測る。 候補の指標を最低1か月測り、今の値を知ります。測れない指標は SLA に入れません。
  2. 利用者に聞く。 止まると困る時間帯と、待てる時間を聞きます。夜間に使わないシステムなら、対象時間を絞るほうが体制に合います。
  3. SLO を置く。 直近の測定値より少し手前の値を内部目標にします。測定値が 99.97% なら SLO は 99.95% という置き方です。
  4. SLA を置く。 SLO より一段緩い値にし、差を時間に直して対応の余裕として足りるか確かめます。
  5. 見直しの時期を決める。 半年または1年ごとに、測定値と利用状況を見て数値を更新します。見直しの手続きも SLA に書きます。

SLA合意書のMarkdownひな形

そのまま貼って、角かっこの部分を書き換えてください。契約に関わる文言は一般的な項目の例です。

# サービスレベル合意書(SLA)

| 項目 | 内容 |
|---|---|
| 対象サービス | [サービス名] |
| 提供者 | [部門名・担当者] |
| 利用者 | [部門名・担当者] |
| 適用期間 | [開始日] 〜 [終了日] |
| 版 | [1.0]([合意日] 合意) |

## 1. 対象範囲
- 対象: [対象とする機能・環境]
- 対象外: [対象としない機能・環境]

## 2. サービス提供時間
- 提供時間: [24時間365日 / 平日9:00〜18:00 など]
- 計画停止: [実施する曜日・時間帯]。[n]営業日前までに[連絡手段]で通知する

## 3. サービスレベル項目
| 項目 | 指標 | 測定方法 | 集計期間 | 目標値 | 除外条件 |
|---|---|---|---|---|---|
| 可用性 | 稼働率 | [測定方法] | 暦月 | [99.9%以上] | [除外条件] |
| 応答時間 | [95パーセンタイル] | [測定方法] | 暦月 | [2.0秒以内] | [除外条件] |
| 障害通知 | 第一報までの時間 | [測定方法] | 障害1件ごと | [30分以内] | [除外条件] |
| 復旧時間 | 復旧までの時間 | [測定方法] | 障害1件ごと | [4時間以内] | [除外条件] |
| 問い合わせ対応 | 一次回答までの時間 | [測定方法] | 暦月 | [4営業時間以内が90%以上] | [除外条件] |
| バックアップ | 取得の成功率、RPO | [測定方法] | 暦月 | [成功率100%、RPO24時間] | [除外条件] |

## 4. 計算方法
- 稼働率 =(対象時間 − 停止時間)÷ 対象時間 × 100
- 対象時間 = サービス提供時間 − 通知済みの計画停止の時間
- 停止時間 = [停止の定義。例:外形監視が3回連続で応答を得られない時点から復旧確認まで]
- 端数の扱い: [小数第3位を切り捨て など]

## 5. 除外事項
- [n]営業日前までに通知した計画停止
- 利用者側の回線・端末・操作に起因する停止
- 広域の災害など、提供者の管理が及ばない事由
- [その他]

## 6. 未達時の扱い
| 月間稼働率 | 扱い |
|---|---|
| [99.9%以上] | なし |
| [99.0%以上99.9%未満] | [月額料金の10%を減額 / 原因と再発防止策を報告] |
| [99.0%未満] | [月額料金の25%を減額 / 改善計画を提示] |

- 申請の方法と期限: [翌月n日までに、利用者から提供者へ連絡]

## 7. 報告
- 月次報告: 毎月[n]営業日までに、各項目の測定値と未達の有無を報告する
- 障害報告: 重大な障害は、復旧後[n]営業日以内に原因と再発防止策を報告する

## 8. 見直し
- [半年 / 1年]ごとに測定値と利用状況を確認し、双方の合意で改定する
- 改定の履歴: [版・日付・変更点]

記入例(備品予約システム)

# サービスレベル合意書(SLA)

| 項目 | 内容 |
|---|---|
| 対象サービス | 備品予約システム |
| 提供者 | 情報システム課 |
| 利用者 | 総務課 |
| 適用期間 | 2026-11-01 〜 2027-10-31 |
| 版 | 1.0(2026-10-20 合意) |

## 1. 対象範囲
- 対象: 本番環境の予約登録・予約一覧・管理画面
- 対象外: 検証環境、利用者の端末と社内ネットワーク

## 2. サービス提供時間
- 提供時間: 24時間365日
- 計画停止: 毎月第2日曜 2:00〜6:00。5営業日前までに社内掲示板で通知する

## 3. サービスレベル項目
| 項目 | 指標 | 測定方法 | 集計期間 | 目標値 | 除外条件 |
|---|---|---|---|---|---|
| 可用性 | 稼働率 | 外形監視が1分ごとにログイン画面へアクセス | 暦月 | 99.9%以上 | 通知済みの計画停止 |
| 応答時間 | 95パーセンタイル | アクセスログから予約一覧画面を集計 | 暦月 | 2.0秒以内 | CSV一括出力 |
| 障害通知 | 第一報までの時間 | 監視の通知時刻と掲示板への投稿時刻の差 | 障害1件ごと | 30分以内 | 平日9〜18時以外は翌営業日9時から起算 |
| 復旧時間 | 復旧までの時間 | 障害管理票の発生時刻と復旧確認時刻の差 | 障害1件ごと | 重大な障害は4時間以内 | 利用者の確認待ちの時間 |
| 問い合わせ対応 | 一次回答までの時間 | 問い合わせ管理票の受付時刻と回答時刻の差 | 暦月 | 4営業時間以内が90%以上 | 受付時間外は翌営業日9時から起算 |
| バックアップ | 取得の成功率、RPO | ジョブの終了コードと月1回の復元テスト | 暦月 | 成功率100%、RPO24時間、保管30日 | なし |

## 4. 計算方法
- 稼働率 =(対象時間 − 停止時間)÷ 対象時間 × 100
- 対象時間 = サービス提供時間 − 通知済みの計画停止の時間
- 停止時間 = 外形監視が3回連続で応答を得られない時点から、復旧を確認した時点まで
- 端数の扱い: 小数第3位を切り捨て

## 6. 未達時の扱い
| 月間稼働率 | 扱い |
|---|---|
| 99.9%以上 | なし |
| 99.0%以上99.9%未満 | 原因と再発防止策を翌月の定例で報告 |
| 99.0%未満 | 改善計画を10営業日以内に提示 |

ひな形の 5・7・8 節は、書き換えずにそのまま使える内容なので記入例では省いています。この記入例では、11月(30日、計画停止4時間)の障害停止が 42.96分までなら目標を満たします。前の節のコードで、合意前に境界の値を確かめておけます。

確かめて分かったこと

  • 計画停止を除外すると、許容停止時間も少し減る。 分母が 43,200分から 42,960分になり、99.9% の上限は 43.2分から 42.96分になりました。「99.9% は月43分まで」と覚えていると、43分ちょうどの停止で目標を下回ります。
  • 除外しない計算式では、4時間の計画停止1回で稼働率は 99.44% になる。 計画停止があるサービスで除外を書き忘れると、障害が無い月でも 99.9% に届きません。
  • 表示の桁数で判定が変わる値がある。 99.8999% は小数第3位までの表示で 99.900% になります。判定の桁数と端数処理を計算方法の節に書く理由です。
  • 対象時間を平日9〜18時に絞ると、99.9% の許容停止は月 10.8分。 24時間365日の 43.2分の4分の1です。対象時間を絞るときは、目標値も合わせて見直します。
  • SLO 99.95% と SLA 99.9% の差は、月に 21.6分。 0.05ポイントという小さな差に見えても、時間に直すと検知から復旧まで1回分の余裕になります。
  • Google の SRE 本では、指標の定義をそろえる項目として「集計の間隔」「測定の頻度」「対象に含めるリクエスト」「データの取得方法」を挙げている。 早見表の「測定方法」「集計期間」の列は、この考え方に沿っています。

よくある質問

Q. SLAとSLOの違いは何ですか? A. 未達時の扱いが決まっているのが SLA、決まっていない内部の目標が SLO です。「届かなかったら何が起きるか」を問い、減額や報告義務などの結果が合意されていれば SLA、チーム内の優先順位を見直すだけなら SLO と考えると区別できます。

Q. SLIとは何ですか? A. サービスの水準を表す測定値のことです。稼働率、応答時間、リクエストの成功率などが代表的で、SLO と SLA はどちらも SLI に対する目標値として書きます。

Q. SLAの稼働率はどのくらいに設定すればよいですか? A. 直近の測定値と、復旧にかけられる時間から決めます。99.9% なら月 43.2分、99.5% なら月3時間36分が上限です。検知から復旧までを手順書どおりに行って収まる時間かどうかを、体制と合わせて確かめます。

Q. SLAを達成できないときはどうなりますか? A. 合意書に書いた未達時の扱いを適用します。料金のあるサービスでは月額料金の減額、社内向けでは原因と再発防止策の報告や改善計画の提示とする例が一般的です。適用の条件と申請の期限も合意書に書いておきます。

Q. 計画停止は稼働率に含めますか? A. 事前に通知した計画停止は対象時間から除外する取り決めが一般的です。除外する場合は「何営業日前までに、どの手段で通知したものか」を条件として書きます。

まとめ

  • SLA の項目は「指標・測定方法・集計期間・目標値・除外条件・未達時の扱い」の6点セットで書く。
  • 項目は可用性・応答時間・障害通知・復旧時間・問い合わせ対応・バックアップの6つから始める。
  • SLI は測る値、SLO は内部目標、SLA は約束。 SLO を SLA より厳しく置き、差を対応の余裕にする。
  • 99.9% は月 43.2分、年 8時間45.6分。 対象時間を絞ると許容停止時間も比例して減る。
  • 計画停止の除外は計算式を変える。 除外の条件、判定の桁数、端数処理まで計算方法の節に書く。
  • 目標値は測ってから決める。 測れない指標は SLA に入れず、半年から1年ごとに見直す。

参考・出典

  • Google「Site Reliability Engineering」Chapter 4 - Service Level Objectives(https://sre.google/sre-book/service-level-objectives/ 、2026-10-05 確認)

本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。

(記載例)出典:株式会社RJC「SLAの項目例と目標値一覧 SLO・SLIとの違いと合意書ひな形」

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。

WE ARE HIRING

RJCで一緒に開発しながら、
成長を楽しみませんか?

RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!

  • 127日年間休日
  • 12時間平均残業時間
  • 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!

ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。

ABOUT RJC RJCがどんな会社か知る 考え方、研修、働き方、福利厚生、社員の前職まで。RJCのことが丸わかり! RJC丸わかりページへ JOB DESCRIPTION 仕事内容・待遇を見てみる 仕事内容、給与・待遇、選考の流れ。経験者も未経験も!応募前に知りたいこと、まとめました! 募集要項を見る ENTRY エントリーする エントリーは1〜2分・履歴書不要です。まずは話を聞いてみたい、という方でも歓迎です! エントリーフォームへ

RJCで一緒に開発しながら、 成長を楽しみませんか?