本文へジャンプ

ミドルウェア

uVALUE 実業×IT

Hitachi

第14回:SIサービス工業化の時代にユーザ企業が学ぶべきこと(2)

〜情報処理システム開発案件のフェーズを理解する

株式会社ノークリサーチ

ユーザにもメリットがある情報処理システム構築における変化の兆しとして、前回は「工事進行基準」を取り上げた。 自社の業務に適した情報処理システムを構築するためには、SIerに任せきりにするのではなく、ユーザ自らが構築過程に参画する姿勢が求められる。

とはいっても、何から始めて良いかわからないケースも多いだろう。

そこで、今回はシステム開発案件の基本的な考え方である「フェーズ」について解説することにする。

第13回 工事進行基準とは何か?
2009年4月から受託ソフトウェア開発にも「工事進行基準」が適用される。
この基準が情報処理システム開発にもたらす影響とそれに伴ってユーザが知っておくべき事項について解説していく。
第14回 情報処理システム開発案件のフェーズを理解する
情報処理システム開発には「要件定義」「設計」「開発」「テスト」「運用」といったステップが存在する。このステップは「フェーズ」と呼ばれ、今後ユーザが自社の情報処理システム構築を成功させ、SIerとの良好な関係を築くためには必須の知識である。
ユーザの視点からの「フェーズ」をわかりやすく解説する。
第15回 個人の持つノウハウを業務フローに落とし込む
工事進行基準などのルール、そして情報処理システム開発の「フェーズ」を理解することによって、ユーザ側の情報処理システム構築スキルは大きく向上する。しかし、こうしたスキルをきちんと社内で共有しておかないと、同じミスを繰り返してしまうことになる。
ここではノウハウ蓄積と共有のノウハウについて解説していく。

情報処理システム開発案件のフェーズを理解する

「フェーズ」とはシステム開発案件の段階や工程を表す言葉である。

「フェーズ」の定義は様々だが、ここでは以下の五つのステップからなる最もシンプルかつ基本的なものを取り上げる。

要件定義

何のためのシステムなのか?そのシステムをユーザはどう取り扱うのか?といった「ユーザ視点」でのシステムの目的や利用方法を決めるステップである。
当然ながらユーザ側がしっかりとした要求事項をドキュメントの形で明示することが重要なポイントとなる。

設計

要件定義の内容をシステムの言葉に置き換えるステップである。どんな技術を使ってシステムを構築し、どういう仕組みで動作させるかをSIerが考え、それをドキュメントとして書き記す。

開発

設計ドキュメントに従い、プログラミングやインテグレーションによって実際にシステムを組み上げるステップである。一般的には全ステップの中で最も大きな作業量を占める。

テスト

組み上げられたシステムが意図通りに動作するか?不具合はないか?をチェックするステップである。実際には開発とテストは交互に行われることもある。
またテスト自体にも何種類かあり、小さなプログラム部品の動作確認を行うものから、システム全体のデータ連携テストを行うものまでいろいろある。

運用

構築された情報処理システムの利用が開始されるステップである。システム利用方法に関するユーザ教育や旧システムからのデータ移行などが行われることもある。

基本的なフェーズ定義
基本的なフェーズ定義

この五つのフェーズのうち、ユーザが最も注意を払うべきステップはどこになるだろうか?

もちろんどのステップも重要であるが、ユーザ側の影響力が最も強いのは「要件定義」のステップである。

「どのようなシステムが必要なのか?」をSIerに正しく伝えることができなければ、仮に納期と予算をクリアしたとしても出来上がったシステムは自社にとって役に立たないものになってしまう。

「システムのことは良くわからないので」と放任してしまうのではなく、IT用語でなくても構わないので、自社の課題や要求をはっきりと伝えることが重要である。

しかし、ユーザ自身もどのようなシステムを構築すれば良いのかわからない場合も少なくない。構築されるシステムの具体的なイメージがない段階では、何を要求すべきなのかをドキュメントに記すことも難しいだろう。

そうした背景を受けて、「フェーズ」にも様々な工夫がなされてきた。

とりあえずプロトタイプ的にシステムの雛形を作成し、それを元にして徐々に機能を追加する「プロトタイピング」や「スパイラル」と呼ばれる方法、ユーザから見た場合の機能単位に反復的な開発を行う「RUP」と呼ばれる方法などがその例である。

これらはいずれも「全ての要件定義を最初の段階で明確にすることは難しい」という前提に基づいている。

それだけ、ユーザにとってもSIerにとってもシステムに求められる要件を始めから確定することは難しいことであるといえるだろう。

プロトタイプ/スパイラル
プロトタイプ/スパイラル

RUP
RUP

こうした状況に対し、近年登場してきたのが「モデル/パターン指向」のアプローチである。

情報処理システムには情報系(グループウェアやメールなど)や基幹系(財務会計、人事給与など)といったある程度の種別がある。ユーザ独自のシステム開発の場合も、よほど特殊なものでない限りはそれら種別のいずれかに分類できることが多い。

そこで、過去の様々なシステム開発案件で得たノウハウを体系化し、それを雛形としてシステム開発に活用するのが「モデル/パターン指向」のアプローチである。

この方法であれば、ユーザは白紙の状態から自身の要件を書き出す必要がなくなり、提供された雛形を元にして自社に適した選択肢を選べば良いことになる。SIer側もあらかじめ用意された雛形を土台としたシステム開発が行えるため、的確なユーザ要件の汲み取り、開発工数の短縮、品質の向上といったメリットを享受することができる。

もちろん、ユーザが提示する全ての要件がモデル/パターンの選択のみで満たせるわけではない。しかし、白紙の状態から要件を描き出す場合と比較すれば、効率面やコスト面での差異は明らかだろう。

こうした取り組みの代表例がパートナSIerに対して日立製作所が提供する「uCosminexus SI Navigation System」と呼ばれるツールである。

パートナSIerはこのツールを使って、ユーザの要件に基づいたモデル/パターンを選択し、それに基づいたシステムの詳細設計に描き出すことができる。

さらに運用に必要な各種パラメータの設定やバッチ処理の自動生成まで行うことができるのである。

従来の手法とモデル/パターン指向との比較
従来の手法とモデル/パターン指向との比較

このように情報処理システム構築は人手に頼る方式から工業的な手法へと徐々に進化しつつある。

その進化の恩恵を受けるためには、SIerだけでなくユーザ側もある程度情報処理システム構築の流れを理解しておくことが重要である。本稿がその助けとなれば幸いである。

さらに大切なことはこのようにして得た知識を一部の個人に留めず、企業としてきちんと共有した上で継続的に活用することである。

そこで次回は知識共有のために何をすべきか?について述べていくことにする。

次回予告

第15回 個人の持つノウハウを業務フローに落とし込む

工事進行基準などのルール、そして情報処理システム開発の「フェーズ」を理解することによって、ユーザ側の情報処理システム構築スキルは大きく向上する。しかし、こうしたスキルをきちんと社内で共有しておかないと、同じミスを繰り返してしまうことになる。
ここではノウハウ蓄積と共有のノウハウについて解説していく。

特記事項

  • 記載されている会社名、製品名は、それぞれの会社の商標もしくは登録商標です。