ソフトウェアを作っていると、自分が技術屋なのか、法律屋なのかわからなくなるほど、
実はルールに縛られる。
また、これらのルールはいつも、解釈が曖昧である。

別に直接、法律には絡まないなーと思っていても、業務システムに手を付ければ、
そこにも法律ではないものの同じようなものに縛られる。
例えば、私は以前、損害保険システムをやっていたが、
仕様は約款を満たす必要がある。
そのために、技術の有無よりもあの難解で利用者にわざとわかりにくくしていると思えるような、
内容を読めるかどうかが、最初の関門であり、それを突破できないと、技術の話もできない。

まあ、保険をやってりゃ仕方がないなーとおもっていると、そうでもない。
今や、会員ビジネスが基本となっているIT業界にとって、
いろいろな規制やルールを知らないとまずいルールがあります。

突然、それは違法だからできないよ。サービスを止めてといわれると、
ビジネス上の大打撃をうけるのですが、
そのことを最初に判断できるのが、技術者となってしまっている現実があります。
というのも、技術用語をつかった、法律用語が展開されてしまうので、
双方を理解できないと、ちんぷんかんぷんな話になってしまいます。

個人的に、非常に重要だと思っているのが、以下の2つです。
1)個人情報保護法
2)JSOX法(18号監査・IT統制)

個人情報保護法

この言葉をしらない人はいないと思うのですが、意外と、できた背景というのは知らないようです。
1.個人情報保護法制整備の背景(PDF)というのが消費者庁のHPにあります。
ちょっと、わかりにくいかもしれませんが、要は2つのことをいっています。
・国民総番号制度などをにらんだ、行政整備。
・他の国の仕事をする際に必要な国としての整備(要はこれがないと外国の仕事に入札できないなど)
です。
つまり、個人の情報の権利を守るためとか、個人が個人の情報をコントロールできるため。
というよりは、諸外国への対応と、これを作っても、現在の行政運用が正しいこと。ということです。
従って、あるべき姿からできたということではなく、
既にルールがないところで、運用が始まってしまっている所に対して、ルールを後付けで作っていった。
という側面があります。
これを知らないと、ちょっとガイドラインなどの読み方に間違いが出てしまいます。

しかし、今は何が「個人情報」なのか?というあたりで、
スマートフォンではいろいろと問題が出てきています。
というのも、技術的に個人をかなり限定的に特定できる方法(情報の種類)が、
スマートフォンの利用では隠されています。
こんなの素人は誰も気がつかないだろうと思っているかもしれませんが、
それを発見し、指摘するのは、同じ技術者です。
まず、見抜かれます。今までの携帯であれば、電話の先はキャリアの通信網だったので、
何となく問題なかったものが、スマートフォンになって、アプリの動きは監視できるし、
ネットワーク上に流そうとしているデータだって筒抜けにできます。
この辺りは、世の中の流れで変化する部分はありますが、
基本的な部分としての解釈はできるようにしておいた方がいいです。
お客さんが、明らかに「黒」のことをしようとしていても、
実際にはそれが「黒」だということをしらないケースがあり、
むしろ、それを「黒」と教えてあげることでより信頼が得られるケースもありますから・・・

JSOX法(18号監査 / IT統制 )

実際、私は最近までこの18号監査という名前を知りませんでした。
なぜって、監査を外部から受ける(求められる)対象ではなかったかです。
でも、ずーと疑問に思っていました。
その疑問は、自分たちはお客から課金している内容が正しいことを証明することや、
データの運用がきちんとされていることなど、いろいろなルールで運用してきました。
(なぜって、ASPを運用していたからです。)
でも、SIや運用委託でくるものにはどうして、そのようなルールがないのだろうか?
抜け穴なのだろうか?
と思っていたら、どうやら、それを求める際に、「18号監査」という名前でくるらしいのです。
やっぱり必要になるのです。

また、JSOXではIT統制ガイダンスも求めています。
こちらも、あーだこーだと説明できるほど知識もないので、
5分で絶対に分かるJ-SOX IT統制ガイダンスをリンクしておきます。

しかし、現場ではこれを文面通りに解釈して行うということよりも、
私はまずは、以下のマネジメントモデルを知るべきだろうとおもいます。
1つは、CMMI
もう一つは、ITIL
です。

こちらは、JSOX法と直接絡みはありませんが、目的が重複している部分もあるので、
より現場でルールと実態をともに両立させるならば、知っておいていいモデルだとおもいます。
それに、JSOX法よりはだいぶ現場に近いところの話です。

たとえば、gitやcvs,subversionなどでソースを管理していることや、
trac,redmineで修正管理をしていることはCMMIで管理すべき事項として当然規定しています。
別に手段は問いませんが・・・、でもルールとしての文面はおもおもしいことでも、
要は、このような実体運用としてできることとルールが一致していることが多い方が、
いいにきまっています。

まあ、ルールを作ろう!という雰囲気や、必要性が出てきた際には、
このような世の中がITの世界に求めている規制やルールを知ってもらった上で、
つくるようにすれば、いざ、外からそれを求められたときに、
うろたえる必要もなくなると思います。

それに外部(現場外)から突然やってくるルールに翻弄させられるのは、
本望ではありません。
その前に、ある程度、こういった外部要因に即したルールと運用を作っておくことも、
専念したい部分に集中するためには必要な理論武装と思います。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2012年6月
« 5月   7月 »
 123
45678910
11121314151617
18192021222324
252627282930  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