ユメのチカラ: 技術は会社のものではない。みんなのものだ。社内セミナーをニコニコ動画(RC2)で公開するまで。
先日、野村総合研究所向けに「技術は会社のものではない。みんなのものだ」というタイトルで社内セミナーをした。 オープンソースにまつわるソフトウェア開発方法論みたいな話である。まあ、中身は日頃わたしのブログをご覧の皆様にはおなじみなお話である。 野村総合研究所(NRI)の社員30人程度の皆様への社内セミナー(注)である。今回一つお願いをした。「講演を後に公開していただく事を前提にお請けします」。 セミナーを職業にしている講師にとってはありえない条件である。しかし、わたしは講演を公開することの経済的な損失というのはないし、むしろ自分の日頃の主張と行動に一貫性を持たせるという意味あいの方が強い。 講演内容を公開しろなどという講師は前代未聞である。大きな企業になればなるほど社内調整というやっかいなものが待っている。一度誰かが先例をつければ次の人はその道をフォローできるが、最初の一歩が困難にみえる。越
ユメのチカラ: コミュニティ活動と仕事
先日、大手企業にお勤めの若手技術者の方とお話する機会があったのだが、上司がコミュニティ活動をバカにしていて正直、説得するのに疲れてしまったというような事を伺った。上司が「所詮コミュニティ活動なんていうのはサークル活動だろ」と全くその価値を認めてくれない、というような話であった。 コミュニティ活動をしたところで、自社の直接的な売上に結びつくわけでもなく、経費節約に直接貢献するわけでもないので、上司殿にとっては単なる無駄なアクティビティにしかみえないのだろう。とは言うものの、時間外にやっているわけであるから、ほっといてくれと思わなくもないが、その手の上司は、ほっとくのではなく、白い目でみるというか、良い顔をしないというか、露骨にイヤな顔をするらしい。 仕事の延長で、どんどんコミュニティ活動を奨励する会社は、そうは多くはないと思うが、もちろんなくはない。しかし大手企業で、そのコミュニティ活動の可
ユメのチカラ: カジュアルなコミュニケーション
昨日はTLF (The Linux Foundation)のシンポジウムだったのだけど、仕事にはまっていて、キャンセルしてしまった（残念）。そしたら@itoh_bmarkからTwitterで体育館の裏までちょっと来いみたいな感じで呼びだされ、気がつくとTLFの懇親会会場にいた。セミナー本体にはいかないで、懇親会だけに居るというのも、どーよという感じがしなくもないが、重要な話は懇親会でされるという「宴会第二の法則」のとおり、その日も非常に示唆に富むお話が満載であった。 来年のLinux Kernel Summitをカーネル読書会がハイジャックするという件は、各所から非公式に打診されていて、がんばります。はい。 懇親会で、TLFのスポンサー企業の皆様とお話していて、よしおかさんたまにはブログ書いてくださいよとお願いされる。あれ、「はてな」の日記書いてますよ、と言うと、会社からは「はてな」ブロッ
ユメのチカラ: 若い人に人気のない産業は減衰する
未来をイメージできない産業に人は集まらない。IT産業は人がすべてである。魅力のない産業は減衰する。 IPAフォーラム2007 【討論会】 「学生から見たＩＴ産業」と「ＩＴ産業から見た学生」 ～ＩＴ産業は学生からの人気を回復できるか～ http://www.ipa.go.jp/event/ipaforum2007/program/discussion.html#tou-1 参加者がすごい。業界の重鎮。岡本晋氏（TIS株式会社 代表取締役社長）、浜口友一氏（社団法人情報サービス産業協会 会長、株式会社NTTデータ 取締役相談役）、藤原武平太氏（IPA 理事長）。 当日、このパネルディスカッションに参加していないので、下記の報道で様子を窺うしかないのであるが、「業界の重鎮もたじたじ」だったそうである。 IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ － ＠IT http://ww
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
