八月の鯨 ～ 人生の半分はトラブル ? ～ ／ 上原 守

ちょっと時期外れですし、ご存知の方もおられると思いますが、「八月の鯨」
という映画があります。
　私が初めてこの映画を観たのは、東京の神保町にある岩波ホールででした。こ
の岩波ホールは、埋もれた名画を発掘して上映するミニシアターの先駆け的存在
です。映画運動家の高野悦子さんが永い間総支配人を務めておられましたが、残
念ながら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審査員穂
エンドユーザ，ユーザのシステム部門，ソフトハウスでの経験を活かして，上流
から下流まで，幅広いソリューションが提供できることを目指しています。