ユメのチカラ: 人月の神話
Frederick Phillips Brooks Jr., "The Mythical man-manth: essays on software engineering", Anniversary edition. フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳 わたしが紹介するまでもなくソフトウェア開発の古典中の古典である。先日の「情報システム学会(ISSJ)、情報システムのありかたを考える会」での発表のために、久し振りに読みかえしてみた。 原書は1975年に出て、長いこと読み継がれてきて、今だにその指摘は古びていない事に驚かされる。16章からは、初版以降に書かれた論文、評論になるが、やはりこの書の本質は、初版時点で書かれた1章から15章であろう。 第1章「タールの沼」。大規模システムプログラム開発がタールの沼にはまってもがき苦しむ、恐
ユメのチカラ: カーネル読書会のめざすもの
YLUG(横浜Linux Users Group)のカーネル読書会FAQページがあまりにも古いので更新しようと思ったのだが、どっから手をつけていいやら。 この手のFAQは個別のエントリに回答を重ねて更新する事はもちろん可能なのだが、ロードマップというかカーネル読書会をなぜ開催したいと思ったのかとか、なぜ続けているのかとか、どうしたいのか、とかいう明確な意志の表明なんかがあるといいかもしれないと思った。企業のビジョンステートメントみたいなものである。 おいおい、たかが趣味の世界でビジョンステートメントはいくらなんでもやりすぎだろう。大袈裟すぎやしないか、という声もある。そう思う人もすくなからづいそうだ。わたしもそう思わなくもない。 コミュニティ(？)のビジョンとかミッションというのは通常明文化されないし、されたためしも(ほとんど)ない。LinusのJust For Funという書籍は、ある意
ユメのチカラ: Community Based Development
オープンソースソフトウェア(OSS)の力はバザールモデルとして知られるコミュニティによる開発(Community Based Development)だと思う。 OSSの特徴としてフリーなライセンス(利用、変更、再配布の自由など)があげられる事が多いが、それはあくまで必要条件であって、十分条件ではない。ライセンスをフリーにしたからと言って、コミュニティが自然発生するとは限らない。商業ソフトウェアベンダは自社製品をプラットフォームとするために、あの手この手を使ってコミュニティを形成しようとするが、それには相当なコストと時間がかかる。 大雑把にソフトウェアを分類してみる。 最初のカテゴリは、プログラム。これは実行可能なソフトウェアで、趣味で作ったり学校の課題で作ったりする小規模なものとする。規模も小規模でせいぜい大きくても数千〜数万行程度のものである。おもちゃのプログラムに毛がはえた程度のもの
ユメのチカラ: ムーアの法則を理解すること
Matzにっき (2007-05-30) インテル：「ソフトウェアもムーアの法則に従う必要がある」 - CNET Japan http://www.rubyist.net/~matz/20070530.html#p07「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。 っていうか、最初からそういう風に言ってほしいものだ。このブログの読者ならご存知かと思うが、わたしは昔DEC (Digital Equipment Corporation)という会社に勤務していた。わたしがエンジニアリングのイロハを習った会社である。VAXそしてAlpha AXPというコンピュータ史に残るアーキテクチャを開発した会社でも知られている
ユメのチカラ: 若者との会話
びぎねっと主催のオープンソースパーティ2007に参加した。今年は120人を越える参加者ということで、会場がごったがえしていたので、落ち着いて話をすることはなかなか難しかったが、それでも懐しい顔にいっぱいあえて楽しかった。前日はカーネル読書会だったので2日連続で会う人も少なくなかった。特にオープンドリームの皆様には、あ、どーも、とか言う感じであった。 入口近くには、びぎねっと勢が陣どっていて、Linux World Expo3日間の疲れかテンション低くまったりとしていた。 その一人大内さんとお話をする。まだ10代のハッカーである。はりぼてOSの会で、自分OSを作っている若者である。 はりぼてOSの会は、「30日でできる！ OS自作入門」に触発されて自作のOSを作ろうという狂気(誉めています)の集団である。わたしみたいな人間はOSを自作しようなんていう発想にはまったくもってついていけないのであ
ユメのチカラ: Rubyって何よ。
先日、NHK土曜ドラマ「ハゲタカ」の事をこのブログで書いたものだから(「ハゲタカ」、「職人気質」など)、日頃このブログの読者でない方も多数訪問されている。ご訪問ご苦労さまです。45度おじぎ。(ぺこり) ハゲタカファンの皆様にとってはこのブログ、わけのわからない、Rubyだ、オープンソースだ、gdbの使い方だで、ほとんど興味を引かないものばかりかと思うのだが、ここは一つ、ハゲタカファンの皆様にRubyについて、お話をしてみたいと思う。 Rubyというのは、まつもとゆきひろという一人のプログラマが作ったソフトウェアである。(ふむふむ)。ソフトウェアを記述する言語のことをプログラミング言語というのであるが、Rubyはそのプログラミング言語の一種である。(ふーん)世界には様々なプログラミング言語があるのだけど、Rubyは赤丸急上昇の人気言語なのである。 ソフトウェアの世界にも流行すたりがある。プロ
ユメのチカラ: なせ欧州のオープンソース開発者は活発なのか
佐藤嘉則氏の「なぜ欧州のオープンソース開発者は活発なのか---FOSDEM2007に見るヨーロッパのOSS事情」という記事が面白い。 http://itpro.nikkeibp.co.jp/article/COLUMN/20070508/270280/ 佐藤氏はLinuxのH8アーキテクチャのメンテナーであり、サイオステクノロジーでLinuxのサポートをおこなっているプロ中のプロである。 日本という地域では、組み込みLinuxのベンダやハードウェアベンダ以外でLinuxのカーネルを仕事として開発、変更しているというエンジニアはほとんどいない。その意味で佐藤氏は貴重なエンジニアの一人である。 さて、上記の記事は彼がFOSDEM2007での旅行記という形式をとるが日本の開発者への熱いメッセージでもある。引用する。 所属企業からの支援も「勝ち取るもの」 http://itpro.nikkeibp
ユメのチカラ: JavaからRubyへ
角谷さんからの献本。ありがとうございます。 これは、文字どおりJavaからRubyへの移行するにあたっての実践的なガイドとなっている。技術的な側面よりもマネージャが知らねばならない様々な問題について議論している。 この手の本はパターン言語として、新しいパラダイムとか技術を導入する時に注意しなければならないガイドとして読める。 例えば、Linuxを導入するには、情報収集をして、限定的な展開をし、広範囲な展開をする。とか。 7章「普及」。要員の育成、社内でのスキル育成、短期間での立ち上げ、来るべき日に備える、などなどはJavaからRubyへの移行じゃなくても参考になる。かなり一般的なお話だと言えよう。 Rubyが言語としての熱狂を得ているのは、このような書籍が出版されていることからもうかがいしれるが、大手国産ハードウェアベンダのレーダにはまだ映っていないようだ。大丈夫なのかな。 いづれにせよ、
ユメのチカラ: オープンソースソフトウェアの本当の使い方
リナックスアカデミーの濱野賢一朗さんと日立の鈴木友峰さんの新書である。献本ありがとうございます。 鈴木さんとは、日本OSS推進フォーラムのワーキンググループなどでいつもお世話になっていて、IPAでやったOSSの評価プロジェクトなどではご一緒させてもらったりした。 本書も単なるOSSの解説だけではなく、IPAのOSS評価プロジェクトで得られた知見などをおりこみ類書にない特徴をだしている。(第4章など) 第5章で「OSSの課題」にふれているが、OSSミドルの発展はリナックスのようにはいかないだろうとしている。リナックスの開発の多くが最近はハードウェアベンダなどに勤務するOSの専門家によってなされているというのはよく知られているが、OSSミドルにはそのようなメカニズムがはたらきにくい。例えば、データベース管理システムの専門家はOracleのような専業ベンダーに多数いるが、彼らがOSSのデータベー
ユメのチカラ: ブログと人材採用
事業拡大にともなって人材の積極的な採用を継続的におこなっている。われわれソフトウェア製造業は、人材が価値を生みだすので、人が全てといっても他ならない。再三このブログで記しているとおりである。 実は、このブログ(ユメのチカラ、2007年1月23日23:00)「人材」で「弊社ではエンジニアを募集中であるが、びびらないで気楽に応募してほしい。」などと記したのであるが、ある元気のいいエンジニアが応募してきた。面接、試験などを経て先日、はれて入社。おめでとうございます。 さて、最近入社の人達とランチを食べる機会があって、いろいろお話をうかがうのだが、入社のきっかけとか動機というのは、人それぞれで面白い。最近増えてきたのが弊社のブログを読んで社風が気にいったとか、楽しそうだとか、物を作りたいとか、そーゆーポジティブな印象を弊社のブログから受けたからというのがある。 入社をしたいというくらいだから、弊社
ユメのチカラ: Web2.0時代のソフトウェア開発のスピード
最近、あるWeb2.0系の会社の方たちと勉強会をしているのだが、その勉強会もさることながらその後の懇親会でのユルイ会話が面白い。ていうか、勉強会の後の懇親会が好きでやっているのだろうとかいう突っ込み。否定しません。というか、飲み会に大義名分をつけるために、勉強会と称しているのだろう＞自分 それはともかく、いろいろ面白いお話を伺う。 Web2.0系のサービスってのは、やってみないと分からない類のものが多いのでともかく思いつきでも何でもとりあえづやってみる。だめだったら考え直す。そーゆースタイルらしい、極論すると。 古典的なウォータフォールモデルでのソフトウェア開発だと、だめだったら考え直すなんていうアバウトなことを言ってはいけないという前提で物事が進むから、ともかく石橋を叩きつつ確実に確実に事をはかる。それはそれで確立されたスタイルなので、間違いではないが、プロジェクトを開始した時点と終了す
アジアのペンギン: アセンブラの勉強方法
ダンプを解析するときなどはアセンブラを理解していないといけません。勉強しようと思っても最初は意味不明でやりづらいのですが、簡単でわかりやすい方法があります。実務的にはこれで十分だと思いますのでご紹介します。 この方法ではLinuxマシンを用意すればいいだけです。(本を探したり、購入する必要もなし) アセンブラを理解するためにはCPUのレジスタなどを理解する必要があります。私が実際にダンプを解析するときに見るのはEIP、ESPぐらいです。アセンブラからソースコードを解析する場合は少しアセンブラ命令の意味を理解していれば、レジスタは汎用的に使用されるため特別な知識はあまり必要ありません。 まずは下記のようなソースコードを作成して、コンパイルします。( Fedora Core 5 32bit の場合 ) # cat assemble.c #include <stdio.h> int globa
ユメのチカラ: YAPC::Asia 2007
Yet Another Perl Conference at Asia (YAPC::Asia) に参加した。 技術系カンファレンスというのは何のためにあるのか考えるいいきっかけになる。 なぜ、技術系カンファレンスに時間を作ってもいかねばならないのか。楽しいから、新しい技術を勉強、ネットワーキング、旧友にあう、有名人のサインをもらう、オライリーの新刊を立ち読みする、初対面の人となかよくなる、技術的な議論をする、気分転換、カーネル読書会の宣伝、技術系カンファレンスの運営について学ぶ、ついでにリクルーティングなどなど。 参加者はざっとみて400人弱くらいか。Shibuya Perl Mongersの人達が主体となってボランティで運営開催されている手作りのカンファレンスである。Ruby会議やPHPカンファレンス、LLなどと規模や運営方法が似ている。Linux World Expoのような企業によ
ユメのチカラ: TOMOYO Linux
横浜Linux Users Group (YLUG)の有志でやっているカーネル読書会でTOMOYO Linuxのお話を聞く。開発者が日本人だと日本語でいろいろ議論ができて非常に楽しい。今回のカーネル読書会はNTTデータさんの会議室をお借りしておこなったのだが、懇親会の会場の予約まで全ておんぶにだっこで原田さんをはじめとするNTTデータの皆様に大変お世話になった。ありがとうございました。 下記に資料があるので参照されたい。 http://sourceforge.jp/docman2/ViewCategory.php?group_id=1973&category_id=532 質疑応答が活発におこなわれたが、会場からは強くアップストリームへのマージについての要望というか激励というか愛に満ちたお言葉、コメントが多数でた。原田さんたじたじである。 確かに企業人としての立場もあるし、会社がソースコー
ユメのチカラ: 勝手に性能評価(Lingr編)
週末にLingrを利用したチャットイベントがあったそうだ。[JTPA] Lingrイベントの顛末/My Life Between Silicon Valley and Japan昨日のオンラインサロンは、参加者が集まるにつれてLingrが重くなってしまって残念ながら中止となりました。実のところLingrの実装がどうなっているかは全く知らないのだが、何百人もわらわら集まってチャットをやろうという心意気が楽しい。素晴しい。やってみてスケールしなかったというのも主催者側は若干凹むかもしれないが、それもいい経験で、むしろそーゆー得難い経験を得られたと考えた方がいい。 Lingrの開発者の江島さんは、梅田さんのブログで再挑戦を表明しているので楽しみにしたい。 さて、今回の経験から江島さんら実装者の皆さんは何を学んだのだろうか？ぜひ情報公開をしてほしいと思うのだが、わたしだったらどうするか勝手に記して
拓かれた世界へ向かって: 週報から始めるPDCA
最近、企画書の書き方を勉強のためにいろいろな本を立ち読みしているのですが、なかなか視覚的に訴えるプレゼンテーションが多く、参考になります。 こういった技術を他のことにも応用できないか考えていたところ、身近なところで週報の作成に使えるのでは、と思いつきました。 ml_pdca.potをダウンロード 使い方はいたって簡単、左上に「今週の目標」、左下に「今週の成果」、右下に「今週の反省（振り返り）」、右上に「来週の目標」を書き込みます。いわゆる有名なPDCAサイクルですね。 なんの変哲もない一枚きりのPowerpointテンプレートですが、私の意見ではむしろそれがいいのかもしれないと思っています。 まず、一枚に収めることで情報の一覧性が高まり他人に説明しやすいこと。後で自分が読み返しても各要素の繋がりがよくわかります。 また、時系列に並べやすくなるのもポイントでしょう。今週の右上の「来週の目標
ユメのチカラ: バザールモデルにおける品質
ソフトウェア開発モデルとしてのバザールモデルというのは従来のソフトウェア開発モデルとまるっきり違うので、簡単に対比して考えてみる。 古典的なウォータフォールモデルでは、工程を要求定義、外部設計、詳細設計、実装、単体テスト、統合テスト、運用保守となる。工程による分割可能で、要求定義を上流工程と実装、テストなどを下流工程と言う。それぞれの工程には明確なアウトプットがあり、要求定義のアウトプットは要求定義書で、それが外部設計のインプットになる。 要求の獲得から実装という一連の流れのなかで、利用者の何らかの問題を解決しなければならないのだけど、要求定義が利用者の要求とかけはなれたものであったら、いくら設計から実装が正しくとも、まったく意味のないものができあがってしまう。要求を的確に把握する事が重要なのだけどそれが一番難しい。 仮に要求定義の時点で利用者の要求を把握していたとしてもウォータフォールモ
ユメのチカラ: ハッカーのつくりかた
先日も朝から3人面接し、午後外出の後、夕方1人とじっくり話しこんでしまい、結局ディスカッションは2時間くらいになった。 まあ、ブレストなのか雑談なのかなんなのかよくわからない面接なのであるが、忘れないうちにブログのネタとして書いておく。 彼は弊社一番のカーネルハッカーでバックエンドチームに所属している。カーネルにまつわるどんな問題も魔法のごとく解決する凄腕である。 わたしの下心としては、彼のコピーをどのようにして作るのかというところにある。もちろん人間のコピーなんていうのが簡単にできるわけはない。しかしそれでも彼の1/10くらいのハッカー予備軍ができればおつりがくる。 カーネルの場合、必要とする知識はユーザーランドのアプリケーションより遥かに広範囲である。知識量勝負の部分がある。詳解Linuxカーネル程度の事は常識として理解していないといけない。割り込みの場合、コントローラのレジスタがどう
ユメのチカラ: 人材
今年にはいってから一対一の面接を延々おこなっている。一人あたり30分から1時間くらいフリーディスカッションをする。真剣に話を聞くので一日4人〜5人もやるとふらふらになる。 わたしの仕事は、顧客に価値を提供することだが、その価値を創造する人材を育成することも重要な仕事である。 ソフトウェア会社はヒトが価値を創造するのだから(製造業は工場がモノを生産するが、ソフトウェア会社は別に設備投資とか莫大に必要というわけではない)、そのヒトがモチベーションを最大化するように考えないといけない。 そのためには一人一人のエンジニアの満足度をキープすることが必要である。 そこで先日そのベンチマークのために社員意識調査というのを人材コンサルティング会社におねがいした。この手のサーベイは継続しておこなわなければ意味がないのだが何事も最初の一歩がなければはじまらない。 アンケートは75項目あって、マネジメントの視点
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユメのチカラ: フューチャリスト宣言