このような背景があったので、今回のプロジェクトでは、できるだけ社内の人材を活用すること、また、負荷をかけてしまうことになるが、これまで開発に携わっていただいた優秀な技術者を中心にせざるを得なかった。これにはかなりリスクを伴うが、うまくいけば開発工数を抑えることができる。優秀な開発者には２倍お支払いしたとしても、それ以上のOutputを期待できる。力仕事は社内の人材を使い、PMは私自身が担当する。それが最も効率的に思えた。なので、本来であれば大手ベンダーにお願いするSI案件であるものを、社内プロジェクトの体制で臨んだのである。社内プロジェクトでは、責任の所在が曖昧なので、万一完成しなかった場合のリスクが大きい。というか、できなかった責任はベンダーではなく間違いなく自社ということになるだろう。しかしよくよく考えてみると、プロジェクトが失敗してしまった場合には、たとえIBMであったとしても責任とって何かしてくれるわけではない。（大手ベンダーに請負ってもらう方は、それが現実だと肝に銘じておいたほうがよい）
私は開発のイメージをもっていた。それは、IBM時代のPM経験というより、XMLコンソーシアムにおけるイメージの方が近い。XMLコンソーシアムの各社の代表は、成果物の責任をともなうような契約があるわけでもないのだが、皆が一つの目標に向かってまっしぐらに開発をすすめ、苦労を重ねながらでも最後はいいものを作りあげる。これは参加したものしか分からないのかもしれないが、とても独特で不思議な開発手法だ。私はXMLコンソーシアム iPlatの開発をイメージしながら今回のプロジェクトに臨むことにした。ただし、この方法でやるためには次のような社内外の担当者の意識改革が必要だと思った。
- 社内の担当者は、責任をもって要求仕様の作成とOutputの検証を行う
- 協力会社の開発者は、すばらしいシステムを作るという情熱・信念をもち、常に善意に基づいて判断する
社内の担当者に対しては要求内容を明確にしてもらう必要があった。リストを整理すると皆の意見を集約したような曖昧で無責任な要求が散見されるようになる。「誰の要求か」を特定できない場合には検証できないので非常に困る。たとえごもっともな事が書かれてあっても、それを言った人が特定できないのであればすべて削除することにした。要求する人には、まず最初に作る理由と効果の説明、さらに作った後のしっかりした検証を求めた。「言いっぱなし」を認めず、必ず検証を求めたので、作業が大変なのか黙ってしまう人もいた。また後に個々のコストが算出されるようになると軽々しく言うこともなくなった。その結果、本当に作るべき要求だけが残ることになった。
一方、開発者に対して私が求めたのは、高度かつ先進的なITスキル、円滑なコミュニケーション、情熱と信頼である。特に情熱と信頼は大切だ。先日、ある友人がなかなかよいことをいった。「IT技術者は医者や弁護士のようにクライアントの信頼を得られなければならない。クライアントは、命をあずけようとする相手を信頼するだろうし、その信頼があるからこそ高額なお金を払ってもいいと思ってくれる」
優秀なIT技術者は、医者や弁護士のような高いレベルの仕事をすべきだと思う。クライアントが何が困っていて何をしたいのかをよく聞いて善意でもってソリューションを見い出す。その際、技術者は具体的な方法や手段は一任されることになり、細かい指示ではなく命題や目的だけを考えて結果を出さなければならない。例えば、何か調子の悪い現象が報告されたら「それは仕様です」とはいわず、迅速に悪い現象に対応するか、その改善案を提案すべきである。
夏の開発のピーク時に、開発者の増員を図ったことがあった。契約の内容が派遣と同じような時間給であり、納期も短かったため、残念ながら中途半端な結果に終わってしまった。本人たちは、しっかり完成させなきゃという気持ちはあるものの、契約がそのようになっているので、どうしても机に座っている時間を基準に考えてしまう。「MTGに出席する時間は仕事に含まれるのですか？」と聞かれたとき、私は非常に不愉快な気分になった。「MTGに出るのは何のため？効率よく仕事をするためじゃないの？他にもっと効率よく仕事できれば出なくて結構だよ。」いつのまにか時間をかけて非効率な仕事をやる方がオイシイことになっている。時間をお金に換える発想から、結果をお金に換える発想に転換しなければ、お互いにメリットはない。そのうち彼ら自身の向上心もなくなってしまうだろう。今後、この手のサービスを利用することはおそらくないと思う。
