あるクライアント様の案件では、システムの第一次フェーズがサービスインし、本格的な利用が始まった。小生は、この第一次フェーズの導入時からプロジェクトの全体管理を行うことになった。
今までは、アドバイザー的な参画であったがこのタイミングからプロジェクト全体の管理を行うことに．．．
　
　システムの導入時以降では、どんなシステムであってもバグも出るが、エンドユーザーからの要望というものが数多く出てくることになる。この要望が、実は曲者であり、その対応を間違えるとサービス提供者側もクライアント様側の両者にとって、苦労を重ねる結果となるのだ。
　
　要望＝修正しなければならない　ということではない！　しかし、クライアント様側にとっては、せっかくお金を出して作っているのだから直して欲しいと思うのが当たり前。開発側としては、しれは仕様追加扱いだといいたくなるのも当たり前。この両者の当たり前をどう決着させるかで、満足度の高いものになるか、不満だらけのものになるかが分かれてしまう。
　
　クライアント様にとってはこれ以上費用は出したくない。でも、直したい。開発側は、直したい気持ちはあるが、お金をもらいたい。その線引きをするのが小生の役目であろう。
　
　両者の間に入り、コミュニケーションを取っていくことになるが、その基本は文書でのやりとりに限る。これ以外の方法では、まず、混乱を招く結果になる。これは経験からも言えること。
　
　文書管理とは、修正依頼表を作成して、その文書に記述したことについて検討結果や対応策を記述していくもの。言った、言わないなどの争いや、過去の要望やバグの履歴が残ることで解決をスムースにする効果がある。デメリットとしては、言えば簡単なことでもきちんと明文化して記述しなければならないという面倒くささかもしれない。しかし、メリットの方が断然大きいのでこの方法を採用することが多い。
　
　今回のＰＪでも、この管理表を採用することに。導入直後というものは、非常に多くの要望や疑問点、バグ報告が挙げられる。これを、まずこなすことが開発側の必須作業となる。ここのレスポンスが悪いと、後々影響を残すことになるので必死に立ち上がり時の要望やバグを潰しにかかる。
　
　とはいえ、システムのリリース後なので、本当に緊急の場合以外は、計画的に修正を行っていくことも大事だのである。これを、言われたから．．．　すぐに出来るから．．．　と言って、無作為に修正してしまうと管理できない状態になり、両者にとって良くない結果になる。
　
　この流れを調整するのが小生なのだ。今回も多くの要望が挙がってきている。開発側との調整も頻繁に行う必要があるだろう。ここからが、小生の腕の見せ所．．．
　
　この作業の傍ら、第二次フェーズの要件定義も行っていかなければならない。頭の中は、きちんと引き出しを使って分けていかなければならない。でも、醍醐味を感じる部分でもある。
　
　この数ヶ月、頭も身体もフル回転で対応していくことになるだろう．．．