メディア

最初が大切──構築システムの“概要”を作る：ユーザーサイド・プロジェクト推進ガイド（2）（2/2 ページ）

» 2005年10月28日 12時00分公開

[山村秀樹，＠IT]

システム構成を考える

システム形態、技術の特徴を知る

　具体的なシステム案としては、システム構築費を安くするためパッケージソフトを導入し、業務をパッケージに合わせる方法もありますし、業務が特殊な場合や業務プロセスにこだわる必要があったり使い勝手などきめの細かさを重視したりするのであれば、システムを業務に合わせて作り込む方法もあります。システムを自社で保有しないで、アウトソースする方法もあります。

　作り込むにしても、既存システムの拡張で対応するのか、課題に対して直接的な効果のある範囲のみに限定して新たなシステムを開発するのか、選択肢はいろいろあります。システム化の範囲を広げることにより、さらなる効果が認められるのであれば、これも選択肢になり得ます。

　また、クライアント／サーバ・システム、Webアプリケーション、リッチクライアント、Applet、JavaScriptなど、さまざまなシステム形態や技術があります。どの形態や技術がよいかは、それぞれのケースによって事情が違いますので、一概にはいえません。時間があれば（時間を作って）、よく聞くものに関してのみで十分なので、各システム形態や技術の特徴を調べてみてください。

　システム構成について、ベンダの説明を聞いていると「宇宙人の話を聞いているよう」な感じになることがあります。その程度の説明の仕方しかできないベンダにも問題がありますが、それよりも注意したいのは、ユーザー側プロジェクトチームがベンダの言うことは分からないからと無関心になってしまうことです。アーキテクチャはエンドユーザーにとっての使いやすさやメンテナンス性にも大きく影響します。アーキテクチャに関してもベンダ任せとせず、不審な点についてはあれこれ質問し、納得したりうさんくさいと判断したりできるだけの知識は欲しいところです。

重要な“エンドユーザーの使い勝手”

　エンドユーザーにとって使いやすいシステムであることは重要です。業務プロセスの検討に集中し過ぎてしまい、実務担当者の使い勝手が疎かになってしまうことがあります。また、機能要求仕様の肥大を防ぐために、現場の使い勝手などは「しばらく使っていれば慣れる」などの理由で考慮に入れないこともあります。しかし、これは作り手側の手前勝手な理屈です。

　確かに、個々の業務部門から相反する要求があったり、コストの制約があったりして要求を100％満足することはできません。しかし、システムの使い勝手を“慣れてしまうもの”などと安易に考えてほしくはありません。現に、各業務部門も効率化を求められており、「システムが使いにくく操作に手間が掛かるようになったので残業になった」では困るのです。このベクトル上に、使われないシステムになるという最悪ケースが存在します（詳細についてはこの連載の中で説明します）。

メンテナンスも重要

　メンテナンス性も重要です。業務の停止を招かないようにし、停止に至ったとしても最小限にしなければなりません。クライアントも台数が多くなるとかなりの手間を取られます。クライアント・マシンへのソフトインストールなどのセットアップ作業なしに、Excelなど必ずインストールされているアプリケーションソフトのみを使用することで実現できるシステムアーキテクチャが理想です。

　個人的には、クライアントにWebブラウザだけあれば済むWebアプリケーションが、最もクライアントでの導入作業に手間が掛からないので気に入っているのですが、入力項目の多い画面では、使いにくくレスポンスの悪いシステムとなる可能性があります。この辺りもシステムのケースにより、複数のベンダの見積回答仕様を比較したり、システム開発を依頼するベンダと相談したりして判断材料を収集することになります。あらかじめ、どのような選択肢があるかを少しでも知っておくことは時間の節約にもなります。

他システムとの連携を考える

　企業にはいくつかのシステムが存在しており、新しく開発するシステムとこれらとをどのように連携させるのかも検討しなければならない点です。システム間でデータのやり取りを行う連携のほかにも、統合してしまう方法があります。相手システムの規模や運用コストを検討して、新システムに統合してしまう方がメリットを得られる場合も考えられます。

　複数のシステムで同じデータを使う場合があります。基本的には、データは1つのシステムで一元管理し、データのやり取りのためのインターフェイスを定義して、ほかのシステムは必要なときにこのシステムに要求して受け取るようにするべきです。過去データをサービスするシステム（DWHなど）では、データのメンテナンスが不要なため問題はありませんが、こうした場合を除くと、同じデータをシステムごとに複数用意することはデータの整合性を維持するコストがかかるので勧められません。少なくとも、システムごとにデータを入力するような設計は避けるべきです。

　システム連携を検討するためには、全社的なシステム構成を把握しておかなくてはなりません。業務部門が独自で作ったシステムを含むすべてのシステムを網羅した構成図があれば良いのですが、おそらくそのような図を準備している会社は少ないでしょう。存在したとしても、きちんとメンテナンスされていないのではないでしょうか。機会を見て、努めてシステム全体構成図を整理されることをお勧めします。もちろん、新規システム開発プロジェクトはその機会の1つです。

業務プロセスフロー図を作成する

　また、業務の流れとその中での作業とシステムやシステム同士のかかわりが分かる図があれば便利です。この図を「業務プロセスフロー図」と呼ぶことにします（詳細については次回以降に説明します）。この図は、プロジェクトチームのみならず業務部門やベンダにも活用されるべきで、プロジェクトの中で大きな役割を果たします。この業務プロセスフロー図の作成がユーザーサイドの仕事のメインなのです。

　プロジェクト立ち上げの段階では、以上のことを念頭に置きながら、システム案を考えます。システムの概要が決まったならば、スケジュールやコストのめどを立てます。

プロジェクト立ち上げ期チェックポイント

システム化の必要性、費用効果、リスクなどを批判的に検討する
システムの概要を直感的に把握・認識し、以後の指針とする
使い勝手、メンテナンス性、システム間連携を考慮に入れて、システム形態・技術を調べる

　次回は、プロジェクト立ち上げ段階でのスケジュールやコストの見積もりや、業務部門への協力要請などについて考える予定です。

profile

山村秀樹（やまむらひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、なかでもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

前のページへ 1|2 　　　　　　