1999年2月

[前月][次月][一覧]:[表紙][映画][King][BBS]


2/28(Sun) 暑い暑い

暑い。とにかく暑い。もうすっかり夏に突入したようだ。 屋外リンクでのインラインホッケーの試合では、 朝9:00前だと言うのにぎらぎらと照りつける日射に肌が焼かれてゆくのがわかる。 昨年の3月はまだぐずぐずと雨が続いてやけに肌寒かったのだが、 今年、春休みで旅行に来る人はばっちりである。

常夏の島とは言っても、ホノルルの緯度は北緯21.3度。 一応季節がある (雨期、夏、そして真夏だ)。 ええと、ちょっと中学の理科を思い出してみると、地軸は公転面の鉛直方向から23.5度傾いて いるんだったっけ。すると、南中時の太陽高度は冬至の時約45度、春分と秋分が68.7度、 夏至の時は天頂より北側に来るが、南から測って約93度になる。その間は、 春分からの日数をdとすればだいたい 68.7+23.5*sin(2*pi*d/365) 度。 東京の緯度は北緯35.7度なんで、同様に 54.3+23.5*sin(2*pi*d/365) 度。 ホノルルでの2月末の太陽高度は東京では春分プラス15日、だいたい4月5日くらいにあたる。

あれ。もちろん気温の変化は陸地や海の熱容量やら大気や海水の対流やらに 影響されるのだけれども、直射日光の強さは晴れてさえいれば太陽高度だけに影響 されそうに思うんだけど。しかし、今の日射しが4月の東京の日射しと同じと言われると ちょっと意外。4月頭のよく晴れた日に東京で、 昼間2時間程花見をしたら顔が日焼けしててかてか、なんてことはあるんだろうか。

  1. 雲が多いため実際の日光の照射量は多くない
  2. 実は日射しは強いんだけど、寒いから気づかない
  3. 上の計算が根本的に間違っている

等々考えてみたけど、そういえば上の計算では秋分の15日前でも同じことになるのだった。 東京の9月6日の日射し、と言われれば、なるほどそうかという気がする… このへんの印象、やっぱりかなり気温に影響を受けるのだろうか。


さて、0:00を過ぎて月曜になったので、仕事にゆくとするか。

2/27(Sat)

週末の間にやっとかなければならない仕事があるのだが、 日曜はサーバ増設のため作業が出来ない。今日ぎりぎりまで粘ったが 間に合わんかった。うーむ、月曜0:00に出勤か?

久しぶりに偏頭痛。右目の奥が痛む。眼精疲労か、あるいはコンタクトがもう 合わなくなってきたのかもしれない。サーバ停止で一日休めるのは丁度良いかも。

2/26(Fri) 出来ることをやるだけでは…

しばらく更新頻度を減らしていた。理由を簡単に言えば、忙しいから、である。 しかし、これまでは締切直前の狂気のような忙しさの中でも更新はしていた (そういう時に限っていろいろ書きたいことが浮かんだりするものである) のだ。それより時間的余裕がある現在、忙しくて日記も書けないというのはどういうこと だろうか。

ソフトウェアシステムの開発サイクルの初期段階では、問題の分析に 多くの時間を割く。公式・非公式のミーティングを行っている間以外は、 ほとんど四六時中、考えを巡らせている。机に向かう必要もないので、 カフェに行くなり、散歩するなり、端から見れば遊んでいるようだが、 精神的にはいちばん苦しい時期である。テンションを自分で維持しなければ ならないからだ。

一方、締切近く、一日の3/4以上をオフィスで過ごしているような時は、 コーディングやらデバッグやらを行っているわけで、プレッシャーはきついものの あまり深く考える必要があるわけではない。目と手が疲れるとコーヒーを飲みながら 関係無いことをいろいろ考えたりもする。

上記のどちらの場合でも、日々つれづれに書きたいことはあり、日記を更新してきた。 現在の状況は、時間配分からすればコーディング・デバッグ・サポートに半分、 デザインに半分という、上記の二つの極端なケースの中間にあたる。 前者からは適度なプレッシャー (いや、「明日まで」とか「今日中に」とか締切は きついのだけれど) と短期的なフィードバックを得られ、そこで浮かんだアイディアを デザインに取り込んで試してみる、というわりとバランスの取れたサイクルが出来ている。 一定のテンションを維持したまま、モノはどんどん出来て行くので楽しい。 生産性という観点からすれば、最適な状態にあると思う。

