本年最後の週は…

今週は年の瀬ということもあり、いわゆる通常業務や飛び込み的作業は発生しなかった。
そのため、（再）来年以降の準備（のための準備？）を始める時間を取ることができた。

オフィス全体が年末モードで、どことなく平和ムード漂う1週間であった。

リソースマネージメント？

今週は来年度の予算やらスケジュールやら、リソース調整に関する作業が多かった。

やってみて分かったことは

• 2008年末～2009年6月に4プロジェクトの担当業務が重なる
• 2010年9月には過密スケジュールを強いられる
• これらの事実から、2008年中に余程準備を入念にしておかないと業務が破綻するリスクが高いことが予想できる

ということである。んー、今から気が重い・・・。

ファイルはうまく保存して

今週は

• 自分の担当プロジェクトの紹介（所属グループ向け）の準備
• 旧要員の作成したある報告書の探索
• 逐次集計用のデータ取り込みプログラム作成
  

が主な業務であった。

「…報告書の探索」は、（外付け）ハードディスクから電子ファイルを検索するだけなのだが、その保存状況が

• 同じものがいくつも保存
• フォルダの構成も検索の手がかりにならない、というよりむしろ妨害
• ファイルサイズが計４５GBなので全て検索するなど非現実的

ということで、ファイルの更新日付等外部情報を用いて検索範囲を絞り込み、とりあえず一段落を付けることができた。

教訓：同じものを何度も保存しない。スナップショットをどうしても保存したければ、せめて圧縮する等の工夫は必要。また、フォルダ名は考えて命名する。

データにエラー？

Multi-stateモデル解析用のRプログラムでは、個々の状態について

1. その状態に推移した時間
2. その状態から別の状態に移った時間

を引数に取り、1.<2. となることを事前要件としている。
一方、（自分で導出したので怪しい限りだが）ID

• 3905
• 4999
• 6490

については1.=2.となっている。

追跡中止・治療中止の管理が甘いのがこのデータの欠点で、Time-to-event解析にとっては結構痛いエラーなのだが・・・

Multi-stateモデル入門メモ

Multi-stateモデルとは、いくつかの「状態」（ある疾患への罹患、機械の動作状況等）とある状態から別の状態への推移時間に対するモデル化の総称である。

状態の推移を問題にするのだから、ある状態とそこから推移した後のある状態の間に何らかのモデルを仮定するのは自然な発想である。Time-to-eventデータの場合はCox回帰モデルが最も標準的であろう。

その仮定の置き方は…

• 個々の推移パスに対してハザード関数のモデル化を目指す「Markov stratified hazards」モデル
• ある状態への推移が複数想定される場合、各推移のハザードが比例関係にあると仮定する「Markov proportional hazards」
• ある状態への推移のハザードが、その直前の状態への推移時間に（見方を変えると「直前の状態での滞在時間」）に依存すると仮定する「State arrival extended Markov 」モデル

の3種類が主な所のようである。

引継ぎに追われ…

今週の前半は、年明けに発生する非定型な解析業務の準備を進めた。

集計内容自身は易しいものだが、逐次対応が求められるだけに、データ取り込み処理がネックになると判断。そこで、プログラムに漸く取り掛かることができる所まで来たのだが…。

マネージャーさんから、今月末で退職する方の担当プロジェクト業務をサポートするように依頼されたのだ。

「来週（次週）1週間位でやっといて」

とのことだが、どう優先順位を考えればよいのか。急に依頼が来て困っている所である。

なぜか浮つく1週間

今週は、年明けに「データ入手→すぐグラフ作成」というアクロバット的作業の準備について、何とか一区切り付けることができた。

なかなかグラフの内容に対する要求が細かく、当初はうまくいくか不安はあったが、年内に解決できてまずは一安心である。

ただし、「データの入手→解析用に変換」のプロセスはまだ未解決な部分を残している。

この作業は品質をあまり問わないものなので、与えられた時間は少ないが、できれば色々実験的要素を盛り込んでみたい。

計画性を養う方法は？

今週は、来年・再来年のスケジュール設定に時間を割いた。

この手の作業は元々苦手であったのだが、業務の仕組として組み込まれたのであれば、得手不得手は言っていられない。さらに、再来年前半（GW前後）にかなり業務が立て込むことが予想されるので、事前にスケジュールを設定しておくことはリスク管理行動としても有用だろう。

実際には、主な目的はスケジュール設定ではなくリソース管理で、FTEを予め予想しておきたいとの要望への対応であった。もちろん、実際に業務が走り出せばそのような見積りは吹っ飛んでしまう可能性が高いことは覚悟しておかないといけないであろう。

これらの作業に時間を割いてみて残った感想は：

1. あくまでも「予定は未定」。最後は自分の与り知らない事情？に流されることを前提としておいた方が（少なくとも精神的には）無難。
2. 1.の考えに立てば、スケジュールやリソース（FTE）を「正確に見積る」努力は程々にした方がよい。どうしても「正確に見積」がしたければ、実際に業務を行う際に作業時間を測定し、精度を上げるより他ない。ただし、これも結局は「担当業務の内容次第」なので、近い将来の別の担当業務にこの記録を活用できるかどうかは不明確である。
3. 最も重要なことは、スケジュールやFTEの定量的な見積の精度を云々することではなく、「スケジュールが過密になる」「時間のかかる作業が必要となる」という事実をまずは自分の目で見て、予め受け入れておくということである。そうすることで、根拠を以って必要な作業やその優先順位を決めることができる。

