ホスティング屋のISO20000ブログ

ITベンチャーが、ISOを取得する上で、
注意しなければいけない点をお話しています。

ISO20000を取得する上で、圧倒的に有利な人材がいます。
それは、

・メーカー出身者

です。もちろん、ITILを学んだ人も有利です。
同様に、ISO構築チームに、メーカー出身者がいたら、同じくらい重宝されると思います。

ISOの基本は、ISO9000です。ものづくりの品質管理の世界。
このベースとなる考え方、言葉は、ITベンチャーには正直、馴染みがないのです。
「開発？やってないよ、うちは運用だけだよ」という会社はなおさら。
ちなみに、ここで言うメーカーは、開発を含みます。
開発は立派なものづくりだからです。
開発のマネジメントを規定した「PMBOK」とISO20000が一緒に語られること、なんとなく多いと思いませんか？

取得のときを振り返ると、要求事項書いてある「間接費の配賦」の"配賦"読み方を、隣の席の人と「ハイフ？ハイブ？」と悩んでみたり。
「目標」を立てても、学校の「めあて」とか「スローガン」とか、それに近いものだったり。
うーん、なんか違う（というか大間違い）。
「基本は9000だよ」とセミナーで聞いた足で、
品質管理関連の入門書を読みあさることになりました。

取得を目指される方は、まず、ISO27001や20000関連の「図解」から入ると思うのですが、もう一冊、品質管理の図解も本棚にぜひ加えてください。
要求事項（特に前半のマネジメントシステムの部分）がよくわかるようになります。

先日、ソフトウェアのQAの仕事をされていたエンジニアさんが、
ご入社されたのですが、まるで留学中に日本人に会ったかのような感動を覚えました。
「間接費の配賦は・・・」と聞くと、「ハイブorハイフ論」より先に、
「データセンターは○○で、回線は××で、工数は▼▼で管理して、顧客ごとにこんな風に...」
と予実管理をしている資料を見せてくれました。
わぁ、話が早い！！

「ものづくり」では、体系化された考え方があり、管理手法があります。
メーカー出身の方は、それを普通に使いこなしているのだな、と頭が下がりました。
ISO20000はITサービスの「品質管理」なので、ISO27001以上に、
ISO9000で定義されているような、QCDや顧客要求事項、という考え方が重要です。

ISOの構造としては、どの規格も共通で、
・「マネジメントシステム」の要求
・「個別の分野の要求（品質、環境、セキュリティ、サービスetc）」の要求
の2つで構成されています。プライバシーマークも同じですね。
マネジメントシステムの要求に、個人情報保護に特化した要求が乗っかっています。

ITILを学んだ人が重宝されるのは、後者の部分。
メーカー出身者が重宝されるのは、前者の部分。
そんなイメージです。

ISO20000の構築・運用に関わられている方は、プロジェクトチームの編成や、
日頃のプライベートのおつきあいを、こんな視点で見直されてみてはいかがでしょうか？

ITベンチャーがISOやプライバシーマークを取得、運用していく上で、
注意しなければいけない点＝新米事務局の失敗をお話したいと思います。

反省(1)「雛形通りに作るのは10年早い」

「さぁ、マネジメントの仕組みを作るぞ！」と意気込んで、
（※まったく、今思うと恥ずかしい意気込みです）
参考書を開くと、帳票例がいっぱい出てきます。
帳票例の押印欄が、5つ、6つ設けられていて戸惑うわけです。
「え！私の上には部長と社長の2人しかいないのに！？」と。

間違いなく、参考書はある程度の規模の会社を想定しています。
この通りに作成すると、担当者は紙の管理だけで1日業務が終わってしまいます。

業務を再設計する際は、
今ある業務と、あるべき姿を照らし合わせて、ない部分をどう実現するかを考えます。
自分は要求事項をもとに、付け足す作業をしたわけですが、
そのない部分を付け足す際に、雛形をそのまま採用しそうになりました。
すると雛形だけで何十という書式を、新たに管理する事態に・・・

雛形は一旦横において、斜めから眺めながら、
「もっとカンタンな方法はないかな？コンパクトにならないかな？」
と一捻りさせなければ、と心得ました。

