プロジェクト管理支援のコンサルティングをしていると、こんな笑い話を聞くことがある。「開発チームのリーダーが先週まで“予定通り”と報告していたが、今週は“2週間遅れ”と報告してきた」というものだ。1週間しかたっていないのに2週間遅れるのは変だと言いたいわけである。
こういう報告を弁護するわけではないが、遅れを認めたくないリーダーの立場で考えれば内情はある程度推察できる。よくあるのは、先週の報告は「普通にやれば1週間遅れだが、無理すれば予定通りにできる見込み」という意味である。うまくいけば進捗遅れの事象はなかったことにできるはず。しかし、今週その無理をしようとして、1週間空転した揚げ句に断念した。よって今週の報告は「2週間遅れ」になっている。ここでいう無理とは、徹夜や休日出勤、増員要請といった挽回策だ。
このような状況を指して、プロジェクトの進捗管理が機能していないと論評するのは簡単だが、管理の仕方を変えても、メンバーが適切に行動しなければ抜本的な解決にはならない。管理視点の他にメンバーに適切に行動してもらうための指針が大切になる。
こうした指針には、ITのさまざまなメカニズムが参考になると筆者は常々考えている。ITは複雑なシステムの動作を統制して機能させていく知恵の固まりだからだ。前述したような進捗遅れの報告という行動なら、Javaなどの言語に組み込まれている例外処理のメカニズムが参考になる。
例外処理とは、プログラミングにおいて、入力値が正常でないなど、本来の処理ができない例外ケースの処理のことだ。以前はコード中にif文を記述し、こうした処理を分岐させていた。だが煩雑な上、正常処理と例外処理が入り交じって見通しの悪いコードになってしまうという問題があった。
それに対してJavaの例外処理のメカニズムはよくできている。最初に触れたときは感心したものだ。「try-catch-throw」という機構で、簡単に説明すると、対象範囲を実行する（try）中で、例外的な事象が発生するとそれを例外としてキャッチ（catch）し、正常系のコードと明確に区分けされた例外系のコードで処理を行うものだ。そして、何より秀逸なのが、その例外処理の中で解決できないものについては、より上位の例外処理に例外を投げる（throw）ことができる点である。こうすることで、個々の例外処理での考慮すべき範囲を限定し、見通しの良いコードにできる。
プロジェクトで仕事をするための行動指針としては、この例外処理のメカニズムをぜひ参考にしてほしいと思っている。例外とはつまり問題の発生である。自分が本来求められていることを着実にこなす一方で、例外として処理しなければならない出来事をキャッチして対応する。報告すべきことは、例外をキャッチしたこととその対応状況である。自分の守備範囲を超えた例外は、ちゅうちょなく上位のリーダーやマネジャーに投げてほしい。“できる”エンジニアは、こうした動きが自然にできている。だから安心して仕事を任せられるのである。
一方、上位のマネジャー側には、投げられた例外を適切に処理する機能が必要である。プロジェクトマネジャーがやらなければならない最も重要なことは、いわゆる管理ではなく、上がってきた例外を処理することである。破綻してしまうプロジェクトの多くは、例外をキャッチして処理するメカニズムが機能していない。多段の例外処理構造を用意することで、問題が小さいうちに解決できるようにしたいものである。
ITエンジニアの中にはJavaプログラムの設計はできるのに、どうしたことか自分の仕事には問題を抱え込みがちな人を時々見かける。「いつも書いているJavaのコードみたいにやろうよ」と筆者なら言いたくなる。
