ラクラス
ニュースレター
キタハラコラム
マイナンバーの
リアル
キタハラコラム第1回「コアとコンテクスト」では、米国の著名なITコンサルタントであるジェフリー･ムーア氏が主張する「コア業務の定義」を紹介しました（キタハラコラム第1回へ⇒）。彼はコア業務を、「ターゲットとする市場における自社製品あるいはサービスの競争優位に、直接の影響を与える業務」と定義しています。コア業務以外のすべての業務を、彼はコンテクスト業務と呼んでいます。給与計算業務は、企業の競争優位に直接の影響を与えない業務であり、したがってコンテクスト業務に分類されます。
キタハラコラム第1回では、「コンテクスト業務には嫌な特徴がある」ということも説明しました。コンテクスト業務にとっての最優先課題は効率です。競争優位に影響しない業務に費用をかける必要はありません。しかし、効率を追求するあまり品質が一定のレベルを下回ると、その瞬間、深刻なトラブルが発生するというのが、コンテクスト業務の嫌なところです。
給与計算業務が好例です。どの企業も給与計算作業にコストをかけたくありません。しかし一方で、給与計算を間違えることは、会社に対する従業員の信頼を毀損します。あるいは、源泉徴収税や社会保険料の支払いに重大な障害を与えます。内部統制の視点からみれば、財務諸表への影響も深刻です。このように、コンテクスト業務の品質不全には、様々なペナルティが課せられるのです。
まして給与を支払うことができない事態など、人事部にとっての悪夢です。通貨払い、直接払い、全額払い、毎月1回以上の定期払いという大原則を損ねれば、それは労働基準法違反になってしまいます。
ラクラスは、「事業継続性を確保し、安定したサービスを安心してご利用いただけるように努める」ことを、お客様への約束として明文化しています（ラクラスの経営理念へ⇒)。人事BPO、人事クラウド、給与アウトソーシングといったサービスを提供するラクラスにとって、事業継続性の確保はお客様に対する最大のコミットメントです。
今回のキタハラコラムでは、ラクラスの事業継続への取組みについて説明いたします。
まず、災害復旧計画 (Disaster Recovery Program：以下DRと表記します) と事業継続計画 (Business Continuity Program：以下BCPと表記します) という用語を定義しておきます。
DRは、情報システムの復旧について定めています。情報システムの中には、ハードウェア、ソフトウェア、ネットワーク、あるいは物理的な配線などのすべてを含みます。そしてBCPは、情報システム以外の経営資源の復旧について定めています。
私はこの区分を、世界最大の情報処理サービス企業の米国本社のセキュリティ担当者から教わりました。「DRとBCPの間のどこに境界線があるのかわからない」という私の困惑に対して、彼らは即座にLANケーブルの接続口を指さしました。「ここが境界線だ」。
つまり、「接続口の内側のデジタルな世界がDRの対象領域。そして外側のアナログな世界がBCPの対象領域」だと彼らは言うのです。
この区分は、日本では決して一般的ではありません。ほとんどすべての文献やウェブサイトは、両者を混合して論じています。データセンターのホームページを見れば、「サーバをデータセンターに移設してBCPを強化しよう」と謳っています。サーバを移築したところでDRは強化されますが、BCPは強化されません。BCPとは、事業継続に必要な情報システム以外の設備であり、社員であり、彼らが働く場所を対象とした計画書なのです。
ラクラスは、「接続口が境界線」という定義に従って、最初は半信半疑でDRとBCPの構築を開始しました。しかし実際にやってみると、この定義は実に有効に機能するのです。二つの計画が、全体としては協調しつつ、しかし個別の責任範囲はきれいに区分されて、ラクラスのDRとBCPは完成しました。完成後も毎年定期的にテストを行い、改良に努めています。
キタハラコラムは、この区分に従って説明することにいたします。
災害復旧計画 (Disaster Recovery Program：以下DRと表記します) は、情報システムの復旧について定めています。情報システムの中には、ハードウェア、ソフトウェア、ネットワーク、あるいは物理的な配線などのすべてを含みます。
ラクラスのDRでは、通常稼動しているインターネットデータセンター (Internet Data Center：以下IDCと表記します)を基本IDCと呼んでいます。基本IDCがディザスタに直面した場合に稼動開始するのが遠隔地に置かれた代替IDCです。ラクラスが定義するディザスタとは、「お客様にサービスを提供する能力を著しく減衰させるすべての出来事」を指します。
ラクラスは、基本IDCにあるすべての機器を多重化しています。機器だけではなく、インターネット回線、電源設備、空調設備などの設備も多重化しています。機器や設備が停止した場合には、すみやかに代替機が稼動を開始します。「ASP・SaaS安全・信頼性に係る情報開示認定制度」で開示している当社クラウドサービスの稼働率は100％です（2012年4月1日から2013年3月31日までの実績値）。
また基本IDCにおいては、データのバックアップ処理を日次で実施しています。したがって、復旧できる最新の情報が最長で何時間前のものかを表すRPO (Recovery Point Objective：目標復旧時点)は24時間ということになります。
ラクラスは、この基本IDCに加えて、遠隔地に代替IDCを設置し、両者間をVPN回線で結んでいます。代替IDCには、サービスを提供するのに必要なすべてのハードウェアとソフトウェアの基本構成が設置されています。また、基本IDCのデータは日次で代替IDCに送られ、同期がとられています。
基本IDCがディザスタに直面してから代替IDCが稼動を開始するまでに最長で何時間かかるかを表すRTO (Recovery Time Objective：目標復旧時間) は72時間です。
この他にもDRには、災害復旧計画を発動する基準、緊急対応チームの組織体制や連絡体制、ネットワーク回線を切り替えるための作業手順、DR文書の保管場所（複数）などが定められています。
ディザスタ発生時には、このDR文書を全員が手に取り、災害復旧に向けての行動を開始します。
事業継続計画 (Business Continuity Program：以下BCPと表記します) は、情報システム以外の経営資源の復旧を定めています。ラクラスのBCP文書には、事業継続に必要な情報システム以外の経営資源として、①作業拠点、②電話、③メール、④データと文書、および⑤社員を挙げています。
作業拠点
ラクラスの社業は情報処理サービスですから、製造設備や原材料といった経営資源は不要です。事業継続にとって何よりも必要なのは、社員が業務を遂行するための作業拠点です。作業拠点がなければ、いくら情報システムが稼働できる状態だったとしても、事業を継続できません。DRとBCPは、重なり合いながらも、異なる領域に焦点を当てているのです。
ラクラスはディザスタという言葉を、「お客様にサービスを提供する能力を著しく減衰させるすべての出来事」と定義しています。とすると想定すべきは、震災による被害だけではなく、作業拠点が火事や浸水、あるいは停電や電力不足によって、使用できなくなるという事態への対応策が含まれてきます。
作業拠点を確保するためにラクラスは、毎日の業務を行っている文京区の基本作業拠点に加えて、2ヵ所の代替作業拠点を準備しています。１ヵ所目は、東京都区内にあります。基本作業拠点がサービス提供能力を失ったときの緊急対策チームの設置場所として、また最もクリティカルな業務を短期間で復旧するための作業拠点として準備されています。
2ヵ所目は、2013年3月に仙台に開設した東北オペレーションセンターです。大震災が発生したとしても、2ヵ所同時被災を免れえるだけの遠距離にあり、また継続的に業務を行うだけの社員数を収容できる拡張性と設備をもっています。
いずれの代替作業拠点からも、基本IDCおよび代替IDCへのネットワーク回線が準備されています。基本作業拠点がディザスタに直面してから代替作業拠点が稼働開始するまでのRTO (Recovery Time Objective：目標復旧時間) は72時間です。
②電話とメール
BCPには、電話やメール等の情報網を代替するための方針についても定められています。
電話については、携帯電話による代替が考えられます。また代替作業拠点には固定電話も備えられています。したがってBCPには、ディザスタ発生に際して、すみやかにこれらの電話番号をお客様に通知して、情報網を早期に確立することを定めています。
メールに関してラクラスは、社内でメールサーバーを保有せずに、外部のメールサービスを利用することで可用性を確保する方針を採用しています。したがってBCPでは、メールを代替する手段を定めていません。SNSは代替的に利用されます。
インターネット経由で外部のメールサービスを利用する際の機密性を確保するために、ラクラスは、個人情報等を含む機密情報のやり取りにメールやFAXを使うことを、そもそも禁止しています。これはディザスタ発生時だけではなく、通常の業務遂行においても同様に禁止です。ラクラスは、誤配信や不注意な転送等により情報流出のリスクをもつメールやFAXを、個人情報のやり取りに使っていません。
機密情報のやり取りを受け持つのは、ラクラスがクラウドで提供しているワークフローソフトウェア「LIP」です。LIPは、データファイルを暗号化して、特定の相手と安全にやり取りする機能を備えています。お客様との間の機密情報のやり取りは、すべてこのワークフローを通じてのみ実行されます。誤配信や不注意なメール転送による情報流出の可能性は限りなくゼロです。
データと文書
ラクラスは可能な限り広い範囲の業務処理を、デジタルデータの形式で実行しようとしています。お客様との間の情報は、ワークフローソフトウェアを使ってやり取りされます。受け取ったデータはそのまま人事データベースに蓄積されますし、給与計算の結果として生成された給与明細は、ワークフローソフトウェアを通じて社員の皆様に配信されます。すべてのデジタルデータは、基本IDC、代替IDC、および磁気記憶媒体に保存されます。つまりデータは二重三重にバックアップがとられており、ディザスタ発生時に逸失する危険性は限りなくゼロです。
課題となるのは紙媒体として保存されている文書です。日本において組織をまたがる情報のやり取りは、いまだに多くの場合、紙媒体を利用しています。政府が推進するE-Gov計画により市区町村、税務署、ハローワークといった官公庁に提出する書類の電子化は進んできました。それでもゼロにはなっていません。ラクラス社内には、そのような文書が保管されています。
BCPにおいては、これらの書類をできる限り救い出すことが定められています。しかしそれは、役職員の安全を確保した後の作業です。ディザスタに直面したときには、まず緊急避難して安全を確保します。そしてその後で、書類を救出するチームを編成します。救出できなかった書類に関しては、デジタルデータでその存在を明らかにし、再発行手続きを依頼することで、復旧を目指します。
社員
BCPは、最重要の経営資源である社員についても定めています。情報システムや作業拠点のように、社員を完全に二重化しておくことはできません。また電話やメールのように、外部の資源に完全に代替させることもできません。
ラクラスはBCPの中で、ラクラスが提供している一つひとつのサービスのすべてに対して、その重要性に応じた優先順位をつけています。そして、中でも最も優先順位の高い3つのサービスをクリティカルサービスと名付け、ディザスタに際してはクリティカルサービスに社員を集中することを定めています。
3つのクリティカルサービスとは、給与計算業務、お客様との間のファイル転送機能、およびお客様に納品したシステムの保守業務です。BCPは、すべての稼働可能な社員を、まずこの3つの業務に集中することを定めています。
さらにBCPは、稼働可能な社員の数に応じて、提供するクリティカルサービスのレベルを3段階に分けることを定めています。想定される中で最も甚大な被害は、東京が全滅して仙台だけが生き残るケースでしょう。この場合、前月度給与計算結果と銀行振込データをお客様に提出することが、ラクラスが保証するサービスレベルになります。稼働可能な社員が増えるに従い、入退社者の反映や変動情報の反映を行うことで、より上位のサービスレベルを提供していきます。
ラクラスのBCPでは、復旧への日程表をフェーズ1から4までの、4つのステージに分けて定義しています。
| フェーズ | 期間 | 目標 |
|---|---|---|
| ディザスタ発生時 | 発生時 | ・社員および訪問者の安全確保 ・ディザスタの初期評価 |
| フェーズ1 | 最初の1日 | ・DRとBCPの発動 ・組織および連絡網の確立 ・現状の調査・分析・評価 ・復旧戦略の策定 |
| フェーズ2 | 3日以内 | ・クリティカルサービスに必要な経営資源の稼働 ・クリティカルサービスの稼働 ・サービス範囲拡大のための経営資源の拡充 |
| フェーズ3 | 3日以内 | ・サービス範囲の拡大 ・完全稼働のための経営資源の拡充 |
| フェーズ4 | 1ヵ月以内 | ・経営資源の完全稼働 ・サービスの完全稼働 ・恒久的な作業拠点への引っ越し準備完了 |
1日、3日、1週間、1ヵ月という期間でのフェーズ分けは、現実的かつとても使いやすいフレームワークです。
ラクラスは、組織体制と連絡体制、情報システムと情報システム以外の経営資源、およびクリティカルサービスとノンクリティカルサービスにおいて、このフェーズ分けごとの目標を定め、相互に整合性をもった形で復旧活動を行っていきます。
事業継続計画を定めることと同様に重要なのが、その内容を組織に周知徹底することと、環境の変化に合わせて改訂を続けていくことです。最初に作ること以上に継続するのはとても難しいものです。
そこでBCPには、1年に1度以上のBCPテストの実施と規程の見直しを、経営陣が行うことを定めています。ラクラスではこの定めに従い、毎年5月にBCPテストを行っています。BCPテストとは、社長以下関係者が一堂に会し、事業継続計画規程の一行一行を読上げて、それが実行可能かどうかをシミュレーションしてみる作業です。
規程に定めた物品は実際その場所に存在するのか、記載してある電話番号は実際につながるのか、代替機は実際に稼働するのか、作業の順番に矛盾はないのか、といった一つひとつの作業を確認していきます。
規程と現実との間に差異があれば、規程を修正します。そして、修正された規程に従って、毎年全員に社員教育を行っています。
これは時間のかかる地道な作業です。しかし、あらかじめこのようなシミュレーションや教育を行っておくことが、いざディザスタに直面したときに生きてきます。DRとBCPがほぼできあがっていたために、ラクラスは2011年3月11日もスムースに緊急対応体制を構築することができました。準備は決して無駄にはなりません。
今回のキタハラコラムでは、お客様にサービスを提供する能力を著しく減衰させるあらゆるディザスタに対して、ラクラスが可能な限りの準備を整えていることを説明させていただきました。