といった所である。

既存の統計手法で解析

問題となっているMulti-stateモデルのデータを、

• 関心のあるイベントに対するCox回帰モデル
• 　　　　　　　　〃　　　　　　　　Tarone検定

を用いて解析した。これらの手法は背景にある仮定が同じで、現在はごく標準的に使用されている。

現在主張しようとしているのは、「これらの手法では打切り（関心のあるイベントが観測されないうちに追跡が終了する）の扱いに問題があるのでは？」ということである。いわば上記の解析はその主張のための「比較・対照」の役割である。

Multi-stateモデルについてはRパッケージが存在するようなのだが、

• モデルの理解（背景の仮定、解釈、…）
• Rパッケージでの解析に必要なデータの準備

という課題を解決する必要がある。

データと全く異なる予測値？‐（非線形）モデルの当てはめ

モデルの当てはめに対する私の考えは間違っていたのか？

先日、ある共同プロジェクトの提携先が実施した、ウイルス動態に対する（非線形）モデルの当てはまりを評価するために、パラメータ推定値を基に予測値を算出した。

パラメータ推定値はデータから算出されたものなのだから、予測値はデータとはさほど乖離しないはずだと考えていたし、仮にそうでなければそれは「モデルが当てはまっていない」、つまり当てはめようとしていたモデルの選び方に問題があった可能性が高い。しかし…。

結果を見ると、データとは全般的に全く乖離しており、解釈に困るものであった。

もちろん、

• 予測値の算出ミス
• 解析パッケージの影響
  
• モデルの当てはまりを「データ全体」ではなく「区分的に」最適になるようにパラメータを推定している

等の可能性は検討の余地はあるのだが、乖離の内容が「企業にとって都合のよい」方向への乖離であることがなお不安を煽る。

モデルへの当てはめはあくまでも「データの説明・次元縮約」が目的であって、「ユーザー側の都合のよい結論を導く」手段ではない。そう考えていたのだが…。

しばし平穏な日々

今週は、担当プロジェクトで必要な技術文書のレビュー用ドラフトを作成し、レビューに回すことができた。

もっともこの文書は、相当前から作成を開始していたこととプロジェクトの遅延が重なった結果、何とかスケジュールどおりに作業できたというもの。冷や汗ものであった。

その他はウイルス動態解析のプログラム作成など、比較的非ルーティーン的業務に時間を割くことができた。

いつまで続くのか…。

打合せの要否

今週はいくつかの会議に参加した以外は、

• ウイルス動態解析プログラム
• 種々の文書作成

に勤しんでいた。

会議は

1. 所属する部・グループの会議
2. 個々の担当プロジェクトでのデータ収集に関する打合せ

といった内容である。

1.については、組織上の問題で「全員（部・グループメンバーが）集まる場」がないということで、「最初の顔合わせ」といった意味合いの強い会議であった。一方、2.については単純に業務上の打合せで、具体的な方針の合意をする目的の打合せである。

1.のような会議の要否判断はなかなか難しい。「目的次第」と言われればそれまでなのだが、「目的達成によるメリット」と「会議に時間を費やすデメリット」を天秤にかけていることも忘れるべきではない、と思うのだが。

流れるような中身のない会議プレゼン

会社の会議の主な目的といえば、

1. プロジェクト進捗報告など、事実を大人数で共有するための会議
2. 具体的な問題に対する解決策を導き出すための会議
3. ブレーンストーミング等、アイデアをできる限り数多くアウトプットするための会議

といった所である。従って、「会議で求められるプレゼン」といえば、

1. の場合は重要な事実関係（+今後の課題等）を告知すればよいし、
2. の場合は「解決したい問題」を明らかにしたり、解決策の候補とその裏づけを説明し、
3. の場合は会議の導入で背景情報などのインプットを知らせればよい。

しかし、どれかといえば1.に分類される会議で

• 重要な事実は最後の数分の内容だけ
• 後は演者自身の経験談や過去の歴史的経緯の紹介でプレゼンの必然性を疑わせる内容

というプレゼンを聞かされることになった。

マネージャーさんから指示があってのプレゼンなのかもしれないが、「言われたから何か発表しておけばよい」という問題ではなく、

• 会議の目的をよく考える
• できればプレゼンをしないように努め、するにしても時間を短くする工夫を施す

といった配慮が必要ではなかったか。

業務に費やす時間を敢えて（成果に直接結び付かない）会議に割く以上、どういう形にせよ「やっといてよかった」会議にするよう、プレゼンに工夫を加えるべきであろう。

11月突入

今週は

1. 外部委託した統計解析業務の成果物の受入対応
2. ウイルス動態解析プログラム作成
3. その他雑用

といった業務内容の構成であった。

1.についてはスケジュール対応が必要であったが、後はさほど急ぎでない業務なのでまったりと？実施。

また、金曜日はある事情で休暇を取得。

月末ゆえの…

今週は、行政当局へ提出する資料の最終化のサポートに追われた。

