予約の日程

予約の日程と言ってもピンと来ないでしょう。

出張の時の予約のことです。

宿（ホテル）と足（交通機関）。先ず、宿を取ります。宿のキャンセルは自由度が高いので早くとって問題ない。早期予約料金の設定もあるから安く泊まることができる。それに、受験とかイベントとかが入ると急に宿が取れなくなることもあるので、その意味でもなるべき早期にとる。

東横イン、アパホテル、ルートイン、などのホテルチェーンを利用する人は出張先の細かい住所が不明でも、取り合えず押さえる。ホテルの会員メンバーなら尚のこと。

次に優先するのはフライト。席が直ぐに埋まる。都合の時間のフライトで、良い席で移動したい。遅くなると真ん中の窮屈な席になる。自由度が低いため、日程が確定したら、なるべく早く予約する。

予約すると３日以内に決済を要求されるので、出張スケジュールが本当に確定しているかどうかの確認は必要。１ヶ月を切ったら予約に入ること。

在来線の特急。全く読めないが満席になる懸念は少ない。最悪、自由席、立ち席でも良いでしょう。新幹線も同様。２週間を切ったら即予約が良い。即時決済だから、スケジュール確定は大事。

※

• ホテル：スケジュール提示、都市確定で即手配。
• フライト：スケジュール提示、手配了解確認の上、３０日前に予約。チケットレス搭乗。領収書は機械発行のもので済ます。
• 新幹線：スケジュール提示、手配了解確認の上、１５日前に予約。駅ネットチケットは１週間前。領収書は窓口。

-

20090113

-system-

-audit-

• やたらと細切れの審査計画。話を聞いている内に終わってしまうよ。
• 自分だけ新幹線で仙台～大宮と素直な流れで気持ちよくお泊り審査を設定している。審査する業務領域（機能）も単純な営業支店２件。リーダーが見る領域じゃない。
• 他人には日帰りで静岡～千葉と振り回す。前泊出来ないようにわざわざ変な開始時間に設定している。審査効率も移動効率も何もない。審査領域は特殊な業務と営業。こちらが複雑と言うか大事。
  

-advisory-

20081215

-system-

• 全体のバランスが良くない。形式主義的な印象。昔のＩＳＯ9000の文化に馴染み過ぎたのではないかと思う。本質を見る考えるが上手くできていない。いまだ手探り。
  

-audit-

• 審査計画は酷い。まるで素人。
• 単なる人数比で時間を決めているから製造部門はやたら意味も無く長い。
  
• 所見は凡庸。
  

-advisory-

アボカド-コンテンツ・ガイド

◇「システム」

構築されたＩＳＭＳシステム。「システム-1」（概要）は場所、規模、事業分野など一般的な内容。「システム-2」（特徴）は非常に優れている事項、非常に劣っている事項、一般から乖離している事項内容。

◇「審査」

システムを評価する審査概要。「審査-1」は審査チームの人数・経験・年齢・傾向、及び審査計画の概要。「審査-2」は審査所見の特徴。優れた所見、劣る所見、見逃した事項。

◇「助言」

「助言-1」はシステム構築・改善に向けたシステムオーナーに対する助言。「助言-2」は「審査チームに対する助言。

アボカド-コーディング・ポリシー

審査開始日-年月日（6桁）
審査日数（実出動日数。半日も1日。前泊・後泊は含めない）（1桁）
チームメンバー数（1桁）
初回登録年（2桁）

0812085407

system

