« February 2007 | Main | April 2007 »

March 18, 2007

『エンジニアのための時間管理術』と『Sunbird』

E085『エンジニアのための時間管理術』と言う本を読了した。いわゆる『時間などの自己管理』の本なのだが、意外と面白かった。
私は、この類いの本を良く読むようで、古くは「Aタイム」や「7つの習慣」、その他昨年再流行したシステム手帳の本など、多数読んで居る。一般的な自己管理の本は、新社会人か一般管理職を対象に書かれて居るのに対し、『エンジニアのための時間管理術』はコンピュータのシステム管理者を対象にかかれている。例えば「繰り返し作業の手順化」を「インタラプターとコンパイラ」に例えたり、「スケジュール管理」を「マルチタスクでのCPUやメモリーなどのリソース処理」に例えて説明して居るところが面白かった。私はコンピュータのシステム管理者ではないのだが、一般職を対象に書かれた本よりは共感できる部分が多い。(職場でサーバーの管理を仕事として行って居るのに、帰宅したら、さらに最新のサーバーをインストールして試して居る・・・とか、そのあたり)

時間管理の方法は、色々と流儀があるようで、本によって千差万別だ。
酷い本になると「やらなけらばならないことは、片っ端から片付けること」と平気で書いてあることもある。優先順位も付けずに片端から片付けて済むなら、そもそも時間管理なんて要らない!

大きく分けると時間管理の方法は、「日単位で管理」と「週単位で管理」の2通りになるようだ。
「エンジニアのための時間管理術」と「Aタイム」は「日単位で管理」で、「7つの習慣」は「週単位で管理」を薦めている。これは、職業の別や生活習慣にもよるので、一概にどちらが良いとは言えないだろう。

とりあえず、現在は「エンジニアのための時間管理術」を見習って「日単位で管理」を行っている。この本に書いてあるが、「習慣化するには最低でも21日は続けること」とあるので、それを試して居る。
過去においても幾度となく、「時間管理」に挑戦しているが、身になっていない。自分の生活習慣に合わせて、オリジナルな時間管理方法と、それに合わせたPDA用のツールでも作ろうかと、「理想のPDA」なる連載をブログ上で行っていた時期もあった。
結局、オリジナルな時間管理法やツールを作っている暇があったら、既存の方法やツールを使った方が早い。

私の過去における「時間管理」の挫折は、必ずしも「三日坊主」ではない。週単位でも日単位でも、時間管理をしていると、無駄な時間があることが見えてくる。
この無駄時間を無くすように仕事をスケジューリングすると、グッと効率が上がる。ここで調子に乗って、仕事を増やすと禄な事がない。最初のうちこそ、無理が効くが、一カ月もしないうちに体力が持たずに破綻する。二週間も寝込むと結局効率は悪くなる。どうやら、自然のうちに無理をしないようにしていたようだ。

時間管理は、効率最優先ではない。また、短期的な効率最優先は、結局、効率悪化を招く。

実は、先程の「グッと効率が上がる」に大きな落とし穴がある。「効率が上がる」と見えるのは、あくまでも短期的な雑用に近い仕事の効率に過ぎない。もちろん、短期的な仕事でも重要な仕事もあるにはあるが、実際は短期的な仕事の大半は、さほど重要ではないもなのだ。

時間管理の真の目的は、一見すると「やらなければならない事」だと思えることで、実は本質的ではないことを止め、一見無駄に思える事でも「自分の人生の目標のためになる事」を優先して実行する事だ。

「エンジニアのための時間管理術」の「日単位で管理」は、短期的な効率化と、本質的でない事を止める事には効果がありそうだが、「自分の人生の目標のためになる事」を優先して実行するには未だ足りないような気がする。

ところで、時間管理のツールと言えば、最近、『Sunbird』を Debian Linux Sarge 上で試している。個人的なスケジュール管理は Zaurus で十分なのだが、Sunbird では、プライベートなプロジェクトのスケジュールと ToDo 管理を行おうと思っている。
ネットワーク上でのスケジュールと ToDo の共有などは上手く行っているようだが、不満もある。
まず、私の使っているサブノート PC の画面は 800 x 600 と小さい。小さい画面に合わせて、Sunbird のフォントも小さくしたいのだが、フォントサイズが変更できない。
また、モバイル環境で使う時、当然の事ながらネット接続できなければ、共有化したスケジュールと ToDo は見ることもできなければ、変更することもできない。
ネットワークに接続できない場所では、最後にアクセスした時のスケジュールと ToDo を表示し、変更した項目は、後にネットワーク接続した時に同期されるようになっていると良いのだが。もちろんコンフリクトの問題はあるが。
(この辺、Zaurus の後継を考えている事もある。Zaurus 自体を Debian 化するか、工人社の SA シリーズのような超小型のノートPCに Linux を入れて、PDA 的にモバイル環境で、Sunbird でスケジュール管理する可能性を考えて居る。Zaurus なら画面は 640x480だし、SA なら 768x480 だ。)