複数似たような資料を提出することになっており、記載の細かい点の修正作業に時間を割くことに。

また、ある臨床試験のデータ収集方法について相談をいくつか受けた。基本的には「必要な統計解析ができれば収集方法は自由」であり、後はやりやすい方法を採用してくれればよいのだが。

比較的地味だが重要な業務の多い1週間だった。

ルールを決めるためのルール

何のためにルールを決めるか？

ルールの必要とされる状況次第でその答は様々であろう。仕事の場合は

• 必要な成果・成績を確実に（しかも効率的に）出すため
• 規制対応

・・・といった所だろうか。

ただ、近年ルールが真に「公明正大に」決められたという話は聞かない。どちらかと言えば少数の人々の嗜好や国策等、つまりは「誰かの都合」で決まっているように思う。

もちろん「関連する人々全てがハッピーになる」ルール等存在しないわけで、「三方一両損」的な最適化が本来は目指すべき所であろう。そのためには、

• 皆が納得するような、ルールを決める目的を決める。
• 現状のプラクティスを把握し、上記の目的に沿って良い点・悪い点を客観的に把握する。
• 現状のプラクティスの悪い点を修正するための現実的かつ有効な対応策を定める。
• ルール案を「ルール案を定めた人」以外に審査してもらい、そこで出た意見には必ず回答をフィードバックし、合意を得るよう努める。

といった手順が必要であろう。

ところが、時折見聞きする「ルール決め」では、

• そもそもルールを決める手順そのものを定めない。
• ルールを決める目的のステートメントがない、あるいは曖昧な説明のみ。
• ごく少数の人物が「自分の基準」のみで現状のプラクティスを評価する。このため、「三方一両損」ではなく「一方三両損」になる。
• 対応策が現状のプラクティスとさほど変わらないので、問題解決につながらない。
• 意見を募集しない、あるいは募集はするものの、都合の悪い意見は無視する。

といった行為が繰り返されている。

この状態を改善するためには、ルール決めのリーダーを（職制等に関係なく）明確に指名し、

• リーダーがルールを決める目的を明確に宣言し、手順の概略を定める。
• 誰もが「俺がルールブック」的思想に陥る可能性があることを踏まえ、できるだけ多人数でチームを召集する。
• 意見を述べる手順・様式をチーム側で提供する。また、出された意見はチーム全員が目を通し、チームで合意できる形でルール策定に反映する。
  

という準備が必要だと思うのだが。

雑務が多めな1週間

今週は業務用ソフトウェアに関連する調整業に何故か多く時間を割く羽目に。

ライセンス関連の資料（例：どのサブパッケージの使用契約を結んでいるか？）を調査したり、インストールの支援をしたり。

通常ならば何でもない作業だが、引越の影響で資料が散逸気味に。こういうことがあるので、IT関連の資料は一括管理（しかも自分たちの部署とは別の離れた所で）した方がいいと思うのだが、管理する立場にない人にはわからないんだろうなぁ。

まだゴタゴタなまま

環境が変わって2週目、今週は新組織のキックオフの打ち合わせが催された。・・・と言ってもライン長が少々プレゼンしただけで終了。

また、製品の開発プロジェクト実行の新しい仕組みの説明があった。統計担当としても、業務計画やリソース管理等に色々工夫が必要になりそうだと感じた。

環境や仕事の仕組み等、色々変わって大変な部分もあるとは思うが、やったことのない事に取り組むのは1つの成長のきっかけになるのではないか。

新たな環境で

今週は新たな環境での仕事始めとなった。

…といっても転職したのではなく、会社そのものがある変化を見せ、それに伴い私（も含めた大奥の社員）の仕事環境もがらりと変わったのだ。

オフィス内のフロア、デスク、上司・・・。何もかも大変化。

何かと不安はあるけど、せっかく気分転換のきっかけを大枚叩いて与えてくれたのだから、新鮮な気持ちで仕事に励む・・・ことができるとよいのだが。

デ、データが・・・

今日は1日中、「日常業務（「Run the business.」）」ではなく統計の研究作業を行った。

もちろん「仕事が嫌になった」訳でもなく、また「やる仕事がない」訳でもない。

予定していた作業は、

・研究課題設定の根拠を明確にするため、問題のデータを探索的に解析してみる
・必要に応じシミュレーションも実施
・結果を記録

といった内容、だったのだが…。

以前PCが故障したため、作成したはずのデータセットが丸々なくなっていた。

結局今日はデータセット作成計画の立案どまり。

ああ、予定とぜんぜん違う…。

外の空気

金曜日に（会社の大変化で本当はそれどころではなかったのだが）福岡でのバイオ統計関連の学会に参加した。

私の恩師が中心となっていることもあり参加したのだが、何より久々の学会、というか久々の出張で外の空気を吸うことができたのが何よりだった。

懇親会や裏？懇親会で同業他社の人たちと色々話をしたが、何よりよかったのが「その人でなければ聞くことのできない話」を聞くことができたことであった。

「（ひょっとすると話すとまずい）社内の話」や「（色々異論があるかもしれない）自分の考え」が話題の中心となることが多く、話す側は結構腹が据わっていなければならない。話の詳細な内容はともかく、その腹の据わり具合には感心するばかりである。

