単なる偶然だが、東京へ出張していた昨日と今日、ちょうど中島美嘉も東京国際フォーラムでライブをやっていたらしい。
僕は怠惰なファンなので、チケットを買っていない。
でも、今日、東京から大阪へ帰ってくる前に、思わず有楽町駅で降りて、東京国際フォーラムのＡホール前まで歩いてしまった。
まだ１３：３０ごろで、中島美嘉のファンらしき人たちも数えるほどしかおらず、「入場開始　１６：００」という張り紙があった。
ついでにビッグエコー有楽町店で２時間、中島美嘉と柴田淳の曲ばかり歌ってきた。
だが、この有楽町店のプレミアDAMが最悪だった。
プレミアDAMなら、中島美嘉の本人映像曲は全曲対応しているはずなのに、「Helpless Rain」も「GAME」も「雪の華」さえも、本人映像が入っていなかった。
まぁ、ど～でもいいことなのだけれど、かなり損した気分だ。
でも大阪の道頓堀店、千日前店、千日前２号店、梅田中央店などの、薄汚いビッグエコーと違って、禁煙ルームがちゃんとあるだけましだろう。
今のところ、大阪市内で行く価値のある清潔なビッグエコーは梅田桜橋店だけである。

状況証拠だけで死刑判決が出た和歌山カレー事件について、最高裁の判断がいかに不適切だったか、ビデオニュース・ドットコムが緻密に検証している。
要するに、ほぼ冤罪に間違いない。やや長文になるが、そのごく一部をご紹介したい。
ビデオニュース・ドットコムの「第420回マル激トーク・オン・ディマンド」の放送内容にしたがって、検察が死刑判決の状況証拠としている点を以下に説明してみる。
■被告以外の全員がヒ素を持っていなかった証明はされていない
犯行に使われた135グラムのヒ素は、ふつうの白い紙コップで、４つある鍋のうち１つだけに入れられた。
紙コップでヒ素を入れるだけなら、一瞬でできる。したがって、現場で一人きりになるまで待つ必要はない。
しかし検察は一人きりにならないとできない行為であるとし、鍋の近くで一人きりになったのが被告だけだったという目撃証言を根拠に、被告を実行犯だと論証している。
しかし実際にはヒ素の混入時刻とされる昼１２時から１時の間、鍋の付近には被告の娘と、町内会の男性２名がいた。この点ですでに検察の論証は破綻している。
また、検察は、混入時刻に現場にいた人々のうち、被告が自宅にヒ素を持っていたことは証明したが、被告以外の全員がヒ素を持っていなかったことを証明していない。
にもかかわらず、検察は被告一名だけを起訴した。検察は、十分な理由もなく、なぜか犯人が複数である可能性を最初から否定しているのだ。
■あやふやな目撃証言
また、被告が鍋の付近で不審な動きをしていたという目撃証言は、夏祭り会場の近くに住んでいた女子高校生の証言だ。
ただ、その証言は、カーテン越しにたまたま外を見ていたら、被告が鍋の付近をうろうろし、鍋のふたを開けた、という内容である。
ヒ素を入れたのを見た、という内容ではない。
しかも、最初は一階からカーテン越しに見た、という内容だった証言が、後に二階から見ていたという内容に変わっている。
さらに、最初はその不審な人物が、タオルを首にかけていたという証言が、後にタオルをかけていなかったと変わった。
ところで、「鍋の付近をうろうろしていた」という行動を、「不審だ」ととらえるか、とらえないかは、純粋に目撃者の主観的判断であり、本来、客観的な証拠にはなりえない。
さらに、この目撃者が、被告がフタを開けたのを目撃した鍋は、ヒ素の入っていなかった鍋だと分かっている。
また、この目撃者が見た不審人物は、髪型や体型などから、被告ではなく、被告の娘であることも分かっている。
要するに、この目撃者の証言は、状況証拠としてはあまりに脆弱すぎる。
■ヒ素鑑定の不審点
次に、被告の自宅にあった亜ヒ酸と、カレーから検出された亜ヒ酸と、上述の紙コップから検出された亜ヒ酸の成分が、一致したという状況証拠について。
ちなみに被告がヒ素を所有していたのは、被告の夫がシロアリ駆除業をしており、ヒ素は殺虫剤として一般的に使われているためだ。
亜ヒ酸の鑑定は、最初、科学警察研究所でおこなわれたが、「同一性については判断できない」という結論になった。
そこで、経緯は不明だが、東京理科大学の教授が自ら鑑定を名乗り出て、スプリングエイトという非常に大規模な設備で分析を行った。
その結果、亜ヒ酸そのものではなく、亜ヒ酸に含まれる不純物が同一であることが確認された。
したがって、３つの亜ヒ酸が、同一時期に、同一工場で製造されたものであることが確認された。
そして、その亜ヒ酸は中国から輸入されたもので、日本に３トン輸入されていることも分かった。
しかし、その３トンの日本国内での販売経路は分かっていないし、中国の工場の場所も特定されていない。ただ亜ヒ酸の缶に「中国製」と印刷されているだけである。
また、不純物は同一だが、不純物の量が同一であることまで確認されたわけではない。
さらに、不純物は亜ヒ酸と化学的に結合するものではなく、いわば単なる「ゴミ」であり、しかも、ごく微量しか含まれていなかった。
したがって、製造や販売の経路でいくらでも混入しうるし、製造・販売経路で混入したと考えるのが自然だ。
そして、３つの亜ヒ酸以外に、事件と無関係な２０個以上の亜ヒ酸も集めて比較分析された。
しかし、それらは工場や、学術研究などに使われていた亜ヒ酸ばかりで、殺虫剤や肥料など、類似の用途の亜ヒ酸とは比較されていない。
用途の全く異なる亜ヒ酸と比較して、３つの亜ヒ酸がそれらと特徴が異なるから、３つの亜ヒ酸は同じものだ。これが東京理科大学の教授の鑑定結果である。
用途の類似する、他の殺虫剤用の亜ヒ酸と比較しなかったのは、鑑定の手続きとして明らかに不備がある。
東京理科大学の教授が行った鑑定は、比較対象とする基準の亜ヒ酸を設定せずに比較検証するという、明らかに不適切な手続きによるものだった。
しかも、亜ヒ酸そのものが合致したわけではなく、不純物の合致が検出されただけであり、かつ、不純物の量は一致していない。
したがって、この亜ヒ酸の鑑定も、状況証拠として非常に脆弱である。
■被告の髪の毛から検出されたヒ素の不自然さ
次に、林真須美被告の髪の毛からヒ素が検出された件だ。
被告は逮捕当時、４か所から髪の毛を採取され、その２ヵ月後に鑑定に出されている。
最初は某医科大学に鑑定に出したが、鑑定できなかった。
そこで、経緯は不明だが、再び上述の東京理科大学の教授に鑑定を依頼する。
この東京理科大学の教授は、再びスプリングエイトという大規模設備で被告の髪の毛に含まれる亜ヒ酸の分析を行った。
分析されたのは、長さ約16cmの髪の毛で、髪の毛が採取されたのは事件の約４か月後だ。
分析の結果は、亜ヒ酸が発見されたのは、髪の毛の切断点から4.8cmの一点だけという内容だった。
事件発生から約４か月後の採取であることを考えると、髪の毛の伸びる速度から推定して、切断点から4.8cmという分析結果はいかにも真実らしく見える。
しかし、仮に事件発生時に亜ヒ酸が髪の毛に付着したとして、密集して生えている髪の毛の根元だけに付着するというのは、いかにも不自然である。
亜ヒ酸は外から髪の毛にふりかかって付着したとしか考えられないが、そうであれば、毛先から根元まで、亜ヒ酸が散らばって付着するのが自然である。
いったいどうなれば、外からふりかかったヒ素が、髪の毛の根元の一点だけに付着するなどということが起こりえるのか。
髪の毛の根元だけに亜ヒ酸が付着するということが、合理的に説明できない以上、この分析結果そのものにも問題があると言わざるを得ない。
■保険金詐取の「プロ」である被告夫婦
また、林真須美被告が過去に、保険金を詐取するためにヒ素を使っている点も、状況証拠としてあげられている。
被告が殺そうとした相手は夫と、被告の自宅に居候していたＩさんである。
夫についてはヒ素入りの「くず湯」を飲ませて殺害し、保険金を取ろうとしたが失敗した。Ｉさんについては牛丼にヒ素を入れて殺害しようとした。
こういった保険金目当ての殺人をするような人物だから、カレーへのヒ素混入をする可能性が十分にあるというのが、検察の立証だ。
しかし検察は一方で、カレー事件の目的が保険金詐取でないことを認めている。カレーを食べた結果、誰が死ぬかわらかないし、事前に町内会の全員に生命保険をかけることも不可能なので、当然である。
一方は保険金詐取という目的が明確な殺人未遂であり、他方は全く目的のない殺人である。
この両者を検察は類似した事件とみなし、「だから被告がカレー事件もやった」と立証している。
しかし、これは逆ではないか。
むしろ被告は過去、目的が明確でない殺人を計画したことがない。保険金詐取という、目的の明確な殺人未遂しか実行したことがない。
したがって、被告を目的の全く分からないカレー事件の容疑者とすることには無理がある、というのが合理的な推論である。
■実際には被告の夫は自らくず湯を飲んだ
さらに、実際には、くず湯事件について「被害者」である夫は「自分でくず湯を飲んだ」と証言している。
ビデオニュース・ドットコムは、つい最近、被告の夫である健治さんにインタビューをしており、それもビデオニュース・ドットコムで見ることができる。
ふつうのマスメディアが絶対に報道しない内容なので、このインタビューは必見である。
ところで、くず湯にヒ素を入れたのが、林真須美被告である証拠が何もないことは、検察も認めている。
要するに、くず湯にヒ素を入れて被告の夫・健治さんを殺そうとしたのは、別人の可能性があるのだ。
では検察は、なぜくず湯事件についても被告がヒ素を入れたと判断したのか。実はこれも単なる状況証拠なのだ。
その状況証拠も、きわめて脆弱なものである。
上述の同居人のＩさんが、くず湯を飲んで入院した夫を見舞いに来た林真須美被告が、あんたなんか早く死んじゃえ、と言ったのをたまたま耳にした、と証言しているのだ。
そのＩさんの証言だけを根拠に、検察はくず湯にヒ素を入れたのは被告であると断定しているのだ。
Ｉさん自身が、ヒ素入りの牛丼で殺害されかけた事件も、同様に単なる状況証拠で、林真須美被告がヒ素を入れたと断定されている。
つまり、Ｉさんが被告に「牛丼作って」と頼んで、作ってもらった牛丼を食べたら、突然体調がおかしくなったというＩさんの証言だけを根拠に、検察はこの牛丼にヒ素を入れたのは被告だと断定しているのだ。
ところで、体調がおかしくなったＩさんは、実は、その日は病院に行っていない。体調がおかしくなったと言っても、病院に行くほどではなかったのだ。
くず湯の件も、牛丼の件も、そしてカレーの件も、被告がヒ素を混入した現場を目撃した人物は一人も存在しない。
くず湯については、被告が病院で被害者である夫に対して「あんたなんか早く死んじゃえ」と言ったのを聞いたというＩさんの証言だけが状況証拠となっている。
しかも、当の被害者である夫・健治さん自身が「自分で飲んだ」と言って、林真須美被告の犯行であることを明確に否定しいてる。
牛丼については、Ｉさんが自分が作ってと頼んだ牛丼を食べたら体調がおかしくなったという経緯だけだ。
カレーについては、近所の女子高校生の上述のような目撃証言があるだけである。
こういった脆弱な状況証拠だけで、この３件すべてについて、ヒ素を混入したのは林真須美被告であると、検察は断定したのだ。
なお、被告が最初に逮捕されたのは、保険金詐取を目的とする殺人未遂容疑であり、夏祭りのカレー事件で再逮捕されたのは、最後である。
さらに、被告の夫・健治さんは有罪判決をうけて服役しているが、それは保険金詐欺罪である。
つまり、妻である林真須美被告と共謀して、自らの体をこわすことで、保険金を詐取しようとした容疑で有罪となり、服役したのだ。
よく考えてみよう。
被告の夫・健治さんが保険金詐欺罪で有罪になったということは、検察は健治さんが、彼自身の言うとおり「自分でくず湯を飲んだ」ことを認めていることになる。
つまり、妻である林真須美被告と共謀して、自らくず湯を飲むことで、保険金を詐取しようとしたという認定をしていることになる。
にもかかわらず検察は、もう一方のカレー事件では、被告の夫は、知らない間にくず湯にヒ素を混入され、林真須美被告に殺されかけた、だから林真須美被告はカレーにもヒ素を混入した、という推論をしているのだ。
同一の保険金詐欺事件、つまり「くず湯」事件について、検察は完全に矛盾した推論をしているのだ。
ちなみに、自らヒ素入りのくず湯を飲んだ理由については、健治さん自身が次のように説明している。
林真須美被告の母親が、平成８年に死亡したときの保険金を、健治さんは競輪で三～四千万円使ってしまった。
それがバレたために林真須美被告は夫に対して激怒し、被告の夫は、じゃあ自分の体を張ってその金を取り返すよと言い、自らヒ素入りのくず湯を飲んだ、ということだ。
■健治さんの証言が一審で取り上げられなかった理由
ところで、健治さんのこの「自分でくず湯を飲んだ」という証言は、身内である林真須美被告をかばうための嘘だとされている。
その理由は、健治さんが一審ではこの証言をせず、二審になって初めてこの証言をしたためである。
ところが、実際には、健治さんは一審のとき、すでにこの証言を検事に伝えていた。しかし、一審で検察はこの証言を無視したのだ。
健治さんは、検事から、一審の法廷の進行は弁護士に従うように言われたため、そのとおりにしていたところ、一審でこの証言は取り上げられず、結果として、健治さんが一審で自分自身のこの証言について話す機会がなかったのだ。
検事自身が健治さんの重要証言を、一審で意図的に取り上げないでおいて、一審でその証言が出されなかったことを理由に、その証言自体を信用するに足りないと判断したというわけだ。
さらに、くず湯事件の経緯について、健治さんの入院した病院に被告が見舞いに来たのは、入院の１０日後であることがわかっている。
仮に林真須美被告が、健治さんに気づかれないようにくず湯にヒ素を混入して殺そうとしたなら、入院してすぐに死んだかどうか、または、一命をとりとめたとすれば、自分がヒ素を混入したことに気づいていないかどうか、それを確認するために、すぐに病院に行くはずだ、と考えるのが合理的である。
しかし実際には入院して１０日間たって初めて、被告は夫の病院を訪れている。
この事実からしても、夫である健治さんの証言どおり、健治さん自身が「じゃあ自分で飲んでやる！」と言ってヒ素を飲んで病院にかつぎこまれた。
そして、母親の死亡保険金を使い込まれて、林真須美被告は健治さんに腹を立てており、１０日間放っておいた、という、ある種の夫婦げんかと考えるのが自然である。
■保険金詐取については夫婦は密接な共犯者
というのは、それまでに林真須美被告と健治さんは、さまざまな方法で保険金詐取を繰り返しており、健治さん自身、その総額が数億円にのぼることを認めている。（だからこそＩさんのような居候を食べさせられるわけだが）
もちろん保険金詐取を繰り返す夫婦は、それはそれでひどい人間たちである。
しかし、二人で協力して数億円にのぼる保険金を詐取してきた夫婦で、しかも林真須美被告からすると、夫の協力なしには保険金詐取ができないのである。保険金詐取ができなければ、生活できないのである。
そういう、長年にわたって密接な共犯関係にある夫婦の妻、つまり林真須美被告が、夫に気づかれないようにくず湯にヒ素を混入し、夫を殺害しようという合理的な理由とは何だろうか。
しかも、仮に本当に林真須美被告が致死量のヒ素をくず湯に混入していたとしたらどうなるだろうか。
健治さんは自宅のその場で死亡するはずである。警察に通報すれば間違いなく林真須美被告が容疑をかけられる。
長年にわたって数億円にものぼる保険金詐取をくりかえしてきた、いわば犯罪のプロ（それで生活していたのだから文字通りプロ）である夫婦の妻である林真須美被告が、そんなずさんな殺人を計画すると考えるのには明らかに無理がある。
同じことがカレー事件にも言える。
仮に本当に被告が犯人だとしたら、犯行にはヒ素が使われており、被告の家族がシロアリ駆除業でヒ素を扱っていることは、警察が調べればすぐに分かる。
しかもカレー事件の犯行現場は被告の自宅の近くだ。真っ先に林真須美被告に嫌疑がかけられるのは間違いない。
自分に疑いがかけられ、逮捕されることが、実行する前から分かっているのだ。
しかも林真須美被告は、ヒ素が猛毒であることも知っていて、カレーに混入すれば複数の死亡者が出て、死刑が確実であることも十分予想できる。
そんな割に合わない殺人を、保険金詐取のプロがやるだろうか？
ところが検察は、被告は保険金詐取を繰り返すことで、犯罪に抵抗感がなくなっており、したがって、カレー事件の犯行に及んだと主張している。
しかし、これはまったく逆だろう。
林真須美被告は、保険金詐取という犯罪のプロであるからこそ、簡単にバレることが最初から分かっており、しかも死刑が確実であるような殺人事件を、わざわざ犯すはずがない。
こう考える方が、はるかに合理的である。
■犯行推定時刻の不合理
また、カレー事件におけるヒ素の取扱い方法についても、不合理な点がある。
ヒ素は水に溶けない。また、比重が大きく、すぐに凝固してしまう。
検察によれば、カレーにヒ素が混入されたのは昼の１２時から１時の間で、そのとき、カレー鍋の火は止まっていた。
カレーが実際に配布されたのは夕方の６時だ。
仮に被告がカレーにヒ素を混入して殺人を計画していたなら、水溶性ではないヒ素はカレーと混ざらないことは当然知っているので、鍋の中を十分にかきまぜる必要がある。
しかしそれでもヒ素の比重は大きいので、夕方６時までには鍋の底に沈んでしまい、凝固してしまっている恐れがある。
つまり、６時に配布されることが分かっているカレーに、ヒ素の性質を知っている被告が、昼の１２時にヒ素を混入するのは、殺人が目的だと仮定すると、実に不合理なのだ。
６時まで露呈することなく殺人を実行しようとすれば、６時のカレー配布の前、誰かがカレーを温めなおす直前にヒ素を混入するのが、もっとも確実で、露呈しない方法である。
また、林真須美被告が単独犯で、自分の犯行計画を家族にも話していなかったとすると、自分の夫や娘がカレーを食べて犠牲になる可能性がある。
長年にわたって保険金詐取を繰り返してきたくらいなのだから、林真須美被告が、十分に利己的で、自己中心的だと仮定できる。
であれば、まず保険金詐欺の重要なパートナーである夫が死ぬかもしれないような殺人を計画するはずがないし、まして自分の娘が死ぬかもしれないようなことを計画するはずがない。
どう考えても林真須美被告が、上述のような極めて露呈する危険性が高い、稚拙な方法で、しかも死刑が確実である殺人事件を実行するための、合理的な理由が見つからないのだ。
ビデオニュース・ドットコムの議論は、ここからさらにマスコミの集団過熱報道（松本サリン事件や光市母子殺害事件との関連）、裁判員制度の是非などに進んでいく。
ただ、以上をお読み頂いただけでも、死刑の根拠になっている状況証拠が、いかに脆弱であるか、お分かりだろう。
そして、一つひとつの状況証拠を検証すると、逆に、林真須美被告がとても今回のカレー事件のような、割に合わない犯罪を犯しそうにないことの証拠になることも、お分かりだろう。
あとはビデオニュース・ドットコムをじっくりとご覧いただきたい。
僕個人は、林真須美被告が過去に保険金詐取を繰り返していた点については、れっきとした犯罪者であるが、カレー事件については冤罪だと、ほぼ確信した。
ところで、カレー事件の起こった夏祭りには町内会の人たちしか参加していないらしい。
だとすると、真犯人はカレー事件の起こった町で、いまだに平気な顔をして生活している可能性が高いということになる。
死刑判決が確定した後、カレー事件の被害者の皆さんは、これは一つの節目に過ぎず、私たちの苦しみは一生続くのだと訴えられていた。
まさにその言葉通り、カレー事件の起こった町の人たちは、誰が本当の犯人なのか分からないまま、一生、生活し続けなければならない可能性が高い。
果たして、これがあるべき司法の姿だろうか？

