相談内容の可視化は新しい知識にフィードバックされる

予定していた夜の部会の延期が決まった後にその部会メンバから予定が空いているままなら会わないかとDMでお誘いを受けたので仕事を片付けて行くことにしたのです。

DMの内容はその部会について話したいと書かれていたので、何かあるなと思いつつ、作っておいた資料をみてもらえば良いかと思っていたら件の話になったんですよ。

使ってナンボ

部会向けの資料は企画ネタのもので、ただ前回の資料は大分具体性が有り過ぎて2−３歩下がって資料の理解を得るところがアクティビティになってしまっていたという反省をどうしようかと思案しつつ、スタートアップやアジャイル開発系で使うことが多いキャンバスやマッピングなどのツールで整理しなおせばいいのではと思い当たって仕事の気分転換に前回資料のおさらいといくつかのツールに落とし込んでみるといくつかの項目の表現が今二歩くらいあったけれど、何をやりたい企画なのかがすんなり入ってくるようになったので、やっぱりツール類は素振りじゃなくて実践的に使わないと労力を使うリターンが少ないなぁと実感したり。

使ってナンボですわ。

描いて共通理解を確認する

今回の資料はA4に押し込んでコピーを渡してざっと整理した資料の読み合わせをしたら、するっと理解してもらえたようで、じゃあ、次そちらの番だねと振ると実はと切り出すところからやはり勘は当たっていたようで（バンザイ）。

ざっくりまとめるとプロダクトマネジメントをすることになった中堅エンジニアが今まで企画畑で開発経験がなくプロダクトの立ち上げはいいけれどデリバリのところに入ると試行錯誤になってしんどいから、プロジェクトマネジメントを教えてあげたほうがいいのだろうかと抱えている悩みを共有してもらったんですが。

これはシステム開発でのプロジェクトの4層フレームワークの最下層にあるマネジメントプロセス（例えばSIerのシステム開発ならPMBOK）と第3層システム開発手法（例えばウォーターフォールやアジャイル開発）にプロダクト開発であれば何を当てればいいのかってことと、それを踏まえてプロダクトマネージャに何をインプットすればいよいか探り出す必要があると思って、言葉の意味合いから事象として起きていることや客観的に押さえている情報をひと通りホワイトボードに描くことで可視化されるとだんだんとわかってくることもあるのです。

共通理解から得られたのは新しい知識

システム開発畑なので第4層はPMBOKで第3層はシステム開発手法でと経営からのモニタリングに耐えられるプロジェクトの計測、監視と制御が無意識に当てはめてしまうけれど、プロダクト開発の場合は、違うなと。特に、プロダクトやサービスを企画からクロージングというアクティビティなので第4層はPMBOKではミスマッチというか機能不全になるのです。そこはプロダクトマネジメント、プロダクトのライフサイクルを KPIで計測、制御するマネジメント手法が適切なのです。

件のプロダクトマネージャはそこは問題はないので。次は第3層のシステム開発手法ですがキャリア的にここが圧倒的に力不足というか形式知がないに等しいのかもしれません。ここはウォーターフォールがとかアジャイルがとかよりはプロダクトを完成してリリースするための作業プロセスの組み立て方の知識と実践力をいかに身につけさせるかを具体的な活動に落とし込んだほうが良いなと。

相談者への囁きは、前述後段ですが、自分自身の気づきは、第4層はPMBOKばかりじゃないということです。元々は形式知として得た知識をひとつ増やすことができてよかったと。