• 静岡県
• リスクアセスメントが酷い。資産価値評価はＣＩＡの観点から実施されているが、リスク値評価は資産価値との関連が消えてしまっている。資産価値と別に影響の大きさを出しなおしている。では最初の資産価値は何だったのか疑問。リスク値に持って来る時はＣＩＡの観点が消えてしまう。
• リスクアセスメントでゼロ（0）が使われている。ゼロはアナログ情報を論理値のゼロに変換してしまうので取扱が難しい。問題の所在を明確にするために使っているとの説明は説得性がない。刻みを変えれば済むこと。
• 資産価値をゼロにすると無いのか有るのに低いのかすら分からなくなる。脅威をゼロにすると無いのか有るのに低いのかすら分からなくなる。脆弱性をゼロにする絶対神が入るのか人間としては相当頑張っているに過ぎない状態なのか分からなくなる。完璧な人間は存在しないから神とのギャップは大きいし、実際の着地は脆弱性しかないのだから、ゼロが存在したら話は終わってしまう。
  

audit

• 酷い計画。最も長いサイト間移動に対して審査外の取扱にして、他は大した距離移動がなくても審査内の扱いにしている。不公平もいい所だ。
• リスク対応計画に基づかない施策展開。リスクアセスメントとの関連付けも当然無い。降って涌いたような施策が蔓延ししたら適切な成長を妨げることになりかねない。好ましくないのは自明。それでも所見とすることに否定的な審査員がいる。不思議なことだ。
  

Advisory

• 
  

0901133205

audit

• 酷い計画。リーダーは地方遊説でなく本社拠点をやれよ。秘匿性の高いサイトで行き先が分からなければ審査できないのだからアクセスガイドくらい出して欲しいね。
• 酷い計画だね。静岡へ行って、わざわざ朝一番の移動を強要しておいて、次は千葉に追いやる。時間の無駄だろう。静岡県内か神奈川県内か方向ぐらい合わせろよ。帰りがまた大変だし。このやろう何も考えていないな。このくそたわけが。
  

system

• n/a

advisory

• 
  

0812155208

audit

• ひどい審査計画だ。審査員を西や東に振り回してどうするつもりだ。右往左往というのだ。分けの分からない理屈を並べて、人数が多いところでないと全体の把握が出来ないと決めて掛かっている。時間配分が上手く取れないと決めて掛かっている。本末転倒だ。この男は馬鹿だね。
• 京都まで行って、その後、たった一時間の審査のために、名古屋に戻る。その後、また関西へ向かうのだから、それも只の半日仕事でだ。半日日当で一日中振り回すなんてどういう了見だ。この野郎め。
  

0810232-

-審査-

• 人の宿の手配をしてポイントを稼ぐという恥ずかしい御仁。悪い意味ではない違った価値観が支配している。ビジネスライク。それも、パーソナルビジネスライク。

-システム-

• エクセルを利用してリスクアセスを機械的にやろうとしているが、弊害（巨大なダミーデータの入ったリストになり実際的でない）も出ている。この頃は下手な機械化（ツール利用）が多いね。
  

0810272-

-審査-

• 計画は変更が多いし無理（移動時間）に無理があるし。別質のヒアリング中心で部署現場を見ない設定が多い。これじゃ良い審査は出来ない。
• 腰が低い。なかなか出来ないこと。
• 所見は凡庸。

-システム-

• 内容は不明

-

0811253-

-審査員-

• 計画は並み。最新バージョンを連絡してこない。一つ間違えると問題だ。
• 人当たり宜しいが鋭さはない。
• 話を聞いていても伝えようとする意図の部分がなかなか見え難い。
• 所見も凡庸。

-システム-

• リスクアセスはツールを利用。資産価値だけは入力できるけど、後はチェックをしていると勝手にリスク値が判定される。誰も、価値と脅威と脆弱性とリスク値の関係を説明できない。ツールベンダーの言いなり？
• ツールのバージョンが変わるとリスク値が変わる。馬鹿みたい。何に一喜一憂しているんでしょう。
• 部門の固有のリスク（脅威脆弱性）は反映する方法が不明確。

-

591-106-200