引続きマイクロソフト Office Project Server 2007のバグ（不具合）について、Microsoft Office Project Professional 2007とProject Web Access 2007を組み合わせて使った場合の不具合について詳しく説明したい。
I’ll continue explaining the “bug” of Microsoft Office Project Server 2007 when using it with the combination of Office Project Professional 2007 and Project Web Access 2007.
ひとことで言えば、プロジェクト管理者がOffice Project Professional 2007から「発行」したタスク割当の変更が、Project Web Access 2007の「プロジェクトセンタ」画面には反映されるが、「自分のタスク」画面には反映されない場合がある、という不具合だ。
We can summarize the “bug” as follows: when project manager “publishes” task assignment updates from Project Professional 2007, in some cases, the updates are applied only to “Project Center” but not to “My Tasks” of Project Web Access 2007.
ご承知のようにMicrosoft Office Project Server 2007は、プロジェクト管理者はOffice Project Professional 2007で詳細なプロジェクト計画を作成し、チームメンバーはProject Web Access 2007のウェブ画面から、各自の進捗を入力するという使い方を、通常の使い方として想定している。
As you know, Microsoft Office Project Server 2007 expects project managers use Professional 2007 for planning in detail while team members only use Project Web Access 2007 for checking and inputting the progress of each task.
その理由は、チームメンバー全員分のOffice Project Professional 2007を購入すると導入コストが高くなるし、インストール展開する作業工数も大きくなるためだ。
The reason is that if you have to install Project Professional 2007 for all team members, it will cost too much.
チームメンバーの進捗報告や新規タスク提案の作業が、Project Web Access 2007のウェブ画面だけで完結できるというのは、Office Project Serverの大きな「売り」である。
Team members only need Project Web Access 2007 for reporting task progress. That’s one of the advantages of implementing Office Project Server 2007 system.
ところが、チームメンバーが進捗状況を入力する唯一のインターフェースである、Project Web Access 2007の「自分のタスク」画面に、プロジェクト管理者からのタスク割当の更新が反映されないことがあるのだ。
However, the updates of task assignment published by project managers aren’t sometimes applied to “My Tasks” of Project Web Access 2007.
そしてマイクロソフトは、それがOffice Project Server 2007の「仕様」だと言っている。
Microsoft says it is “specifications” of Office Project Server 2007.
以下、詳細を説明する。
I’ll explain it in detail.
（Ａ）プロジェクト管理者の田中さんが、チームメンバーの鈴木さんに、あるプロジェクトのうちの「タスクＡ」を割り当てたとする。タスクの期間や標準時間の設定は何でも良い。
(A) Ms. Tanaka, project manager, assigns “Task-A” to Mr. Suzuki, team member. Its duration and baseline hours can be whatever.
（Ｂ）チームメンバーの鈴木さんはProject Web Accessの「自分のタスク」画面から、「タスクＡ」の進捗を入力し、一時的に「保存」だけしておいた。ただ、他のタスクの進捗も入力してから、まとめてプロジェクト管理者に「提出」しようと思っただけである。
(B) Mr. Suzuki inputs his own task progress on “My Tasks” of Project Web Access 2007 and temporarily saves it. He just wants to “submit” his progress after finishing inputting all other task progresses.
（Ｃ）その頃、プロジェクト管理者の田中さんは、鈴木さんに対する「タスクＡ」の割り当てを変更したいと思い、Office Project Professional 2007で割り当てを変更し（例えばタスクの期間を変更するなど）、Project Server 2007に対して「保存」かつ「発行」したとする。
(C) At this moment, Ms. Tanaka wants to change “Task-A” assignment to Mr. Suzuki. So she updates the assignment by using Office Project Professional 2007, saves and “publishes” it to Project Server 2007.
（Ｄ）ところが、Office Project Server 2007の仕様上、その「発行」は、Project Web Access 2007側では「プロジェクトセンタ」のプロジェクト計画にしか反映されない。つまり、鈴木さんが「自分のタスク」で「タスクＡ」を開くと、依然として自分が一時的に「保存」した時のままの状態である。
(D) However, because of the specifications of Office Project Server 2007, the updates published by Ms. Tanaka are applied only to “Project Center” of Project Web Access 2007. Even when Mr. Suzuki opens “My Tasks”, “Task-A” still remains the same status as Mr. Suzuki temporarily saved it.
さて、以上のような動作は、プロジェクト管理の業務フロー上、適切な仕様と言えるだろうか。
Can this be appropriate specifications for project management workflow?
プロジェクト管理の業務フロー上、プロジェクト計画の変更権限はあくまでプロジェクト管理者にある。だからこそ、チームメンバーが「提出」したタスク進捗の更新は、プロジェクト管理者が「承諾」「発行」しない限り、「プロジェクトセンタ」のプロジェクト計画に反映されない。
Concerning project management workflow, the authority of changing project baseline plans belongs to project managers. That’s why the task updates submitted by team members will not be applied to “Project Center” until project managers “approve” and “publish” them.
であれば、（Ｃ）の段階でプロジェクト管理者が変更して「発行」したタスク割当は、Project Web Access 2007の「プロジェクトセンタ」だけでなく、「自分のタスク」画面にも強制的に反映されるべきではないだろうか。
If this is true, the task assignment updates published by project managers at step (C) should be applied not only to “Project Center” but also to “My Tasks” of Project Web Access 2007.
にもかかわらず、Office Project Server 2007の仕様上、プロジェクト管理者がProject Professional 2007を使ってProject Server 2007へ「発行」したタスク割当の変更は、Project Web Access 2007上では「プロジェクトセンタ」画面には反映されるが、「自分のタスク」画面には反映されないという、不可解な仕様になっている。
Nontheless the task updates published by project managers are applied only to “Project Center” and NOT to “My Tasks” of Project Web Access 2007. This is a strange specification of Office Project Server 2007.
また、チームメンバーにとって、自分に割り当てられたタスクに対する進捗を入力できる画面は「自分のタスク」画面だけである。
In addition, team members can input their own task progresses only through “My Tasks” screen.
その画面に、プロジェクト管理者が「発行」した最新の割り当てが反映されないのは、当然のことながら、チームメンバーにとって非常に不都合である。古いままの開始日・終了日・標準作業時間の割り当て状況を見つつ、進捗を入力するしかないのだ。
If “My Tasks” screen doesn’t show the latest updates of assignment which are published by project managers, that’s really annoying for team members because what team members can rely on when inputting their own progress are old task assignments, old start date, old finish date and old baseline hours.
They cannot refer to the updated task assignments, updated start date, updated finish date or updated baseline hours.
ただし、マイクロソフトによれば、この不可解な仕様には「回避策」がある。
それは以下のような手順である。
However, according to Microsoft, there is a workaround for this strange specifications of Project Server 2007 as follows.
（Ｅ）鈴木さんをふくむ全てのチームメンバーは、一時的に「保存」中で、まだ「提出」していない進捗入力を、とにかくいったん全て「提出」する。
(E) At any rate, all team members including Mr. Suzuki submit every progress which are not submitted yet.
（Ｆ）プロジェクト管理者の田中さんは、それらの「提出」内容が適切かどうかにかかわらず、全てを「承諾」かつ「発行」する。
(F) At any rate, Ms. Tanaka, project manager, approves and publishes the submitted progresses.
（Ｇ）そうすると、プロジェクト管理者の田中さんが先ほど「発行」したタスク割当の更新は、当然、チームメンバーが「提出」してきた進捗状況で全て上書き変更されてしまう。
(G) Then all the assignment updates which Ms. Tanaka input before by using Project Professional 2007 are overwritten by the approved and published progresses of all team members.
（Ｈ）それに構わず、プロジェクト管理者の田中さんは再度、タスクの割当を変更し、Project Professional 2007から「発行」し直す。
(H) Ms. Tanaka, project manager, inputs task updates again and publishes them with Project Professional 2007.
（Ｉ）こうすることで初めて、田中さんの発行したタスク割当の更新は、各チームメンバーのProject Web Access 2007の「自分のタスク」画面と「プロジェクトセンタ」画面の両方に反映されるのだ。
(I) By doing this, the task updates published by Ms. Tanaka are applied both to “My Tasks” and “Project Center” of Project Web Access 2007.
これがOffice Project Server 2007の仕様である。
These are “specifications” of Office Project Server 2007.
仮に、プロジェクト管理者の田中さんが、（Ｆ）の段階で、一部の「提出」を「承諾」ではなく「拒否」したとしよう。
Let’s suppose that Ms. Tanaka rejects some updates submitted by team members at step (F).
するとそれらのタスクについてだけは、（Ｉ）の段階でProject Web Access 2007の「自分のタスク」画面に「発行」が反映されなくなってしまうのだ。つまり先ほどの（Ｄ）と同じ状況になってしまう。
Then, only regarding the tasks whose update are rejected by project manager, even how many times project manager publishes task assignment updates, such publishements will never be applied to “My Tasks” of Project Web Access forever.
以上をまとめると、プロジェクト管理者が自分が「発行」したタスク割り当ての更新を、各チームメンバーのProject Web Access 2007の「自分のタスク」画面に反映させたい場合、以下の条件がすべて必要になる。
Let’s summarize what is described above. If project manager wants to apply every publishement of task assignment updates to “My Tasks” page of each team member, all the following conditions must be met.
（１）チームメンバーはタスクの進捗を入力したら、単に「保存」するだけでなく、必ず「提出」する必要がある。
(1) Every team member must “submit” all progress updates to project manager, not only “save” them as frequently as possible.
（２）かつ、プロジェクト管理者は、チームメンバーの「提出」した進捗入力を、その内容がいかに不適切であろうと、いったんは全て「承諾」し「発行」しなければならない。
(2) Project manager must “approve” and “publish” all the updates submitted by team members even if project manager finds some of the updates inappropriate.
（３）その上で、プロジェクト管理者は、（２）においてチームメンバーの「提出」を「承諾」「発行」したことで、ぐちゃぐちゃになったプロジェクトファイルを、自分の想定の内容に変更し直して、改めて「発行」しなければならない。
(3) By doing so, the project file will inevitably become a ‘mess’ because project manager must “approve” and “publish” all the updates submitted by team members even if some updates are clearly inappropriate. Then project manager must correct every inappropriate point one by one and, in addition, must update task assignments just as the project manager originally wants to make them so.
さて、もしみなさんがプロジェクト管理者の立場だとしたら、Project Professional 2007上で、いったい何が自分の想定するプロジェクト計画だったのか、そのうち分からなくなってしまうに違いない。
By the way, if you are a project manager using Microsoft Office Project Server 2007, you will be inevitably thrown into a mess where you cannot see what was your original task assignment plan.
以上のようなMicrosoft Office Project Server 2007の「仕様」を、バグ（不具合）と言わずして何と言おうか。
Regarding such a strange “specification” of Microsoft Office Project Server 2007, why don’t you call it “bug”?