しかし、負荷と出力がちょうどバランスしているこの状態を長く続けていると、 きっと成長することは無いだろう。 自分の持てる技で集団に貢献するのは喜びであるが、人はそれ以上に刺激を求める。 できるとわかっていることをやるのは、やっぱりつまらないのだ。

2/22(Mon)

野菜ジュースの"V8"。これにSpicy Hotというバリエーションがある。 辛いのだが、その辛みが旨い。朝飲むとすっきり目が覚める。 最近、新しい飲み方を発見した (友人がやりはじめたんだけど)。 ビールを、Spicy Hot V8で割るのである。2:1くらいの割合。 ビールとトマトジュースというカクテルはあったと思うが、 こちらはほのかな辛みが味に捻りを加える。機会があればお試しあれ。

2/20(Sat)

ここ一週間程、日本から友人が泊まりに来ていた。 仕事の量は相変わらずで、かつ友人と遊ぼうとすると、Webの更新はついおろそかになる。 ただ、日常的なことについて常に他人と議論できる状態にあると、 Web日記なんかでそれを論ずる必要性が自分にとって減少するのを感じた。 結局のところ、身辺雑記的な記事をつらつらと綴るのは、自分にとっては そういうことを話す相手がいないからなのかもしれない。

2/12(Fri) オープンソースソフトウェアの将来。その二。

FF8は社販で買ったけど、今ハマると大変なことになるので封印中。 しかしだらだらと昨日の続きなど書いてみる。今日は、サポート体制について。

企業がオープンソースでフリーのソフトウェアを採用することを躊躇する 理由として、サポートに不安があるから、というものがある。それに対する オープンソースコミュニティの反論はこうだ:バグの対応や新機種への対応は、 世界中のハッカーを味方に付けている我々が有利だ。セキュリティホールへの 対応パッチの開発などは、どんな商用ソフトウェアよりもフリーのオープンソース ソフトウェアの方が速いなんてことはよくある。また、企業ユーザ向けには ソフトウェアでなくサポートそのもので料金を徴収するビジネスがある、と。 一方、昨日紹介したLewis氏の記事は、現在のオープンソースのやり方が 通用するのはニッチな層を相手にしている場合だけで、 ユーザ層が大きくなればそのやり方ではサポートコストの増大は支え切れない だろうと見る。

私の経験からすると、サポートコストの重みというのは強調しすぎても しすぎることは無い。確かに、例えばLinuxはWindowsに比べて遥かに 安定しており、サーバとしてなら通常のオペレーション時のサポートは 殆んど不要だし、専任のシステム管理者がいればバグが出てもソースがあるので 迅速に対応できる。だが、メジャーマーケットを相手にするということは、 クライアントマシンにまで導入した場合を考えなければならないということだ。 クライアントマシンユーザをサポートするということは、「ウィンドウが 消えちゃったんですぅ」「後ろ側に隠れていませんか」というレベルから サポートが必要だということである。 オープンソースの薔薇色の未来像である「分散したデバッグ---目の数が多い程 バグは見付かり安いしFixも速い」というのは、ユーザがアプリケーションの バグを判断できるということを前提にしている。ところが、現在何らかの形でコンピュータを 使っている人々のうち、ある動作がバグかどうかを判断できる人なんてごくわずか なのだ。

それにもかかわらず、私はオープンソースであってもサポートの問題をクリアする ことは可能だと考える。いや、むしろ将来的にはオープンソースの方が有利なんでは ないかと考えている。

サポートコストの要因を分析してみると、多分こんなふうに分解されると思う。

  1. コンピュータ導入前のアセスメント
  2. コンピュータ導入後のユーザ教育、ガイダンス
  3. バグフィックス

1. のアセスメントは、簡単に言えば「コンピュータで何を実現したいのかを 明らかにする」ということだ。ここがきちんと出来ているかどうかで、 サポートコストは劇的に変化するのだ---明確なビジョンとゴール設定を 欠くソフトウェアプロジェクトはサポートの泥沼にはまり込むことが最初から 運命づけられている。受注生産の業務システムでは このようなアセスメントある程度体系的に行われている筈であるが、 個人あるいは小規模な職場で、売りきりのパッケージソフトを組み合わせて 環境を構築したいような場合には、それはユーザー側に委ねられてしまっている。 コンピュータの専門家ではないユーザが、最も専門的な知識を必要とする筈の この部分を担わなければならない点が、コンピュータがいつまでたっても使いやすく ならない根本原因の一つだと思う。

