連載
» 2004年07月10日 12時00分 公開

ブレークタイムに“設計思想”を語り合おう何かがおかしいIT化の進め方(8)(3/3 ページ)

[公江義隆,@IT]
前のページへ 1|2|3       

Fail Safeのプロセス構造〜情報システム問題への展開

 Fail Safe概念の情報システムに対する展開例として、データチェックのプログラムロジックや、セキュリティのチェック手続きの問題を考えてみる。

 基幹系などのアプリケーションシステムでは、多くの場合、前段のプログラムでデータのチェックを行い、後段で具体的なデータ処理や加工を行うようにしていると思う。

 このとき、データチェックのプログラムロジックの構成として、入力データは(A)“通すことを原則にして、不適なものが見つかればはじき出す”方法と、(B)“通さないことを原則にして、適正であることを確認できた場合にだけを通す”方法との2種類の考え方ができる。

 システムをダウンをさせた揚げ句に「やっと原因が分かりました。こんな条件のデータがあるとは思いませんでした」といったことが多い人のプログラムには、チェックロジックの構造への問題意識がないAB混在型というのもあったりする。Fail Safeの考え方に沿えば基本構造として(B)が正解だ。

 さらに、現実的な問題として、このチェックロジックの仕様・条件設定の問題を考えてみよう。

 往年の社内SEやプログラマには、(A)の好きな人が予想以上に多いように感じた。業務プロセスの例外処理を熟知し、チェック条件の設定に自信のあった彼らにとっては、自分の知識を生かせるこのタイプを自然に選ぶことが多かったのかもしれない。業務実態を知る人の少なくなった、また設計を社外に依存することの多い現在ではどうであろうか。

 人間は、問題が発生してから具体的な判断を行うのが普通だ。人が処理する業務プロセスでは、前もってすべてのケースを考えておく必要はない。ユーザー(業務)部門の人にとっても、前もって“すべての不都合なケースを列挙”することは常識的にもまず不可能だ。これが“ものの道理”ということだろう。大変なエネルギーを掛けて不完全なことしかできない。

 そこで(B)の構造が妥当ということになるが、このためには(B)を明確に意識して外部仕様の調査・検討をやる必要がある。

 プログラムの構造は、当然考えていなかった条件のデータが来れば直ちに人間に助けを求める(人が介入する)形のものになる。こうすれば問題のデータがはっきりする。システム稼働後の保守運用体制や品質に関係する問題である。作り手(ベンダ)に任せ放しにしないで、“頼む側(ユーザー)”もよく考えておくべきだ。

 最近、どの会社もセキュリティ問題には大変気を使っている。しかし、玄関から入ってくる行儀の良い人に厳しく、裏口から入ってくるようなルールを守らない人に結果的に寛大になっているようなことはないだろうか。これも前の例と同様である。

 不正な方法を事前にすべて列挙することはできない。セキュリティチェックの問題は、コンピュータ系でも人間系でも不審者を除外しようという考え方では、目的を十分には果たせない。通さないことを前提(システムの既定値)とし、条件を満たしたと確認できたものだけを通す、上記(B)のタイプの仕組みが必要だ。こんなレベルで問題をキッチリと押さえないと、立派なセキュリティポリシーも具体レベルでは十分に機能しない。データベースへのアクセス権などについても同様である。ルールを守らない人に対しては、情け容赦ないやり方をするのが正解となる問題である。

 次回は、“FoolProof”の問題についてさらに深く考えていくと同時に、「情報化のコンセプト」についても言及したい。こうしたことを、仕事の合間のコーヒーブレイクで会話してみることから、新たなアイデアが生まれることもある。

profile

公江 義隆(こうえ よしたか)

ITコーディネータ、情報処理技術者(特種)、情報システムコンサルタント(日本情報システム・ユーザー協会:JUAS)

元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業(経済産業省)、沖縄型産業振興プロジェクト(内閣府沖縄総合事務局経済産業部)、コンサルティング活動などを通じて中小企業のIT課題にかかわる


「何かがおかしいIT化の進め方」バックナンバー
前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