2011年07月04日
拡大審査vs.縮小審査vs.移転審査
話を聴いていると定義が今一つはっきりしない。住所先が増えたり減ったりしたらそれは拡大または縮小。所在が単純にAからBへ移れば移転。部門が分散したり統合したりと組織再編が絡むと少し分かり難い。移転といえども新しい環境でのリスク対応を要求されるのは当然。
審査の前に何を確認するのですか？
情報資産の拡大縮小の有無
組織（部署・人数）の拡大縮小の有無
ロケーションのセキュリティ境界の拡大縮小の有無
住所先（サイト数）の拡大縮小の有無
ネットワーク環境の変更の有無
変更があったら特別審査をやるかどうかを決める必要があります。その変化によるリスクの可能性に対しても組織は適切に対応できていることを確認する。面倒だけど理屈の上ではそうなる。というより積極的に変化点を理解しリスク対応を済ませて安心するのが本来でしょう。
.*.
ところで、
変化があるときには、移動（引越し）が伴うケースがある。企業は引越しについては結構神経質になる。途中で物が無くなることが懸念されるからだ。もう一つはスペースが十分確保できない場合は資産の処分・外部倉庫利用などが余儀なくされる。引越しは回数も少なく手順が確立されていないから、どの企業も一本勝負的になりがちだ。
セキュリティリスクの大きいこの一連のイベントに対して、不思議なことに、事前または事後の審査でリスク対応の妥当性をチェックされることは殆ど無い。理由は？ 彼らは経験も無く殆ど知見を持ち合わせていないことと、規格を読み解く力が無いこと。知見は引越し業者に蓄積されている。規格上は予防処置、あるいは事業継続管理の一環としての取り組みが妥当らしい。もちろん、トラブルが発生してしまえば他の側面からのリスク対応も要求される。
既存情報資産の引越しの有無
引越しを見る審査はあまり例を見ないが、引越しマネジメントを見るコンサルあるいは審査があってもいい。トラブルの宝庫が引越しなんだから。
.*.
話を聴いていると定義が今一つはっきりしない。住所先が増えたり減ったりしたらそれは拡大または縮小。所在が単純にAからBへ移れば移転。部門が分散したり統合したりと組織再編が絡むと少し分かり難い。移転といえども新しい環境でのリスク対応を要求されるのは当然。
審査の前に何を確認するのですか？
情報資産の拡大縮小の有無
組織（部署・人数）の拡大縮小の有無
ロケーションのセキュリティ境界の拡大縮小の有無
住所先（サイト数）の拡大縮小の有無
ネットワーク環境の変更の有無
変更があったら特別審査をやるかどうかを決める必要があります。その変化によるリスクの可能性に対しても組織は適切に対応できていることを確認する。面倒だけど理屈の上ではそうなる。というより積極的に変化点を理解しリスク対応を済ませて安心するのが本来でしょう。
.*.
ところで、
変化があるときには、移動（引越し）が伴うケースがある。企業は引越しについては結構神経質になる。途中で物が無くなることが懸念されるからだ。もう一つはスペースが十分確保できない場合は資産の処分・外部倉庫利用などが余儀なくされる。引越しは回数も少なく手順が確立されていないから、どの企業も一本勝負的になりがちだ。
セキュリティリスクの大きいこの一連のイベントに対して、不思議なことに、事前または事後の審査でリスク対応の妥当性をチェックされることは殆ど無い。理由は？ 彼らは経験も無く殆ど知見を持ち合わせていないことと、規格を読み解く力が無いこと。知見は引越し業者に蓄積されている。規格上は予防処置、あるいは事業継続管理の一環としての取り組みが妥当らしい。もちろん、トラブルが発生してしまえば他の側面からのリスク対応も要求される。
既存情報資産の引越しの有無
引越しを見る審査はあまり例を見ないが、引越しマネジメントを見るコンサルあるいは審査があってもいい。トラブルの宝庫が引越しなんだから。
.*.
こんな不適合は困る？
何が問題なのかはっきりしない不適合。こちらも気が弱いから黙って受け入れたけど、結局どうすれば是正というか再発防止になるのか分からない。審査員は解決のための方法論は言わなくていいのは建前で、実際の解法についてんおイメージが何もないのでは困る。杓子定規を絵に描いたケース。知識経験の乏しい審査員は困る。
どのルールに違反しているのかがやはりはっきりしないときも困る。審査員の経験に照らしての不適合も困る。品質管理の常識を当てはめてくれても困る。
コンサルだって問題がはっきりすれば解けるけど何が指摘のポイントか分からないときはコンサルしようがない。
もうひとつ困るのは、枝葉末節をついた不適合。不適合出してみましたというだけで、実際のリスクはあまり考えられないところで「はい！ルール違反ね」とやるのもどうかと思う。まるで、嘱託になった定年組み警官が、人通りも信号もない道路でネズミ捕りをしているようなもの。交通事故の多いところでねずみ捕るするなら効果も出るだろうが、問題のなさそうなところでアルバイト代わりに切符を切る姿に似ている。
.*.
何が問題なのかはっきりしない不適合。こちらも気が弱いから黙って受け入れたけど、結局どうすれば是正というか再発防止になるのか分からない。審査員は解決のための方法論は言わなくていいのは建前で、実際の解法についてんおイメージが何もないのでは困る。杓子定規を絵に描いたケース。知識経験の乏しい審査員は困る。
どのルールに違反しているのかがやはりはっきりしないときも困る。審査員の経験に照らしての不適合も困る。品質管理の常識を当てはめてくれても困る。
コンサルだって問題がはっきりすれば解けるけど何が指摘のポイントか分からないときはコンサルしようがない。
もうひとつ困るのは、枝葉末節をついた不適合。不適合出してみましたというだけで、実際のリスクはあまり考えられないところで「はい！ルール違反ね」とやるのもどうかと思う。まるで、嘱託になった定年組み警官が、人通りも信号もない道路でネズミ捕りをしているようなもの。交通事故の多いところでねずみ捕るするなら効果も出るだろうが、問題のなさそうなところでアルバイト代わりに切符を切る姿に似ている。
.*.
不適合を受けた時の是正処置計画のレビュー
これはもうさまざま。今まで何をやっていたのかわからないくらい残念なものもあるようだ。再発防止を確実にする観点での計画なのだけど、問題の本質追及をやらないでいきなり思いついた対策を書き始めるから始末が悪い。十分考えたつもりでも方向がずれるケースがある。普通は、はっきり言ってコンサル任せ。コンサルとしてはお手本を書いてあげるようなつもりで応じるしかない。
ここ（是正処置）がいい加減な会社は、内部監査（の是正処置）やインシデント対応（の是正処置）だっていい加減なことが予想される。大いに心配な組織と言う事らしい。まだ一人歩きできていないのに、ばっさりコンサルは切られてしまう。
もっとも、コンサルもビジネス。中途半端にコンサル契約を継続されて人が動かせなくなる方が困るときもあるから、さっさと契約を打ち切りたいという本音がちらちら見えたりして、クライアントばかりを責める訳にも行かない。
.*.
是正処置計画は担当した審査員も見るわけだが、彼らもレベルがある。不運が重なれば、組織の現場は意味のない作業を１年間やらされることになる。認証書の期限が迫っている中では、さらに不運が重なることになる。
不適合は継続審査で出して、更新審査は観察どまりで済ませる。そういう構えの輩（審査員）も中には居るらしい。正しくありませんが、周囲は割と納得してくれるそうです。継続は厳しく、更新は温かく。
.*.
これはもうさまざま。今まで何をやっていたのかわからないくらい残念なものもあるようだ。再発防止を確実にする観点での計画なのだけど、問題の本質追及をやらないでいきなり思いついた対策を書き始めるから始末が悪い。十分考えたつもりでも方向がずれるケースがある。普通は、はっきり言ってコンサル任せ。コンサルとしてはお手本を書いてあげるようなつもりで応じるしかない。
ここ（是正処置）がいい加減な会社は、内部監査（の是正処置）やインシデント対応（の是正処置）だっていい加減なことが予想される。大いに心配な組織と言う事らしい。まだ一人歩きできていないのに、ばっさりコンサルは切られてしまう。
もっとも、コンサルもビジネス。中途半端にコンサル契約を継続されて人が動かせなくなる方が困るときもあるから、さっさと契約を打ち切りたいという本音がちらちら見えたりして、クライアントばかりを責める訳にも行かない。
.*.
是正処置計画は担当した審査員も見るわけだが、彼らもレベルがある。不運が重なれば、組織の現場は意味のない作業を１年間やらされることになる。認証書の期限が迫っている中では、さらに不運が重なることになる。
不適合は継続審査で出して、更新審査は観察どまりで済ませる。そういう構えの輩（審査員）も中には居るらしい。正しくありませんが、周囲は割と納得してくれるそうです。継続は厳しく、更新は温かく。
.*.
観察事項の是正は必要か？
不適合は是正が必要なのは当然として、観察事項の是正はどうするんでしょうか？
この単純な問いかけに対する答えが実にさまざまなのは驚く。「必ず是正を要求する」〜「まったく関与しない」まで１８０度違うくらいの違いがある。コンサルとしては非常に困る。審査機関によって違うだけならまだいいが審査員によって言うことが違うからだ。沿う入っても、実は、答えは単純。このまま放置すれば将来的に不適合になりかねないものが観察事項だから放置してはいけないのが常識。
勿論、指摘を額面どおりに受け取るのは問題がないわけでもないから、と言うのは審査員はその業務のプロでもなんでもないから、指摘の本質を見て手を打つのも常識。
.*.
前年の観察事項への対応について、まったくフォローしない審査員がときに居るがあれは許せない。それでは、言いっぱなしで後は勝手にすれば、私は関心ありませんと同じで非常にクライアントのやる気を阻害する結果になる。
不適合は是正が必要なのは当然として、観察事項の是正はどうするんでしょうか？
この単純な問いかけに対する答えが実にさまざまなのは驚く。「必ず是正を要求する」〜「まったく関与しない」まで１８０度違うくらいの違いがある。コンサルとしては非常に困る。審査機関によって違うだけならまだいいが審査員によって言うことが違うからだ。沿う入っても、実は、答えは単純。このまま放置すれば将来的に不適合になりかねないものが観察事項だから放置してはいけないのが常識。
勿論、指摘を額面どおりに受け取るのは問題がないわけでもないから、と言うのは審査員はその業務のプロでもなんでもないから、指摘の本質を見て手を打つのも常識。
.*.
前年の観察事項への対応について、まったくフォローしない審査員がときに居るがあれは許せない。それでは、言いっぱなしで後は勝手にすれば、私は関心ありませんと同じで非常にクライアントのやる気を阻害する結果になる。
見積工数vs.実績工数
審査工数の見積もりは推定に基づいて実施する。審査現場は現実に基づく。推定したものに現場の現実を無視して従うのは本末転倒だ。
もっとも、審査員の力量（？）、応対した組織の担当者、準備したコンサルの周到さによって、時間は余ったり足りなかったりするから、現場の実績と言いつつも必ずしも確定的ではない。
大事なことは、事実が営業にも周知されて、より適切な次回の見積もりに反映させること。らしい。そういう仕組みは、どんな企業でも必要なことだが、１回限りのケースもあって、仕組みにまで作りこむのは少ないらしい。
.*.
見積もり工数は営業が意図的に、あるいはうっかりとご都合の工数を算出する可能性がある。もしくは古いデータを前提とした見積もりである可能性がある。だから担当する審査員は、（１）最新の人数・サイト数を確認し、（２）改めて適切な工数を算出する。（３）もし、営業見積もりとギャップがあれば調整を行い、（４）改めてクライアントと新たな審査工数について合意を得る。
.*.
審査工数の見積もりは推定に基づいて実施する。審査現場は現実に基づく。推定したものに現場の現実を無視して従うのは本末転倒だ。
もっとも、審査員の力量（？）、応対した組織の担当者、準備したコンサルの周到さによって、時間は余ったり足りなかったりするから、現場の実績と言いつつも必ずしも確定的ではない。
大事なことは、事実が営業にも周知されて、より適切な次回の見積もりに反映させること。らしい。そういう仕組みは、どんな企業でも必要なことだが、１回限りのケースもあって、仕組みにまで作りこむのは少ないらしい。
.*.
見積もり工数は営業が意図的に、あるいはうっかりとご都合の工数を算出する可能性がある。もしくは古いデータを前提とした見積もりである可能性がある。だから担当する審査員は、（１）最新の人数・サイト数を確認し、（２）改めて適切な工数を算出する。（３）もし、営業見積もりとギャップがあれば調整を行い、（４）改めてクライアントと新たな審査工数について合意を得る。
.*.
システムの運用監視などは、その時間の量がサービスの中身だから、チェックを全部済ませたので帰りますとはなかなか行かない。1日張り付いていて監視していたことになる。現地待機。アラートを自宅で受け取っても構わないケースもあるだろうに。
コンサルの場合は、成果物主義で通る部分と、工数提供がサービスとなる部分の２面性がある。高額なコンサル費用がかかるのは概ね前者、経験の乏しいところは後者の傾向がある。
.*.
審査工数はどちら？
チェックリストを予定分終了したらさっさと帰る審査員と、プログラム通りの時間いっぱい審査を続ける審査員と両方居る。中には時間をオーバーして審査する人も居る。さっさと返る審査を認定機関（JAB?)が認めているかどうかはしらない。
審査のためのチェック項目数を例えば１０件として１時間かかると計画する。１０件終了するまで審査する。成果物は１０件の結果。分かりやすい。
一方、審査のために１時間使うとして、チェック件数が５件でも１時間で終了する。チェック件数が３０分で完了しても残り３０分エクストラのチェックを続ける。どうしてそんなに時間にこだわるの。か分かりにくい。
1件の中身、深さが問題なのかな。
組織の人数が何人の時は審査工数は何人日と設定したガイドラインがある。少なくとも計画はこのガイドラインをベースにする。その工数の中でチェックリストが準備され実施されれば構わない。
.*.
時間にこだわるところでは、時間が多すぎて気まずいお見合いみたいな審査を延々続けるところがある。杓子定規。形式主義的で中身にはあまり期待できない。（中身が無いから形式にこだわるのかも）
便宜的な工数ガイドに従えば、実態と会わないことはいくらでも出てくるのは当然。
.*.
＃何か分かり難いね。
工数のガイドラインの大本が超アバウトなのに、一旦数字が決まると、1分1秒に拘る人が出てくることに、不自然さを感じる。といえばわかりやすいかな。算数に弱い文科系の人間は、こういう馬鹿な拘りをしやすい。口先だけの文科系人間が多くなるとこういうことも分らなくなる。のかな？
.*.
コンサルの場合は、成果物主義で通る部分と、工数提供がサービスとなる部分の２面性がある。高額なコンサル費用がかかるのは概ね前者、経験の乏しいところは後者の傾向がある。
.*.
審査工数はどちら？
チェックリストを予定分終了したらさっさと帰る審査員と、プログラム通りの時間いっぱい審査を続ける審査員と両方居る。中には時間をオーバーして審査する人も居る。さっさと返る審査を認定機関（JAB?)が認めているかどうかはしらない。
審査のためのチェック項目数を例えば１０件として１時間かかると計画する。１０件終了するまで審査する。成果物は１０件の結果。分かりやすい。
一方、審査のために１時間使うとして、チェック件数が５件でも１時間で終了する。チェック件数が３０分で完了しても残り３０分エクストラのチェックを続ける。どうしてそんなに時間にこだわるの。か分かりにくい。
1件の中身、深さが問題なのかな。
組織の人数が何人の時は審査工数は何人日と設定したガイドラインがある。少なくとも計画はこのガイドラインをベースにする。その工数の中でチェックリストが準備され実施されれば構わない。
.*.
時間にこだわるところでは、時間が多すぎて気まずいお見合いみたいな審査を延々続けるところがある。杓子定規。形式主義的で中身にはあまり期待できない。（中身が無いから形式にこだわるのかも）
便宜的な工数ガイドに従えば、実態と会わないことはいくらでも出てくるのは当然。
.*.
＃何か分かり難いね。
工数のガイドラインの大本が超アバウトなのに、一旦数字が決まると、1分1秒に拘る人が出てくることに、不自然さを感じる。といえばわかりやすいかな。算数に弱い文科系の人間は、こういう馬鹿な拘りをしやすい。口先だけの文科系人間が多くなるとこういうことも分らなくなる。のかな？
.*.
審査工数が抱える矛盾性？
コンサルファームも、審査機関も、ソフトウエア開発業者も、建設業者も、殆ど全て、多くのビジネスで、工数の妥当性は常に問題になる。
さて、見積もり工数と実績工数に乖離があっても構わないビジネスと、乖離が認められないビジネスと、何が違うのだろう。
努力して工数を減らしたのだから、その利益還元は自分が受け取る。逆に工数が増えてしまった場合のリスクも自分が取る。
システムの運用監視などは、その時間がサービスの中身だから、チェックを全部済ませたので帰りますとはなかなか行かない。
コンサルの場合は、成果物主義で通る部分と、工数提供がサービスとなる部分の２面性がある。高額なコンサル費用がかかるのは概ね前者、経験の乏しいところは後者の傾向がある。
.*.
審査工数はどちら？
チェックリストを予定分終了したらさっさと帰る審査員と、プログラム通りの時間いっぱい審査を続ける審査員と両方居る。中には時間をオーバーして審査する人も居る。
審査のためのチェック項目数を例えば１０件として１時間かかると計画する。１０件終了するまで審査する。成果物は１０件の結果。分かりやすい。
一方、審査のために１時間使うとして、チェック件数が５件でも１時間で終了する。チェック件数が３０分で完了しても残り３０分エクストラのチェックを続ける。どうしてそんなに時間にこだわるの。か分かりにくい。
組織の人数が何人の時は審査工数は何人日と設定したガイドラインがある。少なくとも計画はこのガイドラインをベースにする。その工数の中でチェックリストが準備され実施されれば構わない。
.*.
時間にこだわるところでは、時間が多すぎて気まずいお見合いみたいな審査を遠遠続けるところがある。杓子定規。形式主義的で中身にはあまり期待できない。（中身が無いから形式にこだわるのかも）
便宜的な工数ガイドに従えば、実態と会わないことはいくらでも出てくるのは当然。
コンサルファームも、審査機関も、ソフトウエア開発業者も、建設業者も、殆ど全て、多くのビジネスで、工数の妥当性は常に問題になる。
さて、見積もり工数と実績工数に乖離があっても構わないビジネスと、乖離が認められないビジネスと、何が違うのだろう。
努力して工数を減らしたのだから、その利益還元は自分が受け取る。逆に工数が増えてしまった場合のリスクも自分が取る。
システムの運用監視などは、その時間がサービスの中身だから、チェックを全部済ませたので帰りますとはなかなか行かない。
コンサルの場合は、成果物主義で通る部分と、工数提供がサービスとなる部分の２面性がある。高額なコンサル費用がかかるのは概ね前者、経験の乏しいところは後者の傾向がある。
.*.
審査工数はどちら？
チェックリストを予定分終了したらさっさと帰る審査員と、プログラム通りの時間いっぱい審査を続ける審査員と両方居る。中には時間をオーバーして審査する人も居る。
審査のためのチェック項目数を例えば１０件として１時間かかると計画する。１０件終了するまで審査する。成果物は１０件の結果。分かりやすい。
一方、審査のために１時間使うとして、チェック件数が５件でも１時間で終了する。チェック件数が３０分で完了しても残り３０分エクストラのチェックを続ける。どうしてそんなに時間にこだわるの。か分かりにくい。
組織の人数が何人の時は審査工数は何人日と設定したガイドラインがある。少なくとも計画はこのガイドラインをベースにする。その工数の中でチェックリストが準備され実施されれば構わない。
.*.
時間にこだわるところでは、時間が多すぎて気まずいお見合いみたいな審査を遠遠続けるところがある。杓子定規。形式主義的で中身にはあまり期待できない。（中身が無いから形式にこだわるのかも）
便宜的な工数ガイドに従えば、実態と会わないことはいくらでも出てくるのは当然。
牛乳瓶を片手で持って腰に手を当てて飲む
正しい風呂上りの牛乳の飲み方。風呂屋の隣では、風呂屋がつぶれても正しい飲み方がまかり通っている。オスもメスもオイもワカキもなくである。
昔は口の欠けた牛乳瓶が結構あった。使いまわしの程度もあるし、検査の能力もあるし、コストもあるし、世間も厳しくなかった。今は、口の欠けた牛乳瓶は探しても見つからない。
普通の白い牛乳
茶色のコーヒー牛乳。ミルクコーヒー牛乳ということもある。
黄色ピンクのフルーツ牛乳
最近はヨーグルト牛乳もある。
瓶に収まるだけで、紙パックとはものが違うと言わんばかりに、堂々と冷蔵棚に収まる。牛乳瓶はえらいのだ。
.*.
正しい風呂上りの牛乳の飲み方。風呂屋の隣では、風呂屋がつぶれても正しい飲み方がまかり通っている。オスもメスもオイもワカキもなくである。
昔は口の欠けた牛乳瓶が結構あった。使いまわしの程度もあるし、検査の能力もあるし、コストもあるし、世間も厳しくなかった。今は、口の欠けた牛乳瓶は探しても見つからない。
普通の白い牛乳
茶色のコーヒー牛乳。ミルクコーヒー牛乳ということもある。
黄色ピンクのフルーツ牛乳
最近はヨーグルト牛乳もある。
瓶に収まるだけで、紙パックとはものが違うと言わんばかりに、堂々と冷蔵棚に収まる。牛乳瓶はえらいのだ。
.*.
2011年07月03日
内部監査が審査までに終わらない場合？
あれ程しつこく言って置いたのに内部監査が終わらない。１０部門のうち半分ならOKなのかOUTなのか。なんて議論自体がNGみたいだ。内部監査が終わっているとは結果が経営者に報告されていることだから。報告の場はマネジメントレビューだから、下手するとマネジメントレビューも終わっていないことになる。
内部監査が終わっていなければ重大な不適合が本来の形。本来の形と言うのは、審査員や審査機関によっては、一部でも着手しているだけOKにするケースがある。観察事項で済ませてしまう。冷や汗をかいていたコンサルが胸をなでおろす瞬間と言うやつだとか。
内部監査も終わっていないのにマネジメントレビューを開催して、中途半端な指示を出す経営者の存在も重大な不適合に近い。
.*.
初回審査の場合は内部監査未了は少ない。コンサルがしっかり入っているから、未了は許さない。
継続審査、更新審査となると、コンサルは契約が切れて面倒は見なくなるから、時々未了が発生する。そのときの審査員の態度が見ものらしい。気の弱い審査員、面倒くさがる審査員は、所謂、観察事項で済ましてくれるらしい。そうなるともう駄目だね。いけないね。二度と完了した内部監査を見ることは出来なくなる。
.*.
拡大審査の場合はどうなるでしょう？
拡大サイト単独の拡大審査、継続審査とか更新審査に合わせてサイト拡大を行う拡大審査と両方ある。拡大する部門・サイトの内部監査が終わっていなかったら？どうなるでしょう？
重大な不適合で拡大は認められない。
場馴れして、コンサルも断って、独自運用はいいけど、慣れると油断が出る。
審査する側にも慣れの問題が出ているようだ。誰かが一度でもOKすると次に行った審査員がまともなことを言ってもクレームの対象になる。審査員は前任者の問題と気づかずにコンサルを問題にする。
俄かに風呂屋の隣が少し盛り上がる。
.*.
あれ程しつこく言って置いたのに内部監査が終わらない。１０部門のうち半分ならOKなのかOUTなのか。なんて議論自体がNGみたいだ。内部監査が終わっているとは結果が経営者に報告されていることだから。報告の場はマネジメントレビューだから、下手するとマネジメントレビューも終わっていないことになる。
内部監査が終わっていなければ重大な不適合が本来の形。本来の形と言うのは、審査員や審査機関によっては、一部でも着手しているだけOKにするケースがある。観察事項で済ませてしまう。冷や汗をかいていたコンサルが胸をなでおろす瞬間と言うやつだとか。
内部監査も終わっていないのにマネジメントレビューを開催して、中途半端な指示を出す経営者の存在も重大な不適合に近い。
.*.
初回審査の場合は内部監査未了は少ない。コンサルがしっかり入っているから、未了は許さない。
継続審査、更新審査となると、コンサルは契約が切れて面倒は見なくなるから、時々未了が発生する。そのときの審査員の態度が見ものらしい。気の弱い審査員、面倒くさがる審査員は、所謂、観察事項で済ましてくれるらしい。そうなるともう駄目だね。いけないね。二度と完了した内部監査を見ることは出来なくなる。
.*.
拡大審査の場合はどうなるでしょう？
拡大サイト単独の拡大審査、継続審査とか更新審査に合わせてサイト拡大を行う拡大審査と両方ある。拡大する部門・サイトの内部監査が終わっていなかったら？どうなるでしょう？
重大な不適合で拡大は認められない。
場馴れして、コンサルも断って、独自運用はいいけど、慣れると油断が出る。
審査する側にも慣れの問題が出ているようだ。誰かが一度でもOKすると次に行った審査員がまともなことを言ってもクレームの対象になる。審査員は前任者の問題と気づかずにコンサルを問題にする。
俄かに風呂屋の隣が少し盛り上がる。
.*.
Control Objectives for Information and related Technology
コビットの話題は以前ほどには出てこない。２０００年前後に盛んに議論されて今はもう落ち着いてしまった印象で、IT管理の枠組み・方法論の理解には役立つが、それ以上でないことが話題性を維持できない理由かもしれない。話題にないことと活用されていないこととはまったく別であることも理解しておかなければいけないようだ。
大手企業のIT管理部門あるいは経営管理部門にいてCOBITの話題についていけないこともないだろうから、コンサルとしても基本的な理解はしておかなければいけない。らしい。でもその類は他にもいろいろあって大変なようだ。日本版SOX法（JSOX法）なども。コンサルは知らないでは済まされない厳しい職業なのだ。
その点、審査員はもう少しスパンを狭くして良いらしい。余計な話は、返ってコンサル行為になって拙いらしい。
コビットの話題は以前ほどには出てこない。２０００年前後に盛んに議論されて今はもう落ち着いてしまった印象で、IT管理の枠組み・方法論の理解には役立つが、それ以上でないことが話題性を維持できない理由かもしれない。話題にないことと活用されていないこととはまったく別であることも理解しておかなければいけないようだ。
大手企業のIT管理部門あるいは経営管理部門にいてCOBITの話題についていけないこともないだろうから、コンサルとしても基本的な理解はしておかなければいけない。らしい。でもその類は他にもいろいろあって大変なようだ。日本版SOX法（JSOX法）なども。コンサルは知らないでは済まされない厳しい職業なのだ。
その点、審査員はもう少しスパンを狭くして良いらしい。余計な話は、返ってコンサル行為になって拙いらしい。
ジョブ・アサイン・コード（ジョブ・アサイン・ナンバー）は作業番号、いわゆる作番のこと.。顧客（クライアント）名、クライアント番号のほかに大企業の場合は部署名・部署コードも設定される。場所が重要な案件だと場所名も管理される。受注案件（契約案件）名、受注番号（契約番号）が決まって、工数が確定し、作業チームがアサインされ、作業番号が振られる。
細かいことは分からないが、コンサル牛乳瓶も審査牛乳瓶も役務サービスの提供であるため、大枠は似ている。ただ、コンサルは構築フェーズが主戦場で、文書化、教育、運用指導が中心になるが、審査は審査行為自体が成果物になっているので、審査の管理は少し厳密に見ているような印象がある。
コンサルタントと審査員は審査の場で火花を散らす。と言っても敵味方の関係ではないようだ。
ジョブアサイン番号はどの審査員がどの日程でどの場所のどの部門を審査するかを決めたものだが、コンサルタントにとってはこれが非常に重要になる。極端な話、それが分かれば一夜漬けをしてでもそのジョブアサインが入った部署に行って再教育することもある。
ジョブアサイン番号はシステム開発プロジェクトで設定されるものと同じように採算も見ることが出来るように管理されるが、費用規模も小さくそれほど厳密に管理されることはない。
.*.
問題はサービスサイトのジョブアサインらしい。やって出来ないことはないが他者の住所であることや、一過性のサイトのため、管理のスキームに上手く収まらないし、データベースへの登録も上手く行かないようだ。
.*.
細かいことは分からないが、コンサル牛乳瓶も審査牛乳瓶も役務サービスの提供であるため、大枠は似ている。ただ、コンサルは構築フェーズが主戦場で、文書化、教育、運用指導が中心になるが、審査は審査行為自体が成果物になっているので、審査の管理は少し厳密に見ているような印象がある。
コンサルタントと審査員は審査の場で火花を散らす。と言っても敵味方の関係ではないようだ。
ジョブアサイン番号はどの審査員がどの日程でどの場所のどの部門を審査するかを決めたものだが、コンサルタントにとってはこれが非常に重要になる。極端な話、それが分かれば一夜漬けをしてでもそのジョブアサインが入った部署に行って再教育することもある。
ジョブアサイン番号はシステム開発プロジェクトで設定されるものと同じように採算も見ることが出来るように管理されるが、費用規模も小さくそれほど厳密に管理されることはない。
.*.
問題はサービスサイトのジョブアサインらしい。やって出来ないことはないが他者の住所であることや、一過性のサイトのため、管理のスキームに上手く収まらないし、データベースへの登録も上手く行かないようだ。
.*.
データセンターはサービスサイトか？
組織が管理するサイトは通常のサイト。
他者が管理するエリアに情報資産と管理プロセスが存在すれば、そこはサービスサイト、と言うわけではない。ただの業務委託が含まれてしまう。情報資産の管理業務を委託する場合はサービスサイトとは言わない。
他者の管理環境の一部を借りて、組織の管理下の従業員が情報資産の管理をする場合、借りる期間は、定めがなくても定めがあってもかまわない。
データセンターはサーバーシステムの管理を委託しているので、当社の従業員がもっぱら情報資産の管理を担当しないので、サービスサイトとは言わない。
本当？
.*.
組織が管理するサイトは通常のサイト。
他者が管理するエリアに情報資産と管理プロセスが存在すれば、そこはサービスサイト、と言うわけではない。ただの業務委託が含まれてしまう。情報資産の管理業務を委託する場合はサービスサイトとは言わない。
他者の管理環境の一部を借りて、組織の管理下の従業員が情報資産の管理をする場合、借りる期間は、定めがなくても定めがあってもかまわない。
データセンターはサーバーシステムの管理を委託しているので、当社の従業員がもっぱら情報資産の管理を担当しないので、サービスサイトとは言わない。
本当？
.*.
2011年07月02日
牛乳瓶の会話によればサービスサイトという言葉が出てくる。
コンサルを泣かすサービスサイト？。定義がはっきりしない。認可サイト、アプルーブドサイト（Approved Sites）。いくつかのイメージがある。よく引き合いに出されるのは、建設現場に一時的に設定される事務所などで、建設が終われば閉鎖。物品の受け入れあるいは出荷前の品質検査のために、一時的に試用される作業所で、物の移動がある時期だけオープンし少なくなったらクローズを繰り返す。空いている時は他の目的で他の部署が利用。
客先にコピーサービスなどの部隊として常駐。ミニマムの施設管理・情報管理で、全体の管理標準は客先に従う。清掃班も施設規模が大きい場合は常駐形態になる。
ソフトウエア開発を客先に常駐して請け負う場合も、サービスサイトの扱いになる。（派遣は特定のエリアの管理委任が無いのでサービスサイトとは呼ばない）
携帯電話の販売店もある一角を借りて営業しているので、サービスサイトに含めて良さそうだ。
.*.
コンサルを泣かすサービスサイト？。定義がはっきりしない。認可サイト、アプルーブドサイト（Approved Sites）。いくつかのイメージがある。よく引き合いに出されるのは、建設現場に一時的に設定される事務所などで、建設が終われば閉鎖。物品の受け入れあるいは出荷前の品質検査のために、一時的に試用される作業所で、物の移動がある時期だけオープンし少なくなったらクローズを繰り返す。空いている時は他の目的で他の部署が利用。
客先にコピーサービスなどの部隊として常駐。ミニマムの施設管理・情報管理で、全体の管理標準は客先に従う。清掃班も施設規模が大きい場合は常駐形態になる。
ソフトウエア開発を客先に常駐して請け負う場合も、サービスサイトの扱いになる。（派遣は特定のエリアの管理委任が無いのでサービスサイトとは呼ばない）
携帯電話の販売店もある一角を借りて営業しているので、サービスサイトに含めて良さそうだ。
.*.
特別拡大審査〜スーパー拡大審査
拡大テンコ盛りはよくある話。最初は情報システム部など特定の1部門で認証を取得し、1年後に拡大で全社の認証取得を図る。最初は、ＩＳＯとはＩＳＭＳとは何かを理解するため、あるいはコンサル会社と審査機関の相性を探るために、プローブ的な認証取得をはかり、特に問題が無ければ一気に全社の展開する。
この時にクライアントはこれが実質的な初回審査だから、初回審査に準じた手順を踏もうとするケースが普通。ところが、中には勘違いしたクライアントと営業の暴走で、杓子定規に只の拡大審査として日程を組むことがある。
時として不幸な事態を招く。
何処のファームも営業とライン部隊は仲がわるいものだ。こういう大きな勘違いも早めに気づけば事なきを得るが、予算とか日程とか、外堀内堀が埋まった後では変更が難しくなる。全員がアンハッピーになってしまう。
何がアンハッピーなの？
拡大審査の工数は初回審査工数より小さい。システムの構築（主に文書審査）は既に終わっていて、現場部署の実施状況の確認だけということが少ない工数でよしとする理由。
新たに500人が追加になった場合、初回審査なら仮に６人日の工数が必要でも、拡大フェーズの場合は4人日で済ますことが出来るというもの。手順を少し変えるだけで、全体としては大きな工数削減が可能になる。この場合は、初回審査を2/3の工数でやることになり、審査の質を落としてしまう。
出費を抑えることができて、誰か喜ぶ人もいるだろうが、本末転倒でしょう。
「拡大審査とする場合は既存の範囲（人数）を超えない範囲に限定する。既存組織範囲を超える場合は特別拡大などとして、工数的には拡大部分には初回の工数を充てるようにするのが、妥当ではないだろうか。
.*.
拡大テンコ盛りはよくある話。最初は情報システム部など特定の1部門で認証を取得し、1年後に拡大で全社の認証取得を図る。最初は、ＩＳＯとはＩＳＭＳとは何かを理解するため、あるいはコンサル会社と審査機関の相性を探るために、プローブ的な認証取得をはかり、特に問題が無ければ一気に全社の展開する。
この時にクライアントはこれが実質的な初回審査だから、初回審査に準じた手順を踏もうとするケースが普通。ところが、中には勘違いしたクライアントと営業の暴走で、杓子定規に只の拡大審査として日程を組むことがある。
時として不幸な事態を招く。
何処のファームも営業とライン部隊は仲がわるいものだ。こういう大きな勘違いも早めに気づけば事なきを得るが、予算とか日程とか、外堀内堀が埋まった後では変更が難しくなる。全員がアンハッピーになってしまう。
何がアンハッピーなの？
拡大審査の工数は初回審査工数より小さい。システムの構築（主に文書審査）は既に終わっていて、現場部署の実施状況の確認だけということが少ない工数でよしとする理由。
新たに500人が追加になった場合、初回審査なら仮に６人日の工数が必要でも、拡大フェーズの場合は4人日で済ますことが出来るというもの。手順を少し変えるだけで、全体としては大きな工数削減が可能になる。この場合は、初回審査を2/3の工数でやることになり、審査の質を落としてしまう。
出費を抑えることができて、誰か喜ぶ人もいるだろうが、本末転倒でしょう。
「拡大審査とする場合は既存の範囲（人数）を超えない範囲に限定する。既存組織範囲を超える場合は特別拡大などとして、工数的には拡大部分には初回の工数を充てるようにするのが、妥当ではないだろうか。
.*.
派遣-請負-委任-支援
偽装請負というのが話題になった。実施は派遣なのに請負の看板で仕事をさせる。派遣法に違反。責任所在が曖昧。支払い対価が不明確。
技術者に対する特定派遣はルールが少し変わるらしい。
業務委託などと一般に言われるものは、意味合いとしては請負。派遣員にやらせる場合は業務は自分の管理下にあり外に委託していない。
正しい請負は自分の責任で管理遂行できる。ＰＤＣＡが回るから適用範囲。
支援という言葉を使うケースもある。支援は主体で無いという意味で業務内容についての管理責任は負わない。派遣と同様に、人を提供した組織としての人に対する管理業務が残るだけだ。
.*.
偽装請負というのが話題になった。実施は派遣なのに請負の看板で仕事をさせる。派遣法に違反。責任所在が曖昧。支払い対価が不明確。
技術者に対する特定派遣はルールが少し変わるらしい。
業務委託などと一般に言われるものは、意味合いとしては請負。派遣員にやらせる場合は業務は自分の管理下にあり外に委託していない。
正しい請負は自分の責任で管理遂行できる。ＰＤＣＡが回るから適用範囲。
支援という言葉を使うケースもある。支援は主体で無いという意味で業務内容についての管理責任は負わない。派遣と同様に、人を提供した組織としての人に対する管理業務が残るだけだ。
.*.
派遣先業務を適用範囲とすることは、ＱＭＳではＮＧらしい。そのことはＱＭＳのコンサルタントには徹底している。
ＩＳＭＳでは解釈が割れているらしい。しかし、割れていること自体が問題だし、明確に誰も言わなければ「やったもん勝ち」で通してしまった管理体制に問題がある。所謂、審査員に対して要求している倫理的行動が貫かれなかった訳だ。
不思議なことに、牛乳瓶通しでは話題になっても結論が割れることは一度も無かった。派遣先に常注して従事する業務は認証範囲外は明確。でも何処かの誰かが勝手にやっていることも事実らしい。
取り締まる機関にはＪＡＢとかＪＩＰＤＥＣとかがあるが、ＩＳＭＳでは力不足と言った所みたい。
.*.
少々誤解されることもあるが、客先に常駐して行う業務については、派遣元の会社内でも実施する業務というケースがある。だから、その場合は記載内容は「ｘｘｘ開発」とやっておいても全く問題が無い。社内に開発環境も一切置いてなくて純粋に人貸し業の場合は、それなりに控えめの認証範囲が妥当ということですね。
分るような気がする。
.*.
ＩＳＭＳでは解釈が割れているらしい。しかし、割れていること自体が問題だし、明確に誰も言わなければ「やったもん勝ち」で通してしまった管理体制に問題がある。所謂、審査員に対して要求している倫理的行動が貫かれなかった訳だ。
不思議なことに、牛乳瓶通しでは話題になっても結論が割れることは一度も無かった。派遣先に常注して従事する業務は認証範囲外は明確。でも何処かの誰かが勝手にやっていることも事実らしい。
取り締まる機関にはＪＡＢとかＪＩＰＤＥＣとかがあるが、ＩＳＭＳでは力不足と言った所みたい。
.*.
少々誤解されることもあるが、客先に常駐して行う業務については、派遣元の会社内でも実施する業務というケースがある。だから、その場合は記載内容は「ｘｘｘ開発」とやっておいても全く問題が無い。社内に開発環境も一切置いてなくて純粋に人貸し業の場合は、それなりに控えめの認証範囲が妥当ということですね。
分るような気がする。
.*.
派遣会社って、社員は派遣先に行っていて、会社には誰も居ない。管理者とサポートの女性。こういう会社のＩＳＯって何だろう。
名刺に、私どもはＩＳＯをやっていますとマークを印刷したいので、派遣先に常駐する人も一員に組み込む。あわよくば派遣先の業務そのものも組み入れた。
派遣を主体とする企業のＩＳＯは自社に残って管理している人の範囲で認証取得がどうやら常識らしい。
ＰＤＣＡが回って経営者が責任の取れるように改善が責任を持って進められる範囲で認証の領域を設定するのは常識。経営者の責任（権限）の及ばない範囲まで人称範囲にしたら、経営者の無責任を追及される最悪の事態になる。越権でやれば契約上の問題が出るし、責任も権限もない範囲をあたかも責任権限が及ぶように外部に見せるのは詐欺行為に近い行いになる。
「派遣先に常駐してソフトウエア開発に従事する人を管理する業務」と表現するなら嘘はないが、黙って「ソフトウエア開発」とやれば詐欺行為でしょう。商行為における虚偽の記載だから逮捕されてもいいのかな。
.*.
ところが、不心得なコンサルと不心得な審査機関が組むと、常駐先で管理されてやっている業務まで自社の業務として認証範囲に記載することがある。クライアントもそのほうが受けがいいから譲らない。赤信号をみんなで渡る図式だ。とは言え、流石に今時はこのようなことはないとのことだ。以前に認証した時の適用範囲（スコープ）表現の見直しに時間が掛かっていると言うのが昨今の実態だろう。
カスタマーフォーカス。顧客第一主義。ＣＳ経営。どういう言葉を並べようと、より本質的な意味でそれを達成すべきで、目先の売上・顧客対応だけで判断するのはコンサルも審査員も二流だとか。
しっかりお客さんに説明する先生は見た感じではせいぜい1割？。それ位らしい。
.*.
名刺に、私どもはＩＳＯをやっていますとマークを印刷したいので、派遣先に常駐する人も一員に組み込む。あわよくば派遣先の業務そのものも組み入れた。
派遣を主体とする企業のＩＳＯは自社に残って管理している人の範囲で認証取得がどうやら常識らしい。
ＰＤＣＡが回って経営者が責任の取れるように改善が責任を持って進められる範囲で認証の領域を設定するのは常識。経営者の責任（権限）の及ばない範囲まで人称範囲にしたら、経営者の無責任を追及される最悪の事態になる。越権でやれば契約上の問題が出るし、責任も権限もない範囲をあたかも責任権限が及ぶように外部に見せるのは詐欺行為に近い行いになる。
「派遣先に常駐してソフトウエア開発に従事する人を管理する業務」と表現するなら嘘はないが、黙って「ソフトウエア開発」とやれば詐欺行為でしょう。商行為における虚偽の記載だから逮捕されてもいいのかな。
.*.
ところが、不心得なコンサルと不心得な審査機関が組むと、常駐先で管理されてやっている業務まで自社の業務として認証範囲に記載することがある。クライアントもそのほうが受けがいいから譲らない。赤信号をみんなで渡る図式だ。とは言え、流石に今時はこのようなことはないとのことだ。以前に認証した時の適用範囲（スコープ）表現の見直しに時間が掛かっていると言うのが昨今の実態だろう。
カスタマーフォーカス。顧客第一主義。ＣＳ経営。どういう言葉を並べようと、より本質的な意味でそれを達成すべきで、目先の売上・顧客対応だけで判断するのはコンサルも審査員も二流だとか。
しっかりお客さんに説明する先生は見た感じではせいぜい1割？。それ位らしい。
.*.
開発のご経験はありますか？
システムとかソフトウエアの開発経験はＩＴ企業には豊富にあっても一般企業では極めて稀。昨今のようにセキュリティ対策の成否が会社の浮沈にまで影響する時代では、素人には手が出せない。
企業でＩＴを担当させられている場合は、中小企業の場合は特に神経質になる。人が余って居るわけでなく、予算が潤沢にあるわけでなく、ボランティアに会社のセキュリティが任されているときは傍から見る以上に本人はプレッシャー。
こういう無理無理がんばっている人を平気でやっつける審査員を見ると腹が立つ。らしい。杓子定規は止めてほしい。
出来ることから一つ一つ積み上げていくのを応援する審査をやってくれ。ということらしい。
コンサルは金さえあればいいツールを紹介するが、金が無い時にどうやって乗り切るかが知恵の出しどころ。
クライアントと気持ちが一緒になれば手弁当で頑張る。その辺の呼吸がなかなか難しい。
.*.
どんな会社でも総務人事経理はあります。そのためのシステムも動いています。手作りであろうがパッケージであろうがシステムの調達行為は必ず存在するし、システム改修も必ずあります。年度ごとに決算のルールを変えたりするし人事の制度（主に給与）も変わります。システム開発《調達）の経験がない会社は存在しない。
問題はどの部署の役割かが明確かなケースと明確でないケースがあること。だから、冒頭の質問は誰に出されるかで意味が有ったり無かったり。その企業の姿勢がＩＴガバナンスをどの程度意識しているかで守りも攻めも変わるらしい。
.*.
結局、何が言いたいの？。まあ、IT業務に長けているかどうかでコンサルのやり方も、多分、審査のやり方も変わるということですね。
そんなの当たり前ジャン。
それより、どういうシステムを利用していますか？と聞いた方が話はクリアで、共感も得やすい。冒頭のフレーズを人を馬鹿にしているように聞こえる。
.*.
システムとかソフトウエアの開発経験はＩＴ企業には豊富にあっても一般企業では極めて稀。昨今のようにセキュリティ対策の成否が会社の浮沈にまで影響する時代では、素人には手が出せない。
企業でＩＴを担当させられている場合は、中小企業の場合は特に神経質になる。人が余って居るわけでなく、予算が潤沢にあるわけでなく、ボランティアに会社のセキュリティが任されているときは傍から見る以上に本人はプレッシャー。
こういう無理無理がんばっている人を平気でやっつける審査員を見ると腹が立つ。らしい。杓子定規は止めてほしい。
出来ることから一つ一つ積み上げていくのを応援する審査をやってくれ。ということらしい。
コンサルは金さえあればいいツールを紹介するが、金が無い時にどうやって乗り切るかが知恵の出しどころ。
クライアントと気持ちが一緒になれば手弁当で頑張る。その辺の呼吸がなかなか難しい。
.*.
どんな会社でも総務人事経理はあります。そのためのシステムも動いています。手作りであろうがパッケージであろうがシステムの調達行為は必ず存在するし、システム改修も必ずあります。年度ごとに決算のルールを変えたりするし人事の制度（主に給与）も変わります。システム開発《調達）の経験がない会社は存在しない。
問題はどの部署の役割かが明確かなケースと明確でないケースがあること。だから、冒頭の質問は誰に出されるかで意味が有ったり無かったり。その企業の姿勢がＩＴガバナンスをどの程度意識しているかで守りも攻めも変わるらしい。
.*.
結局、何が言いたいの？。まあ、IT業務に長けているかどうかでコンサルのやり方も、多分、審査のやり方も変わるということですね。
そんなの当たり前ジャン。
それより、どういうシステムを利用していますか？と聞いた方が話はクリアで、共感も得やすい。冒頭のフレーズを人を馬鹿にしているように聞こえる。
.*.
社内システムの改善
基幹システム、総務・人事・経理といったどこの会社でも基本システムとして欠かせないものを基幹システムとして位置づけて情報システム部門がそのお守りにあたる。会社の機密情報が集中する訳では、投資の優先度も高い。
このシステムをサラで開発する例は少ない。企業が大きいと10年、20年に1回くらいしかやらない。小さくても5年で入れ替えるのは稀だ。基幹システムは手作りカスタマイズの塊でおいそれと更新も出来ない。その分、部分改修は頻繁に行われる。エンハンスメント開発も含まれる。パッケージをそのまま使うのも苦労が伴う。カルチャーのぶつかり合いだから。
既存システムの機能拡張あるいは機能変更を行う場合、システム改修のための手順はあるか、セキュリティ要求事項を明確にしているか、が問題になる。ゼロベース開発手順を適用するのか、スキップできる手順を明確にしているか。システムトラブルの殆どはシステム改修直後だから重要といえば重要らしい。
泣き所は、コンサルも審査員もＩＴのプロではないこと。技法、ツールをベースの手順を見ても何の判断も出来ない。
基幹システム、総務・人事・経理といったどこの会社でも基本システムとして欠かせないものを基幹システムとして位置づけて情報システム部門がそのお守りにあたる。会社の機密情報が集中する訳では、投資の優先度も高い。
このシステムをサラで開発する例は少ない。企業が大きいと10年、20年に1回くらいしかやらない。小さくても5年で入れ替えるのは稀だ。基幹システムは手作りカスタマイズの塊でおいそれと更新も出来ない。その分、部分改修は頻繁に行われる。エンハンスメント開発も含まれる。パッケージをそのまま使うのも苦労が伴う。カルチャーのぶつかり合いだから。
既存システムの機能拡張あるいは機能変更を行う場合、システム改修のための手順はあるか、セキュリティ要求事項を明確にしているか、が問題になる。ゼロベース開発手順を適用するのか、スキップできる手順を明確にしているか。システムトラブルの殆どはシステム改修直後だから重要といえば重要らしい。
泣き所は、コンサルも審査員もＩＴのプロではないこと。技法、ツールをベースの手順を見ても何の判断も出来ない。
情報セキュリティ要求事項
これは行けないらしい。おどろおどろした言葉が思考停止を招いてしまう。開発者向けならセキュリティ実装方針あるいはセキュリティ要件でもいいのではないかということらしい。ものを作る時にセキュリティのことも考えてください。物を作る時に、安全を考えるのは常識、最近はエコも考えるのが常識。コストも考える。勿論、性能・機能は入る。そういう開発要件の中にしっかりセキュリティを入れなさないということ。極めて常識的。
こういう風に話を聞くとタイトルの言葉も理解できない訳ではない。さらに、セキュリティの中身はソフト開発、システム開発をやる人には当然の内容がほとんどで、今更、セキュリティ要求事項を振りかざされると戸惑うのは止む無いことのようだ。ある意味、余計なお世話。まあ、チェックリストの一つとしてみるだけは見ておきましょうねというレベル。
..
それは当然。ここに集まる牛乳瓶はＩＴのプロではなくてプロのＩＴ開発者にものを言うには知識的にも無理がある。
牛乳瓶はもう一つのことで盛り上がった。品質、環境、情報、サービスなどの分野で微妙に言い回しが変わってくる。牛乳瓶にもいろいろあるようだ。一人でいくつもやる人もいて、こっちではこうだけどこっちではこうだ。ちんぷんかんぷん。
セキュリティ要求は社内のシステムに対して要求するもので、販売するシステムには要求しないと言い出した牛乳瓶をよってたかって小突き始めた。セキュリティをやっている会社からセキュリティに穴だらけのソフトが出てくることの是非が小突きあいの争点。訳知り顔の牛乳瓶は、それは品質の要求であってセキュリティの要求ではないと来たもんだ。
聞いていて変な理屈だと思ったら、フォローする牛乳瓶が出てくる。品質要求に無かったら、セキュリティをやっている会社からセキュリティホール付きのソフトを出荷していいのかと聞いてきた。訳知りはそれは品質の問題、セキュリティじゃないと又叫ぶ。こうなると殆どアホに見えてくる。世間はそんな仕分けはしてくれない。社長だってＯＫする訳ない。理屈屋の小理屈だね。
社内で開発した販売用のソフトウエアも立派な情報資産。開発環境もテスト環境も情報資産で溢れ返る。全ての情報資産はリスクに応じたセキュリティが維持されることが求められるから、仮に商品であってもセキュリティは達成されなければいけない。求められるセキュリティレベルは商品の取扱（社内及び顧客先）に応じたものであればいい。全くケアしない（セキュリティを考慮しない）こととは別の話だ。
普通の会社？では、品質要件にセキュリティ要件を織り込んでいることが多いが、セキュリティは無関係ということではまったく無い。社内に滞留する情報資産に対するセキュリティ要件のスタンスの話が１つ。
もう一つは、商品提供は会社の行うサービスとして捉えることができるという発想のもの。ＰＬ法とか保証とかサポートとかあって、企業はものを売っても関係が切れるわけではない。商品に対する責任、商品の基本性能に対する責任は長く求められるという観点に立てば、デフォルトでセキュリティを掛け、顧客の責任でセキュリティを外すとか追加のセキュリティを実装するとかの流れが実際的だという主張が出てきた。
訳知り顔は依然頑張っているが、保身的な振る舞いに見えるのは致し方無しということでしょうか。
これは行けないらしい。おどろおどろした言葉が思考停止を招いてしまう。開発者向けならセキュリティ実装方針あるいはセキュリティ要件でもいいのではないかということらしい。ものを作る時にセキュリティのことも考えてください。物を作る時に、安全を考えるのは常識、最近はエコも考えるのが常識。コストも考える。勿論、性能・機能は入る。そういう開発要件の中にしっかりセキュリティを入れなさないということ。極めて常識的。
こういう風に話を聞くとタイトルの言葉も理解できない訳ではない。さらに、セキュリティの中身はソフト開発、システム開発をやる人には当然の内容がほとんどで、今更、セキュリティ要求事項を振りかざされると戸惑うのは止む無いことのようだ。ある意味、余計なお世話。まあ、チェックリストの一つとしてみるだけは見ておきましょうねというレベル。
..
それは当然。ここに集まる牛乳瓶はＩＴのプロではなくてプロのＩＴ開発者にものを言うには知識的にも無理がある。
牛乳瓶はもう一つのことで盛り上がった。品質、環境、情報、サービスなどの分野で微妙に言い回しが変わってくる。牛乳瓶にもいろいろあるようだ。一人でいくつもやる人もいて、こっちではこうだけどこっちではこうだ。ちんぷんかんぷん。
セキュリティ要求は社内のシステムに対して要求するもので、販売するシステムには要求しないと言い出した牛乳瓶をよってたかって小突き始めた。セキュリティをやっている会社からセキュリティに穴だらけのソフトが出てくることの是非が小突きあいの争点。訳知り顔の牛乳瓶は、それは品質の要求であってセキュリティの要求ではないと来たもんだ。
聞いていて変な理屈だと思ったら、フォローする牛乳瓶が出てくる。品質要求に無かったら、セキュリティをやっている会社からセキュリティホール付きのソフトを出荷していいのかと聞いてきた。訳知りはそれは品質の問題、セキュリティじゃないと又叫ぶ。こうなると殆どアホに見えてくる。世間はそんな仕分けはしてくれない。社長だってＯＫする訳ない。理屈屋の小理屈だね。
社内で開発した販売用のソフトウエアも立派な情報資産。開発環境もテスト環境も情報資産で溢れ返る。全ての情報資産はリスクに応じたセキュリティが維持されることが求められるから、仮に商品であってもセキュリティは達成されなければいけない。求められるセキュリティレベルは商品の取扱（社内及び顧客先）に応じたものであればいい。全くケアしない（セキュリティを考慮しない）こととは別の話だ。
普通の会社？では、品質要件にセキュリティ要件を織り込んでいることが多いが、セキュリティは無関係ということではまったく無い。社内に滞留する情報資産に対するセキュリティ要件のスタンスの話が１つ。
もう一つは、商品提供は会社の行うサービスとして捉えることができるという発想のもの。ＰＬ法とか保証とかサポートとかあって、企業はものを売っても関係が切れるわけではない。商品に対する責任、商品の基本性能に対する責任は長く求められるという観点に立てば、デフォルトでセキュリティを掛け、顧客の責任でセキュリティを外すとか追加のセキュリティを実装するとかの流れが実際的だという主張が出てきた。
訳知り顔は依然頑張っているが、保身的な振る舞いに見えるのは致し方無しということでしょうか。
個人情報の管理
多分、日本くらい個人情報の管理に神経質な国はないのではと思われるくらい情報漏えいのニュース記事が毎日のように流れる。
個人情報を収集したり保持したりするときは個人情報保護法の適用を受ける。安全な管理・適切な管理が求められる。適用条件となる情報件数は5千件以上らしいが、1千件だったら許してくれるほど社会は甘くない。結局、個人情報は常に安全に管理されるべきとなるのは止むを得ない。
安全な管理の一つとして暗号化圧縮技術の応用がある。
*.*
多分、日本くらい個人情報の管理に神経質な国はないのではと思われるくらい情報漏えいのニュース記事が毎日のように流れる。
個人情報を収集したり保持したりするときは個人情報保護法の適用を受ける。安全な管理・適切な管理が求められる。適用条件となる情報件数は5千件以上らしいが、1千件だったら許してくれるほど社会は甘くない。結局、個人情報は常に安全に管理されるべきとなるのは止むを得ない。
安全な管理の一つとして暗号化圧縮技術の応用がある。
*.*
ソースコードの管理
ソフトウエアのソースコードと聞いてもぴんと来ないが、作成したソフトウエアプログラム、いろんな命令の塊。どんなパソコンでソフトを動かすによってプログラムの実行形式を変えて使うらしいが、ソースというのはパソコン向けに変更する前の大元。一番大事なものの一つらしい。
紙で管理する会社も稀にある。電子情報の危うさを知る会社は紙にこだわる。サーバーに入れておいて、ハードクラッシュでソースも消えた。幸いバックアップが委託先に取ってあった。テープとかに入れておいたらテープ毎行方不明とか。大事に保管していたのは古いやつだったとか。委託先に丸投げしていたら倒産。ソースも所在不明。
実に色々な失敗があるが、おいそれと笑えないらしい。ソースはなかなか確定しない。いつも中途半端。手直しが仕切りと発生する。管理用のソフトを買うところもある。結構高いから、大きな企業。小さな企業はツールは買えないし、管理する能力（手間）が出ないし。
もう一つは、ソースは誰のものかという問題がある。発注者？、開発者？、利用者？。ソースと言っても下敷きがある時は複雑。オリジナルは何処にあるか。それを明確にするのは大変らしい。
著作権
バックアップ（保全性）
Availability（有用性）
世代管理（履歴管理の側面もあるが派生バージョンが多いケースでは単純でない？）
変更管理（一般的には手順のことだが、規模によってはもっと面倒でツールのお世話になりたい。
*.*
ソフトウエアのソースコードと聞いてもぴんと来ないが、作成したソフトウエアプログラム、いろんな命令の塊。どんなパソコンでソフトを動かすによってプログラムの実行形式を変えて使うらしいが、ソースというのはパソコン向けに変更する前の大元。一番大事なものの一つらしい。
紙で管理する会社も稀にある。電子情報の危うさを知る会社は紙にこだわる。サーバーに入れておいて、ハードクラッシュでソースも消えた。幸いバックアップが委託先に取ってあった。テープとかに入れておいたらテープ毎行方不明とか。大事に保管していたのは古いやつだったとか。委託先に丸投げしていたら倒産。ソースも所在不明。
実に色々な失敗があるが、おいそれと笑えないらしい。ソースはなかなか確定しない。いつも中途半端。手直しが仕切りと発生する。管理用のソフトを買うところもある。結構高いから、大きな企業。小さな企業はツールは買えないし、管理する能力（手間）が出ないし。
もう一つは、ソースは誰のものかという問題がある。発注者？、開発者？、利用者？。ソースと言っても下敷きがある時は複雑。オリジナルは何処にあるか。それを明確にするのは大変らしい。
著作権
バックアップ（保全性）
Availability（有用性）
世代管理（履歴管理の側面もあるが派生バージョンが多いケースでは単純でない？）
変更管理（一般的には手順のことだが、規模によってはもっと面倒でツールのお世話になりたい。
*.*
この10年の間に、実は風呂屋は店を閉じた。と言って何かビルが建った訳でもない。客が極端に減った訳でもない。所謂、世代交代が上手く行かなかったことになるのだろう。風呂屋の仕事はああ見えて結構重労働らしい。公衆衛生上の規制も厳しくて、燃料代、メンテナンス代と、兎に角、金も体力も要る。夫婦でやり続けるのは大変だった。家業を継いでくれることも期待できず。休業がぽつぽつあったと思ったら、張り紙がずっと残ることになった。常連さんが減って、一見さんが増えるから、心理的な負担もあった。
風呂屋の隣は、相変わらず牛乳の売れ行きがいい。風呂屋が閉まって、幾分減ることは減ったがココに来る客は牛乳好きだ。見知った人の顔が牛乳瓶にかぶるのも仕方のないことだ。牛乳も瓶からパックが主流だが、この店は瓶に拘る客が多い。
メモは量は大したことはないが捨てずに取っておいたから、いきなり黙って捨てることが出来ないくらいの愛着が残る。5年以上も前のメモもある。10年を超えるものは見つからないが、十年一昔の雰囲気にはなってきた。
少しの本当と少しの嘘とたくさんの分らないで埋まったメモを少しずつ捨てることにした。
同じ話が何度も出るのには閉口する。しかも結論が右だったり左だったりで定まらない。
*.*
風呂屋の隣は、相変わらず牛乳の売れ行きがいい。風呂屋が閉まって、幾分減ることは減ったがココに来る客は牛乳好きだ。見知った人の顔が牛乳瓶にかぶるのも仕方のないことだ。牛乳も瓶からパックが主流だが、この店は瓶に拘る客が多い。
メモは量は大したことはないが捨てずに取っておいたから、いきなり黙って捨てることが出来ないくらいの愛着が残る。5年以上も前のメモもある。10年を超えるものは見つからないが、十年一昔の雰囲気にはなってきた。
少しの本当と少しの嘘とたくさんの分らないで埋まったメモを少しずつ捨てることにした。
同じ話が何度も出るのには閉口する。しかも結論が右だったり左だったりで定まらない。
*.*
審査工数ばかり気にする審査員？
審査員は審査工数をひどく気にする。コンサルはあまり気にしていない。認証取得が問題で、コンサルの費用に比べれば審査費用は問題外。規模の大きい企業なら尚更だ。
コンサルタント事業と審査事業は規模が一桁の差では済まない。2桁以上違う感じだ。
審査員＝審査機関が審査工数を気にする本来の理由は、審査の正当性を確保するためには、何処かのガイドラインをクリアしなければいけないというもの。だから、審査工数を多めに設定すれば話は終わる。ところが、審査機関も事業だから受注するには審査費用は小さい方が有利と考える存在（営業？）があるからややこしい。
何か起きるか。ある審査機関は審査単価（一人一日の費用）を下げて、工数はたっぷり確保する。ある審査機関は単価を下げないで工数をガイドが許す限りのミニマムを目指す。
工数をぎりぎりにすると無理が出る。トラブルは良く起きる。お目付けの機関も要注意としてマークを続ける。ということらしい。
一方、コンサルは上がってなんぼだから工数は関係ない。と言いつつも採算に響くので、パッケージの転用で済まそうとする。パッケージ利用率で管理されることもある。コンサルも工数で費用請求するケースもあるようだ。ややこしい。前者は認証取得を請け負う事業で、後者はお手伝いにこのレベルの人間を1年間お貸ししますと言ったようなもの。派遣の感覚。
審査員は審査工数をひどく気にする。コンサルはあまり気にしていない。認証取得が問題で、コンサルの費用に比べれば審査費用は問題外。規模の大きい企業なら尚更だ。
コンサルタント事業と審査事業は規模が一桁の差では済まない。2桁以上違う感じだ。
審査員＝審査機関が審査工数を気にする本来の理由は、審査の正当性を確保するためには、何処かのガイドラインをクリアしなければいけないというもの。だから、審査工数を多めに設定すれば話は終わる。ところが、審査機関も事業だから受注するには審査費用は小さい方が有利と考える存在（営業？）があるからややこしい。
何か起きるか。ある審査機関は審査単価（一人一日の費用）を下げて、工数はたっぷり確保する。ある審査機関は単価を下げないで工数をガイドが許す限りのミニマムを目指す。
工数をぎりぎりにすると無理が出る。トラブルは良く起きる。お目付けの機関も要注意としてマークを続ける。ということらしい。
一方、コンサルは上がってなんぼだから工数は関係ない。と言いつつも採算に響くので、パッケージの転用で済まそうとする。パッケージ利用率で管理されることもある。コンサルも工数で費用請求するケースもあるようだ。ややこしい。前者は認証取得を請け負う事業で、後者はお手伝いにこのレベルの人間を1年間お貸ししますと言ったようなもの。派遣の感覚。
2011年07月01日
風呂屋の隣は酒も飲める牛乳屋。
コンサルのたまり場。
いつも同じような話。
これじゃ客も気の毒だ。コンサルって結構高いらしいから。
四方山話の結論？
結論が無いのが四方山話。
ちょっと自慢できるかなと思えるのは、このメモを取って居たら、規格書とか、新書本みたいな小さい奴を誰かから酒の勢いでもらったこと。意味は分らないけど、よく出てくる数字が規格の番号ということは分る。
.*.
分からないことで、気になるのは調べたりすることも出来るようになった。で、どこかの話もメモに加えて、所謂、パクリも加わってメモは増えるのに、発信元は全く不明。主語がいつの間にか自分になっている。錯覚？ でもこれだけ付き合えば気持ちは業界人でも致し方あるまい。なんてね。
パクリは、そうだそうだと思うのはパクリの対象になるが、ちょっと違うと思えばパクリの対象にしていないつもり。まあ、時々で変わらないわけではないけど。つまり、一貫性はないけど。
文字にして載せておけば、自分で参照するには便利。
場合によっては誰かの参考になるかもしれない。
コンサルのたまり場。
いつも同じような話。
これじゃ客も気の毒だ。コンサルって結構高いらしいから。
四方山話の結論？
結論が無いのが四方山話。
ちょっと自慢できるかなと思えるのは、このメモを取って居たら、規格書とか、新書本みたいな小さい奴を誰かから酒の勢いでもらったこと。意味は分らないけど、よく出てくる数字が規格の番号ということは分る。
.*.
分からないことで、気になるのは調べたりすることも出来るようになった。で、どこかの話もメモに加えて、所謂、パクリも加わってメモは増えるのに、発信元は全く不明。主語がいつの間にか自分になっている。錯覚？ でもこれだけ付き合えば気持ちは業界人でも致し方あるまい。なんてね。
パクリは、そうだそうだと思うのはパクリの対象になるが、ちょっと違うと思えばパクリの対象にしていないつもり。まあ、時々で変わらないわけではないけど。つまり、一貫性はないけど。
文字にして載せておけば、自分で参照するには便利。
場合によっては誰かの参考になるかもしれない。
風呂屋の隣が飲み屋。売れるのは牛乳。意外な客として先生が多い。似たような話が毎晩繰り返される。先生方が直接経験したこと、ただ聞いただけの話し。面白かろうと勝手に作った話。
成る程。これが四方山話というものか。
虚虚実実の繰り返される話は妙な空気を作って伝染病みたいに、人から人へ移っていく。
こちらは場末の女給みたいだけど、一応学校は出ている。何の警戒心も無く、声も潜めず。いい加減な話をしていることに少し腹立たしくもなる。
メモしてみることした。そうすれば客と話をあわせることも出来るようになる。
成る程。これが四方山話というものか。
虚虚実実の繰り返される話は妙な空気を作って伝染病みたいに、人から人へ移っていく。
こちらは場末の女給みたいだけど、一応学校は出ている。何の警戒心も無く、声も潜めず。いい加減な話をしていることに少し腹立たしくもなる。
メモしてみることした。そうすれば客と話をあわせることも出来るようになる。
風呂屋の隣の飲み屋。飲み屋と言っても牛乳が一番売れる飲み屋。湯上りのほてりを冷まして、次はアルコールで温めなおすなんて、人間らしい。酒は日本酒もビールも洋酒も何でも置いてある。まるでいい加減な飲み屋。つまみは乾きもので済まされたり。
どう言う訳か、出張者のたまり場になっている。一週間いてビジネスホテルからわざわざこの風呂屋に足を運ぶ連中。彼らはカラオケよりも客の悪口でもないが残念をしきりに口にする。語り口は先生様。会社は別でも客の悪口の話は共通らしく変に盛り上がる。
先生方は大方は年配の紳士といった雰囲気。若い人も混じる。若い人は二色。使い走りのような小気味良い反応をする人と、如何にもエリート然とした雰囲気の人。能書きが達者なだけで、傍から見ていても気分はよくない。時に、女の先生が入ったりもするが、盛り上がり方は変わる。女といっても年齢は相当なんだけど、異性が混じると意識しないではいられないらしい。
しかし、まあ、人が変わっても会社が変わっても、似たような話を延々繰り返すだけで、テープを巻きなおしてみている感じ。駄目だ駄目だといっている人が一番駄目に見えてくる。
所謂、コンサルタントの先生。どう言う訳か審査員の先生も混じる。コンサルタントは二枚舌どころか全身が舌で出来ているような、一体何が本当の本音かは皆目分らないようにも思う。コンサルという種族はどこまで行っても実が無い寂しい人たちのようにも見える。
口先商売の先生に共通する特性？なのか、必ず何処かで線を引いて其処から先へは梃子でも行こうとしない。当事者にならない。
.*.
どう言う訳か、出張者のたまり場になっている。一週間いてビジネスホテルからわざわざこの風呂屋に足を運ぶ連中。彼らはカラオケよりも客の悪口でもないが残念をしきりに口にする。語り口は先生様。会社は別でも客の悪口の話は共通らしく変に盛り上がる。
先生方は大方は年配の紳士といった雰囲気。若い人も混じる。若い人は二色。使い走りのような小気味良い反応をする人と、如何にもエリート然とした雰囲気の人。能書きが達者なだけで、傍から見ていても気分はよくない。時に、女の先生が入ったりもするが、盛り上がり方は変わる。女といっても年齢は相当なんだけど、異性が混じると意識しないではいられないらしい。
しかし、まあ、人が変わっても会社が変わっても、似たような話を延々繰り返すだけで、テープを巻きなおしてみている感じ。駄目だ駄目だといっている人が一番駄目に見えてくる。
所謂、コンサルタントの先生。どう言う訳か審査員の先生も混じる。コンサルタントは二枚舌どころか全身が舌で出来ているような、一体何が本当の本音かは皆目分らないようにも思う。コンサルという種族はどこまで行っても実が無い寂しい人たちのようにも見える。
口先商売の先生に共通する特性？なのか、必ず何処かで線を引いて其処から先へは梃子でも行こうとしない。当事者にならない。
.*.
2011年01月23日
Performance Evaluation
普通に訳すと達成度評価。有効性評価が使われるかも。
1. 監視、計測、分析及び評価
2. 内部監査
3. マネジメントレビュー
マネジメントレビューは経営者自らが評価を行う。
内部監査は経営者から委託された独立した組織が評価を行う。
監視計測分析評価は運用者が運用の一環として行う（適切に運用するためのフィードバック回路）。組織の機能設計の観点から理解すればISMS事務局の仕事になる。
普通に訳すと達成度評価。有効性評価が使われるかも。
1. 監視、計測、分析及び評価
2. 内部監査
3. マネジメントレビュー
マネジメントレビューは経営者自らが評価を行う。
内部監査は経営者から委託された独立した組織が評価を行う。
監視計測分析評価は運用者が運用の一環として行う（適切に運用するためのフィードバック回路）。組織の機能設計の観点から理解すればISMS事務局の仕事になる。
2010年06月10日
モバイルコードに対する管理策
この頃は広くフリーソフト全般に対する管理策として理解することが多い。
ホワイトリスト方式とブラックリスト方式があるが、セキュリティを意識したらホワイトリスト方式が普通でしょう。
依然は管理工数の関係でぶらっくをリスト方式が採用するところが多かったが、最近はホワイトリスト方式の採用が増えてきた。
いずれにしても情報システム部門の検証を踏まえてリストにアップされる。
企業規模に比べて情報部門が貧弱な場合は、開発元が明確、アップデートが定期的にされている、業界の実績があるなどの条件を栗すれば部門判断で導入を認めるところもある。
どのような場合でも、基幹ネットワークから分離されたテスト環境を持つことは必須であるが、担当者の意識が無防備なことが余程懸念される。一生懸命に頑張っていることとシステムの脆弱性とは何も関係ないということに気づいてほしい物だ。
この頃は広くフリーソフト全般に対する管理策として理解することが多い。
ホワイトリスト方式とブラックリスト方式があるが、セキュリティを意識したらホワイトリスト方式が普通でしょう。
依然は管理工数の関係でぶらっくをリスト方式が採用するところが多かったが、最近はホワイトリスト方式の採用が増えてきた。
いずれにしても情報システム部門の検証を踏まえてリストにアップされる。
企業規模に比べて情報部門が貧弱な場合は、開発元が明確、アップデートが定期的にされている、業界の実績があるなどの条件を栗すれば部門判断で導入を認めるところもある。
どのような場合でも、基幹ネットワークから分離されたテスト環境を持つことは必須であるが、担当者の意識が無防備なことが余程懸念される。一生懸命に頑張っていることとシステムの脆弱性とは何も関係ないということに気づいてほしい物だ。
