プロジェクトはパートナーシップ…

発注側がいて受注側がいて。あるいは営業部門がいて技術部門がいて。
こういう関係者の間で、「いっしょにがんばりましょう!」ってのが、得てしてプロジェクトの始まりの頃です。
で、だんだんきつくなっていくと、「いっしょに泥にまみれましょう!」と、なんとか前向きに持っていこうとするわけです。
さらにきつくなっても、「仲間じゃないか!」と、ややもすると80年代頃の青春ドラマ風味でなんとか乗り切ろうとします。
で、それで乗り切れれば、それはデスマでは無いわけで。
本当ならば強調しなければいけないヒトビトがいがみ合い、縄張り争いをはじめ…さらには、「それ、あいつらの仕事だろ。なんでそのために残業しなきゃいけないわけ?」という、ある意味ごもっともな文句が出てくるわけです。
そういう文句が上層部に到達するのは非常に高速なので、「以後、このプロジェクトで当部門の人員を残業させることは禁止する。残業させる場合は、その分の残業代を貴部門(あるいは貴社)に請求する。」「ウチのxx、このプロジェクトに専従状態なんだから、人件費全額、そっちで持てよな」などのオフィシャルレターが飛んだりします。
要するに「好きなだけ泥にまみれて赤字垂れ流せよ。オレはいやだけどな。」って言うことですな。
こうなると、もはやパートナーシップではなく奴隷船ですな。
ま、デスマの嵐の中では、こんなもんでしょ。

パートナーシップ:順風の時には二人乗りだが、嵐になると一人乗り。これもそんな程度の船。
(参考:A.ビアス『悪魔の辞典』)

ゴールを見せろ

“Big picture”を描いてそのアーキテクチャーがどうした…という話ではありません。
プロジェクトのゴール、マイルストーンのゴールの話です。
何を持って、プロジェクト完成とするのか。
何を持って、マイルストーン到達とするのか。
例えば元請けの担当者に「うーん、これじゃまだお客さんには…」といわれるような場面です。そこで「じゃぁどこをどう直して欲しいのですか?どうすれば検収上げてもらえるんですか?」と聞き返さなければいけないと。そして、ソレに対する明確な回答は無し…。
それを探せって、あんた、かくれんぼやってるんじゃないんですから…
デスマの終盤戦によく見られる光景ですが、開発側も結構消耗している状態で「ゴールが見えない」というのは、心理的に相当なマイナスです。
そして、そのゴールを見つけ、或いは作り、そこに向かって全力を投入させる-これが、デスマ終盤戦のマネージャーの大きな仕事の一つでしょう。
#この「作る」ってのがポイント。ゴールがなければ作ってしまえ。
#そうでもしないと、「賽の河原の石積み」プロジェクトが出来上がります。

大文字小文字ぐらい変換しようよ…

実際、とある商用サイトであった例です。
「半角英字大文字で入力してください」と。
全角を入力エラーが返却されるのは、まだ判らなくはありません(不満ですが…)。
で、ここで半角の英字小文字を入力したら、エラーが返却されたわけです。
さすがに腹が立ちまして。
「大文字じゃなきゃやだってのはオメェの都合だろ!」と。
その商用サイト、中が何で動いているのか知らないですが、大文字小文字チェックができるなら変換しろよ!と。
.NET Framework なら、String.ToUpper で。
VB.NET なら、StrConv([String], VbStrConv.Uppercase) で
それぞれ変換できるわけですし、そういうベンリな関数が無くても、たかだか 26×2 の二次元配列を作って変換してしまえばオシマイです(全角・半角も、この手で何とか変換できなくはない…)。
ま、イロイロ中でのご都合はあったのでしょうが、その中でのご都合でのツケを利用者に回されたような感じで、非常にイラつきました。
Microsoft Visual Studio International Pack 1.0 ベータ1を使うという手もアリ。ベータだけど。

報告書はプロジェクトを救いはしない

プロジェクトの遅れ具合、デスマ具合に従って、比例的に報告書などの管理書類が増大します。
遅延に立腹した上位層(顧客とか元請けとか上司とか…)の「どうなってんだ!ゴルァ!!」というお怒りがスタート地点である場合が殆どです。
こうして、月報が旬報になり、週報になり、日報になり、さらには時間・担当者単位のミクロ管理報告になっていきます。
なぜこういう報告書を求めるのか?
1)とにかく圧力をかけるため
2)…思い浮かばん…orz
…「問題点の早期発見と対処をより上位で行うため」という「大義名分」がつく場合もありますが、それなら文書でやるよりももっといい方法が幾らでもあります。
こういった報告書は何をもたらすのか?
1)管理工数の増大による更なる遅延
2)「作文」な報告書の山
多少なりとも経験のあるマネージャーは、こうして増大した類の報告書が結局「ロクに読まれはしない」ことを経験的に知っているので、イキオイ、「作文」になります。
そして、これらの「報告書」がたどる運命は…
1)ディスクの肥やし
2)裏紙として第二の人生を送る
3)機密保持によりシュレッター直行
4)丁寧にファイリングされ、キャビネットで朽ちて行く
と相場は決まっています。
だいたいが、報告書を山と書いた所でそれは「報告書」に過ぎず、デスマーチに陥っているプロジェクトを救いはしません。
プロジェクトを救う方法は極めてわずかであり、遅らせる方法は星の数ほどあるのです。

VBは「初心者向け」?

