要件定義

要件定義とは、システムの開発や改修に先立ち適用される領域の業務を明確にしシステム側に要件を明確にする、ソフトウェア開発の一プロセスである。

かつてのシステムは、非常にシンプルなものであった。企業・社会の中でのシステムの位置付けは、人が手作業で行っていた単純な計算作業を代わりに行う電卓の延長のようなものである。しかし、ハードウェア・ソフトウェア・ネットワーク技術の発達と共にシステムが行える事が幅広くなり、社会・企業のあらゆる領域に進出した。今や、企業の中核で重要な経営判断をサポートするまでに広がっている。それに伴い、代替する業務の内容は複雑化し、技術者はシステムを開発する能力のみでその責務を果たす事は難しく、システムをとりまく業務を含めてデザインする能力が求められるようになった。技術面でも、複雑化に対応するため、オペレーティングシステム・ミドルウェア・フレームワーク等、多くの実現方法を生み出し、技術者はシステムに求められる要件から最適な実現方法を選択する能力が求めらるようになった。これらの業務に従事する人材を日本ではSE(システムエンジニア)と呼ぶ。今やIT業界に置いて、プログラミングのみが行えるプログラマは重要視されない存在となっている。

システム開発のプロセスを大別すると、「要件フェーズ」→「設計フェーズ」→「製造フェーズ」→「試験フェーズ」に分類できる。この構造は建築の手法によく似ており、日本に置いてはその業界構造まで類似する点が非常に多い。ただし、システム開発は50年程度の貧弱な歴史故に、未だよちよち歩き状態であると言わざる得ない。品質・コスト・納期、この全てが超過することなく基準内で収まるプロジェクトを成功と定義した場合、IT業界におけるプロジェクトの成功率は約30%と言われている。これは建築業界の半分以下という、異常な数値である。それだけ、システム開発プロジェクトは大きなリスクを抱えているのである。このような背景において、プロジェクト成功の命運を握るのは、「要件フェーズ(≒要件定義)」であると言われている。その理由としては、以下の通りである。

1. システム導入の効果を決定する。
まず大前提として、お客様である企業に対してシステムを導入してお金を稼いでもらうことが必須となる。企業はシステムを入れたことにより儲けられるから、システム開発者にお金を払うのである。近年は効果の不透明となる多くのシステムが登場しているが、根底の仕組みは変わっていない。この効果を大きく決定するのが、儲ける方法について検討するフェーズ、つまり要件フェーズなのである。ここを疎かにした場合、例えば実際の業務に全く適合しないシステムが完成し適用に失敗したり、非効率化により生産性が低下したりと、企業は大損害となる。どんなモノであれ最低限儲けられるような作りでないと、システムは場所と電気を食うただの箱になる。

2. 不備の発見が遅いほど、コストが多くかかる。
プロジェクトは、工程が後になるほど、初期の工程で発見された不備の修正に多くのリソースを要する。通常、要件フェーズはプロジェクトの初めに行う。近年、要件定義を長期化させたり、開発プロセスの中で頻繁に行いフィードバックを行うような技法も登場したが、未だ大規模システムの開発現場では、要件を早期に確定し、慎重に積み上げるようにシステムを開発するウォータフォールモデルベースな開発手法が多い。したがって、要件フェーズで発見された不備は常に、多くのリソースを要し、コストや納期をひっ迫する。

これだけ重要な要件フェーズであるが、「設計フェーズ」や「製造フェーズ」に比べ非常に難易度が高い工程である。設計には数多くの解決技法が生み出され要件定義の成果からほぼ導出的に解決方法を導く事が可能になっているが、要件フェーズにはこれといった技法が存在しない。用語一つとっても全く統一が行われておらず、業界を取り巻く環境や特有の問題点も刻一刻と変化していく。プログラミングには正しく動くという確実な「解」が存在するが、要件定義では解を追求することができない。環境は刻一刻と変化し、その瞬間ごとに要件は変化する。完全であることよりも、妥当であることが求められ、明確な指標すら存在しない対象の落とし所を探すことに多くの時間を要する事も珍しくない。