この部分に関しては、オープンソースのフリーなソフトウェアを利用しつつ、 アセスメントの部分で収益を上げるようなコンサルティング業務がもっと活発になって 良いと思う。今でも無いとは言わないが、もっと個人のユーザレベルで気軽に利用できる 手段があっても良い。ネットにつなぐためのハードウェアが現在のTVセット程に 普遍的なものになれば、そのようなコンサルティング業務をネット上で行うことも できるようになるだろう (現在では、ネットに繋ぐためにまずハードとソフトを 揃える、という時点でユーザがヘルプを必要とするからまだだめだが)。 このような構造が浸透することによって、アプリケーション提供者がサポートに 割かねばならないコスト自体が減少することが考えられる。

2.のユーザ教育のコストは、現在は無視出来ない (上記の「ウィンドウが消えちゃった」 みたいなものはこのカテゴリに入る)。しかしこれが将来減少するという見込みはある。 まず、アセスメントがしっかりすれば、ユーザはあまり迷うことはなく、また目的が はっきりしている分、自分で解決を見つけ出そうという姿勢になることが期待される。 さらに、ユーザインタフェース技術の進歩への期待。別にSFに出て来るような 賢いコンピュータでなくても良いのだが、「ユーザがエラーを起こすとしたら、 それはインタフェースが悪いためである」というインタフェース設計の原則は もっと浸透して良いはずだ。

さて、上記のように、コスト要因1.と2.は(アプリケーション開発者にとって) 将来軽減される見込みがあるが、3.は厄介である。バグの無いソフトウェアは無い。 だが、ここでオープンソースの強みが発揮されるのだ。「全世界に散らばるデバッグ要員」 という要素だけではない。バグフィックスのコストを極端に増大させる一つの 原因は、アプリケーションが利用しているコンポーネントが仕様のはっきりしない ブラックボックスであることである。仕様がはっきりしてさえいれば、あるいは 内部を覗くことができればすぐ同定できる問題が、それが出来ないために様々な 回り道を強いられるのだ。(MicroSoftよ、ヘルプファイルにアニメーションなんて 付けなくていいから、プレーンテキストで良いから、ちゃんとした仕様書をプロダクトに 着けてくれええええ)。仕様がはっきりして、かつ参照実装のソースコードが手に入れば バグフィックスのコストも軽減できる。この点で、 オープンスタンダード、かつオープンソースはいずれクローズドな製品を凌駕する であろうと考える。


この手のコンサルタントが書きそうな文章って苦手。わしの専門じゃないやね。

2/11(Thu) オープンソースソフトウェアの将来。その一。

IEEE Computer誌の99年2月号に、 オープンソースソフトウェア(*)の流れが 市場を支配してゆくだろうという見方に疑問を呈する 記事が乗っている (Ted Lewis: "The Open Software Acid Test")。 「オープンソースの流れは多少のシェアを占めるが、 決してメジャーにはならないだろうし、ソフトウェア業界に大きな変革も もたらさないだろう」というLewis氏の結論には同意しないけど、 彼が挙げているいくつかの理由はなかなか核心を突いている。 ひとつひとつについて論じようとしたらめちゃめちゃ長くなりそうになったので、 今日は一つだけ取り上げる(**)。 覚えていれば明日以降に続く。

オープンソースコミュニティは、オープンソースの強みとして、 世界中に散らばる膨大なハッカー達の力を味方にできることを挙げる。 企業がシニアプログラマとして迎えるような人材が、無償で自発的に 自分の時間を割いて開発に協力するのだ。 これに対し、Lewis氏は具体的な商用ソフトウェアに関わるプログラマの数をあげ、 それに比べればオープンソースの開発要員は決して大人数とは言えないという。 彼の比較は、例えばWindows NTの開発要員全員の人数を用いたりしているので 私からずればちょっと疑問であるが (NTの開発要員「全員」が、オープンソースの 開発に積極的に協力出来るレベルであるとは考えにくい。ジュニアレベルのプログラマも 多数抱えていると思う)、オープンソース開発の主力となれる人材が 有限である、という点は非常に重要である。

