プロジェクトやシステムの「見える化」に、改めて目を向ける時期に来ている。背景にあるのは、「クラウド」へと急速にシフトしつつあるコンピューティング環境の変化だ。サービス中心、ネットワーク中心へとシステム形態が変わり、システムはいっそう複雑化するとみられる。そうした中、いかにきめ細かくリソースとコスト、納期、品質を管理してユーザー満足度の向上につなげるか。本稿では、クラウド時代でも通用する見える化の方法を、筆者の経験を踏まえながら紹介する。 ※本記事はNTTデータ発行の「USInsight vol.39 Spring 2010」の記事を編集して掲載しています。
情報システムの歴史はメインフレームに始まり、クライアント/サーバーによるオープン化、サーバーの仮想化、システム基盤のクラウド化へと進んでいる。システム形態の変化に伴い、かつては業務の一部を代替するものだったコンピュータの役割も、業務の遂行に必要不可欠なものになった。同時にシステムの大規模化と複雑化が進んでいる。こうした中、プロジェクトを成功させるために、システム開発の各フェーズにおける「見える化」はもちろん、個々の開発者が担当すべき仕事を明確にすることの重要性が日増しに高まっている。
以下では、まずシステム開発のフェーズを細かく分解し、どうしたら徹底した見える化が可能になるか、その実践方法を見ていく。続いて、プロジェクト管理という、どちらかというとマクロな視点での見える化についてもポイントを整理する。
企画・要件定義の見える化、非機能要件の合意を形成
アジャイル型やウォーターフォール型などの手法に関係なく、システム開発は大まかに(1)企画、(2)要件定義、(3)設計、④コーディング、(4)テスト、(5)リリース、(6)運用というフェーズからなる。そして、それぞれのフェーズにおいて見える化が可能だ。
システム要件を見える化する最大の目的は、開発するシステムの要求条件をユーザー企業と合意し、満足度を高めることにある。このとき大切なのは、「非機能要件」を明確にすることだ。大手システムインテグレータを中心とする検討会は、「非機能要求グレード」という用語を用いて、非機能要件を整理する重要性を次のように説明している。
非機能要求グレード検討会では非機能要求の見える化と確認の手段を実現するため「非機能要求グレード」を検討しました。非機能要求グレードでは要件定義工程までに確認が必要な非機能要求項目を体系的に整理し、項目ごとにレベル付けした選択肢を提示することで、これまで受発注者の間で曖昧な表現で意識あわせをしてきた内容を明確に共有することができます。（同検討会のWebサイトより）
同検討会はこれまでに、要件定義に盛り込むべき「システム基盤の非機能要求に関する項目一覧」を公開、次の6つの大項目を中項目から小項目へと細目化している。
- 可用性：システムの耐性
- 性能・拡張性：システムの応答速度や増設のしやすさ
- 運用・保守性：システムの維持のしやすさ
- 移行性：システムの更改のしやすさ
- セキュリティ：データの安全の度合い
- システム環境・エコロジー：環境への配慮
この一覧は、発注者であるユーザー企業と受注者である開発者との間で、システム応答速度や維持のしやすさ、環境への配慮といった非機能要件を検討する際のチェックリストとして有効利用できるだろう。
システム利用方法の想定シナリオも作成する
非機能要件の見える化以外に、筆者が重視しているのが、「ユースケースシナリオ」の作成である。これはシステムがどういった局面で使われるかをユーザー企業と一緒に検討し、想定される一般的なユーザー像を基にシステムの利用方法をシナリオ化したもの。要件定義の早い段階で、目的のシステムがどのように使われるのかユースケースシナリオにまとめておくことで、設計フェーズにおけるUML（Unified Modeling Language：統一モデル言語）のユースケース（後述）が策定しやすくなる。
一般的に「ペルソナ/シナリオ法」と呼ばれる手法を活用し、ペルソナ（架空の人物）を登場人物とする物語（シナリオ）を作る。そして想定されるシステムの利用パターン、すなわちインタラクションやシステムの振る舞い、機能を明確にして、デザインの要件を確定していく。
成果物はシステム利用のシーンを文章で表現した物語となる。個々のシーンは、利用者が何を目的にどのような状況で何を考え、または感じながらシステムを操作するかを示しており、ユーザーの行動を想定しながらデザインするための基礎情報になる。実際、筆者は主な利用シーンを全体のサービスイメージとして絵を描いて添えるようにしており、ユーザー企業との要件の意識合わせに力を発揮している。
設計の見える化、モデリングによって意思疎通
設計フェーズで見える化を進める目的は大きく2つある。1つは、開発者間で意思を疎通しやすくすること。もう1つはユーザーとの意思疎通を促進し、合意を形成しやすくすること。
情報を正確に伝達する手法の1つに、設計書を単純な図形で示すモデリングがある。先に少しだけ触れたUMLは、ソフトウェア工学におけるオブジェクト指向開発のために標準化された仕様記述言語であり、モデルの記述様式を形式化･標準化した代表例だ。ユースケース図（図1）、シーケンス図、状態遷移図、クラス図、コンポーネント図、配置図の作成に用いることができる。
UMLを使うことで、誰もが同じルールでモデルを書くことができるといったメリットがある。さらに、矢印や四角など簡単な記号の意味を一度学習すれば、誰でもモデルを理解できるという利点もある。しかし、図が単純なためにUML以外の設計図も作成して補完した方がよいケースは少なくない。例えば、システムアーキテクチャの概観などはUMLだけでなく、ブロック図によって内容を補うことが意思疎通を図る上で大切だ。
会員登録（無料）が必要です
- 1
- 2
- 3
- 4
- 次へ ＞
- ERP導入企業は34.8％、経営改革や業績管理に活用する動きも─ERP研究推進フォーラム/IT Leaders共同調査（2013/02/07）
- ツールの効果的活用で機能品質高め─テスト工程のあり方を見つめ直す（2013/01/29）
- IaaSを利用する際、これだけは押さえておきたいセキュリティのツボ（2012/10/18）
- これからIT部門が育てるべき人材像とは（2012/08/24）
- ベテラン社員に技術やノウハウが偏在、情報システム部門の技能継承が課題に（2012/07/19）
