システム開発で一度も失敗したことがないPMが実践していること

先日、facebookで元部下が誕生日だとわかり、久しぶりに会うことにした。facebookの良いところは、友人などの誕生日を教えてくれるところだと思う。流石に一人ひとりの誕生日を聞くことはないし、でも、知っていれば飲む口実が作れる。ソーシャルネットワークでは友人の近況を投稿から知る機会があるので物理的に会っても久しぶりな気が全く起きないが、それでも会話することでソーシャルネットワークではかかれないリアルさを知ることができる。

かれこれ2年振りくらいに会って会って、近況をお互いにとてもフランクに尋ね合う。自分は上司なんていっときのたまたまマネージャがロールの人くらいしか思っていないので、所謂、上司風を吹かせなかった(つもりだ)から非常にタメ口ウェルカムである。

そんな感じで色々と注文した肴を突きつつ、ふと、質問をされた。

 

「そう言えば、プロジェクトを一度も失敗したことがないんじゃないですか。そんな話は誰からも聞いたことがないし」

 

突拍子も無い質問をされると理解するまで時間がかかるが、これも言われてみればその質問のとおりである。自分がやってきたプロジェクトで所謂(QCD)失敗したことがない。

 

「そう言えば、そうだね」

「コツを教えてください」

 

そう言われても、である。やることを終わらせる。約束したことは履行する。ダメそうなら相談する。つらつらと思いつくことを言いかけるが、少し、空想する。頭の中の記憶を引っ張り出しても上手く言えない。

なぜなら、計画が計画したとおりに進むように色々と手はずをするからだ。こうしたことをそのまま伝えても多分、本質は伝わらない。もう少し、具体的にした方が良いし、箇条書きぽく短く、単純にした方が良いのだろう。

オジサンになって嫌われるのはくどくどと長ったらしく話すことだ。

 

  • キーとなる人的リソースを揃える
  • スコープを明確にする
  • チーム・ステークホルダと確認するプロセスを回す
  • 曖昧なまま手をつけない
  • 上手くいくなんて思わない

 

少し上の空間を眺めながら、こんなことを言ったはずだ。システム開発は技術を持ったエンジニアで成り立っている。プロジェクトだけの観点で言えば、プロジェクトの制約条件、前提条件を満たすことを確認して始めなければならない。その筆頭なのが、エンジニアの技術力である。チームとしてプロジェクトが必要とするスキルセットとレベルを揃えていなければキックオフしてはいけない。

 

スコープが明確でなければ同じように始めてはいけない。定量的な仕様若しくは定性的でもキャップがかかっていることを確認しなければならない。それでもスタートするのであれば、何が起きるかリスクを識別し、プロジェクトのコンテンジェンシプランを作ってから始めなければならない。

 

チームメンバとも然り、ステークホルダである顧客とも然り、活動ごとにゴールを確認してそれが終わった状態であるかを確認するプロセスを回さなければいつまで経ってもその活動を終われない。その状態だと次の活動、工程に突入できない。見切りで突入した途端、終わっていない活動にリソースを取られたまま次の活動のリソースが足らずに始まるので混乱するだけだ。そして全く成果が出ず、曖昧なまま、さらに進んでしまう。良いことは何一つない。

 

曖昧さを残したまま進めてはいけない。システム開発はコードを仕様に沿って書く。数値や文字列を比較し、操作する。曖昧さはコードで表現できない。曖昧さをなくすために活動の工程を分割し、詳細化を図っているのだし、曖昧だから小さく、短い期間で作るプロセスを回し、都度確かめるのである。その点で言えば、これが欲しいのかとと尋ねるよりは、これが欲しかったものかと尋ねられる手法の方が良いのは決まっている。

 

何より、いくらプロジェクトチームのメンバが精査したとしても、プロジェクトの骨格は自分の経験と他所のアイデアを思いつきで混ぜて考えた考えでしかない。何より、計画はそのプロジェクト用に初めて作ったもので、どこでも一度も試したことがない。この事実をもっとプロジェクトマネージャもプロダクトマネージャもスクラムマスタも認識すべきである。つまり、上手くいく確証なんてどこにもないのである。基本は、大局的は楽観的に、局所的には悲観的に物事を考える志向が必要である。

 

しかし、失敗していないのはこれまでであって、次も失敗しないとは言い切れない。なにせ、やったことがないのだから。

 

 

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)