シブツカ

昔、ラジオを聴いていると、「シブツカ」という聞きなれない単語が耳に入ってきた。

「渋（い）塚」？

等とトンチンカンなことを考えていた。

渋い塚ではなく「私物化」。

本来多くの人が共有するものを、特定の個人が自己都合で（寡占的に）利用・運用する行為。

本来共有すべきものとして存在する以上、「私物化」が起こると周りに迷惑がかかる可能性は高い。しかし、「成果主義」の名の下に、「自分の仕事なんだからしょうがないじゃないか」と開き直って堂々と「私物化」をついついやりたくなってしまう。

そういえば「公衆電話」や「公衆便所」も少なくなっている。何でも「私物」になった今。子供の頃からその状態なら、「公衆」（publicity）の概念など吸収するべくもない。

某国の首相の反省コメントを聞いていて、そのようなことをふと感じた。

量は質に転化する？

今週は色々細かい作業をひたすらこなしていた。

• 他部署で作成した試験報告書のレビュー結果への回答のサポート
• 退職（業務委託終了）した人のPC返却
• ウイルス動態解析の打ち合わせ調整
• システム導入に関する文書レビュー依頼
• 他部門からの追加のデータ解析依頼
• 人事考課に関する上司との面談と資料準備
• 試験デザインに関する意見募集へのコメント
  

「作業」と言っても実は一筋縄でいかないものも多く、こうして眺めると「それなりによくこなしたもんだ」という感じである。

少し前には、例えば「・・・へのコメント」のような業務には時間をゆっくりかけて取り組んでいたが、今回は（予定が詰まっていたこともあり）30分で書きなぐった資料を返信してしまった。ただし、コメントの対象となった問題については、意見を求められてから断続的にでも考え続けていたので、書いた内容自体は必ずしも単純な「思いつき」ではない。

これは経験則だが、私が何か問題を解決する場合、考え付くのは「会社外」、しかも帰宅・出勤途中にぼーっと歩いている時が多い。だとすれば、「会社内」ではひたすら作業をこなしていけば、「仕事やった感」はずいぶん達成できる可能性は高いのかも。

スポーツでも「リズム・テンポ」の重要性がよく言われるが、リズムの良し悪しが有形無形でパフォーマンスに影響するというのは多分真実だと思う。

それにしても、問題解決のアイデアの多くが「会社外」で出てくるのだとすれば、これまでのような「デスクに縛り付ける」オフィスのあり方を見直すべき時が来ている（見直している企業もあるようだが）のではないか。

ま、うちの会社は「超保守的」なので、フリーアドレス制などに考えが及ぶことは100年経ってもないんだろうな。

とんだ失敗

今週は日曜日に、台風の中出勤の上、システムのデータ移行作業を実施･･･の予定だったが、移行するデータのサイズが想像以上に大きく、結局移行は完了しなかった。

しかも、作業は翌日の月曜日にわたり、連休の2・3日目がほぼ丸つぶれとなった。

結局データ移行は別の方にお願いすることに。

スミマセン。

ちなみに、振り替え休日取得を上司に相談した所、

「有給取れば？」

上司殿。お金を掴ませればそれでよいのか？

Tarone検定実施用プログラム作成

フリーソフトとして利用可能なR言語で作成した。既存の生存時間解析パッケージを基に、検定統計量やP値を算出する。

･･･といってもこれはR言語の勉強や趣味ではなく、「従属性のある打切り」の下でのTarone検定の挙動をシミュレートするのが最終目的である。

従って、次は2変量指数分布（しかも従属性のある）に従う乱数発生モジュールを作成する必要がある。しかも、2変量指数分布なる分布も1種類ではない模様。2変量分布の乱数発生自体も結構難しいのだが･･･。

人不足

今週は、システム導入プロジェクトの収束作業がメインだった。

開発委託先とスケジュールを詰めていくうち、どうにかゴールが見えた感じ。
仕様書等の文書作成とプログラムの操作を伴うタスクが別立てでスケジュールされているのが不満（文書→プログラムという流れがまだ理解できていない？）だが、社内の事情であまり瑣末なことにこだわってもいられない。