それに対して「その人でなくとも聞くことのできる話」や「有名人の話の受け売り話」の何と面白くないおことか。確かに話しても支障はないし異論も出ないが、何の感動もない。

それで満足な人もいるのだから仕方のないことだが、願わくばそのような「面白くない話」の聞き手が御免被りたい。

上半期終了

今週は2007年上半期最後の週であった。

システム導入の業務やら引越準備やら、とにかくどたばたしていた。しかも月曜日は休日、金曜日からは学会で福岡に出張することもあり、持ち時間が3日しかなかったために、尚のこと慌しい週であった。

いずれにしても10月からは心機一転で仕事に励みたい。

仮住まい

今週は、仮の引越先フロアで業務に従事した。

本引越？が控えているので、できる限り荷解きはしない方針を採った。従ってはさみやホッチキスなど、ちょっとしたものも使うことができない状況だった。

もっとも、今週は

• 統計（マクロ）ライブラリの受け入れテスト
• 製品開発プロジェクトの共同開発会議への出席（情報共有が主目的）

等、正直言って単調な作業が続いたため、あまり不便は感じなかった。

周りが引越作業でどたばたしていたことと座席配置を除けば、よい気分転換になった。

仮引越？

今週はオフィスのフロア間の引越作業に多くの時間を割いた。

しかも、実際の引越は10月1日で、その前にビルの工事の都合で、私の所属先＋αの部署だけは、その期日前に暫定的に別フロアに追いやられることに。

今回は

1. 何より早めに作業を開始したこと
2. 更に、かなり前から（多分偶然だとは思うが）倉庫に送るべき資料は梱包していたこと
3. 結婚時の引越で「引越（整理整頓）とは捨てることと見つけたり」の精神を学習済で、しばらく閲覧していない文書は基本的に「捨て」と決めたこと

等の要因があり、あまりストレスを感じることなく作業を終えることができた。

敢えて更なる改善策があるとすれば、

1. 日頃から「いらないものは捨てる」ことを実践する。
2. 「資料を自分で持たない」方策を探る。
3. 本当に重要な紙の資料はスキャナで電子化（これは部分的に実践済）

といったところか。

もっとも、「本当に重要な紙の資料」なんて、なかなかお目にかかることはできないんだけど。

Tarone検定の第1種の過誤率：続き

Tarone検定の第1種の過誤率についての続報。

検討対象と相関のある終末的イベント（「死亡」等）を打切りと扱う場合について、終末的イベントのハザードが

1. 群間で均一な場合
2. 用量依存的に減少している場合
3. 用量依存的に増加している場合（これが懸念される状態）

の各パターンの場合について、シミュレーションでTarone検定の第1種の過誤率を推定した。

その結果、第1種の過誤率はそれなりに名義上の値を維持していることが示唆された。これは想定していた仮説と異なる結果である。

なぜそのような結果が出たのか？考えうる原因は・・・

1. 仮説が間違っている。
2. シミュレーションには自作のGumbelの2変量指数分布乱数を使用したのだが、これが正しく機能（本当にGumbelの・・・分布に従っているのか？）していない。さらに、主要なイベントと終末的イベントの相関が結果として低くなり、本来評価したい状況＝2つのイベントの相関が（ある程度）強い状況になっていない。
3. ハザードの設定に問題がある（ハザードが低ければ、そもそも有意差が検出される可能性が低い）。

ただし、現実の臨床試験データとあまりに乖離した設定もできないので、3.は原因としては考えないことにしたい。また、1.については、一般的には「統計モデルを誤指定した場合にも第1種の過誤率が高くなる」ことが知られており、このシミュレーションの結果だけでは1.の結論の正しさは判断できない。

とりあえずシミュレーション計画の見直しか・・・。

「淡々とやる」ことの重要さ

私が会社に入って2年目ほど経った時、（当時の私としては）比較的大きな仕事を任されることとなった。

それは他部署の人たちにも（実は他社にも）関わる仕事で、何とか準備はしてみたものの、緊張半分浮かれ？半分といった状況であったと思う。そんな私に先輩の一言。

「淡々とやれよ。」

当時の私にはあまり意味が理解できなかったが、その後、事ある毎にこの言葉を自分に言い聞かせてきた。

淡々と事態・目標を把握する。
淡々と目標への道程を定める。
淡々と決め事に従って行動する。

外部の状況や他人の目は関係なく、あくまでやるべきことを真摯にやる。

変に浮かれるでなく、かといって訳知り顔でしらける訳でもなく。そこにあるのは

• やるべきこと
• そこに至るプロセス
• 行動

だけである。最も重要なのは「やるべきこと」を正確に見定めることだが、それは

• 最終的にどのような状況になることを皆が（そして自分も）望んでいるのか？

という観点に立たないと、ただの「自己満足」に陥ってしまう。

周りの様子を見ていて、この「自己満足」で完結させてしまっている話が多い感じる今日この頃。

束の間の安穏

今週は、色々な懸念事項が解決してきたこともあって業務量は少なく、本業である統計関連の調査や検討に時間を割くことができた。
10月にある会社イベントがあるので、「嵐の前の束の間の安息期間」といった所か。でも、こんな時にどれだけ「仕込み」をしておくかが重要なのかも。これは、結婚を機に料理をするようになって、理屈でなく学んだことである。