• コンサルタント事業
• 技術系が多い。
• アクセンチュア～アンダーセン出身の経営者
• 表面的には懸念はサーバーの保護くらいか。と言うより整理整頓のレベル。
• 構造的にはリスクアセスメントのレベル。脅威の洗い出しが出来ているか。受容レベルの妥当性。資産価値4段階、脅威3段階、脆弱性3段階の構造で、リスク値12は一律受容しているが、資産価値4、脅威3、の資産については、脆弱性1と見てしまった場合、手が抜けてしまう懸念がある。継続的に追加の管理策（環境変化への対応策）を検討させる構造とすべきだ。例えば、リスク値12は個別にトップの確認を得るなど。
• 構築面では規定は規格の丸写し。これってシステム構築が出来ているの？。自分としての構築になっていないからＰＤＣＡは回っていかない。ただのワッペン取得狙いかも。というより時間を掛けたくないのが本音か。
• コンパクトに作って実質的な中身のあるシステムに直していくのが今後の方向か。
• しかし、この担当のＡさんは、いろいろ話を聞いてもメモを取ろうとしないで、上の空で利いているだけ。入社2年目なら立派な社会人なのに。残念。
• さくら総研のコンサルを得たように言っているが実態は感じられない。
  

591-110-300

• 取り立てて何が問題と言うものは見当たらない。
• しかし、リスク対応計画の存在が確認できない。希薄。
• いきなりリスクが全て受容レベルに収まるって言うこと自体が怪しげなものを感じる。改善活動は姿を消して全て維持活動で済まされている。基本的なところを理解していないのではないか。
• 継続的改善でなくて継続的維持活動って何よ。

0811132204

• 一番の引っかかりはリスクアセスメントの手法。
• リスク値は資産価値と脅威と脆弱性の和で算定しているが論理的には有り得ない。背景にある単位系に全く無頓着。
• 驚くのは某審査機関が主催するセミナーでは足し算でも掛け算でも自由ですと説明していること。自由と言うことと合理性を放棄することとは全く別だがこのような審査機関の審査は果たして有効な審査と言えるのだろうか。大いに疑問。
• ＣＩＡ喪失による被害（＝コスト）から実際に実現するであろう期待損失（＝コスト）を導くだけの単純な計算だから、足し算するならコストで無いければいけない。子供が考えても分かることを大企業の大の大人が猪突猛進。気の毒だ。審査員の方もいろいろあって良いですからと言って引き上げていくようだ。
• 脅威・脆弱性の識別も怪しい。が、もともと容易でない部分。別途解説を参照されたい。
• もう一つの懸念は内部監査。実質的には殆ど出来ていない。年１回は会社としてどこかの部門を一つでもやれば定期的に実施となるとでも考えているんだろうか。流石に、監査不足は分かっているようで自主点検をプログラムしているが、是正処置も何もないから適切なＰＤＣＡになっているか分からない始末。
• 監査は特権的な人の専横的業務としていたみたいで全社のへの健全な展開を妨げている。
• 出荷前の組み立て調整エリア、出荷後の不具合きり分け試験エリアに対するゾーニングと整理整頓も弱い。

0812013208

-審査員-

• 下手糞な審査計画だ。これじゃ時間の無駄でしかない。
• 初日、前泊で大阪に入り、午後はオフにして戻す。２日目３日目はしっかり本社を審査する。これで工数は2.5日。宿泊日当が２日分。実働は４日。
• 前泊無しだと、日帰り日当が１日分。実働は３日。中途半端に集中するので返って負担になる。大阪の味を楽しむ時間も無い。
• 審査計画を組んだ人は気が利かないね。
• スキームの問題を指摘しない。これじゃ組織は捻じ曲がったまま固定化されてしまうね。
  

-システム-

