【EC開発体験記-人財-】あなたはSuperになるべきだ

　何をやるにしても一番重要なのは「人」だ。どれだけ優秀な人材がいるかによってプロジェクトの成否が決まる。優秀な技術者がキーマンでいればプロジェクトは成功し、いなければ失敗する。IT業界で開発プロジェクトを経験した人は皆同じことを感じているだろう。成功したプロジェクトには、必ずといっていいほど天才的なプログラマーがいて、その人がキーマンとなって開発をすすめている場合が多い。そこそこ大きなプロジェクトでも、全体の８０％～９０％を数人だけで担当していることもめずらしくない。これはいつの時代でもそんな感じのようである。とにかくすばらしい人材の有無によってプロジェクトの命運が分かれることは間違いない。今回のプロジェクトでは、特に優秀な人材をどれだけ集められるかということに、かなりの神経を使った。しかしこれはとても大変なことだった。優秀な人材はまずいないし、いても非常に忙しくて、とても参加できそうにない。また、IT業界では非常に好景気で、猫の手を借りようと思っても、猫すらいない状態で、普通の人材すら見つけるのは困難だった。
　このような背景があったので、今回のプロジェクトでは、できるだけ社内の人材を活用すること、また、負荷をかけてしまうことになるが、これまで開発に携わっていただいた優秀な技術者を中心にせざるを得なかった。これにはかなりリスクを伴うが、うまくいけば開発工数を抑えることができる。優秀な開発者には２倍お支払いしたとしても、それ以上のOutputを期待できる。力仕事は社内の人材を使い、PMは私自身が担当する。それが最も効率的に思えた。なので、本来であれば大手ベンダーにお願いするSI案件であるものを、社内プロジェクトの体制で臨んだのである。社内プロジェクトでは、責任の所在が曖昧なので、万一完成しなかった場合のリスクが大きい。というか、できなかった責任はベンダーではなく間違いなく自社ということになるだろう。しかしよくよく考えてみると、プロジェクトが失敗してしまった場合には、たとえIBMであったとしても責任とって何かしてくれるわけではない。（大手ベンダーに請負ってもらう方は、それが現実だと肝に銘じておいたほうがよい）
　私は開発のイメージをもっていた。それは、IBM時代のPM経験というより、XMLコンソーシアムにおけるイメージの方が近い。XMLコンソーシアムの各社の代表は、成果物の責任をともなうような契約があるわけでもないのだが、皆が一つの目標に向かってまっしぐらに開発をすすめ、苦労を重ねながらでも最後はいいものを作りあげる。これは参加したものしか分からないのかもしれないが、とても独特で不思議な開発手法だ。私はXMLコンソーシアム iPlatの開発をイメージしながら今回のプロジェクトに臨むことにした。ただし、この方法でやるためには次のような社内外の担当者の意識改革が必要だと思った。

1. 社内の担当者は、責任をもって要求仕様の作成とOutputの検証を行う
2. 協力会社の開発者は、すばらしいシステムを作るという情熱・信念をもち、常に善意に基づいて判断する
   

　まずオペレータ、運用責任者等、社内担当者は自分たちも開発に参加するという意識をもってもらい、開発の主体となるように仕向けた。よくあることだが、発注者が特権的な意識があるような錯覚をしている。お金を払っているのだから何でも発注者のいうことを聞くべきというのが理屈なのだが、これをやってしまうと優秀な技術者ほど芳しくない結果を生む。もう少し補足すると、自分のいうことを忠実にやれ、ということは要するに、少なくとも優秀な開発者以上に自分が優秀でないと結果は出せない。ざっと見渡したところ、社内の人材で開発者より優秀な者はあまりいなかった。社内の人は逆に開発者を信頼して謙虚に接する必要があると思った。また、請負業者に対して厳しく接しないと損という人もいるが、人心の妙で結果的に発注者が損をすることになる。少なくとも、発注者と請負業者という変な上下意識はやめてもらいたかったが、これまで植えつけられた意識はそう簡単には変わる様子がなかったので、無理難題・無責任な要求仕様があった場合には、思い切って開発者の判断において優先順位を下げることを容認した。社内担当者にとって無視されると困るが、いつかは作るよといえば大抵、納得してもらえる。

社内の担当者に対しては要求内容を明確にしてもらう必要があった。リストを整理すると皆の意見を集約したような曖昧で無責任な要求が散見されるようになる。「誰の要求か」を特定できない場合には検証できないので非常に困る。たとえごもっともな事が書かれてあっても、それを言った人が特定できないのであればすべて削除することにした。要求する人には、まず最初に作る理由と効果の説明、さらに作った後のしっかりした検証を求めた。「言いっぱなし」を認めず、必ず検証を求めたので、作業が大変なのか黙ってしまう人もいた。また後に個々のコストが算出されるようになると軽々しく言うこともなくなった。その結果、本当に作るべき要求だけが残ることになった。

一方、開発者に対して私が求めたのは、高度かつ先進的なITスキル、円滑なコミュニケーション、情熱と信頼である。特に情熱と信頼は大切だ。先日、ある友人がなかなかよいことをいった。「IT技術者は医者や弁護士のようにクライアントの信頼を得られなければならない。クライアントは、命をあずけようとする相手を信頼するだろうし、その信頼があるからこそ高額なお金を払ってもいいと思ってくれる」
優秀なIT技術者は、医者や弁護士のような高いレベルの仕事をすべきだと思う。クライアントが何が困っていて何をしたいのかをよく聞いて善意でもってソリューションを見い出す。その際、技術者は具体的な方法や手段は一任されることになり、細かい指示ではなく命題や目的だけを考えて結果を出さなければならない。例えば、何か調子の悪い現象が報告されたら「それは仕様です」とはいわず、迅速に悪い現象に対応するか、その改善案を提案すべきである。

夏の開発のピーク時に、開発者の増員を図ったことがあった。契約の内容が派遣と同じような時間給であり、納期も短かったため、残念ながら中途半端な結果に終わってしまった。本人たちは、しっかり完成させなきゃという気持ちはあるものの、契約がそのようになっているので、どうしても机に座っている時間を基準に考えてしまう。「MTGに出席する時間は仕事に含まれるのですか？」と聞かれたとき、私は非常に不愉快な気分になった。「MTGに出るのは何のため？効率よく仕事をするためじゃないの？他にもっと効率よく仕事できれば出なくて結構だよ。」いつのまにか時間をかけて非効率な仕事をやる方がオイシイことになっている。時間をお金に換える発想から、結果をお金に換える発想に転換しなければ、お互いにメリットはない。そのうち彼ら自身の向上心もなくなってしまうだろう。今後、この手のサービスを利用することはおそらくないと思う。