2006/10/11

                                          『良いシステムと悪いシステム』

                                          ―運用を考慮したシステム設計―

　1.開発の留意点

ユーザーが開発者に同じように業務システムを発注し、同じように出来上がってもシステムのライフサイクルを通して見ると大きな違いが生ずる。その理由は構築する時に運用を考えたか否かである。住みやすい家と住みにくい家があるように運用しやすいシステムもあれば運用しにくいシステムもある。運用しにくいシステムでは障害も多発し、運用時の費用も莫大なものとなる。さらに金融商品取引法に対応するには最初から作り直す外無いシステムすらある。目先の費用を最小にするため要求された機能だけを追及すると長い目で見てかえって費用が嵩み、安物買いの銭失いのそしりをまぬかれなくなる。

　システムを構築する際重要なことは、要求機能を充足するだけではなく次の3点を常に留意しなくてはならない。

　システム開発にあたって留意すべき3点：

　(1)利用者（エンドユーザー）に使い易く信頼されるシステム

　(2)保守・運用を含めた総費用（トータルコスト）削減を対象にする

　(3)長期に渡って使用可能であること

　2.システム品質

システムの品質は高機能・多機能で測るべきではない。品質が100％というのは障害がまったく無いことであって、いろいろなことができることでは無い。高機能と品質とは異質の概念であることを認識しなくてはいけない。品質の評価は以下のRASの3原則を持って測らなくてはならない。

RASの3原則：

　(1)障害が少ない(Reliability)

　(2)長期間連続して使用できる(Availability)

　(3)障害が発生しても回復が容易である(Serviceability)

3.運用の原則

システムを開発する時から運用段階を想定して開発する必要がある。以下のような運用原則をまず当事者間で取り決め合意すべきである。

運用原則：

　(1)利用部門

  　データの責任は利用部門が持ち、運用部門や開発・保守部門にデータの中身を変更させない。ソフトウェアのスキルは不要とし操作手順書に基づき操作する。

  (2)運用部門

　　本番ライブラリィに責任を持ち、開発・保守部門に直接ライブラリィを変更させない。

　　操作員は運用手順書に基づき監視・運用し記録をとる。

  (3)開発・保守部門

　　開発ソフトウェアだけを対象とし本番データや本番ライブラリィを取り扱わない。

　　操作手順書・運用手順書を作成・保守する。

4.開発原則

　運用を考慮した開発原則を取り決めアプリケーション開発チーム全員に徹底する必要がある。

開発原則：

　(1)異常データやデータ0件の場合でも異常終了しない

　(2)適切なチェックポイント（概ね30分）をとり、リランのロスを最小限にする

　(3)データの保守・削除・圧縮のしくみを準備する

　(4)以下の法律・原則を始め国内法や業界標準に準拠する

　 商法・金融商品取引法（J-SOX法）・企業会計原則・ITIL・ISMS・CMMI・GSD331

　(5)RAID-5以上のディスク障害対策をとる

　(6)システム全体のバックアップを持つ

　(7)誤入力しないようデータ入力でチェックする

　(8)バージョンアップに容易に対応できるようにする

　(9)適切なガイドを組み込みマニュアルの参照や問合せを減らす

　(10)障害を検知し自動的に報告するしくみを持たせる

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上