データ消失事故から2年！ファーストサーバ、再生への第一歩 第2回

会社ぐるみで取り組んだGAP分析、ヒヤリハットなどの施策を聞く

信頼を失ったファーストサーバが挑んだ事故調査と再発防止

顧客の情報を消失してしまうという前代未聞の事故を起こしたファーストサーバ。事故対応とともに進められたのが、事故原因の調査と再発防止策の立案だ。ここでは外部を巻き込んだ事故調査体制の構築やGAP分析、ヒヤリハットなど一連の施策について聞いた。

自分たちだけの調査ではお客様には信じてもらえない

　第1回で紹介した事故対応と並行して同社で行なわれたのが、再発防止のための緊急対策だ。同社では外部のメンバーも参加した第三者調査委員会を立ち上げると共に、再発防止のためのリスクマネジメント体制を作った。

社長室村竹：これだけ大きな事故を起こしてしまったので、自分たちだけで調査して、報告してもお客様には信じてもらえないと思いました。そこで、外部の人たちを混じえた第三者調査委員会をいち早く設置し、事故の原因と再発防止策のとりまとめをお願いしました。そこでまとめられた再発防止策をとにかくすぐにやるというのが、喫緊の課題でした。

「自分たちだけで調査して、報告してもお客様には信じてもらえないと思いました」（村竹氏）

　第三者委員会から一番大きな問題として指摘されたのは、開発と運用の権限が分離されておらず、牽制のない業務フローになっていた点だという。たとえば、システム変更作業が発生する時に、担当者が上長に報告し、スケジュール調整の後にそのまま実行していた。つまり、いつ、誰が、なんの目的で変更作業を行なうのか、きちんと共有されていなかった。そのため、事故の時になにが起こったのか、把握するだけでも多くの時間を費やしていた。

開発担当藤原：ベンチャーに近いところから、18年近くレンタルサーバーをやってきた。サービスを構築し、トラブルを修正しという日常業務を淡淡とやり続けてきて、業務フローや承認のプロセスなどを見直す機会がなかった。メンバーの行動に依存していた部分が多かったと思います。

　そこで、組織面での刷新を行ない、同一組織だった開発と運用の組織を分離。開発と運用の権限分離を明確化した上で、開発と運用のプロセスを考える専門の部署を期間限定で創設し、変更管理をどうするかを考えた。開発と運用の分離はシステム面でも徹底されたほか、ルールだけ決めても徹底されないので、ツールも導入された。

運用担当松本：本番環境に変更を加えるのは運用担当に限定し、サービス基盤に独自にアクセスできないよう、アクセス経路も統一した。開発者であっても、サポートからのエスカレーションで障害の原因追及を行なう以外は、サービス基盤へのアクセスは禁止。アクセス時も運用担当から時限的なアクセス許可を得て、操作ログも完全に取得・保存されるようにした。

開発と運用が一体化した組織を分離し、権限を明確化した

　また、当時行なっていた同一筐体内へのバックアップは、リスクの低減にならないという点も第三者の調査委員会から指摘されたところだ。そこで、事故が起きたサービスはもちろん、対象とならなかったサービスも、二次バックアップを取るような作業を進めた。事故が起こったサービスは事故から2ヶ月経った2012年の8月に、その他のサービスは2013年9月に別筐体への二次バックアップを取得する作業を完了した。

現場の反発もあったGAP分析で潜在リスクを洗い出す

　一方、再発防止策を進めるべく、事故の2ヶ月後にリスクマネジメント委員会が立ち上げられた。一般企業のリスクマネジメント委員会では、CSRや事業リスクまでを取り上げているが、ファーストサーバのリスクマネジメント委員会は、ISMS（Information Security Management System）で対象となっているリスクを、ことさら高い経営レベルで対応するという特徴を持っている。

　再発防止の施策として、リスクマネジメント委員会では、潜在リスクを洗い出す「GAP分析」も実施した。GAP分析とはコントロールしたいリスクを「長時間のサービス停止」「データロスト」「情報漏えい」と定義し、ISMSの実装の手引きをベースにリスクを洗い出すというものだ。具体的には、運用と開発担当が、各項目で5段階の評価を行ない、結果を集計。基準値に満たない23項目については、2013年3月からツールを用いた事象管理を推進した。

　もちろん、これら一連の再発防止策はすべてスムースに行ったわけではない。当然、「面倒」「時間がかかる」「今まででいい」といった声が上がり、以前のやり方でやっていた現場からの反発も大きかった。

運用担当松本：納得してくれる人は早かったけど、納得してくれない人もいたでしょう。今まで自由にやれていたことが、突然ルールに縛られるようになったので、反発は大きかったです。でも、結局きちんとしたプロセスに則ることで、安全にできるし、みんなが同じルールで動けば、効率的に回るんです。このプロセスを現場で根付かせていくことが、もっとも重要だと思いました。

「今まで自由にやれていたことが、突然ルールに縛られるようになったので、反発は大きかった」（松本氏）

　当初、反発は多かったが、ツールを用いた事象管理を始めた結果、3ヶ月後には入力にも慣れ、KPIが計測できるようになった。一元管理の便利さや重要さを実感できるようになったことで、今ではツールを使った事象管理が定着。定期的に分析して、業務改善に役立てているという。

　とはいえ、一度作ったプロセスだからといって正解ではない。環境やサービスによって、今後も変えていかなければならないというのは、みんなに伝えたという。

運用担当松本：会社としてああいった事故を起こして、変えていかなければならないとは誰もが感じていたはず。みんな、どこかで折り合いをつけてくれたんだろうと思います。

（次ページ、約600件におよんだヒヤリハット）