計画とは

計画とは元来

のことを指しますが、これが苦手だと言う人が結構多いのではないでしょうか。

しかし、考えてみてください。

計画とは未来に対して100%保証するものにはならないものの、それなりの確度で予測できるものを予測し、時には心配していることや懸念事項、情報不足の中でも問題なく運用できるように様々な具体的状況を考慮に入れて、対策を考える作業として認識されているかと思いますが、それって要するに

　プログラムのアルゴリズムを検討するのと同じ

ではないでしょうか。

異常系を想定してif/else分岐しておいたり、例外系を想定してtry～carch文でスタックトレース管理しておくのは、要するに

　・正常なプログラムの進行手順を明確にし、
　・想定通りにいかなかった場合の進行手順も明確にし、
　・それでも何ともならなかったときにも、
　　お手上げとならないようあの手この手を駆使して処理を考える

ことと似ていませんか？

プログラムが異常終了しないよう最大限検討し、あらかじめ起きうる問題を想定し、様々なセーフティネットを用意することと計画は非常に酷似しています。

…と言うことがわかれば、アルゴリズムのようにプロジェクト運用を考えればいいだけです。特にプロジェクト活動を何度か経験している人は、

　どういったところでどのようなことを考えておかなくてはならないか？
　どういう時期には、どんな対策を講じて必要があるのか？
　どんな相手には、どの言葉を選べばいいのか？

等、リスクとして予測可能な部分はどんどん増えているはずです。
分からないことは検討できませんが、それも周囲を見渡せば自分が経験したことのない悩みを抱えている人も見かけますし、大変なプロジェクトであれば噂程度聞く機会もあるでしょうから、未経験であっても想定できることは多少増えるはずです。

まずは正常系ルートのプロジェクト計画を立て、異常系のｉｆ分岐を肉付けし、例外系はtry～catch文で定常監視を行い、catchした場合はexceptionとして拾い上げ、例外処理を実行し、対策内容を追記する…。

その想定すら超えて問題が起きた時は、仕様検討漏れのバグでしかないと言うことですが、それすらもコンティンジェンシー予備をきちんと計画時に考えておけば対策が打てるはずです。

そう考えると、少なくとも私たちＩＴサービス業に属しているエンジニアやエンジニア上がりのプロジェクトマネージャーというのは、ソフトウェア開発のプロフェッショナルだからこそプロジェクト計画は容易にできそうな気がします。

もちろん、人間というアナログな存在が関与するためプログラムほどシンプルにいかないこともありますが、それらはある程度『ルール』と『基準』でシンプル化することが可能です。

たとえば、進捗管理を例に挙げると

ルール：「毎週月曜日に進捗を報告する」
　　　　　　※２日以上遅れている場合は即時報告する
　　　　　　※報告以外は不要。課題や問題は報告会以外で個別に有識者で対応。

基準　：進捗率は不要。現状タスクに要する残日数のみ報告する

といったようにレールを敷いてあげればこれ自体がアルゴリズムの正常なマイルストーンとなり、人がアナログに行動することを極力抑えることが可能になります。

逆に、組織的活動でルールや基準を明確化しないと言うのは要するに"無法地帯"を容認するということで、それはもう組織でない（組織的活動によるパフォーマンスを期待できない）ことを意味します。

チームが"組織"でありたければ、常に無法だけは避けなければなりません。