ビデオブログ向けビデオ制作というもの

Channel 9日本版サポートブログに書いた方がいいのかもしれませんが、ちょっと視点を変えて考えるためにこちらに書きます。 ビデオブログという新しいメディアは、その運営を継続するにはかなり努力が必要ではないかと感じるようになってきました。文字を主体とするブログは、思いついたら書くことができますが、動画を主体とするブログは、思いついたら撮影すればいいってものでもなさそうだからです。また、配信するビデオについてもいろいろと考慮する必要があるかと思います。 ビデオブロガーになろうとデジタルビデオの制作をはじめて何度か試行錯誤を繰り返していると、ことは単純ではないことがわかってきます。いくつかの理由が挙げられます。 ・投稿するビデオには何らかのテーマが必要である 文字に変わって動画で物事を伝えていくために、あるテーマのもと、会話なり場面がつながっていかないと困る ・著作権保護や肖像権保護を念頭におく必要がある 個人的用途のビデオと異なり、簡単に音楽の挿入はできないし、プライバシーを守り、出演許可を得てない人の映像が放映されることを避けなければならない ・ネットワークを利用して配信するために帯域幅を無視できない たとえハイビジョンで撮影したとしても、ある程度の解像度に下げる必要があるし、いろんな回線でネットワークを利用している視聴者のことを考えなければならない ・1テイクで全ての場面が撮影できるわけではない 編集せずに撮影したビデオを垂れ流しにすることはほとんど考えられない ・映像や音声がクリアでないビデオは見ているのがつらい 照明条件、ビデオの明るさ、音響というものを無視できない ここで注意してほしいのは、単なる動画共有とビデオブログは分けて考えたほうがいいということです。思いつくまま興味深い動画を共有する場合はストーリーとか品質とかあまり関係なく、単に面白ければよい、という可能性もあるからです。ビデオブログは文字に変わる記録ですから、投稿される動画には投稿者が意図している何らかの意味を伝達することが必要だと思います。 デジタル技術によって、ビデオの編集はリニア編集からノンリニア編集になって、ビデオの制作は素材を好きなように組み合わせることが簡単になっています。たとえばインタビューの記録内容を、撮影後の編集作業で順番を入れ替えることもできますし、必要でない部分を削除することも容易です。しかし、いざ編集を始めると、素材そのものの品質や全体のストーリーは無視できなくなってきます。また編集における加工もきりがなく、編集者がどこかで作業の終結を認めないといけません。 何にしても素材の集め方はかなり重要です。解像度を下げて配信することを前提に考えると、解像度が高くないと理解できない映像を撮影することは避けなければなりません。たとえば、ソフトウェアのデモンストレーションをビデオに撮影することを考えれば、文字の大きさを調整できるなら大き目のものに変更する、調整ができないならズームを使って撮影する、といったことを念頭において向き合う必要があります。またコンピュータのディスプレイやプロジェクターから投影された画像を撮影する際は、ホワイトバランスのことを考えてカメラの調整をしなければなりません。屋内のホワイトバランスでコンピュータの画面を撮影するとどうしても青みが強い映像になってしまいます。よくテレビコマーシャルなどでディスプレイ部分の映像について「はめ込み合成」と書かれていますが、これは、ビデオカメラでテレビやコンピュータのディスプレイを撮影した場合にディスプレイの内側と外側の色を同時に再現することができないからです。たとえば、動画なり静止画を利用したプレゼンテーションを行っている様子をプレゼンター含めビデオカメラで撮影しようとすれば、色再現性を無視すれば別ですが撮影内容の色再現性を考慮すると安価な民生用のビデオカメラではまず太刀打ちできません。また普通に人物を撮影するにしても、屋内での撮影の場合、単純ではありません。たいていの場合、屋内の撮影は照明条件が悪いことが多いからです。悪い照明条件をよくするためには、撮影環境に照明機材を持ち込んで条件を変えてしまうことが求められます。 映像だけでなく音声もいろんな課題が出てきます。音声の収録を含めて撮影用の空間がきちんと確保できるということはまず考えづらいです。たとえば、講演会場などでのプレゼンの様子をビデオに収めようとした場合、いかに音声をクリアに記録するかというのは、単純な問題ではありません。プレゼンターのマイク用の音響装置がきちんと用意されていて、そこから音声のラインが引き込めれば問題なく録音ができると思いますが、そうでない場合は周辺の雑音を拾うことを避けられません。マイクの指向性の高さやS/N比も重要になってきます。また会話の収録などしゃべっている人が複数に分かれる場合、マイクをうまく使う必要が出てきます。 いろいろ書いていますが、上を見たらきりがないので、最後には適度なところでまとめる、ということも考慮する必要があります。 気軽に動画が撮影できる時代なので、個人としてビデオ日記にチャレンジするのは難しくないですが、企業としてビデオブログに向かうときは手軽さだけで進まない方がよいかもしれません。 Channel 9日本版は、そんなわけで今でも試験放送中。

0

低レベルAPIを叩いてプログラムすることの醍醐味