スケジュールの共有だけでなく、さらに進んで複数のメンバーで行うプロジェクトを管理できるグループウエアがあれば良いのだが、今のところ良いものを見つけられずに居る。
Web ブラウザ上でのグループウエアは、先のようなモバイル環境では使えない。以前、Kolab と Kontact の組み合わせを試したが上手く行かなかった(使い方が悪かったのかも知れない)

OpenGraoupware のようなものも出来つつあるようだが、こう言ったものが、もっと普及して欲しいものである。

| | Comments (0) | TrackBack (4)

March 16, 2007

IPS (恒星間測位システム)

野尻抱介氏のSF小説「沈黙のフライバイ」に出てくる IPS (恒星間測位システム)について、説明する。

この作品、1998年に書かれたものだが、IPSについての当時の検討を何処にも発表も公開もしていないので、あらためてここに記する。

IPS の目的は、「鮭の卵」のような小さな恒星間探査機のナビゲーションのための位置決定である。
そのため、まず電波の往復時間を測って距離を求めることはできない。小説「沈黙のフライバイ」の設定のように10光年離れた場合、往復で20年もかかってはナビゲーションに使えないからだ。従って、GPS のように一方通行の電波のみを使って、位置を求める必要がある。
また、受信側は「鮭の卵」のようにリソースが限られる。従って、可能な限り受信側をシンプルに作れるような仕組みが必要だ。「鮭の卵」は恒星間探査船だが、エネルギー源は太陽電池のみで、目的地の恒星に近付いて始めて電源が入る。その間は電源が切れた状態なので、時計を動作させ続けることはできない。つまり、正確な時刻を知らない状態から、始めなければならない。

E0841図1
IPS は、図1のように、2つの惑星に、それぞれ2つ、合計4つの衛星から構成される。(図1は、小説「沈黙のフライバイ」の設定に合わせて、恒星レッド・ドワーフと惑星トーリンとドワーリンにしている。私の元々の設定は、太陽・地球・海王星だ)

図2に、惑星の公転軌道面への投影図を示す。図2には、レッド・ドワーフと惑星公転面に垂直な軌道を持つ2つの衛星は省略している。


図2左上のトーリンを回る衛星から「鮭の卵」に行く電波に注目して欲しい。「鮭の卵」で受ける電波の周波数は IPS の位置によって、ドップラーシフトが起きていることが判るだろう。衛星が近付いてくる時は周波数が高く、離れている時は周波数が低い。
ドップラーシフトの時間変動率に注目すると、周波数が中間の時(図2の赤い矢印で示した場所)が、最も激しい。

E0842図2

この最も激しくドップラーシフトが変化する時の IPS の位置が判れば、トーリンから、その方向の先に「鮭の卵」が居る。正確に言うなら、ドップラーシフトが変化する時の速度ベクトルに対して垂直な面内に「鮭の卵」が居ることになる。(小説の中では、ドップラーシフトが最大になる時の接線方向と書いてあるが、実際はドップラーシフトの変化率の方が正確に測定できるので、こちらを用いる)

実は、この方法は、「のぞみ」や「はやぶさ」などの惑星間探査機の位置決定の時に用いる方法の応用だ。惑星間探査機の場合、臼田のアンテナから出る電波が探査機を往復したドップラーシフトを用いる。臼田のアンテナは衛星軌道を周回してはいないから、地球の自転を利用している。現在の技術として、この方法で、百万分の1ラジアンと言う高い精度で、角度を測定できる。

「鮭の卵」は、トーリンとドワーリンからの角度が判るので、三角測量の応用で、距離が判る。また、惑星公転面と垂直な2つの IPS の角度情報と合わせて三次元的な位置を決定することができる。

実は、IPS は3つの衛星があれば、三次元的な位置の決定が可能である。だが、これは受信側すなわち「鮭の卵」が極めて安定性の高い時計を持って居た場合の話である。実際には、安定性の高い時計を持つことはできない。そこで、一つ多い4つ衛星の信号を用いることで、正確な時計が無くても、位置を計算することができる。