このプロジェクトに関する委託先内のリーダーは元来プログラマで、諸般の事情で「緊急登板」である。プログラマと違い、このような管理業務を担うスタッフは

• 育てるが難しい（時間がかかる）
• そもそも育てられる人がいない
• 必要なスキルが多種多様

･･･といった、本来「代えの利かない」スタッフなのだが、そのようなポジションに緊急で指名せざるを得ないのが辛い所である。

人不足なのねぇ。どこの会社も。

気分のよい会話：その理由

今日は職場で久々に少し気分のよくなる会話が耳に入った。

事の発端は、あるプロジェクトの打上げに私の上司（そのプロジェクトに関しては担当者？として対応）が呼ばれなかったことであった。

打上げは若手のプロジェクト担当が運営していたようで、これまでの経緯から、どうもこの上司を呼びづらい、あるいは呼びたくないという話になったようである。

この上司がプロジェクトチームを色々な意味で振り回していたのは確かである。とは言え、プロジェクトが一応の成功を見たのであれば、打上げの時は水に流してあげればよいのに、と私も側で思っていた。

ところが、プロジェクトマネージャーが直々にこの上司の下に来て、「あなたが来ないと俺の気分が悪い」と一言。最初はへそを曲げていた上司も「お前が気分悪いんならしょうがないな。」の返し。

単純だが気持ちのこもったよい会話。どうでもよい（しかし気分が悪くなりがちな）ひそひそ話やギョーカイ通をひけらかすいやーな会話が多く耳に飛び込む中で、久々に気分が良くなった。

しかし、なぜ気分が良くなったのだろうか？

これは単に、互いに気分が良くなることを最終目的とした会話で、「お互いもやもやをなくそうよ」という気持ちを一瞬で共有できたことが伝わったからではないだろうか？

そういえば私はそんな会話ができていない。うまく相手と共に少しでも気分良くなる方向の会話が。もちろん、職種柄どうしても小難しい話が多くなるが、そんな中でも「互いに気分が良くなる会話」を目指したいものだ。

これを踏まえると、前述のひそひそ話やギョーカイ話が不愉快な理由が浮かび上がる。それは、

• 手許の仕事に飽きたから、休憩代わりに･･･
• 何となく小難しい話を（これ見よがしに）して、物知りを演じる
• ギョーカイ通である所を見せる

といった、自己満足の領域を出ない会話だからであろう。

自分も相手も気分のよくなる会話。最近少し落ち込み気味だった私には一服の清涼剤となった（例えが古い）。

期待のし過ぎ？

今週は、私の携わるプロジェクトの全体ミーティングに出席した。

諸般の事情でやや進捗が遅れるとのこと。ベンチャー企業との協業なのだが、「やっぱり細かい所までは手が回らないのか？」と少しがっかり。

一方、私がリーダーを勤めるシステム導入プロジェクトは、これまた諸般の事情で「一部開発打切り」で収束に向かうことで合意。

開発は外部委託だったのだが、どうも期待のし過ぎだったのかもしれない。
お金をもらってプログラムを作っているのに、

• 気の利くコメントがほとんどない（気の利かないものは数多い）。
• 同じコードが複数のモジュールで存在。多分コピペ。
• （結合）テストケースが「ざる」状態。UATの方がテストケースが多いだなんて、あってもよいのだろうか？
• いわゆる「境界条件」の設定が甘い。「設計上想定していなかった」との説明だが、本来は最もデリケートな部分なので、不安ならば開発段階で確認すればよいのに。

･･･と問題多発。もちろん仕様の詰めの甘さは当方に問題があるにしても、「お金をもらってする仕事」ではない。

この件から学ぶべきことは、

• 「プログラムのシンタックスを記憶している」≠「ライブラリ・アプリケーションを開発できる」であることを知る。
• その点を理解した上で、ベンダを選定する。
  
• プロジェクト管理やテストケース設計など、プログラムのコーディングから離れた分野の技術も選定基準に含める。（ただし、自分たちにその技術がないと難しい。）

といった所か。でも、こんなことをしていたらベンダにシステム開発を依頼できないかも？