システム開発の仕事

　システム開発は「作業」ではない。最終的には「作業」のレベルまで落とすべきなのだけれど、まずはclientの意図を理解する事が必要となる。たとえば、事案の見た目としては「websiteを作る」であっても、裏に今後の展開や事業戦略が依頼者の本質的な目的として隠れている事は多い。本質的な意図を見抜けないまま進めれば、完璧に稼働するsystemと美しいdesignをもってしてもclientの満足を得ることはできない。
　つまり、ProjectManagerの仕事とは、本質的には「指示を出す」事ではなく「意図を理解して噛み砕く」事にある。細かい指示は任せても何とかなるものだが、その前提は「作業者（ex.Programer）」がclientの意図を理解している状態にあることだ。もちろん、理解させられない場合は、Managerはclientの意図を踏まえた詳細な指示を出す必要がある。
　にもかかわらず、「ProjectManagerの仕事は指示出しと進行管理であって仕様や要件は全部clientの担当者に聞けばいいのさ」と思っている人、clientの意図を理解せずにいきなり「具体的にこれこれの作業を行う」にしてしまうProjectManagerが時折存在するのはどういうわけだろう。全部客から聞くのなら、指示は直接客から貰えばいいだろうに。更に言えば、担当者レベルでclient全体の意図が理解できているとは限らないのだけれど。
　一因としては、Programer→ProjectManagerというステップを採っている企業がこの業界には多いけれど、昇進ステップに問題があるというのも一因なのだろう。上記の昇進ステップをはじめとして、ProjectManagerの条件にProgramerとしての経験を挙げる人は多い。しかし、designerのように一人でProjectを担当する機会がないProgramerには「客の意図を理解する」という経験を積む機会も少ない。結局の所、Programerの経験とは「同じ言語で会話ができる」という事だけなのだ。もちろん同じ言語で話せるというのは重要だけれど、客の話す言語が解らないのでは本末転倒だと思うのだが。
　ここまでを読んで、「clientにしつこく聞けばいいのだな」と思う人もいるのだろうなと考えるとちょっと暗くなる。
　自ら進んで教えてくれるclientもいる（system開発の外部委託に携わった経験のある人に多い）が、経験があっても「推察しろ」とばかりに全く話さない人もいるし、上手くsummaryして話すのが下手な人だっている。社外の人間と何かを作るという経験が無い人の場合は「何をどう話せばいいか解らない」だろう。
　「clientに聞く」のではなく「自分の考えた事がclientの意図と合っているか確認する」のだ。話してくれない相手にはこれしか無いし、上手く聞けたとしても考えなければ理解できず、ProjectのMemberに伝えることもできない。
　途中まで読んで「clientに（Programerは「PMに」）聞けばいいのだな」と思った人は、もうちょっと「clientが作りたいのは何なのか、自分が作っているものは何なのか考える」事を習慣にするといいと思う。日々の業務・作業で忙しいのは解るけれど、10分でも15分でも考える時間が取れないはずはない。