ハッカーもしくはその予備軍の多くは、大学の計算機工学科に在籍するとか、 計算機を駆使する研究所やメーカーに勤めるなど、自分と同程度やそれ以上のスキルを持つ 仲間がまわりに居るのだと思う (私もそういう環境にいる)。 それだけに、オープンソースプロジェクトにsignificantな貢献をできる程の スキルを持つことが、現実社会でどれくらい特異なことかという 事実に気づきにくいのではないか。確かに凄腕のハッカーは世界中に数多いが、 そうでないプログラマはもっとずっとたくさんいる。 そうでなくてもプログラマとしてやってゆけるのだし、 皆が皆ハッカーになる必要もなければそれを求められてもいないのだ。 コンピュータ工学に深い知識を持つ人と、 プログラミングも多少かじるが専門はむしろそれを適用する領域の方だという人とは、 ともに重要だし。(時々その両方に深い知識を持つ人もいるが、それはむしろ例外)。

すぐれたハッカーは常人の数十倍の生産性をあげることもある という話もある。実際、それをすぐに否定できない程、 ジュニアプログラマと経験を積んだプログラマで生産性がはっきり違うことは ざらにある。これほど差が出る職種は他にあまり無いのではなかろうか。 その上位にいる人を基準に生産性を外挿して予測してしまうことは非常に危険である。

だが、この事実をもって、オープンソースの開発は頭打ちになると予測するのも 短絡的にすぎる。ソフトウェア工学の進歩を考慮に入れていないからだ。 ソフトウェア設計の方法論、プログラミング言語、開発環境等の 進歩により、個々のプログラマ当たりの生産性は増大する。 また、エンドユーザ向けの簡易言語類がよりわかりやすくなることで、 使う人自身の手になじんだ道具にしてゆく部分がプログラマの負担でなくなってゆくことも 大きい。これらは2〜3年の期間ではあまり目立たないだろうが、10年経ってみれば 驚く程進歩しているはずであり、ソフトウェア開発のありかたを大きく変えていることだろう。 現在の段階での生産性論議がどの程度適用できるかはわからないのである。

もうひとつ。ジュニアレベルのプログラマはいつしかシニアレベルのプログラマに なることが期待されるわけだが、そのために最も良い方法の一つは、 他人の書いた(優秀な)ソースコードを読むことである。この効果は絶大である。 したがって、オープンソースの流れが広まることにより、プログラマ全体のレベルが 底上げされることが有り得るのだ。

(つづく、かも知れない。)

(*)オープンソースソフトウェアとは、開発者がソースコードを公開し、 興味ある人間が自由に開発、デバッグに参加できる形態で開発されたソフトウェア。 成果物は通常、無料でネット上を出回る。無料と言ってもそのクオリティは商用製品を 上回ることもしばしばある。 hotWIREDのFSFに 関する記事とかが分かりやすい。

(**)他の論点は、サポート費用の問題とか、 「企業は技術的優位性を保持するために結局コードを非公開にするだろう」とか。

2/9(Tue)

"Deadly Feasts" を読んだせいかどうかは知らないけれど、 なんだか肉を食べたくない気分。 しかし、昨日のホッケーの練習で体力強化の必要性に目覚めた私は 何とかしてプロテインを摂らなければならぬという使命に燃えていた。 スーパーマーケットSafewayでプロテインを探し求める私の目に飛び込んで来たのは "TOFU" のサイン。一丁で27グラムのプロテイン。Saturated Fat、Cholesterol、 Sugar全て0gの健康優良食品だ。ハワイで豆腐といえばアロハ豆腐しか無いと思って おられる人もいるかもしれぬが、今日買ったのは "Hinoichi" ブランド。御丁寧にも "Say Hee-no-ee-chee" と発音まで指示してある。私は綿漉し愛好家なのだが、 こちらのTOFUは Soft・Regular・Firm と分類されている。 ここはいつもの如くFirmをゲット。

豆腐を使う料理も様々なものがあり、ベジタリアンレストラン等に行けば豆腐料理 だけでメニューを一ページ使ってしまうほどだが、私は豆腐本来の持ち味を楽しむことを是として いるので、なるべく手を加えないようにしている (←単に料理が出来ないだけである)。 日本の冬ならば湯豆腐も良いかも知れぬが、午後には冷房が必要な当地ではそれも無用。 買って来たTOFUを適当な大きさにカットし、同時にGreen Onionこと細葱を刻みふりかけ、 かつおぶしをふりかけ、醤油と酢と辣油で出来上がりだ。うまいぞ。ちなみに、 以前も書いたように外食の多い独身者ゆえ、買って来た食材は直ちに消費することにしている。 つまり、どんぶり一杯の冷奴もどきが出来たというわけだ (TOFUの一丁はでかい)。 それだけで腹一杯になってしまい、果たしてこれが健康的かどうか考え込む。