引越は人（私）を謙虚にする？

今週は、システム導入に必要な文書の修正手続きが主な業務で、それ以外は雑多な作業だらけであった。

この修正手続きについては、文書作成そのものはベンダに依頼しているのだが、修正案は全て私が作成した。何のための外部委託だったのか？外部委託の方法論を検討する時期に来ているように思う。


社内の事情で、近く社内で引越をすることになっている。

私も就職以来、社内・社外（プライベート）で何度か引越を経験しているが、その度に自己嫌悪に陥る。

何で日頃から片付をちゃんとやらないのか？なぜ持ち物管理を「モジュール化」して、何時運搬してもよいようにしておけないのか？要らないものはその都度捨てないのか？

でも、自己嫌悪はつらいが引越すると身の回りはすっきりして気分が変わるのも確かである。

「定期的に仮想引越」なるイベントを定義して、常に整理整頓を心がけさせるより他ないのだろうか？

でもやっぱりちょっと気が重いな・・・。

想像力

今週は休み明けで、リハビリ気分？で気が付けば週末、という感じだった。

文書の署名をお願いしたりちょっとした打ち合わせをしたり、比較的細かい作業が多く、リハビリにはちょうどよい塩梅だったかと。


今週一通のメールを受信。内容は「あるミニ・プロジェクトが見送り（中止）になった」というものなのだが、気になったのはその中止理由に言及していないことであった。送り主はプロジェクトマネージャの部下。

数日後、追加でその理由をまたメールで連絡。その理由は「上位プロジェクトの計画が変更となり、ミニ・プロジェクトの実施が不要になったから。」というものであった。

このメールを読んで色々なことが頭を駆け巡った。

1. 一連の作業内容は「やっつけ仕事」と言われても仕方のないものだが、連絡内容の重要性を分かっているのか？
   
2. よくよく考えると、2報目のメールは重要な情報を何も伝えていない。重要なのは「上位プロジェクトの計画変更理由」の筈なのだが、その説明は？

2.については後日調査して理由は把握したのだが、この「調査する時間」は私にとっては無駄な時間なのである。メールで連絡すれば2、3行で伝わる内容なのに。

1.については、部下君としてもマネージャ殿の言うとおりにメールを送信したまでのことで、深く考えなければ大した問題ではないのかもしれないが。

入社したての新人君ならばともかく、少しは経験があるのならば、

• 連絡内容はどれ程重要なのか？
  
• 自分が伝えるべき情報は何か？
• 連絡先の知識をどこまで仮定するか？

といった「プラスアルファ」の想像力を働かせるようになってほしいものだ。

しかし、見送りとなったミニ・プロジェクトの準備と称して、私もいくばくかの時間を割いたのは事実である。しかし、マネージャ殿の行動は、「ミニ・プロジェクトの見送りは大して重要ではない」という考えを反映しているように思われる。

ということは、私の割いた時間も「大して重要ではない」ってこと？

・・・とは考えたくないが、マネージャ殿にもプロジェクトチーム全体に対する想像力がもっとあればなぁ。

Tarone検定の第1種の過誤率：続き

Rでのシミュレーションにより、Tarone検定のサイズ（第1種の過誤率）をモンテカルロシミュレーションで推定した結果、名義上の値（有意水準、片側検定で2.5%）をやや上回る値を示すことが示唆されたのは説明済みである。

そこで、環境を変え、会社のSASを使用して同様のシミュレーション計画により第1種の過誤率を推定した結果、やはり名義上の値をやや上回る結果が示唆された。

気になるのは、その「上回り具合」が

• Rの場合：2.5%→5.5%
• SASの場合：2.5%→3.5%

と微妙に異なるところである。（指数分布）乱数の発生アルゴリズムが異なっている等の差異があるので、この微妙な違いの原因について定かなことは分からない。

現時点で言えることは

• Tarone検定は（打切りの影響にもよるだろうが）元々第1種の過誤率を正しく制御できない可能性がある。
• シミュレーションだけでは、上記事項の「可能性（リスク）」の示唆どまりであって、数学的な評価（第1種の過誤率についてきれいな不等式が証明できればベスト）をするのが望ましい。既存の研究成果も調査が必要。

といった所であろう。

研究の主題からどんどん外れていく…。

Tarone検定のサイズ（第1種の過誤率）を推定しようとした所…

研究テーマである「準競合リスク（Semicompeting Risks）存在下での傾向性検定」は、

• 関心のあるイベント（四肢切断）発現までの時間について解析する際、そのイベントと関連のありそうなイベント（死亡、原因は不問）を「打切り」と扱うと、Tarone検定で仮定しているモデルに合致しない
• このような場合、第1種の過誤率が名義上の値（有意水準）を上回る可能性がある
• 従って、データの性質を適切に考慮したモデルに基づく検定統計量が必要

・・・という問題提起から来たものである。

そこで、（打切りのある）生存時間データに対する傾向性検定として有名なTarone検定に対して、モンテカルロシミュレーションを使用した第1種の過誤率の推定を試みた。

準競合リスクデータを、Gumbelの2変量指数分布に従うと思しき乱数（この話も後日述べてみたい）を発生させ、さらに打切り時間を一様乱数でシミュレートし、第1種の過誤率を推定した結果、名義上の値（片側検定だったので2.5％）を上回る5％強の値を軒並み示した。

