やはり企業ユーザーは"Microsoft Surface"を無視できない！

やはり企業ユーザーは"Microsoft Surface"を無視できない！

デスクトップ、ノート、タブレット、スマホ、仮想化デスクトップ、スカイドライブ、etc。相互運用性、シームレス運用、既存の情報資産の利用を考慮すると、マイクロソフトしか残らないから。

マイクロソフト純正タブレットの評価は多分このようなことで落ち着くだろう。

.*.

ビッグデータ

ビッグデータ

普通のデータベースでは処理できないくらい大きいサイズのデータ。正規化されたデータと非正規ののデータが混在することもある。なかなか手に負えないデータ。それが少しずつ手に負えるようになってきて俄かにビッグデータの言葉があふれ出した。

.*.

ロングテール・ビジネスもビッグデータの一つではないかな。今まで諦めていた雑多なデータの再評価が可能になった。そういうことだろう。

.*.

エクサバイト（EB）：ビッグデータが扱うデータ量（ファイル容量）はエクサバイト単位とか。テラバイトの１００万倍。相当だね。

ギガバイト（ＧＢ）⇒テラバイト（ＴＢ）⇒ペタバイト（ＰＢ）⇒エクサバイト（ＥＢ）

.*.

Virtual Desktop Infrastructure

Virtual Desktop Infrastructure

VDI

これは何でしょうか？

発展したシンクライアントのコンセプトみたいですね。

デスクトップというかウインドウズは端末上にはダウンロードされない。単なる表示機に過ぎないのでしょうか。

となると通信俯瞰が大変ですね。

.*.

クラウドをビジネスに利用し始めた企業

クラウドをビジネスに利用し始めた企業

クラウドは負荷対応の弾力的運用という側面が評価されている。ミニマムのリソースで最大の効用を得ようというものだが、ぎりぎりで設計するとNTTの通信ダウン事故みたいに何度も失敗する。やはり余裕を持っていないと安心できない訳です。

クラウドのもう１つの側面はインターネット（イントラネットでも）の利用です。企業グループ内や、ビジネスパートナー、あるいはユーザー～顧客との情報連携がしやすいということです。

これって必ずしもクラウドであることを要求するものでは有りません。ただ、不確定のニーズに対する備えとしてクラウドは取り敢えず有効であろうとの理解は得られます。

.*.

一方で、クラウドは幻滅期に入ったとする観測もある。

実際に、そんな余裕で幾つもサーバーを動かしていなければクラウドに変えるメリットは出ない。頻繁に設備増強に追い込まれるような急激な変化は、クラウドにしても容易ではあるまい。

クラウドにすることで、一部のトラブルが全体に波及するリスクもある。途上技術。

.*.

ディザスタリカバリ

ディザスタリカバリ

DR:disaster recovery

災害復旧。南海トラフ広域地震の想定シナリオが発表されてしまったので、企業は無視できなくなった。つまり、今後の災害復旧プランはこの震災を想定に入れざるを得なくなった。大変なことです。

ISMSの事業継続管理も当然、この想定に引っ張られることになる。

取り敢えずは、社会インフラを担う企業の取り組みを診てからということで、待ちの姿勢になるでしょう。

.*.

ソフトウエア開発における重要な活動

ソフトウエア開発における重要な活動

1. 品質計画
2. 製品ライフサイクル管理
3. 開発標準に基づく開発
4. 構成管理
5. 差別化能力と訓練
6. 機密管理

.*.

Service Level Agreements

Service Level Agreements