.NET Frameworkのマネージドコードしか体験していない開発者の方もいらっしゃるかと思いますが、Windows APIやC言語のランタイムライブラリの低レベルAPI(ここでいうレベルとは低いほど決め細やかな操作ができる一方で書かなければならないコード量は増えることを意味します)を駆使してシステム構築している人は海外に限らず日本においてもいます。 皆さんは、クリティカルな処理や高いパフォーマンスを要求される処理を実装する場面に出会ったことがあるでしょうか。 低レベルAPIのよさは、まさにクリティカルでハイパフォーマンスを要求される場面で真価を発揮します。 いまどきはC言語プログラマの人口が減少傾向にあるかもしれませんが、C言語のプログラマであれば、たとえばファイルの入出力に2つのレベルの関数が用意されていることを知っていると思います。ファイルポインタを利用するfopen()でファイルを開くタイプと、ハンドルを利用するopen()。ハンドルとかポインタとかいう用語にピンと来ない方もいらっしゃるかもしれません。 .NET Frameworkの良い点は、低レベルAPIを意識することなく、オブジェクト指向のクラスライブラリで面倒な部分を隠蔽化(カプセル化)している点です。一方で、低レベルAPIを叩いてアプリケーションを構築している経験者であれば、内部で何が行われているかが定かでない部分もあって、マネージドコードをすんなり受け入れられないということもあるかもしれません。.NET Frameworkのスタックは、COMサーバにより実現されているということを認識している人もいればそうでない人もいます。細かいことを突き詰めていけばきりがないのですが、一種のプロセス間通信によりアプリケーションの実行されているリソースが他のアプリケーションに影響を及ぼさないように管理できたり、メモリやスレッドなどのシステムリソースを.NET Frameworkの中で管理していることで、細かな低レベルのAPIを知らなくとも(特にメモリ管理)アプリケーションを開発できるというのがマネージドコードの良い面であります。 しかしながら、いくらマネージドと言えど、開発者が低レベルのレイヤーで何が行われているかをまったく知らなくてよいといえるでしょうか。 推測の域を出ないことを事前に断った上で、マネージドコードをうまく使えている開発者というのは、実は低レベルのAPIの中で何が行われているかを事前に頭の中でエミュレートできる人ではないかと思っています。エミュレートしている中でマネージドコードのリスクを管理できる人とも言えるかもしれません。リスクというと否定的な感じを受ける方がいらっしゃるかもしれませんが、システム開発において、開発者は常にリスク(予期せぬ出来事など仕事の進捗に影響を及ぼす事象)にアンテナを高くしておく必要があるかと思います。 たとえば、ガベージコレクタ(GC)という機構がマネージドコードを処理する言語ランタイムに備わっています。これは.NET FrameworkのCLRだけに限らず、Java VMにおいても同様にGCの機構が用意されています。GCのメリットは、メモリ管理においてポインタの概念から開発者を解放することに尽きると思いますが、果たしてGCにすべてを任せてアプリケーションがまともに動作するでしょうか。今から5年くらい前の話になりますが、私は業務命令により、とある企業のJavaのサーバアプリケーションのパフォーマンスのトラブルシュートを担当したことがあります。そのアプリケーション開発は、日本人が仕様を決め、実装はオフショアということでインドの企業に業務委託されていたものでした。現場に向かい、現象を観察し、パフォーマンスモニタで必要なメトリクスを測定した上で、ソースコードを見なくとも、問題が予想できました。「これは、GCがパンクしている・・・」と。その後、Javaのソースコードの現物を見ながら、即座にループを行っている部分をgrepで抽出しました。いくつかの怪しいループがgrepだけで見つかりました。そして、そのループの内部を見たら・・・。 「あのー、この1万回以上の繰り返しの中で、インスタンス生成が繰り返されて、不要なインスタンスが解放されていないのは何故ですか?」 Javaの処理系で文字列を操作するためにStringというクラスがあります。これは基本データ型ではないので、利用においてインスタンス生成がなされ、GCの管理下にメモリが置かれます。し・か・し、Java VMが起動する際のメモリヒープ量には限界があります。(注:Java VMのスタートアップ時のパラメータにより決定されます)この限度を超えたメモリが消費され、GCがパニック状態になってしまうとどうなるか想像できますか?これは非常に面白い現象なのですが、低レベルAPIで開発経験のある方なら「そんなの当然だろ!」って思うかもしれません。何が起こるかというと、限られたメモリヒープを死守すべくGCが不要なインスタンス(オブジェクト、つまりメモリ空間)を解放しようとするのですが、GCから見てそれが不要なのかどうか判断ができない一方でアプリケーションは繰り返し処理によってメモリをVMに要求します。メモリリソースを解放しようと努力するGCとメモリリソースを要求するアプリケーションに衝突が発生するわけです。この結果、WindowsでタスクマネージャでJava VMを監視しているとCPU利用率がほぼ100%に達します。これにより、アプリケーションがタスクマネージャ上のプロセスとみなされていても、ユーザエクスペリエンスとしては、フリーズしている状態に見えます。GCの落とし穴がここにあるわけです。この事象はJavaに限った話ではなく、GCを有するオブジェクト指向の処理系すべてに共通するリスクです。 話を戻し、低レベルAPIを叩くことの意義というか、OSの上でアプリケーションを開発する上で必要な知識というのは、低レベルのAPIを含めて、アプリケーション層の下位レイヤーで何が行われているかを知っておくことではないかと、今更ながら思います。 .NET Frameworkが3.0に進化する過程でAPIセットには大きな変化があります。その一方で、Windows Vistaにおける低レベルAPIにおける制約が変わっていることにいち早く気がついている開発者もいます。Webアプリケーション、Webサービス、スマートクライアント・・・、ある程度、簡単に可視化できるものは開発効率重視に走っていくことは悪いことではないと思います。しかし、長時間の稼動でクラッシュしない、高トラフィックになったときにきちんと対処できる・・・、そんなアプリケーションを実装しようと思ったら、間違いなく、アプリケーションが稼動している環境のブロックダイアグラムが描けないと困ると思います。 確かに低レベルAPIを叩くことは容易ではないでしょう。でも開発者と名乗る人々には、一度でもいいから高水準のAPIを使わないで同じことを低水準のAPIで実装するということにチャレンジしてもらいたいと思います。その上で、OSが提供する機能を深く理解してもらい、高水準でよい部分は高レベルのAPI、またはクラスライブラリで、一方で、クリティカルな部分は低水準のAPIまたはそれらの機能をラップしたコンポーネント開発をすることで、安全に運用でき、リスクを管理できるような開発を行ってもらいたいと感じます。 そういう努力を積み重ねていれば、たとえば排他制御(Exclusive Control)というものを難しく考えずに単純なものになぞらえて、システムプログラミングができるようになると思います。なぜ、セマフォ、ミューテクス(Mutex)、クリティカルセクション、などという排他制御のための機構が用意されているのか、何故、リソースを利用する前にロックしなければならない状況があるのか、同時実行制御にどんな問題があるのか、頭の中でエミュレートできるようになると思います。また、プロセスが起動してスタートアッププロセスが起動し、アプリケーションが実行される準備が整うまでに何が行われているか、あるいはアプリケーションが終了する際にどんなことが行われるか、またどんなことを開発者はきちんと処理しなければならないのか、プロセス・スレッド・メモリ、ネットワークやストレージを含めたコンピュータのリソース、CPUの優先度、仮想メモリ機構が何故用意されているのか、何故、サービスとデスクトップとの対話というのが単純なものではないのか、インプロセスではなくアウトプロセスでの通信において、ACLを含めた管理が必要なのか、・・・いろんなことに対して、視野が広がる(嫌でも視野を広げざるを得ない・・・というのが正解かもしれない)と思います。 ・・・ 昨日、つくばで、ソフトイーサの開発を行った登さんとマイクロソフト側の及川さん(Windows開発統括部)との対談をChannel 9のコンテンツとして撮影しながらぐるぐる考えていたことをブログに残してみました。。。 # 今やほとんどビデオ屋さんとなっている私、大西ですが、これでも元はDeveloperなんですぅ (^^;  