「とりあえず第1関門クリア」…と思いきや、2種類のイベントが独立である場合にも5％強の第1種の過誤率を示した。

あれっ？

これはTarone検定の性能に問題があるってことなんだろうか？あるいは、

• Tarone検定を実装した自作のRプログラムのバグ（テキストで答え合わせはしたのだが・・・）？
• シミュレーションデザインに問題？
• 第1種の過誤率の推定アルゴリズムが問題（カウントと単純な割り算だけだが・・・）？

といった点に問題があるのだろうか？

Tarone検定が研究の主題ではないものの、研究テーマの導入部分に拘る問題なので、会社のSAS（Tarone検定が実装済）で試してみたい。

変な問題を見つけてしまったものだ。Tarone検定があまりにマイナーな手法なので、まじめに評価した人がいなかったんだろう。

屋台が無くなるその前に

今週は夏期休暇で実家（福岡）に帰省した。

ということで仕事の話は一切ないのだが、ローカル局のニュースで取り上げられた、博多の屋台の話題が気になった。

この話は数年前から耳にしていたが、要は

• 都市景観上（屋台が邪魔、衛生上問題、などのクレームが発端）の理由で、福岡市は屋台を廃止したい
• 現在屋台を生業としている人々については一代限りで営業を許可
• 一方で、観光資源として貴重であるとの意見もある
  

ということのようだ。

もちろんまだ知らない背景情報もあると思うが、この話で最も疑問なのが

「福岡市はいったい何の問題を解決したいのか？」

という点である。

「道をふさいで邪魔」「衛生上問題」というクレームは確かに考えうる範囲の内容だが、

• 屋台を廃止して最終的に今より改善する点は何か？
• 屋台を廃止せずに事態を改善する方策はないのか？

といった点が不明確である。また、「観光資源として貴重」という意見も重要で、

• 屋台を廃止することによる（観光資源の損失の）デメリットは何か？

という点は考慮すべきであろう。

もちろん、福岡市も何か考えがあっての施策であろうが、やはり最初にグランドデザインを提示すべきであろう。メリット論・デメリット論がどちらも棄却が困難である以上、各論を議論しても結論はなかなか出ない。「市の方向性」とか「文化の維持管理」という水準の問題であり、安易なアクションは考え物だと思う。

…ということで、屋台が無くなる前に「焼きラーメン」でも食べに行かないと。

…だけではなく、夏休み前なので四半期報も

今週は水曜日に新規サーバの運用開始手続きを行った。

1年半の長きにわたり作業をしてきた結果がようやく結実して、やれやれという感じだった。この秋に会社の合併を控えており、このサーバもどうなるかはわからないが、この仕事を通して色々と物事を考える機会ができたのが何よりであった。協力してくれた方々にはただただ感謝である。

さて、このブログを結婚を機に書き始めて約3ヶ月。これまで「会社第一」（というか他に考えることがなかっただけの話だが）だったのが、それ以外の「家庭」という軸ができたのが大きかった。これまでと違い、家が「雨露をしのぐ」だけでなく「落ち着く」場所となったのだ。

転寝する妻を横目に落ち着いて自分に時間を投資する。何とも言いがたい貴重な時間である。

仲良し集団は苦手

ようやく完了した新システムへのデータ移行（と言ってもファイルコピーだけだけど）のフォローアップ作業から仕事はスタートした。

また、本業では、他社との共同プロジェクトの打ち合わせに出席。そのような会議は久々なのでやや緊張した。


今週最大の話題は、何はともあれ衝撃的な選挙結果であろう。

その原因の一つと言われているのが、「仲良し集団」と揶揄されることもある「チームABE」。もちろん色々考えての任命であったはずなのだが、まさかあそこまでお騒がせになるとは。

さすがにその人の頭の中まではのぞくことはできないのだから、これは「（人材登用という）ばくちに負けた」といってしまえば簡単だが、あれだけ連続すれば「ばくちに負けた」レベルの話ではない。

それに加え、形振り構わない強行採決の連発。誰か止められなかったのだろうか？それとも、「仲良し」だから何も言うことはできなかったのか？

緊張感の薄い「馴れ合い所帯」の末路を見た感じだった。

シブツカ

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

「渋（い）塚」？

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

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

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

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

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

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

量は質に転化する？

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

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

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

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

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

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

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

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

とんだ失敗

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

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

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

スミマセン。

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

「有給取れば？」

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

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

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

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

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

人不足

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

期待のし過ぎ？

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

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

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

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

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

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

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

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

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

「経営の現状と課題」（？）の話を聞いて

今週は、火曜日に導入予定のシステムについて部署内で説明会を催した。
ある意味一区切りとなり、少し安心。

木曜日には営業部門のトップから表題（タイトルは失念）の説明があったので出席。

実は、私の会社ではこの秋にある会社と合併することになっていて、この説明会も本来の開催時期をずらして催したとのこと。

内容はありきたりだったのだが、意図は（話せる限りの）事実を伝え、「もやもや」感を何とかしたいという点にあったように思った。

自分がリーダーの立場になったとして、この配慮に到達できるかどうか心配になった。

空腹は最高のスパイス

