プロジェクトに計画はあるのに、設計はないのだろうか？

昨日、PMI中部の勉強会に参加してきました。
【3月27日「本当にPMは育成出来るのか？」(PMIJ中部 3月度定例会)(愛知県)】
その日いろんな意見を交換したり、懇親会でもたくさんの話を聞いていて疑問がでました。

「プロジェクトにはプロジェクト計画というものがあるのに、設計や実装といった言葉がないのはなぜなのか」

僕の意見も含めてその場で出たのは「チームビルディング」や「WBSの作成(PRODUCTバックログの作成)」などがそれにあたりそうだけど、ハッキリとはわからない。といった感じ。

経緯

なんでこういう疑問が出たかというと、大きくは2つあります。

計画という言葉があると、テスト戦略 -> テスト設計 -> テスト実装 -> テスト実施と思い浮かんだので、プロジェクトにはそれがあるのか気になった。
本会での話で「目的を伝えきれずにタスクだけを渡してしまうことがあり、PMが行う目的の種類がわからなくなってしまうときがあった」という話。WBSの作成だけを言われてなんのためにやっているのかわからなくなってしまったり、目的を把握できていないので、やったことのあるタスクでしか解決方法を見いだせないなど。

設計という言葉がほしいわけではない

疑問に思っているだけで、「プロジェクト設計っていう言葉大切だよ！つくろうよ！」って思っているわけじゃないです。
なんでないのかなって思うのと、もしPMの目的やアクティビティをうまく表現できていないのであれば、計画(戦略策定) -> 設計 -> 実装 -> 実施 -> フィードバックという流れは自然かなって思いました。
まだ表現されていない他にもいろんな観点があると思うし、既存のPMに関して勉強不足な部分もたくさんあります。PMBOKとBABOKとソフトウェア工学系の書籍読んだだけの知識ですしね。。。

PMに限らずあるあるだと思った

アジャイルのプラクティスにあるユーザーストーリーなんかは典型的だなって思います。「顧客との会話を促す」ために「ユーザーストーリーをつくる」があると思うのですが、ユーザーストーリーをなんのためにつくるか意識できていないと、ペルソナの引っ張り合いになってしまったり、無駄に凝ったユーザーストーリーを作ってしまったり、いろいろとダメな行動につながる場合があると思います。
なので目的を意識するというのは重要なのだなぁと感じるとともに、それをうまく共有できる言葉作りは、曖昧さとかムダを抜いて、やりたいことに時間を費やしやすくするために重要だなぁと思いました。（これが標準化というものなのですかね。よくはわかりません。

まとめ

プログラミングでの設計パターンがたくさんオープンになりつつあり、テストでの設計パターンもいくつかオープンに考案されはじめました。情報アーキテクチャでも同様です。
同じようにプロジェクトの設計パターンというのもいろんな言葉でどんどんでているとは思うのですが、僕としてはなによりかにより「同じ目的について言及している気がするのに、別々で言っているから調べにくいよ！勉強しづらいよ！」って思うことがしばしばあります。（本音そこかよ！
どんなことをするのがプロジェクトの設計と言えるのかとか、どんな手段があって、いまないものはどんなものか？っていうのを考えながら勉強していきたいなって思いました。
もし、参考になる書籍やWeb情報や、勉強会などありましたら、教えていただけると非常に嬉しいです。