twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ

ブログ

ブログ別アーカイブ l 未来のいつか l Android/OPhone雑記 l l
l アジアのペンギン l 烏龍の旅 l 第三のペンギン l TOMOYO Linux l

 

新着記事



3代目スマートフォン(Softbank 001HT,Desire HD)

先週の水曜日に3代目スマートフォンとなる、Softbank 001HT(HTC ...
続きを読む...
 

ブラウンバッグミーティング

欧米の研究所なんかでは、昼休みにランチを同僚ととりながら様々なことを議論するブラウンバッグミーティングというのがあるらしい。ランチを紙袋(ブラウンバッグ)にいれて持ってくることから、そのような名前がついている。日本だとコンビニでランチを買ってもビニール袋は白なので、ホワイトバッグミーティングになってしまうけど。 このランチでのミーティングというかインフォーマルな勉強会というか単なる雑談の会というか、中身はいろいろあると思うけど、これが意外といい。非常にいい。 先日も、昼休みの時間帯に読書会をやった。週1回のペースで開催を目論んだのだけど、なんやかんやで月に2〜3回程度のペースではあったが、最後まで読めたのは非常によかった。 まず、ちょっと形式ばって勉強会を昼休みにやることのメリットを考えると、夕方就業時間後にやるのと比べて、スケジュール調整が容易なことがあげられる。就業時間後だと、時短勤務の人、例えば小さなお子さんがいる人などの参加は難しいが、昼休みなら参加可能だ。今回の読書会も、実際そのような人の参加があって、参加者のダイバーシティー(多様性)が広がって、議論の深みがました。 また、昼休みの時間が限られているので、だらだらと勉強会なのか単なる飲み会なのかわけがわからなくなる(それはそれでいいのだけど)というようなことがない。 飲み会と違って、ノンアルコールなので、それなりのメリット、デメリットもあるかもしれないけどがあって、それはプラスマイナスゼロ。 勉強会ではなくても単なるランチを同僚とではなく、ちょっと違ったメンバーと取るというだけでもいろいろが刺激されていい。 弊社では、新卒とか中途採用の人がランチミーティングと称して、半ば強制的に先輩社員とランチを取ることが奨励されている。時々わたしも呼ばれて新卒の人たちとランチを取るのであるが、真面目半分面白半分であれやこれやお話をする。わたしもその機会を多いに利用して若い人が何をやっているのかとか、仕事のどんなところで苦労しているのかとかいろいろ知るきっかけをもらって大変勉強になっている。 このランチミーティングの制度(?)を発明した人はすごいと思う。コストをほとんどかけないで組織の活性化というか、横の継がりというか、血液をサラサラにしているというか、ちょっとした情報をコストゼロで流通させているというか、メリットは大きい。 勉強会同好会も月例ミーティングをやっているのだが、それだけだと、仕事の都合上どうしても参加できない人が出てくるので、先日来ランチミーティングを積極的に開催している。そうすると、同好会のことだけではなく、仕事の話やプライベートな話など話題がつきない。同好会というのは、会社にとっては、社員同士の親睦を深めるという機能を期待しているわけで、その意味でもランチミーティングは非常に意義が深い。...
続きを読む...
 

プログラマが知るべき97のこと

和田さん監修、夏目大さん翻訳。下記のような日本人プログラマに書き下ろしもついている。 命を吹き込む魔法 森田 創 ロールプレイングゲーム 関 将俊 ルーチンワークをフローのきっかけに 宮川 達彦 プログラマが持つべき3つのスキル 吉岡 弘隆 快適な環境を追求する 舘野...
続きを読む...
 

CloudStackユーザ会(CloudStack勉強会) 勉強会に参加してきました。

月曜日にCloudStackユーザ会(CloudStack勉強会)に参加してきま...
続きを読む...
 

人を見るということの素晴らしさ

先週人材育成トレナーをされており、著書である「ファーストクラスに乗る人のシンプル...
続きを読む...
 

中国でもっとも有名な日本人の話を聞いた。

昨日、GIEシンポジウム Asian Cloud Manifest - Cloud Computing, Asian Growth, and Regional Integration なるものに参加した。http://gie.sfc.keio.ac.jp/sympo101115/index.html コメンテーター、パネリストは、錚々たる人々で、Microsoft Chief Research and Strategy Officer, Craig Mundieなどなど。 KIM KWANGSU 氏   (Director, Privacy Protection and Ethics Division, KCC (Korea Communications Commission))...
続きを読む...
 

そろそろ勉強会について一言いっておくか。

自称勉強会マニアと呼ばれている@hyoshiokです。(それって自称じゃないじゃん。セルフツッコミ) それはともかく、勉強会の達人は「勉強会に勉強しにいくのは素人」とか、勉強会はあくまで手段であって目的ではないとか、勉強会マニア(苦笑)とか、まあいろいろ言っているわけであるが、わたしも勉強会について一言いっておく。 勉強会は主催者発表者参加者それぞれの思いがありそれぞれ渾然一体となって出来上がっているから同じものは世界に二つとないし、同じ主催者の勉強会でも毎回毎回微妙にことなるライブなセッションである。十人十色である。 なので、勉強会はなになにでなければいけないとかなになにであるべきだというものは一切ないし、自分が「これが勉強会だ」というようなことを言うつもりもない。 一方で勉強会に集う人々、主宰する人々、それぞれにある種の共通の価値観みたいなものはあるような気がする。十人十色なので全員が同意するというものではないけど、多くの人が大切にするような価値観である。それぞれのコミュニティには、それぞれの価値観があり、その価値観で緩くつながっているわけで、その価値観が普遍であればあるほど多くの人の共感を集める。 わたしがカーネル読書会をはじめたきっかけは本当に偶然で、それがまさか10年以上も続くなんてことは夢にも思っていなかったし、自分にとってこれほど大切なものに育つなんてことは考えてもいなかった。偶然と僥倖である。 ただ漠然とした思いではあるが、シリコンバレーというIT業界のメッカ、それも90年代半ばというインターネット勃興の現場にいたものにとって、シリコンバレー的な開かれたユーザグループの会合とか大学の授業への一般人の参加は、本当にwkwkして、そーゆーことが日本という地域でもあればいいなあと思っていて、その思いが最初のカーネル読書会の開催をさせたどっかにあった。 ソースコードを読むという試みは「モジラの解剖」という当時書いていた「シリコンバレー日記」と併設する技術系(?)日記のようなもので98年ころ実践していて、日本に帰ってきて、Web日記(当時ブログという言葉はなかった)を書くのは電話代の関係もあり*1、面倒で放置していた。モジラへの興味も若干薄れたこともあり、ちょろっとLinuxのカーネルでも読んでみようという極めてあいまいなところで、どうせやるなら、それを肴に飲み会でもするかというのがというのが正直なところである。*2 *3 カーネル読書会の向こうに見えるものは、90年代のシリコンバレーで見た自由闊達な議論で、そのような議論が自分の半径5メートル以内で出来れば素敵だなあという思いだ。そのような議論が出来る場、それが欲しかったのである。...
続きを読む...
 

アジアの端っこでグローバリゼーションを考えた

大学卒業してから20数年会社員生活をして、転職もして、それなりに経験をつんで、その立場からあれやこれや考えてみた。あれやこれや。 最初に就職した会社が、米国外資系ハードウェア会社の日本法人(日本DEC)、一年程、米国本社に転勤になってVAX Rdbという製品開発に参加、次が同じく米国系ソフトウェア会社の日本法人(日本オラクル)、その時、米国本社に出向になって、Oracle8というRDBMSの開発に参加、日本に戻ってきて、日本オラクルが出資するミラクル・リナックスを立ち上げて取締役CTO、最後に5ヶ月ほど独立行政法人情報処理推進機構(IPA)に出向。そして今は楽天。ミラクル・リナックスの経営は日本人がやっていて本社も日本だが、日本オラクルという外資の子会社なので、資本的には外資(?)ということになる。なので、わたしの会社員人生は、外資がほとんどだ。 長年外資の子会社に勤めて痛感したのは、重要なことはすべて本社が決める。子会社の裁量は限られている。当然と言えば当然の話である。ミラクル時代、日々のオペレーションはもちろん任されていたが、重要事項は親会社の親会社、すなわち海の向こうの本社の意向に支配されていた。 80年代、日本の経済成長が著しいころ、本社の中で日本の発言力が他の海外子会社に比べて相対的に強い時代もあった。日本オラクルの発言力が強かったのは90年代なかばの佐野力が社長をしていた時代であるが、21世紀に入ってからは、日本固有のオペレーションというのはほとんどなくなってグローバル化ということで、米国本社の縛りがきつくなっていった。 米国系外資の場合のグローバリゼーションというのは基本的にはアメリカ本社化である。それが一番効率がいいので、金太郎飴なオペレーションをして可能な限り例外は認めないという考えである。個別対応はコストがかかるので可能な限り、そのようなことはしないという方針でずんずんやる。 まあ、もちろんまったくローカライズしないというのはいくらなんでもありえないので、若干はやるとしても、それも程度問題である。 IT産業は幸か不幸かほとんどすべて米国企業にやられているので、米国的なグローバリゼーションというのが、当たり前と言うか、そーゆーものだという印象がある。わたしも、そー思っていた時期もあった。 80年代DECが日本市場に上陸し、ソフトウェア製品を売るときの最初の障壁は日本語化だった。当時ソフトウェア製品と言うのは国際化どころか満足な日本語化もされていなかったので、いちいちソフトウェアに手を入れて、漢字が通るようにしたり、マニュアルやメッセージなどをせっせと日本語に翻訳したりした。もちろんすごくコストもかかるし、市場に投入するのに何ヶ月へたをすると年単位で時間がかかったりする。しかも、ソフトウェアに手を入れるので、バグが入ったりして、品質もよろしくないという三重苦を味わっていたりした。 そもそも、ソフトウェアが国際化ということを念頭に実装されていないので、とんでもなくアドホックなやり方で日本語化したり、どう考えても拡張性がないような方法で変更するものだから、日本語版そのものの品質も悪く、もちろん保守なんてのは悪夢以外の何物でもない。 日々、時間との戦いで、ひーひーいいながら日本語化をするのであるが、若い血気盛んなエンジニアは、あまり創造性が高いとは思えない仕事なので、どこか日本語化をばかにして、そーゆーことには関わりたくないと思っていたりした。わたしも、正直、日本語化とか、いーかげんにして欲しいよなあとか思いつつ、ぶつぶつ言いながらやっていた口なのではあるが、何年もやっていると、さすがにパターンが見えてきて、ソフトウェアが元から備えるべき属性の一つとしての国際化という概念がおぼろげながら理解できてきた。 自分の中では、80年代後半の文字コードの開発、JIS X0208:1990, JIS X0212:1990など、VAX Rdbの国際化プロジェクト、日本語COBOLおよび国際化COBOLの開発などを通して、その設計と実装の理解が深まった。 ソフトウェアを後から日本語化などするのは先に記したとおり、(1)実装のコストがかかる、(2)オリジナル発売から日本語化までの時間がかかり、機会損失が発生する、(3)品質も悪い、など諸問題がある。さらには、オリジナルがバージョンアップするごとに、同じ作業を延々繰り替えさなければいけないため、80年代の終わりには、はじめから各国語化をしやすくソフトウェアを作るべきであるという考えが広まった。その概念をより一般化したものがソフトウェアの国際化として後にしられるベストプラクティスである。 80年代ぶつぶついいながら日本語化していた経験未熟なエンジニアであったわたしもさすがにこれじゃいかんだろうと思うようになって、原因は元から断たないとだめだ、誰かがやってくれるわけはない、この問題に一番詳しいのは自分なんだから、いっちょ向こうに乗り込んで根本から解決するしか、みたいな鼻息も荒く海を渡ったわけである。 米国本社も、日本語化するコストが下がって、すぐに日本語版が出荷できて、しかも品質も良いということになれば、いいことずくめなので、ちょっとコストがかかっても日本人のエンジニアを呼んで、コードを書かせてやればいいじゃないかというこになった。 一個一個のソフトウェア製品をいちいち一人で直していたらいくら時間があってもらちがあかないので、それをソフトウェアの国際化というパターンにして、素人でも国際化プログラムが書けるようになるには、もう少し時間が必要なのであるが、まあ、そんな時代である。 米国本社のエラい人を動かすには、日本のエラい人にお膳立てをしてもらって、ビジネス的なジャスティフィケーションとかあれやこれやしてもらうわけであるが、まあ、米国市場で十分儲けていたりすると、国際化なにそれ、おいしいのという感じなので、噛んで含めるように、それがめちゃくちゃおいしいのであるということで理解してもらう。これは技術的な話ではない。お金の匂いである。 ビジネス層が仮にうんと言ったとして、現場の技術者に国際化のイロハを伝えていかないといけない。現場の技術者は、あんまりお金の匂いに興味が無い。最初の一歩は日本語化というか文字コードのお話などを延々念仏のように唱える。なだめすかしお願いしたりする。 いつの日か、日本語化のような不毛なことをしなくても、漢字がふつーに出る日々のことを夢見て、毎日毎日コードと格闘し、無知なエンジニアを啓蒙する。そんなことを丹念に諦めないで行った。時にはくじけそうになったがひたすら続けた。 もちろんUnicodeなどというものはない。なければ作る。DIYの世界である。 まあ、そんなこんなで子会社の従業員の立場から見ると、本社に乗り込んであれやこれや出来たのは牧歌的であるが貴重な経験を積めた時代でもあった。そして、ソフトウェアの国際化が一般化して、Unicodeも普及して、米国で作ったソフトウェアが一切変更なしに世界中で利用でき、何の問題もなく日本語も中国語もヘブライ語もフランス語も英語もドイツ語も扱えるようになると、日本語という非関税障壁がなくなった日本市場はあっというまに、米国製ソフトウェアに席捲されるのである。 日本にあった日本語化をやる開発部隊は必要なくなり、外資系ソフトウェア会社の多くは、本社の製品を効率よく販売する機能だけが残っていくことになる。 そのような組織では当然のことながら重要事項はすべて米国本社で決定することになる。子会社の経営陣に決定権はない。 わたし自身、転職するにあたって、次の会社は外資以外にしようというのがあった。海の向こうで何かが決まるという会社はもうお腹いっぱいなので、本社が日本にあって日本で決まる会社にしようと思って、今の会社を選んだ。日本で住んでいるので、そーゆーことになる。 転職して半年もしないうちに、グローバリゼーションだなんだというお話が出てきた。世間では社内公用語の英語化というのがおもしろおかしく取り上げられているが、グローバリゼーションというのは英語化と同じではない。まあ、それはここでは触れない。 今の会社で、技術のあれやこれやを考える立場にあって、グローバリゼーションってなんなんだろうと考える。 DEC時代にソフトウェアの国際化のアーキテクチャを構築するプロジェクトがあって、それに参加したことを思い出した。そのプロジェクトはDEC本社のCorporate Consulting Engineerをリーダーとして、世界中からソフトウェア国際化の専門家を集めて行われた。イギリス、フランス、スイス、イスラエル、タイ、香港、日本、米国から参加した。そこでDECの国際化アーキテクチャーを定義した。 *1 当時はわたしも若かったのであるが、気がつくと、いつのまにかに国際化プロジェクトを率いていたリーダと同じような年齢になって、グローバル化を考える立場になった。因果応報。 本社が米国東海岸ではなく日本にあるという違いだけかもしれない。 海外子会社の若いエンジニアが何年か経って立場が変わって本社のシニアなエンジニアになった。当時のプロジェクトリーダーは何を考えどのように行動したのだろう。わたしにとっての雲の上の憧れのエンジニアだった人と同じ世代になって、わたしは彼のようになれたのであろうか。 先月、楽天テクノロジーカンファレンスで"What does globalization mean for Rakuten?
続きを読む...
 

Debug Hacks韓国語版

syoshidaです。 今週、宅配便で自宅に一冊の本が届きました。 なにも注文し...
続きを読む...
 

Linux のアクセス制御

情報処理学会の会誌 10 月号の特集は,「Linux のセキュリティ機能」というタイトルで,SELinux と TOMOYO Linux によるアクセス制御がメインの内容でした. エンタープライズよりの内容っぽくて,あまり実感は沸きませんでしたけど,「こんなことやってたのか」ということで勉強になりました.正直なところ,今まではファイルのアクセス権くらいしか気にしたことありませんでした….(おおっ... 続きを読む...
続きを読む...
 
94 / 101 ページ
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!