今週は、火曜日から木曜日まで出張に出かけた。通常業務はほとんどはかどらず。

出張と言っても、実際はある作業への立会いが私の主たるミッションで、残りは肉体作業のお手伝い、のはずだったのだが･･･。

現地スタッフの方々が手を回してくれたおかげで、実際には肉体作業のお手伝いはほとんど無し。朝9:30から18:00近くまで「ひたすら待つ」だけ。

最後にちょっとした整理作業があったのだが、出席者は皆待たされた鬱憤を晴らすべく、その（大して量も多くない）作業を奪い合う始末に。

仕事を奪い合う？

日常社内ではまずお目にかかることのできない光景であった。

いつまでもあると思うな親と金と仕事。

たまには「仕事がどうしてもできない」という、一種の「飢え」の状況を作ってみると、自分の仕事も他人の仕事も大事に感じるようになるのではないだろうか？

所詮は数字遊びなんだけど

今週は細かい打ち合わせや文案のレビューの仕事が入れ替わり立ち代り入ってきた。

それぞれの仕事は本来もっとじっくり時間をかけたい仕事だが、やはり「数は力」で、うまく捌いて（手を抜いて？）いくことが全体の仕事の質も上げることになるのでは、と思う。

その中の1つに、ある医学研究のサンプルサイズの検討依頼が含まれていたのだが、最初の依頼の仕方が

「（サンプルサイズが）･･･になるように数値を作って下さい。根拠になる数字はありません。」

確かにサンプルサイズの設定は所詮「数字遊び」の域は出ないのだが、その背景は「当該プロジェクトの取り進めの意思決定」のシナリオを描くことであって、「その研究が手早く終わるか？」等といった「現場のエゴ」をむき出しにすべき検討事項ではない。

自分が投資家になったつもりで、投資先がこのような安易な発想を持っていたらどう振舞うかを考えて欲しいところだ。

とはいっても返信が必要。どうしよう？

稀に穏やかな週

今週は本業の統計関連業務に多く時間を割いた。

1. データ収集の基本方針の摺り合わせ
2. ウイルス動態の解析に関する情報収集

という感じで、特に仕事を邪魔されることもなく、比較的穏やかな1週間だった。

1.に関しては会社・医療機関の思惑がぶつかる所だったが、会社の方針を優先するとの合意に至った。

2.については、動態モデル自体は（連立）微分方程式で記述されているものの、解析的に閉じた形で解くことができない（と私は思っている）。

色々論文を調査した所、動態に関していくつか仮定を加えることによりモデルを単純化し、閉じた形の解を求めた上でモデルを当てはめるのが一般的らしい。しかし、ある会社の解析報告を見ると、どうもそのような手順を踏んでいる形跡が見当たらない。

慣れた人なら直感でわかる問題なのかもしれないが、まだまだ勉強しなければならないことがあることを痛感した。

･･･とはいえ、この解析結果は結構重要な意味を持つことが予想されるので、あまり悠長なことは言っていられないのだけど。

（少し）つらい相談

今週はシステム導入のトラブル（納入遅れ）対応の他、本業である統計解析業務も「つまみ食い」的に少しずつ進める。

どちらかと言えば人の話を聞く方が得意なのだが、システムの分納（機能を段階的に導入）の可否について監査部門に話をしなければならないこととなった。

言うまでもなくシステムは「予定通り全部セットで」導入するのが最善（というかわかりやすい）なのであり、分納の相談はやや消極的な内容にならざるを得ない。

話をしている最中は多少つらい気分なのだが、相談が終わって今後の行く先が見え隠れしだすと不思議と気分が軽くなる。

その理由を考えると、

1. 相談する内容が（少し）つらいものである。だから、聞き手の反応は自分にとって（少し）つらいものだろうと予想してしまう。
2. 実際に相談すると、（途中の議論は確かにつらいが）一応今後の道筋が立って話が終わった。

というプロセスが共通して存在していることに気がついた。さらに

1. （少し）つらい相談を伴う仕事をしなければこのような経験はできない。
2. 今後の道筋を立てるには、話し手・聞き手の技術が必要。（自己弁護になるが）話し手は「困った」状態で話をもちかけるので、聞き手の忍耐強さは特に重要。
   

という事を感じた。

そういう意味では（少しつらいが）恵まれているのかも。監査部門の方々、ありがとうございました。

仕事中の私語も程度が

どこで仕入れたかは知らないが、人（有名人）の不幸のニュースで仕事中に盛り上がるというのはちょっとどうなのかなと。

「全く私語はNG」とは言わない（本当はうるさいと思っている）けど、せめて場の空気を悪くしない気配りはしてもらいたい。特に「職位が高い」とされている人々には。

あまりの感性の鈍さに沈黙。まともに相手にせんとこ。

問題点を回避する方法は？

独立でない打切り（死亡）を独立とみなして扱うのではなく、

1. 独立でない打切りまでの時間に対してモデルパラメータを推定し、
2. そのパラメータの推定値を基に、主要なイベントに対する打切りを独立な打切りと独立でない打切りを区別して取扱う

ことにより、検定統計量の一致性を確保する。

「できないこと」

今週は、納入が遅れているプログラムライブラリの開発委託先と今後の対応について話し合った。

本当は、

