事業継続マネジメント雑感

事業継続マネジメント（じぎょうけいぞくマネジメント、BCM: Business continuity management）とは、リスクマネジメントの一種であり、企業がリスク発生時にいかに事業の継続を図り、取引先に対するサービスの提供の欠落を最小限にするかを目的とする経営手段である。できあがった成果物を事業継続計画 (BCP) という。

via ja.wikipedia.org

というのが一通りの説明ではある。しかし、想定されるリスクとして災害や犯罪を引き合いに出す事例が多く、どうも現実味がない。特に中小零細企業は、大地震の対策としてデータセンター契約（リソース配置）の多重化を導入する資金なんてないわけだし（国民金融公庫その他が融資をしているのは知っている）、事業継続にかかわるリスクとしては、取引先の倒産とか支払い拒否の方がよほど切実だと思う。もちろん、将来像を描くという意味では災害にも耐えうる業務フローや陣容を組み立てることは考慮すべきかもしれないが、それはリスクマネジメントを少しでも勉強すれば誰でも思い浮かべることだし、さしあたっては、「そこが実際に検討すべき課題となるまでの事業規模に育てることが、自社の目標なのか」という視点で考える方がよいだろうと思う。別にみんながみんな、池袋と堂島と沖縄の三箇所のデータセンターを借りるくらいの事業規模にしたくて会社をやっているわけではないだろう。リスクアセスメントへの対応策や BCP は、しょせん情報セキュリティの担当者が決めるようなものではなく、経営者に判断材料を提供するフレームワークなのだ。

情報資産（無形）や、それらを保有し守っている物理資産（有形）という姿で想定されるオーソドックスなペリメータモデルを前提に考えると、ISMS の範囲では人、物、そしてフローを含むマネジメントの三つが大きな事業リスクになるだろう。そこで、まず人を考える。業務マシンで Winny を使うようなバカはともかく、自宅マシンと会社の業務マシンを嬉しがって VPN で繋いでいるような、傍目からは「できる」ように見える人も、マネジメントの理屈から言えば同等の背任因子でしかない。ちょうど UFJ の関連会社で起きた漏洩事件でも分かるように、情報セキュリティやシステム開発の担当者を牽制しうる実効性がないと、マネジメント全体としては性善説を仮定することになり、やがては他の部署の社員についても牽制が甘くなるのだ（「セキュリティを担当しているくらいだから、ちゃんとやっているだろう」という理屈が通ってしまえば、「会社の業務だから、ちゃんとやっているのだろう」という過信に至るまでは数歩しかないと言える）。更には、情報セキュリティやシステム開発を担う者としての無頓着という過失はともあれ、もっと強調されていいのは他の部署の人々に対する啓発だろう。簡単な研修だけでも、「FTPのパスワードを外注さんにメールで送るのがそんなに危険だとは知らなかった」と気づく場合もあるからだ。

ここで現実的な話として中小企業内での牽制というテーマを取り上げてみると、一般にシステム担当者とセキュリティ担当者を別個に雇用するのは、原資配分として過剰だと思われている。なぜなら、たいていのウェブ制作プロダクションでは、システム開発の技術者は情報セキュリティにも強いという都市伝説がまかり通っているからだ。特にここで何度か書いたように、傾きかけた印刷会社やデザイン学校の学生が立ち上げたようなウェブ制作プロダクションでは、デザインと営業・経理以外の業務を「システム」と呼ぶ傾向があることからも分かるように（笑）、インターネット上の技術を使ってメシを食っていながら「分からないこと」や「怖いこと」は、システム担当者の領分だと思い込みがちである。

ただ、こうした点を無知なまま放置しないで正確に理解しているウェブ制作プロダクションであっても、情報セキュリティに関心のあるプログラマを雇えばよいという短絡に走りやすい。実際には、事業継続において大切なのはプログラマのスキルなどではぜんぜんなく、情報セキュリティマネジメントの実務能力、それから経営陣のコミットメントや決裁権の委譲なのだ。事業継続という観点からすると、いざとなれば経営判断で残留リスクを外注に転嫁したり、あるいは事業を一部だけ取りやめてリスク回避できるわけだから、従業員ひとりのサーバ管理技術やプログラミングスキルなど、はっきり言ってどうだっていいのである。

