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

さて、今日は改善のためのフレームワークをご紹介します。
案を考えるというと、柔軟な発想や、奇抜なアイデアが必要なように思いますが、
考え方にも「型」があり、トレーニングで量産できるようになるものです。
あ、あくまで「質」じゃなくて「量産」ですよ（言い訳、言い訳...）。

改善提案のフレームワークで代表的なものをひとつ上げてみます。

「改善のECRS」
そのまま「イーシーアールエス」とか、人によっては「イクルス」とか読みます。
ある業務について、E→C→R→Sの順に考えていくというものです。

排除(Eliminate)
やめてみる。なくしちゃう。
例：
「書類の廃棄期間を決めていなかったが、保存期間を3年間と決め残りを廃棄したことで、探す時間が短くなった。」
「障害を15区分に分類し、分析していたが、5区分に整理し、10区分減らしたことで、傾向がつかみやすくなった」

結合(Combine)
くっつけてみる。
例：
「設定情報をAシステムに入力した後、Bシステムにも入力していたが、Bシステムの機能を、Aシステムに統合したのでAシステムへの入力だけで済むようになった」
「毎週決まった時間にデータセンターにオンサイト確認のために社員を派遣していたが、同じ週に他のデータセンターの作業があるときは、スケジューリングを工夫し一緒に済ませるようにした」

交換(Rearrange)
とりかえてみる。
例：
「本部長が作業の確認をしていたが、チームリーダーがやるようにしたことで、作業の確認の際に、細かなアドバイスもできるようになった」
「データで管理していた作業履歴を、紙にすることで、見える化が促進され、抜けや漏れが少なくなった」

簡素化(Simplify)
単純に、シンプルにしてみる。
例：
「A作業、B作業、C作業...それぞれに価格をつけ、お客様に都度お見積りをだし、受注していたが、定額サービスにしたので、依頼から作業まで迅速になった」
「文書のうち、決まって記入する項目や図をフォーマットにしたので、数カ所変更するだけで、文書が完成するようになった」

生産管理系の研修の中には、ECRSを使って、改善案をドリルのように考えさせるものがあるようです。なんてたくましい！

ECRSの中で、一番改善効果が高くて、一番難しいのが、Eであるとされています。
数年前には「捨てる技術」という本が流行りました。捨てることの価値は、誰もが認めるところですね。

と、こんな記事を書きながら、私の机は「いつか使うかも」と取っておいた書類が山を成し、作業スペースを圧迫しかけています。
本当に、捨てるのは難しいことだと実感します...

9月になりましたが、まだまだ暑いですね。
1箇月間ぶりのエントリとなりますが、
スカイアーチのISO20000の取り組みも、相変わらずアツイです！

先月より、新しい取り組みが始まりました。
「業務改善提案制度」
なんともISO企業らしい取り組みです！

この取組みの背景の取り組みは、「ITIL資格の奨励」。
全社でITIL Foundation資格の取得を奨励しているのは、先日お話したとおりです。
取り組みも半年を数え、先々月には既に取得者が10名（全社員の2割）を超えました。

エンジニアやセールス、事務局だけでなく、最近では、経理部門のマネージャーも取得！
社内の各所で、ITIL用語が聞こえ、全社の共通言語になりつつあります。
取り組みを継続すると、組織は変わるものですね。

「せっかく勉強したんだから、アウトプットの場も」
と社長の一声で、この制度が始まりました。

業務改善提案制度の仕組みはシンプル。
1.社員に業務改善の提案を広く募集。
　社員はエクセルの様式に提案を記入します。
2.月末に提出を締切り、役員会で評価・採否を検討。
3.月末の月次報告会で全社員に、すべての業務改善提案の概要と公表。
4.優秀者には、賞金！（お小遣い）

先日8月31日には、第1回目の発表がありました。
提出者は2名。1人は営業担当の方。身近なことが「すぐにできる」と高評価。すぐにできる小さな改善こそ、業務改善の要諦ですね。
もう1名は、情シスリーダの方。4件もの提案を提出。さすが、情シス。社内に目が光っています。

先月は2名。要領を学び、また来月は提出が増えることでしょう。楽しみですね。

提案制度というと、コンテストのようで、ちょっと敷居が高く思えますが、
案を量産するためのフレームワークが、世の中にはたくさん存在します。
改善案に特化したフレームワークというのもあるのです。
社員の方は、これで改善案を量産して、がっちりお小遣いを稼ぎましょう！

と、ここまで引っ張りつつ、長くなりましたので、
具体的なフレームワークは、また明日ご案内します。

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に更新します）