コンパクトにすると統制のレベルが下がるのでは、と心配される向きもあると思うのですが、
ISO27001ですが、以前、関係者の方がこんなことを仰っていました。

「御社は紙の文化ですか？印鑑が好きなのですか？（笑）
　ITの会社なんだから、電子データで管理したらどうですか？
　電子印鑑がない？では、共有ドライブに適切に担当者と責任者を分けて権限管理をすることで、
　責任者が承認した、とみなすこともできるのではないですか」

この方がおっしゃっていたのは、こんな感じです。

手順「責任者は『承認前申請書フォルダ』の申請書を確認したら、
　　『承認後申請書フォルダ』に申請書を移す」
┌────┐　　　　　　　┌────┐
│承認前　│　　　　　　　│承認後　│
│申請書　│──────→│申請書　│
│フォルダ│　　　　　　　│フォルダ│
└────┘　　　　　　　└────┘
担当者：作成・更新可　　　　担当者：作成・更新不可
責任者：作成・更新可　　　　責任者：作成・更新可

※等幅フォント以外でご覧の方は崩れて見えます。ごめんなさい。

客観的に「責任者が見ている」ということがわかればいいわけです。
「紙、いらないんだ！」これは目からウロコでした。

組織のマネジメントシステムですから、要求事項は一緒でも、
業種・業態・規模によって、それをどう実現するかは、千差万別になるはずです。
あくまで雛形は、ITベンチャーにとって10年以上先のあるべき姿と心得て、
次の更新審査（3年先）のあるべき姿を追うくらいが、
ちょうどよいのかなぁ、と思う今日この頃です。

(2)以降はまた次回お話します。

ITベンチャーがISOやプライバシーマークを取得、運用していく上で、
注意しなければいけない点＝新米事務局の失敗をお話したいと思います。

反省(1)「雛形通りに作るのは10年早い」

「さぁ、マネジメントの仕組みを作るぞ！」と意気込んで、
（※まったく、今思うと恥ずかしい意気込みです）
参考書を開くと、帳票例がいっぱい出てきます。
帳票例の押印欄が、5つ、6つ設けられていて戸惑うわけです。
「え！私の上には部長と社長の2人しかいないのに！？」と。

間違いなく、参考書はある程度の規模の会社を想定しています。
この通りに作成すると、担当者は紙の管理だけで1日業務が終わってしまいます。
世の中には、ISO事務局のアウトソーシングなんてビジネスもあるそうです。

業務を再設計する際は、
今ある業務と、あるべき姿を照らし合わせて、ない部分をどう実現するかを考えます。
自分は要求事項をもとに、付け足す作業をしたわけですが、
そのない部分を付け足す際に、雛形をそのまま採用しそうになりました。
すると雛形だけで何十という書式を、新たに管理する事態に・・・

雛形は一旦横において、斜めから眺めながら、
「もっとカンタンな方法はないかな？コンパクトにならないかな？」
と一捻りさせなければ、と心得ました。

コンパクトにすると統制のレベルが下がるのでは、と心配される向きもあると思うのですが、
ISO27001の関係者の方が、以前こんなことを仰っていました。

「御社は紙の文化ですか？印鑑が好きなのですか？（笑）
　ITの会社なんだから、電子データで管理したらどうですか？
　電子印鑑がない？では、共有ドライブに適切に担当者と責任者を分けて権限管理をすることで、
　責任者が承認した、とみなすこともできるのではないですか」

この方がおっしゃっていたのは、こんな感じです。

手順「責任者は『承認前申請書フォルダ』の申請書を確認したら、
　　『承認後申請書フォルダ』に申請書を移す」
┌────┐　　　　　　　┌────┐
│承認前　│　　　　　　　│承認後　│
│申請書　│──────→│申請書　│
│フォルダ│　　　　　　　│フォルダ│
└────┘　　　　　　　└────┘
担当者：作成・更新可　　　　担当者：作成・更新不可
責任者：作成・更新可　　　　責任者：作成・更新可

※等幅フォント以外でご覧の方は崩れて見えます。ごめんなさい。

