4 月 2007
アプリケーション"MirrorAgent"の終了に失敗したため...ログアウトできず？
2007/04/25 00:17
使用中のアプリが終了できなくなってしまったのでログアウトしようとすると「アプリケーション"MirrorAgent"の終了に失敗したため、時間切れでログアウトてせきませんでした。もう一度やり直すには、"MirrorAgent"を終了して、アップルメニューから"ログアウト"を選びます」とのダイアログが出た...はて？！
当然のことながら？これまで幾多のトラブルに見舞われながらMacintoshと格闘しているが、初めてと思われる症状に出くわした。
問題の直接のきっかけは使っていたテキストエディタが終了できなくなってしまったのである。まあ、その程度でバタバタするほどのことではないから静かにログアウトでもしようと実行したら、これが出来ないのである...。
なんと「アプリケーション"MirrorAgent"の終了に失敗したため、時間切れでログアウトてせきませんでした。もう一度やり直すには、"MirrorAgent"を終了して、アップルメニューから"ログアウト"を選びます」とのメッセージが表示した。記憶の範囲ではこのトラブルは初めてである。
ちょっとビビッたのは「アプリケーション"MirrorAgent"の終了に失敗したため」というメッセージである。その"MirrorAgent"って一体何なのだ！？
こんなアプリを起動したつもりもないし、知らんぞ...そんなもの。NetBarrier X4のブロックを破って、スパイウェアかなんかが入り込んだのかと一瞬思った...。しかしまさかそんなことはないだろうと冷静に頭をフル回転して記憶をたどると、どこかで"MirrorAgent"っていう名称を見た覚えがあることを思い出し、早速ネットで検索してみた。
"MirrorAgent"とは、ローカルディスクと.macとをシンクロ（同期）させるソフトウェアだった。
そういえば思い当たるフシがある。
数日前に久しぶりにバックアップの意味を含めて、Safatiの「お気に入り」やMailのアカウント設定などを.macへ同期を取っておこうと実行した。それ自体は問題なく終了したようなのだが、デスクトップに置かれたiDiskのアイコンが捨てられないのである。しかしその時点では実害があるわけでもなし「まっいいか」で放っておいたのだが、どうやら先のトラブルはiDiskの接続問題のようである。
困ったことに、こうなるとアプリの強制終了などではダメで、電源長押しの強制終了しかなくなることだ...。
仕方がないので一端電源長押しの強制終了し、再起動させるとPowerMac G5 Quadはもの凄い音でファンがフル回転した後にまずは無事に起動したが、例のiDiskアイコン殿はまたまたデスクトップにおいでになる(笑)。
仕方がないので「システム環境設定...」の「.mac」を開き、その同期タブの「.Macと同期：」のチェックを外し、iDiskタブの「iDiskの同期機能は動作中です」を停止させた上でやっとiDiskをデスクトップから捨てることができた。
※「システム環境設定...」の「.mac」を開き、その同期タブの「.Macと同期：」のチェックを外し(上)、iDiskタブの「iDiskの同期機能は動作中です」を停止させた(下)
問題はこの原因だが、"MirrorAgent"のバグといえばそれまでなんだろうが、困ったことである。
確かに.macと同期を取ることは手動で実行したが、前記したような設定をONにした覚えはないのである(笑)。手動の実行なのだから、一度同期の作業が終わったら一連のプロセスも終了してくれないと困るわけだが、どういうわけか同期しっぱなしになっていたようだ。
というわけで、珍しいトラブルのためにサイトの更新も遅れてしまった次第である。
Home
当然のことながら？これまで幾多のトラブルに見舞われながらMacintoshと格闘しているが、初めてと思われる症状に出くわした。
問題の直接のきっかけは使っていたテキストエディタが終了できなくなってしまったのである。まあ、その程度でバタバタするほどのことではないから静かにログアウトでもしようと実行したら、これが出来ないのである...。
なんと「アプリケーション"MirrorAgent"の終了に失敗したため、時間切れでログアウトてせきませんでした。もう一度やり直すには、"MirrorAgent"を終了して、アップルメニューから"ログアウト"を選びます」とのメッセージが表示した。記憶の範囲ではこのトラブルは初めてである。
ちょっとビビッたのは「アプリケーション"MirrorAgent"の終了に失敗したため」というメッセージである。その"MirrorAgent"って一体何なのだ！？
こんなアプリを起動したつもりもないし、知らんぞ...そんなもの。NetBarrier X4のブロックを破って、スパイウェアかなんかが入り込んだのかと一瞬思った...。しかしまさかそんなことはないだろうと冷静に頭をフル回転して記憶をたどると、どこかで"MirrorAgent"っていう名称を見た覚えがあることを思い出し、早速ネットで検索してみた。
"MirrorAgent"とは、ローカルディスクと.macとをシンクロ（同期）させるソフトウェアだった。
そういえば思い当たるフシがある。
数日前に久しぶりにバックアップの意味を含めて、Safatiの「お気に入り」やMailのアカウント設定などを.macへ同期を取っておこうと実行した。それ自体は問題なく終了したようなのだが、デスクトップに置かれたiDiskのアイコンが捨てられないのである。しかしその時点では実害があるわけでもなし「まっいいか」で放っておいたのだが、どうやら先のトラブルはiDiskの接続問題のようである。
困ったことに、こうなるとアプリの強制終了などではダメで、電源長押しの強制終了しかなくなることだ...。
仕方がないので一端電源長押しの強制終了し、再起動させるとPowerMac G5 Quadはもの凄い音でファンがフル回転した後にまずは無事に起動したが、例のiDiskアイコン殿はまたまたデスクトップにおいでになる(笑)。
仕方がないので「システム環境設定...」の「.mac」を開き、その同期タブの「.Macと同期：」のチェックを外し、iDiskタブの「iDiskの同期機能は動作中です」を停止させた上でやっとiDiskをデスクトップから捨てることができた。
※「システム環境設定...」の「.mac」を開き、その同期タブの「.Macと同期：」のチェックを外し(上)、iDiskタブの「iDiskの同期機能は動作中です」を停止させた(下)
問題はこの原因だが、"MirrorAgent"のバグといえばそれまでなんだろうが、困ったことである。
確かに.macと同期を取ることは手動で実行したが、前記したような設定をONにした覚えはないのである(笑)。手動の実行なのだから、一度同期の作業が終わったら一連のプロセスも終了してくれないと困るわけだが、どういうわけか同期しっぱなしになっていたようだ。
というわけで、珍しいトラブルのためにサイトの更新も遅れてしまった次第である。
Home
ブルックス著「人月の神話」とソフトウェアビジネスの難しさ
2007/04/22 23:04
私は丸14年間仕事の約半分は自社開発のパッケージソフト作りに、後の半分は大手企業からの特注ソフトウェア開発で飯を食ってきた。そして様々な修羅場もくぐってきたから、ソフトウェアビジネスについて物言いする資格はあるだろう(笑)...。
前回ご紹介した「Appleの開発チームは『ブルックスの法則』とは無縁なのか？」で持ち出したブルックスの著書、「人月の神話〜狼人間を撃つ銀の弾はない」にからめて今回はソフトウェアビジネスの難しさをテーマに雑文を書いてみる。
フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」は1975年に出版された本だから、すでに30年以上も前の本である。そして私が手にしているものは発行20周年を記念して1996年に増訂出版された一冊だ。
本書(原題：「The Mythical Man-Month」)はコンピュータの開発、特にそのソフトウェア開発の生産性に関わるマネジメントの問題を扱った本である。ただし1975年といえば、コンピュータは大型汎用コンピュータを意味した。ブルックス自身、IBMのシステム/360の開発者として知られており、その開発の経験が本書を書くきっかけとなったという。したがって現在パソコン向けのソフトウェア開発の現状とは些かニュアンスが違うが、事ソフトウェアという "魔物" を扱う仕事としては傾聴に値する内容であることには間違いがない。
まあ、これからの話はプログラマや同業者の方々には文字通り釈迦に説法であるから、読み飛ばしていただきたいが、ソフトウェアを創るという仕事の内幕をご存じない方には面白いかも知れないし、一部はすべてのビジネスにも関わってくることだ...(笑)。
※フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」 (原著発行20周年記念増訂版)表紙
本書「人月の神話」について詳しく解説する余裕も能力も私にはないが、ソフトウェアを開発する立場からは現在にも通じる様々な問題を考えさせられる「古くて新しい一冊」だといえる。
ところで「人月」という言葉に馴染みがない人もいると思うので少し触れておきたい。「人月」は通常「ニンゲツ」と読み、ソフトウェア(とは限らないが)を開発実装するのに必要とする工数(一般的には見積額の算出などに利用する延べ時間)を人と時間との単純な掛け算で表現した単位である。例えば「3人が6ヶ月かかってソフトウェアを開発する場合」の工数は「18人月」となる。
この工数はそのまま見積の単位として見なされ、その開発企業の一人月の費用が100万円なら、前記の開発費用の基本総額は1,800万円となる計算だ。
しかしこの人月という考え方は、心ある人なら誰でも頭をかしげながら使っているのではないだろうか。
ブルックスは、開発コストは人月で算出されるが開発の進捗は人月にはそぐわず、疑うべき危険な神話であると言っている。
コストを人月で表すと言うことは、"人"と"月"とがお互いに交換できるというニュアンスを含んでいる。しかし実際には交換はできない。どういうことか...。
例えば前記のように「3人で6ヶ月かかるから18人月の仕事です」とクライアントに提示したとする。クライアントは「18ヶ月もかかるのでは間に合わないから18人を投入して1ヶ月で開発してくれ」と要求する(笑)。しかし、現実には出来得ない相談である。
そこに混乱が起きる。こうしたソフトウエア開発の管理の難しさから「女性がどれほどたくさん動員されたところで、子供１人が生まれてくるまでは十月十日かかることに変わりはないのと同じだ」とか「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」というブルックスの明言が生まれた。
そんなに不明瞭なら人月といった単位は使わなければ良いと考えるかも知れないが、当然クライアントはコスト算出のためには単位の定量化・標準化を求める。したがってある意味、ソフトウェア開発の天才であろうと今年入社した新人であろうと、１人は１人として数えるしか方法はなく、何ヶ月で開発が終わるかをコストに反映させるしか説得力のある単位が他にないのである(笑)。まあ、厳密にはより以上に緻密なコスト算出をしなければならないが、一般的に「人月」へのイメージはこんな感じなのだ。
さて、私の経営したMacintosh専門のソフトハウスは工数単価の高いことでも知られていた(笑)。
クライアントが他社と相見積をとるような場合があれば確実に2倍から3倍は高かったと思う。いや、私から言わせれば相見積の他社が異常であり、そのコストでは後先を考えずに仕事を取りたいがための安売りとしか考えられないのだが...。そして初めからそのコストではまともなものが作れるとは到底思えない。
ともかく１人月のコストは高かったが、自慢できることがひとつある。それは14年間のビジネスのなかで自社開発のケースは別として、クライアントからの特注開発依頼の納期を一度でも遅らせたことはない...。
さらっと書いたが、この事実はこの業界では希有なことだと断言できる(笑)。中には「ソフトウェア開発は遅れて当然」と考えている人もいるようだが、趣味ならともかくビジネスとしての契約あるいは約束を「当然」とか「慣例」のひと言で済ませてしまうそのことが、ソフトウェア産業への信頼性を薄くする原因に違いないと考える。
無論技術的にも他社が開発を失敗し、アップルに泣きつき、その駆け込み寺的に私の会社にコンタクトを取られた超大手企業もあったくらい、手前みそながら技術的にも優れた企業だった。
ともかく特注ソフトウェア開発はひと言でいえば「魔物」である。数多くの開発を手にしてきた経験から言えば最大の問題は「クライアントの多くは発注時に自身の欲しい"もの"を知らない」と常々感じている。どういうことか...。
もともとMacintosh用のソフトウェア開発のために、本格的な意味での仕様書などを書き上げた例はほとんどなく、開発の進捗そのものが仕様の確認となる場合が多かった。それでもクライアントは注文に当たり、当然のこと「このような機能を実装し、このような結果が得られるソフトウェアを開発して欲しい」と依頼してくる(注文書)。しかしそれらを実装して実際に動作するところをお見せすると、その大半は「ああ...なるほど、弊社が考えたことはこのことなのですね」と始めて本当の意味で、機能の目的や仕様の実際・実態を認識され、それが他へどのような影響を与えるものなのかを知ることになる。だから多くの場合に続いて「...それなら、こうした機能も可能ですか？」とくる(笑)。
...それでは見積の工数計算をやり直さなければならない。しかしクライアントはその事は頭にない(爆)。
だいたい仕様やその完成度について、開発側とクライアント側とはもともと温度差が違うものだから、その温度差をいかに埋めるかが重要であり、まかり間違っても口約束だけの仕事を受けるようなことがあってはならない。
私がどのような大手とも対等の基本契約書をやり取りする努力を怠らなかったのはそのためだ。
だいたい相手は工数だなんて便宜上のものであり、どうにでも収縮できるものだと思っているフシもあるのだ(笑)。
プログラムの開発の話ではないが、最近友人から聞いた話しで印象的な出来事があった。それは彼らがビデオ制作の受注を受け、何度もクライアント側のスタッフらと入念な打ち合わせをした結果、作品が完成し、それを納品するため相手先に出向いたという。クライアントのスタッフらは思った通りの出来に満足だったようだが、そこにこれまで一度も打ち合わせに出たこともない責任者と称するオヤジが登場し、一瞥しただけで「これではダメだな...やり直してもらえ」とスタッフにボソっと指示をしたという...嗚呼。
この種の場面を経験したことのないビジネスマンは幸せであるばかりでなく、失礼ながらまだ一人前ではないと思う(笑)。なぜならそれほどこの種の、それも理不尽なすれ違いが実際には多いものなのだ。
ともかくひと言でいえばソフトウェア開発という仕事は特殊な要素を多々含んでおり、単純に他のクリエイティブな労働と比較出来ないのである。
ここで詳細な部分には踏み込まないが、ブルックスはこうした問題を解決する意味で、管理者側の取るべき行動のうちもっとも重要なことは、「だれか１人を製品アーキテクト(architect)に任命することだ」と主張している。アーキテクトとは、この場合、設計者・考案者・構成者などと訳されるが、アーキテクトは開発関係者全員が共有すべき製品の心的モデルを形成することは勿論、利用者の代弁者でなければならない。
開発には機能・性能・サイズ・コスト・スケジュールといった様々な要因が複雑にからんでくるが、これらを十分に認識し、問題があれば傷の浅い内に軌道修正をとらなければならず、それらをコントロールするのもアーキテクトの役割に違いない。そして自身がユーザーの立場からもソフトウェアを評価できることが最も大切なことだと考える。
手前みそにはなるが、私の会社においてのアーキテクトは社長の私自身であった。現在でも私の大きな仕事のひとつはソフトウェア開発や新規事業立ち上げに際しての"アーキテクト"であると自負しており、名刺にもその旨を記してある。
というわけで、幸いにも優秀な開発陣やスタッフらの努力と共に私自身がアーキテクトの役割を果たし得たからこそ、納期を違えたこともなく、大きなトラブルを抱えることもなく14年間を過ごすことが出来た。
ただし、これは特注開発に関する状況であって自社開発のパッケージソフトウェアを生み出すプロセスとなれば話はかなり違ってくる。暴露話になるが(笑)、正直遅れに遅れたプロダクトもあったし、バグがなかなか取れずに苦労したプロダクトもあった。そうしたパッケージソフトの開発秘話についてはまた別途ご紹介してみたい。
さて、ブルックス著「人月の神話」はソフトウェア開発だけでなく、さまざまな業種における管理職のあり方をも考えさせられる名著だと思う。そこに展開されている理窟がすべて我々の日常を反映しているとは思わないが、もしまだお読みになっていない管理者がおられたら是非一読をお勧めしたい一冊である。
____________________________________________________________________________________
「人月の神話〜狼人間を撃つ銀の弾はない」
1996年2月15日 増訂版第1刷発行 (原著発行20周年記念増訂版)
著者：フレデリック・P・ブルックス
訳者：滝沢徹、牧野祐子、富澤昇
発行：アジソン・ウェスレイ・パブリッシャーズ・ジャパン（株）
発売：（株）星雲社
書籍コード：ISBN4-7952-9675-8 C3055
定価：本体2,816円+税
_____________________________________________________________________________________
Home
前回ご紹介した「Appleの開発チームは『ブルックスの法則』とは無縁なのか？」で持ち出したブルックスの著書、「人月の神話〜狼人間を撃つ銀の弾はない」にからめて今回はソフトウェアビジネスの難しさをテーマに雑文を書いてみる。
フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」は1975年に出版された本だから、すでに30年以上も前の本である。そして私が手にしているものは発行20周年を記念して1996年に増訂出版された一冊だ。
本書(原題：「The Mythical Man-Month」)はコンピュータの開発、特にそのソフトウェア開発の生産性に関わるマネジメントの問題を扱った本である。ただし1975年といえば、コンピュータは大型汎用コンピュータを意味した。ブルックス自身、IBMのシステム/360の開発者として知られており、その開発の経験が本書を書くきっかけとなったという。したがって現在パソコン向けのソフトウェア開発の現状とは些かニュアンスが違うが、事ソフトウェアという "魔物" を扱う仕事としては傾聴に値する内容であることには間違いがない。
まあ、これからの話はプログラマや同業者の方々には文字通り釈迦に説法であるから、読み飛ばしていただきたいが、ソフトウェアを創るという仕事の内幕をご存じない方には面白いかも知れないし、一部はすべてのビジネスにも関わってくることだ...(笑)。
※フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」 (原著発行20周年記念増訂版)表紙
本書「人月の神話」について詳しく解説する余裕も能力も私にはないが、ソフトウェアを開発する立場からは現在にも通じる様々な問題を考えさせられる「古くて新しい一冊」だといえる。
ところで「人月」という言葉に馴染みがない人もいると思うので少し触れておきたい。「人月」は通常「ニンゲツ」と読み、ソフトウェア(とは限らないが)を開発実装するのに必要とする工数(一般的には見積額の算出などに利用する延べ時間)を人と時間との単純な掛け算で表現した単位である。例えば「3人が6ヶ月かかってソフトウェアを開発する場合」の工数は「18人月」となる。
この工数はそのまま見積の単位として見なされ、その開発企業の一人月の費用が100万円なら、前記の開発費用の基本総額は1,800万円となる計算だ。
しかしこの人月という考え方は、心ある人なら誰でも頭をかしげながら使っているのではないだろうか。
ブルックスは、開発コストは人月で算出されるが開発の進捗は人月にはそぐわず、疑うべき危険な神話であると言っている。
コストを人月で表すと言うことは、"人"と"月"とがお互いに交換できるというニュアンスを含んでいる。しかし実際には交換はできない。どういうことか...。
例えば前記のように「3人で6ヶ月かかるから18人月の仕事です」とクライアントに提示したとする。クライアントは「18ヶ月もかかるのでは間に合わないから18人を投入して1ヶ月で開発してくれ」と要求する(笑)。しかし、現実には出来得ない相談である。
そこに混乱が起きる。こうしたソフトウエア開発の管理の難しさから「女性がどれほどたくさん動員されたところで、子供１人が生まれてくるまでは十月十日かかることに変わりはないのと同じだ」とか「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」というブルックスの明言が生まれた。
そんなに不明瞭なら人月といった単位は使わなければ良いと考えるかも知れないが、当然クライアントはコスト算出のためには単位の定量化・標準化を求める。したがってある意味、ソフトウェア開発の天才であろうと今年入社した新人であろうと、１人は１人として数えるしか方法はなく、何ヶ月で開発が終わるかをコストに反映させるしか説得力のある単位が他にないのである(笑)。まあ、厳密にはより以上に緻密なコスト算出をしなければならないが、一般的に「人月」へのイメージはこんな感じなのだ。
さて、私の経営したMacintosh専門のソフトハウスは工数単価の高いことでも知られていた(笑)。
クライアントが他社と相見積をとるような場合があれば確実に2倍から3倍は高かったと思う。いや、私から言わせれば相見積の他社が異常であり、そのコストでは後先を考えずに仕事を取りたいがための安売りとしか考えられないのだが...。そして初めからそのコストではまともなものが作れるとは到底思えない。
ともかく１人月のコストは高かったが、自慢できることがひとつある。それは14年間のビジネスのなかで自社開発のケースは別として、クライアントからの特注開発依頼の納期を一度でも遅らせたことはない...。
さらっと書いたが、この事実はこの業界では希有なことだと断言できる(笑)。中には「ソフトウェア開発は遅れて当然」と考えている人もいるようだが、趣味ならともかくビジネスとしての契約あるいは約束を「当然」とか「慣例」のひと言で済ませてしまうそのことが、ソフトウェア産業への信頼性を薄くする原因に違いないと考える。
無論技術的にも他社が開発を失敗し、アップルに泣きつき、その駆け込み寺的に私の会社にコンタクトを取られた超大手企業もあったくらい、手前みそながら技術的にも優れた企業だった。
ともかく特注ソフトウェア開発はひと言でいえば「魔物」である。数多くの開発を手にしてきた経験から言えば最大の問題は「クライアントの多くは発注時に自身の欲しい"もの"を知らない」と常々感じている。どういうことか...。
もともとMacintosh用のソフトウェア開発のために、本格的な意味での仕様書などを書き上げた例はほとんどなく、開発の進捗そのものが仕様の確認となる場合が多かった。それでもクライアントは注文に当たり、当然のこと「このような機能を実装し、このような結果が得られるソフトウェアを開発して欲しい」と依頼してくる(注文書)。しかしそれらを実装して実際に動作するところをお見せすると、その大半は「ああ...なるほど、弊社が考えたことはこのことなのですね」と始めて本当の意味で、機能の目的や仕様の実際・実態を認識され、それが他へどのような影響を与えるものなのかを知ることになる。だから多くの場合に続いて「...それなら、こうした機能も可能ですか？」とくる(笑)。
...それでは見積の工数計算をやり直さなければならない。しかしクライアントはその事は頭にない(爆)。
だいたい仕様やその完成度について、開発側とクライアント側とはもともと温度差が違うものだから、その温度差をいかに埋めるかが重要であり、まかり間違っても口約束だけの仕事を受けるようなことがあってはならない。
私がどのような大手とも対等の基本契約書をやり取りする努力を怠らなかったのはそのためだ。
だいたい相手は工数だなんて便宜上のものであり、どうにでも収縮できるものだと思っているフシもあるのだ(笑)。
プログラムの開発の話ではないが、最近友人から聞いた話しで印象的な出来事があった。それは彼らがビデオ制作の受注を受け、何度もクライアント側のスタッフらと入念な打ち合わせをした結果、作品が完成し、それを納品するため相手先に出向いたという。クライアントのスタッフらは思った通りの出来に満足だったようだが、そこにこれまで一度も打ち合わせに出たこともない責任者と称するオヤジが登場し、一瞥しただけで「これではダメだな...やり直してもらえ」とスタッフにボソっと指示をしたという...嗚呼。
この種の場面を経験したことのないビジネスマンは幸せであるばかりでなく、失礼ながらまだ一人前ではないと思う(笑)。なぜならそれほどこの種の、それも理不尽なすれ違いが実際には多いものなのだ。
ともかくひと言でいえばソフトウェア開発という仕事は特殊な要素を多々含んでおり、単純に他のクリエイティブな労働と比較出来ないのである。
ここで詳細な部分には踏み込まないが、ブルックスはこうした問題を解決する意味で、管理者側の取るべき行動のうちもっとも重要なことは、「だれか１人を製品アーキテクト(architect)に任命することだ」と主張している。アーキテクトとは、この場合、設計者・考案者・構成者などと訳されるが、アーキテクトは開発関係者全員が共有すべき製品の心的モデルを形成することは勿論、利用者の代弁者でなければならない。
開発には機能・性能・サイズ・コスト・スケジュールといった様々な要因が複雑にからんでくるが、これらを十分に認識し、問題があれば傷の浅い内に軌道修正をとらなければならず、それらをコントロールするのもアーキテクトの役割に違いない。そして自身がユーザーの立場からもソフトウェアを評価できることが最も大切なことだと考える。
手前みそにはなるが、私の会社においてのアーキテクトは社長の私自身であった。現在でも私の大きな仕事のひとつはソフトウェア開発や新規事業立ち上げに際しての"アーキテクト"であると自負しており、名刺にもその旨を記してある。
というわけで、幸いにも優秀な開発陣やスタッフらの努力と共に私自身がアーキテクトの役割を果たし得たからこそ、納期を違えたこともなく、大きなトラブルを抱えることもなく14年間を過ごすことが出来た。
ただし、これは特注開発に関する状況であって自社開発のパッケージソフトウェアを生み出すプロセスとなれば話はかなり違ってくる。暴露話になるが(笑)、正直遅れに遅れたプロダクトもあったし、バグがなかなか取れずに苦労したプロダクトもあった。そうしたパッケージソフトの開発秘話についてはまた別途ご紹介してみたい。
さて、ブルックス著「人月の神話」はソフトウェア開発だけでなく、さまざまな業種における管理職のあり方をも考えさせられる名著だと思う。そこに展開されている理窟がすべて我々の日常を反映しているとは思わないが、もしまだお読みになっていない管理者がおられたら是非一読をお勧めしたい一冊である。
____________________________________________________________________________________
「人月の神話〜狼人間を撃つ銀の弾はない」
1996年2月15日 増訂版第1刷発行 (原著発行20周年記念増訂版)
著者：フレデリック・P・ブルックス
訳者：滝沢徹、牧野祐子、富澤昇
発行：アジソン・ウェスレイ・パブリッシャーズ・ジャパン（株）
発売：（株）星雲社
書籍コード：ISBN4-7952-9675-8 C3055
定価：本体2,816円+税
_____________________________________________________________________________________
Home
Appleの開発チームは「ブルックスの法則」とは無縁なのか？
2007/04/18 00:03
先日Appleは、8-core or quad-core Mac
Proを発表したが、期待していた"Leopard"のリリースがiPhoneを理由に遅れると発表された。先にはApertureの開発チームが大幅に縮小されたというニュースもあったし、Appleの開発能力に不安を感じる人も多いと思うが...さて...。
ソフトウェアの開発はハードウェアの開発よりどうしても曖昧な部分が多いようだ。しかし双方共に人間が作るわけだから、企画から仕様の決定、そして開発期間および発売時期の決定といった一連のビジネススケジュールが立案できなければそれこそ仕事にならないはずだ。
かつて私の会社も100％Macintosh用ソフトウェア開発企業として丸14年間開発に努力をしてきたから、ソフトウェア開発がいかに不確定要素の多いものであるかは十分に承知している(笑)。
もっともパーソナルコンピュータ最初期の開発会社の多くはプログラマ自身が率いることが多かった。自分でソフトウェアの立案から開発そして販売に至るまでの責任を取るのだから、万一開発が遅れて損失を受けようがそれは自身の問題として明快だった。しかし例え小さくとも組織となれば話は違ってくる。
十分な相談・打ち合わせの上で新しく開発するソフトウェアの仕様やコンセプトを決めたとしても、一般社員の立場であるプログラマとすれば、いたずらに苦労したくないのは心情だろう(笑)。したがって困難だと思われる機能の実装などには消極的になっても不思議ではない。
また開発の実態はプログラマ個人に大きく依存することになる。一般の方には想像していただくより他はないが、プログラマとひと言で言ってもその能力は個人差が大変大きなものなのだ。
かつてのAppleでさえ、あのMacintoshの開発時にそのシステム回りの多くをビル・アトキンソンやアンディ・ハーツフェルドらに大きく依存したことは周知のことだ。その天才たちが昼夜を選ばす働いたようだが、それでもMacintosh 128Kの開発はチームを率いたスティーブ・ジョブズの思惑通りに進まず、リリースは遅れた。
現在のAppleソフトウェア開発チームも大変優秀な人材が揃っていると言われているが、文字通りの秀才や天才を必要とする時代ではすでにない。チーム全体でいかにパフォーマンスをあげるかが企業として問題になってくる。
かつてスティーブ・ジョブズがAppleに復帰したとき、ビル・アトキンソンがジョブズに「(Appleに復帰して)手伝いましょうか？」といった提案をしたとも言われているが、ジョブズは断ったという。１人の天才によりすべてを成し遂げる時代ではないことをジョブズもよく承知していたに違いない。
ただ、企業側の求める仕様や機能を開発チームにいかに徹底させ、出来ることと出来ないことを明確にした上で開発期間の見通しを立てるのは簡単なことではない。第一企業のトップに開発側の能力をきちんと見通せる能力がなければ、大変バランスのわるいことになる。
例えば「Aという機能を実装したい」と企業側が考えたとしよう。それに対して現場の開発側あるいはプログラマが「それはできません」と応えたとしても、その拒否のニュアンスには大きな幅があるものなのだ。
その「できない」という事由は、「物理的に誰が考えても不可能」なのか、「担当するプログラマに能力がない」ということなのか、あるいは「何らかの条件が揃えば可能なのか」が不明では決断もできないし先に進めない...。
最悪なのは、実現は大変難しいと知りつつ「やってみましょう」といった類を連発する開発側だ。これまた思い出すのはAppleがニューOSとして開発を進めていたコープランドやガーシュインがこれにあたる...。周知のようにApple再建のためにCEOとなったギルバート・アメリオの腹心、エレン・ハンコックが就任最初に判断したことは皮肉にも実態のないコープランドの自社開発を凍結・断念することだった。
さて、開発は単純に開発人数を増やしたから開発期間が短縮されてその質が向上するものではないことも事実である。だから先にAppleがApertureの開発チームを縮小したといういう情報が流れたときも単純にはその結果を評価できるものではないと考えた...。そして今回iPhoneの開発に人材とリソースを回すために"Leopard"の発売を延期するという判断も、現時点でのAppleの方向性を考える上で興味深いことだと思うし、制約や限界のある中での判断としてはあるべき姿なのかとも思う。
そうでもしないと私たちソフト開発にたずさわる者には知られている「ブルックスの法則」とか「人月の神話」の泥沼に入ってしまうのがソフトウェア開発の怖いところなのだ。
例えばその「ブルックスの法則」の中で最も有名なひとつに「遅れているソフトウェアプロジェクトへの要員追加はさらにその進捗を遅らせるだけ」というのがある。これを実体験した関係者は少なくないに違いない(笑)。
これは皮肉ではないが、Appleはその社名から"Computer"が消えた。そして例えば先日発表された8-core or quad-core のMac Proだってアップルジャパンのホットニュースはおろか、発表資料にも掲載されていないのだ...。Appleの力の入れようのバランスがこれまでとは微妙に違ってきたのを感じる。
ともかく、Appleとして今年最大のミッションは予定通りiPhoneをリリースしてビジネスチャンスをより拡大することに違いない。iPhoneが出たとしても即その恩恵を受けられない日本の私たちからすれば「2007年はまさかiPhoneだけではないでしょうね」と言いたいが、一連の報道から私はスティーブ・ジョブズのリーダーシップならびに割り切りの良い企業判断を評価している。
ただ、そうした報道だけに接しているとAppleのソフトウェア開発能力低下が目に見えるようでもあり、少々心配になっていたが4月15日に発表された「Final Cut Studio 2」と「Final Cut Server」の報道を得て「やるべきことはきちんとやっているな...」という思いを新たにし、安心した次第である。
そう、項を新たにして「ブルックスの法則」とか「人月の神話」についてはリアルなお話しをしてみたい(笑)。
Home
ソフトウェアの開発はハードウェアの開発よりどうしても曖昧な部分が多いようだ。しかし双方共に人間が作るわけだから、企画から仕様の決定、そして開発期間および発売時期の決定といった一連のビジネススケジュールが立案できなければそれこそ仕事にならないはずだ。
かつて私の会社も100％Macintosh用ソフトウェア開発企業として丸14年間開発に努力をしてきたから、ソフトウェア開発がいかに不確定要素の多いものであるかは十分に承知している(笑)。
もっともパーソナルコンピュータ最初期の開発会社の多くはプログラマ自身が率いることが多かった。自分でソフトウェアの立案から開発そして販売に至るまでの責任を取るのだから、万一開発が遅れて損失を受けようがそれは自身の問題として明快だった。しかし例え小さくとも組織となれば話は違ってくる。
十分な相談・打ち合わせの上で新しく開発するソフトウェアの仕様やコンセプトを決めたとしても、一般社員の立場であるプログラマとすれば、いたずらに苦労したくないのは心情だろう(笑)。したがって困難だと思われる機能の実装などには消極的になっても不思議ではない。
また開発の実態はプログラマ個人に大きく依存することになる。一般の方には想像していただくより他はないが、プログラマとひと言で言ってもその能力は個人差が大変大きなものなのだ。
かつてのAppleでさえ、あのMacintoshの開発時にそのシステム回りの多くをビル・アトキンソンやアンディ・ハーツフェルドらに大きく依存したことは周知のことだ。その天才たちが昼夜を選ばす働いたようだが、それでもMacintosh 128Kの開発はチームを率いたスティーブ・ジョブズの思惑通りに進まず、リリースは遅れた。
現在のAppleソフトウェア開発チームも大変優秀な人材が揃っていると言われているが、文字通りの秀才や天才を必要とする時代ではすでにない。チーム全体でいかにパフォーマンスをあげるかが企業として問題になってくる。
かつてスティーブ・ジョブズがAppleに復帰したとき、ビル・アトキンソンがジョブズに「(Appleに復帰して)手伝いましょうか？」といった提案をしたとも言われているが、ジョブズは断ったという。１人の天才によりすべてを成し遂げる時代ではないことをジョブズもよく承知していたに違いない。
ただ、企業側の求める仕様や機能を開発チームにいかに徹底させ、出来ることと出来ないことを明確にした上で開発期間の見通しを立てるのは簡単なことではない。第一企業のトップに開発側の能力をきちんと見通せる能力がなければ、大変バランスのわるいことになる。
例えば「Aという機能を実装したい」と企業側が考えたとしよう。それに対して現場の開発側あるいはプログラマが「それはできません」と応えたとしても、その拒否のニュアンスには大きな幅があるものなのだ。
その「できない」という事由は、「物理的に誰が考えても不可能」なのか、「担当するプログラマに能力がない」ということなのか、あるいは「何らかの条件が揃えば可能なのか」が不明では決断もできないし先に進めない...。
最悪なのは、実現は大変難しいと知りつつ「やってみましょう」といった類を連発する開発側だ。これまた思い出すのはAppleがニューOSとして開発を進めていたコープランドやガーシュインがこれにあたる...。周知のようにApple再建のためにCEOとなったギルバート・アメリオの腹心、エレン・ハンコックが就任最初に判断したことは皮肉にも実態のないコープランドの自社開発を凍結・断念することだった。
さて、開発は単純に開発人数を増やしたから開発期間が短縮されてその質が向上するものではないことも事実である。だから先にAppleがApertureの開発チームを縮小したといういう情報が流れたときも単純にはその結果を評価できるものではないと考えた...。そして今回iPhoneの開発に人材とリソースを回すために"Leopard"の発売を延期するという判断も、現時点でのAppleの方向性を考える上で興味深いことだと思うし、制約や限界のある中での判断としてはあるべき姿なのかとも思う。
そうでもしないと私たちソフト開発にたずさわる者には知られている「ブルックスの法則」とか「人月の神話」の泥沼に入ってしまうのがソフトウェア開発の怖いところなのだ。
例えばその「ブルックスの法則」の中で最も有名なひとつに「遅れているソフトウェアプロジェクトへの要員追加はさらにその進捗を遅らせるだけ」というのがある。これを実体験した関係者は少なくないに違いない(笑)。
これは皮肉ではないが、Appleはその社名から"Computer"が消えた。そして例えば先日発表された8-core or quad-core のMac Proだってアップルジャパンのホットニュースはおろか、発表資料にも掲載されていないのだ...。Appleの力の入れようのバランスがこれまでとは微妙に違ってきたのを感じる。
ともかく、Appleとして今年最大のミッションは予定通りiPhoneをリリースしてビジネスチャンスをより拡大することに違いない。iPhoneが出たとしても即その恩恵を受けられない日本の私たちからすれば「2007年はまさかiPhoneだけではないでしょうね」と言いたいが、一連の報道から私はスティーブ・ジョブズのリーダーシップならびに割り切りの良い企業判断を評価している。
ただ、そうした報道だけに接しているとAppleのソフトウェア開発能力低下が目に見えるようでもあり、少々心配になっていたが4月15日に発表された「Final Cut Studio 2」と「Final Cut Server」の報道を得て「やるべきことはきちんとやっているな...」という思いを新たにし、安心した次第である。
そう、項を新たにして「ブルックスの法則」とか「人月の神話」についてはリアルなお話しをしてみたい(笑)。
Home
ハイエンドイヤフォンSHURE E4cとv-mode vibeの聴き比べ
2007/04/12 19:42
最近iPodユーザーに大変好評だというハイエンドイヤフォン「v-mode
vibe」を手にすることができた。私の回りでも数人のユーザーがいて「これいいよ」という。
それならばと私の愛用する「SHURE E4c」と聴き比べてみた。
イヤフォンの種類はすでに数え切れないほどで、いわゆるピンからキリまで多様な製品があり、さらに新製品は増え続けている。そんな中で愛用のひとつを見いだすことはなかなか難しい。
一般的にiPodユーザーなら、本体を購入したときに同梱されているApple純正イヤフォンで十分だと感じる人も多い。確かに"音"の良し悪しは比較しなければなかなか認識できない部類のもので、だからこそオーディオファンは少しでも原音に近づけたいと金をつぎ込む(かつての私もそうだった...笑)。
私も歩きながらといったラフな聴き方をiPod Shuffleと共にするときには手頃なApple純正イヤフォンを持ち出すこともあるが、正直音が良くないといった不満をリアルに感じることはほとんどない。しかし物事にはやはり優れているものが存在することも知っておきたいといくつかのイヤフォンを渡り歩いた結果、現在「SHURE E4c」を愛用している。
この「SHURE E4c」については過去にレポートしたので興味のある方は参考にしていただきたいが、今回はその「SHURE E4c」と「v-mode vibe」の聴き比べをしてみたわけ...。ただし特に両者のスペック的なことには立ち入らないので興味のある方は後述する取り扱い会社のウェブページで確認願いたい。
テストする音源はiPod 5Gで、ソースはジャズとクラシック(ピアノあるいはギター)を中心に一部はロックなども聴いてみた。
まずは「v-mode vibe」を耳に装着。カナル型のシリコンイヤーパッドは耳当たりが大変良く違和感がないので長時間の使用に最適だ。重さも約12gと見かけより軽いので苦にならない。
さてその音だが、大変ナチュラルに感じたしバランスも悪くない。暖かいサウンドといったイメージであり、長時間聴き続けても疲れない音といえばよいのだろうか。低音も十分出ているが、強いて言うならシャープさがより欲しいといった感じがする。
しかし、この音は心地よい。純粋に楽しみながら音楽を聴くには大変よい製品であると思う。
※「v-mode vibe」のLaMocha リッチゴールド・イヤフォン
さて「v-mode vibe」の心地よさを十分に堪能した後に愛用の「SHURE E4c」を耳にする。ケーブルが太めなのと重さが31gあるので「v-mode vibe」と比較するなら、ケーブルの扱いが少々煩わしい。
まあ、随分と遍歴の末に「SHURE E4c」にたどり着いたわけだから、好みであるものの、あらためて音のクリア度と分解能の高さには驚く。そして音像定位はよりシャープである。
例えて言うなら「v-mode vibe」は良質なリスニングスピーカーといったイメージに対して「SHURE E4c」はモニタースピーカーだといえば良いのだろうか。音の解像度が違う。
※「SHURE E4c」イヤフォン。フォーム・イヤーパッドで聴いている
再度「v-mode vibe」と「SHURE E4c」をSmartShareを使い、同じ音源で繰り返し聞き比べをしてみるが、音楽を純粋に楽しむなら「v-mode vibe」は何の不足もない良質のイヤフォンである。しかし自身がギターを弾き、ピアノも習ったという楽器を多少なりともこなす１人としてはひとつひとつの楽器の音のリアル感やその場の音像定位がイメージできる「SHURE E4c」が好みなのだ。
勿論これまた重要なことだが「SHURE E4c」は「v-mode vibe」の約倍ほどの価格であることも明記しておかなければならないだろう。しかしこの世界は価格が高いから良いといった単純ではないだけに、なるべく多くの製品を聞き比べて自分に合うものを選ぶ必要がある。
そうした意味において「v-mode vibe」は実売10,000円台のイヤフォンとしては大変レベルの高い製品だと感じた。
そう、「v-mode vibe」でひとつだけ気になったことがあるので記しておきたい。私が試聴したのは「v-mode vibe」のLaMocha リッチゴールドというタイプの製品だが、左右...すなわちRとLの表記がシリコンイヤーパッドを少しめくりあげないと分からないのは使いづらい...。
まったく、音に対する探求には限りがない。何と厄介な...そして楽しいことなのだろうか(笑)。
■SHURE E4c
■v-moda vibe LaMocha リッチゴールド
Home
それならばと私の愛用する「SHURE E4c」と聴き比べてみた。
イヤフォンの種類はすでに数え切れないほどで、いわゆるピンからキリまで多様な製品があり、さらに新製品は増え続けている。そんな中で愛用のひとつを見いだすことはなかなか難しい。
一般的にiPodユーザーなら、本体を購入したときに同梱されているApple純正イヤフォンで十分だと感じる人も多い。確かに"音"の良し悪しは比較しなければなかなか認識できない部類のもので、だからこそオーディオファンは少しでも原音に近づけたいと金をつぎ込む(かつての私もそうだった...笑)。
私も歩きながらといったラフな聴き方をiPod Shuffleと共にするときには手頃なApple純正イヤフォンを持ち出すこともあるが、正直音が良くないといった不満をリアルに感じることはほとんどない。しかし物事にはやはり優れているものが存在することも知っておきたいといくつかのイヤフォンを渡り歩いた結果、現在「SHURE E4c」を愛用している。
この「SHURE E4c」については過去にレポートしたので興味のある方は参考にしていただきたいが、今回はその「SHURE E4c」と「v-mode vibe」の聴き比べをしてみたわけ...。ただし特に両者のスペック的なことには立ち入らないので興味のある方は後述する取り扱い会社のウェブページで確認願いたい。
テストする音源はiPod 5Gで、ソースはジャズとクラシック(ピアノあるいはギター)を中心に一部はロックなども聴いてみた。
まずは「v-mode vibe」を耳に装着。カナル型のシリコンイヤーパッドは耳当たりが大変良く違和感がないので長時間の使用に最適だ。重さも約12gと見かけより軽いので苦にならない。
さてその音だが、大変ナチュラルに感じたしバランスも悪くない。暖かいサウンドといったイメージであり、長時間聴き続けても疲れない音といえばよいのだろうか。低音も十分出ているが、強いて言うならシャープさがより欲しいといった感じがする。
しかし、この音は心地よい。純粋に楽しみながら音楽を聴くには大変よい製品であると思う。
※「v-mode vibe」のLaMocha リッチゴールド・イヤフォン
さて「v-mode vibe」の心地よさを十分に堪能した後に愛用の「SHURE E4c」を耳にする。ケーブルが太めなのと重さが31gあるので「v-mode vibe」と比較するなら、ケーブルの扱いが少々煩わしい。
まあ、随分と遍歴の末に「SHURE E4c」にたどり着いたわけだから、好みであるものの、あらためて音のクリア度と分解能の高さには驚く。そして音像定位はよりシャープである。
例えて言うなら「v-mode vibe」は良質なリスニングスピーカーといったイメージに対して「SHURE E4c」はモニタースピーカーだといえば良いのだろうか。音の解像度が違う。
※「SHURE E4c」イヤフォン。フォーム・イヤーパッドで聴いている
再度「v-mode vibe」と「SHURE E4c」をSmartShareを使い、同じ音源で繰り返し聞き比べをしてみるが、音楽を純粋に楽しむなら「v-mode vibe」は何の不足もない良質のイヤフォンである。しかし自身がギターを弾き、ピアノも習ったという楽器を多少なりともこなす１人としてはひとつひとつの楽器の音のリアル感やその場の音像定位がイメージできる「SHURE E4c」が好みなのだ。
勿論これまた重要なことだが「SHURE E4c」は「v-mode vibe」の約倍ほどの価格であることも明記しておかなければならないだろう。しかしこの世界は価格が高いから良いといった単純ではないだけに、なるべく多くの製品を聞き比べて自分に合うものを選ぶ必要がある。
そうした意味において「v-mode vibe」は実売10,000円台のイヤフォンとしては大変レベルの高い製品だと感じた。
そう、「v-mode vibe」でひとつだけ気になったことがあるので記しておきたい。私が試聴したのは「v-mode vibe」のLaMocha リッチゴールドというタイプの製品だが、左右...すなわちRとLの表記がシリコンイヤーパッドを少しめくりあげないと分からないのは使いづらい...。
まったく、音に対する探求には限りがない。何と厄介な...そして楽しいことなのだろうか(笑)。
■SHURE E4c
■v-moda vibe LaMocha リッチゴールド
Home
祝い！ 1億台突破〜iPodの操作は服の上からでもできる？！
2007/04/10 19:29
アップルのホットニュースによれば4月9日付けでiPodの累計販売台数が1億台を突破したとのこと。そういえば今更ではあるものの、友人が「iPodって服の上からでも操作できるんですね...」と感心していた。
なるほどね。私は落とすまいと、iPodを例えばシャツの胸ポケットなどには絶対入れないようにしているが、シャツ程度の生地なら位置と指の圧さえ見当つければいちいちポケットからiPodを取り出して操作する必要はないことは確かだ。
まあ、生地の種類や厚さにもよると思うが、それで当然と思っていた私は最近iPodユーザーになった友人の感激ぶりを見て、あらためて自分が慣れすぎた感覚を持っているのかな...と反省した次第。
で、いまあらためてiPod (5G)を胸ポケットに入れて操作してみたが、ホイールを押すことは当然できる。しかし少々慣れが必要なのはボリューム調整だ。強く押しすぎてるとモードが変わってしまうから、ほどよい圧を習得しなければならない(笑)。しかし上手にやればシャツの生地一枚程度で隔てていてもボリュームコントロールができるのだから友人の感激もわかるような気がする。感激できることは素晴らしいことだ。
はいはい...確かに凄いですね〜
。
「指で操作する」といえば私などはやはりiPhoneを連想してしまうが、思えば知らない間にiPodがない生活など想像もつかないはめになってしまった。
それにつけても1億台とは凄い数字だ。そして確実なことはその中に私の10数台も含まれていることだ(笑)。
今夜は1億台突破を祝い、すべてのiPodに充電をしてあげようではないか。
■アップルジャパン株式会社
Home
なるほどね。私は落とすまいと、iPodを例えばシャツの胸ポケットなどには絶対入れないようにしているが、シャツ程度の生地なら位置と指の圧さえ見当つければいちいちポケットからiPodを取り出して操作する必要はないことは確かだ。
まあ、生地の種類や厚さにもよると思うが、それで当然と思っていた私は最近iPodユーザーになった友人の感激ぶりを見て、あらためて自分が慣れすぎた感覚を持っているのかな...と反省した次第。
で、いまあらためてiPod (5G)を胸ポケットに入れて操作してみたが、ホイールを押すことは当然できる。しかし少々慣れが必要なのはボリューム調整だ。強く押しすぎてるとモードが変わってしまうから、ほどよい圧を習得しなければならない(笑)。しかし上手にやればシャツの生地一枚程度で隔てていてもボリュームコントロールができるのだから友人の感激もわかるような気がする。感激できることは素晴らしいことだ。
はいはい...確かに凄いですね〜
。
「指で操作する」といえば私などはやはりiPhoneを連想してしまうが、思えば知らない間にiPodがない生活など想像もつかないはめになってしまった。
それにつけても1億台とは凄い数字だ。そして確実なことはその中に私の10数台も含まれていることだ(笑)。
今夜は1億台突破を祝い、すべてのiPodに充電をしてあげようではないか。
■アップルジャパン株式会社
Home
SDHCカードのClass 2とCalss 4はどの程度違うのか？
2007/04/05 22:36
記録メディアにもいろいろと種類があるが、ふと手元にある機器類を確認してみると私の環境ではSDカード類が多い。そして今回ハイビジョンムービー
Xacti DMX-HD2用にと買ったSDHCだが、従来のSDカードとは互換性がないという...。
これまでのSDメモリーカードの最大容量は2GBだったが、SDHCでは4GB以上の容量が実現可能となり、現在8GBの製品が販売されていることはご承知のとおりである。そして業界では2008年から2010年に至るスパンでは最大32GBの実現を目指しているという。
しかし現実問題、SDHCと従来のSDとどこがどれほど違うのだろうか...。
SDHCカードはハイビジョンカムコーダやデジタルカメラは勿論のこと、携帯電話やパソコンなどへの採用を想定しており、いわゆる記録データの大容量化と高速化の要求に合わせて登場したメディアである。
そのSDHCは、SDメモリー・カードの規格団体であるSD Card Associationが設定した新しい標準であり、従来の限界であった2GB容量を超える容量を実現し、かつ3つの速度クラス(Class 2、4、 6)を提供して最低の転送速度を保証している点がポイントである。そしてSDHCカードは、SDHC対応デバイスやSanyo、Nikon、Canon、Pentax、Casioなどの各社がSDHCをサポートするカメラ器機で認識できる。
重要なことはSDHCカードとSDカードは互換性がなく、従来のSDメモリーカード対応機器でSDHCメディアを利用することはできない。したがってこれまでのSDカードリーダーではSDHCは読めないわけだ。ただし、SDHC機器は従来のSDカードも利用できる。
さて、SDHCのClassとは前記したように速度の保証値を規定するものだが、スペック的にはClass 6は6MB/Secの転送速度を保証、Class 4は4MB/Sec(32Mbps)、そしてClass 2は2MB/Sec(16Mbps)と規定されているという。したがってClassの高いSDHCほどハイビジョンなど、高いパフォーマンスを求められる書き込みや読み込みスピードにコマ落ちといったことなく対応できるというわけだ。ただし例えば、SDHCのClass 6を使ったとしても、使用機器がClass 2までの対応なら、そのパフォーマンスは当然Class 2までのものになってしまう...。
なるほど...理窟はわかったが、今回手に入れたSanyo ハイビジョンムービー Xacti DMX-HD2 でムービーを撮ってみると実際にはSDHC Class 2で問題がないようなのだ...。もしそうなら製造メーカーにもよるものの、一般的には同容量のClass2よりClass 4の製品の方が高価なので、必要以上の高Classカードを使っても意味がないように思える。
ただし、例えばデジカメとして写真を撮ることを考えると(私はこちらの方が使用頻度が高い) Xacti DMX-HD2 は、シャッターを押してから次のシャッターを押せるのはSDHCに書き込み完了後である。ちなみに Xacti DMX-HD2 にもいわゆる連写モードがあるが、解像度が30万画素の640×480に限定されてしまうので、解像度の高い写真を撮るには適さないのだ。
であるなら、Class 2よりClass 4、またはClass 6のSDHCを使えば、例え3,680×2,760ピクセル(標準圧縮)での撮影や、3,072×2,304ピクセルの低圧縮による撮影時にも連写は無理だが、レスポンスが良くなる理窟になる。
私の手元には現在従来のSDカードの他、今回購入した4GBのClass 2と同じく4GBのClass 4のSDHCがあるので、早速 Xacti DMX-HD2 で写真を撮る際のパフォーマンスを試してみることにした。
当然、スペック的にはClass 2とClass 4との差は前記したように2MB/Sec(16Mbps)と4MB/Sec(32Mbps)の倍違うことになるわけだが、実際の使用感ではどうなのだろうか...といった点に興味が湧いたわけである。
※左からこれまでのSDカード、SDHC 4GB Class 2、そしてSDHC 4GB Class 4の各カード
一番シンプルな比較として、同一の被写体に Xacti DMX-HD2 を向け、シャッターを切った瞬間から書き込みが終わるまでのタイムを計測すればよい理窟だが、残念ながらそれを正確に計る手段がない。
しかしXacti DMX-HD2 ではシャッターを押し、撮影後にマルチインジケータのランプが速く赤色で点滅する。このタイムを計るしかないが、点滅開始と点滅終了の前後の物理的なタイムラグがどれほどあるのかないのかも分からない(笑)。ましてや左手に Xacti DMX-HD2 を持ち、右手にデジタルストップウォッチを持ってやるアナログ的テストでは正確さはまったく期待できないが、まずはできることからやってみた...。
その結果、アクセススピードが明らかに違うことはわかった。SDカードではマルチインジケータのランプがシャッターを押した後、6回点滅する。しかしSDHCのClass 4では3回、Class 2では4回点滅する...。ランプの点滅はメディアに対するアクセスだから、それだけSDHCのClass 4は書き込み速度が速いことになる。
シャッターと同時にストップウォッチを押し、マルチインジケータのランプの点滅が終わった瞬間までを各3回計測してみた。まあ、目で認識してから手が動くわけで、くどいようだがまったく精度に期待は持てないが、こんなものかという見当はつくかも知れない(笑)。以下はその平均値である。
・SDカード 3.69秒
・SDHC Class 2 3.23秒
・SDHC Class 4 2.11秒
またこの時間だけ待てば次のシャッターが間違いなく切れるのかについては心許ないが、こうして比較してみると是非Class 6のメディアも試してみたくなる(爆)。この比較値はともかく、体感だとSDカードとSDHC Class 4では撮影から次の撮影までのレスポンスは倍程度の違いとして感じられる。したがって確かにできるだけClassの高いメディアを使う方がよいことをあらためて理解した次第である。
SDカードは一時期より大幅に価格が大幅に安くなった。しかしSDHCは信頼できるメーカーの製品はまだ高いこともあり、無闇にあれこれと買うわけにはいかない。ここはしばらく4GBのSDHC 2枚を使い回すことにしようと思う。
Home
これまでのSDメモリーカードの最大容量は2GBだったが、SDHCでは4GB以上の容量が実現可能となり、現在8GBの製品が販売されていることはご承知のとおりである。そして業界では2008年から2010年に至るスパンでは最大32GBの実現を目指しているという。
しかし現実問題、SDHCと従来のSDとどこがどれほど違うのだろうか...。
SDHCカードはハイビジョンカムコーダやデジタルカメラは勿論のこと、携帯電話やパソコンなどへの採用を想定しており、いわゆる記録データの大容量化と高速化の要求に合わせて登場したメディアである。
そのSDHCは、SDメモリー・カードの規格団体であるSD Card Associationが設定した新しい標準であり、従来の限界であった2GB容量を超える容量を実現し、かつ3つの速度クラス(Class 2、4、 6)を提供して最低の転送速度を保証している点がポイントである。そしてSDHCカードは、SDHC対応デバイスやSanyo、Nikon、Canon、Pentax、Casioなどの各社がSDHCをサポートするカメラ器機で認識できる。
重要なことはSDHCカードとSDカードは互換性がなく、従来のSDメモリーカード対応機器でSDHCメディアを利用することはできない。したがってこれまでのSDカードリーダーではSDHCは読めないわけだ。ただし、SDHC機器は従来のSDカードも利用できる。
さて、SDHCのClassとは前記したように速度の保証値を規定するものだが、スペック的にはClass 6は6MB/Secの転送速度を保証、Class 4は4MB/Sec(32Mbps)、そしてClass 2は2MB/Sec(16Mbps)と規定されているという。したがってClassの高いSDHCほどハイビジョンなど、高いパフォーマンスを求められる書き込みや読み込みスピードにコマ落ちといったことなく対応できるというわけだ。ただし例えば、SDHCのClass 6を使ったとしても、使用機器がClass 2までの対応なら、そのパフォーマンスは当然Class 2までのものになってしまう...。
なるほど...理窟はわかったが、今回手に入れたSanyo ハイビジョンムービー Xacti DMX-HD2 でムービーを撮ってみると実際にはSDHC Class 2で問題がないようなのだ...。もしそうなら製造メーカーにもよるものの、一般的には同容量のClass2よりClass 4の製品の方が高価なので、必要以上の高Classカードを使っても意味がないように思える。
ただし、例えばデジカメとして写真を撮ることを考えると(私はこちらの方が使用頻度が高い) Xacti DMX-HD2 は、シャッターを押してから次のシャッターを押せるのはSDHCに書き込み完了後である。ちなみに Xacti DMX-HD2 にもいわゆる連写モードがあるが、解像度が30万画素の640×480に限定されてしまうので、解像度の高い写真を撮るには適さないのだ。
であるなら、Class 2よりClass 4、またはClass 6のSDHCを使えば、例え3,680×2,760ピクセル(標準圧縮)での撮影や、3,072×2,304ピクセルの低圧縮による撮影時にも連写は無理だが、レスポンスが良くなる理窟になる。
私の手元には現在従来のSDカードの他、今回購入した4GBのClass 2と同じく4GBのClass 4のSDHCがあるので、早速 Xacti DMX-HD2 で写真を撮る際のパフォーマンスを試してみることにした。
当然、スペック的にはClass 2とClass 4との差は前記したように2MB/Sec(16Mbps)と4MB/Sec(32Mbps)の倍違うことになるわけだが、実際の使用感ではどうなのだろうか...といった点に興味が湧いたわけである。
※左からこれまでのSDカード、SDHC 4GB Class 2、そしてSDHC 4GB Class 4の各カード
一番シンプルな比較として、同一の被写体に Xacti DMX-HD2 を向け、シャッターを切った瞬間から書き込みが終わるまでのタイムを計測すればよい理窟だが、残念ながらそれを正確に計る手段がない。
しかしXacti DMX-HD2 ではシャッターを押し、撮影後にマルチインジケータのランプが速く赤色で点滅する。このタイムを計るしかないが、点滅開始と点滅終了の前後の物理的なタイムラグがどれほどあるのかないのかも分からない(笑)。ましてや左手に Xacti DMX-HD2 を持ち、右手にデジタルストップウォッチを持ってやるアナログ的テストでは正確さはまったく期待できないが、まずはできることからやってみた...。
その結果、アクセススピードが明らかに違うことはわかった。SDカードではマルチインジケータのランプがシャッターを押した後、6回点滅する。しかしSDHCのClass 4では3回、Class 2では4回点滅する...。ランプの点滅はメディアに対するアクセスだから、それだけSDHCのClass 4は書き込み速度が速いことになる。
シャッターと同時にストップウォッチを押し、マルチインジケータのランプの点滅が終わった瞬間までを各3回計測してみた。まあ、目で認識してから手が動くわけで、くどいようだがまったく精度に期待は持てないが、こんなものかという見当はつくかも知れない(笑)。以下はその平均値である。
・SDカード 3.69秒
・SDHC Class 2 3.23秒
・SDHC Class 4 2.11秒
またこの時間だけ待てば次のシャッターが間違いなく切れるのかについては心許ないが、こうして比較してみると是非Class 6のメディアも試してみたくなる(爆)。この比較値はともかく、体感だとSDカードとSDHC Class 4では撮影から次の撮影までのレスポンスは倍程度の違いとして感じられる。したがって確かにできるだけClassの高いメディアを使う方がよいことをあらためて理解した次第である。
SDカードは一時期より大幅に価格が大幅に安くなった。しかしSDHCは信頼できるメーカーの製品はまだ高いこともあり、無闇にあれこれと買うわけにはいかない。ここはしばらく4GBのSDHC 2枚を使い回すことにしようと思う。
Home
意外と知られていない? カラーパネルの使い方
2007/04/03 19:36
先日友人との会話で気がついたが、Mac OS
Xのさまざまなアプリでお世話になる「カラーパネル」の話しになったとき、大きな違和感を感じた。それは私が基本中の基本だと思っていたことに友人はまったく頓着していなかったからだ(笑)。
「カラーパネルってこんな機能もあるんだぞ...」という話に「へえ〜」と関心された(笑)。無論「カラーパネル」に精通したからといって、どうということもないが便利なことは覚えていた方がよいではないか。
「カラーパネル」というとグラフィックソフト系につきもののように思われている方もいるようだが、テキストエディットやフォントパネルにも「カラーパネル」は機能する。無論それはフォントカラーを指定するためだ。またアプリケーションによっては「カラーパネル」の仕様にも違いがあったり、オリジナルの機能がプラスされていたりするが、基本的な使い方はほとんど変わらない。
※左がテキストエディットなどに使われている標準「カラーパネル」。右はOmniGraffle Pro.の「カラーパネル」例
ここでは基本的な...という意味でテキストエディットから呼び出した「カラーパネル」を例にして話を進めさせていただくが「カラーパネル」の使命は申し上げるまでもなく、任意のカラーを選択して目的の作業に反映させるためだ。
まずカラーの選び方はウィンドウタイトル下にある左から「カラーホイール」「カラーつまみ」「カラーパレット」「イメージパレット」そして「クレヨン」と名付けられている各パレットから指定する。それらの5種類からひとつを選択してカラー指定を行うが、勿論それぞれを切替ながら使ってもよい。
問題はなぜこうした5種類の選択肢があるかを理解しておく必要がある。ここではすべての機能について詳細な解説は省くが、それぞれ存在する意味があるわけだ。
例えば「カラーパレット」にすると「リスト」というポップアップメニューが追加されているのがわかるだろう。その中の「Webセーフカラー」を選べばウインドウズとマッキントッシュのシステムパレットに共通するカラーが一覧で確認できるばかりか、検索もできる。
この「Webセーフカラー」選びはWebページを作る場合に必須であることはご承知の通りだ。したがってこの小さな「カラーパネル」も使い方を工夫すればなかなか頼もしいツールになるわけである。
※「カラーパレット」による「Webセーフカラー」の例
前記した友人は「カラーホイール」しか使ったことがないそうだが、カラー選択はホイールからカラーを選び、目的のアプリにそのカラーを指定しているとのこと。それはそれで基本だが、選択カラーの表示エリア左にあるルーペ機能など使ったことがないという(笑)。もったいないことだ...。
このルーペアイコンを一度でもクリックすれば、それが何を意味するのかは分かるだろうし、時として大変便利なツールになるに違いない。
※ルーペ機能をONにするとマウスポインタにルーペが付属する
実際にルーペアイコンをクリックするとマウスポインタに大きめのルーペが付属する。このルーペでモニター上をあれこれ覗いてみると新しい発見もあるかも知れない...。
例えば私たちは1,677万色フルカラーの環境でテキストエディタの「Jedit X」を何気なく使っているが、そこに入力したテキストの一文字づつにルーペを合わせてみれば、それらはアンチエイリアス処理の意味も含めてブラック一色ではないことに気づくはずだ。
それはともかくこのルーペは、デスクトップをはじめ、現在オープンされているモニター上のあらゆる場所の表示カラーをピックアップすることができる。
※テキストエディタの「Jedit X」で入力したテキストをルーペで見ると...
さらに、この「カラーパネル」最下段にある初期設定16個表示のよく使うカラーを登録しておくエリアも、そのフレーム下の丸ポッチを真下に引き下げれば、最大160個の登録・閲覧・指定ができるように表示が拡大される。さらに「カラーパネル」の横サイズを最大にすれば、300個の登録・閲覧・指定が可能になる。
※よく使うカラーは最大300個が可能だ
基本的な機能過ぎて、有り難みがないかも知れないが「カラーパネル」ひとつにもMac OS Xの気概が溢れていると思えば楽しいではないか！
万一友人と同じくこうした使い方をご存じないユーザーがいらっしゃったなら、今日から是非活用していただきたい。
Home
「カラーパネルってこんな機能もあるんだぞ...」という話に「へえ〜」と関心された(笑)。無論「カラーパネル」に精通したからといって、どうということもないが便利なことは覚えていた方がよいではないか。
「カラーパネル」というとグラフィックソフト系につきもののように思われている方もいるようだが、テキストエディットやフォントパネルにも「カラーパネル」は機能する。無論それはフォントカラーを指定するためだ。またアプリケーションによっては「カラーパネル」の仕様にも違いがあったり、オリジナルの機能がプラスされていたりするが、基本的な使い方はほとんど変わらない。
※左がテキストエディットなどに使われている標準「カラーパネル」。右はOmniGraffle Pro.の「カラーパネル」例
ここでは基本的な...という意味でテキストエディットから呼び出した「カラーパネル」を例にして話を進めさせていただくが「カラーパネル」の使命は申し上げるまでもなく、任意のカラーを選択して目的の作業に反映させるためだ。
まずカラーの選び方はウィンドウタイトル下にある左から「カラーホイール」「カラーつまみ」「カラーパレット」「イメージパレット」そして「クレヨン」と名付けられている各パレットから指定する。それらの5種類からひとつを選択してカラー指定を行うが、勿論それぞれを切替ながら使ってもよい。
問題はなぜこうした5種類の選択肢があるかを理解しておく必要がある。ここではすべての機能について詳細な解説は省くが、それぞれ存在する意味があるわけだ。
例えば「カラーパレット」にすると「リスト」というポップアップメニューが追加されているのがわかるだろう。その中の「Webセーフカラー」を選べばウインドウズとマッキントッシュのシステムパレットに共通するカラーが一覧で確認できるばかりか、検索もできる。
この「Webセーフカラー」選びはWebページを作る場合に必須であることはご承知の通りだ。したがってこの小さな「カラーパネル」も使い方を工夫すればなかなか頼もしいツールになるわけである。
※「カラーパレット」による「Webセーフカラー」の例
前記した友人は「カラーホイール」しか使ったことがないそうだが、カラー選択はホイールからカラーを選び、目的のアプリにそのカラーを指定しているとのこと。それはそれで基本だが、選択カラーの表示エリア左にあるルーペ機能など使ったことがないという(笑)。もったいないことだ...。
このルーペアイコンを一度でもクリックすれば、それが何を意味するのかは分かるだろうし、時として大変便利なツールになるに違いない。
※ルーペ機能をONにするとマウスポインタにルーペが付属する
実際にルーペアイコンをクリックするとマウスポインタに大きめのルーペが付属する。このルーペでモニター上をあれこれ覗いてみると新しい発見もあるかも知れない...。
例えば私たちは1,677万色フルカラーの環境でテキストエディタの「Jedit X」を何気なく使っているが、そこに入力したテキストの一文字づつにルーペを合わせてみれば、それらはアンチエイリアス処理の意味も含めてブラック一色ではないことに気づくはずだ。
それはともかくこのルーペは、デスクトップをはじめ、現在オープンされているモニター上のあらゆる場所の表示カラーをピックアップすることができる。
※テキストエディタの「Jedit X」で入力したテキストをルーペで見ると...
さらに、この「カラーパネル」最下段にある初期設定16個表示のよく使うカラーを登録しておくエリアも、そのフレーム下の丸ポッチを真下に引き下げれば、最大160個の登録・閲覧・指定ができるように表示が拡大される。さらに「カラーパネル」の横サイズを最大にすれば、300個の登録・閲覧・指定が可能になる。
※よく使うカラーは最大300個が可能だ
基本的な機能過ぎて、有り難みがないかも知れないが「カラーパネル」ひとつにもMac OS Xの気概が溢れていると思えば楽しいではないか！
万一友人と同じくこうした使い方をご存じないユーザーがいらっしゃったなら、今日から是非活用していただきたい。
Home