2/8(Mon)

クリスマス・正月休暇明けから、狂ったような仕事のスケジュールに巻き込まれて ずっとホッケーを休んでいた。ようやく仕事のほうも落ち着いてきたし、ブランクが 空きすぎるとみんなに追い付けなくなるので、1月半ぶりくらいに練習に参加する。 ……吐きそうになった。心肺機能って簡単に衰えるもんだね。

2/7(Sun)

Richard Rhodes: "Deadly Feasts"。読み出したら止まらなくなって一気に読了。 「伝染するタンパク質」Prionに関するドキュメンタリーである。 (数年前に欧州でパニックを引き起こした「狂牛病」等の原因物質と疑われている タンパク質)。 これは恐い。キングよりも恐い。キングが "One of the most horrifying things I've ever read" とコメントを寄せた "The Hot Zone" よりも恐い。 後でコメントを書く予定。

2/6(Sat) Payback/Storm of the Century

Mel Gibsonがとことんタフな男を演じるアクション "Payback"。 ちょっとコミカルなところもあってそれなりに楽しめる。そんだけ。

今週頭に発売されていた筈のStephen Kingの新刊 "Storm of the Century" をようやく買えた。いや、売り切れだったとか言うわけではなく、本屋に行ってる 時間が無かったのだが。 これは、KingがTVのミニシリーズ用に書き下ろした脚本をそのまま出版したもので、 番組は来週末に3回に渡ってABCで放映される。「TVのミニシリーズとしては 史上最高規模のプロジェクト」だそうな。1996年に着想を得たKingは、 「この作品は映像作品でなければならない。しかし映画にするには 長すぎる」と感じ、過去に "The Shining" や "The Stand" 等でミニシリーズを作ったABCに話をもちかけた。ファースト ドラフトを見ただけでABCは$33,000,000の予算を組んだと言う。 アメリカではやはりKingはビッグネームだ。 読みたくてうずうずするけど、そういうことなら読まずに最初に映像作品に 触れた方が良さそうである。

本屋に行くと、目当ての本以外にたいてい数冊余分に買い込んでしまう。 今日は目的の "Storm of the Century" と共に、Einsteinの "Relativity" と "Ideas and Opinions" のペーパーバック版をレジに出したら、 「へえ、キングにアインシュタインねえ、不思議な取り合わせだな」 そうかなあ。

2/5(Fri) Waking Ned Devine

金曜日だ。この一週間はあっという間だった。 昨日プロデューサにプレゼンしたシステムを、今日の夕方に実際のユーザに説明。 まだ完成には程遠いが、とりあえずひとつ山を越えたというところか。 来週から実際に使われ始めると、山のようにバグ報告が届くのだろうけど。

恒例の金曜の映画、今日のチョイスはアイルランド産コメディ "Waking Ned Devine"。観終ったあと自分の気持の地平線が広がったような 気になれる、素敵な映画だった。 人口たった52人の村で、賞金数百万ポンドの宝くじの当選者が出る。 ところが当の本人が… とこれ以上書くともうネタバレになってしまうのだけど、 とにかく面白い。劇場的な設定と演出も効果的で、 シチュエーションコメディとしてきちんと作り込まれているが、 それだけではない。 惜しげも無く挿入される、どこまでも丘がうねるように広がるアイルランドの大地と、 文字通り黄金色の海の映像が、 人間の生も死も暖かく受け入れてくれる大きな存在を感じさせてくれて、 人生の様々な困難を笑いで乗り切る力強さを与えてくれる。 主要登場人物の半分は老人なのだが、これがまた芸達者な役者達で、 どのショットでも微妙な味付けをした演技を見せてくれる。

主演の一人で、大胆なヌードシーン(!)を披露した David Kellyは PixarのCG Short Film "Geri's Game" のGeriに似ているのだけれど (とくに動いているところはそっくり)、Pixarは彼をモデルにしたのかな。 この人の舞台を観てみたいなあ。

2/4(Thu) 免許更新/「本当の自分」

プレゼン。なかなか良い感触。まだ足りない部分は多いものの、 基本的な路線が正しいことを確認。夜、祝杯をあげる。

