 |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| 前のページ 1 2 | ||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
| ポイント別トラブル対応方法 | ||||||||||||||||||||||||||
|
ここからは、上記事例や一般的な事例の中からポイントになる要素を取り上げ、その対応方法を解説していきます。 |
||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||
| 見積書 | ||||||||||||||||||||||||||
|
開発会社から提出される見積書の書式で、業務ごとに分かれておらず「開発一式」などとして、見積額と合わせて1行で表現されることもあります。 小さい規模（金額の低い）のシステムに多く見られますが、やはり分析調査、設計（基本設計、内部設計、プログラム設計）、製造、テストなどと、業務ごとに工数と単価、金額が書かれている方が安心できます。さらに、その見積額に含まれる納品物（ドキュメント、ソースコードなど）も見積書に書かれているべきでしょう。 提出された見積書の書式に不満を持ったり疑問を感じたら、発注側で納得できる形式に修正してもらいましょう。そういうものを疎かにしている開発会社は、それなりの質のシステムしか開発できないと受け止めていいでしょう。 また、各業務項目の「分析調査」は何をするのか？「設計」とは、どういう作業をして、どの時点でどんなドキュメントが作成されるのかということを、きちんと説明してもらって下さい。情報システム部として、発注担当者としては当然のことです。 その内容と、開発スケジュールを照らし合わせてはじめて、スケジュール管理ということになります。 |
||||||||||||||||||||||||||
| バックアップ体制の確立 | ||||||||||||||||||||||||||
|
システム開発の中で、意外と忘れられたり、疎かにされがちなのがバックアップについてです。データのバックアップももちろんですが、システムのバックアップも重要です。 データのバックアップについては、システムの規模や社内運用ルールに依存する部分が多いのですが、外部流出を防ぐ意味で内容を圧縮したり、データの一部をコード変換してバックアップを取る方法をシステムに組み込むなら、機能的にも満足するものにするべきです。テストの段階では、バックアップを取ったり、リストア（バックアップを戻す）するテストも重要ですから、きちんと行ってください。 システムのバックアップ、主にリストアについては、プログラムの単純コピーで済むものから、ネットワーク環境やデータベースなどのツールを構築してから行う場合と範囲が広く、作業も大変になる場合があります。 いくらシステムのリストアについてのマニュアルが用意されているからといって、一度も試さないというのはよくありません。本番運用開始前、テスト期間中に、面倒でも開発会社立会いの元でシステムのリストアテストを行うべきでしょう。 |
||||||||||||||||||||||||||
| バージョンアップ | ||||||||||||||||||||||||||
|
ここで言うバージョンアップとは、稼動させているマシンや、システムで使用しているデータベースを始めとするツールについてです。 新しいOSが搭載されたマシンや、同じデータベース製品の最新バージョンにすぐに飛びつくことは危険が伴います。システムが正常に動かなくなる可能性があるからです。プログラムがOSに依存した手法で作られていたり、データベースに対する呼出し命令が旧バージョンとでは違っているなど、十分な調査を行ってから移行しなければなりません。 長く使い続けるシステムであるなら、設計書にその辺のことをきちんと書いてもらうようにしましょう。数年後、マシンのバージョンアップが必要になったときに何を調査すればいいのか、変える必要があるときにはどこを変えればいいのか、容易に判断できるようにするためです。 バージョンアップが必要なときに、システム開発を請け負ったSEに担当してもらえればいいですが、先のことは分かりません。 |
||||||||||||||||||||||||||
| 予算 | ||||||||||||||||||||||||||
|
始めてシステム発注を行うなど、社内にシステム開発に精通している人材がいなければ、社内で予算を立てることは難しいでしょう。これも経験ですが、何度かシステム会社と付き合い、見積を提示される回数が多ければ、おのずと何にお金が掛かり、どれくらいの規模で開発できるのかが見えてきます。 とは言え、いままで手掛けたシステムとは違う開発環境・運用環境では、未経験と同じように戸惑うこともあるかも知れません。 逆に、例えどんな手法・環境で開発しようと、これ以上の予算は算出できないという、予算に厳しい上限がある場合もあります。（無尽蔵に予算を注ぎ込めることはほとんどないと思いますが…） 発注経験が少ないなら、複数社から見積を取ることをお勧めします。詳しくはこのコーナーのバックナンバーでご確認頂けますが、何度か経験すれば大まかな額が判断できます。つまり社内での予算立てができるようになるということです。 |
||||||||||||||||||||||||||
| 汎用性のあるシステム | ||||||||||||||||||||||||||
|
システム開発を行う際、呪文のように「将来を見据え、汎用性のあるシステム開発を…」という言葉を耳にします。実際これがどの程度実現されているかは分かりませんが、プログラム内部的なことや設計に関してだけでなく、運用ルールやデータの管理方法といったことを、他に稼動しているシステムがあれば、包括的に考えることが重要です。 必要があれば、全システムでデータベースに手を加えるなどして、継ぎはぎだらけのシステムになることを極力避けるべきです。これは言うほど簡単ではなく、テストに時間が掛かるために疎かにされがちですが、慣れることも大切です。 |
||||||||||||||||||||||||||
|
前のページ 1 2 |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
-
-
連載
