新鮮

頑張らないために頑張る

311 と BCP(Business Continuity Planning)

f:id:hiizumix:20180310192758j:plain

東日本大震災から 7 年が経とうとしている。

数万人規模の犠牲者をだした未曾有の大災害。知人の知人を亡くしたり、元彼女の家族が避難してきたり、といったエピソードがあったりするので、そんな話でもツラツラ書こうと思ってエディタを開いてみたが、いかんせんテーマが重すぎて全然キーボードが進まない。

そこで今回は「BCP」 を考えてみようと思う。

f:id:hiizumix:20180302185052j:plain

またよく分からない単語が出てきたね

 

BCP(Business Continulty Planning)

BCP とは事業継続計画。「災害が起こってもサービスを継続できるようにしておこうぜ」という計画を立てておけという話である。

「ん?企業は災害が起こっても儲けることしか考えてないのか?」

と思われるかもしれない。ただ、たとえばライフラインである電気・ガス・水道・情報あたりでは、被災者にサービス継続できないと人命に関わるため、単純に儲けを継続すると言うだけのお話ではない。このあたりは企業の社会的責任と言われる。きっとノブリスオブリージュでも気取っているのだろう。

 

情報システムにおける BCP

そんな BCP だが、情報システム業界では震災よりも前にコンサルが流行らせている。

情報システム業界における BCP とはディザスタリカバリ環境を作ること、とほぼ同義である(訓練だのRTO/RPOだのといった細かい話はある)。ディザスタリカバリ構成とは、ある機械とまったく同じ機械を別の場所にも構築して、災害などがあったら別の場所でサービスを継続させることができる構成である。

これは SIer 視点でみるとおいしい商売で、まったく同じ機械が何倍も売れるので丸儲けだ。またデスマーチリスクの高いソフトウェアは移植するだけでよい。さらにいえば保守費も倍額請求できる。まさにカモネギ状態である。ほんとコンサル様の大義名分創生スキルにはため息がでる。

実際、僕が所属する会社でも「BCP 検討委員会(仮称)」なる委員会が立ち上げられて、システムの重要度別にBCP対応をするしないを協議したり、BCP の場所をどうするだったり、災害訓練をしなきゃだめだよねだったりが検討されていた。

もちろん、BCP検討委員会(仮)の参加者全員が「データセンターが全壊するような災害なんて起きるわけ無いだろ?」と思っていたので、結局は西日本に「第 2 ○○センター」なる組織が作られ、第 2 ○○センター長といった役職が生まれて、エラい人の席が一つ増えただけで終わった。

そんななかで 311 が起きた。

震災時の状況は話が重くなるので置いておこう。

 

震災後の BCP

では震災後、情報システム開発はどうなったか。

いつもの通り「BCP 再検討委員会(仮)」が設けられる。前回と違うのはよく分からない総務部門らしきハゲが出張ってきて「新規システム構築や既存システム更改をおこなうときは BCP 対策を施すこと」などとほざくようになるわけだ。

あなたはもしかしたら「いいんじゃないの?」と思うかもしれない。

そう素晴らしいことだ。企業は社会的責任を果たすべきだし、それで救われる命があるのかもしれない。だがそういった社会派コメンテータが好きそうな話は、大体において現実に落ちると様々なハレーションを生む。世界は複雑系なのだ。

 

無茶な値下げ要求をする

まず RFP に「ディザスタリカバリ環境を構築すること」要件が組み込まれるようになる。すると同じ機械を複数用意するわけだから単純に倍額かかる。ソフトウェアは流用できるのでは?と思うかもしれないが、データを同期する仕組みを入れたりするのでトントンになる。

ところがモノが倍額かかるからといってシステム部門全体予算が倍になるわけではない。モノの値段とは関係なくお財布の総量は決まっているからだ(昨年度 -10%とか)。すると取りうる選択肢は、「やめる」か「無茶な値下げ要求をする」かの二択になる。システム部門には「やめる」権限はないので実質一択。そしてあなたの営業に「相談」が行く。

 

仕様変更が発明される

次に起こったことは仕様変更ラッシュである。

あたりまえだが「相談」にも限界があるので、ROI が満たされず取りやめになる案件が出てくる。ここで困るのは業務部門だ。業務のためにはシステムが必要だが案件が通らない。コストセンターまじぶっ殺す、と思いつつも、まあ一生懸命考え始めるのだ。

考えた結果どうなるだろうか。

少なからず通った案件に「仕様変更」として要件追加していくのである。隣の部は無事案件が通って開発を進めているのに自分の部は通らない。ならば隣の部の案件に自分の部の要件を混ぜてしまえばいい。そんな発想ばかりだ。

加えて、仮に案件が通った部署においても、今後の改修案件が通らなくなることは分かっているので、(使う使わないはさておき)現時点で考えうる全ての要件をぶち込んでくる

楽しいデスマーチの始まりである。

f:id:hiizumix:20180220143835j:plain

次はないって分かってたら全部ぶち込むよね。。

 

まとめ

企業の社会的責任を果たすため、確かに BCP は必要な考え方だ。だが、現実には

安全を求める → コスト削減要求 → デスマーチ誘発

といったユーザ企業ダイナミズムが働く。だからどうしたらいい?まではなかなか考えが及ばず申し訳ないが、今日はそんなことをなんか書いておきたかった。

おわり