マガジンのタイトルを「プロジェクトとコーチング」に変更しました。
今回のマガジンは最初プロジェクトマネジメントの解説しようと思ったのですが、そんなの教科書にいっぱい書いてあるのであまり面白くない。
30年間ソフトウエア開発に従事して、リタイア後にコーチングを学び、もっとコーチング的なコミュニケーションが出来ていればいろいろ問題解決できたのに・・と、もう後の祭りですが、本当にそう思うので、このあたりを中心に書いてみようかと。

技術現場の中でも特にソフトウエア開発現場は、多くの場合火の車状態に陥ります。プロジェクトマネジャー（そのプロジェクトの統括責任者）は、
・品質が一向に良くならない(Quality）
・大手術が必要な大きなトラブルが発生する（Quality）
・予算が足りなくなる（Cost)
・突然進捗が悪化する（Delivery)
などのQCDにまつわる「症状」に対処していかなくてはなりません。

なんでこんなに問題ばかり起きるんだぁ！！！！！！
と怒鳴っていても何も解決しないのです、そんなことはプロジェクトマネジャーも分かっている、でもどうしたらいいのか分からない。

では、どうすればいいのかのヒントですが、大きく2つあります。
①プロジェクトマンジメント手法を現場に取り入れる（Doing)
②プロジェクトマネジャーの在り方、およびコーチングを軸としたチーム内コミュニケーションの変革（Being）

①は前回も書きましたがPMBOKという教科書があります。これを勉強すると知識が身につきます。ただし私はPMBOKをお薦めしていません。なぜならAmazonで検索してもらえば分かりますが、高いし、読みづらいし、紙質が悪いし、なので、「プロジェクトマネジメント」などのキーワードで検索してもらって、日本人が書いた良さそうな本をベーズに勉強すると良いと思います。勿論不足があれば複数の本を読んでみてもいいと思います。
ここで大事なことは、PMBOKなどの教科書に書いてあることは、「こうしないと失敗しますよ」という失敗から学んだことなので（だからナレッジと言ってます）、自分たちの職場に当てはめた時に、
「どれをどの程度やるか」
という意思決定が必要です。
さらに、それを複数のプロジェクトで適用させていき、繰り返しPDCAを回して組織のナレッジとして蓄積し、
終結したプロジェクトの反省を次のプロジェクトの計画立案に活かす
ということがとっても重要です。
この①については、細分化して書いていこうと思います。

②は①より重要度が高いのですが、こちらは誰も教えてくれません。
いろいろな経験から来るナレッジなので教科書は基本的にありません。
ですので、次回はこちらから書いていこうと思います。
一言だけ②のキーワードですが、「プレゼンス」です。

次回は、「プロジェクトにおける3つの制約とプロジェクトに影響を与える3つの要因」の予定です。