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

業務システム構築の初期段階におけるシステムの概要設計について考える。これから構築するシステムには“直感的なイメージ”があるだろうか？ これは、その後の段階における指針となる重要な作業でもある。

[山村秀樹，＠IT]

プロジェクト立ち上げ段階の作業

　ある課題を解決するために、複数の部門にまたがる業務を範囲とする大規模なシステムが必要と考えられる場合、トップマネジメントから、関係する業務部門とシステム担当部署にその検討が命じられます。ほとんどの場合、システム担当部署が中心となり、業務部門の協力を得ながら、業務やシステムの概要を検討、開発費用や期間、プロジェクトチームの規模などの見通しを立てます。その結果をトップマネジメントに報告し、プロジェクトを進めるのか否か、規模は適切か否かなどに関する指示を待ちます。

　この連載では、ここまでを「プロジェクト立ち上げ段階」ということにします。普通、システム担当部署の管理職がこの作業を担当し、そのままプロジェクトリーダーとなります。余談ですが、それなりの権限を持つ人がプロジェクトリーダーを担当するのは、作業の性質を考えれば当然のことです。プロジェクトは金額的に大きな取り組みであり、成功の責任が求められます。また、各関係者に対しても、システムの機能や性能に責任があります。責任を持つ人が権限を持っていなければならないのは当然であり、逆に、権限のない人に責任を負わせることはできません。権限のない人の責任は、自らの作業に対する責任、意見具申の義務に対する責任に限られます。

　トップマネジメントからプロジェクトを進めるよう指示されると、プロジェクトリーダーはプロジェクトチームを編成し、より詳細な見積もり要求仕様書（RFPのことです。この連載では、できるだけ英文字略語は使わない方針です）を作成してベンダに提示します。ベンダから見積回答仕様書と金額などを受け取り、交渉を経て、その内容に関して合意することができると、トップマネジメントに予算を含めたプロジェクトの承認を求めます。

　プロジェクト立ち上げの段階では、検討や計画といっても、目安となる程度のことしかできません。多くの時間は与えられないでしょうし、また、緻密（ちみつ）な調査や分析などは要求されません。費用やエネルギーを掛ける価値があるのか、必要であればおおよそどの程度必要なのかを把握することが目的です。エネルギーを本格的につぎ込むのは、この後の作業であるプロジェクトチームを編成して見積要求仕様を作成する段階からです。

　できれば、この段階から、パッケージソフトやWebアプリケーションなどといった選択し得るシステム形態や技術の特徴を調べておきます。詳細はベンダに説明を求めればよいので、簡単なレベルで結構です。構築が速くできる、安くできる、エンドユーザーに親切、メンテナンスが容易、既存の資産が使えるなど、形態や技術ごとのメリットやデメリットを知り、システム構成までイメージしておくことは、この後の作業を進めるうえで有益です。

システム概要を検討する

　まず、開発するシステムの概要を構想します。課題に関係する部署に出向いて、現在の状況や、問題点と考えていること、要望などを一通り簡単にヒアリングします。その結果を整理し、どのような業務、システムであれば良いのかを考えます。また、その部署に関係を持つほかの部署や取引関係などについても聞いておきます。これは、関係者の漏れを防ぐためだけではなく、それぞれの業務を別の角度から見ることによって、業務に関する知識を広げる効果があるからです。既存システムの更新プロジェクトであれば、上記以外に、システムのドキュメントに目を通したり、未処理のシステム改善要求や過去のトラブル履歴を調べたりする作業があります。

システム化を批判的な目で見る

　システム開発失敗の経験がある人や、普段からIT系Webサイトや雑誌・書籍の記事などで開発事例を研究している人であれば、システムを構想する際には、システム化について批判的な見方ができ、システム化するとしてもその範囲を極小化する方向で検討していると思います。具体的には、コンピュータ・システムによらずに、業務上の工夫で課題を解決できないかと考えたり、いま考えている機能は本当に実装する価値があるのかと考えたりします。

投資効果の面から見る

　コンピュータ・システムの開発には、多くのお金や時間、エネルギーが必要です。その投資に対して効果を考えることは当然のことで、効果が見合わない機能はシステム化せずに、投資額を圧縮することは当然のことです。開発期間もその分短くて済みます。また､その企業あるいは事業所全体で考えた場合、そのシステム開発以外にも投資を必要としている案件があるかもしれません。システム化予算を圧縮した分をそちらに回した方が効果的ではないか、ということも考えるべきです。