本頁では、要件定義について、最低限確定すべき大枠の部分として以下を挙げる。

1. システムの目的
2. システムスコープ
3. 制約条件と前提条件
4. 機能要件
5. 非機能要件

システムの目的

要件定義は、システムを開発することを前提として進めてはいけない。問題の解決方法は、人間の手作業やExcelなどのツールの方が、ベストなソリューションな場合もある。この工程では、対象の業務に眠る問題の真因を探り、根本的な解決法を見つけなくてはならない。このため、対象となる背景はできる限りクリアに、目的は掘り下げてできる限り深く追求する。

「システムの目的」は初めに明らかにすべき重要な点である。目的は、システムの適用範囲であるシステムスコープの確定、システムが提供するサービスの機能である機能要件、性能である非機能要件を決定する。例えば、「ミッキーマウスのいる遊園地で思う存分水を浴びる」という目的があったとする。このユーザへろくなヒアリングも行わず、「ねずみのいる王国で高速な乗り物に乗る」というあいまいさのある言葉を信じてプロジェクトを開始したとしよう。SEはユーザをまず、フェラーリでドライブするサービス(機能)を薦めることにした。また場所(スコープ)は、鼠もかつて大量発生したし、イタリアにしておけば間違いないだろうと判断した。フェラーリに乗せられたユーザは「この乗り物では、水が一滴も侵入してこないじゃないか。水を浴びさせろ」と文句を言う。SEはここで、水を浴びる乗り物に乗れるサービスでないといけないことに気がつく。次に、SEはユーザを海へ連れて行きカヌーに乗ることを薦める。今度は「ミッキーマウスはどこだ!」と文句を言う。ここに来てようやくSEは、ミッキーマウスがいる領域(スコープ)で、それを実現しなくてはならないということにも気がつく。そもそもイタリアにいては、ミッキーマウスのいるディズニーランドに行けない。SEはソリューションの提供が可能な、千葉へ場所(スコープ)を移す。そしてまた一からユーザの要望をかなえることができるサービス(機能)について検討する。

このSEは目的を明確にしなかったせいで、千葉へ行き、ディズニーランドの入場料を払い、スプラッシュマウンテンの登場チケットを買えば解決できたソリューションを、イタリアの往復チケット、フェラーリとやたら高いコストを支払った。また、時間も多く無駄にしている。目的確定のプロセスとは、例え足踏みに感じても、確実にクリアする必要のある重要なステップである。多くのリソースを無駄にしない為にも。

目標確定のプロセス

システムの目的は、目標ではないので、定量的に評価できないものが多い。しかしこれは多くの場合問題にならない。最も重要なのは、その目的が簡単なことで揺れないことである。目的がブレたり、あるいはプロセスに溺れると、真に解決したい課題は解決されない。何があっても常に「真」である目的を立てて、これを解決するため様々な方法を検討することが、問題の効果的な解決法なのである。

これを行う方法として、トヨタの「なぜなぜ分析」と呼ばれるものがある。トヨタでは、何か問題が発生した際に、必ず「なぜ?」という問いかけを5回繰り返し、そこで得られた問題の真因に対して対策を講じる。「発電機が故障した」というシーンを想定してその真因について分析してみる。

問題:発電機の部品が故障した。
(1) なぜ?:オイルが部品に付着したから。
(2) なぜ?:近くのチューブのネジが緩み、オイルが漏れたから。
(3) なぜ?:ネジが緩みやすく、振動に弱いから。
(4) なぜ?:工場の機械が、ネジを十分な強さで締めないから。
(5) なぜ?:機械がネジを十分な強さで締めているか、チェックする仕組みがないから。

