ちょっと時期外れですし、ご存知の方もおられると思いますが、「八月の鯨」という映画があります。
私が初めてこの映画を観たのは、東京の神保町にある岩波ホールででした。この岩波ホールは、埋もれた名画を発掘して上映するミニシアターの先駆け的存在です。映画運動家の高野悦子さんが永い間総支配人を務めておられましたが、残念ながら2月9日に亡くなられてしまいました。ご冥福をお祈りします。
岩波ホールには、東京で暮らしていたときは良く行きました。観た映画で印象に残っている作品には「TOMORROW 明日」「宋家の三姉妹」「芙蓉鎮」「コルチャック先生」「山の郵便配達」「海の沈黙」「父と暮せば」他があります。
こちらで暮らすようになって足が遠のきましたが、好きな映画館なので、高野悦子さんが亡くなられても、是非永く続けてもらいたいと思います。
■もう鯨はこない
「八月の鯨」の舞台は、アメリカのメイン州の小さな島です。メイン州はアメリカ合衆国の北東部に位置し、大西洋に面しています。この島で暮らす老姉妹が主人公で、登場する人たちは、ほとんど（おそらく全員）が60歳以上です。主演のリリアン・ギッシュは、この時91歳で、しかも老姉妹の妹役！です。姉役のベティ・ディヴィスも79歳だったそうです。
姉妹が子供の頃、八月になると島の近くに鯨がやってきて、二人はそれを見るのを楽しみにしていました。しかし時は流れ、もう鯨はやってきません。目が不自由になった姉は気難しくなり、周囲の人たちに刺々しく接します。それを世話する妹は心を痛めます。
姉を元気付けるために、妹は亡命貴族を晩餐に誘ってみたり、また鯨が来たら見られるように大きな窓を作ろうと話すとか、色々と気を使いますが…
■人生の半分はトラブル
ある日、二人の家の近くでベリーを摘んでいた知人が立ち寄ります。
姉の世話に疲れを感じていたリリアン・ギッシュは、思わず愚痴をこぼしますが…こう言われてしまいます。
「人生の半分はトラブルなのよ」
「あとの半分はそれを乗り越えるためにあるの」
この時のリリアン・ギッシュの表情が良いです。
私の仕事では、色々なプロジェクトの遂行が必要になります。以前は、コンピュータやネットワークのシステム構築のプロジェクトが多かったですが、この数年は、業務改善やISOの認証取得のプロジェクトを担当することが増えました。
読者の中には同意していただける方もいらっしゃるかと思います（笑）が、システム開発に限らず、プロジェクトを担当すると「プロジェクト・マネジメントの仕事の半分はトラブルで、残りの半分はそれを乗り越えるためにある」と思います。実際にプロジェクトによっては、WBSベースで管理しなくても、大日程のスケジュール管理と課題管理だけで何とかなってしまう場合もあります。
もう少し外側の視点に立てば「プロジェクトの半数はトラブル・プロジェクトで、残りの半数は辛うじてトラブルを乗り越えるたプロジェクトである」と言えるかもしれません。
■問題と課題
「プロジェクトの半数はトラブル・プロジェクトで、残りの半数は辛うじてトラブルを乗り越えることに成功したプロジェクトである」なら、「成功したプロジェクト」は「トラブルを乗り越えることに成功したプロジェクト」です。
ここで「トラブル」を「プロジェクトの遂行に何らかの悪影響を及ぼす状況」と考え、さらに「悪影響を及ぼす可能性がある状況」も含めると、「問題」という日本語が浮かんできます。日本語だと、一般には語尾が「～がない」「～ができない」となる状況です。
英語は全然だめなので、おこがましいですが「問題」にはquestion（質問・疑問）という訳もありますが、この場合はproblemとtroubleを足したような意味、ISMS2005年版の対訳本だとsequrity eventとsequrity incidentを足したような意味になるかと思います。
「問題」にプロジェクトの遂行に悪影響を及ぼす「可能性」を含めると、思いっきり広く考えれば進捗管理も顧客交渉も問題管理の一つの側面になります。
先ほど、プロジェクトを行う場合に「大日程のスケジュール管理と課題管理だけで何とかなってしまう場合もある」と書きましたが、「課題」は「問題」とは少し違います。どちらかと言うとロジカル・シンキングでよく使われるissueに近いイメージです。「課題」は問題を解決するために行うべきこと、日本語だと「～する」「～の必要がある」という語尾になるかと思います。
例えば、プロジェクト・メンバーに課題管理を書いてもらうと「○○の仕様が決まらない」とかよく書いてきます。これは「問題」であって「課題」ではありません。課題に書き直せば「○○の仕様を決める必要がある」となります。ここで、○○の仕様決めのリミットが×日なら、以下のようにtodoに落とすことができます。
1.▲日迄に○○の仕様案を作成する。
2.△日迄に○○について●●様にレビューする。
3.×日迄に▲▲様に承認をもらう。
もし、仕様が決まらない原因がユーザ側の理解力にある（普通の人はIT用語で書かれた仕様は分かりません）なら、マネージャが判断して仕様案の代わりに、プロトタイプを作るように方針を変える事も考えられます。工数は増えますが、プロジェクトが止まるリスクとのバランスになってきます。
プロジェクト・マネージャには、強い決断力と鋭いバランス感覚が求められますが、その一つの例と言えるかもしれません。
極論すればプロジェクトの「問題」の中には顕在化するまで対処する必要がないものも考えられます。しかし「課題」に上がれば、対応を先延ばしすることができません。
■課題を「管理」するということ
日本語の「管理」には、色々な意味があります。英語のmanagementも「管理」と訳されますし、controlやdirection、governanceも「管理」と訳されることがあります。managementは「経営」、controlは「制御」、directionは「指導」、governanceは「統治」と訳されることもあります。
では、課題を「管理」するという場合、実際にやるべきことは何でしょう。
managementはISO的に言えば「組織に、PDCAサイクルを確立し、導入し、継続的に改善する」と定義できます。またcontrolは、count（counter:～に対して）＋roll（roll:巻紙 法律が書いてある＝rule）ですから、ある事象を一定の範囲内に収める活動を意味します。directionの語源は、di-（強意）＋regere（指揮する、まっすぐにする）ですから「方向を示して引っ張っていく」ような意味になります。governanceはgovernの名詞形で、governは「船の舵を取る」意味のギリシャ語からきているそうですから、権力のある者が政治を行なって支配するような意味かと思います。
プロジェクトにおいて「課題」を管理する場合、大雑把にはプロジェクトの規模（要員数等）と残課題の数のバランスをとります。フェーズにもよりますが、全員が課題解決に追われている状況では、成果物の作成に工数が注ぎ込まれていないことが分かります。少し細かく見るなら、課題の発生数と解決までの平均時間からフェーズの遅延リスクが判断できますし、設定された期限から遅れている課題があればそのリスクを考えます。
これらのことから考えると、課題を管理することは課題全体をコントロール下に置くことが「課題管理」になると思います。
■人生の残りの半分はトラブルを乗り越えるために
プロジェクト・マネジメントの場合は、広い意味で言えば半分は問題管理で、残りの半分は課題管理かも知れません。
ISMSでのリスク対策として定義されている方法は、低減、回避、転嫁、受容があります。
プロジェクトでは、乗り越えることが困難（低減が難しい）に思われるトラブルでも、回避、転嫁、受容のどの方法をとるかを考え、その結果、リスクがどのように変化するかを考えることには意味があると思います。
しかし人間を永くやっていると、身内の病気など、低減も回避も転嫁もできないトラブルに出会うことがあります。こういった、低減も回避も転嫁もできないトラブルに出会った場合、私はいつもこの言葉を思い出します。
「たとえ明日世界が終わるとしても、私はリンゴの苗を植えよう」ルター
————————————————————————
■執筆者プロフィール
上原 守
ITC,CISA,CISM,ISMS審査員穂
エンドユーザ，ユーザのシステム部門，ソフトハウスでの経験を活かして，上流
から下流まで，幅広いソリューションが提供できることを目指しています。
