［進捗管理編］アドホックな開発をしてはいけない

　アドホックというと，パッケージ開発を思い浮かべる方も多いだろう。しかしこれはパッケージ開発に限った話ではない。ここでいうアドホックとはユーザーからの要望による追加開発を指している。しかし，それならば変更要求として管理していると言われる方も多いだろう。筆者が問題視しているアドホック開発とは，明らかにユーザーからの追加要望であるが変更要求項目として管理されない，または管理されていたとしても無償で提供する開発のことを指している。まさに「その場をしのぐ，その場限りの」開発のことである。

　ユーザーとの良好な関係を築くために，ユーザーからのちょっとした追加要求に対して，変更管理をせずに「こっそり」と追加開発するプロジェクト・マネージャ（PM）がいる。確かに無償で対応してもらったユーザーとしてはうれしい限りであり，両者の関係は良好になるかもしれない。しかし，それを続けることにより，かえって両者の関係を悪化させることも少なくない。

　Gさんは中堅SIベンダーW社のベテランPMである。今回，GさんはW社と長年良好な関係のあるV社のシステム開発についてPMを任されることとなった。V社の担当者HさんとGさんは以前も何度か一緒に仕事をしたことがあり，お互いの間にある程度の人間関係は築けていた。

　プロジェクトがスタートし順調に進んでいたある日，GさんはHさんから相談を受けた。それはある画面に表示されるラベル文字を変更してほしいというものであった。既に外部設計は完了してはいたが，そのくらいの変更ならばと，Gさんはその場で了解しすぐにプログラマへ変更指示を行った。Gさんとしては，画面表示ラベルの変更程度であればデータベースやロジックに影響を与えないので変更管理として大げさに取り扱うこともないだろうという思いであった。

　数日後，またHさんから変更依頼が入った。今回も画面の表示ラベルに関する要求だった。そのときもGさんは簡単に了承した。ところが，その後もHさんからたびたび画面表示に関する変更要求が来るようになった。

　Gさんは，Hさんとの良好な関係を保ちたいという思いがあった。また，変更要求とはいえ毎回Hさんから相談される内容が画面ラベル程度の軽いものなのでこのまま対応しておけばそのうち要求も下火になるだろうと軽く考えていた。

　そのためHさんからの一連の要求はすべてGさんだけで判断し，プロジェクト全体で情報共有することなく，Gさんと担当SEの間だけで解決していた。しかしHさんからの相談は下火になるどころか，だんだんと大胆になってきた。画面ラベルの変更にとどまらず，プログラム・ロジック自体に影響を及ぼすような変更要求まで出てくるようになったのである。

　さすがにこのままでは問題ありと感じたGさんは，Hさんに対して「その要求は簡単に受け入れることはできません。正式に変更会議にかけさせていただき，追加費用について協議したい」と申し出た。

　これに対してHさんは「いままでは軽くOKしてくれたじゃないですか。今回の件だって今までと対して変わりはないはずです。第一，社内関係者には既に対応すると言うことを約束しています。これまで通り無償で対応していただかないと，私に対する社内の信頼を失うことになります」と激高した。

　実は，Hさんはこれまでの変更点について，自分がGさんと知り合いだから特別に無料で対応してもらっているということを社内で話をしていた。そして，正式な手続きを取ると有償になるような変更であっても，規模が小さければ，自分がGさんに何とか頼み込むから気軽に相談するようにと触れ回っていたのである。

　結局，Gさんはこれが最後だという約束をしてHさんからの要求を実施することとしたが，Hさんと築いてきたこれまでの関係を失うこととなった。さらに，ロジック部分への変更ということで手戻りが発生し，工程全体を見直すはめになった。しかも無償対応と言うことで，W社におけるGさんへの信用も下げることになってしまった。

　すべてのユーザーと良好な関係を築くことができるのであればそれに越したことはないが，なかなかうまく行くものではない。そこでユーザーと良好な関係を築こうとするばかりに，その要望をつい軽く引き受けてしまうPMは少なくない。

　しかし，これで本当に「良好な関係」を築けているのかというと非常に疑問である。確かに，自分の出した要望を二つ返事で引き受けてもらえればユーザーの心証はよい。またこれが続けば少なくとも表面上は「良好な関係」となるだろう。しかし，あくまでそれは一時的なものである。人間は，本質的に要望を受けてもらうことに対してだんだんと慣れてしまうものである。

　つまり，こちら側（PM）が「厚意」で行ったとしても，相手（ユーザー）にしてみれば「当たり前」になってしまうのだ。厚意が限界に達したとき，急にビジネスの世界に引き戻すことになる。しかし，ユーザーとしてみれば，これまでの当たり前の世界から急転直下してしまう。その結果，本来ビジネスの世界では当たり前であっても，ユーザーから見れば「なぜ？どうして？裏切られた」となってしまうのである。

　欧米のような完全契約社会であれば，厚意を全く示すことなく開発を行うことも可能だろう。しかし，日本型ビジネス社会では，どうしても厚意の世界が発生する可能性は極めて高い。それどころか，全く厚意を示さないPMに対して「頑固で融通の利かない奴」という烙印を押すユーザーすらいる。

　PMの任務は，プロジェクトを成功させることである。プロジェクトを成功させるということは，システムを計画通りに完成させることだけではなく，自社にとって利益を上げることも意味している。利益の出ないプロジェクトは，たとえユーザーに喜ばれたとしても最終的には失敗と言わざるを得ない。「損して得取れ」という言い方は美しいが，プロジェクトの世界では失った損失をリカバーして，それ以上の得を得ることはまれである。

　PMは，例え進捗に影響を与えないような軽微なアドホックな変更要求であっても即答で了承してはならない。プロジェクトが順調に進んでいればいるほど，気軽に答えたくなる気持ちは充分理解できる。しかし，ユーザーに“当たり前感”を与えないためにも，一呼吸空けて返答すべきなのだ。

　PMは，すべてのアドホック要求に対して，担当SEや営業担当者等と協議・合意した上で，対応を行うかどうかを決めるのが望ましい。また，ユーザーに対しては，プロジェクト開始時点で，どの範囲までならアドホックを受け入れるということを正式に書面で交わしておくことが重要である（表）。また，アドホック開発の有無にかかわらず，すべての変更要求は変更管理としてプロジェクト共有情報として公開することは言うまでもない。

上田 志雄 ティージー情報ネットワーク 技術部 共通基盤グループ マネージャ 日本国際通信，日本テレコムを経て，2003年からティージー情報ネットワークに勤務。88年入社以来一貫してプロジェクトの現場を歩む。国際衛星通信アンテナ建設からシステム開発まで幅広い分野のプロジェクトを経験。2007年よりJUAS主催「ソフトウェア文章化作法指導法」の講師補佐。ソフトウェア技術者の日本語文章力向上を目指し，社内外にて活動中。