1

無いものは作る・・・、そして仕事の95%は準備期間だったりする

昨日、はがきスタジオ開発チームの取材をしていて、はっと思い出したこと。 「無いものねだりするのではなく、無いものは作ってしまえばいい!」という私自身の開発者時代の信条です。 最近はインターネットが容易に使えるため、昔のように「無いものを作る」よりも「どこかにあるかもしれないから探してみよう」と検索エンジンに頼るケースは少なくないと思います。それで目的に合致するものが見つかればいいのでしょうが、ある程度のスキルレベルに達している人々の場合、多分、目的とするものは見つからないのではないかと想像しています。 それは何故か・・・、要求されているレベルが非常に高度な場合、前例がない開発に直面することがあるからです。 MSDNの膨大なライブラリを検索しても見つからないような機能、つまりWindows APIや言語のランタイムライブラリに用意されていない機能要求を突きつけられたとき、あなただったらどうしますか。 はがきスタジオという製品は一般のお客様向けであり、年賀状や暑中見舞いなどのはがき印刷のための準備をできるだけ短時間に行えるように設計されています。開発担当者はお客様がマニュアルを読まなくともはがきのデザインができるように、ユーザインターフェイスを設計し、実装しています。 私自身もはがきスタジオのユーザなのですが、今回、はがきスタジオの開発担当者と話をして、「おぉ!」と気がつかされたことがありました。製品をお持ちの方でないとわからないかもしれませんが、実ははがきスタジオのユーザインターフェイスは既存のWindowsのコントロールを組み合わせて作られていない、完全にカスタムにGUIをレンダリングしている機能が満載なのです。マイクロソフト内部に既存のGUIライブラリがあったわけでもなく、完全に開発担当者が要求に応じたUIを「無いものは作る」というエンジニアリングによって調布の技術センターで生み出されたものです。 私がプログラマの駆け出しの頃、よくこんな言葉を耳にしました。 「こんなのできっこないよ、だってライブラリにもないし、見たこともないし、要求が間違っているよ・・・」、さて、皆さんはどうでしょう。 要求を否定してしまったら、そこから先に進むことは一生できないでしょう。 エンジニアリングの極意は、「ともかく動かすこと」、それに尽きるのではないでしょうか。文句を言ったり批判や否定するのは簡単です。前例がない場合は特にそうでしょう。しかし、前例がない状況に直面しているエンジニアは実はかなりラッキーなのです。ここぞとばかりに知識を知恵に変える最大のチャンスだからです。 でもその道を進むのは簡単なことではありません。数多くの仮説に基づいた実験を繰り返して、少しずつ要求を満たすものを作っていく必要があるからです。これはかなり地道な作業の繰り返しになります。スクラップ&ビルドというのも不思議ではないでしょう。この忍耐を要求される試行錯誤とうまく付き合えるかどうかで、エンジニアの人生は大きく変わるものだと思います。 非常に地味ではあるのですが、Plan – Do – Seeというサイクルの繰り返しを暗黙のうちにこなせるようになってくると、実は仕事というものは、仕事全体を100%として95%くらいが準備期間ではないかと感じるようになるかもしれません。 えっ?5%で完了するの?と思われる方もいるかもしれません。実はそうではなくて、3%で完了すると思います。残りの1%はfine tune、より成果を洗練させるための部分、最後の1%は全体の振り返りです。 どうして3%で?、それは、準備期間の中での試行錯誤で、ソフトウェア開発であれば多くの問題が解決できるからです。また多くのテストプログラムが必然的に作られ、多くの実証済みの知識が蓄積されることも忘れてはいけません。 反対に捉えれば、準備を怠れば怠るほど、時間が非情に過ぎるだけで、本質的な仕事は進みません。当てのない作業を繰り返すだけになってしまうからです。 「急がば回れ」という言葉があります。とんでもない要求が突きつけられたとき、非常に短期で完成させなければいけない開発案件を突きつけられたとき、焦って行動に入る前に、まず準備する、ということを考えてみてください。より高度な領域に進む人は、モレなく無駄なく重複なく、ロジカルシンキングにおけるMECEということについて学ぶことも重要かと思います。 忙しそうにしていなくて、超人的なパフォーマンスを発揮する人々は、たぶん、準備(あるいは計画)を考えて行動していると思います。その裏に数多くの努力があることはいうまでもありません。 無から有を創造する、これぞソフトウェアエンジニアリングの醍醐味です。 無いものは作る、機会があれば皆さんも考えてみてください。また、普段の仕事を振り返って、皆さんがどれだけ準備に時間を割いているかを測定してみるのもよいかと思います。

