翔ソフトウェア (Sho's) Fujiwo の日記: February 2005 アーカイブ

« January 2005 | メイン | March 2005 »

February 26, 2005

第4回 ITベンチャー交流会

第4回ITベンチャー交流会
2005/02/24(木) 17:00～20:30
福井県産業情報センタービル

前回に続いて二度目の参加。

このイベントは第一部と第二部に分かれていて、第一部は、DREAMGATE『起業・独立の強化書』の著者の増田紀彦氏の講演。

福井の西武デパート近くの店や呉服町商店街の話からスタートし、以下のような独立・起業に関わるノウハウと事例が紹介された。

「事業の基本プラン『誰に、何を、どう売るか』」と「事業の実施プラン『いつ、誰と、いくら使って売るか』」は違う。
いけてる『誰に、何を、どう売るか』といけてない『誰に、何を、どう売るか』がある。
「起業したい」と「独立したい」と「今の職場がいや」は違う。
「ブログがはやっている→ブログで設けよう」ではなく「ブログがはやっている→ではどんなビジネスチャンスがあるのか」と発想せよ。
「事業家」と「経営者」は違う。自然の摂理が伴ってない基本プランの事業を、「経営」したって駄目。
『誰に、何を、どう売るか』がうまく行かなくなったら、『誰に』や『何を』や『どう売るか』のどれかを変えることで、いけてる事業になる例がある。
事業にお金を安易に投入するな。知恵を投入せよ。

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

前回のときにお会いした方や、『ソフトウェア技術者サミット in 福井』に参加して頂いた方と再会。
新たな知人もできた。

今回は、全部で 60名くらいの人が参加されていた。
結構様々な業種の人、年齢層の人が参加している。

第一部の講演でも、第二部の交流会でも、日頃参加するソフトウェア開発技術系のセミナーとは全然違う刺激を受けた。

今後も、時々こうして様々な人の話を聴いて、脳の色んな部分をつなげ、視点を広げるようにしたい。
良いアイディアは、狭い範囲のものの組み合わせからは出にくいからだ。

※ セミナーに参加された他の方のレポート:

投稿者 Fujiwo : 03:22 AM | コメント (0) | トラックバック

February 23, 2005

"Be Agile. That's my attitude."

ナジャイラ (NAgiler: ドットネッターでアジャイラーの意味) の中西さんの言葉。

いい。
実に良い。

強い言葉だ。

言い訳じみていないし、説得しようとしていない。

「こうあるべき」、「だからこんな風にしていくべき」なんていう「べき論」なんか寄せ付けない潔さがある。

凛とした感じ。自然体。

毛筆で書いて飾りたいという意見があったので、作ってみた。

投稿者 Fujiwo : 07:41 PM | コメント (6) | トラックバック

February 22, 2005

ハントンライスとタンバルライス

私の大好物にハントンライスというのとタンバルライスというのがある。
子供の頃はよく食べた。
しかし、ここ二十年では一回しか食べていない。

洋食の一種で、強いて言えば、それぞれオムライスとドリアに似ている。
でも、強いて言わなければ、何にも似ていない。ハントンライスはハントンライスだし、タンバルライスはタンバルライスだ。
ハントンライスのハンはハンガリーのハン、トンはフランス語でマグロを意味するそうだが、そんなこともどうでも良い。

はっきり言ってうまい。
十年に一度くらい、猛烈に食べたくなる。
丁度今がその十年に一度の状態だ。

何処にでもある料理ではない。
東京にも無いだろう。

しかしすぐにでも食いたい。

これはもう自分で作るしかないか。

ハントンライスのレシピ: COOKPAD ＊ハントンライス＊

投稿者 Fujiwo : 05:35 PM | コメント (4) | トラックバック

February 16, 2005

コミュニティのマニフェスト

コミュニティ活動を色々やる中で思い付いたので、ちょっとメモ。

■ コミュニティのマニフェスト

「私たちは、

『明文化された厳密で詳細な決まりごと』より『柔軟な臨機応変』、
『全ての問題が解決するまで始めない』より『先ずはやってみて結果をフィードバック』、
『入念な準備』より『変化への対応』、
『トップダウンなコミュニティ』より『ボトムアップなコミュニティ』、
『縦社会のコミュニティ』より『横社会のコミュニティ』、
『報告』より『双方向のコミュニケーション』、
『責任者の追及』より『言い出しっぺの法則』、
『どうあるべきか』より『どうしたいか・どうなりたいか』、
『責任感』より『ボランティア精神』
『義務感』より『自由な参加』

をより尊重します。
(前者も尊重するが、後者をより尊重する)

これは、理想を言っているのではありません。極めて現実的な解です。
全てを前以て厳密に決め厳密なトップダウンで実行、という方がはるかに理想を追っていて非現実的です。コミュニティなのですから」

# 複雑系 (Complex Systems) では初期の計画の精度を上げることは無意味 (謎)。
# 「全てを前以て厳密に決め厳密なトップダウンで実行」というのは、複雑系の問題を線形方程式で解こうとしているようなもの。

投稿者 Fujiwo : 12:01 AM | コメント (2) | トラックバック

February 15, 2005

C# Tips: 継承

今まで新人向けのオブジェクト指向の研修で、「継承」というのは、


    class Sub : Super
    {
    }

こういうのだ、とか説明してきたんだけど…

ごめん。この説明はちょっとごまかしなんだ。
説明が面倒だったから…

本当は、これは C# 言語の「派生」なんだ。オブジェクト指向でいう継承と同義じゃない。
これは、「『派生』という機能を使って継承を実装する」っていう C# のイディオムに過ぎないんだ。

他にも、オブジェクト指向の用語を C# にマッピングして説明するときに結構ごまかしてるんだ。


    Super  s = new Super();

オブジェクト指向っぽくこれを表現してみると、
「Super というクラスに new というメッセージを送ると s というインスタンスが作られた」
という感じかな。


    s.Foo();

これも、「s という名前のインスタンスに Foo というメッセージを送ると s はそれに応じた振る舞いを行う」という感じに表現できる。

でも、実は C# 的には、s はインスタンスじゃない。参照変数に過ぎない。インスタンスを参照してるだけ。インスタンスは別に在る。

これも、「クラスのインスタンスを参照変数で表現」っていう C# でオブジェクト指向をやる場合のイディオムを前提に説明しちゃってる。

用語の曖昧さを使って誤魔化していたんだ。説明すると長くなっちゃうからね。
本当は、どのレイヤの話をしているのか、明示すべきなんだ。

ごめんよ。

投稿者 Fujiwo : 02:40 PM | コメント (0) | トラックバック

C# Tips: interface を抽象クラス (abstract class) とどう使い分けるか

# 久々に技術ネタを書いてみる。
# と言っても、某掲示板で使ったネタの使い回し。

C++ にはなかった新しいキーワードとして、C# では interface というものが出てくる。 interface は、Java ではおなじみのキーワードだ。

例．


interface ICloneable
{
    object Clone();
}

interface では公開されているメソッドとプロパティの外見 (名前、パラメータ、戻り値) だけが宣言されていて、実装部分が定義されていない。実装部分は、その interface を実装するクラスによって定義される。

例．


class Employee : ICloneable
{
    private string name;

    public string Name

    {

        get { return name; }

        set { name = value; }

    }

    public Employee(string name)

    { Name = name; }

    public object Clone()

    {

        return new Employee(Name);

    }

}

interface は抽象クラス (abstract class) と機能的には似ている。
抽象クラスも、中身のないメソッド (abstract method) の宣言を持つことができ、そこから派生したクラスで、そのメソッドの実装を定義する。

例．


abstract class Person
{
    private string name;

    public string Name

    {

        get { return name; }

        set { name = value; }

    }

    public Person(string name)

    { Name = name; }

	public abstract void DoSomething();

}

class Employee : Person

{

    public Employee(string name) : base(name)

    {}

	public override void DoSomething()

    { /* Do good job. */ }

}

機能上の大きな違いとしては、

- 抽象クラスは、実装を持つこともできる。上記の例でいうと、name や Name や Person(string name)。
- interface は、実装が持てない。
- 抽象クラスは、二つ以上継承できない。つまり、多重継承できない。
- interface は、二つ以上でも継承できる。

というものがある。

しかし、機能上の違いでなく、使い分けるときの一般的な指針はないだろうか。

デザインパターンの一つである、State/Strategy パターンの場合で考えてみよう。
先ずは、抽象クラスを使った場合と、interface を使った場合の両方について書いてみる。

・抽象クラスを使った場合の例:


class Context
{
    State state = null;

    public State State

    {

        set { state = value; }

    }

    public void DoSomething()

    {

        if (state != null)

            state.DoSomething();

    }

}

abstract class State

{

    public abstract void DoSomething();

}

class ConcreteState1 : State

{

    public override void DoSomething()

    { /* 省略 */ }

}

class ConcreteState2 : State

{

    public override void DoSomething()

    { /* 省略 */ }

}

・interface を使った場合の例:


class Context
{
    State state = null;

    public State State

    {

        set { state = value; }

    }

    public void DoSomething()

    {

        if (state != null)

            state.DoSomething();

    }

}

interface State

{

    void DoSomething();

}

class ConcreteState1 : State

{

    public void DoSomething()

    { /* 省略 */ }

}

class ConcreteState2 : State

{

    public void DoSomething()

    { /* 省略 */ }

}

さて、State/Strategy パターンを使う場合、はたしてどちらが標準的なのだろうか。

「State/Strategy パターンを構成している部分だけ」を見ると、或る振る舞いに関する制約が付けられれば十分なので、interface が適しているような気がする。

但し、実際の設計では、

「State/Strategy パターン」を使おう → じゃ interface を使おう

とはならない。

それは、通常 State/Strategy パターンが適用される場合というのは、先ず (リファクタリングなりの結果としての) クラス設計があって、そこにおける抽象化すべきものがクラスなのか、振る舞いに関する制約なのかの判断があり、結果として「State/Strategy パターン」の形になるだけであるからだ。

つまり、抽象化したいのがクラスであれば抽象クラス、単なる振る舞いに関する制約であれば interface、という感じで使い分けることになる。

それから、もう一つ。
実装上の問題として、State/Strategy パターンなどが対象としている関心事が、既存のクラス階層と直交する関心事であった場合は、抽象クラスでなく interface を使う。多重継承ができないからだ。

例えば、始めの方の例でいうと、

等の継承によって形成される継承ツリー或るいはその他の継承ツリーが対象としている関心事と、ICloneable が対象としている関心事は直交している。

従って、ICloneable の方の関心事の実装には interface を使う。

これは、「アスペクトの実装を便宜上 (言語の都合上) interface で行う」というイディオムといえるかと思う。

尚、余談になるが、Strategy パターンの場合は、抽象クラスも interface も使わずに delegate を使う、というイディオムも有ると思う。

例．


class Context
{
    public delegate void DoSomethingMethod();

    DoSomethingMethod doSomething = null;

    public DoSomethingMethod OnDoSomething

    {

        set { doSomething = value; }

    }

    public void DoSomething()

    {

        if (doSomething != null)

            doSomething();

    }

}

用語解説:

インタフェイス (interface):

広義では、境界。或る纏(まと)まりと別の或る纏まりが接する点のこと。ソフトウェア開発では、或るモジュールが別のモジュールに公開している機能の利用方法を記述したもののセット。オブジェクト指向においては、特に、それを実装するクラスに必要なメソッドやプロパティ、イベントのセットを定義したもの。

ソフトウェアパターン (software patterns)

ソフトウェア開発のためのパターン。ソフトウェアを設計する際に繰り返し現れる経験的な要素を抽出したもので、効率の良いプログラミングをするためのテンプレート。「デザインパターン」、「アーキテクチャパターン」、「アナリシスパターン」、「アンチパターン」、「イディオム」等の種類がある。

デザインパターン (design patterns)

ソフトウェアパターンの一種で、OOD (オブジェクト指向設計) において、過去のソフトウェア設計者が発見し、編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したもの。

イディオム (idiom)

プログラミング言語やプラットフォームなど、実装レベルの問題に対するソフトウェアパターン。

関心事 (concerns)

ソフトウェアを構成する様々な要素のうち個別に着目することができひとまとめに扱うことのできる何か。

横断的関心事 (Crosscutting Concerns)

分割されたモジュールをまたがる関心事。例えば、「オブジェクト指向のパラダイムによって関心事の分離がなされたモジュール」間にまたがる関心事。

関心事の分離 (SOC：Separation of Concerns)

関心事を分離すること。関心事によってプログラムをモジュール分割すること。

アスペクト (aspect)

様々な視点からみた際に、関心事 (特に横断的関心事) として分離されるべきソフトウェアの持つ側面。

投稿者 Fujiwo : 12:00 PM | コメント (2) | トラックバック

February 12, 2005

橇遊び・スキー遊び

三連休で久々に天気が良いので、家族で福井県勝山の長尾山総合公園へ。

ここは家から車で30分くらい。恐竜博物館がある場所で、橇(そり) やスノーシュー、クロスカントリースキー、スノーモービルなどで遊ぶことができる。

子供らと橇とクロスカントリースキーをした。
娘は生まれて初めての雪遊びにはしゃいでいた。

投稿者 Fujiwo : 04:53 PM | コメント (5) | トラックバック

February 10, 2005

C# vs. VB.NET

2/3 に行われた Developers Summit 2005 ― INETA Japan Presents VB.NET vs C# 『.NET 言語合戦』のために集めたネタ (とイベント中で使われたネタ)。

【.NET】VB.NET 及び C♯ の良い点・悪い点

投稿者 Fujiwo : 10:02 AM | コメント (0) | トラックバック

February 09, 2005

デベロッパーズサミット2005

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

■ 詳細

Developers Summit 2005
日時	2005/02/03(木)～04(金)
会場	青山ダイヤモンドホール
主催	株式会社翔泳社
詳細	Developers Summit 2005

■ はじめに

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

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

それでも小松空港には随分早くついた。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音順):
北野さん、本間さん、森屋さん、和田さん…

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