• リスクアセスメント。機密性は0-1-2の3段階。完全性・可用性は1-2-3の3段階。何故、レベル値を返るのか不明。リスク値の概念を理解していないからこういうことになる。リスクは結局金額換算ですよ。期待損害額を導き出さないロジックは不毛。
• 脅威・脆弱性は括って1-2-3の3段階。脆弱性に手を打つと言う基本が出来なくなる。
• 加えて、Ｉ-Ａの資産価値は常に同じ設定。値の大きい方を取ると言うが論理的に破綻している。違うものを括ってどうするの？。
• 変なコンサルを入れると基本的なスキームが方向を間違える。
• 「この部署は機密性が高いので審査に入らないで下さい」という場所が３つもある。馬鹿じゃないの。重要な部屋にどういう問題課題があるか、審査で見てもらうのでしょう。それをスキップさせるなんて、目的を自分で否定するようなもの。クレージーだね。
• 怪しげな名簿を何処かで手に入れてきて電話を掛けまくっている。資産台帳にもその名簿は入れていない。
  

-コンサル-

• よく口出しをするコンサルだ。攻め込むと必至になって防戦を始める。挙句、問題・課題の存在を有耶無耶にする。客が混乱するだけだろうが。馬鹿モン。
  

591-106-200

• 1フロア４０人程度。電子錠もがっちり。ビル全体の管理も並み以上だから特に懸念は不要。
• 事務局の一人走りで現場意識と乖離。
• ルールの整備は形だけで中身は何もない。規格をコピーして会社のルールにしている。
• 組織内への定着は殆どこれから。
• だから内部崩壊が一番懸念される。
  

591-029-303

• ここの課題は何かな。
• 適用範囲が限定的であること。サービスを提供する部門（本社、センター）は入れているがサービスを受ける部門（営業部門の出先）は入れてない。リスクは末端にあるのに。
• 社長は接続先･展開先のリスクを心配しているのに適用範囲に入れていない。
• 形骸化が始まっている懸念が大きい。
• 脅威の程度が識別されていない。脅威に対する脆弱性の程度が識別されていない。
  

591-020-203

-client
-system

• 
  
• 現場部署には、資産台帳があるだけで、脅威･脆弱性は何も識別されていない。
• ここも事務局で全て済ませている。
• ３年経っても何も改善されていない。
• 当初はコンサルが入っていたらしい。適当にやって逃げてしまった。
• リスク値を出すロジックも不明。
• リスク対応計画が存在しない。そんな馬鹿な。システム部門を中心に少なくとも運用改善とかやっているだろう。システム改善とかあるだろう。其れは各部署にも降りてきているのではないか。
• ＩＳＭＳが特殊な世界の、封印されるべき存在にされてしまったようだ。
  

ＩＳＭＳの出来具合

ＩＳＭＳの出来具合をどのように見るのが適当なのか結構難しい。規格適合性の観点で見る出来具合は一部の側面でしかない。

ＩＳＭＳ的な構造を持って活動をしていれば規格には適合していることになる。空回りをしていても、ＰＤＣＡ的な構造を実現していればＯＫというのは少し変ですが審査は通ってしまいます。

書式より中身。当然ですがなかなか出来ていない。皆が馬鹿にしてきたＴＱＣに真剣になったのが英国。第三者認証制度なんてデミング賞のシステム化、ビジネスモデル化に過ぎない。

癒着の構図

• 促成栽培よろしく促成認証取得をコンサルは企業にアプローチ。
• 企業はコンサルの実績を見て提案に乗ってしまう。
• コンサルのテンプレートは促成栽培用だから文書の形は揃っているが、実運用に耐えるものではない。
• コンサルは一方で、顧客の紹介を審査機関に対して行う。営業だね。
• 審査機関は、営業は弱いからコンサルに頼る。コンサルに対して依存関係を持ってしまう。結果、コンサルの顔を立てようと図る。
• それがコンサルの付け目･ねらい目。促成栽培テンプレートでの認証取得を実現する。
• 審査機関の言い訳は、ＰＤＣＡを回して徐々に適正な形にすればよいと言うもの。
• 企業（客）の言い分は、取り合えず認証を貰うことが先決。中身は徐々にやればよい。
• コンサルはさっさと一件落着させて貰うものを貰えばよい。適正化は徐々に少しずつ儲けさせてもらえばよい。実際に適正化できるかどうかは企業（客）次第で責任はない。

-