[ネタ元]
@IT 最も初心者向けの言語は「Visual Basic」――スクリプト復活へ
確かに、VB.NET, C#, C++, Java と並べた時に、「初めての方でも安心ですよー」と言ってオススメしやすいのは、VB.NETですし、VB.NETが目指している方向もその方向です。その辺りには、Paul Vick の Blog より “Is it time to replace Mort?” の記事でもうかがい知る事が出来ます。
しかし、VBが「初心者向け」か?と言われると、それは言葉としてどうか?と思います。持っている機能としては「初心者向け」どころではないほどパワフルですし、他の言語と比べても遜色はありません。
なので、VBは初心者向けか?と言われると、肯定的な意味の「初心者向け」ではありますが、否定的な意味では-デチューンされているとかやりたいことが出来ないとか-決して「初心者向け」ではありません。
VBが初心者向けだと言うのは、ホンダ スーパーカブが「初心者向け」というのと同じ意味で「初心者向け」でしょう。初めてバイクに乗る人でも簡単に運転できるが、その性能といい使い易さといい決して「初心者向け」というカテゴリーではなく、究極の実用バイクです。
そういうわけで、ネタ元の記事の本文はよく理解できたものの、表題が「如何なものであろうか」という感覚でした。

その場を離れて考えてみる

コードを書いていた時、設計していたときは「コレで良い!」と思っていたもの。
これを、その場を離れて考え直してみると、イロイロと問題が出てくるものです。
電車やバスの中、仕事をサボっての喫茶店の中(非推奨)、風呂の中、布団の中でふと考えてみると、ロジックの抜けや矛盾が明らかになる瞬間があったりします。
そういう瞬間を見逃してはイカンなぁ…と思うことしきりな今日この頃だったりします。

意味あるの?

出席した会議で途中で退席したくなるというのは、実によくある話です。その理由は様々ながら、究極的には「退屈」の一言に収斂されます。
なぜ退屈なのか?
・最初の5秒で結論が見える
 →配られた資料で全てが把握できる(特に「無意味だ」という事実が…)
・終わりが見えない
 →アジェンダが判らない
・内容が後ろ向き
 →単なる吊るし上げの儀式。「じゃぁこれからどうするの?」という話がない。
これらの会議は、ゴミ箱どころか放射性廃棄物とさえいいたくなります。なぜか?
・最初の5秒で結論が見える
 →→事前に資料を配れば良いだけ
・終わりが見えない
 →→アジェンダを配れ
・内容が後ろ向き
 →→他所でやれ。プロジェクトを終わらせることに対してなんら貢献しない。
とはいっても、そういった会議に動員され、退席するわけにも行かないというのが、いわゆる「大人の事情」というヤツだったりします。
#今日も今日とて、アジェンダ無しで「準備するものはありません」等と書かれた会議召集をメールを受け取って意識が遠ざかりました。
#準備する必要がないなら出席する必要も無いじゃん!
#アジェンダが無いから「なぜ準備する必要も無いのか」も判らないし…

テスト部門 vs 開発部門

まず最初に。テスト担当者のストレスとかは、判っている(つもり)です。特にマトモに動いていないモノであるときにはなおさらです。
「ったく、また落ちやがった!」とか、そういう手の悪態をつく羽目になり、「直ったっていってるけど、全然ダメじゃねぇかっ!」とか「今度はデグレかよ!」とか。そういう類の事になるわけです。
人間である以上、そういう感情は生まれてしまうものです。
でもって、その感情が何処へ向かうか?開発側に向かうのは至極ごもっとも。
で、その感情が抑えきれずに、バグ票に滲み出たり、或いはあからさまになったりするわけです。
さて、そのバグ票。当然開発側に回されるわけです。
テスト側がそういう状態なら、開発側も推して知るべし。死屍累々の修羅の巷となっているのが普通の光景です。
そういう状況でそういうバグ票を見ると、どういうことになるのか。
ただでさえ苛立って殺気立っているところに、文字通りの「燃料投下」となる場合が往々にしてあります。
「何だと、コノヤロー!人の気もしらねぇでっ!!」
と一触即発。口もききたくないどころか、マヂ切レ寸前状態となってしまいます。
そこで対応を間違えると、チームは空中分解。あるべき「仕様としてどちらが正しい」的な議論ではなく、感情的な「あいつの言うことは一切やらん!」というコトになってしまいます。
確かに、テスト部門と開発部門の間では、ある程度の健全な対抗意識-「あっと言わせてやる」的な-は必要かもしれません。ですが、このような先鋭化した感情的な対抗意識は、百害あって一利なし。
これを防ぐには…難しいんですよね。バグ票を気をつけて書けと言っても、書くほうも人間ですし、気をつけすぎても「慇懃無礼」状態になって、これまた燃料投下。
やはり、普段からテスト部門と開発部門で、コミュニケーションを十分に取っておくのが、良いのではないかと思います。バグ票に「カチン」ときても、普段からそういうコミュニケーションを取っていれば、そんなにひどい事にならないと思います。
#とは言っても、デスマーチの猛威の前にはそれも「緩衝材」に過ぎないわけですが…

敗戦処理の評価は、やっぱり低い

と、いうプロ野球関係のニュースが出ていたわけです。
[Yahoo! News]
小宮山やる気なし…“敗戦処理”の評価低すぎ猛反発
この業界でも似たようなもので、大炎上死屍累々のデスマーチプロジェクトを、なんとかかんとか「この程度で食い止めた」というのもあるわけです。野球と違って「9回で終わり」「1-0で負けても30-0で負けても『一敗』」というのは無いので、際限なく燃え広がって跡にはぺんぺん草一つ生えないという事態もありうるわけですから。
で、こういう「敗戦処理」「火消し」はどういうことになるのか。
ありがちなオチとしては、「居たプロジェクト全部赤字だから、評価無しね」とか、「全社で赤字なんだからしょうがねぇだろ」とか。大体そんな感じです。
ま、「最終結果」としての「数字」しか見ないと、得てしてこういう結果になりますな。
これでどうやる気を出せと?