「デスマーチ」を生き残るために(2)

前回の続きです。

ソフトウェア開発とはほぼ無縁の私がこの本を通読することができたのは、個人的に興味のあるテーマだったことのほかに、

「このスーパー・ウィジェット・システムは、何が何でも、絶対、必ず、1月1日までに完成させねばならない。でないと、世界が破滅する」。この指令が何段もの社内官僚の層を通過すると、どんどん尾ヒレが付いて、次のようになる…

こんな感じのちょっと皮肉めいたユーモアが、ほぼ全編にわたってまぶされていたからかもしれません。

さて、筆者がデスマーチを生き残るために最初に注意すべき点は「政治」である、と指摘します。プロジェクトの中身ではありません。上記の引用も、この「政治」について書かれた一節です。

ソフトウェア開発でも多種多様の関係者がいるのでしょうけど、子育ても同様です。実家、親類、先生、ママ友。自らの「プロジェクト」の方針に対し「味方」となってくれる人は誰か?常に気を配らなければなりません。同じ人が(本人の意思とは関係なく)いつの間にか味方から敵に変わってしまうことも、残念ながらありえます。

さらには、SNSを含むネットに流れる有象無象の意見も、その影響力はバカになりません。子育ては、ソフトウェア開発よりも変動要素が大きい(文字通り24時間何が起こるかわからんのです)ゆえに、「政治」は大きな問題点かもしれません。

もちろん影響力を最小限にする、つまり人付き合いやネットとの接触を減らす、という選択肢もありえますが、昨今の子育てではあまりお勧めはできません。親だけで全てのミッションをこなすのは物理的に不可能と言っていい。ただ、子供の成長に合わせて、近しい「関係者」をこちらから意図的にシャッフルすることは、考慮すべきでしょう。

本書の後半では「時間の管理」についても一章をさいて述べられています。ただ、ここでは管理ツールの名前が出てくるわけではなく、なぜ無駄に時間を使ってしまうのか?とついて触れ、あの『7つの習慣』にも登場する「重要性/緊急性」の4象限も登場します。

また、物事の重要性/緊急性を決定するのは、プロジェクトの中身もさることながら、関係者との「政治」も深く関わる、と筆者は指摘します。関係者がどーでもいいことで緊急性をがなりたてるとプロジェクトに余計な停滞が発生する。残念ながらよくある話ですが、その面でも「政治」に気を使うことは、時間の有効な使い方に影響することがわかります。

そして、筆者が最後に強調した一節

それよりずっと重要なのは、生き残ることだ。我々が目指すデスマーチ・プロジェクトは、上層部を驚嘆させる日程と予算で進捗し、エンドユーザーに輝かしい結果を提供するものだが、我々は、これらすべてを健康、才覚、家族、ユーモアのセンスのどれも損なわないで行うべきなのだ。それができてこそ最高だ。

なによりも、生き残ること、できればユーモアのセンスを忘れずに生き残ること、これが大事なのだと思います。

全ての「プロジェクト・マネージャー」のみなさま、笑って、良いお年を。

「デスマーチ」を生き残るために(1)

生き残れば十分なんです。少なくとも、最低条件ではないんです。

私はIT業界に勤めているわけではありません。ただ、ソフトウェア開発のプロジェクト・マネジメントには若干の興味がありました。子育てや自分の人生構築に何らかの参考になるかもしれない、と思ったからです。

この本は全ての子育てパパにオススメできる、というわけではありません。ソフトウェア開発の専門用語が頻発し、私も専門用語はあまり理解できていないと思います。ただ、1944年生まれの著者が、巻頭に

4世代にわたり家族が増えたことは、
デスマーチ・プロジェクトで、
何が重要で、
何が最優先すべきかを
適切に決める上で、
最大のヒントになった

と書いたのを見て、あ、これは期待出来る、と思いました。

まず著者は「デスマーチ」の定義から書き起こします。幾つかの定義の中で、こういう項目があります

通常必要な人数の半分以下しかエンジニアを割り当てないプロジェクト

二人の子供を持つ父親として言わせていただければ、両親の片一方が不在がち、あるいは病気がちで、子供が二人以上いて、かつ「実家」の定常的支援が得られない子育ては、ほとんどこれに該当する、つまり「デスマーチ」である、と言っていいと思います。現代の子育てにおいて、かなりの核家族は「デスマーチ」にならざるをえないのです。

その一方で、著者はこうも書いています

私の結論は、デスマーチ・プロジェクトは、常態であって、例外ではないというものだ。

異論がある方も多々あるかと思います。ソフトウェア開発と子育てを一緒にするとは何事か?と思う方もおられるかと思います。ただ、著者はデスマーチ・プロジェクトに反対しているわけではないことを強調し、その上で、デスマーチ・プロジェクトを成功させ、生き残るために何をすればいいか、に焦点を絞ってこの本を書いています。

そのために、これだけは覚えておいてほしい言葉として「トリアージ」をあげています。医療におけるトリアージの概念を聞いたことがあるかもしれません。特に救急医療において、限られた医療資源をどの患者さんにどの程度つぎ込むか、という難しい判断です。これを、プロジェクト管理にも応用するのです。乏しい資源(人、時間、お金)を何につぎ込むのか?

私が関係したほとんどすべてのデスマーチ・プロジェクトでは、システムの要求項目を、トリアージスタイルで、
「やらねばならぬ(must-do)」
「やったほうがいい(should-do)」
「やれればできる(could-do)」
の三つに分けるのが常識となっていた。

この三つの分け方は、単純ではありますが、私にとっては新たな発見でした。重要度を10段階に分けるよりよっぽどわかりやすいです。そして、すべての要求項目が「やらねばならぬ(must-do)」に入っている時点で、すでにおかしい、と容易に気づくこともできます。

もちろん子供に対して出来る限りの事はしてあげたい、というのは自然な親心ですし、残念ながらそれを無理に押し付ける人も少なくありません。でも、トリアージスタイルで、できないことはできない、と判断することは、ソフトウェア開発よりはるかに複雑な子育てにおいて、とても大切なことだと思います。

この項、続きます。