リスクの面から見る

　一部の人々がシステム化を批判的な目で見る理由には、コンピュータ・システムの開発にはリスクが多いということを知っており、リスクコントロールをしているということもあります。簡単にいえば、機能要求仕様のボリュームは必ず膨れ上がるものであり、絞り込んだ状態で検討を始めてちょうどいい具合になる、という考えがあるということです。リスクをもたらす可能性のあるものを除外したり、あらかじめ､リスクを受け入れる余地を用意したりしているのです。

　既存システムの改善をしたくても予算が取れずにできない状態が続いていると、プロジェクトが動き出した機会に何でもかんでも要求を詰め込みたくなります。しかし、これはかなりリスキーといわざるを得ません。いま、システムの改善ができない理由は、そのシステム開発プロジェクトが失敗だったからではないでしょうか。つまり、何でもかんでも要求を詰め込み過ぎ、しかも、その要求がコロコロと変わった結果、システムが複雑怪奇なものとなり、改造コストが高くなっているのはないでしょうか。リスキーといったのは、このことを繰り返す恐れがあるということです。

ファーストインプレッション（初心）を大切にする

　ただし、前述したように、この段階で緻密（ちみつ）な計画は要求されません。目的は、ファーストインプレッション、つまり、第一印象をつかんで、プロジェクトが成り立つかどうかを判断し、プロジェクトの基礎となる計画のたたき台を作ることにあります。この段階で、機能の要不要を決定することはできません。より緻密（ちみつ）な調査を進め、業務の詳細が明確にならないことには、本当にその機能が必要なのか不要なのか判断しようがないからです。

　この段階での、いわば直感的なシステム構想は、今後、システム開発が進んでいく中で、思わぬ方向に進むことを防ぐチェックリストの役割を担います。初心に戻るといいますか、折を見て当初の想定とその時々の機能要求をチェックすることで、システム化の目的の逸失や肥大化を防ぐことは、プロジェクトを失敗から救います。

仕様はさまざまな声に影響される

　コンピュータ・システム開発の特徴の1つに、機能要求仕様が機械設備以上に関係者の声に大きく影響されるということがあります。プロジェクトリーダーが承諾ないし気付かないうちに関係者の声が機能要求の中にどんどん入り込んできます。これは自然現象のようなものです。これに対して、システムに対する機能要求が適当なレベルに収まっているかモニタリングすることが重要であり、正常な状態を維持する活動を行わなければなりません。最初に想定したシステムは直感的で、混ざり物がなく、シンプルなものであるはずです。これを指標としてチェックを繰り返せば、無理、無駄を早期に発見することができます。

　例えば、業務部門が簡単な操作で任意にデータ加工できる手段（EUCのこと）を用意しておき、それを活用することで帳票の数を抑えるのが当初の構想だったのに、いつの間にか、多種多様の帳票を用意することになっている場合があります。この場合、プロジェクトはコスト高、スケジュール遅れの方向にシフトしているといえます。コミュニケーション不足によりプロジェクトチーム内でのシステム・イメージの共有が徹底されていないなど、チームマネジメントに問題があるのかもしれないため、対応策を考えなければなりません。このようにチェックできていれば、プロジェクトを健全な状態に保てます。

　そもそも管理とは、健全な状態を維持するための活動であり､健全な状態をイメージしておく必要があります。ついでながら、数値や記事を収集して資料を作るだけなら管理とはいわないことを付け足しておきます。

初心は忘れやすい

　初心は忘れやすいものです。「忙しいとは、心を亡くす」と書くように、忙しいときはチェックする時間がないだけではなく、チェックするという心構えすら忘れてしまいます。プロジェクトに限らず、マネジメントを担当する人にとって理想の環境とは、具体的な作業を持たないで余裕を持って管理監督作業をすることですが、現実には、要員が少ないこともあり、現場で力をちゃんと出せるリーダーが望まれています。プロジェクトリーダーの作業は量も多く厳しいものとなりますが、この段階で想定した内容を記録しておき、スケジュールにあらかじめこの想定との比較チェック作業を織り込んでおくなどの工夫が有効です。

　システムが出来上がってから、「最初に考えていたとおりにしておけばよかった」とは、比較的よく耳にする言葉ですが、これは「折を見て当初の案とチェックすべきだった」と現実的に解釈すべき言葉と考えます。