所謂SLA(エスエルエー）です。あまりしっかりしたSLAにはお目にかかれません。独立系のITサービス事業会社なら立派なSLAを持っているかもしれません。

それでも、保障《未達成はペナルティ）と努力目標（ペナルティなし）に分けて、妥協の産物になっているでしょうか。

.*.

会社内の情報システム部門の場合は尚更明確なSLAを設定しません。これはいけませんね。CIOとかをおく場合はしっかりこの辺は縛りましょう。

.*.

安全なウェブサイトの作り方

安全なウェブサイトの作り方

IPA（ここも天下り独立法人ですか？）がこのようなサイトを開いている。企業のＷＥＢ担当者は一応読んでおかないと説明責任を負えない。

http://www.ipa.go.jp/security/vuln/websecurity.html

.*.

ISO/IEC 15408

ISO/IEC 15408

JIS X 5070：セキュリティ技術―情報技術セキュリティの評価基準

これは確か、商品自体の情報セキュリティ達成基準でしたよね。特に通信機器などでは重要とか。ソフトウエアでも関連するところは大事かも。

.*.

IT Service Management

IT Service Management

これは確か、規格がありました。

.*.

ISO/IEC 20000-1

.*.

ITIL　（アイティル）

http://www.itsmf-japan.org/itil/

.*.

ITサービスが社会に与える影響が大きいことを踏まえ、より安定的にITサービスが提供されるように規格を定めている。と言うのが建前。ISMSでも全然問題ないが、議論が寄り適切にフォーカスされるためには、こっちの規格は有用。認証取得と勘違いしないこと。認証はISMSで充分。内容的に参照すべきと言うことです。


「サービスレベル管理」
「サービス記録管理」
「サービス継続性・可用性管理」
「サービス資源管理」
「容量能力管理」
「情報セキュリティ管理」
「顧客関係管理」
「供給者管理」
「インシデント管理」
「問題管理」
「構成管理」
「変更管理」
「リリース管理」

.*.

構成およびリリース管理

構成およびリリース管理

ここでの構成及びリリース管理は開発中の構成管理と異なり、市場に出ている商品の構成管理である。従って、関連する多くのスタッフ、協力会社、ユーザーなどと必要な範囲で共有できなければいけない。

再現性も保障されること。普通は怖いからオブジェクトコードのコピーを持ちます。再構成なんて最後の最後の切り札です。


.*.

リリースノートとは：

何を変更したのか。その他必要なことを記載。

.*.

ソフトウェアライフサイクル

ソフトウェアライフサイクル


ソフトウェアの企画・構想から設計、開発、導入、運用、保守、破棄に到るまでの工程全体のこと。普通の商品・サービスの「ライフサイクルマネジメント」と基本的に同じ。

最初から捨てるときのことを考えて開発しなさいと。今では常識？。ソフトなら運用性、保守性を考慮して開発する。

情報セキュリティまで考慮する昨今は廃棄・サービス停止の時のことまで考慮することが求められる。

.*.

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

.*.

テスト

テスト

ホワイトボックステストとブラックボックステスト

内部構造・内部仕様などを踏まえて行うのがホワイト、イン･アウトだけに着目するのがブラック。言葉が面白いだけで、詰まらない。前者は開発者視点のサイドのテスト、後者は利用者視点のテストと理解した方がわかりやすい。このカテゴリー分けは何も新しいものをもたらさない。

＜開発部門＞
単体試験
組み合わせ試験
総合試験

＜第３者部門＞
αテスト

＜利用者側＞
受け入れてスト
βテスト

テストフェーズをどのように区分するかは組織の決め事。

.*.

テスト環境の管理：
テストアカウント管理
テストデータ管理

.*.

不具合管理＝これは構成管理の支援も必要。

単体・組み合わせで、スペックの不備まで引っ張り出しておかないと大変。総合試験より後のフェーズで問題が出ても、相性の問題、タイミングの問題などが入り込むと非常に厄介。

.*.

構成管理

構成管理

バージョン管理、リリース管理、インテグレーション管理、ビルド管理、、、。

.*.

地味な仕事だから、間に合わせ人材を入れて失敗することがある。

専用ツールは高い。

.*.

今は、開発プロセス全体から、ライフサイクル全体までを管理する役割を担う。とても重要。

.*.

開発環境

開発環境

各ベンダーが提供している。一度ベンダーが決まると変えたくなくなる要因。独立系の環境を利用したくなる。ハードウエアメーカーに縛られたくない。

.*.

Eclipse

Visual Studio, NET Framework

.*.

オブジェクト指向分析設計

オブジェクト指向分析設計


UML:聞いたことあるね。モデル表記法の標準仕様。

Unified Modeling Language

.*.

構造化分析設計技法

構造化分析設計技法

問題をクリアにするための方法論ですから、ソフトウエア開発に限りません。

「状態遷移図」とか「データフローダイアグラム」などは古くから利用されています。

E-Rモデル：

E：Entity:実態-R：Relation：関係モデリングは主にデータベース設計に利用される。

.*.

要件定義と要求分析

要件定義と要求分析

禅問答みたいな文字の並び。企業文化、技術者の美学の違いの程度と理解しておきます。別物とすると返って混乱します。

.*.

この用語においては実際には何をやるかを明確にしているかどうかが大事ですね。

.*.

「要件定義書」が取り敢えずの成果物。要件定義書策定マニュアルとか手順書が開発部門標準として用意されています。

QMSと同じく、最新版管理、周知管理が問題になります。

.*.

ソフトウエア開発の方法論

ソフトウエア開発の方法論

◆　ウォーターフォール型

古典的な、しかし、今も主流のウォーターフォール型。大型プロジェクトはこの形になる。

矛盾する概念ではないが設計技法として：
構造化技法。プロセス分析技法の応用。どちらが応用したのか分りませんが。
オブジェクト指向型開発技法。

◆　プロトタイプ型

これも、必ずしも矛盾する概念ではないが、プロトタイプ型。アイデアの骨子を先ずモデル的に作り、主にユーザー視点から検証しながら要求仕様を確立しながら作り込んでいく。

.*.

プロジェクト全体の進め方はウォーターフォール型に沿い、個別のところの開発はそれぞれに適した手法が選択される。

.*.

◆　アジャイル型

アジャイルSW開発は、様々な変化への対応を柔軟に出来ることを意図して集積した方法論の総体。

品質の確保とスピードアップは常に課題であるわけで、アジャイルと名前を付けたら、そう都合よくものが運ぶわけではない。

.*.

プログラミング言語

プログラミング言語

処理手順を記述するのがプログラム言語。どの装置、どの分野で利用するかによって様々です。

技術進化に合わせて言語も進化あるいは最適化されるため、ハードウエア環境の違いへの対応もあってプログラミング言語の数はきりがない。

.*.

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.soumu.go.jp/main_sosiki/joho_tsusin/security/kiso/k05.htm

＜ISMS管理＞

本社部門（法務、人事、総務など）が絡む場合はコンプライアンスに穴が開くケースは少ないが、部門に任されている場合は、本社からのマニュアルで作業するため、穴が開くケースが出る。本社（各機能統括部門）の常識が部署、特に別授業所、別地域に展開している先では要注意。

特に、部門による派遣従業員の採用、業務委託のケース。

.*.

LRM

LRM

コンサル会社の名前。何の略かは知らない。

http://www.iso27001.jp/




取得１００％保障と記載されている。100％実績の記載もある。何かしら引っかかる表現です。勢い余ってかも知れません。

みんな若い。

.*.

株式会社クオーレ

株式会社クオーレ

http://www.cuore.jp/index.html

ISMSコンサルティング

手広く仕事をしている印象だ。ＩＳＭＳはほんの一部。そのためか会社の方向性が今一分かりにくい。社長の挨拶は、しかし、クリアで好感が持てる。

.*.

可用性の議論：問題の単純化

可用性の議論：問題の単純化

可用性の問題を如何に単純化するか

（１）アクセススピードはプロセスの要求によって決定される。一律に何時間、何日とやるのは意味が無い。
（２）最悪の状態をイメージしてみる。漏洩していないし、改竄されていないし、紛失していない（＝アクセスできる）。

「アクセスできない。紛失の可能性がある。倉庫全部を探さないと分らない。棚卸しが必要。」

もしこうなったらどれくらいの損害が出るのか。アベイラビリティの喪失による損害額。この金額レベルを、例えば３段階で表現する。

プロセスの要求が当日中となっていて、当日中が実現できない場合、翌日にはアクセスできるかもしれないし、永久にアクセスできないかも知れないし、１週間以内とか色々なバリエーションを発想できる。でもこれは意味のない議論です。

問題はアクセス性が管理されているかどうかの二択問題なんですね。管理されていない場合の最大の損害額は紛失（漏洩では有りません）～アクセス不可を前提に策定します。

.*.

間に合わない。手遅れ。を想定すると、もっと簡単に単純化できます。タイムリーでない情報は取り返しが付かないとやります。

アクセス時間（要求レスポンスタイム）は情報の属性の一つです。内容が同じでもアクセスタイムが異なればそれはもう別の情報と観ればいいですね。

.*.

安全性の確認

安全性の確認

米軍のヘリコプター飛行機「オスプレイ」の配備について、安全性の確認が問題になっている。

「安全性確認」とは何で、その方法論はどういうものか、常識の範囲で考えてみる。まあ、常識そのものも怪しいが。

＜安全性＞

（１）肉体的精神的にどの部位・どの機能においても人を傷つけないこと。（部位機能を問わない）
（２）どのような時間枠の中でも人にダメージを与えないこと。（時間を問わない）
（3）人の個体差があるばあいも、その全てに対してダメージを与えないこと。（個体を問わない）

安全性は基本的に人に対する安全。一番優先される深刻な問題の資産

どんな人？

オスプレイの安全性は、操縦する人、乗り込む人、地上スタッフ（運用面、サービス面）、地上の市民。


（４）人が所有するあるいは管理する有形無形の資産に対して損害を与えないこと。

安全性の問題から引き離すことも有るが、資産を毀損させないことも安全性として一緒に議論されることも多い。

＜安全性の確認＞

新技術、新素材、新商品、新サービス、新しい手順、新しいルールなどが認識されると安全性の確認はほぼ義務といっていい。

新しくなくても、全てが安全性確認の対象となるが、新しいものについては特に重要とされている。が、ライフサイクル末期の安全性も重要かつ深刻なものとなっている。劣化は管理が困難だからだ。

（方法論）

最も一般的なやり方は「実績積み上げ」。兵器も同じ。実績積み上げは改善の積み上げ。利用技術も含めて、品質が安定するまで実績を積んでいく。

操縦ミスは品質の外において米軍は議論しようとしているが無意味。操縦ミスを起こしやすいだけで不良品質と考えたほうがいい。有事は未熟な操縦者もありうる。

.*.

今回、防衛省から品質の専門家が米国へ出向いているが、彼らに安全確認のためのどんな方法論があるのか疑問。安全基準も無ければ検証しようがない。基準は実績を積まないと作れないという自己矛盾も有る。

.*.

ISMSの発想

新しい情報技術を導入するときのセキュリティ確認にたいする方法論としてみれば全く同様の問題になる。

（１）実績は充分か。
（２）元の状態に戻せるか。
（３）情報のシェア・体制の連携など管理レベルは充分か。

.*.

顔認証システム

顔認証システム

USJの年間パスポート使用者の本人確認に利用。

ユーカリが丘の住民を見守る。登録した人が一定期間通行が無ければ以上と判断する。

グローリー（姫路市）はお札の真贋確認システムを持っていて顔認証のノウハウを蓄積。

山万（マンション販売）はグローリーの顔認証システムを地域やマンションのセキュリティ確保に利用。

グローリー：顔認証

http://www.glory.co.jp/

山万：顔認証

http://www.yamaman.co.jp/

.*.

ISMSの観点では幾つかポイントが出てくる。

1. 登録情報の管理
2. 登録手順・削除手順・更新手順
3. システム異常時の対応手順
   代替手段の検証と復旧手順
4. 地域･建物全体の災害時の対応

.*.

事業継続計画の枠組みの統一化

事業継続計画の枠組みの統一化

「一つの枠組み」が良く分からないみたいだ。

審査員を見ていてもこのこと（1つの枠組み）に言及することは少ない。事例が少ないことに加えて、良く分かっていないようだ。

中身は簡単なもので、BCPあるいはBCM策定の手順でも具体的に言及されていいものだが、伝言ゲームでお茶を濁す組織では無用の長物か。

考え方は、料理を作る時のレシピの書き方をイメージすればいい。

レシピの数は膨大であり、レシピの書き方も料理人によってばらばら。ですが、ある店、ある宿屋、ある主婦を特定すると、非常にまとまった統一感のあるレシピが作成されています。門外不出もありますが、その店の必要な人の間では共有できていて、受け継がれていきます。

組織の文化にあうBCPが必要なだけ策定され、それらはある統一感のある作法で作成され表現されるものです。

組織の誰でも理解できるBCPが作成されることになります。

.*.

回らない緊急連絡網？訓練も簡単ではない！

回らない緊急連絡網？訓練も簡単ではない！

緊急連絡網のテスト

お手軽に事業継続計画の実践訓練として緊急連絡網を回す話はよく聞きます。一応、やりましたから、規格はクリアですね、と。お手軽は、お気楽ですね。

どれくらいの時間でどれくらいの人に何を伝えるのか？

そもそも、どういう時に緊急連絡網は発動されるのか？

伝言ゲーム型なのか？それも、糸電話型か、ツリー型か。一斉同報型か。それぞれの連絡表は最新版か、どうやって確認できるのか。変更手順は明確か？、変更通知のやり方は？

こういうのは「自衛隊のOB」が強い。オフィスの人たちへの連絡と、現場（前線）の人たちへの連絡と。知らせてはいけないことまで決めてあるかもしれない。

問題の性格によっては家族情報にも立ち入ることになる。

伝えた相手にどういうアクションを求めるか？

インフラ、ライフラインが正常な時と、正常でない時と、手順が変わるか。

緊急連絡に伴い、情報の配信・収集、遠隔会議、緊急招集。場合により、特別な移動手段が確保できるか。

企業規模、事業規模により、該当しないものもあるだろうし、さらに強化された準備が必要になるだろう。

1つのセクション、１つのチーム、係単位・課単位なら問題にならないことも 全社レベルでは簡単にいかない。

如かして、緊急連絡網はなかなか回らないものです。

もっとも、何が１００％（100点）か分からないだけで、取り敢えず出来る範囲で緊急連絡は始まります。あれこれ考え確認するよりその方が早い。だから0点にはなりません。怖いのは現場のアクションが伴う場合。適切な手が打てない場合は問題が大きくなる。

どういう事態・事象の時に緊急連絡網が発動されるのか予め洗い出しておく作業も有効な準備活動だ。網羅するのは無理でも、主要なパターンは把握できるだろう。

.*.

Mac OSのアプリ制限はセキュリティ確保策は一つの方向

Mac OSのアプリ制限はセキュリティ確保策は一つの方向

どのようなアプリケーションをダウンロードして良いかは企業毎に決めて、ブラックリスト、ホワイトリストで管理してきたが、OS自体にも身元不明のアプリの起動を制約する機能を入れるのは、BYODが進む中では必要な機能の一つとなるだろう。

何でもできるけど危険この上ないCromeとAndroidで行くのか、少々制限が掛かるけどよりセキュアなMacOSとiOSで行くのか。

＜グーグル＞
カスタマイズに拘る向き、これはIT屋さんに多いが、特別な仕様を設定するような場合はグーグルのソリューションを使う。

＜アップル＞
カスタマイズも程ほどで済ます場合は、アップルのソリューションでもいいだろう。出来る限り純正アプリで済ます。

こういう棲み分けは、今は非常識。カスタマイズをやれば、失うものがとても多いことを既に学んでいる。ご本家の純正アプリをそのまま使う。カスタマイズは長続きしない。どうしても固有のスペックが必要な場合は出口を作っておく必要がある。出口をいい加減なまま強行すると失敗して立ち往生。SAP R/3で多くの人が経験している世界。土俵がスマホに移っても構造は同じです。

.*.

Mac OSの新バージョン：マウンテンライオンはiOSとの相互運用性の強化が図られている。面白い。マイクロソフトがWindows8でPCとスマホのシームレスな運用を目指すのと同じ発想。グーグルがクロムとアンドロイドで目指すのも同じ。

＜ブートキャンプによる事業継続性の確保＞

ウインドウズは常に攻撃の対象であり、クロム/アンドロイドは無防備すぎる現状があり、結局、セキュリティを意識する人はアップルしか選択できない。企業ユーザーでこういう極端は考え難いが、事業継続性の観点からブートキャンプを併用するBCP施策はより現実性を帯びてくる。

.*.