• 可愛そうなのは企業（客）側。１００のお金を毎年入れて１０の効果しか得られない。テンプレートが悪いからやり直すしかないが、悪質コンサルを抱えている限りは、やり直しも出来ない。３年目で気付かなければ企業の経営者もそれなりと言う事だね。
  

コンサルタント

コンサルタントの問題

• 審査中にいきなり横槍を入れてくるコンサルタントがいた。審査妨害だ。「こんな審査は見たこと無い」と審査員に罵声を浴びせる。「お客がこうだといっているんだから文句を付けるな」と高圧的に審査員に大声で怒鳴りだす。
• コンサルをしていて客に言ったことの不適切性を露呈されるのが怖くて必至で頑張ったのだろうが全く審査を理解していない行為だ。コンサルとして失格を自分で宣言したようなもの。
• なりふり構わず認証取得をやろうとしている。
  
• コンサルは企業（客）と審査機関の間に入ることで、利益を得ようとしているが、それが行き過ぎた時のコンサルと審査機関の癒着の構図もうっすらと見えてくる。
• ＪＩＰＤＥＣが監視すべきことであるが、ＪＩＰＤＥＣにそれを期待することは出来ない。
  

審査計画：経営者インタビュー

審査計画の中で経営者インタビューは最重要なセッションです。

どういうISMSを構築しようとしているか、背景、狙い、着手、覚悟、等々を踏まえての方針と方針管理を確認する場ですから、このインタビュー結果を踏まえて、審査は実施される必要があります。

規格適合性の審査ですが、規格は経営者方針に従えともある訳ですから、経営者の意思を正しく理解していないと、審査自体の適切性に問題が出ます。

審査計画では、従って、第１段階のどこかと言うより、基本方針の確認のときに経営者インタビューを行うのがもっとも自然なやり方です。

ただ、多くの場合は、残念ながら第１段階の時点では基本方針自体がまとまっていないので、やむなく第２段階の最初に行うのです。

審査員

審査員を観るのにいろいろな要素・角度から評価しようとする。返って本質を見失う。

組織のISMSが持つ本質問題を的確に見抜いて客観的に明らかにする能力。これが大事。事前にどんな準備をしたか、マナーがどうであったか、コミュニケーションがどうかなどは二次的、三次的な低次元の問題。それらを横並びにして評価すると、礼儀正しいだけの能無し審査員が誕生する。

591-016-300

-client

• 何と言うのだろうね。人貸し業。分かりにくい関連会社を並べて。一括で認証取得。

-consultant

• 質の悪いコンサルだ。審査機関を食い物にする。
  

-system

• リスクアセスメントのロジックは出来ているが、中身がひどい。フリーソフトの機密性が最高機密レベルとか。資産価値の識別が出鱈目。
• リスク評価は各部署でやらないで本部一括。脅威も脆弱性も本部一括評価。かなり乱暴。出鱈目。リスク値を本部で出して対応策も本部で決めて、現場には「セキュリティの心得」みたいな冊子が配られてお仕舞い。
• だから現場はリスク値も知らないし、リスク対応策の存在も知らない。脅威、脆弱性の変化点も把握できないし、報告する先も無い。全部本部がやるんだから。
  

-auditor

• ひどい審査計画。
  ①サイト審査の手順が稚拙で長距離を2往復する。新幹線で3時間以上の距離。手順を少し変えれば行ったり来たりは発生しない。顧客との折衝能力も無いのだろう。
  ②地方なのに朝の開始時間が9時半。終了時間もずれて移動に無理が出る。報告も遅れることになる。9時開始にすれば無理なく一日が使える。
  ③日によってはお昼の時間も取ってない。どこかで手を抜くことになる。下手なスケジューリングは審査の質を落とす。
  ④審査計画の文書もペラもの1枚に3人3日を入れ込んで済ませている。
