非エンジニアにプロジェクトマネジメントをどう説明するか

非エンジニア向けにプロジェクトマネジメントの講座を開くことを依頼され、しばらく経っていたのでそろそろ手をつけなければとmindmapを開いて思いつくままに目次構造を書き出していたら、ピタリと手が止まった。

これでは受講する方々は辛そうだ。そう思った。

さて、非エンジニア向けのプロジェクトマネジメント講座をやって欲しいと依頼したビジネスオーナの狙いは何か。何事も行動には目的がある。それが些細なことでも。

だから、知見のある専門家は知っていることをただ順に並べてはいけない。なぜそれをやりたいか、目的は何かを知らなければ講座はオーナの目的を代行として果たすことは難しいだろう。

プロジェクトマネジメント講座を教えようとするとついやってしまいがちなことがある。例えば、

プロジェクトマネジメント原理主義ではないが、PMBOK６thの知識エリアをおさらいしてみよう。

要件を確認するマネジメントも要件を実現する開発手法や段取りはもちろんのこと、エンジニアの大好物の開発ツールや言語はもちろん心理的安全性などのマインドセットもない。

プロジェクトが発生する源泉、理由は何か。

それは業務、定常業務を行なっていて、その事業上に課題が生じたとき課題を解決する手段として定常業務と違うプロジェクトとして課題を解決する活動を行う意思決定をするからである。

『だからなに』と思うかもしれないが、定常業務のアドオンで特別な業務活動を行うという点には注目したい。ここを忘れてか知らずにいると、事業サイドのレスポンスが遅いとか体制が貧弱だとITエンジニアは文句をいうからである。

それはさておき、

であるから、始める前に押さえておくことと始めるにあたり前提条件があることがわかる。これを踏まえて始めないからグダグダになる。

そうすると非エンジニアには、

を踏まえた上で、プロジェクト化した特殊な活動をマネジメント、業務活動をコントロールする手段としてプロジェクトマネジメントの視点（知識エリアの切り口）を知っていると手順化されていない特殊な活動であるプロジェクトマネジメントをしている、ということが理解できるようになるのではないか。

それで、そうした知識を一方的に詰め込んでもたぶん必要なときに読み返すからなんとなくやれそうと思うだろうし、知識を得たから満足するかもしれない。

でもそれはわかった風なだけでしかないので、そこには擬似的な体験をするべきだろう。

という感じでやると、そこそこの回数をしなければならないし、スライド、演習の建てつけや小道具が必要になってくるという見通しがつけばあとは作業である。

さて、お仕事お仕事。