実際に、どの位の精度で衛星の位置を決定できるか、計算してみた。
レッド・ドワーフから太陽系までの距離を10光年(100兆キロメートル)、トーリンとドワーリンの距離が、海王星までの距離と同じ 30 AU つまり45億キロメートルとする。

角度精度が、百万分の1ラジアンとすると、距離方向の誤差が 2.2光年(22兆キロメートル)、横方向の誤差が1億キロメートル(0.67 AU)だ。

どうだろう?
良い精度だと思うだろうか?悪いと思うだろうか?
実は私は「意外と良いなあ」と思った。

とは言え、百万分の1ラジアンと言う角度精度は、現在の技術で可能なレベルであり、IPS が未来の技術と考えれば、2〜4桁位精度が向上しても、おかしくは無い。
例えば、角度精度が2桁向上すれば、距離方向の誤差が 0.022光年(2200億キロメートル)、横方向の誤差が100万キロメートルになる。
角度精度が、さらにもう2桁向上すれば、距離方向の誤差が 0.00022光年(22億キロメートル、15AU)、横方向の誤差が1万キロメートルになる。

もちろん、何処まで行っても誤差は残るので、目的地の恒星自体を使った天測による補正は必要だろう。

と、ここまでは、約十年前に考えた事である。
今考えてみると、ドップラーシフトだけではなく、IPS の位置情報も使う方が良いかもしれないとか、全然違うところにもう幾つか IPS 衛星を配置し、搬送波レベルまで同期させて、「逆VLBI」させた方が角度精度があがるだろうなとか、IPS のバリエーションも星の数ほどありそうな気がしてきた。少なくとも IPS 間の距離があるほど精度が良くなるから、もっと距離を離す工夫は必要だろう。

余談
「鮭の卵」は、後日談がある。
その後の検討の結果、光速の15%と言う超高速に加速するのに、レーザー光が使用できる可能性があることが判った。
笹本祐一氏のSF小説「星のパイロット4」『ブルー・プラネット』のラストシーンで、マリオとスウの二人がラグランジュ2で見送っているのが、レーザー光で加速するバージョンの「鮭の卵」である。

| | Comments (2) | TrackBack (0)

March 03, 2007

ロケット設計 CGI

E083誰でも簡単にロケットの設計を Web 上で行える CGI を作った。

ロケット設計 CGI <= ここをクリックしてリンク

ロケットの設計と言うと、物凄く複雑で、とても素人が手を出せるような事では無いと思うだろう。実際、本当のロケットを作るためには、細かい解析や計算と言った設計は大変な作業となる。

しかし、本当にロケットを作るなら兎も角、大雑把なロケットの設計には、そんな複雑な計算をする必要はない。

例えば、「こんなロケット欲しいなあ」とか「こんな宇宙船を打ち上げるには、どんなロケットが要るんだろう?」と夢想したり、漫画やSF小説のネタに使う程度なら、電卓で計算できる程度のもので十分だ。(それすら禄に計算していない漫画やSF小説だらけだ。例外は、あさりさんや野尻さん位のものか?)

また、「何で液体酸素+液体水素の組合せと言われて居るんだろう?」とか「それなのに何で液体酸素+液体水素の一段目エンジンを持つロケットが、性能の低い筈の固体ロケット・ブースターを持って居るんだ?」とか「月へアポロを送ったサターンVは、何故2段目と3段目は液体酸素+液体水素なのに、1段目は液体酸素+ケロシンなの?」とか言った疑問を持ったら、ちょっとした計算してみると理解し易い。「何で何時までたっても、飛行機のように、各段を分離せずに、1段だけで宇宙に行くロケットはできないの?」なんて思って居る人も同じだ。

ロケットの設計に必要な基本的な計算方法は、昔、コ・ツと言う偉い人が定式化してくれた。これを使えば、本当に電卓ていどの簡単な計算でロケットの設計ができる。
普段、私は表計算ソフトなどを使って計算しているのだが、これを Web 上で使えたら面白いだろうな・・と思ったのが、今回公開した CGI である。ついでに設計したイメージを SVG 画像で見れるように工夫した(SVG の画像が見れるのは、Firefox だけ)

もちろん、高度な計算はしていないので、そのまま本物のロケット製造には使えないが、ちょっと遊んでロケットへの理解を深めてくれれば、幸いである。

| | Comments (3) | TrackBack (0)

告知

3月10日(土曜日)に、初台の NTT インターコミュニケーション・センターで開催中のOpenSky2.0トーク・イヴェント:ロケットまつりEX「宇宙(そら)へ」に出演予定。

| | Comments (0) | TrackBack (0)

« February 2007 | Main | April 2007 »