客観的に「責任者が見ている」ということがわかればいいわけです。
「紙、いらないんだ！」これは目からウロコでした。

組織のマネジメントシステムですから、要求事項は一緒でも、
業種・業態・規模によって、それをどう実現するかは、千差万別になるはずです。
あくまで雛形は、ITベンチャーにとって10年以上先のあるべき姿と心得て、
次の更新審査（3年先）のあるべき姿を追うくらいが、
ちょうどよいのかなぁ、と思う今日この頃です。

(2)以降はまた次回お話します。

内部監査の打ち上げは、いつもビールのおいしいところか、鍋か。
すなわち、当社では、毎年夏と冬に内部監査をやっています。
今日は、今年の夏の内部監査が行われています。

当社の場合、監査員としてみなさんにヒアリングすると、
監査を受ける人の態度は、当社は概ねこの3タイプに分類されます。
※筆者の主観です。

・挑んでくる人（25%）
「私は正々堂々と正しく業務をしています！
　さぁどこからでも掛かって来い！」
こちらも気持よくリスクを発見することができます。
監査は客観的に淡々と、と思いつつ、楽しいものです。

・トップに声を上げて欲しい人（5%）
内部監査の報告は社長のもとに届くので、
業務の実情や悲喜こもごもを、広くに知って欲しい方には、
絶好の機会だったりします。

・素直な人（70%）
圧倒的に多いです。社風だと思います。
「はい、やっていません」
そんなにあっさり認めるの！？とこちらが焦ってしまうことも...

こんな人口分布ですので、いつも審査機関の方が審査に来ると、
内部監査報告書を見て、その件数の多さに驚かれます。
といっても、事故が多発しているわけではなく、
当社は、文書の誤字脱字も、忘れないように指摘しておいて、
サービス改善計画で、進捗管理しているのですね。
この辺りは、その会社ごとにやり方があると思います。

さて、今、審査と内部監査、2つの言葉が出てきました、
これらはどう違うのでしょうか？

○第一者監査（内部監査）
    組織内で行う監査です。経営者が、社員や代理人に指示して行ないます。
○第二者監査（外部監査）
　　組織が、取引先を監査するものです。
　　例えば、「このサービスは、契約にあたって、セキュリティは大丈夫かな」
　　といった視点で、
　　お客様→当社の業務を監査
　　当社→サプライヤのデータセンタを監査
　　といったケースがあります。契約前、更新前、または定期的に行われることが多いですね。
○第三者監査（外部監査）
    独立した第三者（認証機関など）が、ある法律や標準、ガイドライン等
　　をもとに、その基準を満たしているか、監査するものです。

今回の内部監査は第一者監査、審査は第三者監査になります。

「え、だったら、内部監査はいらないんじゃないの？
　審査の方がより客観性も高いんでしょ？」
と一瞬、思いがちですが、PDCAを回す上では、
自社内にチェック機能を設けることも重要です。

日本内部監査協会が公表している「内部監査基準」によると、
内部監査は、「助言」や「支援」も含んでいます。
Checkの結果をもとに経営や業務をサポートする位置づけです。
一方、審査のほうは、審査登録機関はコンサル業務をやってはいけないと、
定められていますから、経営や業務のサポートは直接できません。

このように役割が違うので、PDCAを回す上で第一者監査と、
第三者監査は併用が効果的であるとされています。

PDCAの上での内部監査と審査のそれぞれの位置づけ、
もう一度確認して、有効に機能するよう努めたいと思います。


参考：内部監査基準
http://www.iiajapan.com/guide/kijun-j.htm

ITIL Foundation v3、合格者インタビューの第3段です。
今回も、理解しにくい用語との戦いがテーマです。

今日の主役は、営業職の大村昌之さん（2年目）。
営業職の大村さんは、ITの現場の言葉をどうやって獲得したのでしょうか？


Q「合格したのはいつですか？」
A「2010年2月中旬です」

Q「勉強期間はどれくらいですか？」
A「1月中旬頃からだったので、1～1ヶ月半といったところですね」

Q「時間にすると？」
A「平日は20分とか30分とか・・・休日は勉強できたので、トータルで40時間前後でしょうか」