0

動画配信による情報伝達のパワー

百聞は一見に如かず、うまい言葉だと思います。 IT業界に限らず、情報伝達を、特にネットワーク上で動画を利用することによって効率的に行うことがとても重要だと最近感じます。 本業であるChannel 9日本版の仕事を通じて、私自身、物凄い量の情報に触れ、その一部はChannel 9のビデオブログとして公開しはじめていますが、短時間でポイントを押えてビデオを作成し、それをネットで流すことの意義がChannel 9を始める前よりもよくわかるようになってきました。 現在のWebプラットフォームにおいて、マッシュアップやポッドキャスティング、いろんな手法が取り入れられて情報の取捨選択は複雑になりつつあるようにも思える一方、マスマーケットに訴えかけるマーケティングからロングテールへのアプローチへのシフトを見ていると、情報発信のあり方は、一人でもいいから「共感」を作り出すことに集中する方がいいのではないかと感じています。 この共感を作り出す上で、文字情報だけでの伝達はかなり大変です。しかし、動画と文字情報をうまく組み合わせることで、「へー、なるほど」と思っていただくことができるのではないかと最近感じています。言うは簡単、行うは難しではありますが・・・。 ノンリニア編集システムが安価に手に入れられるこの時代、デジタルビデオカメラを使えば、簡単にビデオが作れます。またFlashの技術を使ったビデオ共有サービスが増えており、様々なビデオファイルをサーバ側で変換して公開できる時代になっています。 ・・・でも、どんなビデオ作品が受け入れられるか、そういうことを考えてきちんと制作されたコンテンツが必ずしもいいのかどうか、よくわかりません。商用作品はマーケティング面を含めたプランニングの下、計画的にビデオが作られるわけですが、あたりもあればはずれもある・・・、これはビジネスだから仕方のないことでしょう。それなりに数多く見てもらおうとするならば、ターゲットとなる視聴者を想定してシナリオを作る必要があります。しかし、想定したシナリオ通りに視聴者が共感してくれるかどうかは予想できません。なかなか難しいところではあります。 いろいろと課題はあるにせよ、動画配信による情報伝達のパワーは、文字よりも強力だと思います。 そんなわけで、Channel 9をやりながらも、他の人をインタビューするだけでなくて、自作自演で動画を使って何か新しい情報発信ができないかを考えていたりします。本業の傍ら、エバンジェリストとして何か変わった試みができる時間を作りたいと思う今日この頃です。  

1

幅広い視野で物事を見通せるエンジニアでありたい