• ひどい審査計画（続き）
  ⑤本人はなんと初日東京で部門審査。自分だけミニマム移動で済ませている。恐れ入る。
  ⑥トップインタビューは最終日。事務局審査も最終日。トップ、事務局の状況確認を最後にやってどうするんだろう。
  ⑦メンバーの最終日も多くの部署、しかも広島本部のメイン部署の多くを最終日に回している。纏める気があるのか。
• 驚いたね。苦手だね。２日目終了後に同じホテルに入って確認の電話は貰ったが、普通は２日間の状況を確認して落としどころを探るものだけど、明朝の集合時間を確認するだけで、ご自身はお出かけ（接待？）だとか。二流人の振る舞いは徹底している。いよいよ穴が見えてきた。
• そもそも第１段階審査の結果が何もフィードバックされないのはどういうことだ。こいつ、完全な素人か、仕事をなめているか、パートナーをなめているか。兎にも角にも、どうしようもない奴な可能性が高いね。
• 本質問題：リスクアセスメントからリスク対応計画への下りの問題に指摘が入っていない。詰まらない内容の指摘ばかり。リーダーとしては全く不十分。メンバーの指摘も意味不明なものが混じる。其れに対する事前検討も不十分なままレポートに載せる。
• コンサルと癒着したようなリーダー。審査中に一緒に食事している。酷いね。
  

591-007-203

-

• マルチメディアコンテンツ制作配信

-

• 内部監査の有効性が極めて低い。ＩＳＭＳ推進担当者の領域だけで、実施して指摘を出している。一般部署には指摘ゼロ。内部監査のエビデンスは集計したサマリー表のみ。
• インシデント、弱点の報告もない。
• ＩＳＭＳの有効性はかなり低い。形式を最低限のレベルで踏んでいるだけ。

-

• 人格が疑われる。
• 自分が決めた時間に現れない。１５分以上遅刻。連絡もしてこない。こちらから携帯に電話しても出ない。遅れて現れて謝罪もない。翌日もまた時間を指定しておいて遅刻。１０分遅刻。携帯に電話をくれたらしいが、既に遅刻の時間。審査時間も、クロージングも全て後ろにずれずれ。
• そもそも客先のビルの１階で待ち合わせるのに２０分も前を指定するものか。何かは無しがあるのだろうと思って早めに行ったら飛んでもない食わせ物だった。
  
• 審査計画は最新版を送って寄越さない。って言うか自分自身が古い計画を持ってきている始末。
• 未だに古いレポート様式を利用。
• トップインタビューでも関係のない話を延々。しかも、業界の知識が無さ過ぎるから話も噛み合っていないまま。勿論、たっぷり時間オーバー。
• 会社の悪評を一人で背負っているくらいに酷い。
  

590-911-103

-

• 検針業務委託

-

• もっともリスクが高い領域を適用範囲に入れていない。本社の統括機構だけを適用範囲にしている。大勢のアルバイト、頻繁に入れ替えのあるアルバイトを抱え、検針結果収集される個人情報が溢れ返っている各地の営業部門は除外している。
• リスクアセスメントの有効性が低い。資産価値の識別が２段階しかなく、社外秘、機密などの実運用のレベル分けを反映していない。
  

-

• 本質を外したまま何年も同じ審査を続けているので、正しい態度とは言い難い。規格に反している可能性もある。緩み過ぎ。
  

0809014305

-

• 技術者派遣事業
• マルチサイト：全国カバー

-

• 派遣事業に共通の傾向として適用範囲設定に無理がある。人・組織、情報資産、エリアのどれを取っても管理責任は不明確。
• 脅威・脆弱性の見直しを各部署でどのように実施しているか確認できない。部署ごとのプロセスや環境の変化を認識してリスクアセスに取り込む仕組みが無い。
• 事務局主導だと現場の自立性が育たないのに、現場の自立を促す取り組みが弱い。
• 現時点では、世の中の水準よりは高いレベルにある。
  

-