Q「使った教材は何ですか？」
「「IT Service Management教科書 ITIL V3 ファンデーション (ITサービスマネジメント教科書) (単行本（ソフトカバー）)」とWeb上で無償提供されているテスト教材です。
　教科書を読み、理解して、章末の問題に臨み、知識を定着させました。
　Webのテストは理解度を確認するために使いました」

Q「振り返ってよかったと思うことってありますか？」
A「こうしておけばよかった、という反省なのですが、
　 もう少し計画的に勉強を進めればよかったと感じますね。
　 じっくりと理解することで、初めて業務に知識が生かせると思うのですが、
　 ITILは経験がないと、用語が取っつきづらく、理解するのに、とにかく時間がかかります。
　 覚えるのに必死だったので、もう少し余裕を持って、理解しながら進めたかったです」

Q「そうはいいつつも、受かっていますよ（笑）
　　合格のポイントがあるとしたら、何だと思いますか？」
A「実務と紐付けると、用語が覚えやすいです。
　　テキストを読み進める中で、随時、自分の周りの仕事をイメージしながら、
　　どういった業務のことを指しているのか、確認しながら理解しました。」

Q「学習中、もっとも大変だったことを教えてください」
A「眠気...（笑）テキストを開くと、眠くなりました（笑）
　眠気の原因は、とにかく、理解しにくい用語が多かったからだと思います。
　例えば、「RFC」。英語の略称なので、ピンと来にくいです。
　理解しないままテキストを読み進めると、またRFCが随所に出てきて、余計に混乱しました」

Q「勉強前と勉強後、変わったことはありますか」
A「業務への理解が深まりました。
　　例えば、SLAはお客様のためにある印象を持っていたのですが、
　　サービスを運営する上で、社内の業務でも有益なもので、
　　私たちのためのものでもあるのだ、とわかるようになりました。
　　仕事の流れ、仕事のキホンを学ぶことができました。」

Q「これから受ける方に、メッセージをお願いします」
A「ITILの学習は理解に時間がかかります。
　 合格後を考えると、用語の暗記だけではなく、理解したほうが実務に生かせます。
    計画性を持って、理解の時間を確保して、勉強を進めてください！」

インタビューへのご協力ありがとうございました。
分かりにくい用語は、実務と紐付けることで、理解ができるそうです。
みなさんも、IT業界にいる方の話を聞くなどして、
イメージをふくらませながら、用語を攻略してください。

スカイアーチネットワークスでは、
ITIL Foundation資格の取得を応援しています！

ITIL Foundation受験者のみなさん、
意味のピンとこない用語に悩まされていませんか？
確かに、ITILはマネジメントの視点ですから、
特に若手のみなさんは、しっくり来ないかもしれません。

しっくり来にくい、用語の攻略をどうするか？？
今日は、入社3年目のエンジニア、鳥井充さんに伺ってみましょう！

-----

Q「合格したのはいつ頃ですか？」
A「2010年2月です」

Q「合格した科目は？」
A「ITIL V3です」

Q「勉強期間はどれくらいですか？」
A「4日です」

Q「合計すると何時間ぐらいだったんでしょうか？」
A「25時間くらいですね」

Q「使用した教材を教えてください」
A「・WEB (ネットで内容・単語を調べる)
　 ・WEB 問題集」

Q「振り返って、合格のポイントってなんだったんでしょうか？」
A「単語をただ覚えるだけでなく、其々の単語の繋がりと必要性・関係性を理解する
ようにしていました。
また、試験範囲の全体像を理解することを心がけていました」
 
Q「もっとも大変だったことや困ったことはありますか？」
A「知らない言葉が多く、ネットで調べるので時間がかかった事。
　どのような形式の問題がでるか分からないので、勉強をしていて不安でした。」

Q「勉強前と勉強後、変わったことはありますか？」
A「社内で言っていたPDCAへの理解が深まり、行動に起こしやすくなりました。
　 試験内容と会社のあり方に近い部分があるので客観視がしやすくなった実感もあります。」

Q「これから受験する方に、メッセージがあればお願いします」
A「ただの試験勉強ではなく、社会人として生きていくために必要なことが学べるの
　で楽しみながら勉強をしてもらえればと思います。
　資格をとってからがスタートになるような試験である気がします。」