Channel 9の活動を始めてマイクロソフトディベロップメント株式会社に6/12からほぼ毎日、夕方18:00-20:00のヒアリングを行ってきています。非常に興味深い毎日でありながら、その一方で基本的なことに立ち返るよいきっかけとなっています。 私自身はソフトウェア業界での仕事は18年目です。もともとパソコンが好きだったわけではなく、実はコンピュータの仕事なんかするものかと考えていた人だったりします。17年を超える経験の中で、私のコアコンピタンスは何かと考えると、私自身がデベロッパーであるということだと思います。無から有を作り出す、その面白さのとりこになったのは、初心者からスタートしてC言語を学び、1ヶ月くらい過ぎたころの話です。当時は、ポインタの使い方を誤って、何度もコンピュータを暴走させた記憶があります。反面、コンピュータを異常な状態にすることを体験しながら、C言語の良さを学んできたようにも思います。当時のパソコンのリソースは、非常に貧弱でした。CPUは低速、MS-DOS上で利用できるコンベンショナルメモリが実質400KB以下だったり、ハードディスクが存在せず、フロッピーブートでアプリケーション込みでの実行なんてことも珍しくはありませんでした。MBなんて夢のような大きさだったし、GBなんてありえねーって思っていました。 でも今は、ネットワークはギガビット、メモリもGB、ストレージはTB、CPUクロックはGHz、GPUも超高速になり、そこそこの予算でも自作レベルならスーパーマシンが手に入ってしまいます。 そんな時代に、ソフトウェアエンジニアのスキルレベルがあまり高くならなく、ひとりのカバー範囲が非常に狭くなっている最近の傾向に、一人のデベロッパー経験者として憂いを感じています。 例えば、DeveloperとIT Proという言葉を分けて使っています。マイクロソフト自体も情報の提供の仕方をMSDNとTechNetの二つのブランドで行っています。欧米においては、IT Proという職種がプロフェッショナルとしての地位を認められて給与水準もスキルに応じて高くなるため、マイクロソフトの製品技術の場合、Microsoft Certified Professional、すなわちMCPの資格、特に上位の有資格者というのは仕事をする上で優遇される可能性が高いです。しかし、日本に目を向けるとそうとは言い切れません。ではそこにどんなギャップがあるのだろうかと勝手に想像してみます。 もともと日本においても、計算機のエンジニアというのは、開発も運用もこなすエキスパートであったと思います。今の言葉で言うDeveloperとIT Proを兼任していたようなものです。言い方を変えると、コンピュータと会話する手段をきちんと持っていて、目的に合わせてコンピュータを利用することを限られたリソースの中で実現する、考えてみれば至極当然のことをこなしていたわけです。これはメインフレームのような大型コンピュータに限らず、PCベースのDOSシステムにおいても同じだったと思います。コンピュータリソースが貧弱だった時代は、開発者は1バイトでも少なくプログラムサイズを削る努力を行い、実行時のフットプリントを含めて、利用可能な範囲のリソースの中で最大限の効果をもたらすシステムを設計し、実装してきたと思います。特にDOSベースでネットワークを構築していた時代にシステムを開発していた人は、様々な制約の中で仕様を定め、現在では考えられないようなシステムチューニングを施していたと思います。(私もその一人だったりします) DOSからWindows、TCP/IPの浸透、ネットワークの高速化、WWWサービスの増加、Webベースのシステム開発へのパラダイムシフト、Webサービスを複合したSOAへのシフト、FTTHやMIMOといった高速ネットワークの低価格化と民生化、さらにはモバイルアクセスの増大。利用可能な技術は確かに革新を遂げています。 では、問題。 大規模Webアプリケーションをきちんと設計できるアーキテクト(あるいはデベロッパー・・・私としてはこっちの方がしっくりくるけど)になるためには、何を知っていなければならないのでしょうか。 似たような問題をC/S(クライアントサーバ)全盛の時に、ネット系のコミュニティで提起したことを思い出します。 なんだかんだ言っても、DeveloperとIT Proと両方の素養を持っていて、ハードウェアからネットワーク(機器構成含む)を含めて、OS、ネイティブAPI、メモリマネジメント、同時アクセス、トランザクション、耐障害性、セキュリティ、データベース設計および管理、コンポーネント設計、分散処理、スレッド、排他制御(クリティカルセクション、ミューテクスなど)、QoS、SLA、クラスタリング、バックアップ&リストア、HTML、CSS、XML・・・、俯瞰レベルからコンピュータ内で起こっている細かな処理やデータ伝送処理まで、様々なことを見渡せなければならないように思います。ストレージが巨大になれば、SANの構築や運用、WWナンバーの管理やRAID構成、ストレージ仮想化、さらに複雑な技術が要求されます。 で、そんな広範囲なことを見渡せる人って、例えば日本にどれだけいるんでしょ?という疑問(ならびに興味)がわきます。 じゃあ、お前はどうなんだ?、という意見もあるでしょう。まずは、こちらからアプローチしてみましょう。 繰り返しになりますが、1989年4月、初心者からのスタートで私はC言語のプログラマとなりました。その後、数々のプロジェクトを通じて、COMポート(RS-232-C)やI/Oポート経由の制御を通じてネットワークプロトコルなるものを学ぶ機会に出会いました。その後、拡張ボードの制御をDOSのコンベンショナルメモリのバンク切り替えを通じて、FARポインタを駆使しながら理解していきました。バイナリモードもテキストモード、どちらでもファイルアクセスはできるようになり、データの永続化ということを学びました。それでは足りず、検索容易性の追求ということで、当時データベース用のライブラリを買ってもらえなかったゆえに、自らデータベースもどきのデータアクセスライブラリを作ったりもしました。SHARE.EXEのプロセスを利用し、ファイルアクセスの排他制御を理解していきました。やがて、ISAMをベースとするDBFというファイル形式を簡単に取り扱えるdBase互換処理系(通称Xbase言語)に出会い、データアクセスとプログラムロジックが一体で記述できる言語にとことんほれ込みました。Windowsが登場し、DDEでのアプリケーション連携だけでなく、OLEの技術でのアプリケーション連携に出会いました。しかしそれだけでは目的を達成しづらく、メッセージループのフック(目的としてはハック)を覚えました。やがて先進的なオブジェクト指向言語に出会い、ダイナミックバインドの強力な部分にほれ込みました。同時にトランザクションを含めて、異機種混合の中でのデータベースアクセス技術をODBC 2.0時代にとことん追求しました。WWWサービスについては、IIS1.0のベータの時期から学び、CGI(Common Gateway Interface)を利用して、Xbase言語で作成したアプリケーションを動的に呼び出して、動的なWebページを作成することを学びました。IISのASP(Active Server Pages)サポートにもすぐに飛びつきました。その後、マイクロソフトがOLEDBを投入し、時代がUDA(Universal Data Access)になろうとし、ADOとMTSを追いかけました。ここまでが1999年くらいまでの話です。 そこから先が、日本のトレンドとかなり違った動きになっています。2000年4月から、Enterprise Application Integration、Business Intelligence、Portal、といった情報管理系の技術にどっぷりはまりました。Enterprise Application Integrationの世界においては、OLEDB、XML、MAPI、WBEM、EJB、COM、LDAP、ODB、様々な情報ソースを集約し、C++、COM、あるいはJavaのAPIで情報アクセスできる技術を中核とした製品に触れ、それをベースにService Managementという世界に足を踏み入れました。ソフトウェアをサービスと捉え、利用した分を測定し、課金(社内システムであればコスト配賦)することができる製品の国際化ならびに日本語化に関与しました。この時に、動的に生成されるXMLからHTMLをレンダリングする技術や、LDAPサーバに格納されているユーザインターフェイス要素を元に動的にWebアプリケーションのメニューを構築する技術、計測された値に対して、サービスレベルの目標値(Service Level Objective: SLO)を設定し、複数のSLOを組み合わせて計算することからSLA (Service Level Agreement)を導き出すためのSLAエンジンという技術にも触れることになりました。その製品のWebアプリケーションのユーザインターフェイスに関する文字列をXMLにまとめることでの国際化、ローカライズの簡便化なんかを推進したのが2001年初頭。ラウンチは9ヵ月後。その間に学んだことは数知れず。2002年初頭にはその製品のアップグレードにおいて、コアテクノロジーの徹底理解だけではなく、Webベースのレポートエンジンの多言語対応について、議論した時期もありました。JavaScriptとWebサービスの組み合わせ、今でいうところのAjaxによる開発はその頃に経験する機会があったりします。同時期に、面白い製品オプションの開発を行ったことがあります。java.io.Serializableインターフェイスを有するJavaのクラスをC++からインスタンス化して呼び出しできるというものです。これは、ローカルマシン上のJavaオブジェクトの生成だけではなく、RMI(Remote Method Invocation)を利用しているEJB(Enterprise Java Beans)の呼び出しができる、かなり変なものでした。EJBのシステムとC++ベースのシステムを簡単に連携できてしまう(もっというと実は、COMベースのシステムとEJBのシステムもOK)ものを開発したことがあります。2002年の3月からスタートして、完成したのが2002年の6月くらいだったかと。 その後は、Service Management製品のEnterprise展開ということで、大手製造業向けのシステム設計に関与したのが、2002年10月。当時のお客様から要件が出てこず、結果として自ら要件定義を提案しながらまとめていったあの頃。データモデルからドメイン分析、パッケージ構成、GUIの設計、機能設計、・・・、要件を出してくれないお客様の様々な状況を想像した上での設計活動。もの凄い量のドキュメントを作成して、深夜まで見直しを続けた日々。システム連携上で不足するAPIについては、WebサービスのAPIとして拡張してもらう提案を続けていた時期もありました。 そのプロジェクトが終わり、2003年に私は、3つのロールを一手に引き受けることとなりました。Linux技術と関連製品、セキュリティ製品、さらに特殊任務部隊を指揮する隊長。特殊任務部隊は、S.W.A.T(Special Weapon And Tactics)と呼んでいました。隊長でありながら、自らもS.W.A.Tである立場。S.W.A.Tの実力を試されるために初見のセキュリティ製品の国際化を3週間で終えたことは今でも忘れることはないでしょう。ACLを管理する製品と組み合わせることで、WebサイトのURL単位でのアクセスコントロールを実現する製品のAgentのマルチバイト対応なんかもやっていたりします。 単なるC言語プログラマで出発した一人の男は、2003年9月の時点で、Webシステムの国際化を英語版Windows、英語版MSDEで実現するところまで変貌を遂げました。その後は、製品開発における国際化アーキテクトという道を歩み、インドで70名の技術者に対して国際化プログラミングを指導したこともあります。 なんだかんだ言いながら、2000年前半はManagement Softwareの世界にどっぷり漬かれたことが良かったと感じています。視野はかなり広がりましたが、進化する技術へすべて追従できているとは思えてません。ただし、アナロジー(相似)で考えるという癖をつけてきているので、新しいものが出たときに、それの前進となる技術と対比しながら概要レベルには追いつけられるかと思っています。 2005年9月にマイクロソフトに入社し、今までとはまったく異なる土俵での仕事に移り、いろいろありながら、現在は、Channel…

