 |
「不確実性とITプロジェクト (4)」 河合 一夫：2月号
暗い話題の多い昨今であり，少しでも明るい話題を提供したいと思っている．しかし，本小文がITプロジェクトにおける不確実性のありかたを考えているものなので，明るい話題を提供するのは少し難しい．しかし，ITプロジェクトの失敗の要因としての不確実性だけではなく，それが次につながるものとして，前向きに考えてみたいと思う．この連載では，「不確実性」とITプロジェクトの関係について考えている．不確実性がリスクと同義であったり，不確実性がリスクを内包する概念であったりと一貫した記述となっていない．先回では不確実性がリスクよりも広い概念であると記述をしたが，そろそろきちんと概念の区別を付ける必要がある．不確実性とリスクに関しては，2008年10月号で，今までの概念に捕らわれないリスクへの認識をもつことの必要性を説いた．それがまだ出来ていないことに少しイラつきと反省を感じながら，今回も不確実性とリスクの明確な概念の区別を付けないで進めてみる． 前回までに，要件，見積の不確実さについて考えた．不確実さを考える際には，対象に対する知識の不足(無知であること)や非決定性(これも無知の一種と考えられる)と変動性(ばらつき)の両面から考える必要がある．このうち，変動性に関しては，さまざまな文献でも述べられているし，本小文における目的がITプロジェクトの失敗の要因としての不確実さを考え，それを工学的に扱うための糸口をつかむことを主眼としている．よって，変動性については脇においておき，無知による不確実さを考える．前回まで，要件や見積における不確実さを考えてきた．そのひとつに，変化を引き起こす要因をプロジェクトマネジメントの中に取り入れていないことを述べた(つもりである)．変更に対するマネジメントは，それが発生した時点において，プロジェクトのベースラインへの影響を分析し，最終的にプロジェクトのQCDへの影響度合いをマネジメントすることとされている．変更要求の出所に対して，その要因に働きかけをすることはプロジェクトマネジメントでは扱わない．例えば，発注側においてユーザ要求の把握が甘いことで時間の経過に伴い変更要求が発生している場合，発注側のユーザ要求の分析手法の問題点に踏み込む必要があるが，実際にはそこまで実施しないことが多い．多くは，契約上の取り決めとしてベースライン以降の変更の扱いかたを協議するのみである．そこで，前回は不確実性関係分析を要件定義の段階で実施することをP2Mに盛り込んでもらいたいことを述べた． 先回，IEEE Software Vol.25 No.5のA Replicated Survey of IT Software Project Failuresの報告をすることを述べた．その論文では，11.5%のプロジェクトがキャンセルされ，その大きな要因の一つとして，要件の多さと変更要求の多さが挙げられている．さまありなんという結果である．また，日本情報システム・ユーザ協会(JUAS)が発行しているユーザ企業ソフトウェアメトリックス2008では，要求仕様が非常に曖昧である場合，工期遅延度20%以上の割合が42%を占めているという結果も出ている．これらは計画において不確実さの本質を考える必要性を示している． さて計画という概念は，多様的であり，利用される場面や対象により様々な捉えられ方をされ，様々な計画の形態が存在する．何をどのレベルで記述すべきか，プロジェクトマネージャの力量，チームの組織力が問われるところである．ここでは，プロジェクトの初期段階において作成されるプロジェクトマネジメント計画を念頭におく．計画を作成する段階では，要件や見積の不確実さが形態を変えてプロジェクトマネジメント計画に持ち込まれる．例えば，スコープ記述，品質要求，コスト，要員などに対する前提や仮定条件という形としてである．そして不確実さの形態が変わる典型的なものに識別されたリスクがある．要件や見積における不確実さが，人の認識が及ばない無知に起因していたものが，計画を作成する段階では，それが既知のものであり発生する頻度とその影響を考えてリスクとして扱う．スコープ記述での不確実性からリスクを識別することはPMBOK® で記述はされている．何か，無理やり計画を立案しているようで無理を感じる．不確実性の変化がどうなっているのかわかる方法はないものかと思ってしまう． こうして考えると，計画立案時に評価をする際には，計画への入力となったユーザ要件やそれに対する見積の中に含まれていた不確実さが，どのように変化して計画に取り込まれたのかを考えることが必要となる．計画が進行することで，不確実さの質や程度の変化も発生する可能性がある．ユーザ要件が変化することは前回述べたとおりである．ソフトウェア開発においては，トレーサビリティ情報が重要な役割を果たす．これは要件から実装にいたる各種成果物の関係を明らかにするもので，どの要件がどこで実現されているかを表したものである．これと同じ考えに立つと，不確実さのトレーサビリティ情報が必要であるように思う．もちろん，不確実性は変化をしていくものであるため通常のトレーサビリティ情報と同じような扱いかたはできない．しかし，どの不確実さがどこに影響を及ぼしているのか，その情報がないのが現在のITプロジェクトのマネジメントには欠けているように思う．要件定義におけるSEの無知さが，どこにどの程度あり，それをどのように見積の中で処理し，実際の計画に取り込まれているかがトレースできれば，意味のある計画の評価や検証ができるように考える．前々回の絵にあるように，三段のブランコが実現された別のものになっていたということがなくなるように思える． 現在のプロジェクトマネジメントは，PMBOK?に代表されるモダンプロジェクトマネジメントが全盛であるが，これは1960年代に考えられたものがもとになっている．社会の変化が当時とは比較できないほど早くなっている現在では，次の世代の計画作成の手法やプロジェクトマネジメントの手法が必要とされていると思う．そのキーワードが「不確実性」であることに間違いはないと思う．今回は，次の世代への提言ということで多少明るく終われることができたように思う． |
 |