「開発の主体」って何だろう?
某MS社員に、「MS IME最近どうなっているのよ?」と先週聞いた答えが...「IME開発の主体が、中国にシフトしまっていて我々も手を出せない......個人的にはATOKに切り替えようと思っている」と言う現役開発系社員の発言に絶句!!!
4 兆円を超える金でYahoo買おうという発想があるならその数10分の1でも、IMEの品質向上に自ら開発投資をするべきで...本来IMEは、かな漢字変換としての機能だけではなく...正しい漢字を検索する、自分のファイルやデータをローカルファイルの中から検索する、企業内部で共通辞書や住所、顧客データなどを検索する、社会のデータベースやインターネット上の情報を検索するに必要な共通技術であるにも関わらず...まぁ、そんなことが理解できない経営者が...IMEの開発は中国でやった方が安く済むと思っているのであれば、未来は無いねぇ...
私自身はずっと ATOK を使っていて,最近リリースされた ATOK 2008 も既に導入済みです.一方 MS-IME の中の人とも時々お話しする機会があって,MS-IME 2007 についても色々意見交換をしたことがあるのですが,なんかどうも古川さんのブログに書かれている話と自分の認識が違う気がします.
確かに,MS-IME 2007 では,変換エンジンの大規模な刷新が行われていて,その件に中国の Microsoft Research が関係しているという話は聞いています.以下のインタビュー記事にあるように,音声認識などで研究されていた統計的言語処理の仕組みを,日本語変換エンジンに応用する過程でのことだそうです.
■変換アルゴリズムの一新は、かな漢字変換処理の根幹にかかわる大変化。なぜ、これほどの変更に踏み切ったのか。
変換精度の向上が鈍ってきたからだ。従来の方法での精度向上は飽和しつつある。もっとほかにできることがあるのではと考え、変えようという決断に至った。
従来は、品詞と品詞の接続のしやすさを記述した「品詞接続表」を利用して変換結果を決定していた。大ざっぱな表は統計的に作れるが、最後は職人技とも言える手作業での調整作業に頼るほかない。このため保守が大変で、もっと科学的で機械的な手法を求めていた。
こうした背景にマッチしていたのがTrigram/SLMだった。元々は音声認識分野で使われてきた技術だ。我々は米国や中国のマイクロソフト・リサーチ(マイクロソフトの研究開発部門)とも議論したが、彼らも同じ技術に着目していた。2001年から一緒にプロジェクトを進め、1年で、これでいけるというめどが立った。
Microsoft Research は,米国本社にある Microsoft Research Redmond,イギリスのケンブリッジにある Microsoft Research Cambridge,中国の北京にある Microsoft Research Asia の 3 ヶ所など,計 6 ヶ所があります.上のインタビューでは,MS-IME 2007 の変換エンジンに使用されている基礎研究が Microsoft Research Redmond と Microsoft Research Asia の成果であると明言されています.
一方,古川さんの記事からは,MS-IME 2007 の開発の大半が中国で行われているという印象を受けます.これが Microsoft Research Asia のことだとすれば,研究部門である Microsoft Research で製品開発が行われているというのも不思議な話です*1.それとも中国には別の製品開発部門があって,そこで MS-IME 2007 が開発されているということなのでしょうか?
はてブコメント を見る限り,古川さんの記事を読んだ多くの方は MS-IME 2007 はかなりの部分がオフショア開発されていると理解されたようですが,私の認識は違って,統計処理アルゴリズムの基盤部分が中国の Microsoft Research で研究開発されていて,残りは国内で開発されているものという認識でした.まあまた機会があれば中の人に聞いてみようかと思います.
追記
やはり中国の製品開発部門との分担作業ということらしいですね.
中国にシフトしてという意味は、外部の協力会社に発注しているということではなく、中国の開発部門が作業の分担と責任を持っているということです。本件は、研究部門(Research)とは関係の無い話です。ポイントは、米国のResearch部門にも日本語言語解析の専門家が研究員で努めており、日本語の変換効率を高めるための開発努力をしてきた人間もたくさんいて、なおかつ操作性(ユーザビリティ)の向上やテスティング手順、お客様からのフィードバックが全て機能してMS IMEは使い物になる状態になってきたのではないか? それなのに、使い勝手も変換結果も後退しているように見えるのは何故?ということです。
過去の関連記事
Windows の素人と玄人とプログラマを見分ける方法
『Windowsの素人と玄人を見分ける方法 - 雑種路線でいこう』にさらに付け足し.
- 英数入力をする時、どんなに長い文字列でも、とにかくキー入力してからいちいちファンクションキーで半角に直すのが素人、IMEをオフにして入力するのが普通。IMEがOnのままシフトキーで一時英字モードにするのが玄人。Microsoft のドキュメント規約に従って英数と日本語の間にホワイトスペースを入れるのも忘れないのが Windows プログラマ。
- レジストリなんて編集しないのが素人。レジストリエディタを使うのが普通。管理者モードのPowerShellからコマンドラインで触るのが玄人。新 API の動作テストも兼ねて RegOpenKeyTransacted を使ったトランザクショナルなレジストリ編集ツールを作るところから始めるのが Windows プログラマ。
- C++プロジェクトのビルドにVC++ 2008 Express Editionを使うのは素人。Windows 9xをきちんとサポートするためにVisual C++ 6.0以前を使うのは職業プログラマ。最新版のPlatform SDKでmsbuildを使うのはgeek。発売されたばかりのVisual Studio 2008 Team Suiteを使うのは好事家。「ああ,Platform SDK は Windows SDK に名前が変わったんだよ」とすかさず指摘するのが Windows プログラマ。
- msvcrt の再配布に悩まされないように DDK のコンパイラを使うのがよく訓練された Windows プログラマ。
『【13-B-7】言語の現在・過去・未来を語る』話題メモ - C# side
Developers Summit 2008『【13-B-7】言語の現在・過去・未来を語る』のメモ.C# side.
誰かメモを公開してくれてるかなぁと勝手に期待してましたが,裏番組に id:amachang の『【13-D-7】JavaScript Tips & Technique』が入っていたせいもあってか今のところあまり見ないですね.というわけで憶えているうちに少し書いておきます.なお,これで全部じゃないのと,話題に上った順序とは必ずしも一致していないことに注意.あちこち話題が飛びながらまったり聞いて楽しむ感じの内容でした.「ラジオの深夜放送みたいだった」という渋木さんの表現はまさにぴったり.
以下の内容で興味を持たれた方は,当日聞いていた人を適当に捕まえて詳細を聞き出してみて下さい.
波村さん自己紹介
C# の言語仕様
- クエリ式の,from x in xs という構文について
- 当初は foreach(var item in source) where ... といった構文も検討されていた
- Anders はクエリ式に 1 年ぐらい反対していた
- しかしユーザビリティテスト (テスタに新しい構文を試してもらう) をやってみたところ,メソッド方式では誰も join を書けなかった
- SQL での語順を弄って,select よりも from が先に来ているのは,IntelliSense で型情報を使うため
- 2005 年の発表段階では,Visual Basic は select x in xs だった
- from from in xs は,当初書けるようにするつもりだったが,文法上の曖昧さが起きることが分かってサポート外となった
- var による型推論の話は C# 1.0 の頃からあった
- 当時は JavaScript に間違われると「良くない」と思われていた
- 今は状況が変わった
- 今では Ruby がデザインミーティングで話題に上ることも
- 昔,まだ海外で Ruby がそこまで騒がれていない頃,波村さんが Anders に Ruby の話を振ったらスルーされた
- 今 Anders が興味があること
- メタプログラミング
- 言語設計で後悔していること
C# の開発形態
- デザインミーティングは週 3 回,各 2 時間
- 言語仕様が決まったら実装してみてテスト
- C# 1.0 がリリースされる頃にはもう,Microsoft Research からほぼ動く形の Generics 実装が上がってきていた
- 結局ほとんど書き直して 2 年ぐらいかかった
- 中身はほとんど同じ
- 「シンボル名の付け方が Research くさい」のが気に入らない等々
- 後でマージするときに困った
- もたもたやっていると Research の連中は勝手に fork して自分たちで言語拡張をやり出す
- 結局ほとんど書き直して 2 年ぐらいかかった
- ソフトウェアってのはやはり属人的な面が強い
- 2 週間ぐらい黙々と作業して一気に書き上げてチェックインする人も
- 「機械のような奴」と呼ばれている
- チェックインしてすぐに vacation に出かける奴がいて困る
- 2 週間ぐらい黙々と作業して一気に書き上げてチェックインする人も
- お気に入りのところは Anders がコードを書くことも
- でも実際に製品コードにするには色々テストとかチェックリストがあってそこまでやってくれる訳じゃない*2
- できれば C# で C# コンパイラを書き直したいけどそのコストが正当化できないため未だにできない*3
C# の要望の上げ方
- 色々なチャンネルがある
- 要望は一旦 PM がとりまとめて適当に集計して Anders に提出される
- 確実に reject されるものはここで落とされる
- でも以前 reject されたものが通ることもあるから難しい
- Anders の機嫌が良さそうなときにリストの上から挙げていく
- 確実に reject されるものはここで落とされる
- 波村さん自身がプッシュして採用された部分も
- C# 2.0 の yield return は,最初 yield のみだった.return があった方がよいと波村さんが推して通った.
C# の互換性
- ある言語仕様が,後でどう影響してくるか,最初から見通すのは非常に困難
- 今回波村さんが来日するときに,「Ruby の変数スコープについては触れるな」とアドバイスされた
- 一度決めた言語仕様の変更は非常に困難
- foreach に対して出力する IL コードを変更しただけで,問題が報告されてくる
- IL 解析ツールの動作が影響を受けた