■ 関連リンク:

投稿者 Fujiwo : 05:28 PM | コメント (8) | トラックバック

February 02, 2005

雪

明日は、いよいよデブサミ。

二泊は無理があるので、明朝行く予定にしていた。
朝行こうと思ったら、小松空港から飛行機しかない。

ところが、雪のため今朝の羽田行きは第一便から今まで全部欠航している。

寒波が来ていて、二月の頭から結構な雪が三日降り続いたため、北陸では JR や道路も含め、あちこちの交通機関に悪影響が出ている。

昨晩も、道は混んでいるは、一本道でトラックが側溝にはまっているはで、通常なら 10 分で帰宅できるところを、一時間も掛かってしまった。

天気予報によると、「3日午前6時までの24時間に予想される降雪量は、山沿いの多い所で、北陸が70センチ」だそうで。

ということで、デブサミに行く方法をちょっと考え中。

・朝起きて、居間から外を見る

・家々の様子

・車の様子

・息子の通学風景

・私の通勤風景

投稿者 Fujiwo : 10:15 AM | コメント (9) | トラックバック

February 01, 2005

ソフトウェア技術者サミット in 福井

『ソフトウェア技術者サミット in 福井』
日時	2005/01/31(月) 13:00～
会場	福井県産業情報センタービル 8F (福井県坂井郡丸岡町)
主催	アジャイルプロセス協議会見積り契約ガイドライン作成ワーキンググループ
共催	FITEA ― 福井情報技術者協会準備委員会

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

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

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

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

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

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

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

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

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

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

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

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

投稿者 Fujiwo : 03:57 PM | コメント (5) | トラックバック

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

日々の雑感など