0

日本の開発チームの努力を垣間見て

Channel 9ネタでもあるのですが、このところ毎日、調布技術センターに通って、開発チームの皆様とお話をしております。毎回2時間くらいのヒアリングを行っているのですが、とても興味深いことだらけで、知りえた情報の中で公開可能なものをどうやって皆さんに伝えていけばいいのだろうと模索しております。 「日本のマイクロソフトは開発を行っていない、ローカライズしかしていない」という誤解が日本国内に生じている事実を私たちマイクロソフトの社員は知っています。これは非常に残念な認識の一つです。この認識の相違が生じてしまっている原因は、日本のマイクロソフトの製品展開や製品サポートなどの経緯にもよるものかもしれません。 私が展開しているChannel 9では、その誤解を払拭するためのきっかけを作ろうと狙っています。また、製品開発の現場を知り、その現場での努力を少しでも多くの方に知ってもらいたいと考えています。 たとえば、Windows Vistaをひとつとっても、Active Directory、フォント、IMEの改良、これらは日本のユーザのことを考えています。2007 Office Systemにおいては、ユーザビリティの面で日本のお客様が良く使う機能というのを勘ではなく、実験データやユーザビリティに対するフィードバックから選別しています。ホームユーザ向けの製品をとっても単なる画面を日本語化するという簡単なローカライズではなく、日本市場や日本語という文化をきちんと意識した上で、日本固有の機能が付加されています。 Windows Automotiveのチームは、高機能・高品質の車載機器が求められる日本市場で順調に成長しています。すべての開発を日本で仕切り、プラットフォームが調布から世界に向けて展開されているということはあまり知られていないことでしょう。 日本語や中国語・韓国語といったアジア圏特有の文字を入力するためのソフトウェアであるIMEにおいてもさまざまな努力がなされています。開発チームはより精度の高い入力しやすいエディタを開発する一方、テスティングチームはその問題を大量のテストシナリオにおいて検証し、開発チームにフィードバックしています。また2007 Office Systemに搭載されるIMEはWindows Vistaのものとは異なり、変換精度の追求やOutlook連絡帳との連携、さらにはWindows SharePoint Serviceによる辞書データの連携(辞書ダウンロード、XML Web Service連携)といったことを検討し、よりよい日本語入力環境を追求しています。 開発されている製品やコンポーネントはあまりにも普段の操作に身近なものであるために、それがどのような思想で設計され実装されているか、その情報を知る術は簡単ではありません。ただ、私が展開しているChannel 9のような活動を通じて、開発者の方々を取材することにより、いろんな発見があると考えています。 ゆくゆくは他のMSDNブロガーやeXConnブロガー、TechNetブロガーなどの情報を捕捉するようなビデオログをどんどん投稿できればと考えています。