-----

全体像や関係性から理解していくというアプローチ。
そして、1つ1つを理解しようという姿勢。
私も参考になりました。

スカイアーチでは、ITILをサービスに活かしてゆくため、
教育の一環として、ITIL Foundationの資格取得を応援しています♪

ISO20000導入のお話の続きです。
導入は遡ること4年前。

当時、当社は運用のプロフェッショナル集団。
Linuxで腕を鳴らすエンジニアさんたちがゴロゴロ。
営業担当者までがコマンドを叩ける（もちろん社長も）という恐ろしい技術者集団です（笑）
社員数は20人足らず。
組織的な運用はこれからといった段階。
輝かしい技術と実績の裏には、
時に深夜まで残るエンジニアさんたちの姿がありました。
当社は残業が少ないほうでしたが、それでもサーバーは、
私たちの生活にお構いなしに落ちます。
24時間365日の運用を、若さに頼るのは限界がありました。

ITIL導入にあたっての全社プレゼンでは、ITILの導入事例を紹介。
「1人あたり、今の4倍のサーバー台数が見れるようになります！」
その言葉に、みなさん目を輝かせていたのを覚えています。

既に運用のプロフェッショナルとして業務が確立していたので、
インシデント管理と構成管理を中心に再構築し、
他のプロセスはフレームワークに従い、整理するに留めました。
「PDCAで改善していきましょう！」
改善を継続していくことが大切であることを、全社で学びました。

2007年の夏に審査を終えて、
2007年の秋に取得。

さて、今は。

世間ではクラウドがバズワードとなり「ITはサービスとして提供される」
というフレーズにも、違和感を覚えなくなりました。

さて、当社は。

当時の4倍の台数が見れているかといえば、その指標は達成されていませんが、
深夜まで残る人は、おかげさまでめったにいなくなりました。
20時頃、監視システムのアラートが鳴ったと思ったら、
なぜか会社に飲み屋さんから電話が来ることも。
「エンジニア誰かいるー？」
と、アラートに心配したあるエンジニアさんからのお電話でした。
※飲み屋のエンジニアさんはサポートにはあたりませんので、どうぞご安心ください！

徐々に組織化が進んだ、その過程を振り返ると、
・社長が現場に入って、組織的な仕組み作りの旗をふったこと
・マネージャーがPDCAを着実に回し、改善を重ねたこと
・エンジニアのみなさんが組織的な運用の真意を理解し、
　手間を惜しまず管理のための業務を実践したこと
社長を含めての"現場力"がカギだったのではと思います。

2010年5月。
ITIL教科書を手に、ITのライフサイクルを学習する新入社員を見て、
「ITも、当社も、変わったんだなぁ」
と、感慨深く感じる今日この頃です。

ついにこの夏、当社は初めての更新審査を迎えます。
更新審査は3年に1度の、認証取得時と同じ日数をかけて行う、厳しい審査です。
3年前と今、ISO20000を取り巻く環境は、とても変わったな、と思います。

私（前事務局）が、ISO20000を本格的に勉強しはじめたのは、2006年の夏でした。
ISO27001の移行を済ませて、一段落していた矢先、
移行の情報収集をする中で知り合ったISO関連の方から情報をいただきました。

早速本屋でITILv2のサービスデリバリーを手にとり、衝撃が走りました！
日々、社内で議論されている問題の答えが「ベストプラクティス」として書かれているのです。
当時は、「ITは技術」というのが当然の認識。

「ITはサービス」

と言い切るITILに、前事務局は「ITの革新が始まるのでは！」と心踊りました。

翌日、早速社長に情報共有までにメールをしたところ、数分後には調査の指示が。
「ITはサービス」とあらゆるサービス業の研究をしていた社長ですから、
共鳴できるものがあったのだと思います。

調査をすると、ISO20000は運用業務そのものであること、
ISO27001のフレームワークがそのまま生かせることから、
ISOを取得していた運用のプロであるスカイアーチは、
「自社で取れる」と判断し、自社導入に踏み切りました。

（後編へ　12日13:00に更新します）