• エラーメッセージがわかりにくくて、こちらでテストプログラムが作りづらいんだけど

とか、

• 素人目に見て怪しい処理がちらほらあるんだけど

とか色々言いたいことはあったものの、今回の打ち合わせの趣旨を踏まえ、全体的な方針をお互いに確認するにとどめた。あくまでも、この後の作業をできる限り気分よく進めてもらうことを願いつつ。

ただ、強調したのは、

• できないことはできないと早く言って欲しい
• スケジュールは余裕を持って設定して欲しい

ということである。

ただ、「できないこと」を積極的に主張するのは案外難しい。理由は自尊心やビジネス上の背景など様々だが、少なくとも「（今の自分に）できること・できないこと」の区別や判断はできる限り躊躇わないようにしたい。

「できないことをできるようになる」ことはとても素敵なことだが、ビジネスでは「するべきことをする」ことだけが重要になる。「できないこと」に対しては他のカバー方法を考えればよいことである。

まさしく「言うは易く行なうは難し」。私も安請け合いの癖があるので気をつけないと。

なぜその現象が問題なのか？

検定の一致性（帰無仮説の下では名義上の有意水準を満たす）は、データ分布について置いた仮定が成り立つ場合にのみ成立する。Tarone検定では対象とする事象と打切りの独立性を仮定しているが、本研究で扱うデータでは、下肢切断と死亡による打切りの独立性は自明でない。このため、Tarone検定を適用した場合、検定結果が偽陽性である可能性がある。

研究の動機付けとなった現象は？

医薬品の用量反応試験とは、研究対象となっている医薬品の数種類の用量の比較により、用量と医薬品の有効性の関連性（「用量反応関係」）を検討することを目的とした臨床試験である。用量反応試験では様々な試験デザインが適用されるが、本研究では固定された用量の投与群を並行群間試験において比較する場合を扱う。

用量反応関係として最も単純なものは単調増加性あるいは単調減少性であり、このような関連性を検出するための統計的検定は傾向性検定と呼ばれる。応答変数の形式に応じて様々な傾向性検定の手法が提案されている。

ある臨床的事象の発現までの時間を応答変数とする場合、傾向性検定としてはTarone検定がよく知られている。この手法は、臨床的事象発現のハザード関数の線形対比に対する検定手法であり、Cox回帰モデルから導出することができる。

一方、以下のような状況を考える。

• 慢性的な動脈閉塞に起因する下肢切断実施までの時間を有効性の応答変数とする。
• 事象の追跡が長期にわたるため、途中で追跡の打切りが伴うが、重篤な疾患であるため、被験者の死亡による打切りの可能性がある。
• 医薬品の安全性評価の一環として、下肢切断実施に関係なく、一定期間の追跡を実施する。従って、「臨床的事象の発現後に死亡」というパターンが想定される。
  

このような場合、現時点で考えられる有効性の解析は以下のとおりである。

1. 下肢切断実施までの時間に対してTarone検定を適用し、打切りの理由は考慮しない。
2. 下肢切断実施・死亡いずれかの発現までの時間に対してTarone検定を適用する。
   

これらの解析は問題点を含んでいる。1.については、死亡が下肢切断と独立な事象であると考えている点である。動脈疾患が背景にあることを考慮すると、全ての死亡を下肢切断と独立と考えるのは問題がある。

仕事と電話

今週は、外注していた統計解析用モジュールの受け入れテスト対応でほぼ終始した。納品物に仕様書と食い違う点が出てきて大変だった。

至らぬ点が多く自分にあることは十分承知しているのだが、どうにも納得できないのが、IT（統計解析用モジュール開発がIT関連かどうかはともかく）の世界で飯を食う人にある問題について経緯を尋ねた際の「あなたが電話で言ったからそうなったのです」との回答。

その担当者の方はまじめな方なので「その通りなんだろうなぁ」と思いつつ、言いたい言葉をぐっと飲み込む。

私自身は、少しでも相手に勘違いを引き起こす可能性のある事項については電話で話すことはしない方針を採っている。それは、

• 基本的に「私の話術だけでは相手は理解できない」と考えているから。
• 電話越しに（場合によってはメモを取りながら）小難しい話を長々と聞かされるのは、相手にとってちょっとしたストレッサーではないかと考えている。（自分がそうだから）
• 相手の誤解を後に解くことになればそれだけでロスが生じるし、誤解が実際には生じていなくとも「誤解させなかったかなぁ」と不安になるのが嫌だから。
  

もちろん、仕事としてでもITベンダーが「あなたが電話で言ったから」という根拠で開発を進めるのは問題（何のための仕様書？）だが、この言葉にはそれ以前の部分で気分が良くなくなった。

図らずも自分の考えがそこそこ外れていないことはわかったものの、このために来週は多くの調整が必要になりそうだ。

ブログ移転テスト

結婚して環境が変わったのを機に、書き込み先を変えてみたい。

気になるのは最近書き込むネタが少なく感じること。

元々口数が少ない方ではあるが、それ以上に自分以外の人間と
気分のよい会話をしていない。がっかりする言葉を耳にすることが
ここ数日富に多い。

かく言う自分も相手の気分を悪くしているのかもしれない。

己の欲せざる所人に施すことなかれ。蓋し金言である。