0

日本語版Windows Live Safety Center Beta版

MSNのトップページ http://www.msn.co.jp にある、MSNのおすすめのところに、ひっそりと「セキュリティ対策」というのが追加されていますね。あまり意識していなかったのですが…。 このリンクを辿ると、次のURLへジャンプします。 http://safety.live.com/site/ja-jp/default.htm これは、Windows Live Safety CenterのBeta版。ja-jpというディレクトリに配置されているだけのことはあり、画面は日本語になっています。 サイトの説明を引用すると、 Windows Live Safety Center Beta は、PC の健康状態を維持するための新しいサービスです。無料で使用できます。Windows Live Safety Center Beta のスキャンが行う内容は以下の通りです。   ウイルスの検知と除去 脅威に関する詳細情報の参照 PC のパフォーマンスの向上 ハード ディスク上の不要なファイルの削除 フル スキャンを使用すると、すべての項目を一度にチェックすることができます。目的に合わせたスキャンを行いたい場合は、各サービス センターでスキャン プログラムと情報を入手することができます。 とのことです。スキャンツールはActiveXの技術を使って実行されます。 スキャン中の様子をビットマップとして添付してあります。スキャン途中ですが、1個のウィルスが見つかったと表示されているので、これがどのウィルスなのか、チェックしたいところです。 検出の精度や将来の脅威に対する対応がどうなっているかわかりませんが、Internet Explorerがあれば、即座にウィルスとスパイウェアの検出ができるというのは、よい事でしょう。 Windows DefenderやWindows Live Safety Center、これらは、マイクロソフトがセキュリティに対して、向き合っている例に過ぎません。 日々、新しい脅威が世界のどこかで開発され、ネットワークを通じて広められます。セキュリティソフトウェアベンダーが新しいシグネチャを開発している一方、マイクロソフトもそれらの脅威に対して向かい合っています。 しかしながら、ソフトウェアベンダーがいくらセキュリティに対して向き合っていても、最終的には、ソフトウェアを使う人々の安全に対する意識が変わらなければ、問題はいつまでも解決しないでしょう。P2Pソフトウェアからダウンロードした圧縮ファイルに付属するウィルスの問題、また、最近は多重にウィルスやスパイウェアが組み合わされた脅威が存在し、リアルタイムにマルウェアを検出する環境でなければ、単なるWebサイトからも容易に問題となる悪意を持ったプログラムを実行してしまうことがあります。安易にURLをクリックしない、という意識を持ってネットに接することが必要です。 ウィルス対策、スパイウェア対策、皆さん、万全ですか? ScreenShot-WLSC.JPG

0

Windows Live Gadget SDKのリリース

Microsoft Gadgets Blogに、James LauよりWindows Live Gadget SDKリリースのアナウンスがされています。 http://microsoftgadgets.com/Blogs/gadgetnews/archive/2006/05/25/5857.aspx Live Gadget SDKは、 http://microsoftgadgets.com/livesdk/index.htm に公開されています。英語ですが、一通り必要な情報が用意されています。 例えば、Windows Live Gadget Developer’s Guideには、ガジェットの構造として http://microsoftgadgets.com/livesdk/docs/default.htm#GadgetAnatomy のような説明が書かれています。これは、Channel 9日本版試験放送、第2弾の「ガジェット – Windows Live」で解説されていた話で、ガジェットは、Manifest XML、JavaScript、CSSを使って作られています。 SDKでは、IISによるWebサービス側の話にも触れており、必ずしもクライアント側だけの話に閉じているわけではありません。また、ASP.NETを利用した話も書かれています。 Windows Liveのガジェットは公開できれば、世界を相手にいろんな人を楽しませることができるものです。Live.comをより良く楽しいものにできるよう、今後、日本のマイクロソフトからもWindows Liveに関する開発系の情報が増えるのではないかと思っています。もちろん、私のブログやChannel 9日本版でも情報を発信できればと考えています。  

