■プロジェクトマネジメントの応用 １（ソフトウェア開発編）
プロジェクトマネジメントの基礎に対して，ここでは１０数回程度に分割して，ソフトウェア開発プロセスにおけるプロジェクトマネジメントのポイントを順次述べることにする。プロジェクトマネジメントはいろいろなプロジェクトがあるが，特に，ソフトウェア開発におけるプロジェクトマネジメントは重要で，これが上手く廻るかどうかが，プロジェクト成功の大きなカギであり，ハード開発と違って，技術蓄積などまだまだ不十分な部分が多く，ＣＭＭＩなど標準プロセスを推奨して，組織力アップを図ろうとしている。
ここでも，プロジェクトの流れに沿って，企画～計画～実施～反省 と云った順序に進めていく。
◆要件定義を明確にする
①誰が企画仕様を決めるか？
どのような商品を開発するかと云う商品企画が明確でないと，折角開発した商品が売れないものになってしまうリスクがある。したがって，先ずは誰が，或いはどの組織が企画仕様を決定するかが明らかになっていないと，プロジェクトとして前に進まない。
企画仕様は，絶対に売れる物の仕様に仕上げることは難しい。したがって，顧客要求などをできるだけ取り込もうとすると，開発規模が大きくなり過ぎたり，いつまでも仕様決定ができないなど商品化のタイミングを逸してしまうリスクがあり，誰かが，適切なタイミングで判
断しなければならない。この判断する人が居ないと，或いは判断する機関，部門が無いと，プロジェクトとしてのスコープが定まらないと云った悪い状態が続くことになる。
商品企画を誰が決めるか？と云う問題では，組織の成り立ち，風土・文化に依っても違ってくる。商品企画部門があれば，そこが責任を持つが，商品企画を技術開発部門が代行しているケースもある。そうした場合，開発者が商品企画も兼ねることになり，企画責任が暖昧になってしまうことが起こる。或いは，合議制として一見良いように見える場合でも，なかなか決断がなされないことも起こりうる。
企画仕様は自由度が高いので，その場その場で検討しているといろいろな意見が飛び交う。商品企画部門で中長期の商品開発計画を立て，それに則って競合との競争を意識しながら着実に進める方法ができれば，確実かつ無難な方法である。
また，顧客から要求仕様を突き付けられるケースもあり，こうした場合は，開発部門が責任持って対応して，要求仕様に合意する形で納入仕様書を作成することもある。この場合，納入仕様書が実質上では，顧客との契約に相当するものとなる。
②どのようにして顧客要求を的確に吸い上げるか？
顧客要求は明確に決まっているよりも，こんなものが良いとか抽象的，暖味な要求である場合の方が多い。したがって，顧客の要望を吸い上げながら，顧客要求を仕様書などドキュメ ント化させる必要がある。
ここで難しいのは，顧客が要求している内容に沿ってドキュメント化した仕様と，顧客が要求したものができたときに評価する内容とが必ずしも一致していないことである。できるだけ，この両者の齟齬が無いように，計画段階での仕様を良く詰めておくことが重要である。
現実的には，要求そのものが暖味で確認してみないと顧客も判っていないケースもある。そうした場合，先行してサンプル的なものを作ってみて要求仕様を確認することも必要な場合がある。こうしておけば，後で大きな問題になることは回避できる。
また，顧客が誰か判っていないケース，つまり，顧客要求として誰に聞けば的確な要求を示 してくれるのかが判らないケースである。企業相手であれば，情報としては実務者からでよいが，やはり最終決定権を持った人への確認が必要である。このことも，論理的には明らかなことであるが，最終決定権を持った人が何人も居て，誰が最終決定するのか曖昧な場合もあり，一筋縄で解決しないこともある。一般消費者を対象とする場合には，マーケテイング機能などと連携を取って，要求仕様の把握に努めるべきである。
③ステークホルダーが明らかになっているか？
プロジェクトには，顧客を初め多くのステークホルダーがいる。ステークホルダーがすべて一堂に会して仕様について，議論ができればそれに越したことはないが，そんなケースは稀である。
ステークホルダーがどれだけ居るかがはっきりしていないと，仕様が決まりかけても，新たなステークホルダーが出てきて，新たな要求を突き付け，仕様をひっくり返すことが起こる。つまり，必要だと思われるステークホルダーを見極めて，要求仕様に対するレビューをしてもらって，それ以上の要求は受け付けないと決断することが大切である。より良いものを作りたいと，ステークホルダーを増やして行くと，思いとは裏腹に収拾が付かなくなって，反って良いものが作れない事態に陥ってしまうことになる。
このようなステークホルダーからの影響を最小限に抑える意味では，プロジェクトを始める初期段階で，どのようなステークホルダーが存在するか，どこまでのステークホルダーに要求仕様の確認をすればよいか，見極めておくことが重要である。
④要求そのものが暖昧ではないか？
前述したように，顧客の要求は曖昧であるのが普通一般である。こうしたケースでよく行われるのは，顧客要求を自分たちの納入仕様書に書き換えて，その内容で承認してもらうことである。ただ，納入仕様書を盾に取ると云う考え方（自己保全のために）ではなく，お互い
の接点を確実にするためで，その内容を十分理解してもらうことが大切である。この努力を怠ってはならない。
また，現行品の踏襲や，他社システムからの引継など，従来仕様そのものが明確で引継されないケースもある。こうした場合，現行品同等との表現や，他社システム参照などと，仕様として明確になっていないままで，時間的な制約があって，その状態で仕様にしてしまうことが起こる。こうした表現は，解釈によって如何様にも取れ，仕様として不適切な内容で，○○同等などと云った表現は回避すべきで，できる限りの情報を集め，その仕様を明確にすることに努め，その上で新たな仕様を決定することである。
それでも不明確な部分は，この段階でどのような点かを明らかにしておき，いつまでに明らかにすべきか，その日程を明確にしておくことである。プロジェクトとしてそうした不明確な点を宣言しておけば，協力者が現れることもあり，情報が集まる可能性も出てくる。
⑤仕様がなかなか決まらないときどのように対応するか？
それでもシステムとしての全体の仕様がなかなか決まらないケースはある。例えば，自動車メーカのように顧客の力関係が強いケースでは，なかなか仕様を決めてくれないこともよくある話である。最後まで自分たちの都合で押し付けられることがある。
こうしたケースでは，予め変更が予測される部分が判っていれば，それを考慮したシステム構成にしたり，その部分の作業を後回しにしたり，これまでのノウハウを駆使した対応をせざるを得ない。しかしそれにも限度があり，力関係があるとしても，やはりデッドラインが何日かを明確に伝え，協力を要請することは必要である。むしろ，そうしたメリハリをせずにズルズル遅れてしまうより，日程厳守を約束してデッドラインを示したやり方の方が信用される場合も多い。
また，内部のやりとりで仕様がなかなか決まらないのは，誰もが決断できないケースが多い。 要するに，仕上がりの製品に自信が無いのでいつまでも良いものを追っかける症候群である。 この症状から脱却するには，システム仕様の確立が全体へ及ばす影響を十分考慮した上で， 全体のバランス（例えば，日程が厳守であればそれを考慮して）を良く見て，責任者が判断， 或いは決裁者に判断を仰ぐことである。
ここで重要なのは，システム仕様の項目に優先度を付けることで，限られた中での開発だから，優先度の高いものを先に検討すべきで，優先度の低いものは，次バージョンへ見送ることを決断するなど優先度を付けた進め方をすることも大切なことである。
一番拙いのは，要求仕様の重要さ・曖昧さだけを強調して，誰も責任を取らず，他責にしながらズルズルとプロジェクトが遅れていくことである。この原因は，関係者の殆どがシステム仕様をスケープゴートのようにしてしまうことである。気分的に救われる気にはなるが， プロジェクト全体から見れば，何の役にも立たず，誰かが責任を以って解決しなければ進まないことは明白である。
⑥ドキュメント化がきっちりできているか？
要求を明確にする意味では，やはりドキュメント化をきっちり行うことである。それも単に書類に記載すれば良い，と云うのではなく，必要最小限の事項を明確にして，マニュアル化するか，テンプレートを作るか，均質なドキュメントになるようにしておくべきである。
後戻りなど，プロジェクトが思い通りに進まない要因の大きなものに，顧客要求のドキュメ ント化ができておらず，仕様そのものの解釈が担当者によってバラックことによる不一致が上げられる。この要求仕様がドキュメント化されず暖味だと，続くシステム仕様も決められない。或いは，決めたとしても解釈が間違っているケースも出てくる恐れがある。
ドキュメント化することで顧客要求の原本として，次工程以降での判断基準の手助けとなる。
⑦システム要件はビジネス要件を関連付けた要件定義書になっているか？
組み込み系では，売れる物になっているか，である。顧客要求仕様として作られるものが，一部顧客の要求だけを取り入れただけでなく，製品として売れる物（ヒット商品）になることを十分考慮されたものになっているか，と云う点である。
システム要件として，機能要件だけでなく，非機能要件についても十分考慮されることは必要で，ビジネス全体としてバランスの取れた商品に仕上がるか，と云う観点での配慮がされているかも重要なことである。
非機能要件の代表的なものは，次のようなものがある。
（1）信頼性A．障害許容性
B．負荷仕様
C．競合仕様（2）使用性
A．理解性
B．習得性
C．運用性（3）一貫性
（4）拡張性・移植性
（5）効率性
A．時間効率性
B．資源効率性（CPU占有率，メモリ使用量）（6）保守性
A．解析性
B．変更性
C．安定性
D．試験確認（7) 施工性
（8) 安全性
（9）セキュリティ
[Reported by H.Nishimura 2011.04.15]
Copyright (C)2011 Hitoshi Nishimura