もしこの問題をなぜ1回で解決したとする。メンテナはオイルを拭き取り顧客へ製品を渡すが、しばらくしてクレームと共に再び製品が返却されてくることだろう。このメンテは永遠にオイルを拭く仕事に従事する必要がある。また2回で解決したとすれば、多少負担は減るものの、メンテナには常にネジを締める仕事が飛んでくる。しかし、5回なぜを繰り返したらどうなるだろう。定期的に工場の機械のメンテナンスを行うことなんて、その機械から生産された大量の製品のメンテナンスを行うことに比べたら微々たるものである。浮いた時間を別の活動に利用できるようになり、生産性は向上する。このような改善の繰り返しが、全体として大きく生産性を高める。世界的な企業となったサムスンでは、これより2回多い7回何故を繰り返すと言われている。システム導入を効果的に行う上で真因を発見するための活動は、非常に重要であるということが認識できたであろう。

問題を掘り下げた先にある情報システムの真因、そしてそこで得られたニーズは、往々にして以下のうちどれかに該当する。

  • 業務の省力化・効率化
  • 業務プロセスの標準化
  • 業務プロセスの統合
  • 新規サービスの創造
  • 既存のデータ(情報)の活用
  • 経営者への情報提供
  • 従業員の育成
  • 業界・法律の変化への対応

真因によって得られた「あるべき姿」と、存在するのであれば既存の業務とシステムの「現在の姿」を比較し、この差を埋めるような具体性のある目的を立てるのが良い。先にも述べたが、これはシステムのみではなく、人間の手作業を含めた業務というレベルで捉え、評価し、目的を明確にする必要がある。

現在は情報システムが企業に導入されているのがあたりまえなので、「現在の姿」から「あるべき姿」を導出するボトムアップな方法についても考えることができる。このような場合は、リチャード・L・ノーランの「ステージ理論」が参考になる。ステージ理論とは、「企業が利用する情報システムはさまざまな段階を経て発展していく」という考えに基づくもので、各ステージの持つ特徴を既存システムの特徴と照らし合わせ現状を把握した上で、次に進むべきステージを明らかにするという手法として役立てることが可能だ。

①コンピュータをコスト削減の目的で使い始めた時期
②バラバラにコンピュータを増設していく時期
③投資と効果を明らかにして全社的な立場で導入する時期
④データベースを活用する時期
⑤分散ネットワークと情報共有化をはかる時期
⑥戦略的情報システムを活用する時期

この手法は要件定義と言うよりもっと前の段階、つまりシステム化戦略や全体最適化計画というフェーズで用いられるものである。

システムスコープ

システムスコープは、業務の中でシステムが担う責務の範囲である。スコープ内であればシステムの責任であり、スコープ外であればシステムの責任でない。これをはっきりさせるものである。

システムスコープはやることとやらないことを確定する作業なので、一見、品質・コスト・納期を配慮し、強制して線引きを行うような強引なもののように感じる。もしそのように思っているのであれば、改めるべきだ。スコープ外なのでやらないを決めつけたとして、果たしてシステムは目的を達成できるだろうか。スコープの確定は、あくまで目的の達成に必要な領域を明らかにするものである。品質・コスト・納期の制約は、実現方法にて解決すべきだ。

このように捉えると、システムスコープ確定とは、システムの目的確定と同義であると考えられる。スコープの変更は、目的の分析を怠ったが故に生じる、受け入れざる得ない事実である。目的を達成しないことにはシステム導入の効果を得ることができないのだから、そもそも「スコープ外だからやらない」と拒否することは、顧客にとってシステムを導入する必要性を失うということを意味する。


機能要件


部分最適は「悪」だという言葉がある。システム化には、部分的な効果に特化するな。部分的な効果が多少薄くても、全体的に効果が高いという方法を選べという意味である。これは決して、データを統合しろ、業務プロセスを一元化しろという意味ではない。データ統合には信頼性要件にデメリットが生じるし、業務プロセス一元化も例外的タスクに対する柔軟性を奪う。全体的に見て、最適な方向に向かうよう、




  • 最終更新:2010-04-07 19:54:06

このWIKIを編集するにはパスワード入力が必要です

認証パスワード