• 特定の人に移動時間のしわ寄せが来る下手なスケジューリング。
• チーム待ち合わせ場所を間違えて連絡するし、間違いに気付いてもメンバーを呼びつける無作法を平気でやる。客先までの道もよく間違える。
• クロージングは遅れて開始、遅れて終了。
  

590-929-403

-

• コンピュータ業界

-

• リスクアセスメントはリスク値の自動集計に拘ったロジックとしているため、現場の人の感覚と整合しない。特に、脅威・脆弱性を標準要素の有無・多少だけで算出しているので、現場固有の状況が反映できない。簡易ロジックは全体を俯瞰するには良いが、個々に手を打っていくためには脅威脆弱性を特定させることが必要。
• 内部監査による指摘が殆ど出ていない。有効性が低い。
• インシデント、弱点の収集も積極的にやっていない。
• 部署審査では部門長の応対が極めて少なく、ＩＳＭＳ（事務局）のポジション低下が窺える。
• 業務委託で入り込んでいる外部の人を適用範囲に入れていない。かと言ってインタフェースの管理策が出来ている訳でもない。穴が開いている可能性が高い。
• 時間にルーズな人が非常に多い。定刻に来る人は少なくバラバラ人が集まる。
  

+

• パソコンのセキュリティポリシーでＵＳＢを利用できないようにしている。
  

-

• やや時間にルーズ。
• 待ち合わせ場所などの事前確認などコミュニケーション取りにもやらない。
• 審査計画が初日の前々日まで出てこないのも論外。
  

591-010-102

- Client

• マルチメディア広告の制作。
• ３サイト。
  
• 切り替え審査。

- System

• 資産台帳が棚卸し表になっていない。只の分類表に近くて、資産との対応が付かない。
• 脅威・脆弱性がＣＩＡのどの特性に対するものか識別されていない。脅威・脆弱性のレベルの根拠が不明確。
• 内部監査、インシデント、弱点などの報告が殆ど出ていない。リスクも全て受容レベルに収まっており、ＰＤＣＡを回すエンジンが止まっている。
• 経営者は完全にＩＳ管理責任者に依存する発言があり、経営者の責任を果たしているかどうか疑問。
• 出先サイトでは被審査部門の担当者が遅刻する始末で、ＩＳＭＳとしては既にデッド状態。
  

- Auditor

• その審査機関・審査員は、審査の後で大量の情報提供を要求してきた。審査報告は数枚のペラだったが、判定委員会に掛けた結果の報告書はバインダー1冊に相当する分厚いものだった。
• その審査機関・審査員は、リスクアセスの基本を間違えていて論外。
  

590-925-203

- Client

• 印刷業
• ２サイト

- System

• とても妙なことに、脆弱性のレベル分けが、１，２，３の3段階から、いつの間にか、0.5と言うレベルが誕生していた。
• 0.5が存在するなら0.0も存在するのかな。リスク値計算の基礎。確率計算の世界に居ることを忘れている。
• 資産価値が大きい場合はどんなに管理策を充実させても、脅威は残るから、脆弱性をミニマムにしてもリスク値は大きくなる。そのことを避けたいため、不思議な細工をしたようだ。
• その背景としては、受容レベルを１２に設定していたのに、全ての資産が１２以下に収まったら、今度は６以上に対して施策をトップが要求したことがある。受容レベルと言う数字だけを勝手にトップが弄ったため、不自然な歪みが出ることになった。
• トップの意志が強く、事務局・推進委員は積極的な取り組みをしているが、現場とギャップが
  

- Auditor

• 歪んだ運用に対して適切な審査コメント（苦言・助言・指導）を残していない。
  

SeeSaa : GOLDRA

http://goldra.seesaa.net/

http://shoebill.seesaa.net/

http://cockpit.seesaa.net/

http://nana2005.seesaa.net/

アボカド料理のレシピ

アボカドを始めて食べた時は大変だった。食べ方が先ず分からない。茹でてみたり焼いてみたり炒めてみたり。その内にようやく何もしないで待てばいいのが分かる。アボカドウイズソウルは美味しかった。