第133話　経営情報システム24　システム開発管理 - 自称週末ファーマーの国家試験受験記

情報システムという科目があるからSEが診断士試験をよく受験する、というわけではないのだろうけど、SEさんにとってみれば診断士試験の内容など朝飯前なのかもしれませんね。著者が運営管理に一日の長があるように、SEさんには情報システムで一日の長があるということでしょうか。

今回は、レビューから始めようと思います。

１．レビュー
　レビューとは、システム開発の過程において複数の関係者を集めて、設計書やソースコード（プログラム）のレベルに至るまでを評価・検討し、曖昧な点や問題点を洗い出して改善点を提案し、次のフェーズに進み得る状態にあることを確認するために行われる討議や評価のこと。
　レビューを行うことにより、次のような効果がある。
・エラーの早期発見
・ソフトウエアの品質の確保
・プロジェクトメンバの参画意識の向上
・技術者の育成
以下、代表的なレビュー技法は次のとおりである。

１）ウォークスルー
　設計上の誤りを早期に発見することを目的として、各フェーズの終了時点で作成者と複数の開発者が設計書を評価・検討するレビューである。ウォークスルーは、主に設計書やプログラムなどの作成者とその関係者により実施される。

　●ウォークスルー　→　担当者・開発者によるレビュー

２）インスペクション（査閲）
　レビューの開催責任者（モデレータ）がおり、ウォークスルーよりも厳格に行われる。レビューによって指摘された修正・確認が確実に行われたかどうかを追随して監査する点がウォークスルーと異なる。

　●インスペクション　→　開催責任者が進行する。ウォークスルーよりも厳格

３）ラウンドロビン
　ラウンドロビンとは、レビューに参画したメンバが持ち回りでレビュー責任者を務め、全体として作業を均一に分担しながらレビューを遂行していくレビュー技法。メンバーが持ち回りでレビュー責任者になるため、メンバーの参画意識が向上する。

　●ラウンドロビン　→　各メンバ持ち回りのレビュー

では続きです。
次はシステム移行について概観します。

　新しく開発したシステムは、開発が完了すると擬似運用環境でテスト稼動し、その後、実際の運用環境に移行する。システムが大規模であるほど、移行作業は複雑。移行がスムーズに行われないと現場の混乱を招く可能性が高い。あらかじめ、システム移行の方針と手順を明確にしておく必要がある。

１）移行方針の明確化
　移行をマイグレーションというが、現行のシステム環境を新環境へ変更することである。通常は、すでに何らかの情報システムが存在する場合が多く、影響範囲が広い。そのため、大規模な移行計画になることが多い。スムーズな移行作業のためには、システム移行の基本方針を早い段階から明確にしておく必要がある。

（参考）レガシーマイグレーション
　レガシーシステムとは、新規に開発・導入する情報システムに対して、それ以前から利用している既存のシステムのこと。一般的に、メインフレームや大型汎用コンピュータなどによって構築されたシステムを指す。
　レガシーマイグレーションとは、大型汎用コンピュータで構築した基幹システムを、UnixやWindowsのサーバに移行すること。

　●レガシーシステム　→　新規に導入するシステムに対して、既存のシステムのこと

２）基本要件の明確化
①データベースの移行要件
　データの移行に際し、同類のデータを扱うテーブルが存在していた場合、一元化に伴ってデータが重複し、そのままではデータ登録が出来なくなる場合もある。ゆえに既存データの中から何を移行するのか、移行手順はどのようにするかを明確にする必要がある。
②アプリケーションの移行要件
　新旧アプリケーションの仕様を把握し、十分な移行テストを実施したうえで本番作業を迎えることが望ましい。
③ネットワークの移行要件
④業務運用手順の変更要件
　システム移行には、業務手順の変更を伴う。移行時に利用部門が混乱しないように、移行作業の内容、旧システム停止と新システム開始に関する連絡体制やユーザ教育などを明確にする。　

３）移行方式
　移行には、一斉移行方式、業務別移行方式、拠点別移行方式などがある。旧システムから新システムへ移行する場合、全ての機能を一括で移行することは一般的にリスクが大きい。
①一斉移行方式
　システム全体を一斉に移行する方式。リスクあります。
②業務別移行方式
　業務システム単位で移行する方式。新旧システムの連携などを考慮する必要が在り、移行時の運用が複雑化する。

③拠点別移行方式
　拠点ごとに新システム並行する方式。移行負荷を分散できる。新システムで重大なエラーがあっても影響範囲を限定しやすい。拠点間の連携を考慮する必要が生じる場合もある。

（参考）BPR
　Business Process Re-engineering の略。収益や顧客満足度の向上を目的として、業務内容や業務の流れを抜本的に見直すことを意味する。

次の話題です。
システム開発を支援するツールであるCASEツールについてです。

１．CASE（Computer Aided Software Engineering）
　CASEとは、ソフトウェアの開発や改修にソフトウェアを利用すること。また、そのためのソフトウェア（CASEツール）。
CASEによるソフトウェア開発では、対象業務やソフトウェアの構造・設計などをグラフィックなどを用いて可視化して作業を進めやすくしたり、開発工程の一部を専用のツールを用いて自動化することができる。
計画・設計など、ソフトウェア開発の初期段階を支援する上流CASEツールと、プログラム作成・テスト・保守などを支援する下流CASEツールがあり、これらのプロセスすべてに一括して対応するものを統合CASEツールと呼ぶ。

①上流CASE(アッパーCASE)
　基本計画から外部設計までの開発の上流工程が対象範囲。
②下流CASE(ロワーCASE)
　内部設計以降のプログラム設計からプログラミング、テスト、保守といった工程を対象としている。
③統合CASE
　システム開発工程全般をカバーするCASEツール。

２．CASEのメリット
　それぞれの工程で作成したデータを記録蓄積したりリポジトリを使って工程全体を一貫して一元管理するため、整合性の検証や、保守・変更時の影響範囲の確認などを効率的に行うことが出来る。

３．リポジトリ
　各開発工程に生産される成果物を、データ資源として一元的に管理するデータベースのこと。

　●リポジトリ　→　成果物のデータベース

リポジトリが管理する情報としては、開発標準やデータ標準などの規則、プロジェクト管理情報、データモデルや業務フローなどの業務情報、ファイル、レコード、項目などのデータなどがある。

だんだんしんどくなってきました。
もう少し続きます。