 |
|
「ソフトウェアプロジェクトにおける課題とその解決についての考察」 下野 善弘：5月号
昨年末の地点でPMPの資格者が22万人を超え、日本国内でも2万人に届く勢いである。プロジェクトマネジメント(以下、PM)は、元々は建設・エンジ系が中心に適用されてきたが、最近のセミナーや例会などの参加から見てもわかるように、特にITソフトウェア系の参加が多くなってきている。ソフトウェアプロジェクトにおいては規模、複雑度、納期、予算は年々厳しくなっており、PMの必要性が重要視されているためである。考えてみれば、ソフトウェア開発はその結果が一番不確実性の高い人間の資質に依存しているプロジェクトであり、PMの必要性、効果が非常に大きいということは想像に難くない。しかし一方では、ソフトウェアにおけるPMはまだまだ有効に働いていないと感じられることも多い。今回は、要件とステークホルダーの関係にポイントを絞った問題点を挙げ、その解決については、最近憂いている日本の競争力を上げる考察を合わせてしてみたい。 ソフトウェア開発においては数多くの課題があるが、特に要件管理に関わるステークホルダーとのコミュニケーションの出来、不出来がプロジェクトの成功に関係しているケースが非常に多い。仕様が決まらない、また決まったときには変更の影響が予想以上に大きく、品質低下、納期遅延、コストオーバー、機能削減、段階的リリースに陥るケースはその典型である。 実際、要件管理、ステークホルダーは、共にプロジェクトの初期段階で登場し、最後まで影響することから重要であるのは当然のことである。また、要件管理プロセスについては、ソフトウェア能力成熟度モデルCMM(CMMI)においても最初の成熟度レベル2の中にあり、しかも最初に規定されている。このことは私個人も最初は奇妙に感じていたが、実際に計画や進捗管理プロセスよりもまず最初に取り掛かるべきプロセス改善であることを認識してからは、より重要度を理解できるようになった。また、ステークホルダーとのコミュニケーションについても、PMBOKにおいて基本的なPMのベースとしてその重要性が広範囲に述べられている。このように、広く普及した知識体系CMMとPMBOKにおいて重要さが述べられているにも関わらず、実際にはまだまだ十分生かされていないケースが見られるのである。ここでは、3つの例で説明してみたい。 ①まず第一に仕様決定の遅れである。なかなか決まらない仕様も「早く出してください。」だけではずるずると遅れることが多い。「いつまでに出してください。」という依頼でもどの程度の影響があるかわからなければ、大抵の場合忙しい仕様決定者は優先度の高いと判断しているほかの作業を優先し、この仕様決定は後回しにするのは当然である。脅迫めいた要求は、期限通りに出して貰える可能性は高まるが、単にそれだけでは信頼関係を損ね、必要な協力関係を得られず、マイナス面の方が多い。また、要求通りに仕様が出てきても、事前に範囲も何も決めていなければ、想定外の仕様が出てくる場合もある。この場合既に進めている設計の変更や、計画を超えた工数、人員が必要となる。その上、その仕様決定者に漏れや矛盾が無く、ほかとの整合が取れた十分な仕様を決めるスキルが無い場合も多い。不十分な仕様を出して貰えても、そのまま作って問題が起こったらその人の責任でそのまま、もしくはコストをアップして納期を遅らすという訳にはいかず、最終的にはシステムを動かすために緊急対応せざるを得ない状況になるのである。 ②次に仕様の伝言ゲームから起こる問題である。ソフトウェア要件は一箇所からまとめて出てくるのが理想と言われているが、それは単なる形ではなく、内容が伴わなければならない。例えば、実際に使用するユーザー(現場)からの要求で、設備導入責任者(発注者)が取りまとめ、開発依頼先のシステムエンジニアリング担当(SE)に発注し、ソフトウェア案件はソフトウェアエンジニアリングチームのリーダー(SW)に依頼する、という場合を考える。この時、現場、発注者、SE、SWという経路で要件は流れていくのは確かに正しい経路である。現場は現在のことしか知らないこともあり、発注者は今後の計画を考慮した上で現場要求の取捨選択＋必要予想機能の追加をする、SEはユーザー案件からシステム要件をまとめ、ハードウェアを決定した上でソフトウェア要件をまとめてSWに渡す、などそれぞれの立場で責任を持った要件がより詳細に決まっていく。しかし、この中でほとんどスルーで流れる要件、もしくは、情報が不足している要件が存在する。それは、担当者が途中の段階で受け取った要件にあまり興味が無い、もしくは内容が良くわからない場合に起こる。例えば、実際に現場で使用する画面仕様や、ユーザーインタフェースのような使い勝手である。UIは秒単位でコストを計算する現場では非常に重要なこともあるが、SEには興味が少ないことが多い。そして、SWはSEのみを窓口とし、うまく要求を引き出せない、より良い仕様を見つけられない、仕様の漏れが発生する、間違った仕様解釈でソフトが作られる、というようなことが発生するのである。間に人がいると責任の逃げ道にできる意識が働き、後ろに引っ込みがちになるが、結局は工数のかかる機能や不要な機能を搭載することになったり、後での変更を余儀なくされるのである。 ③最後に、依頼元である顧客、一般には前工程のステークホルダーのプロジェクトへの対応スキル、要件定義に関するスキルが不十分なことにより起こる問題である。大きなプロジェクトや問題の起こったプロジェクトにおいて、依頼側に優れたプロジェクト協力者、推進者がいた事が最も大きな成功要因であったことは良く聞く話である。しかし、一般的には依頼側はPMやソフトウェアに関しては素人であり、何もしなければプロジェクトの一員としてプロジェクトを成功に導くという期待よりも、仕様を漏らし、一番最後のチェックでその仕様を追加するなど、足を引っ張るリスクになることが多いのである。 これらは結局は、ステークホルダーとの要件に関するコミュニケーション不足ということになる。このようなことが起こらないように、事前にそしてプロジェクト進行中にも随時必要なコミュニケーションを行なわなければならない。(1)まずは仕様決定者に対して、仕様決定までのプロセス、遅れによるコスト・納期を中心としたスケジュールへの変更影響の理解を得る。(2)また一方的な要求ではなく、こちらからも穴埋め式などのベースとなる仕様の提案やスケジュール上からの各仕様の最終必要時期の提案を行う。(3)また、残仕様の想定範囲もできるだけ明確にしておくことは重要なポイントである。(4)次に実際に出てきた仕様から真の要求を掴み、より良い仕様の提案や、最終的な仕様決定や確認ができるだけその場で完了する。(5)意識的にステークホルダーに関わっていく。間に人がいると責任の逃げ道にできそうで、壁を作って後ろに引っ込んでしまいがちだが、結局は終盤での仕様変更、仕様追加や、不要な機能を実装してしまうなど、マイナス面を引き起こすことが多い。積極的に仕様を取りにいく姿勢があれば、それまで会えなかった現場の人に会って今までいまいち理解できなかった仕様がシンプルになることも珍しくない。 しかし言うのは簡単だが、人間関係もありこれがなかなかうまくいかない。すべてを明確にして、文書化して交渉・調整して合意する、という所から入る欧米風のマネジメントは日本人は不得手なのである。日本のうまくいくスタイルは、団結し、協力してやりましょう、というところがベースになっていると思う。十七条憲法にも最初に「和をもって貴しとなし」とあったではないか。ノミニケーションに代表されるキックオフを行うことも多い。このスタイルはあいまいで、良い方法ではないように見える。ところが、それはすべてのステークホルダーが進んでプロジェクトに協力するチームスタッフの一員となる、ということである。そうなれば、すべてがうまく回っていく。硬い言い方をすれば、ステークホルダーを含めたチームビルディングを行う、ということになり、実際にはPMにおける問題・課題の根本的対処になっている。例えば、仕様漏れがあったときにも、なぜ必要かを協力して考え、最もほかに影響の少ない仕様を協力して探したり、他機能で賄えるなどで不要になることもあり得る。実際に使う現場の人と直接相談することにより、仕様が縮小できることもある。こうなるとプロジェクトメンバーが、プロジェクトにとって最も良い解決法を最終的に選択できるようになるのである。日本のプロジェクトはこの国民性をぜひ利用指定して頂きたい。加えて日本の技術者は技術面では非常に優秀である。プロジェクトを通じて、優れた仕様提案能力などの課題解決能力を見せることでステークホルダーのプロジェクトへの信頼を得ることにより、チームとしての協力関係が強まり、要件だけでなく、プロジェクトの成功確率も増加していくはずである。 「日本のプロジェクトでは、民族性からステークホルダを含めたチーム全員でプロジェクトを守っているので、世界一プロジェクトがうまくいっている。」近い将来こう予言していたと言いたいので、今後のステップとして方法論について整理し、PMAJの研究会や例会などで意見を頂きたいと考えている次第である。 |
 |