0

ビデオサーチ: Speech Technologyの研究から

Microsoft Research Asia (MSRA)が取り組んでいる研究のひとつに「Speech technology」というのがあります。 http://research.microsoft.com/speech/ 自動で音声認識することや、文字をスピーチに変換することや、音声情報の管理や抽出といった分野で研究が行われています。 今日、その研究の一環として、ビデオサーチという成果を見ることができました。 内容としては、インターネット上に公開されているビデオファイルをキャッシュしておき、その音声情報から喋っている言葉を単語単位で抽出しておきメタデータをデータベース管理することができるようです。そのデータベースに対してキーワード検索をかけると、指定したキーワードを含んでいるビデオコンテンツとそのコンテンツ内のタイムラインを自動検出するというものです。 その研究で作られたアプリケーションで「Channel Japanese」というキーワードで検索を実行してもらったところ、見事に先日公開したChannel 9日本版の第一弾のビデオがヒットしてびっくり!! とても面白い研究です。日本語の認識に関してはまだこれからというところみたいですが、撮り貯めたデジタルビデオから特定のキーワードや台詞を含んだ箇所だけを抽出できるようになると、デジタルビデオの再生方法や楽しみ方ががらっと変わるかもしれません。たとえば、ニュース放送などで、着目しているキーワードを含む箇所にすぐにジャンプできるようなビデオ再生装置があれば、多チャンネルで録画しておいても効率よく目的のニュースを絞り込むことができそうです。また、音声のメタデータを作る際に音声を認識しているわけですから、今後研究が進んでいけば、ビデオキャストをクロールして、ニュースの要約と動画のリンク先を集約してくれるサービスなんかも自動的に作れそうです。 MSN Videoなど、ビデオ配信をしているサイトが増えている中で、将来、簡単に誰もがビデオ内の音声情報を文字として抽出したり、文字から音声情報と対応するビデオのタイムラインを検索したりできるのであれば、ビデオの視聴におけるタイムシフトやビデオに関連する情報サービスとの連携というのが見込めそうです。 さらには音声情報からの自動翻訳というのも進んでいくように思います。この精度が高まってくれば、インターネット上のあらゆるビデオコンテンツを見たいときにオンデマンドで字幕スーパーを作成できるのではないでしょうか。そうなると言語の壁がかなり低くなって、いろんな国のビデオを音声からは意味がわからなくとも文字から意味を理解することができるようになるのでしょう。地域や文化に特化した情報、それを他の文化圏から容易にアクセスできるようになると、異文化コミュニケーションの中に新しい気付きが生まれるかもしれません。 ビデオサーチのデモについては、近いうちにChannel 9で公開したいと思います。 雰囲気を理解してもらうことを優先したいので、基本は英語で。ポイントとなる点は、日本語のテロップを挿入しようと思います。

0

個人情報の保護を考える

本来はChannel 9ネタであるのですが、マイクロソフトの活動として大切なことなので、こちらにログを残すことにします。 Channel 9に出演していただけそうな人々を公募しようと、Channel 9日本版サポートブログに書き込みを始めて、さて、投稿…と思った瞬間に手が止まりました。 「あっ、個人情報の収集になるじゃない、これ (^^;」 書きかけていた内容(一部削除)は以下の通り。 マイクロソフトの製品をお使いで事例を公開したい企業の方、マイクロソフト製品に精通しているMVPの皆様、マイクロソフトを応援したいという皆様、Channel 9に出演してみませんか。   先ほど、米国のDeveloper & Platform Evangelismのマーケティング戦略マネージャとChannel 9日本版について1時間半ほど展開プランをディスカッションしました。その中で、出てきた提案として、「お客様に出演してもらうのはどうか」というものがあり、公募をかけてみたいと思います。   Channel 9は、広告配信を行っていないため、出演にあたって、出演料をお支払いすることはできません。お金目的ではなく、顔や声をネットを通じて「マイクロソフトの製品やサービスでこのような経験をした」ということを世に広めてみたいとお考えの皆様、下記の要領で企画をまとめて、お知らせください。   題目(Subject): 1行でまとめてください ブログメッセージ: フリーフォーマットで何を伝えたいかを説明ください メディア形式: ビデオ or 音声 …(略)   ・・・ いかん、名前・所属・連絡先などを集めたら、それぞれ個人情報保護に該当するではないですか。 マイクロソフトでは、個人情報保護について、下記のURLでプライバシーの声明を出しています。 Microsoft.com Japanプライバシーに関する声明 http://www.microsoft.com/info/ja/privacy.mspx ・・・ あやうく、個人情報保護を正しくないプロセスで集めるところでした。 マイクロソフトでは、「マイクロソフト個人情報保護方針」について小さなカードが用意されていて、社員に配布されています。また、名刺に貼るための「ご連絡希望シール」というのが用意されていて、個人情報を大切にする姿勢を示しています。 オンラインでの個人情報収集に関しては、平文でデータを収集することのないよう、SSLで保護されたWebシステムを使っています。 個人情報の収集にあたっては、Privacyに関する3つのトレーニングプログラムを受けないとシステムが使えないようになっています。このため、誰もが容易に個人情報を収集することはできないわけです。 そんなわけで、近いうちに先のトレーニングを受講し、Channel 9日本版の活動で参加者を公募できるような仕掛けを作ってみたいと思います。  

0