2012年08月30日
ソフトウェアライフサイクル
ソフトウェアの企画・構想から設計、開発、導入、運用、保守、破棄に到るまでの工程全体のこと。普通の商品・サービスの「ライフサイクルマネジメント」と基本的に同じ。
最初から捨てるときのことを考えて開発しなさいと。今では常識？。ソフトなら運用性、保守性を考慮して開発する。
情報セキュリティまで考慮する昨今は廃棄・サービス停止の時のことまで考慮することが求められる。
.*.
ISO/IEC 12207:2008(JIS X 0160:2012)
JIS X 0160:2012 ソフトウェアライフサイクルプロセス
6 システムライフサイクルプロセス 20
6.1 合意プロセス 20
6.2 組織のプロジェクトイネーブリングプロセス 27
6.3 プロジェクトプロセス 32
6.4 テクニカルプロセス 42
7 ソフトウェア固有プロセス 56
7.1 ソフトウェア実装プロセス 56
7.2 ソフトウェア支援プロセス
.*.
こういう標準が出来たんだね。今更もう間に合わないというか、役に立つことは無いだろうけど。
概ね５０ページぐらいだろうからざっと読めばどういう機能配置が必要か分りそうだ。意識・無意識のうちにやっていることが大半だろう。
.*.
ソフトウェアの企画・構想から設計、開発、導入、運用、保守、破棄に到るまでの工程全体のこと。普通の商品・サービスの「ライフサイクルマネジメント」と基本的に同じ。
最初から捨てるときのことを考えて開発しなさいと。今では常識？。ソフトなら運用性、保守性を考慮して開発する。
情報セキュリティまで考慮する昨今は廃棄・サービス停止の時のことまで考慮することが求められる。
.*.
ISO/IEC 12207:2008(JIS X 0160:2012)
JIS X 0160:2012 ソフトウェアライフサイクルプロセス
6 システムライフサイクルプロセス 20
6.1 合意プロセス 20
6.2 組織のプロジェクトイネーブリングプロセス 27
6.3 プロジェクトプロセス 32
6.4 テクニカルプロセス 42
7 ソフトウェア固有プロセス 56
7.1 ソフトウェア実装プロセス 56
7.2 ソフトウェア支援プロセス
.*.
こういう標準が出来たんだね。今更もう間に合わないというか、役に立つことは無いだろうけど。
概ね５０ページぐらいだろうからざっと読めばどういう機能配置が必要か分りそうだ。意識・無意識のうちにやっていることが大半だろう。
.*.
プロジェクトマネジメント
複数の人、部署、会社が共通の目的を達成するために協業するときは、何処にでも存在する役割。プロセス。権限を持たされた専門の部隊を置くケースから、兼務兼業でプロマネの一部を負担するケースまで、組織の状況により様々です。
データを集めて責任者に報告するだけのもの（事務屋の事務局タイプ）もある。
.*.
複数の人、部署、会社が共通の目的を達成するために協業するときは、何処にでも存在する役割。プロセス。権限を持たされた専門の部隊を置くケースから、兼務兼業でプロマネの一部を負担するケースまで、組織の状況により様々です。
データを集めて責任者に報告するだけのもの（事務屋の事務局タイプ）もある。
.*.
ドキュメンテーション
ソフトウエア開発でいうドキュメンテーションとは、システムやソフトウエアと一緒に納品する文書類の作成のこと。或いはプロジェクト完了の要件として整備する文書類の作成のこと。
開発者サイドのドキュメント類は構成管理の一環として管理される。契約によっては、途中の変更過程全ての提出が求められる。というか、指定の構成管理ツールの利用が条件になっている。
一般的な場合、内容は、利用者マニュアル。取扱説明書。操作手順書。ヘルプ＆トレーニングなど。
品質レベルを証明する記録類を整理したものもドキュメント類に入れるケースもある。契約による。
.*.
ソフトウエア開発でいうドキュメンテーションとは、システムやソフトウエアと一緒に納品する文書類の作成のこと。或いはプロジェクト完了の要件として整備する文書類の作成のこと。
開発者サイドのドキュメント類は構成管理の一環として管理される。契約によっては、途中の変更過程全ての提出が求められる。というか、指定の構成管理ツールの利用が条件になっている。
一般的な場合、内容は、利用者マニュアル。取扱説明書。操作手順書。ヘルプ＆トレーニングなど。
品質レベルを証明する記録類を整理したものもドキュメント類に入れるケースもある。契約による。
.*.
不具合管理
構成管理、テスト管理、との関連が強い。
テスト自体は問題を発見する手段でテスト担当者は減員分析とか改修とかには関わらない。開発側の仕事かといえば、問題を主リンクされる懸念もあるので、また別のチームなり部隊が両者と連携しながら担当する。
もぐらたたきの防止
回帰テスト（リグレッションテスト）はあるバグをフィックスしたときに、別の問題が生じていないか確認するテスト。バグの存在を前提に関連するモジュールが動いている場合は、バグが修復されるとそのモジュールは正しく動作しない。下手な作り込みをすると、バグが連鎖してもぐらたたきになる。
.*.
１件１件の不具合に対する確実な修復という視点の管理業務に加え、統計的な分析も必要。これらはテスト計画への反映されるものとなる。分析では、品質に問題の有る領域（ファンクション、モジュール、レイヤー、インタフェースなど）を特定する。
.*.
構成管理、テスト管理、との関連が強い。
テスト自体は問題を発見する手段でテスト担当者は減員分析とか改修とかには関わらない。開発側の仕事かといえば、問題を主リンクされる懸念もあるので、また別のチームなり部隊が両者と連携しながら担当する。
もぐらたたきの防止
回帰テスト（リグレッションテスト）はあるバグをフィックスしたときに、別の問題が生じていないか確認するテスト。バグの存在を前提に関連するモジュールが動いている場合は、バグが修復されるとそのモジュールは正しく動作しない。下手な作り込みをすると、バグが連鎖してもぐらたたきになる。
.*.
１件１件の不具合に対する確実な修復という視点の管理業務に加え、統計的な分析も必要。これらはテスト計画への反映されるものとなる。分析では、品質に問題の有る領域（ファンクション、モジュール、レイヤー、インタフェースなど）を特定する。
.*.
メトリクス
ソフトウエアメトリックスとはソフトウエア品質指標と思えばいい。
一番ポピュラーなのはテスト時間当たりの不具合発生件数。他にも有名な指標は沢山あります。コードレビューで発見できる不具合がコード行数当たり何個か。仕様変更数。変更修正に要する時間。性能。コード量〜プログラム規模。など。
メトリクス測定ツール
規模によっては測定ツールも必要になるかもしれない。測定ツールが悪さをするかも知れないので、嫌う人もいる。多分。開発環境の一環として提供される。
単に、メトリックスといえば只の指標、尺度。
尺度評価は、右上がり尺度、右下がり尺度、中央値尺度などいくつか考えられるが、単なるデータ収集でしかないもの（因果関係の不明確なもの）もあるので、惑わされないことです。
CMMIをメトリクスにするのはピンとこない。開発プロセスの品質レベルには違いないが、品質のばらつきとか、達成状況を計測する視点のものではない。
Capability Maturity Model Integration
.*.
ソフトウエアメトリックスとはソフトウエア品質指標と思えばいい。
一番ポピュラーなのはテスト時間当たりの不具合発生件数。他にも有名な指標は沢山あります。コードレビューで発見できる不具合がコード行数当たり何個か。仕様変更数。変更修正に要する時間。性能。コード量〜プログラム規模。など。
メトリクス測定ツール
規模によっては測定ツールも必要になるかもしれない。測定ツールが悪さをするかも知れないので、嫌う人もいる。多分。開発環境の一環として提供される。
単に、メトリックスといえば只の指標、尺度。
尺度評価は、右上がり尺度、右下がり尺度、中央値尺度などいくつか考えられるが、単なるデータ収集でしかないもの（因果関係の不明確なもの）もあるので、惑わされないことです。
CMMIをメトリクスにするのはピンとこない。開発プロセスの品質レベルには違いないが、品質のばらつきとか、達成状況を計測する視点のものではない。
Capability Maturity Model Integration
.*.
テスト
ホワイトボックステストとブラックボックステスト
内部構造・内部仕様などを踏まえて行うのがホワイト、イン･アウトだけに着目するのがブラック。言葉が面白いだけで、詰まらない。前者は開発者視点のサイドのテスト、後者は利用者視点のテストと理解した方がわかりやすい。このカテゴリー分けは何も新しいものをもたらさない。
＜開発部門＞
単体試験
組み合わせ試験
総合試験
＜第３者部門＞
αテスト
＜利用者側＞
受け入れてスト
βテスト
テストフェーズをどのように区分するかは組織の決め事。
.*.
テスト環境の管理：
テストアカウント管理
テストデータ管理
.*.
不具合管理＝これは構成管理の支援も必要。
単体・組み合わせで、スペックの不備まで引っ張り出しておかないと大変。総合試験より後のフェーズで問題が出ても、相性の問題、タイミングの問題などが入り込むと非常に厄介。
.*.
ホワイトボックステストとブラックボックステスト
内部構造・内部仕様などを踏まえて行うのがホワイト、イン･アウトだけに着目するのがブラック。言葉が面白いだけで、詰まらない。前者は開発者視点のサイドのテスト、後者は利用者視点のテストと理解した方がわかりやすい。このカテゴリー分けは何も新しいものをもたらさない。
＜開発部門＞
単体試験
組み合わせ試験
総合試験
＜第３者部門＞
αテスト
＜利用者側＞
受け入れてスト
βテスト
テストフェーズをどのように区分するかは組織の決め事。
.*.
テスト環境の管理：
テストアカウント管理
テストデータ管理
.*.
不具合管理＝これは構成管理の支援も必要。
単体・組み合わせで、スペックの不備まで引っ張り出しておかないと大変。総合試験より後のフェーズで問題が出ても、相性の問題、タイミングの問題などが入り込むと非常に厄介。
.*.
構成管理
バージョン管理、リリース管理、インテグレーション管理、ビルド管理、、、。
.*.
地味な仕事だから、間に合わせ人材を入れて失敗することがある。
専用ツールは高い。
.*.
今は、開発プロセス全体から、ライフサイクル全体までを管理する役割を担う。とても重要。
.*.
バージョン管理、リリース管理、インテグレーション管理、ビルド管理、、、。
.*.
地味な仕事だから、間に合わせ人材を入れて失敗することがある。
専用ツールは高い。
.*.
今は、開発プロセス全体から、ライフサイクル全体までを管理する役割を担う。とても重要。
.*.
開発環境
各ベンダーが提供している。一度ベンダーが決まると変えたくなくなる要因。独立系の環境を利用したくなる。ハードウエアメーカーに縛られたくない。
.*.
Eclipse
Visual Studio, NET Framework
.*.
各ベンダーが提供している。一度ベンダーが決まると変えたくなくなる要因。独立系の環境を利用したくなる。ハードウエアメーカーに縛られたくない。
.*.
Eclipse
Visual Studio, NET Framework
.*.
オブジェクト指向分析設計
UML:聞いたことあるね。モデル表記法の標準仕様。
Unified Modeling Language
.*.
UML:聞いたことあるね。モデル表記法の標準仕様。
Unified Modeling Language
.*.
構造化分析設計技法
問題をクリアにするための方法論ですから、ソフトウエア開発に限りません。
「状態遷移図」とか「データフローダイアグラム」などは古くから利用されています。
E-Rモデル：
E：Entity:実態-R：Relation：関係モデリングは主にデータベース設計に利用される。
.*.
問題をクリアにするための方法論ですから、ソフトウエア開発に限りません。
「状態遷移図」とか「データフローダイアグラム」などは古くから利用されています。
E-Rモデル：
E：Entity:実態-R：Relation：関係モデリングは主にデータベース設計に利用される。
.*.
要件定義と要求分析
禅問答みたいな文字の並び。企業文化、技術者の美学の違いの程度と理解しておきます。別物とすると返って混乱します。
.*.
この用語においては実際には何をやるかを明確にしているかどうかが大事ですね。
.*.
「要件定義書」が取り敢えずの成果物。要件定義書策定マニュアルとか手順書が開発部門標準として用意されています。
QMSと同じく、最新版管理、周知管理が問題になります。
.*.
禅問答みたいな文字の並び。企業文化、技術者の美学の違いの程度と理解しておきます。別物とすると返って混乱します。
.*.
この用語においては実際には何をやるかを明確にしているかどうかが大事ですね。
.*.
「要件定義書」が取り敢えずの成果物。要件定義書策定マニュアルとか手順書が開発部門標準として用意されています。
QMSと同じく、最新版管理、周知管理が問題になります。
.*.
ソフトウエア開発の方法論
◆ ウォーターフォール型
古典的な、しかし、今も主流のウォーターフォール型。大型プロジェクトはこの形になる。
矛盾する概念ではないが設計技法として：
構造化技法。プロセス分析技法の応用。どちらが応用したのか分りませんが。
オブジェクト指向型開発技法。
◆ プロトタイプ型
これも、必ずしも矛盾する概念ではないが、プロトタイプ型。アイデアの骨子を先ずモデル的に作り、主にユーザー視点から検証しながら要求仕様を確立しながら作り込んでいく。
.*.
プロジェクト全体の進め方はウォーターフォール型に沿い、個別のところの開発はそれぞれに適した手法が選択される。
.*.
◆ アジャイル型
アジャイルSW開発は、様々な変化への対応を柔軟に出来ることを意図して集積した方法論の総体。
品質の確保とスピードアップは常に課題であるわけで、アジャイルと名前を付けたら、そう都合よくものが運ぶわけではない。
.*.
◆ ウォーターフォール型
古典的な、しかし、今も主流のウォーターフォール型。大型プロジェクトはこの形になる。
矛盾する概念ではないが設計技法として：
構造化技法。プロセス分析技法の応用。どちらが応用したのか分りませんが。
オブジェクト指向型開発技法。
◆ プロトタイプ型
これも、必ずしも矛盾する概念ではないが、プロトタイプ型。アイデアの骨子を先ずモデル的に作り、主にユーザー視点から検証しながら要求仕様を確立しながら作り込んでいく。
.*.
プロジェクト全体の進め方はウォーターフォール型に沿い、個別のところの開発はそれぞれに適した手法が選択される。
.*.
◆ アジャイル型
アジャイルSW開発は、様々な変化への対応を柔軟に出来ることを意図して集積した方法論の総体。
品質の確保とスピードアップは常に課題であるわけで、アジャイルと名前を付けたら、そう都合よくものが運ぶわけではない。
.*.
2012年08月29日
プログラミング言語
処理手順を記述するのがプログラム言語。どの装置、どの分野で利用するかによって様々です。
技術進化に合わせて言語も進化あるいは最適化されるため、ハードウエア環境の違いへの対応もあってプログラミング言語の数はきりがない。
.*.
http://www.mwsoft.jp/column/program_top10.html
素人が見ても分らないが雰囲気は伝わって来る。
Scala
JavaScript
Ruby
Perl
Objective-C
C#
Python
PHP(PHP(Hypertext Pre-processer))
C++
C
Java
Smalltalk
Assembly language
FORTRAN
COBOL
LISP
PL/1
Visual Basic
BASIC
.*.
HTML
XML
SGML
.*.
何がISMS？
ソース管理？
力量管理？
環境管理？
構成管理？
世代管理？
.*.
処理手順を記述するのがプログラム言語。どの装置、どの分野で利用するかによって様々です。
技術進化に合わせて言語も進化あるいは最適化されるため、ハードウエア環境の違いへの対応もあってプログラミング言語の数はきりがない。
.*.
http://www.mwsoft.jp/column/program_top10.html
素人が見ても分らないが雰囲気は伝わって来る。
Scala
JavaScript
Ruby
Perl
Objective-C
C#
Python
PHP(PHP(Hypertext Pre-processer))
C++
C
Java
Smalltalk
Assembly language
FORTRAN
COBOL
LISP
PL/1
Visual Basic
BASIC
.*.
HTML
XML
SGML
.*.
何がISMS？
ソース管理？
力量管理？
環境管理？
構成管理？
世代管理？
.*.
ソフトウエア産業とは？
これを如何に括るかは至難の技。それはソフトウエアの無い産業など一つも無いからです。
総務省統計局の分類は何か決めておかないと不便することを考慮して作ったものですが、一般的には殆ど価値が有りません。言い過ぎ？。組織が業態を名乗るときには必要でしょうが、外販しないで内部プロセスとして持つものも少なくない。情報部門を分離して別会社にしたら情報通信業となるが、会社グループとしては何も変わっていない。
http://www.stat.go.jp/index/seido/sangyo/19-3-1.htm
http://www.stat.go.jp/index/seido/sangyo/pdf/19san3g.pdf
大分類 Ｇ 情報通信業
中分類 37 通信業
中分類 38 放送業
中分類 39 情報サービス業
中分類 40 インターネット附随サービス業
中分類 41 映像・音声・文字情報制作業
391 ソフトウェア業
3911 受託開発ソフトウェア業
3912 組込みソフトウェア業
3913 パッケージソフトウェア業
3914 ゲームソフトウェア業
.*.
ISMSの勘所
人的リソース集約産業。知的産業といえば格好いいが人件費集約産業。
知的財産、人的資源、委託契約の関連は当然として、サービス/サポートフェーズまで考慮したライフサイクル管理の側面を見失わないことです。特に、弱小企業でも個人の力量に頼って重要なパートナーとなりますが、永続性が無いリスクをどのように管理しているかがポイントとなります。
.*.
これを如何に括るかは至難の技。それはソフトウエアの無い産業など一つも無いからです。
総務省統計局の分類は何か決めておかないと不便することを考慮して作ったものですが、一般的には殆ど価値が有りません。言い過ぎ？。組織が業態を名乗るときには必要でしょうが、外販しないで内部プロセスとして持つものも少なくない。情報部門を分離して別会社にしたら情報通信業となるが、会社グループとしては何も変わっていない。
http://www.stat.go.jp/index/seido/sangyo/19-3-1.htm
http://www.stat.go.jp/index/seido/sangyo/pdf/19san3g.pdf
大分類 Ｇ 情報通信業
中分類 37 通信業
中分類 38 放送業
中分類 39 情報サービス業
中分類 40 インターネット附随サービス業
中分類 41 映像・音声・文字情報制作業
391 ソフトウェア業
3911 受託開発ソフトウェア業
3912 組込みソフトウェア業
3913 パッケージソフトウェア業
3914 ゲームソフトウェア業
.*.
ISMSの勘所
人的リソース集約産業。知的産業といえば格好いいが人件費集約産業。
知的財産、人的資源、委託契約の関連は当然として、サービス/サポートフェーズまで考慮したライフサイクル管理の側面を見失わないことです。特に、弱小企業でも個人の力量に頼って重要なパートナーとなりますが、永続性が無いリスクをどのように管理しているかがポイントとなります。
.*.
ソフトウエア開発プロセスにおけるコンプライアンス
ウォーターフォール型は、普通の一般的な商品開発・技術開発と同じ流れ。ライフサイクルで見れば似たような発想で理解できる。
コンプライアンス要求
＜ソフトウエア開発プロセスに特徴的な要求＞
「知的財産基本法」
「著作権法」
「特許法」
知的財産権（＝知的所有権）：特許権、実用新案権、育成者権、意匠権、著作権、 商標権その他の知的財産に関して法令により定められた権利又は法律上保護される利益に係る権利をいう。
ソフトウエア（成果物）に関するもの：プログラム、デザイン、アイデア。
＜一般のプロセスと共通する要求＞
その他のコンプライアンス要求は一般のプロセスと同様のもの。
とは言え、ソフトウエア業界では人海戦術がベースにあるため、派遣労働、業務委託に関する法令順守は重要なものである。公平な採用など。
従業員管理・労務管理に関する法令：
「労働基準法」
「労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等に関する法律」（派遣法）
「個人情報保護法」
委託契約に関する法令：
「下請代金支払遅延等防止法」(下請法)
「役務の委託取引における優越的地位の濫用に関する独占禁止法上の指針」
防災防犯関連
「災害対策基本法」
「消防法」
「行政機関等による監視カメラの設置等の適正化に関する法律案」《これはまだ準備中！》
セキュリティ関連：
刑法
著作権法
電気通信事業法
電子署名及び認証業務に関する法律
電子署名に係る地方公共団体の認証業務に関する法律
電波法
特定電子メールの送信の適正化等に関する法律
不正アクセス行為の禁止等に関する法律
有線電気通信法
*参考* http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/kiso/k05.htm
＜ISMS管理＞
本社部門（法務、人事、総務など）が絡む場合はコンプライアンスに穴が開くケースは少ないが、部門に任されている場合は、本社からのマニュアルで作業するため、穴が開くケースが出る。本社（各機能統括部門）の常識が部署、特に別授業所、別地域に展開している先では要注意。
特に、部門による派遣従業員の採用、業務委託のケース。
.*.
ウォーターフォール型は、普通の一般的な商品開発・技術開発と同じ流れ。ライフサイクルで見れば似たような発想で理解できる。
コンプライアンス要求
＜ソフトウエア開発プロセスに特徴的な要求＞
「知的財産基本法」
「著作権法」
「特許法」
知的財産権（＝知的所有権）：特許権、実用新案権、育成者権、意匠権、著作権、 商標権その他の知的財産に関して法令により定められた権利又は法律上保護される利益に係る権利をいう。
ソフトウエア（成果物）に関するもの：プログラム、デザイン、アイデア。
＜一般のプロセスと共通する要求＞
その他のコンプライアンス要求は一般のプロセスと同様のもの。
とは言え、ソフトウエア業界では人海戦術がベースにあるため、派遣労働、業務委託に関する法令順守は重要なものである。公平な採用など。
従業員管理・労務管理に関する法令：
「労働基準法」
「労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等に関する法律」（派遣法）
「個人情報保護法」
委託契約に関する法令：
「下請代金支払遅延等防止法」(下請法)
「役務の委託取引における優越的地位の濫用に関する独占禁止法上の指針」
防災防犯関連
「災害対策基本法」
「消防法」
「行政機関等による監視カメラの設置等の適正化に関する法律案」《これはまだ準備中！》
セキュリティ関連：
刑法
著作権法
電気通信事業法
電子署名及び認証業務に関する法律
電子署名に係る地方公共団体の認証業務に関する法律
電波法
特定電子メールの送信の適正化等に関する法律
不正アクセス行為の禁止等に関する法律
有線電気通信法
*参考* http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/kiso/k05.htm
＜ISMS管理＞
本社部門（法務、人事、総務など）が絡む場合はコンプライアンスに穴が開くケースは少ないが、部門に任されている場合は、本社からのマニュアルで作業するため、穴が開くケースが出る。本社（各機能統括部門）の常識が部署、特に別授業所、別地域に展開している先では要注意。
特に、部門による派遣従業員の採用、業務委託のケース。
.*.
2012年08月17日
LRM
コンサル会社の名前。何の略かは知らない。
http://www.iso27001.jp/
取得１００％保障と記載されている。100％実績の記載もある。何かしら引っかかる表現です。勢い余ってかも知れません。
みんな若い。
.*.
コンサル会社の名前。何の略かは知らない。
http://www.iso27001.jp/
取得１００％保障と記載されている。100％実績の記載もある。何かしら引っかかる表現です。勢い余ってかも知れません。
みんな若い。
.*.
株式会社クオーレ
http://www.cuore.jp/index.html
ISMSコンサルティング
手広く仕事をしている印象だ。ＩＳＭＳはほんの一部。そのためか会社の方向性が今一分かりにくい。社長の挨拶は、しかし、クリアで好感が持てる。
.*.
http://www.cuore.jp/index.html
ISMSコンサルティング
手広く仕事をしている印象だ。ＩＳＭＳはほんの一部。そのためか会社の方向性が今一分かりにくい。社長の挨拶は、しかし、クリアで好感が持てる。
.*.
可用性の議論２
可用性の問題を如何に単純化するか
（１）アクセススピードはプロセスの要求によって決定される。一律に何時間、何日とやるのは意味が無い。
（２）最悪の状態をイメージしてみる。漏洩していないし、改竄されていないし、紛失していない（＝アクセスできる）。
「アクセスできない。紛失の可能性がある。倉庫全部を探さないと分らない。棚卸しが必要。」
もしこうなったらどれくらいの損害が出るのか。アベイラビリティの喪失による損害額。この金額レベルを、例えば３段階で表現する。
プロセスの要求が当日中となっていて、当日中が実現できない場合、翌日にはアクセスできるかもしれないし、永久にアクセスできないかも知れないし、１週間以内とか色々なバリエーションを発想できる。でもこれは意味のない議論です。
問題はアクセス性が管理されているかどうかの二択問題なんですね。管理されていない場合の最大の損害額は紛失（漏洩では有りません）〜アクセス不可を前提に策定します。
.*.
可用性の問題を如何に単純化するか
（１）アクセススピードはプロセスの要求によって決定される。一律に何時間、何日とやるのは意味が無い。
（２）最悪の状態をイメージしてみる。漏洩していないし、改竄されていないし、紛失していない（＝アクセスできる）。
「アクセスできない。紛失の可能性がある。倉庫全部を探さないと分らない。棚卸しが必要。」
もしこうなったらどれくらいの損害が出るのか。アベイラビリティの喪失による損害額。この金額レベルを、例えば３段階で表現する。
プロセスの要求が当日中となっていて、当日中が実現できない場合、翌日にはアクセスできるかもしれないし、永久にアクセスできないかも知れないし、１週間以内とか色々なバリエーションを発想できる。でもこれは意味のない議論です。
問題はアクセス性が管理されているかどうかの二択問題なんですね。管理されていない場合の最大の損害額は紛失（漏洩では有りません）〜アクセス不可を前提に策定します。
.*.
2012年08月16日
安全性の確認
米軍のヘリコプター飛行機「オスプレイ」の配備について、安全性の確認が問題になっている。
「安全性確認」とは何で、その方法論はどういうものか、常識の範囲で考えてみる。まあ、常識そのものも怪しいが。
＜安全性＞
（１）肉体的精神的にどの部位・どの機能においても人を傷つけないこと。（部位機能を問わない）
（２）どのような時間枠の中でも人にダメージを与えないこと。（時間を問わない）
（3）人の個体差があるばあいも、その全てに対してダメージを与えないこと。（個体を問わない）
安全性は基本的に人に対する安全。一番優先される深刻な問題の資産
どんな人？
オスプレイの安全性は、操縦する人、乗り込む人、地上スタッフ（運用面、サービス面）、地上の市民。
（４）人が所有するあるいは管理する有形無形の資産に対して損害を与えないこと。
安全性の問題から引き離すことも有るが、資産を毀損させないことも安全性として一緒に議論されることも多い。
＜安全性の確認＞
新技術、新素材、新商品、新サービス、新しい手順、新しいルールなどが認識されると安全性の確認はほぼ義務といっていい。
新しくなくても、全てが安全性確認の対象となるが、新しいものについては特に重要とされている。が、ライフサイクル末期の安全性も重要かつ深刻なものとなっている。劣化は管理が困難だからだ。
（方法論）
最も一般的なやり方は「実績積み上げ」。兵器も同じ。実績積み上げは改善の積み上げ。利用技術も含めて、品質が安定するまで実績を積んでいく。
操縦ミスは品質の外において米軍は議論しようとしているが無意味。操縦ミスを起こしやすいだけで不良品質と考えたほうがいい。有事は未熟な操縦者もありうる。
.*.
今回、防衛省から品質の専門家が米国へ出向いているが、彼らに安全確認のためのどんな方法論があるのか疑問。安全基準も無ければ検証しようがない。基準は実績を積まないと作れないという自己矛盾も有る。
.*.
ISMSの発想
新しい情報技術を導入するときのセキュリティ確認にたいする方法論としてみれば全く同様の問題になる。
（１）実績は充分か。
（２）元の状態に戻せるか。
（３）情報のシェア・体制の連携など管理レベルは充分か。
.*.
米軍のヘリコプター飛行機「オスプレイ」の配備について、安全性の確認が問題になっている。
「安全性確認」とは何で、その方法論はどういうものか、常識の範囲で考えてみる。まあ、常識そのものも怪しいが。
＜安全性＞
（１）肉体的精神的にどの部位・どの機能においても人を傷つけないこと。（部位機能を問わない）
（２）どのような時間枠の中でも人にダメージを与えないこと。（時間を問わない）
（3）人の個体差があるばあいも、その全てに対してダメージを与えないこと。（個体を問わない）
安全性は基本的に人に対する安全。一番優先される深刻な問題の資産
どんな人？
オスプレイの安全性は、操縦する人、乗り込む人、地上スタッフ（運用面、サービス面）、地上の市民。
（４）人が所有するあるいは管理する有形無形の資産に対して損害を与えないこと。
安全性の問題から引き離すことも有るが、資産を毀損させないことも安全性として一緒に議論されることも多い。
＜安全性の確認＞
新技術、新素材、新商品、新サービス、新しい手順、新しいルールなどが認識されると安全性の確認はほぼ義務といっていい。
新しくなくても、全てが安全性確認の対象となるが、新しいものについては特に重要とされている。が、ライフサイクル末期の安全性も重要かつ深刻なものとなっている。劣化は管理が困難だからだ。
（方法論）
最も一般的なやり方は「実績積み上げ」。兵器も同じ。実績積み上げは改善の積み上げ。利用技術も含めて、品質が安定するまで実績を積んでいく。
操縦ミスは品質の外において米軍は議論しようとしているが無意味。操縦ミスを起こしやすいだけで不良品質と考えたほうがいい。有事は未熟な操縦者もありうる。
.*.
今回、防衛省から品質の専門家が米国へ出向いているが、彼らに安全確認のためのどんな方法論があるのか疑問。安全基準も無ければ検証しようがない。基準は実績を積まないと作れないという自己矛盾も有る。
.*.
ISMSの発想
新しい情報技術を導入するときのセキュリティ確認にたいする方法論としてみれば全く同様の問題になる。
（１）実績は充分か。
（２）元の状態に戻せるか。
（３）情報のシェア・体制の連携など管理レベルは充分か。
.*.
2012年08月13日
顔認証システム
USJの年間パスポート使用者の本人確認に利用。
ユーカリが丘の住民を見守る。登録した人が一定期間通行が無ければ以上と判断する。
グローリー（姫路市）はお札の真贋確認システムを持っていて顔認証のノウハウを蓄積。
山万（マンション販売）はグローリーの顔認証システムを地域やマンションのセキュリティ確保に利用。
グローリー：顔認証
http://www.glory.co.jp/
山万：顔認証
http://www.yamaman.co.jp/
.*.
ISMSの観点では幾つかポイントが出てくる。
登録情報の管理
登録手順・削除手順・更新手順
システム異常時の対応手順
代替手段の検証と復旧手順
地域･建物全体の災害時の対応
.*.
USJの年間パスポート使用者の本人確認に利用。
ユーカリが丘の住民を見守る。登録した人が一定期間通行が無ければ以上と判断する。
グローリー（姫路市）はお札の真贋確認システムを持っていて顔認証のノウハウを蓄積。
山万（マンション販売）はグローリーの顔認証システムを地域やマンションのセキュリティ確保に利用。
グローリー：顔認証
http://www.glory.co.jp/
山万：顔認証
http://www.yamaman.co.jp/
.*.
ISMSの観点では幾つかポイントが出てくる。
登録情報の管理
登録手順・削除手順・更新手順
システム異常時の対応手順
代替手段の検証と復旧手順
地域･建物全体の災害時の対応
.*.
2012年08月10日
事業継続計画の枠組みの統一化
「一つの枠組み」が良く分からないみたいだ。
審査員を見ていてもこのこと（1つの枠組み）に言及することは少ない。事例が少ないことに加えて、良く分かっていないようだ。
中身は簡単なもので、BCPあるいはBCM策定の手順でも具体的に言及されていいものだが、伝言ゲームでお茶を濁す組織では無用の長物か。
考え方は、料理を作る時のレシピの書き方をイメージすればいい。
レシピの数は膨大であり、レシピの書き方も料理人によってばらばら。ですが、ある店、ある宿屋、ある主婦を特定すると、非常にまとまった統一感のあるレシピが作成されています。門外不出もありますが、その店の必要な人の間では共有できていて、受け継がれていきます。
組織の文化にあうBCPが必要なだけ策定され、それらはある統一感のある作法で作成され表現されるものです。
組織の誰でも理解できるBCPが作成されることになります。
.*.
「一つの枠組み」が良く分からないみたいだ。
審査員を見ていてもこのこと（1つの枠組み）に言及することは少ない。事例が少ないことに加えて、良く分かっていないようだ。
中身は簡単なもので、BCPあるいはBCM策定の手順でも具体的に言及されていいものだが、伝言ゲームでお茶を濁す組織では無用の長物か。
考え方は、料理を作る時のレシピの書き方をイメージすればいい。
レシピの数は膨大であり、レシピの書き方も料理人によってばらばら。ですが、ある店、ある宿屋、ある主婦を特定すると、非常にまとまった統一感のあるレシピが作成されています。門外不出もありますが、その店の必要な人の間では共有できていて、受け継がれていきます。
組織の文化にあうBCPが必要なだけ策定され、それらはある統一感のある作法で作成され表現されるものです。
組織の誰でも理解できるBCPが作成されることになります。
.*.
回らない緊急連絡網？訓練も簡単ではない！
緊急連絡網のテスト
お手軽に事業継続計画の実践訓練として緊急連絡網を回す話はよく聞きます。一応、やりましたから、規格はクリアですね、と。お手軽は、お気楽ですね。
どれくらいの時間でどれくらいの人に何を伝えるのか？
そもそも、どういう時に緊急連絡網は発動されるのか？
伝言ゲーム型なのか？それも、糸電話型か、ツリー型か。一斉同報型か。それぞれの連絡表は最新版か、どうやって確認できるのか。変更手順は明確か？、変更通知のやり方は？
こういうのは「自衛隊のOB」が強い。オフィスの人たちへの連絡と、現場（前線）の人たちへの連絡と。知らせてはいけないことまで決めてあるかもしれない。
問題の性格によっては家族情報にも立ち入ることになる。
伝えた相手にどういうアクションを求めるか？
インフラ、ライフラインが正常な時と、正常でない時と、手順が変わるか。
緊急連絡に伴い、情報の配信・収集、遠隔会議、緊急招集。場合により、特別な移動手段が確保できるか。
企業規模、事業規模により、該当しないものもあるだろうし、さらに強化された準備が必要になるだろう。
1つのセクション、１つのチーム、係単位・課単位なら問題にならないことも 全社レベルでは簡単にいかない。
如かして、緊急連絡網はなかなか回らないものです。
もっとも、何が１００％（100点）か分からないだけで、取り敢えず出来る範囲で緊急連絡は始まります。あれこれ考え確認するよりその方が早い。だから0点にはなりません。怖いのは現場のアクションが伴う場合。適切な手が打てない場合は問題が大きくなる。
どういう事態・事象の時に緊急連絡網が発動されるのか予め洗い出しておく作業も有効な準備活動だ。網羅するのは無理でも、主要なパターンは把握できるだろう。
.*.
緊急連絡網のテスト
お手軽に事業継続計画の実践訓練として緊急連絡網を回す話はよく聞きます。一応、やりましたから、規格はクリアですね、と。お手軽は、お気楽ですね。
どれくらいの時間でどれくらいの人に何を伝えるのか？
そもそも、どういう時に緊急連絡網は発動されるのか？
伝言ゲーム型なのか？それも、糸電話型か、ツリー型か。一斉同報型か。それぞれの連絡表は最新版か、どうやって確認できるのか。変更手順は明確か？、変更通知のやり方は？
こういうのは「自衛隊のOB」が強い。オフィスの人たちへの連絡と、現場（前線）の人たちへの連絡と。知らせてはいけないことまで決めてあるかもしれない。
問題の性格によっては家族情報にも立ち入ることになる。
伝えた相手にどういうアクションを求めるか？
インフラ、ライフラインが正常な時と、正常でない時と、手順が変わるか。
緊急連絡に伴い、情報の配信・収集、遠隔会議、緊急招集。場合により、特別な移動手段が確保できるか。
企業規模、事業規模により、該当しないものもあるだろうし、さらに強化された準備が必要になるだろう。
1つのセクション、１つのチーム、係単位・課単位なら問題にならないことも 全社レベルでは簡単にいかない。
如かして、緊急連絡網はなかなか回らないものです。
もっとも、何が１００％（100点）か分からないだけで、取り敢えず出来る範囲で緊急連絡は始まります。あれこれ考え確認するよりその方が早い。だから0点にはなりません。怖いのは現場のアクションが伴う場合。適切な手が打てない場合は問題が大きくなる。
どういう事態・事象の時に緊急連絡網が発動されるのか予め洗い出しておく作業も有効な準備活動だ。網羅するのは無理でも、主要なパターンは把握できるだろう。
.*.
2012年08月03日
Mac OSのアプリ制限はセキュリティ確保策は一つの方向
どのようなアプリケーションをダウンロードして良いかは企業毎に決めて、ブラックリスト、ホワイトリストで管理してきたが、OS自体にも身元不明のアプリの起動を制約する機能を入れるのは、BYODが進む中では必要な機能の一つとなるだろう。
何でもできるけど危険この上ないCromeとAndroidで行くのか、少々制限が掛かるけどよりセキュアなMacOSとiOSで行くのか。
＜グーグル＞
カスタマイズに拘る向き、これはIT屋さんに多いが、特別な仕様を設定するような場合はグーグルのソリューションを使う。
＜アップル＞
カスタマイズも程ほどで済ます場合は、アップルのソリューションでもいいだろう。出来る限り純正アプリで済ます。
こういう棲み分けは、今は非常識。カスタマイズをやれば、失うものがとても多いことを既に学んでいる。ご本家の純正アプリをそのまま使う。カスタマイズは長続きしない。どうしても固有のスペックが必要な場合は出口を作っておく必要がある。出口をいい加減なまま強行すると失敗して立ち往生。SAP R/3で多くの人が経験している世界。土俵がスマホに移っても構造は同じです。
.*.
Mac OSの新バージョン：マウンテンライオンはiOSとの相互運用性の強化が図られている。面白い。マイクロソフトがWindows8でPCとスマホのシームレスな運用を目指すのと同じ発想。グーグルがクロムとアンドロイドで目指すのも同じ。
＜ブートキャンプによる事業継続性の確保＞
ウインドウズは常に攻撃の対象であり、クロム/アンドロイドは無防備すぎる現状があり、結局、セキュリティを意識する人はアップルしか選択できない。企業ユーザーでこういう極端は考え難いが、事業継続性の観点からブートキャンプを併用するBCP施策はより現実性を帯びてくる。
.*.
どのようなアプリケーションをダウンロードして良いかは企業毎に決めて、ブラックリスト、ホワイトリストで管理してきたが、OS自体にも身元不明のアプリの起動を制約する機能を入れるのは、BYODが進む中では必要な機能の一つとなるだろう。
何でもできるけど危険この上ないCromeとAndroidで行くのか、少々制限が掛かるけどよりセキュアなMacOSとiOSで行くのか。
＜グーグル＞
カスタマイズに拘る向き、これはIT屋さんに多いが、特別な仕様を設定するような場合はグーグルのソリューションを使う。
＜アップル＞
カスタマイズも程ほどで済ます場合は、アップルのソリューションでもいいだろう。出来る限り純正アプリで済ます。
こういう棲み分けは、今は非常識。カスタマイズをやれば、失うものがとても多いことを既に学んでいる。ご本家の純正アプリをそのまま使う。カスタマイズは長続きしない。どうしても固有のスペックが必要な場合は出口を作っておく必要がある。出口をいい加減なまま強行すると失敗して立ち往生。SAP R/3で多くの人が経験している世界。土俵がスマホに移っても構造は同じです。
.*.
Mac OSの新バージョン：マウンテンライオンはiOSとの相互運用性の強化が図られている。面白い。マイクロソフトがWindows8でPCとスマホのシームレスな運用を目指すのと同じ発想。グーグルがクロムとアンドロイドで目指すのも同じ。
＜ブートキャンプによる事業継続性の確保＞
ウインドウズは常に攻撃の対象であり、クロム/アンドロイドは無防備すぎる現状があり、結局、セキュリティを意識する人はアップルしか選択できない。企業ユーザーでこういう極端は考え難いが、事業継続性の観点からブートキャンプを併用するBCP施策はより現実性を帯びてくる。
.*.
2012年07月18日
引越しをしたら適用範囲変更！放置するとコンプライアンス違反？
勝手な引越し。迷惑な話です。しかもずっと黙ったまま。コンサルの立場も有ったものではありません。認証はロケーションが特定されているのだから引越ししたら認証は切れてまっせ。どっち道、認証はやり直し。引越し当日にでも審査しない限り、認証切れの期間は発生する。
事前審査と事後審査。引越しの計画と引越し先を事前に審査し、事後の確認審査を速やかに行う。事前と事後の間隔は感覚的には最大1ヶ月。
事前審査も無い場合、事後審査が1ヶ月を超える場合、これらは当然重大な不適合。審査の前提がひっくり返っているのだから当然重大な不適合。
ところが審査側も振り上げたこぶしの下ろし先が分からない。
当該部署を一旦外します。所定のロケーションから所定の部署・事業が無くなったのですから、その事実を確認したことを踏まえて、スコープの縮小手続きを取る。どの日付？遡ることが出来るんら引越し日。遡ることが無理な場合は確認日。次に改めて拡大審査として取り込みます。
スコープから外れたところが認証範囲のように扱っていたら契約違反で、不適合以前の問題になる。
.*.
審査もコンサルもランニングが重要な要素だと気づいているのかいないのか良く分かりません。
引越し時の縮小・拡大をスマートにやれば負担もないし、一定の売上が望める。特に引越し作業そのもののセキュリティについても入り込めば、クライアント側の理解はさらに得やすくなる。
.*.
見てもいないロケーションなのに次回のサーベイランスでOKですとかやっているのは不可解。サンプリングと同じ理屈が使えるなら、もう少し緩く出来る。
.*.
勝手な引越し。迷惑な話です。しかもずっと黙ったまま。コンサルの立場も有ったものではありません。認証はロケーションが特定されているのだから引越ししたら認証は切れてまっせ。どっち道、認証はやり直し。引越し当日にでも審査しない限り、認証切れの期間は発生する。
事前審査と事後審査。引越しの計画と引越し先を事前に審査し、事後の確認審査を速やかに行う。事前と事後の間隔は感覚的には最大1ヶ月。
事前審査も無い場合、事後審査が1ヶ月を超える場合、これらは当然重大な不適合。審査の前提がひっくり返っているのだから当然重大な不適合。
ところが審査側も振り上げたこぶしの下ろし先が分からない。
当該部署を一旦外します。所定のロケーションから所定の部署・事業が無くなったのですから、その事実を確認したことを踏まえて、スコープの縮小手続きを取る。どの日付？遡ることが出来るんら引越し日。遡ることが無理な場合は確認日。次に改めて拡大審査として取り込みます。
スコープから外れたところが認証範囲のように扱っていたら契約違反で、不適合以前の問題になる。
.*.
審査もコンサルもランニングが重要な要素だと気づいているのかいないのか良く分かりません。
引越し時の縮小・拡大をスマートにやれば負担もないし、一定の売上が望める。特に引越し作業そのもののセキュリティについても入り込めば、クライアント側の理解はさらに得やすくなる。
.*.
見てもいないロケーションなのに次回のサーベイランスでOKですとかやっているのは不可解。サンプリングと同じ理屈が使えるなら、もう少し緩く出来る。
.*.
認定機関や審査機関のロゴ変更
認定機関や審査機関がロゴを変える。迷惑な話です。だってどうでも良い事じゃないですか。そんなところのロゴなんて誰一人気にしていませんから。勝手に自己否定してくれてそちらは納得かもしれないがロゴを借りている当方としては名刺からパンフから一切が最新でないことになってしまう。取引先の印象が悪くなる。その損害は考えていないから益々迷惑に思う訳。
.*.
認定機関や審査機関がロゴを変える。迷惑な話です。だってどうでも良い事じゃないですか。そんなところのロゴなんて誰一人気にしていませんから。勝手に自己否定してくれてそちらは納得かもしれないがロゴを借りている当方としては名刺からパンフから一切が最新でないことになってしまう。取引先の印象が悪くなる。その損害は考えていないから益々迷惑に思う訳。
.*.
2012年07月17日
EQA国際認証センター
ここも日本では後発の外資系という枠組みに入るのかな。
http://www.eqaicc.co.jp
ホームページは癖のある作りで好感が持てない。どのサイトがジャパンサイトなんだろう。EQA KOREAはあるのにEQA JAPANは見当たらない。メニューとかプルダウンの設定とか、何となくいらいらさせられる。趣味で作ったページなの？
知っている人に話を聞かないと無理だね。というかあまり関心が持てない。必然性が見つからない。きっとここもコストを掛けない審査が売りなんだろうと思う。
安い審査と高い審査では何が違うのだろう。
.*.
ここも日本では後発の外資系という枠組みに入るのかな。
http://www.eqaicc.co.jp
ホームページは癖のある作りで好感が持てない。どのサイトがジャパンサイトなんだろう。EQA KOREAはあるのにEQA JAPANは見当たらない。メニューとかプルダウンの設定とか、何となくいらいらさせられる。趣味で作ったページなの？
知っている人に話を聞かないと無理だね。というかあまり関心が持てない。必然性が見つからない。きっとここもコストを掛けない審査が売りなんだろうと思う。
安い審査と高い審査では何が違うのだろう。
.*.
ムーディー・インターナショナル・サーティフィケーション
略称：MIC
http://www.moodygroup.co.jp/
http://www.moodygroup.co.jp/mic_index.htm
今一、分かり難いホームページだ。
後発の外資系ながら親会社の知名度を武器？に業績を順調に伸ばしている様子。とは言え、回りでは誰もあまり良く知らない会社ですね。知名度が有って料金が押えられていれば由とするなら採用？
http://www.moodygroup.co.jp/mic-pr02.htm
後発ならでは意識付け・動機付けのページを用意しています。ちょっと見はなかなか面白いですね。
既存の審査に対する認識：
高い費用の審査
威圧的な態度の審査
付加価値のない審査
簡略化を許さない審査
権威を看板にした審査
寸法検査のような審査
＜費用＞審査費用は要注意。安い費用の見積が出ても工数単価を確認すること。工数までぎりぎり少なくしてくる審査機関がある。経験があるからミニマムの審査工数で構わないというのは眉唾。それは何処かに無理が出る。工数単価が低くたっぷり工数をかけてもらって尚且つ安いのが良い。単価も安いし工数もミニマムは要注意。誰のためにもならない審査でしょう。
＜態度＞偉そうに上から目線で物を言う審査員は無くならない。当然です。やることやらないでいい加減な取り組みをしていたら、社員以上に会社のことを考えて苦言を呈することになる。いい加減な審査員は決して威圧的にはならない。会社のことなどどうでもいいから黙って通り過ぎますよ。審査を威圧的に感じたら本当の問題を探す気合が必要。
審査側が敢えて態度を口にするのは逆の意味で心配した方がよい。迎合的な審査に陥る可能性が大きい。3年間で不適合が3件以下なら、節穴審査か迎合的審査。そういうところが威圧的な態度は取りませんといったら要注意。
＜付加価値＞付加価値審査の話は以前からよく聞く。意味は分かるようで分からない。何処かの人が言っていたが何も足さない何も引かないとウイスキーの宣伝文句のような名言がある。それに従えば付加価値審査など存在しない。 付加価値などと余計なことを考えないでしっかり規格にそって審査をやって欲しいのが本音。小さな親切余計なお世話。参考情報は参考情報として別立てで提供して欲しい。殆どがそうだけど付加価値なんて言い出す審査員･審査機関はあまり信用できないね。
＜簡略化＞言っている意味が分かり難い。審査なんて所詮サンプリングで所定の工数でやるしかないので初めから簡略化されている。審査成立のためのレギュレーションがあるからそれはクリアするのは当然。ここで敢えて簡略化を主張するのは手抜きの正当化なのかな。工数を削減したい意図なんだろうか。要注意・要確認。
＜権威＞何のことなんでしょう。社会的ミッションの中で関係者全員が働きますが、何でしょうね。内は老舗ですとか由緒ある団体ですとかやっているんでしょうか。こんなこと気にしている企業は無い。ただ実績は見ます。実績のない新参は慎重になります。当然。こんなことをホームページに乗せているのはMICの劣等感・自信のなさを感じます。こんな意識では駄目だわ。
＜寸法＞これはますます理解困難。寸法を測る必要があれば寸法を測る。重箱の隅を突っつくような審査のこと。枝葉に目が言って幹の部分を見てくれない審査のこと。だったら表現力のヘタな書き方だ。意図が伝わらない。
ホームページにはMICのスタンスが記載されているが、これは審査では無さそうだ。コンサルだね。JABとかはこういうのを放置するのかな。それにコンサルも立場ないね。審査員の立場を利用したコンサル行為なんてご法度でしょう。平気で利益なんて書いているが経営責任も何もない連中に勝手な能書きを並べられたりしたら堪った物ではない。藁にもすがりたい経営者は重宝するのかな。案外。
.*.
略称：MIC
http://www.moodygroup.co.jp/
http://www.moodygroup.co.jp/mic_index.htm
今一、分かり難いホームページだ。
後発の外資系ながら親会社の知名度を武器？に業績を順調に伸ばしている様子。とは言え、回りでは誰もあまり良く知らない会社ですね。知名度が有って料金が押えられていれば由とするなら採用？
http://www.moodygroup.co.jp/mic-pr02.htm
後発ならでは意識付け・動機付けのページを用意しています。ちょっと見はなかなか面白いですね。
既存の審査に対する認識：
高い費用の審査
威圧的な態度の審査
付加価値のない審査
簡略化を許さない審査
権威を看板にした審査
寸法検査のような審査
＜費用＞審査費用は要注意。安い費用の見積が出ても工数単価を確認すること。工数までぎりぎり少なくしてくる審査機関がある。経験があるからミニマムの審査工数で構わないというのは眉唾。それは何処かに無理が出る。工数単価が低くたっぷり工数をかけてもらって尚且つ安いのが良い。単価も安いし工数もミニマムは要注意。誰のためにもならない審査でしょう。
＜態度＞偉そうに上から目線で物を言う審査員は無くならない。当然です。やることやらないでいい加減な取り組みをしていたら、社員以上に会社のことを考えて苦言を呈することになる。いい加減な審査員は決して威圧的にはならない。会社のことなどどうでもいいから黙って通り過ぎますよ。審査を威圧的に感じたら本当の問題を探す気合が必要。
審査側が敢えて態度を口にするのは逆の意味で心配した方がよい。迎合的な審査に陥る可能性が大きい。3年間で不適合が3件以下なら、節穴審査か迎合的審査。そういうところが威圧的な態度は取りませんといったら要注意。
＜付加価値＞付加価値審査の話は以前からよく聞く。意味は分かるようで分からない。何処かの人が言っていたが何も足さない何も引かないとウイスキーの宣伝文句のような名言がある。それに従えば付加価値審査など存在しない。 付加価値などと余計なことを考えないでしっかり規格にそって審査をやって欲しいのが本音。小さな親切余計なお世話。参考情報は参考情報として別立てで提供して欲しい。殆どがそうだけど付加価値なんて言い出す審査員･審査機関はあまり信用できないね。
＜簡略化＞言っている意味が分かり難い。審査なんて所詮サンプリングで所定の工数でやるしかないので初めから簡略化されている。審査成立のためのレギュレーションがあるからそれはクリアするのは当然。ここで敢えて簡略化を主張するのは手抜きの正当化なのかな。工数を削減したい意図なんだろうか。要注意・要確認。
＜権威＞何のことなんでしょう。社会的ミッションの中で関係者全員が働きますが、何でしょうね。内は老舗ですとか由緒ある団体ですとかやっているんでしょうか。こんなこと気にしている企業は無い。ただ実績は見ます。実績のない新参は慎重になります。当然。こんなことをホームページに乗せているのはMICの劣等感・自信のなさを感じます。こんな意識では駄目だわ。
＜寸法＞これはますます理解困難。寸法を測る必要があれば寸法を測る。重箱の隅を突っつくような審査のこと。枝葉に目が言って幹の部分を見てくれない審査のこと。だったら表現力のヘタな書き方だ。意図が伝わらない。
ホームページにはMICのスタンスが記載されているが、これは審査では無さそうだ。コンサルだね。JABとかはこういうのを放置するのかな。それにコンサルも立場ないね。審査員の立場を利用したコンサル行為なんてご法度でしょう。平気で利益なんて書いているが経営責任も何もない連中に勝手な能書きを並べられたりしたら堪った物ではない。藁にもすがりたい経営者は重宝するのかな。案外。
.*.
2012年07月16日
ソフトバンク系？ファーストサーバーのデータ消失事故
ヤフー！系のレンタルサーバー「ファーストサーバー」でデータ消失事故が発生した。ヤフー！系ということはソフトバンク系でしょうか。１０年くらい前に個人情報漏洩の大きな事故を起こして問題になったことは記憶に新しいし、直近では携帯電話のマイクロSDメモリーカードを紛失させる事故を起こしていて全く安心の置けない企業になってしまった印象だ。
個人的にはソフトバンク〜ヤフーとは深い関係（重要な情報を預けるような利用）は積極的に回避したい。要するに今後はもう使わないで置こうということです。
ファーストサーバーは低価格が売りだが、情報消失は論外。バックアップ系も含めて消失してしまった。ニュースを流したWBSの紹介によれば、あるサーバーのプログラム〜データ更新を行った時に対象外のサーバーについては全削除が実行されたとのこと。
まったく不十分なテスト環境しかもって居なかったのだろう。
.*.
内容はいつの場合も非情に基本的な問題です。
内部監査、外部審査、コンサルによる啓蒙、アドバイザリーによる有効性チェック、マネジメントレビュー。どの切り口からでもチェックできることがスルーしてしまうのは本当のマネジメントになっていないことでしょう。
この企業グループはいつもＱＣＤのＤを優先させる傾向にあるようだ。
.*.
ヤフー！系のレンタルサーバー「ファーストサーバー」でデータ消失事故が発生した。ヤフー！系ということはソフトバンク系でしょうか。１０年くらい前に個人情報漏洩の大きな事故を起こして問題になったことは記憶に新しいし、直近では携帯電話のマイクロSDメモリーカードを紛失させる事故を起こしていて全く安心の置けない企業になってしまった印象だ。
個人的にはソフトバンク〜ヤフーとは深い関係（重要な情報を預けるような利用）は積極的に回避したい。要するに今後はもう使わないで置こうということです。
ファーストサーバーは低価格が売りだが、情報消失は論外。バックアップ系も含めて消失してしまった。ニュースを流したWBSの紹介によれば、あるサーバーのプログラム〜データ更新を行った時に対象外のサーバーについては全削除が実行されたとのこと。
まったく不十分なテスト環境しかもって居なかったのだろう。
.*.
内容はいつの場合も非情に基本的な問題です。
内部監査、外部審査、コンサルによる啓蒙、アドバイザリーによる有効性チェック、マネジメントレビュー。どの切り口からでもチェックできることがスルーしてしまうのは本当のマネジメントになっていないことでしょう。
この企業グループはいつもＱＣＤのＤを優先させる傾向にあるようだ。
.*.
2012年07月11日
事前防災の発想
福島原発の関連質疑の中でと思うが、国会のやり取り（自民党の福井照議員）でいきなり”「事前防災」の考え方”というパネルが出てきた。
誰かが整理のために作ったものだろう。特に回復力を重要性を説明。
◆ 予防 Preventive (リスク回避）（リスク抑制）
ソフト：土地利用（高台移転）、
ハード：国土保全事業（堤防整備等）
◆ 減災 Mitigation (リスク軽減）
ソフト:観測･予測、防災教育、
ハード：耐震化、不燃化
◆ 備え Preparedness （リスク受容+緩和）
ソフト：防災訓練、自主防災組織、ボランティア、
ハード：避難路、避難施設、防災拠点
◆ 脆弱性軽減 Vulneerability Reduction （回復力）
ソフト:ＢＣＰ、物流チェーン
ハード：リダンダンシー、分散型国土づくり
.*.
此処の内容には良く分らないものも含まれるようだが、防災（事件事故の未然防止、事業継続管理の関連）に関する発想としては情報セキュリティの分野でも十分参考になる。
.*.
福島原発の関連質疑の中でと思うが、国会のやり取り（自民党の福井照議員）でいきなり”「事前防災」の考え方”というパネルが出てきた。
誰かが整理のために作ったものだろう。特に回復力を重要性を説明。
◆ 予防 Preventive (リスク回避）（リスク抑制）
ソフト：土地利用（高台移転）、
ハード：国土保全事業（堤防整備等）
◆ 減災 Mitigation (リスク軽減）
ソフト:観測･予測、防災教育、
ハード：耐震化、不燃化
◆ 備え Preparedness （リスク受容+緩和）
ソフト：防災訓練、自主防災組織、ボランティア、
ハード：避難路、避難施設、防災拠点
◆ 脆弱性軽減 Vulneerability Reduction （回復力）
ソフト:ＢＣＰ、物流チェーン
ハード：リダンダンシー、分散型国土づくり
.*.
此処の内容には良く分らないものも含まれるようだが、防災（事件事故の未然防止、事業継続管理の関連）に関する発想としては情報セキュリティの分野でも十分参考になる。
.*.