昨年頃より日本でも急速に普及したTwitter。
当社でも多くの社員が自らのアカウントを運営中。
情報収集に使ったり、チャット状態で楽しんでいたりと、皆思いのまま楽しんでいます。
これからもIT企業として、全社でソーシャルメディアのリテラシを上げていきたいものですね！

さて、2009年7月になんと、英国政府でTwitterのガイドラインが出ていたのはご存知でしょうか。
小林啓倫さんが、ご自身のブログで紹介し、和訳されています。
http://blogs.itmedia.co.jp/akihito/2009/08/twitter-templat.html

20ページ程度なので、ちょっとTwitter活用のヒントを知りたいという方は、
数百ページのTwitterガイド本を読むより概要が掴みやすいかもしれません。
例えば、こんな感じ。

4.予想されるリスク
リスク：Twitterの精神を理解していない、と批判が起きる（堅過ぎ、宣伝ばかり、人間味がない、など）
対処法：配信するコンテンツの種類を豊かにする。ただし、ある程度の批判は避けられないことは覚悟する

引用：http://blogs.itmedia.co.jp/akihito/2009/08/twitter-templat.html

まるで規格文書を読んでいるようですね。
「英国政府殿、御丁寧にありがとうございます！」といったところです。

 英国政府はこういった標準化が得意なのだと、
以前、審査員をされている方から教わりました。

ISO20000のもととなるのは、ご存知ITIL。
これも英国政府が定めたものです。
 ITIL自体はベストプラクティス集で、標準化規格ではないのですが、
実はISO化以前に、標準化規格として、BS150000という名称で規格化されていました。
ちなみに「BS」は、British Standardsの略です。

そして今やメジャーになった情報セキュリティ分野、ISO27001も、
もとはBS7799という英国の規格が、国際的な規格となったものです。

うーん、イギリスは、とてもやり方が上手ですね。

今、日本の各審査機関が対応を進めているのは、「BS 25999:2007」。
ここ数年、ISO化の準備が水面下で進んでいるようです。
BS 25999は、事業継続分野の規格です。
地震が多発する日本では特にニーズが高そうですね。
既に、JQA、BSI、日本検査キューエイなどで審査が受けられ、
認証を取得した企業も出ている模様。

1匹目のどじょうをゲットしたい企業は「BS」の国際標準化の動向に注目です。

日ごろからお世話になっているIT業界の先輩が、
ITIL Foundationに見事合格したとの知らせが舞い込んできました。
この場を借りて、おめでとうございます！
早速マイクを向けてみました。

Q「勉強時間はどれくらいですか？」
A「2週間くらいです。時間にすると15～20時間程度です」

Q「これまでITILの経験はありましたか？」
A「会社に書籍はありますが、本格的な導入はしていません。
　 役に立ったのはITILの経験というよりは、業界の経験でしょうか。
　 V3で、上流から下流までのライフサイクルで再編成され、
　 イメージが沸きやすくなったので、勉強しやすかったです。」

Q「教材はどんなものを使いましたか？」
A「教科書と、ITILを解説した参考書籍、模試です。
　 教科書では足りないので、参考書籍でフォローしました」

Q「当日はどのように試験が進められたのですか？」
A「試験予定日1週間前に、プロメトリックに申し込みました。
　 土日だったので、既にかなり枠は埋まっていました。
　 当日は会場に出向き、説明を受け、パソコンの前に座りました。
　 試験時間は60分でしたが、30分程度で一通り解き終わってしまいました。
　 わからない問題は検討もつかなかったので（笑）、
　 手ごたえのないまま、思い切って、終了ボタンを押すと、
  「合格」の文字が。ほっとしました。」

Q「学習中の方にアドバイスがあるとしたら、どんなことですか？」
A「まず、ライフサイクルと対応づけて、すべてのプロセスが言えるようになることが大事です。
　 どんな目的のプロセスかまで理解し、それも言えるようになるとよいでしょう。」

貴重なお時間ありがとうございました！
上記のインタビューが、勉強中の方のご参考になれば幸いです。

社内からも合格者が出ている模様です。
折を見て、PART2を掲載したいと思います。