一例を挙げよう。いわゆる GENO ウィルスや NineBall が流行っているからといって、納品物のアップロードをいちいちシステム担当者に依頼していたのでは、業務フローの点からリスクがシステム担当者に集中してしまう。すると、彼が（俺のことじゃないよ。うちはもっとまともな運用である）病欠したり、死んだり、あるいは急に退職してしまったら、その企業では誰が制作物をどうやって納品するのだろうか。もちろん、いまだにデザイナーやディレクターの中にはサーバ内のパスが理解できない人も多いので^*、それぞれの案件を担当する人がめいめいで恐る恐るコンテンツをアップロードするような結果になりかねない。あるいは、退職したり休んでいる彼には及ばなくても、スキルとして少しはマシな人に再び業務が集中するという愚行を重ねることになる。

このような状況を解決するためには、何が必要だろうか。それぞれの従業員が残業時間を１時間増やして、ネットワークやセキュリティの勉強をすればよいだろうか。あるいは、知らないあいだにいなくなった技術者と同等のスキルをもつ従業員を、再び専任として雇用すればよいのか。

前者は、中小企業では実例に乏しい（ベンチャーだから多そうだと誤解されがちだが）。なぜなら、残業したところで、受託案件を優先する（全てはお客様のために！）という名目がある限りは、実作業時間が延長されたり、顧客対応に追われ続けるだけだからだ。残業ではないが、現実に 10% ルールのようなものを導入している企業のように、マネジメントや経営判断で従業員を守り、統制しない限り、NHK やテレビ大阪がドキュメンタリーのネタとして泣いて喜ぶような自発的取り組みで会社を底上げできるなどと考えるのは、高度成長期伝説やものづくり大好きっ娘、あるいは極端な「底辺主義」の経営者が口走る妄想以外のなにものでもない。

後者のやり方でよいと考える経営者については、再び同じリスクを背負うわけだが、現実にはこの選択しかないように思える。なぜなら、ウェブ制作プロダクションの受注金額の相場を考えると、まじめにセキュリティや事業継続計画を考慮して原資配分をやっていたら、生き残れる企業など殆どないからだ。だからと言って、実質が伴わないルールを作って自分で自分を誤魔化し続けたり、あるいは徒に業容を縮小してみても先は見えないだろう（主事業に絞っても事業継続可能なら業容は縮小してもよいだろうが、ビジュアルデザインや、あるいは口利きまがいのコンサルティングだけで勝負し続けられるウェブ制作プロダクションが、いったい国内にどれだけあるのか）。

このように見てくると、正直なところ事業継続どころか業界としての見通しすら全く先がないように思えてしまうのだが、幾つか改善を試して期待がもてそうなヒントはあると思う。例えば、業務フローの検討は比重が軽いように見えるが、改善すると情報セキュリティマネジメントだけでなく事業継続マネジメントにも効果があるのではないか。概算見積もりと詳細見積もりを分けて出すことすらしない企業もある中で、「簡単ですから」と言われて軽く見積もった金額に縛られてしまうケースは、予想以上に多い。これはもはやクライアントや代理店の方が一枚上手だとかいったレベルの話ではないように思う。そろそろ受注する側の下請け・孫請けにあたる制作プロダクションやオープン系の開発会社は、そうしたいい加減な発注リクエストを「隠れた与件の秘匿」と呼べる一種の違法行為として検討してもよいのではないか。そこまで行かなくても業務フローや商慣行を印刷・広告業界の悪習から改善することにより、結果として適正な工数が割けなくなったり、セキュリティテストを Nessus などのツールだけで済ませてしまったり、更にはツールの警告で「Apache のバージョンが古い」と言われても、「サーバのメンテナンスなんて受注してねーし、俺らは作って納品するだけだろ、知ったことか」という雰囲気にならずに、納得いく仕事ができるかもしれない。こっちだってきちんと仕事はしたいのだ。クライアントや代理店は、アメリカの軍事・医療ドラマか報道番組の緊急シーンさながらのドタバタに高揚感を求めているのかもしれないが、凡人が慌てて作る商品など所詮はクズだと思い知ることだ。

業務フローをかたちづくる作業（「なんたらフェイズ」みたいなお題目を考えることではなく）は、部門長や役員が共同で責任を負って精査し、改善していかなければならない。自社の業務フローを維持するということは、とりもなおさず顧客相手に自分たちのやり方を押し通すということにもなるからだ。そこを引き続けていいようにあしらわれるのが「サービス」なのか、それとも一個の企業として譲れないところは守るのか。それは経営陣にしか決められない。末端の従業員に自発的な向上を期待するというのはマネジメントの放棄であって、そんなことを従業員に望むのは会社ではないと思う。