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

[公江義隆，＠IT]

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化の進め方」バックナンバー

• IT関係者は、原発事故から何を学ぶべきか
• 優れたシステムを作るための“思考力、人間力”とは？
• “影”から目を背けてきた原発とIT
• 他山の石――政治を顧みて学ぶマネジメントの在り方
• 「想定外」から脱却できる、真の対策を
• 失敗は成功のもと、成功は失敗のもと
• いまあらためて確認したい、情シスのイロハ（後編）
• いまあらためて確認したい、情シスのイロハ（前編）
• 持続可能社会とITシステムはどう在るべきか（後編）
• 持続可能社会とITシステムはどう在るべきか（前編）
• 新型インフルエンザ対策に学ぶ組織の在り方
• 変化の中で、自らを制御できるものが生き残る
• “変化”を模索する世界（後編）
• “変化”を模索する世界（前編）
• “変化”は外からやってくる（後編）
• “変化”は外からやってくる（前編）
• その考え、本当にあなた自身のものですか？
• 事の本質を見極めよう
• 適材適所の人材育成をしよう
• コンプライアンスを語る前に考えてみること
• “シックオフィス”で健康を損なっていませんか？
• ゆでガエルになる前に情報子会社は経営の見直しを
• ディスカッションテーマのおもちゃ箱（2）
• ディスカッションテーマのおもちゃ箱（1）
• 有能なプロジェクトマネージャを育てるには（3）
• 有能なプロジェクトマネージャを育てるには（2）
• 有能なプロジェクトマネージャを育てるには（1）
• SOX法とコンプライアンスとIT
• リーダーシップを発揮するにはどうすれば？（後編）
• リーダーシップを発揮するにはどうすれば？（前編）
• 情報システム部は、もう役割を終えてしまったのか？
• 阪神大震災10年目に考えること、するべきこと（後編）
• 阪神大震災10年目に考えること、するべきこと（前編）
• “気付き”のコミュニケーション――機能や仕組みの説明は理解に結び付かない
• JR脱線事故からマネジメントを学ぶ
• 羽田空港の管制はなぜ止まったのか？
• IT徒然草――コストと利便性を追い求めて失うもの
• 理想的な上司と部下の関係とは――部下の育成方法
• 続・いまのIT組織でいつまでやっていきますか？
• いまのIT組織でいつまでやっていきますか？
• ITの動向や他社の状況を、気にし過ぎていませんか？
• IT化と投資の“正しい”関係とは？（後編）
• IT化と投資の“正しい”関係とは？（中編）
• IT化と投資の“正しい”関係とは？（前編）
• ブレークタイムでの話題製品と情報化のコンセプト
• “誰にでもやさしい”ITは良いことなのか？
• ブレークタイムに“設計思想”を語り合おう
• 仕事への取り組み方は最初の数カ月で決まる！
• 優秀なスタッフを育てる職場環境とは
• 全社IT最適化のカギは「データ体系の統一」