2008年03月10日
経済産業省は不祥事が相次ぐ中でのISOの信用回復に動き始めた。ということに成るかな。JAB等の国際規格運用を厳格化することで要請が入るだろう。
効率一辺倒の今の審査を見直すチャンスでもある訳だが、審査機関の過当競争にどのように歯止めを掛けるかが問題。
実は極めて簡単です。
サイトに掛ける審査工数を、増やすようにガイドすることです。サイトが分散しても纏めて見積もってしまうこと（そのほうが安くなるからですが）を戒める。
規格の厳格な運用とか型どおりに言っているだけでは、結局問題は見過ごされる。経産省に識人がいないから既存の枠組みを好む勢力に適当にごまかされてしまうかもしれないが、この単純な本質に入ってこないと目的は達成できない。
続きを読む ...
効率一辺倒の今の審査を見直すチャンスでもある訳だが、審査機関の過当競争にどのように歯止めを掛けるかが問題。
実は極めて簡単です。
サイトに掛ける審査工数を、増やすようにガイドすることです。サイトが分散しても纏めて見積もってしまうこと（そのほうが安くなるからですが）を戒める。
規格の厳格な運用とか型どおりに言っているだけでは、結局問題は見過ごされる。経産省に識人がいないから既存の枠組みを好む勢力に適当にごまかされてしまうかもしれないが、この単純な本質に入ってこないと目的は達成できない。
続きを読む ...
2007年11月02日
外に持ち出せば、忘れるか、奪われるか、破損させるかして、結局のところ失うことになる。
http://www.asahi.com/national/update/1102/TKY200711020112.html?ref=rss
後を絶たない。
・出かけても持ち出さない。
・出かけない。
会議は最先端の電話会議、テレビ会議。専門の宅配業者。
*
肌身離さず！ ウエラブルですか？ まず無理ね。
*
逆転の発想�
なくしても大丈夫。超暗号化。
*
逆転の発想�
ネット上に預けっぱなしにしておいて必要時に鍵で開けて見るだけにする。本当に大事な資料は置けない。所詮仕事レベルは置ける。安全なインターネット環境を準備し、社員はシンクライアント相当のマシンを持ち出して、必要時にアクセスして利用する。シームレス・セキュリティ。社内も社外も同じインフラ。イントラ・インターネット環境。会社の情報部門が構築するのが普通と考えがちだ
が、そんなノウハウは企業情報システム部門にはない。だから、ＫＤＤＩ、ニフティ、グーグル、ＩＢＭなどに委託することになる。モバイル端末も社内社外
シームレス仕様になるだろう。
端末（ハンディ多機能端末）、バイオ、ＰＩＮ（暗証コード）。端末はＩＤ付き（ノード認証付き）プラス位置情報付き。位置はゾーンセキュリティを社内社外でダイナミックに設定する。
最近多いＩＣ付きＩＤカードは単独では、其のカードを奪われればアウト。他と組み合わせればセキュリティは上がるが、ベストパートナーとして生き残る可能性は小さい。ＰＫＩ署名情報を格納していても、それは端末に入れれば済むこと。
ＩＣカードはただのパッシブなツールでシームレス管理には向かない。アクティブツールの端末であること。電話の届かないところでは、モバイルシンクラも使えないから。
ローカルに蓄えた情報は認めない。認める場合は自然揮発型（時間経過ＯＲ再起動の早いタイミングで自動消去）。
「モバイルシンクラ（ノード）+多機能端末（ノード+位置）+バイオ+ＰＩＮ」の全てが揃って始めて利用可能。
如何？
http://www.asahi.com/national/update/1102/TKY200711020112.html?ref=rss
後を絶たない。
・出かけても持ち出さない。
・出かけない。
会議は最先端の電話会議、テレビ会議。専門の宅配業者。
*
肌身離さず！ ウエラブルですか？ まず無理ね。
*
逆転の発想�
なくしても大丈夫。超暗号化。
*
逆転の発想�
ネット上に預けっぱなしにしておいて必要時に鍵で開けて見るだけにする。本当に大事な資料は置けない。所詮仕事レベルは置ける。安全なインターネット環境を準備し、社員はシンクライアント相当のマシンを持ち出して、必要時にアクセスして利用する。シームレス・セキュリティ。社内も社外も同じインフラ。イントラ・インターネット環境。会社の情報部門が構築するのが普通と考えがちだ
が、そんなノウハウは企業情報システム部門にはない。だから、ＫＤＤＩ、ニフティ、グーグル、ＩＢＭなどに委託することになる。モバイル端末も社内社外
シームレス仕様になるだろう。
端末（ハンディ多機能端末）、バイオ、ＰＩＮ（暗証コード）。端末はＩＤ付き（ノード認証付き）プラス位置情報付き。位置はゾーンセキュリティを社内社外でダイナミックに設定する。
最近多いＩＣ付きＩＤカードは単独では、其のカードを奪われればアウト。他と組み合わせればセキュリティは上がるが、ベストパートナーとして生き残る可能性は小さい。ＰＫＩ署名情報を格納していても、それは端末に入れれば済むこと。
ＩＣカードはただのパッシブなツールでシームレス管理には向かない。アクティブツールの端末であること。電話の届かないところでは、モバイルシンクラも使えないから。
ローカルに蓄えた情報は認めない。認める場合は自然揮発型（時間経過ＯＲ再起動の早いタイミングで自動消去）。
「モバイルシンクラ（ノード）+多機能端末（ノード+位置）+バイオ+ＰＩＮ」の全てが揃って始めて利用可能。
如何？
2007年10月26日
フォレンジックと言う聴きなれない言葉に出会うが直ぐに忘れてしまう。
「法的に有効な手段で過去に発生した事象を立証することが可能になる」ことがらかな。
改ざんが行なわれた、アクセスがあった、メールが送られた、などの情報システムの利用に関わる事象を合理的に証明可能とする活動が、多分、デジタル・フォレンジックかな。
法的な問題が発生した時に、確実に相手（加害者）を訴えることが出来る、あるいは、訴えられた時に抗弁できる材料として用意すること。
近頃、電話をすると証拠のために録音しますとメッセージが出ることがある。これは変ないたずら電話などは防止できてしまう。
ところで、証拠を集めまくった時に、自分に非がある材料も集めてしまう。この場合、隠蔽・隠匿しても良いのかな？
「法的に有効な手段で過去に発生した事象を立証することが可能になる」ことがらかな。
改ざんが行なわれた、アクセスがあった、メールが送られた、などの情報システムの利用に関わる事象を合理的に証明可能とする活動が、多分、デジタル・フォレンジックかな。
法的な問題が発生した時に、確実に相手（加害者）を訴えることが出来る、あるいは、訴えられた時に抗弁できる材料として用意すること。
近頃、電話をすると証拠のために録音しますとメッセージが出ることがある。これは変ないたずら電話などは防止できてしまう。
ところで、証拠を集めまくった時に、自分に非がある材料も集めてしまう。この場合、隠蔽・隠匿しても良いのかな？
2007年10月04日
ISO1007
「品質管理-構成管理の指針」と言うものらしい。構成管理って実はあまり馴染みがないので基本を押さえたいが、指針の中で構成管理の定義を以下のように行なっているらしい。
***/+/***
「構成管理とは，製品の構成を文書化するものである。構成管理は，ライフサイクルの全段階で，識別及びトレーサビリティ，その物理的及び機能的要求事項の達成状況並びに正確な情報へのアクセスをもたらす。構成管理は，組織の規模並びに，製品の複雑さ及び性質に基いて実施できる。構成管理は，ISO9001 に規定されている製品識別及びトレーサビリティ要求事項を満たすために使用することができる。」
***/+/***
これってとっても大変なこと。
しかし、意識していなくても都度開発現場でやっていた。レベルはバラバラ。組織としての取組みは弱い。そうでもない。コンフィギュレーションマネジャーなんか置いていたりするから、商品開発ではしっかりやっている。問題は社内情報システムはもともとかき集め的な要素があるので、この辺のマネジメントは弱い。
だから、担当が変わるとこぼれる物もあったはず。
規格にするのはそれを許さない業界の姿勢。これは要求規格ではなくて規範規格だろう。
ISMSでは、17799の12.4.3.の実現の時に記載（宣言）してしまえば要求規格になる。ただ、12.4.3はプログラムソースコードのアクセス制御の切り口での要求なので構成管理全体の要求に答えるものではない。
*
構成管理と変更管理の整合化：
構成管理と変更管理はものの本をつまみ読みするとどうも上下がはっきりしない。一度ここで関連を整理しておきたい。
今の変更管理はシステム変更というイベント（プロジェクト）を立上げ・実施し・完了させるための手順を明確にすることに主眼が行っている。承認プロセス
である。正しい要求を正しくレビューし実行し確認する。
一方、構成管理は、システムのライフサイクルを通じて、構成内容（構成方法、環境、パフォーマンス、不具合などシステムを確実に実現させるために必要な一切の情報を含む）を管理するもの。
変更イベントの出発点と終了点の間の手順は変更管理、出発点の状況と終了点の状況の管理は構成管理のスパンと理解して良さそうだ。ストックとフローの関係のイメージで宜しいかと。
***/+/***
構成管理は、システムをターミネートしてから一定期間保管する。構成管理のスタートポイントは遅くとも最初にシステムインテグレーションを行なうシステムテストの段階から始めなければならない。
構成管理の担当者は構成（インテグレーション）を識別し、システムの各バージョンの構成の内容を台帳で管理すること。
不具合対応時に参照する性格のものであるため、台帳は容易に参照できるように考慮すること。
システム主管はシステムの構成管理を行なうとともに、その内容を構成管理統括担当提出すること。構成管理統括担当はシステムのシステムテスト開始からターミネートまで構成管理データの保管を行なうこと。
構成管理としては以下の内容を含めること。システムの特性により適宜追加すること。
・システム名、システムインテグレーション識別名
・文書構成：文書名、版番号、発効日・改定日
・ソフトウエア構成：プログラムタイトル、ファイル名、バージョン、日付
・ハードウエア構成：
・ネットワーク構成：
文書には設計書・手順書・テスト結果・不具合情報・前バージョンとの差異などシステムの機能的・物理的特性の管理に関するもの一切を含める。
構成管理情報の改ざんが行なわれると、トラブル時のトレースあるいはシステム変更が正しく出来ない。構成管理の独立した担当が望ましいが、兼務でやる場合は、結果を構成管理統括担当に提示し、他による改ざんが出来ない手当てが必要である。
***/+/***
（規則案）
上記でいいだろうか。
各システムの主管は、システムの構成管理を行なうこと。バージョンの変更が生じた時は、その構成を明確にし、全バージョンとの差異を容易に理解できるようにすること。
***/+/***
「品質管理-構成管理の指針」と言うものらしい。構成管理って実はあまり馴染みがないので基本を押さえたいが、指針の中で構成管理の定義を以下のように行なっているらしい。
***/+/***
「構成管理とは，製品の構成を文書化するものである。構成管理は，ライフサイクルの全段階で，識別及びトレーサビリティ，その物理的及び機能的要求事項の達成状況並びに正確な情報へのアクセスをもたらす。構成管理は，組織の規模並びに，製品の複雑さ及び性質に基いて実施できる。構成管理は，ISO9001 に規定されている製品識別及びトレーサビリティ要求事項を満たすために使用することができる。」
***/+/***
これってとっても大変なこと。
しかし、意識していなくても都度開発現場でやっていた。レベルはバラバラ。組織としての取組みは弱い。そうでもない。コンフィギュレーションマネジャーなんか置いていたりするから、商品開発ではしっかりやっている。問題は社内情報システムはもともとかき集め的な要素があるので、この辺のマネジメントは弱い。
だから、担当が変わるとこぼれる物もあったはず。
規格にするのはそれを許さない業界の姿勢。これは要求規格ではなくて規範規格だろう。
ISMSでは、17799の12.4.3.の実現の時に記載（宣言）してしまえば要求規格になる。ただ、12.4.3はプログラムソースコードのアクセス制御の切り口での要求なので構成管理全体の要求に答えるものではない。
*
構成管理と変更管理の整合化：
構成管理と変更管理はものの本をつまみ読みするとどうも上下がはっきりしない。一度ここで関連を整理しておきたい。
今の変更管理はシステム変更というイベント（プロジェクト）を立上げ・実施し・完了させるための手順を明確にすることに主眼が行っている。承認プロセス
である。正しい要求を正しくレビューし実行し確認する。
一方、構成管理は、システムのライフサイクルを通じて、構成内容（構成方法、環境、パフォーマンス、不具合などシステムを確実に実現させるために必要な一切の情報を含む）を管理するもの。
変更イベントの出発点と終了点の間の手順は変更管理、出発点の状況と終了点の状況の管理は構成管理のスパンと理解して良さそうだ。ストックとフローの関係のイメージで宜しいかと。
***/+/***
構成管理は、システムをターミネートしてから一定期間保管する。構成管理のスタートポイントは遅くとも最初にシステムインテグレーションを行なうシステムテストの段階から始めなければならない。
構成管理の担当者は構成（インテグレーション）を識別し、システムの各バージョンの構成の内容を台帳で管理すること。
不具合対応時に参照する性格のものであるため、台帳は容易に参照できるように考慮すること。
システム主管はシステムの構成管理を行なうとともに、その内容を構成管理統括担当提出すること。構成管理統括担当はシステムのシステムテスト開始からターミネートまで構成管理データの保管を行なうこと。
構成管理としては以下の内容を含めること。システムの特性により適宜追加すること。
・システム名、システムインテグレーション識別名
・文書構成：文書名、版番号、発効日・改定日
・ソフトウエア構成：プログラムタイトル、ファイル名、バージョン、日付
・ハードウエア構成：
・ネットワーク構成：
文書には設計書・手順書・テスト結果・不具合情報・前バージョンとの差異などシステムの機能的・物理的特性の管理に関するもの一切を含める。
構成管理情報の改ざんが行なわれると、トラブル時のトレースあるいはシステム変更が正しく出来ない。構成管理の独立した担当が望ましいが、兼務でやる場合は、結果を構成管理統括担当に提示し、他による改ざんが出来ない手当てが必要である。
***/+/***
（規則案）
上記でいいだろうか。
各システムの主管は、システムの構成管理を行なうこと。バージョンの変更が生じた時は、その構成を明確にし、全バージョンとの差異を容易に理解できるようにすること。
***/+/***
JIS X 0160 あまり目にしたことのないナンバーです。ネットで見ると国際規格「ISO/IEC 12207：1995 Information technology - Software life cycle process」を日本語に翻訳したものとのこと。１９９６年発行ってその後の見直しはどうなっているのか知らん。
◆
・取得プロセス
・供給プロセス
・開発プロセス
・運用プロセス
・保守プロセス
これが普通の開発運用のフェーズ。
◆
・文章化プロセス
・構成管理プロセス
・品質保証プロセス
・検証プロセス
・妥当性確認プロセス
・共同レビュープロセス
・監査プロセス
・問題解決プロセス
これは支援プロセス又は管理プロセスですね。これもプロジェクト単位のプロセス。
◆
・管理プロセス
・環境整備プロセス
・改善プロセス
・教育訓練プロセス
・修正プロセス
マネジメントプロセス。年度計画のイメージですね。組織単位のプロセスと見てもいいかな。
◆
今更、規格を読む気にもならないが、今まで特に困ることもなかったから無視していいのかな？
◆
・取得プロセス
・供給プロセス
・開発プロセス
・運用プロセス
・保守プロセス
これが普通の開発運用のフェーズ。
◆
・文章化プロセス
・構成管理プロセス
・品質保証プロセス
・検証プロセス
・妥当性確認プロセス
・共同レビュープロセス
・監査プロセス
・問題解決プロセス
これは支援プロセス又は管理プロセスですね。これもプロジェクト単位のプロセス。
◆
・管理プロセス
・環境整備プロセス
・改善プロセス
・教育訓練プロセス
・修正プロセス
マネジメントプロセス。年度計画のイメージですね。組織単位のプロセスと見てもいいかな。
◆
今更、規格を読む気にもならないが、今まで特に困ることもなかったから無視していいのかな？
2007年09月11日
ＩＳＭＳを部分的に取得してから、漸次拡大は普通のシナリオですが、注意すべきことがあります。
先行して”作ってしまった”ＩＳＭＳに拘ると失敗します。
一言で言えば、適用範囲の特性に見合ったＩＳＭＳでないものを無理やり当てはめる懸念があるということです。
腕力が十分あれば別ですが、普通は拡大すると、どうでも良い部署も取り込みますから、最初のＩＳＭＳが必ずしも適当でありません。一端、最初のものを捨てるくらいに考えないと失敗します。これも、審査機関〜審査員が下手だと最初に作ったものに拘って是正が効きません。事務局も作り直しは普通嫌がります。
でも作り直しが一番まともで理にかないます。
この簡単なことに気付く組織は少なくありません。手間を惜しむと高く付くというより、お仕着せのＩＳＭＳではＰＤＣＡは回りません。事務局だけが体裁を取り繕って空回りさせている無意味なＩＳＭＳになります。
先行して”作ってしまった”ＩＳＭＳに拘ると失敗します。
一言で言えば、適用範囲の特性に見合ったＩＳＭＳでないものを無理やり当てはめる懸念があるということです。
腕力が十分あれば別ですが、普通は拡大すると、どうでも良い部署も取り込みますから、最初のＩＳＭＳが必ずしも適当でありません。一端、最初のものを捨てるくらいに考えないと失敗します。これも、審査機関〜審査員が下手だと最初に作ったものに拘って是正が効きません。事務局も作り直しは普通嫌がります。
でも作り直しが一番まともで理にかないます。
この簡単なことに気付く組織は少なくありません。手間を惜しむと高く付くというより、お仕着せのＩＳＭＳではＰＤＣＡは回りません。事務局だけが体裁を取り繕って空回りさせている無意味なＩＳＭＳになります。
2007年09月07日
「一つのマネジメントシステム」
ＩＳＯ９０００から始まって、ＩＳＯ１４０００、ＩＳＯ２７０００と来て、今後もどんどんマネジメントシステムの認証制度が出てくる見込みですが、一体、いつまで？どこまで？やれば気が済むのでしょうね。
認証ビジネスのために、あれもこれも振り回されているのか、それだと困ったものです。
実際に、世の中で問題が出て、其れへの対応が不十分だから、個別に専門的に対応している。これは、何かを運用を誤ったからです。認証制度がビジネス的にメリットする人は構わず広げていったですが、流石に過ちに気が付いて、今度は統合マネジメントを言い始めた。最悪ですね。恥の上塗りみたいなもの。問題を更に悪くしている。
ＩＳＯ９０００から始まって、ＩＳＯ１４０００、ＩＳＯ２７０００と来て、今後もどんどんマネジメントシステムの認証制度が出てくる見込みですが、一体、いつまで？どこまで？やれば気が済むのでしょうね。
認証ビジネスのために、あれもこれも振り回されているのか、それだと困ったものです。
実際に、世の中で問題が出て、其れへの対応が不十分だから、個別に専門的に対応している。これは、何かを運用を誤ったからです。認証制度がビジネス的にメリットする人は構わず広げていったですが、流石に過ちに気が付いて、今度は統合マネジメントを言い始めた。最悪ですね。恥の上塗りみたいなもの。問題を更に悪くしている。
ＩＳＭＳを始めようとすると、手始めに問題になるのがリスクアセスメント。特に、変な審査機関というか審査員にぶつかると、ただのリスクアセスメントでは収まらず最悪。所謂、潔癖症症候群の審査員先生です。ＰＤＣＡが回り始める前に息絶えます。この手の先生を素早く見抜いて、さっさと忌避できれば、深手の傷を負わずに済みますが、その見抜く方法は、適用範囲の確認のときに簡単に出来ます。リスクアセスの結果が適用範囲の記述に反映しているようなことを期待している節を見せる審査員先生は要注意と言うか即忌避ですね。
意味の無いリスクアセスメントになるのは、全点網羅型の資産台帳が出発点で
す。潔癖先生の言い分は、どのように重要な資産を洗い出したかを明確に！ですが、全ての失敗はここから始まります。そこが潔癖先生ならではです。
ではどうするか。
取り敢えず重要と思われるもの。そのカテゴリーあるいは定義を先に決めてしまう。方針の一環として、プロセス特性に応じた内容でも共通のものでも構わな
い。適用範囲を拡大しながら進めるときは、成長に応じて識別要求を区分しても構わない。
一気にやって負荷を掛けないこと。少しずつ進める。トップを諌める。急発進・急ブレーキは怪我の元。
それでも、意味の無いリスクアセスメント
それは既に分かっていることしか分からないと言う現実です。リスクアセスメントと言う形を記録で作っても、新たな発見は殆んど有りません。それはリスクアセスメントのスキームがそうなっているからです。即ち、リスクアセスメントでは既に認識できている脅威・脆弱性を並べる訳で、新しいものは殆んどの場合ありません。最初から問題と分かっているものを単にリスク評価シート等の構造図上に展開したに過ぎないからです。
トップの「四の五の分析なんかやってないで、さっさと対策してよ」になる訳です。
身体で感じているリスクを文書・記録にする作業だと割り切れば、負担も無く
さっさと出来ます。
「リスクアセスメントとは、未知のリスクを発見する手順でなく、既知のリスクを構造的にあるいは定量的に理解する手順」
網羅性の呪縛から漸く抜け出ることが出来ます。
ではリスクはどこで認識されるか。通常の業務プロセスの中で認識できます。というより其処でしか本当のリスクは見えてこない。もっとも感性を磨く活動なんかは当然必要ですが、いずれにしても現場です。
意味の無いリスクアセスメントになるのは、全点網羅型の資産台帳が出発点で
す。潔癖先生の言い分は、どのように重要な資産を洗い出したかを明確に！ですが、全ての失敗はここから始まります。そこが潔癖先生ならではです。
ではどうするか。
取り敢えず重要と思われるもの。そのカテゴリーあるいは定義を先に決めてしまう。方針の一環として、プロセス特性に応じた内容でも共通のものでも構わな
い。適用範囲を拡大しながら進めるときは、成長に応じて識別要求を区分しても構わない。
一気にやって負荷を掛けないこと。少しずつ進める。トップを諌める。急発進・急ブレーキは怪我の元。
それでも、意味の無いリスクアセスメント
それは既に分かっていることしか分からないと言う現実です。リスクアセスメントと言う形を記録で作っても、新たな発見は殆んど有りません。それはリスクアセスメントのスキームがそうなっているからです。即ち、リスクアセスメントでは既に認識できている脅威・脆弱性を並べる訳で、新しいものは殆んどの場合ありません。最初から問題と分かっているものを単にリスク評価シート等の構造図上に展開したに過ぎないからです。
トップの「四の五の分析なんかやってないで、さっさと対策してよ」になる訳です。
身体で感じているリスクを文書・記録にする作業だと割り切れば、負担も無く
さっさと出来ます。
「リスクアセスメントとは、未知のリスクを発見する手順でなく、既知のリスクを構造的にあるいは定量的に理解する手順」
網羅性の呪縛から漸く抜け出ることが出来ます。
ではリスクはどこで認識されるか。通常の業務プロセスの中で認識できます。というより其処でしか本当のリスクは見えてこない。もっとも感性を磨く活動なんかは当然必要ですが、いずれにしても現場です。
2007年08月28日
ISO規格が複数出てきて微妙にカバー領域が重なる。気分が悪いので簡単に整理しておくことにした。
スタート：「組織の目的達成」が基本命題。
・目的が達成できる度合い＝リスクであることを考えるとRMS。
・目的達成の仕組み＝プロセス品質であることを考えるとQMS。
結果からのアプローチと手段からのアプローチの差で、基本命題を素直に受けている。
リスクは期待とのギャップであるが誰の期待かを考えた時に、経営者（組織）の期待とステークホルダー（経営者を含む全ての関与者）の期待の両方あるが、組織は誰のものかを踏まえれば後者の視点が求められる。CSR
その他の規格：BCMS、EMS、ISMS、ITSMS、・・・は特定問題に対する専門的な要求を取り込むための特定問題の側面のアプローチと見たほうが収まりが良い。
QMSは極めて汎用的な形で規格を設定できているが、RMSに相当する規格は明確でない。近いポジションはBCMSとかSRMS(CSRのISO26000。マルチステークホルダの概念：消費者まで含めて関与者が参加する経営のあり方も入って来ているのが特徴的)とか。SRMSは目的達成は全員ハッピーな形＝民主主義？で、それを脅かすものは全てリスクとする。？
事業継続は、まだサービスを提供する側の視点での捉え方。SRMSはサービスの受けての視点だから、結果管理に近いので、さらに信用とか印象とかまで入り込むことも有り得るので、結果指標としては今のところ最有力と考えて良さそう。ただ、SRMSが認証規格かガイドラインかは気になるが、数値化された結果指標として、誰の目にも明らかな達成度が公開されることになるであろうから、認証する必要すらないかもしれない。
尚、統合マネジメントシステムIMSは、単に枠組み上あるいは書式上の統一化であって、本質的な意味を持つものではないので、ここでの問題とは直接関係なさそうだ。
という事で、やはり、判定する側から見たら、QMSの審査〜プロセスの審査が、組織から見たら品質マニュアルの作り込みが大事というか必須ですね。
スタート：「組織の目的達成」が基本命題。
・目的が達成できる度合い＝リスクであることを考えるとRMS。
・目的達成の仕組み＝プロセス品質であることを考えるとQMS。
結果からのアプローチと手段からのアプローチの差で、基本命題を素直に受けている。
リスクは期待とのギャップであるが誰の期待かを考えた時に、経営者（組織）の期待とステークホルダー（経営者を含む全ての関与者）の期待の両方あるが、組織は誰のものかを踏まえれば後者の視点が求められる。CSR
その他の規格：BCMS、EMS、ISMS、ITSMS、・・・は特定問題に対する専門的な要求を取り込むための特定問題の側面のアプローチと見たほうが収まりが良い。
QMSは極めて汎用的な形で規格を設定できているが、RMSに相当する規格は明確でない。近いポジションはBCMSとかSRMS(CSRのISO26000。マルチステークホルダの概念：消費者まで含めて関与者が参加する経営のあり方も入って来ているのが特徴的)とか。SRMSは目的達成は全員ハッピーな形＝民主主義？で、それを脅かすものは全てリスクとする。？
事業継続は、まだサービスを提供する側の視点での捉え方。SRMSはサービスの受けての視点だから、結果管理に近いので、さらに信用とか印象とかまで入り込むことも有り得るので、結果指標としては今のところ最有力と考えて良さそう。ただ、SRMSが認証規格かガイドラインかは気になるが、数値化された結果指標として、誰の目にも明らかな達成度が公開されることになるであろうから、認証する必要すらないかもしれない。
尚、統合マネジメントシステムIMSは、単に枠組み上あるいは書式上の統一化であって、本質的な意味を持つものではないので、ここでの問題とは直接関係なさそうだ。
という事で、やはり、判定する側から見たら、QMSの審査〜プロセスの審査が、組織から見たら品質マニュアルの作り込みが大事というか必須ですね。
2007年07月30日
ISO関連の規格を見ると良くお目にかかる用語に「Organization」と「Management」がある。「Organization shall ...」とか「Management shall...」とか。日本語化された規格では同じ意味で使われている様に見えることがある。どの規格の何処とは思い出せないから、解説していた人または書物の問題かもしれない。
ここでは直訳で「組織」と「経営者」と読み替えてみる。其の方が現実的で正しいからです。問題は意味することの理解です。
「組織はレビューをすること」とある場合は、組織の役割責任、あるいは組織の活動計画に、レビューの項目が入っていることを要求します。計画的に内部監査が行なわれることなどが該当します。
「経営者はレビューをすること」とある場合は、経営者によるレビューですか
ら、組織レビューも一切を含めて、経営者自身によるレビューが実施されることが要求です。
もっと難しいのはマネジメントがあちこちで使われていること。
ここでは直訳で「組織」と「経営者」と読み替えてみる。其の方が現実的で正しいからです。問題は意味することの理解です。
「組織はレビューをすること」とある場合は、組織の役割責任、あるいは組織の活動計画に、レビューの項目が入っていることを要求します。計画的に内部監査が行なわれることなどが該当します。
「経営者はレビューをすること」とある場合は、経営者によるレビューですか
ら、組織レビューも一切を含めて、経営者自身によるレビューが実施されることが要求です。
もっと難しいのはマネジメントがあちこちで使われていること。
2007年07月28日
JIPDECの県別ISMS認証取得事業者数の表はいつ見ても変。間違っている。この表を作った人は日本人じゃないね。そうか超偏見の持ち主。公共の仕事に携わるのは止めた方が良いと思いますが、如何でしょうか。
従来の分け方を無視してやるとデータの意味が変わってしまう。さっさと普通に戻しなさい。関東、中部、近畿の区分ぐらい理解してからやって欲しいね。要するに中部をまるで分かっていない。中部甲信越、中部北陸とあってここから外すのは山梨だけです。後は全部中部です。
顔が東京向いたら全部関東にしているようですが、そう言うことをしたら、沖縄も北海道も関東になりますね。分けている意味が無いでしょう。
関東から３つ、及び近畿から１つを外して中部に入れること。
従来の分け方を無視してやるとデータの意味が変わってしまう。さっさと普通に戻しなさい。関東、中部、近畿の区分ぐらい理解してからやって欲しいね。要するに中部をまるで分かっていない。中部甲信越、中部北陸とあってここから外すのは山梨だけです。後は全部中部です。
顔が東京向いたら全部関東にしているようですが、そう言うことをしたら、沖縄も北海道も関東になりますね。分けている意味が無いでしょう。
関東から３つ、及び近畿から１つを外して中部に入れること。
2007年07月11日
2007年06月13日
まだ噂だから本当のところは分からない。以前にも流れていた噂ですね。あの大手企業がＩＳＭＳを本格的に始めるらしい。グループ総がかりでの取り組みはチャレンジ。拍手。情報セキュリティなら当然とも言えるけどなかなかどうして出来ないこと。
がしかし、問題は選んだ審査機関でしょうね。例の規格の一字一句に拘ることで有名なところらしい。
周り回ってこちらにも来てくれたりしたら、勘弁ですわ。
思い出すだけで嫌になる。
はっきり言うてはた迷惑ですが。会社もやるのは構わんけど考えて欲しい。
まあ形式的で何もならんこと分かってから修正ですか？
幸さんが泣いてますよ。
がしかし、問題は選んだ審査機関でしょうね。例の規格の一字一句に拘ることで有名なところらしい。
周り回ってこちらにも来てくれたりしたら、勘弁ですわ。
思い出すだけで嫌になる。
はっきり言うてはた迷惑ですが。会社もやるのは構わんけど考えて欲しい。
まあ形式的で何もならんこと分かってから修正ですか？
幸さんが泣いてますよ。
2007年05月23日
功を焦った認証取得はどういう結果を招くか。ある人には耳の痛い話。
組織を切り刻んでの取得はよくある話。これは方向がまとまった組織全体への拡大を意識している限り問題にならない。
厄介なのはシステムを刻んだ場合。特定のシステムを適用範囲とした場合はやがて収拾が付かなくなる。
取得を急ぐ場合は特定プロジェクト、特定システムだけで安直に取得に走る。困ったことにそう言った事を焚き付けるのが審査機関ですから。始末が悪いのです。
功を焦ったのは審査機関ですからね。
そういうことに気付いたらさっさと返上すべきです。何の価値も無いだけでなく返って歪んだマネジメントになり組織に取って害となります。
組織を切り刻んでの取得はよくある話。これは方向がまとまった組織全体への拡大を意識している限り問題にならない。
厄介なのはシステムを刻んだ場合。特定のシステムを適用範囲とした場合はやがて収拾が付かなくなる。
取得を急ぐ場合は特定プロジェクト、特定システムだけで安直に取得に走る。困ったことにそう言った事を焚き付けるのが審査機関ですから。始末が悪いのです。
功を焦ったのは審査機関ですからね。
そういうことに気付いたらさっさと返上すべきです。何の価値も無いだけでなく返って歪んだマネジメントになり組織に取って害となります。
2007年05月22日
囲い込み戦略に使おうと各社が躍起になるなか、一歩リードしたのは圧倒的な檀家集団を抱える品質協会です。
サイトのオセロゲームでなく、規格ごとひっくり返すやり方だ。管理の基本の品質の檀家ベースを使って統合の名の下に環境もセキュリティーも取り込む算段ですね。
ＢＳＩはそのため又しても新たな規格作りに入る。ＰＡＳ９９がそれです。規格を作ったからと言って特にアドバンテージが有るわけではありません。
リーダーとフォロアー、その境が難しい。
サイトのオセロゲームでなく、規格ごとひっくり返すやり方だ。管理の基本の品質の檀家ベースを使って統合の名の下に環境もセキュリティーも取り込む算段ですね。
ＢＳＩはそのため又しても新たな規格作りに入る。ＰＡＳ９９がそれです。規格を作ったからと言って特にアドバンテージが有るわけではありません。
リーダーとフォロアー、その境が難しい。
2006年12月06日
滅多にないことだが外部インターフェイスを見ていて適用範囲外領域の問題を見つけて指摘する審査員がいます。審査員の経験不足が前提にあってのことですが、普通は所謂インターフェイスの管理策として適用範囲内の管理策の問題に視点を変えて問題の本質を確認します。
しかし始末の悪い審査員が加わるとしかもベテランの場合は悲惨です。一旦思い込んだら規格解釈の問題に土俵を換えてでも指摘を撤回することはありません。
ベテランで始末が悪い審査員はいえば札付きですから表に出てこないのですが、忙しい時期に借り出されて表にでてくるのです。
IＳＭＳの事務局は札付きが申請されたら拒否するのが大切な仕事ですね。
オフ会のオフ会では、その審査機関を選んだ段階で既にミスをしていると笑い者にされていた。
確かに。
打算で始めたIＳＭＳは打算の根拠が曖昧になった段階でいろいろな所を足掛かりに破綻していくものですね。
適用範囲外の指摘は是正確認のステップまで続くので審査の有効性はいよいよ妖しくなります。
審査機関によっては判定会議がありますがセレモニーに過ぎないし記録に残した物を変えることはまずありません。
適用範囲内の問題を指摘出来ない時はオブザベーションとするのが常識ですね。そして札付きを抱えて送り込むような審査機関を選ばないのも常識です。
数社の審査機関の人からそれとなく話しを聞けば直ぐ分かることです。それも出来ない人は事務局には向いていないかも知れませんね。
しかし始末の悪い審査員が加わるとしかもベテランの場合は悲惨です。一旦思い込んだら規格解釈の問題に土俵を換えてでも指摘を撤回することはありません。
ベテランで始末が悪い審査員はいえば札付きですから表に出てこないのですが、忙しい時期に借り出されて表にでてくるのです。
IＳＭＳの事務局は札付きが申請されたら拒否するのが大切な仕事ですね。
オフ会のオフ会では、その審査機関を選んだ段階で既にミスをしていると笑い者にされていた。
確かに。
打算で始めたIＳＭＳは打算の根拠が曖昧になった段階でいろいろな所を足掛かりに破綻していくものですね。
適用範囲外の指摘は是正確認のステップまで続くので審査の有効性はいよいよ妖しくなります。
審査機関によっては判定会議がありますがセレモニーに過ぎないし記録に残した物を変えることはまずありません。
適用範囲内の問題を指摘出来ない時はオブザベーションとするのが常識ですね。そして札付きを抱えて送り込むような審査機関を選ばないのも常識です。
数社の審査機関の人からそれとなく話しを聞けば直ぐ分かることです。それも出来ない人は事務局には向いていないかも知れませんね。
2006年10月21日
内部監査人資格ＣＩＡ
世界で六万人。
アイエスエムエスとは別物です。
世界で六万人。
アイエスエムエスとは別物です。
2006年10月09日
ある審査機関Ｊで聞いた話。半分嘘です。Ｊの神話。サーベイランスでは仕組みの問題に触れない。仕組みを初回で合格させているから仕組みの問題を指摘すると自分が見落としたことがあからさまになる。だから言えない。更新は三年後だからその時のは仕組みに触る事も言うらしい。二年目も三年目も同じデショ。根拠に乏しい。手抜きを容認させるためのただの言い訳ですね。
入口は規格と首っ引き。その後は枝葉末節でお茶を濁す。こんな認証貰っても有り難くも何でもない。
そもそも他人の判断で進めてお客さんに責任果たせますか、。
入口は規格と首っ引き。その後は枝葉末節でお茶を濁す。こんな認証貰っても有り難くも何でもない。
そもそも他人の判断で進めてお客さんに責任果たせますか、。
2006年10月05日
オフィスの移転、オフィスの引越し
そのような時にも情報セキュリティ問題は避けて通ることは出来ません。
情報セキュリティ問題に対処する基本は常にリスクアセスメントにあります。
１）先ずは、移動させる情報資産の洗い出しを行います。
・資産は引越し荷物ですから明確です。
・書類、メディア、パソコン/サーバー
・ケーブルとかディスプレィなどコンテンツに関係ないものは通常の引越しレベルで問題ないでしょう。
２）次に、脅威の洗い出しを行いますが、そのためには以下の状況・プロセスを押さえます。
・移動時の梱包形態
・取り扱い業者
・車両の特性
・運搬ルート
・当日中に作業が終わらなければ、何処で一泊させるか。
３）脅威・脆弱性
�輸送時の事故または不注意による破損（普通の引越しでも此れは確率が高い）
�大手企業の引越しの場合は大量のＯＡ機器を狙っての窃盗（あまり聞いたことは無いがリスクケースとして想定できる）
窃盗は輸送時と一時保管時が考えられる。
�紛失。小物のメディアが何かに紛れて紛失するケース。
�については、
・身元のしっかりした人であることを確認しておく。（確認してもらう）
・輸送時の一時預かり倉庫は鍵の施錠管理、２４時間守衛体制などを確認する。不足なら守衛を立てる。
・輸送車とオフィスの間にバッファをおく場合は見張りを付ける。
等の施策で十分であろう。（テロの余蘊赤く新藩についてのリスクは受容する）
�については、
・機密性より、完全性の問題。だから、対策は、本当に重要なファイルは予めバックアップを取る。バックアップの取り方はイントラネット上のファイルサーバを利用するのが一番楽。其処に収まらない場合は、メディアに抜いてセキュリティデリバリーサービスを利用するか、それでも心配な機密情報の場合は自分でジュラルミンケースに腕鍵を付けて手持ちする。銀行の貸し金庫にでも預ける（映画並み）。心配馬鹿に付き合っているとキリがないが、そう言う情報がゼロでもないからやってもらってよい。きっとセコム辺りがサービスしてくれるだろう。電子情報ならサーバーの容量を増やせば済むが、ハードコピーはそうは行かない。
�については、
紛失は始末が悪い。ある確率で必ず発生する。大事なものは只の備品と同じ扱いにしないで、何処にも紛れない工夫をすること。必要なら自分で運ぶ。
※
引越し２日のために、暗号化ソフトを入れるとか、バックアップサーバーを増量するとか、メディアに改めて抜くとかは、おかしな話だ。「あつものに懲りて膾を吹く」会社は案外真面目に取り組むかもしれない。まあ、だからＩＴ業界は救われているんだろうね。
本当に重要なコンテンツなら日頃から、ＨＤＤは引越ししなくてもいつでもクラッシュするチャンスがある訳だから、バックアップを取っているはず。もし取っていなければ今すぐ実施してもらえばよいこと。
日頃やっていないで済ましたことを引越し・移転で大騒ぎして、責任転嫁を図るのは不届き千万ですね。
※
と言うことで、共有ファイルサーバーには既に重要情報は収まっているし、それでも足りない（容量的または完全性の意味で）場合は、別にメディアに落とされて大事に管理されているはず。
ファイルサーバーは運が良ければ運ばなくて良いし、そのメディアはセキュリティデリバリーを頼めば済むこと。
引越し・移転の実行委員は特に騒ぐ必要も無いことです。
※
こう言うときに騒ぐのはいつも同じ人ですね。情報セキュリティから合理性を外すとこうなるという見本みたいな。
そのような時にも情報セキュリティ問題は避けて通ることは出来ません。
情報セキュリティ問題に対処する基本は常にリスクアセスメントにあります。
１）先ずは、移動させる情報資産の洗い出しを行います。
・資産は引越し荷物ですから明確です。
・書類、メディア、パソコン/サーバー
・ケーブルとかディスプレィなどコンテンツに関係ないものは通常の引越しレベルで問題ないでしょう。
２）次に、脅威の洗い出しを行いますが、そのためには以下の状況・プロセスを押さえます。
・移動時の梱包形態
・取り扱い業者
・車両の特性
・運搬ルート
・当日中に作業が終わらなければ、何処で一泊させるか。
３）脅威・脆弱性
�輸送時の事故または不注意による破損（普通の引越しでも此れは確率が高い）
�大手企業の引越しの場合は大量のＯＡ機器を狙っての窃盗（あまり聞いたことは無いがリスクケースとして想定できる）
窃盗は輸送時と一時保管時が考えられる。
�紛失。小物のメディアが何かに紛れて紛失するケース。
�については、
・身元のしっかりした人であることを確認しておく。（確認してもらう）
・輸送時の一時預かり倉庫は鍵の施錠管理、２４時間守衛体制などを確認する。不足なら守衛を立てる。
・輸送車とオフィスの間にバッファをおく場合は見張りを付ける。
等の施策で十分であろう。（テロの余蘊赤く新藩についてのリスクは受容する）
�については、
・機密性より、完全性の問題。だから、対策は、本当に重要なファイルは予めバックアップを取る。バックアップの取り方はイントラネット上のファイルサーバを利用するのが一番楽。其処に収まらない場合は、メディアに抜いてセキュリティデリバリーサービスを利用するか、それでも心配な機密情報の場合は自分でジュラルミンケースに腕鍵を付けて手持ちする。銀行の貸し金庫にでも預ける（映画並み）。心配馬鹿に付き合っているとキリがないが、そう言う情報がゼロでもないからやってもらってよい。きっとセコム辺りがサービスしてくれるだろう。電子情報ならサーバーの容量を増やせば済むが、ハードコピーはそうは行かない。
�については、
紛失は始末が悪い。ある確率で必ず発生する。大事なものは只の備品と同じ扱いにしないで、何処にも紛れない工夫をすること。必要なら自分で運ぶ。
※
引越し２日のために、暗号化ソフトを入れるとか、バックアップサーバーを増量するとか、メディアに改めて抜くとかは、おかしな話だ。「あつものに懲りて膾を吹く」会社は案外真面目に取り組むかもしれない。まあ、だからＩＴ業界は救われているんだろうね。
本当に重要なコンテンツなら日頃から、ＨＤＤは引越ししなくてもいつでもクラッシュするチャンスがある訳だから、バックアップを取っているはず。もし取っていなければ今すぐ実施してもらえばよいこと。
日頃やっていないで済ましたことを引越し・移転で大騒ぎして、責任転嫁を図るのは不届き千万ですね。
※
と言うことで、共有ファイルサーバーには既に重要情報は収まっているし、それでも足りない（容量的または完全性の意味で）場合は、別にメディアに落とされて大事に管理されているはず。
ファイルサーバーは運が良ければ運ばなくて良いし、そのメディアはセキュリティデリバリーを頼めば済むこと。
引越し・移転の実行委員は特に騒ぐ必要も無いことです。
※
こう言うときに騒ぐのはいつも同じ人ですね。情報セキュリティから合理性を外すとこうなるという見本みたいな。
2006年08月22日
ソックス法のリスク分析にＩＳＭＳは使えるか？
ソックス対応で洗い出したプロセスから、情報資産の洗い出しに一度落とし、リスク分析に繋ぐ。
逆かも知れない。最初に財務諸表に関係する資産が洗い出しされた、そのリスク分析をプロセスの視点でチェックし脅威脆弱性に繋ぐ。
しかし、ＩＴ統制ではシステムが洗い出しされる。システムを資産と見るかシステムを分解して行くかはそこのやり方だろう。
開発フェーズと運用フェーズがある。そこは要注意だ。
ソックス対応で洗い出したプロセスから、情報資産の洗い出しに一度落とし、リスク分析に繋ぐ。
逆かも知れない。最初に財務諸表に関係する資産が洗い出しされた、そのリスク分析をプロセスの視点でチェックし脅威脆弱性に繋ぐ。
しかし、ＩＴ統制ではシステムが洗い出しされる。システムを資産と見るかシステムを分解して行くかはそこのやり方だろう。
開発フェーズと運用フェーズがある。そこは要注意だ。
2006年08月03日
ペイメントカード業界・データセキュリティ基準、ＰＣＩ ＤＳＳは国際カード五社が共同で策定したクレジットカード情報保護に関する国際基準。
取引先への遵守要請を始めた。
取引先への遵守要請を始めた。
2006年07月24日
ISO15489はレコードマネジメント関する国際標準。
レコードの「真正性」「信頼性」「完全性」「利便性」の確保についてのガイド
レコードの生成から処理（利用？）・保管・保存・廃棄までのライフサイクルの中での管理ガイド。要求規格ではない。文書管理に対する記録管理に近い概念か、トータルな文書管理に近い概念かは未確認。
マネジメントシステムの国際標準では文書管理・記録管理についての要求が含まれるのでその時のレベルとして求められる内容はこのISO15489を踏まえていることが一つの目処となるであろう。
2001年に制定されたものが現在改訂作業中の様子。2001年版のJIS化：JIS X
0902-1、-2は2005年に行われた。
今回のISO15489改訂でマネジメントシステム（ISO9000/14000/27000)との関連をどのように記載するかは関心の持たれる所です。
レコードの「真正性」「信頼性」「完全性」「利便性」の確保についてのガイド
レコードの生成から処理（利用？）・保管・保存・廃棄までのライフサイクルの中での管理ガイド。要求規格ではない。文書管理に対する記録管理に近い概念か、トータルな文書管理に近い概念かは未確認。
マネジメントシステムの国際標準では文書管理・記録管理についての要求が含まれるのでその時のレベルとして求められる内容はこのISO15489を踏まえていることが一つの目処となるであろう。
2001年に制定されたものが現在改訂作業中の様子。2001年版のJIS化：JIS X
0902-1、-2は2005年に行われた。
今回のISO15489改訂でマネジメントシステム（ISO9000/14000/27000)との関連をどのように記載するかは関心の持たれる所です。
2006年06月19日
モバイルコードとは、インターネットを利用してダウンロードされ自動実行されるプログラムのことらしい。ACTIVE-XとかJAVAとかで作成されたプログラムもその類。
実際に有用なものもあれば、悪意のあるソフトが紛れ込むこともある。要はどのように作りこむかで迷惑な話になる。（場合によってはバグもある）
管理策「A10.42 モバイルコードに対する管理策」では、動作を認可するものとしないものを分けて適切に管理しろとある。
問題は、認可の是非を何を持って行うかだ。
証明書があればOKで、無ければNGか
他に確認する術があるのか
方法が無ければ管理策として成立しない。
証明書があっても悪い札が付いていたら排除しなければならないし。証明書が無いから排除したとして業務インパクトとの関連は理解しておかないと排除の妥当性が掴めない。
要は、施策/方法論だけで検討を始めると話は空回りです。
詳細管理策に「A.15.16暗号化機能に対する規則」と言うのがある。
分からないのはこの管理策に関連して、デジタル証明書を海外に送ったら、特に中国に送った場合、何か問題になることがあるのかどうか。
証明書の妥当性は日本側のサーバーで行うので、暗号技術を利用といっても国内の話のはず。どういう難癖が成立するだろう。何かあれば管理策が必要になる。
*
構築の意味
・文書化された管理体系の策定（確立）
その文書に従えば正しい行いが出来る＝運用が出来る。
・運用開始�案
文書化された体系に頭から従えば、適用範囲・方針・リスクアセスから始まる一連を実施する。
・運用開始�案
全員が揃って正しい活動が出来る前提で考えると、関連する計画の策定が終わっていること。また力量がレディになっていること（必要な教育が完了していること）
運用に必要なコンテンツが洗い出されている状態。
�と�は違うことを言っているようで実際は同じかも。運用可能な文書化レベルってミニマム�まで進んでいないと無理だろう。実質的なシミュレーションに相当。
初回構築はそんなものだ。
２回目からは、リスク対応計画などを踏まえリニューアルされたISMSでの運用開始を経営者は宣言する図になる。ISMSの運用バージョンが概念的に存在する。
2006年04月28日
2006年03月20日
順法。適合性。
合法的な情報流出。
しかし、内部告発を内部に行うのは誰が考えても無理がある。
いい加減な法律なのかな？
合法的な情報流出。
しかし、内部告発を内部に行うのは誰が考えても無理がある。
いい加減な法律なのかな？
2006年03月19日
認証登録の範囲。認証範囲に同じ。
適用範囲はやはり同じになる。システムの適用範囲はしかし厳密に言えば登録範囲に同じかそれをカバーしていることになる。
時々、定義をはっきりさせない報告が来る。
困る。
適用範囲はやはり同じになる。システムの適用範囲はしかし厳密に言えば登録範囲に同じかそれをカバーしていることになる。
時々、定義をはっきりさせない報告が来る。
困る。
2006年03月18日
身体障害者にも優しい建物に関する建築基準を定めた法律。標準の基準と更に改善された基準とがある。この選りすぐれた基準をクリアした建物には「ハート・ビル」のマークを表示できる。
多分、税制上の優遇措置もあるだろう。其れを漬け込んだのが東横インという会社であり、法律違反を意に介さないあの社長の記者会見です。
続きを読む ...
多分、税制上の優遇措置もあるだろう。其れを漬け込んだのが東横インという会社であり、法律違反を意に介さないあの社長の記者会見です。
続きを読む ...
