室長のひとりごち

活動仲間とプロジェクトマネジメントについて会話しているとき、プロジェクトマネジメントで何を身につければ良いのかについてやりとりをした。個人的に良いと思ったので書き残しておく。

プロジェクトマネジメントで何を身につければ良いか。

そんな投げかけを受け取ったらなんと答えるのが正解だろう。PMBOKを覚えて、プロジェクト計画書を作って、実践して。開発手法は今どきのアジャイル開発で、チームビルディングは心理的安全性の高い信頼関係を構築して…。

前述したことはすべて手段に過ぎない。プロジェクトを上手くマネジメントするために多くの失敗の積み重ねを経て得られたプラクティスでしかない。

手段は大事だ。プロジェクトチームのパフォーマンスが期待どおり出ないのは、開発プロセスがプロジェクトの目的達成にフィットしてないからかもしれない。

もしかしたらチームのコミュニケーションにギャップがあるからかもしれない。いやいや、実は…。

私たちはなぜプロジェクトを上手くやりたいと思うのだろう。仕事だからだとか、役割だからとか、このプロジェクトを成功させてステップアップをとか、色々と事情があるだろう。

でも、どうして上手くやりたいのだろう。上手くやるためには何をしたら良いのだろう。

上手くやるためには何を身につければ良いのだろう。

たどり着いた答えは、リスクをコントロールするスキルを身に着ける、だった。

なんだ、と思うかもしれないが、この一文は重い。

一生掛かっても身に付けられる自信は持てない。

なにぶん、アラカンに足を踏み入れたのに未だに後悔と失敗からの学びばかりである。

リスク。

個人的にリスクは曖昧でぼんやりとしていて、語感がよく、掴みどころがない。故に、わかった気になる。だからよろしくない。

リスクをコントロールするためには、リスクは何かを識別できなければならない。識別するためには、色々と型式知は必要になるし、実践知がなければ型式知と紐づかない。紐づかないことは、認知しようがないから一向に気づかない。

結果、見過ごして失敗を生産し続ける。

こうやれば上手くいくと考えたことを言語化して、自分の時間の大部分を占有するくらいに費やして、上手くいくことかを見届けなければならない。

上手くいくと考えられるためには、上手くいくやり方を知らなければならないし、上手く行かない知見も必要になる。

さらに、上手くいく方法と上手く行かなかった最悪のケースのインパクトを見積もれなければならない。

リスクをコントロールためにと始めたら、とめどもなく色々と湧いてくるので、全くよろしくない。

そういう意味合いで、たかが一文のくせに重いのである。

エンジニアはプロジェクトマネジメントのために何を身につければ良いのか。

何かコアとなる、幹となるスキルがあるはずで、それを身につければいいと言いたいのだが、リスクのようにそのバックボーンにある背景をひっくるめてだと、身に着けることの難易度が一気にメータを振り切ってしまう。

全くよろしくない。

調達　5s バッテリ