マイクロソフトのMicrosoft Office Project 2007というのは、なかなか優れたアプリケーションである（もちろん皮肉だ）。
Microsoft Office Project 2007 is an excellent project management application.
例えばあなたがあるプロジェクトのチームメンバーになっていて、以下のような「タスクＡ」を割り当てられていたとしよう。
For example, you are a member of a project and “Task-A” as follows is assigned to you.
2009/04/27 Baseline(標準) 4 hrs / Actual(実績) 0 hrs
2009/04/28 Baseline(標準) 4 hrs / Actual(実績) 0 hrs
あなたは本来「タスクＢ」の実績作業時間として入力すべき時間を、誤って「タスクＡ」の実績作業時間として入力し、「保存」てしまったとする。入力はProject Professional 2007からでも、Project Web Access 2007からでもよい。
But you happen to make a mistake. You input actual hours of “Task-B” into “Task-A” and save it. Input can be done through Project Professional 2007 or Project Web Access 2007. The results are the same.
ただし、まだ「提出」もしていないし、プロジェクト管理者による「承諾」「発行」もされていない。
You indeed saved the wrong actual hours but don’t submit them to project manager yet. So project manager, of course, doesn’t approve or publish them yet.
2009/04/27 Baseline(標準) 4 hrs / Actual(実績) 4 hrs
2009/04/28 Baseline(標準) 4 hrs / Actual(実績) 4 hrs
結果として当然のことながら「タスクＡ」の残存作業時間は0時間になる。
As a result, remaining hours of “Task-A” becomes 0 hours.
入力ミスに気付いたあなたは、「タスクＡ」の実績作業時間を２日間とも0時間にもどして「保存」する。まだ「提出」はしない。
After saving them, you notice you made a mistake. So you input 0 hours as actual hours for the two days of “Task-A” and save them.
すると、驚くべきことに「タスクＡ」は自動的に下記の状態になってしまう。
Now let’s watch carefully the results. “Task-A” automatically turns into a strange status as follows.
2009/04/27 Baseline(標準) 0 hrs / Actual(実績) 0 hrs
つまり、「タスクＡ」は2009/04/27(月)に設定された「マイルストーン」（＝標準作業時間が0時間で、作業期間が1日のタスク）に自動的に変わってしまうのだ。
This means that “Task-A” automatically turns into a “milestone”, i.e. a task with no baseline hours and 1 day duration. And the assignment of 2009/04/28 disappers.
プロジェクト管理者は「提出」を受けていないので、「タスクＡ」が自分の知らないところで「マイルストーン」に自動的に変わってしまっていることに、当然気付かない。
Project manager hasn’t got the “submission” of this automatic change yet. So the project manager doesn’t even notice this strange phenomenon yet. This means any “task” can turn into a “milestone” without Project manager’s approval.
マイクロソフトによれば、これがMicrosoft Project 2007の「仕様」だというのだ。
According Microsoft, this is the “specification” of Project 2007.
さて、プロジェクト管理者のあずかり知らないところで、チームメンバーが単に自分の実績作業時間の入力ミスを修正しただけで、任意のタスクが「マイルストーン」に自動的に変換されてしまう。
By the way, any “task” can change into a “milestone” simply because a team member tries to correct input mistake.
これはプロジェクト管理業務上、適切な動きと言えるだろうか。適切な動きは以下の通りのはずだ。
Can it be an appropriate workflow in a normal project management?
I think the appropriate project management workflow must be as follows.
つまり、チームメンバーが入力ミスに気付いて、「タスクＡ」の実績作業時間を0時間にもどして「保存」したら、「タスクＡ」は最初の状態、つまり、
If the team member notices his/her mistake in inputting actual hours of “Task-A”, corrects actual hours into 0 hours and saves them, then the “Task-A” must go back to the original status as follows.
2009/04/27 Baseline(標準) 4 hrs / Actual(実績) 0 hrs
2009/04/28 Baseline(標準) 4 hrs / Actual(実績) 0 hrs
こういう状態にもどるのが、適切な動きではないだろうか。
ところがMicrosoft Project 2007の「仕様」では上述のように、
Don’t you think this is the appropriate “specification” for a project management application? However, when you use Microsoft Project 2007, if you make a mistake as described above and correct it, then the task will automatically change into a “milestone” like this.
2009/04/27 Baseline(標準) 0 hrs / Actual(実績) 0 hrs
こういう具合に勝手に「マイルストーン」に変換されてしまうのだ。
これを「バグ」と言わずしてなんと言おう。
Why don’t you call this a “bug” instead of “specification”?
マイクロソフトProject 2007は素晴らしいプロジェクト管理アプリケーションである。
Microsoft Project 2007 is an excellent project management application.

雨だし。結局、土日２日連続ビッグエコーでフリータイム。
でも嫌いじゃない。誰にも邪魔されず、誰に気を遣うこともなく、いつでも好きな歌を歌える場所に、19時まで何時間いても二千円しかかからない。
何とかしてファルセットをちゃんと出るようにしたい。「雪の華」のサビの最高音を、なめらかな換声点で裏声で歌いたい。
それができるようになって何の意味があると問われれば、何の意味もないと答えるしかない。
歌があれば何とか生きていける。でも会社員としての仕事の苦痛の大きさと、歌う楽しみのささやかさは、全く釣り合わない。
というか、「楽しい」という言葉の意味を忘れてしまったような気がする。何だったっけ？「楽しい」って。