翔ソフトウェア (Sho's) Fujiwo の日記

社内で特許の勉強会．弁理士さんにお話を伺った．

• t-wadaの日記 ― ハンディサイズのホワイトボード

を読んで、取り敢えず A3 のホワイトボードを買ってきた。
千円くらい。

また、

• ぁまんぁまんニッキ ― A4裏紙＋クリップボード

を参考にクリップボードも買ってきた。

明日から少し試してみるつもり。

ちなみに、これまでは、二人の時は A4 コピー用紙、それ以上の時は普通の大きなホワイトボードを使うことが多かった。

A4 コピー用紙だと、三人以上で覗き込むには狭い。
A3 のコピー用紙だと、ペンを多少太いものにしないと視認性が悪い。
してみると、A3 ホワイトボードというのはいいかも知れない。

ただ実物を手にして思ったが、A3 というのは二人で机の上で使うには、少しでかくてごつい気がする。
さて実際にはどんなものだろう。楽しみだ。

# こうなると、ボードマーカーとイレーサーの良いのも欲しい。

■ Mozilla Firefox

最近は、Mozilla Firefox を使ってみている。

• Mozilla (英語)
• Mozilla Japan
• Mozilla Firefox (日本語)
• Mozilla Firefox まとめサイト

IE 等と比較して、ほぼ問題なく使えている。
そして、使い込む程に、徐々にではあるが楽しくなってきた。

Web ブラウザとして、多くの面で進化している。

Firefox は、機能や見た目をカスタマイズできるようになっている。
柔軟なコア部分を拡張部分が取り巻いている。
そして、更にこれから進化していくであろう、という期待を抱かせる。

こういう新しいものに接することは、「良いソフトウェアとは、例えばどういうものか?」ということを考える良い機会になる。

■ 良い道具とは

様々なユーザーがいる。様々な要望がある。
年年歳歳、環境は変化していく。新たな要望が、生まれていく。

一人一人のユーザーもまた、使い始めの時期があり、次第に使い慣れ、そしてその内、自己流の使い方を見つけていく。
徐々に使い方を変化させていくのだ。

使い始めの頃の「判りやすさ」・「使いやすさ」と使い慣れてからの「判りやすさ」・「使いやすさ」は違う。
使い始めの頃に便利だった機能が、使い慣れてからは邪魔な機能になることもある。
要らない機能は使わなければ良い、ではない。寧ろ、要らない機能は存在すべきでない。

道具に体を合わすのではない。道具が体に馴染んでいって一体感を感じさせるべきなのだ。そして、自分に合った道具を使う、という喜びを感じさせることができれば素晴らしいことだ。

■ ソフトウェアは良い道具になれるか

ソフトウェアにしてもハードウェアにしても IT 周りの道具は、今ひとつ使い勝手が宜しくない、とよく言われる。特にソフトウェアの使い勝手の悪さは、他の道具と比較されて指摘されることが多いようだ。

なにしろ、道具としての複雑さの違いがあるし、勿論、ユーザー側の歴史が違う。
なにより、道具としてのソフトウェア自身、まだまだこなれていないのだとは思う。

しかし、ソフトウェアは、可能性としては、すごいものを持っている筈(はず)だ。

普通の道具というのは、大概、作られた時点で機能や見た目が決まってしまう。
後付けの機能というのはそんなに期待できないし、後から見た目を変えることも余りできない。
つまり、こういう道具の機能や見た目は、静的(スタティック)バインディングであり、事前バインディングだ。

「良い道具の例」によくあげられる一眼レフは、あれは、Strategy パターンだ。
動的(ダイナミック)バインディングになっている。
インタフェースさえ合うものなら、使うときに機能を取り替えられる。

それに対してコンピュータという道具は、これは更に遅延(レイト)バインディングなのだ。
後付けの機能に対応する。
コンピュータがユーザーに与える利便性の多くは、後から「インストール」される。

Firefox のようなソフトウェアだって、先に見た通り、遅延(レイト)バインディングだ。
作り方によっては、後付けの機能や後付けの見た目に対応することができる。

使われ方が変化したり、どんどん進化したり、ユーザーの個々の希望に合わせたり。
そういうのはソフトウェアの得意技の筈なのだ。

ソフトウェアは、作り方により、とても良い道具になる可能性を持っていると思う。

■ 良いソフトウェアとは

「やりたいことが一応できる」ことが、品質ではない。
万人の平均を満たすソフトウェアが良いソフトウェアではない。
人々の欲する機能を一挙に搭載したソフトウェアが良いソフトウェアではない。

良いソフトウェアは、「変化を抱擁(ほうよう)」する。

今週土曜日は、福井のプログラマのコミュニティの忘年会に参加予定。

# まだ参加者募集中 & 歓迎だそうなので、参加希望の方はメール等ください。

福井のプログラマのコミュニティ「FPD (福井プログラマー伝説)」の忘年会に参加。

福井駅近くの居酒屋にて。

えちぜん鉄道で行ってえちぜん鉄道で帰ってきた。
都会では普通のことかも知れないが、福井では、往き帰り電車で飲み会に参加するのは、かなり珍しいパターン。

ていうか終電早過ぎ。

会の中で出た話で、自分も数年前から考えていたことだが、福井でも IT 技術者の横のつながりで盛り上がるのは、良いことではないだろうか。

それには、

• コミュニケーションの場
• ファシリテータ
• イベント

の三つが重要だと思う。

考えていきたい。

昔考えた圧縮/解凍アルゴリズム。
# 特許が切れたので公開 (嘘)。

■ この圧縮/解凍アルゴリズムの特徴

• 任意のファイルの内容を 32 bit 整数一個 に圧縮可能。
• 但し不可逆圧縮。テキスト ファイル向き。

■ 圧縮/解凍アルゴリズム

1. 道行くサラリーマンを一人つかまえて、ファイルの中身を読み聞かせる。
2. その人に電話番号を聞いて数字としてメモしておく。
3. 復元したくなったら、メモしておいた数字で電話を掛けて「あの時私何て言いましたっけ」と聞く。
4. 多分正確には覚えちゃいないだろうから「不可逆」。

■ 高品質版 (サービス パック 1)

1. 道行くサラリーマンを一人つかまえて、ファイルの中身を読み聞かせる。

を以下に差し替え。

1. 道行く東大出ていそうな若いサラリーマンを一人つかまえて、ファイルの中身を読み聞かせる。

■ セキュリティ パッチ (サービス パック 2)

2. その人に電話番号を聞いて数字としてメモしておく。

を以下に差し替え。

2. その人に電話番号を聞いて数字としてメモしておく。但しそれが電話番号である事は実の親にも明かさない。

# 現在 C#/.NET で実装中 (嘘)。

『Developers Summit 2005 (デブサミ2005)』が、セッションの登録申込み受付を開始した。

• 2005/2/3(木)～4(金)
• 青山ダイヤモンドホール (東京都港区)
• 主催: 翔泳社

デブサミは初回からずっと出ている。
今度のデブサミには特に期待している。

セッションのタイム テーブルをざっと見てみたが、どうしても聴きに行きたいセッションが沢山有る。

• 02/03 15:15～16:15
  【.NET】 「VB.NETは、テストファーストで行こう」
  
  中西 さん と 福井 さん が出るのか･･･ こりゃ聴きに行くしかないな･･･
  
  
• 02/03 15:15～16:15
  【プロジェクトマネジメント】 「技術系コーチング入門」
  
  本間 さん のコーチング入門か。コーチング興味有るし、これは聴きたい。
  
  
• 02/03 17:30～18:30
  【開発プロセス】 「デブサミ版『バグがないプログラムのつくり方』～テスト駆動開発によるペアプログラミング・ライブ」
  
  倉貫 さん が出るのか。これは是非聞かないと。
  
  
• 02/03 17:30～19:00
  【.NET】 「VB.NET vs C# 『.NET 言語合戦』」
  
  INETA Japan の企画… これには参加しなきゃ。
  
  
• 02/04 10:00～11:00
  【開発プロセス】 「オブジェクト脳をなぜつくるのか」
  
  平澤 さん と 牛尾 さん のコラボレーション。きっとすごい。とても聴きたい。
  
  
• 02/04 10:00～11:00
  【.NET】 「楽になりたい貴方のための ASP.NET 再入門」
  
  小川 さん が出るセッション。ASP.NET もずっと勉強してるしな。このセッションも是非。
  
  
• 02/04 13:00～14:00
  【.NET】 「ASP.NET 実装パターンとデータセットインターナル解説」
  
  こちらは、森屋 さん のセッション。ASP.NET の実装パターンは興味ある。
  
  
• 02/04 15:15～16:15
  【開発プロセス】 「ソフトウェア開発の「見える化」」
  
  平鍋 さん のセッション。明日のオブジェクト倶楽部 クリスマス企画 と同じテーマ。こりゃあ聞き逃せないな。
  
  
• 02/04 15:15～16:15
  【.NET】 「My Framework 作成の勧め：アプリケーションを30個作る時に何を用意するか」
  
  arton さん のこれは必見だな。今丁度 My Framework の試作をしているところだし。
  
  
• 02/04 17:30～18:30
  【開発プロセス】 「ファシリテーション入門」
  
  本間 さん のファシリテーション入門。これは絶対楽しいだろうな。きっと素敵な体験になる。
  
  

このリストのスピーカーは、知人または直接お話をしたことがある方ばかり。そして、どれも興味深い内容。
どうしても聴いてみたい。

他にも聞き逃したくないセッションが結構ある。
それにまだスピーカーが未定のところが沢山ある。今後も要チェックだな。

しかし… それにしても見事に時間がぶつかりまくり。
参った。
どうしよう。

    // Data data2 = data1; --- (1)
    // (1) だと何故かうまく動かないので下に修正。
    // ― 2004/11/23 Bill
    /*
     *   「何故かうまく動かないので」ってなんだよそれ (泣)。
     *   ― 2004/12/04 Yoshi
     */
    // 下のコードにすると、ちゃんと動くんです。
    // 確認済み。― 2004/12/06 Bill
    /*   ていうか、コピーコンストラクタの方
     *   確認するだろ、普通。
     *   ちゃんとやってよ。もう (泣)。
     *   ― 2004/12/07 Yoshi
     */
    Data data2;
    data2 = data1;

    class Foo
    {
        private int i; // i とは決して公開しないこと
    }

chikura さんのところで「第3回ITベンチャー交流会」のことが紹介されていた。

「『百式』を運営する田口　元氏をお招きしてのセミナー&交流会」とのこと。
『百式』メールマガジンは私も購読している。
特に参加制限はないとのことなので、申し込んでみた。

• 2005/01/21(金) 17:00～20:30
• 福井県産業情報センタービル　会議室A・B 及び　レストラン「グレイズ」(2F)
• 参加料 1,000円

今年は、福井のIT技術者間の横のつながりを強めて行きたいと考えている。
こうした交流会参加も含め、色々と活動してみたい。

以下を開催します。
是非ふるってご参加ください。

※ 前回も書いたことですが、今年は、福井のIT技術者間の横のつながりを強めて行きたいと考えております。
※ FITEA ― 福井情報技術者協会 を立ち上げ予定です。
※ イベントや FITEA へのお問い合わせや参加のご希望などありましたら、私あてでも構いませんのでお気軽にどうぞ。

昨日、『第3回ITベンチャー交流会』に参加してきた。

第一部は、『百式』を運営する田口 元氏のセミナー。
「人と違った発想は、人と違った情報源から。超人気メルマガ&サイト『百式』管理人が語るビジネスを成功につなげるための発想術とは」というテーマ。
実際に田口氏が『百式』で行ってきた、

• 「専門家」としてインターネットで取り上げられるには
• 取り上げられ続けるには
• 情報収集の方法

のかなり具体的なノウハウが語られた。
また、

• 2005年は、どのように情報発信していったら良いのか

についても、語られた。

どれも、なるほど、と思えるもので、今後 Web 上で情報発信していく上で、大変参考になった。
また、田口氏の成功するための発想パターンの一端を伺い知ることができたように思う。

第二部は、立食形式の交流会。

短い時間 (一時間半) だったが、どんどん二十人位の人と話した。
初対面の人が多かったが、日頃よく参加するようなセミナーと異なり、様々な職業の人がいらして興味深かった。

また機会があったら、参加したい。

前にも、書いた『ソフトウェア技術者サミット in 福井』ですが…

chikura さんとこで、楽しい紹介を書いて頂きました。

• 福井プログラマー生活向上委員会 ― 福井のIT技術者さん、1/31に会いましょう。

中々楽しい有意義な会になりそうです。
お近くの IT 関係の方は是非ご参加ください。

「プログラマー ヒロシです」というネタを書いてみた。

• 翔ソフトウェア (Sho's) Wiki ― 【ソフトウェア開発】プログラマー ヒロシです

1. 『アジャイルプロセス協議会の活動内容と今後の展望について』フリーITコンサルタント 北野 弘治 氏 特別出演 ギターSE 氏
2. アジャイルプロセス協議会 セミナー『アジャイルプロセスのもたらすインパクト ―ソフトウェアとビジネスの本質的困難をのりこえる知識主導型の経営、組織、プロセスについて考えよう―』 株式会社一 大槻 繁 氏
   
3. 福井情報技術者協会 発足セミナー『今こそ、立ち上がろっさ。ソフトウェア大国福井を目指して!』 福井情報技術者協会 準備委員会
4. アジャイルプロセス協議会 セミナー『リーンソフトウェア開発と「見える化」』 株式会社永和システムマネジメント 平鍋 健児 氏
   
5. 交流イベント『ソフトウェア開発の成功・失敗の意外な要因』
6. 懇親会
   
7. 二次会

北野さんの挨拶でスタート。北野さんのアイディアで、アイス ブレーキングとして、ギター SE 氏がギター持参で特別出演。ソフトウェア技術者を斬ってもらった。

私は、福井情報技術者協会 発足セミナーと交流イベントで司会をした。
話しながら、観客席側を見ていたら、なんか妙に大きいビデオ カメラで撮影している人がいる。
後で名刺を渡されて気付いたが、FBC (福井放送) の人だった。
夕方の FBC のニュースで流れたそうだ。
まさか TV 局が取材に来るとは思わなかった。誰も直接は声を掛けていないはず。

それにしても、大槻 さん と 平鍋 さん の話は良かった。実装者だけでなくソフトウェア開発全体を広い視野でみていて、しかも、具体的な解が用意されている。とても刺激的な話だ。
実は、今回のテーマのお話をお二人から伺うのは、とある東京のイベントに次いで二回目。
これから、福井でもこのような講演が聴けるようにしていけたら、と思う。

実は数年前から、こうしたソフトウェア技術者向けのイベントを福井で開催したいと思っていた。こうして、アジャイルプロセス協議会 さん のおかげで実現できたことは感無量だ。

福井・石川にもアツイ技術者がいることが判ったこと、そして、その人達と沢山の話ができたことは、とても良かったと思う。
イベント中、懇親会、二次会と話したが、まだまだ話し足りないくらいだ。

この体験を、是非次の行動につなげていきたい。

参加された方のエントリー:

• 福井プログラマー生活向上委員会 ― 福井の情報技術者のパワーが炸裂


• からくり屋Blog ― ソフトウェア技術者サミット in 福井


• keke log ― 050131 ソフトウェア技術者サミット


• 人生　伊達と酔狂 ― ソフトウェア技術者サミット in 福井

上記に参加してきたので、レポートしてみたい。

■ 詳細

■ はじめに

デベロッパーズ サミットの開催期間には丁度、寒気団が日本上空に来ていた。
北陸地方は、今年一番の大雪で、出発前日の午前中には羽田行きが飛ばなかったこともあり、無事会場に行けるかどうかが先ず心配だった。

当日の朝は、五時半に自宅を出発した。道には新雪が積もり、ちょっと油断するとすぐスタックしてしまう。
高速道路もすっかり凍っている。凸凹の路をゆっくりと走った。

それでも小松空港には随分早くついた。INETAJ のイベントに一緒に出る杉下さんも、たまたま飛行機が同じで、同じ頃に空港にいらした。
心配した飛行機は定刻通りに出発し、定刻通りに羽田に到着。予定通りに会場につくことができた。ほっと一安心。

さて会場に入ると、すごい人の行列。
二日間会場の青山ダイヤモンドホールは大変な人で、歩くのに苦労した。

デベロッパーズ サミットには、最初の年から毎年参加しているが、参加するたびに良くなっている。
特に今回は、楽しみなセッションが盛り沢山で、選ぶのに迷うほどだった。

ただ、昨年も感じたことだが、あの Web からの申し込みのユーザー インタフェイスはちょっと「いけてない」気がする。
あれは本当にユーザーの方を向いた UI と言えるのだろうか。
ユーザー側の関心事に対してではなく、主催者側の関心事に対して UI が設計されているように感じた。

• 主催者側の関心事 : 各セッションに何人の人が参加しようとしているのか。どういう人が参加しようとしているのか。
• ユーザー側の関心事: 自分がどのセッションを何時受けるか。申し込み/変更/キャンセルの方法。

今回の参加者、即ちデベロッパーにとっては、ユーザーの視点・ユーザーの関心事に合わせるのがデフォルトだから、多分違和感有りまくり。

でもまあ、その他の面では大満足。とっても良いイベントだった。
デベロッパーが中心というのが実に良い感じ。

このイベントのサブタイトルに「デベロッパーの復権」というのがある。
この趣旨には大賛成。
日本のデベロッパーも、もっと楽しく自信に満ちて物作りをして良い。

■ 参加内容

○ XP事例カタログ
大熊 知栄 氏、猪狩 錦光 氏、関 将俊 氏、小倉 唯克 氏

四年の歴史を誇る XPJUG (日本 XP ユーザグループ) で紹介されてきた XP プロジェクトの中から三つの例が紹介された。

すごい人で立ち見がでている。

大熊 さんの司会に始まり、三人の発表者が順に XP 事例の紹介を行った。

関 さん の発表は、XP 祭り 2004 で 関 さん が発表された内容「三年目の報告」(サブタイトル「XPが良いか悪いかなんて話は もうしないよ。」) だが、マイナー バージョンアップしていて「その後」が少し語られた。題して「3.5年目の報告」。「忍者式テスト」など、独自に XP をカスタマイズされている。
二人目の方はゲーム業界での XP。単純作業などのときに使う「ペアプロ解除」というプラクティスが興味深かった。

お二人とも開発者として、XP をやっていく中で現実的な解をいくつも見つけている。
また、回顧をよくやっていて、次にフィードバックしている。

今回特に良かったのは、顧客側からの XP プロジェクトの発表があったことだ。
以前見たことのあるバーンダウン チャートが顧客側視点で語られた。
これは結構目から鱗で、視点が変わると随分違って見えるものだと思った。

○ 失敗から学ぶプロジェクトマネジメント
伊藤 健太郎 氏

XP だけでなく、プロジェクト マネジメントについても学ぶ必要があるだろう、ということでこのセッションを聴きにいった。

• プロジェクトの失敗原因は? → プロジェクト マネジメントの進化のさせ方

という内容のセッション。
プロジェクトの失敗原因で、

• プロジェクトを KKD (勘と経験と度胸) で実施

というのが印象的だった。

ソフトウェア開発の場合、QCD (Quality: 品質・Cost: コスト・Delivery: 納期) のマネジメントだけでは、中々プロジェクトの成功に結び付かない、とよく言われているようだが、プロジェクト マネジメントも進化しているようだ。

講演中、プロジェクト マネジメントによるプロジェクト成功のための様々なキーワードが使われたが、「いけてる」と思ったものを私の独断であげてみる。

• いけてるキーワード:
  • コミュニケーション
  • モチベーション
  • キャリアパス
  • ナレッジ マネジメント
  • メンタリング

ところで、はじめの方で「是非このセッションが思い出に残るように」とのことで、「プロジェクトの失敗について隣の人と話してみよう」という時間があった。
アイス ブレーキングなんだろうが、これはちょっといけてない。余りにも唐突で中途半端な感じ。

○ .NETでアジャイル ペアプロ ライブ! ～VB.NETはテスト ファーストで行こう!
中西 庸文 氏、福井 厚 氏

「ドットネッターでアジャイラーで TDDer (謎)」になるための方法について。

最近は、Java の開発者に比べてアジャイルに馴染みが薄い .NET の開発者の人たちにもアジャイルな開発を知ってもらいたいという趣旨の講演や記事が漸(ようや)く増えてきたようだ。
嬉しい限りだ。

さてこのセッションだが、なんと終始関西弁。
ペア プレゼンになっていて、会話形式で説明が進められていく。

圧巻は途中二回の「ペアプロ笑劇場」と題したペアプロ ライブ。
若手アジャイラーとアジャイル未経験なベテラン先輩開発者という設定で、テスト ファーストなペアプロを行う。
で、このペアプロが TDD で且つ TDD (謎) なのだ。

前者の TDD は、勿論テスト駆動開発 (Test Driven Development) のこと。アジャイルではお馴染みの手法だ。
後者の TDD (謎) は、ツッコミ駆動開発 (Tsukkomi Driven Development)。
テンポの良いボケとツッコミによって、開発が進められていった。このテンポは関西弁ならではかも。

※ ちなみにツッコミ駆動開発にもペアプロは必須。
※ 一人でぶつぶつとボケとツッコミをしながらプログラミングされるのはかなり嫌だ。

面白いのは、ペアプロなので、ドライバー役 (キーボードでプログラムを書く方: リアルタイム コード レビューア) とパートナー役 (ドライバーのコーディングを見ていてリアルタイムにフィードバックを行う) があるのだが、パートナーがボケてドライバーがツッコんでいたりする。

二回目の「ペアプロ笑劇場」では、Mock (擬似オブジェクト) によるテストも紹介され、技術的にも興味深かった。

このセッションを聴き終わって考えたこと:
これは私の経験則だが、アジャイルな人というのはアジャイルな講演をする。
見ていて感動が有る。
プレゼンテーションが濃いのだ。

コミュニケーションの帯域が違うのだ。時間当たりに伝わる情報量が違う。
これは、沢山話して言葉数を増やす、ということではない。沢山のパワーポイントを用意する、ということでもない。

発信側でなく受信側の情報量を増やすのだ。
新しいアイディアというものは、いくら言葉数を増やしたって伝わらないものは伝わらない。
見せる工夫、伝える工夫をしなければ。

私はこれを Broadband Communication と呼びたい。

仕事でも多分同じだ。

例えば、

• 「プロジェクトの失敗の主な要因はコミュニケーション エラー」

という問題提起があるとする。先のプロジェクト マネジメントのセッションでもこれはあげられていた。

でそれに対する解。プロジェクト マネジメントのセッションでは、

• 「コミュニケーションは『お仕事』なんだからしっかりやらなくちゃ」

ということだった。

でも「プロジェクトの失敗の主な要因はコミュニケーション エラー」という問題提起に対して、しっかりやるべきなのは自明であって、それだけでは不十分なのだ。
そこには「見える化」など実践するための工夫がなければならない。アジャイルな人たちはそこが上手だと思う。

○ INETA Japan Presents VB.NET vs C# 『.NET 言語合戦』
河端 善博 氏、東海林 秀晃 氏、小野 修司 氏、石野 光仁 氏、菊池 和彦 氏、小島 富治雄 氏、福王寺 聡明 氏、杉下 朋年 氏、中西 庸文 氏、片岡 真二 氏、樋口 忠洋 氏、Hollytown 氏

Visual Studio .NET 2003 になってからは、VB.NET と C# はそれほど使い勝手に違いがなくなりつつある。2005 では更に優劣がなくなる。
その中で、VB.NET と C# のそれぞれの長所をあげて、双方の使いどころについて考えてみよう、という趣旨のイベント。
別にどっちを使っている方が偉いかを競う訳ではない。

INETA Japanは、.NET のコミュニティのコミュニティだ。
私は、パネラーの一人として参加。C# 側。

ライブで VB.NET と C# のそれぞれで七並べの戦略部分をプログラミングし、その場で対決した。
お客さんは勝つと思う方に投票し、勝負の結果により、アマゾン ギフト券や PSP などが当たる。全員に参加賞もあたる。

パネル ディスカッションは、どうやら C# 側が劣勢な儘(まま)終わってしまった。折角 C# 側のパネル リーダーの小野 さん が頑張ってくれてたのに。残念。
C# を応援してくれてた参加者の方はさぞやきもきしたことだろう。
というか、VB.NET 側のパネル リーダーの杉下 さん のプレゼンが良過ぎた。

反対にプログラミング ライブの結果の七並べの対戦では、C# 側が終始優勢だった。

商品の効果かも知れないが、全体としては結構ほんわかと盛り上がっていたようで、コミュニティ色が出ていて良かったのではないだろうか。

○ My Framework作成の勧め：アプリケーションを30個作る時に何を用意するか
arton 氏

或る業務に関して、沢山アプリケーションを書くのであれば、その業務に特化した良いマイ フレームワークを自分で書いた方が良い、というお話とその作り方のお話。

arton さん のお話は、理論的で且つとても判り易い。

• フレームワークって何のことだったのか。
• 作ると何がうれしいのか。
• 良いフレームワークってどういうものか。
• そして .NET 上で作る方法は。

arton さん の独特の語り口は、とても説得力がある。

フレームワークの作り方の話は特に技術的に興味深かった。

パラメータ、プッシュ モデル (Tell) /プル モデル (Ask)、依存性注入 (Dependency Injection) などの実際の実装方法を、C# のソースをデバッグ実行しながらデモで見せてくれた。

リフレクションで仮引数名で検索してみせたり、実行時にコンパイラを呼び出してパラメータを評価させたり、自作の DI コンテナを使って依存性注入を実際にやってみせたり、ととても楽しめた。

※ ちなみに、このソース コードは公開されている。

○ フレームワークの効能と、.NET導入事例紹介
三部 雅法 氏

.NET Framework 上でのフレームワークの紹介とその導入事例の紹介。
自社製フレームワークの説明という感じ。

○ セッション参加者のパーティー (懇親会)

一日目の夜は会場でパーティーがあった。
デベロッパーズ サミットの場合は、他のイベントと比較して広い分野から参加者が集まっている。
で、層としては技術者が中心。
なんか縦割りでなく横割な感じで新鮮だった。

例えば、ドットネッターとアジャイラーは日頃それ程イベントでかぶらない。
今回はあちこちでドットネッターとアジャイラーが名刺交換する風景が見られた。

私も、多彩な人とお話ができて実に楽しかった。

○ 二次会

懇親会を途中で抜け出して、ドットネットな方々 (INETAJ・MVP) と原宿辺りで二次会。

○ その他

二日目の午前中は、INETAJ のリーダーズ ミーティングに参加した。
マイクロソフト 新宿オフィス。
その後 INETAJ の方々と食事会。

■ 人とのつながり

今回も多くの方々と話すことができた。
イベント参加の一番の収穫。

• 今回デブサミで初めて直接ご挨拶できた方々 (50音順):
  小野 さん、菊池 さん、国広 さん、関 さん、田中 さん、原 さん、樋口 さん…
• デブサミで再会できた方々 (50音順):
  arton さん、天野 さん、石野 さん、市川 さん、岩切さん、牛尾 さん、大熊 さん、太田 さん、小野 さん、沖田 さん、角谷 さん、懸田 さん、片岡 さん、河端 さん、倉貫 さん、小井土 さん、児玉 さん、佐藤 さん、渋木 さん、東海林 さん、杉下 さん、中西 さん、平澤 さん、平鍋 さん、福井 さん、福王寺 さん、松本 さん、水越 さん、堀田 さん、安井 さん、吉原 さん、和田 さん…
• 同じデブサミ会場にいらしたのに再会できなかった方々 (50音順):
  北野 さん、本間 さん、森屋 さん、和田 さん…

※ お会いしたのにお名前のもれてる方、すみません。ご指摘頂けると幸いです。

■ 関連リンク:

• @IT ― ユーザーに泣かされないITコンサルになるには
• @IT ― バズワードの連発は控えめに
• @IT ― マイクロソフトが提供する開発指針「MSF」とは何か? ―― 翔泳社デブサミ2005 セッション・レポート ――
• MyMy-MyCompany ― デブサミ2005 レポート
• Chronicler わらわらのつぶやき ― [IT]デブサミ2005
• Chronicler わらわらのつぶやき ― [IT]デブサミ2005（第２日）
• Matzにっき ― デブサミ2005 (1日目)
• Matzにっき ― デブサミ2005 (2日目)
• khiramatsuの日記 ― [セミナー]デブサミ2005 2日目
• +++ study room +++ ― [event]Developers Summit2005
• mattena31の日記（主にSeasar2） ― [お勉強]デブサミ
• seraphyの日記 ― デベロッパーサミット2005にゆく
• トアル電算室ノ業務日誌 ― デブサミ行ってきました。（下書き）
• sisonoの日記 ― [その他] デブサミ
• 日々の破片 ― デブサミ終了
• いつまでも構想中 blog ― デブサミINETAJセッション無事終了
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話その１
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話その２
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話その３
• ぺがらぼ Blog ― INETAJ] デブサミ2005 VB.NET vs C# 『.NET 言語合戦』裏話最終章
• jkondoの日記 ― デブサミ
• ぁまんによニッキ ― デブサミ
• ぁまんによニッキ ― デブサミ2日目
• J.Matsumotoの日記 ― デブサミ2005
• J.Matsumotoの日記 ― デブサミ懇親会と二次会
• PM見習いの読書日記 ― [dev]Developers Summit 2005 感想
• Ryo.Matsudaのほろ酔い徒然 ― [開発] デブサミ2005
• Studio Dragon Private Editon ― 馬場 経由 表参道行き
• hayashihがOSをインストールする日記 ― Developers Summit デブサミ2005 １日目
• hayashihがOSをインストールする日記 ― Developers Summit デブサミ2005 ２日目
• Miya's Weblog ― [セミナー]デブサミ2005
• ★ B. T. T. P ★ ― Developers Summit 2005
• 【よーたか】の日記 ― デブサミ
• UnsupportedOperation ― [Seasar]Developers Summit
• すがるの4004年の歴史 ― デブサミ
• あじの日々 ― [etc] Developers Summit 行ってきた
• atene1968の日記 ― [コンピュータ]Java Studio Enterprize
• 紺バージョン ― ■ めも
• nitsujiの日記 ― [仕事]デブサミ2005
• アピラクンの日記 ― デブサミ終了
• やしな日記/shayash ― デブサミ2005
• ふぇみにん日記 ― [Ruby][OSS] Developer Summit 2005 (1 日目)
• ふぇみにん日記 ― [Ruby][OSS] Developer Summit 2005 (2 日目)
• @江青日記 ― 2005-02-05 ― [デブサミ2005]みなさんの日記をたどって

私のサイト内の Wiki に、いつの間にかこんな頁ができていた。

• こんなプロジェクトチームはいやだ

面白いので、20個ばかり追加してみた。

興味の有る人はふるってご参加ください。
参加希望は福井情報技術者 交流掲示板 (FITEA BBS) まで。または私にメールください。

上の写真は、私が愛用しているキーボード、PFU HHK。

最近、この HHK に新色が登場した。

その名も「墨」。

「墨」という名の通り、真っ黒ではなく微妙な色合いで木炭でできているかのように見える。
キートップも含め、見える範囲に文字はない。
※ 無刻印モデルの場合

HHK 好き、且つ、一人暮らしの頃一時炭火で自炊していた程木炭好きの私としては、とても欲しい。
出来ればペアプロのときも、これを持参したい。

いずれ誘惑に負けて買ってしまうかも知れない。

さて、ペアプロのときに持参したいキーボードと言えば、もう一つ次のもの。

DataHand キーボード。実売価格 ¥108,000!
一家に一台、どないだ。

ついでに以下で、他にもペアプロ向き (嘘) のキーボードを色々とあげてみよう。

に行ってきた。

七人の参加。
XML や CSS、Web アクセサビリティ等、Web 関係の技術の話で盛り上がった。
福井でのこうした横のつながりも大変楽しい。
技術の話で盛り上がるのは、とても好きだ。

今後もこのような交流を行っていくところから、FITEA の活動も行っていきたいと思う。

時期柄か、デスマーチや病気が原因で来られない方も多く、それはちょっと残念だった。

夜七時から始まって、十一時に近くなるまで飲んでいた気がする。
やや飲み足りない感があったので、更に二次会まで行ってしまった。

ところで、先週から五週連続で毎週別の集まりでの飲み会がある。
私としてはかなり珍しい状況。
# 家族からは、ちょっと苦情が出始めているような感じ。

4/30 夕方からは、FITEA 準備委員会のミーティングに参加。

これから色々と、福井の IT 技術者を元気にするための活動を行っていきたい。

『北陸ソフトウェア技術者ネットワーク (Hose-net) 創立イベント』に参加してきた。

金沢までは JR を利用。
久々に金沢駅東口に来た。
以前は、年に五百回位利用していたこともある金沢駅東口だが、すっかり様子が変わってしまった。

なんだか格好良いぞ、金沢駅。
一寸感動。
そう言えば福井駅も新しくなりつつあるのだが。

駅から 15 分程歩いて会場へ。

会場に着いてみると、スーツ姿の方が大半。
「あれ? ソフトウェア エンジニアのコミュニティのイベントだよね?」
技術者のコミュニティのイベントだと、カジュアルなものが多いので、ちょっと違和感。

全部で60名位だろうか。年齢層は高め。男性ばかり。
大学の方が結構いらした。

FITEA のイベントに参加して頂いた方も四名位いらして、お話をさせて頂いた。

内容は以下の通り。

1. 創立についての説明
2. 講演『ソフトウェア産業の競争力を考える ～ソフトウェアの品質と生産性を向上させる鍵は何か～』

   富士通総研 経済研究所 主任研究員 前川 徹 氏

   とてもアジャイルな考え方の方だった。
   講演の中で印象に残った言葉を幾つか羅列してみる。

   • ウォーターフォール モデルは間違いだ!
     • ウォーターフォール モデルでは、最初の要求定義の正しさの検証が、最後の受け入れテストまで行われない
   • 「先に計画を立て、その通りに実行する」で正しいのか?
     • 「一度も登ったことのない山を、計画通りに登山する」で良いのか?
   • 動くソフトウェアが一番重要
   • ソフトウェア エンジニアリング (CMM など) で日本のソフトウェア業界を救えるのか?
   • ソフトウェア工場は「アナロジーの罠」: 不適切なアナロジーは危機をもたらす
   • 考えるべきことは全て考慮し文書化 → 実際に動くものでフィードバックを得る
   • 「出来ないプログラマの方が給与が高い」で良いのか?
     • 最初に逃げ出すのは優秀なプログラマ
   • 良い客が良い店を育てる
     • 良いレストランが見分けられない「安ければ良い」客ばかりでは良い店は育たない

   一時間半の講演だったが、とても楽しく聴くことが出来た。
   

3. 形式手法の一つであるモデル検査 (ソフトウェア検証方法の一つ) のツールの施行者の募集
4. グループ ディスカッション

   10～12人×5グループに分かれてグループ ディスカッション。
   テーマは Hose-net に期待すること。Hose-net でやりたいこと。
   

次回は、富山でやるそうだ。今後に期待して行きたい。

技術系のメーリング リストや掲示板で、いつまで経っても同じような質問をする人がいる。

「初心者ですので教えてください。×××したいのですがうまく行きません。分かる方、教えてください」

この質問に誰かが答える。「×××するには、このようにします…」
すると、また似たような質問が来る。

「初心者ですので教えてください。○○○したいのですがうまく行きません。分かる方、教えてください」

何故いつまでも同じような高さの壁にぶつかっているのだろう。

「×××したいのですがうまく行かないので、コツを教えてください」

これは、

「私の目の前の問題を一刻も早く解決できるような手っ取り早い方法を教えてくれ」

という意味だ。
例えれば、

「頭が痛いので、頭痛薬をください」

と言っているようなもの。頭痛薬の効果が切れたら、また頭痛薬を欲しがることになる。
本当に問題を解決する道は、頭痛薬を飲み続けることではない。先ずは、頭痛の原因となっている病気について知ろうとすることだ。それでやっと問題解決のスタート地点に立てるのだ。

「×××や○○○がうまく行かない」状態と「×××や○○○がうまく行く」状態の差。それがこの人が抱えている問題だ。
それは本当は、「基本的な事柄がマスター出来ていない」ということかも知れない。
そして、それが本当の問題であれば「×××のやり方を教えてもらうこと」は、真の解決法ではないのだ。

「問題は何か?」から目をそむけていては問題は解決しない。

『ソフトウェア・テスト PRESS』という本が出るようだ。

予約注文してみた。

「ITアーキテクト」という本が出るようだ。

目次を見ると、「エンタープライズ アーキテクチャ パターン」、「要求開発」、「プロジェクト・ファシリテーション」、「開発プロセスの最適化」のような言葉が並んでいる。

予約した。

最近、人に何かを教えることが多い。

これが中々難しい。例えば、C++言語の研修で、ポインタの概念がどうしても判らない人にそれを教えたり、クラスが理解できない人にクラスについて教えたり。
自分で使いこなせてるつもりの技術でも他人にそれを教えるのは難しい、ということをつくづく感じる。

ここで、私が私の師匠 (誰) から教わった言葉をひとつ。

自分で使うのに比べて他人に使い方を教えるのは、三倍の理解が必要だ (当社比)。

つまり、自分が使える、という段階より、他人にそれが教えられる、という段階の方が大分知識の習得レベルが高いわけだ。

指導する側には指導される側に対して、段位にして三倍ないと教えられない、ということ。それが『指導者三倍段』だ。
# ちなみに、大山倍達が言っていたのは『剣道三倍段』 (謎)。

参考までに、様々な技術習得の段階についてあげてみる。

■ ソフトウェア技術習得のレベル分類

• 段階 1 : 無知の段階 ― その技術について聞いたこともない
• 段階 2 : 気がかりな段階 ― その技術について文献を読んだことがある
• 段階 3 : 見習いの段階 ― その技術について三日間のセミナーに通った
• 段階 4 : 実践しようとする段階 ― その技術を実際のプロジェクトに適用しようとしている
• 段階 5 : 職人の段階 ― その技術を仕事の上で自然に自動的に使っている
• 段階 6 : 名人の段階 ― その技術を完全に消化していて、いつルールを破るべきかを知っている
• 段階 7 : エキスパート ― 専門書を著作し、講演し、その技術を拡張する方法を探究する

■ 「守・破・離」

人や本などから何かを学び、ひとり立ちしていくまでに、『守』・『破』･『離』という段階を進んでいくと言われている。

• 「守」: 最初は教わった型を守り、型の通りにやる
• 「破」:教わった型通りでなく、自分なりに変化させていく
• 「離」:最後には型を離れて独自のやり方を作り出し、行う

■ 「識らない」の順位

• 1 : 無知の欠如 ― 何かについて識っていて、それを使うことが出来る
• 2 : 知識の欠如 ― 何かについて識らないが、識らないことを識別している
• 3 : 認識の欠如 ― 何について識らないかを識らない
• 4 : プロセスの欠如 ― 何について識らないかを識らない、ということをどう解消したら良いかを識らない
• 5 : メタな無知 ― 「識らない」とはどういうことか識らない

■ ソフトウェア職人の称号

• 翔ソフトウェア ― ソフトウェア職人の称号 （謎）

プログラミングの入門時には、取り敢えず以下を守ってもらうことにしている。
※ 言語は一応 C++

或る程度プログラミングになれるまでの間は、無茶なコードを書きがちなので。

「プログラミングの心得」

• 一、同じものには同じ名前をつけるべし。
  
  • ネーミング重要。統一感を大切に。


• 一、同じコードは三回以上書かないこと。


• 一、関数の長さは、平均で10行以内 (最大でも20行を越えない)。


• 一、グローバル変数は禁止。


• 一、メンバー変数は private。


• 一、what → how の順番で書く。
  
  • 何をするのか → どうやってするのか、の順。
  
  
  • インタフェイス → 実装、の順。


• 一、コメントで安易に説明しない。コードに説明させる。


• 一、マジックナンバーの禁止。


• 一、コーディング標準に従う。