カリフォルニアで取った免許が来月の誕生日で切れるので、更新をしに行った。 ハワイでは免許関係の手続きはCity Satellite Officeで用が済む。 オフィスから歩いて3分程のところなので至極便利。 更新にはこれまでの免許の他にSocial Security Cardが必要。 また、他州からのトランスファーの場合は筆記試験を受けなければならない。

とは言ってもいいかげんな国アメリカのことで、免許の筆記試験は楽勝。 (4択問題が30問程。100ページ程のDriver's Handbookに一回目を通しておけばOK。 Handbookには御丁寧に試験問題候補も載っているのだ)。 それでも、「試験」なんて名のつくものはしばらく体験してなかったのでちょっと緊張した。

ハワイでは驚いたことに、その場で本免許証を発行してくれる (カリフォルニアでは 普通6週間程かかる。私はDMVのミスで半年近く待たされたのだが)。アプリケーションを 出してから、虹が背景になった本免許証を手にするまで1時間。実に手軽だ。 ただ、最近寝不足だったせいか写真が妙に眠そうな表情。 6年間使うことを思うとちょっと後悔。


日記猿人 の一部で盛り上がっている「本当の自分」論議について ( 最近の私とその周り 1/29日分, 2/5日分等)。 何をもって「自分」と定義するかってのは手に負えないので置いとくとして、 自分が心に思っていることに対して、様々な社会的要請などからそれとは違う 行動を取らねばならない時、「本当の自分を偽ってる」なんて表現が使われる。 ということは、「本当の自分」=「何ら抑圧も条件も存在しない場合に自分が 取るであろう行動」ってことなんだろうが、人間の存在が物理的にも精神的にも 外界との関係に依存していることから、何の抑圧も無いという状態は有り得ないし、 当然想像することもできない。 ここは考え方を逆転して、いかなる抑圧、いかなる条件があっても変わらずに 居られる部分とは何か、を考えてみると良いんじゃないかと思う。

例えば自分が社会制度も文化も違う国に住んでいたらどうか。 個人の自由が制限されたり、脅かされたりする社会だったら。 非常に自然条件が厳しく、生きぬくことさえ困難な社会だったら。 あるいは、眼の見える人は自分の眼が見えなかったらどうかを考えてみるとか。 あるいは、時間軸をずらして、自分が中世のヨーロッパに生きていたらどうしたか、とか。

もちろんそういうのは想像の遊びの域を出ないのだけれど、 いろいろ条件を変えてみると、自分の心が、現在の生活の条件故に拘っている部分と、 それ以外の部分とに分けられるように思えて来る。 後者は、(少なくとも想像上は)「例え何が自分の身に起ころうと変わらぬ自己」であり、 上記の意味での「本当の自分」ということになるのだろう。 他の何を奪い去られても自分は自分であると言えるが、それが無くなったら 自分では無いような気になってしまう何か。 それは固定された自己イメージではなく、むしろ外界と関わって行く姿勢というような 抽象化されたものになる。

思考の遊びに過ぎないと思うかもしれないけれど、こんなふうに気持を整理 するのは後で後悔しない決断をするためには役立つと思う。 現在存在する条件の故に選択に迷っているのだとしたら、その条件を変えることは 出来ないか、あるいはその条件に沿うことが、「それ以外の部分」にとってどれほどの 価値があるものか、なんて思いを巡らすことが出来るからだ。

どんな行動も、それを選択しているのは常に自分であり、責任は自分にある。 けれど、たまたまそこにあった条件に惑わされて決断したら、後からそれを その条件のせいにしてしまうようなことになりかねない。そんな思いは したくないではないか。

2/2(Tue)

ううっ。早寝早起きのススメ を読んで反省。この記事によれば、今、私の身体のホルモンバランスはめちゃくちゃになっているハズ。

2/1(Mon)

今日出したバージョンはわりと好評。これからバグをつぶして、仕様変更に対応して、 なんとか滑り込みで間に合いそうな気配。

ミーティングの合間を見つけて2時間、3時間と眠る生活。 いつでもどこでもどんな長さでもぐっすり眠れること、というのは この仕事に絶対必要なスキルだ。 それでも、椅子で寝るよりベッドで寝たほうが楽に決まっているので、 家が近いのはありがたい。


[前月][次月][一覧]:[表紙][映画][King][BBS]

Shiro Kawai
shiro@lava.net