Developers Summit 2006

 2/9, 10と2日間行ってきました。

1日目 2/9

  松本吉弘氏(京都高度技術研究所)

 シェフ・モードとコック・モードがあるよという話。シェフ・モードでは客が来なくってもメニューを開発する。コック・モードでは客が来たときにシェフが作ったメニューを元に料理を作る。シェフ・モードで投資を行って、コック・モードで回収する。
 SI企業内でもシェフとコックで分業していく必要がある。何よりも、どこに投資していくかということが決断できるコンピテンスを持った経営者、管理者が必要。要するに腹くくれやってこと。

  伊東大助氏(横河ディジタルコンピュータ)

 進捗は「否定」せず、まず「測定」。ソフトウェアのパフォーマンス改善を行うときと同じ。まず「測定」。その後は、「分析」して「フィードバック」。こんな基本的なことができてないんだよなぁ。
 作業マップって、マインドマップの発想ですね。コミュニケーション、フィードバックという言葉が出てきて、これってXPですね。

  • 楽々ERDレッスンLive 〜これが楽々DB設計の勘所!〜

  羽生章洋氏(スターロジック

 DB設計の勘所、よく分かりました。
 「DB設計を行うには、先にプログラムを勉強してください。SQLを勉強してください。」って話。コーディングのイメージ湧いてない人の設計ってすごく醜いもんね。同感です。
 「マスタを入力するのは誰か?ネゴって来い!!」って、痛いorz ユースケース図を書いていたら、マスタメンテナンスをどのアクタに繋げるのかということと同じ。線1本がすごく大事なんです。って、知り合いの建築士が言ってました。我々、ソフトウェアの技術者も線1本の重みを感じながら設計なり何なりをやる必要があると思いました。
 「生の題材で毎日DB設計する。」量は質に転化するってことですね。
 「コードを主キーにするな!」、「1:mでもFKをエンティティに入れるな!」って、納得です。
 「画面ごとにERDを作る」、「帳票から先に攻める」と、ノウハウがいっぱい聞けました。

  • OSSを活用したシステム構築の8つのポイント

  吉田行男氏(日立システムアンドサービス)

 OSS選定の基準8つ。

  鷲崎弘宣氏/太田健一郎氏/鹿糠秀行氏/立堀道昭氏

 ユースケースアスペクト指向ユースケース図では横断的関心事も1つのユースケースとして表されるから。ユースケース図を実装レベルにマッピングする際に、複数のクラスにばらさずに、アスペクトにするという話。
 セッションタイトルと同名の翻訳本が出るらしい。

  • アジャイルWeb-DB開発 −ツールを活用した効率的な開発

  杉本晋吾氏(エコス)

 コードジェネレータの紹介。
 DBのテーブルを作れば、そこからUIまで自動生成されるということだったので、発想としてはRuby on Railsみたいなもんですかね。

  平鍋健児氏/シュミッツ千栄子氏

 人生VSOP説はなかなか秀逸。

  • 20代 Vitality
  • 30代 Specialty
  • 40代 Originality
  • 50代 Personality

 あと数日でVitalityからSpecialtyになります。

2日目 2/10

  • エンジニアの生きがいとは? 〜マインドマップを使ったQoEL探検ワークショップ〜

  懸田剛氏(オブジェクト倶楽部

 初対面の人とグループワークするのってちょっと抵抗ありましたが、こういったセッションに参加する人は、そもそも参加意識が高い人なのか、盛り上がったと思います。
 グループワークして思ったことは、やっぱりみんな何かをして誰かに喜んでもらえたときにエンジニアになってよかったと思っているということ。誰かが、お客さんであったり、チームのメンバーであったりするわけですけど。ここで機能の平鍋氏の話と繋がって、目標を達成したときに誰にそれを伝えたいですか?っていうこと。喜んでもらえる人がいるってめっちゃ重要。

  • デブサミ2006!オフィシャルコミュニティによるLightning Talks

  小島富治雄氏/中西庸文氏/永安悟史氏/原嘉彦氏/原敬一氏/衣川朋宏氏

 トークスト言えば、高橋メソッド高橋メソッドでやってたところはやっぱインパクトありました。

  渡辺博之氏/幸加木哲治氏

 モデリングの出来(品質)と性能に相関があるかという話。結論は無い!!綺麗なモデルを作っても、性能が出ないということでしょうか。
 設計が綺麗すぎて性能が出ないというのは昔は良くあったらしいです。職人技で性能改善したみたいない武勇伝を良く聞かされたもんです。

  • XP 2.0

  日本XPユーザグループ

 小井土氏がXP第2版の要点を説明されてました。
 その後、倉貫氏が一括受注契約、人月計算、下請構造の問題について話されました。最も興味のあるテーマです。この辺の話をせずにXPの話をしても嘘ですから。

  本間直人氏(国際ファシリテーション協会)

 成功へのカギは一緒に喜びを共有して成長するということ。ここで、またまた平鍋氏と懸田氏の話と繋がって、目標・目的を達成したときに喜んでもらえるのが同じチームのメンバーだったらすごくいいなぁと思いました。
 そいういう風にみんなで喜び合える場をつくるのがファシリテーションなんですね。

  ひがやすを氏/飯田哲夫氏

 ISIDがS2のサポートをするということに対してのISIDの姿勢というか、コミュニティに対しての説明でした。
 ひが氏がチーフ・コミッタとしての経験を話されていて、身の引き締まる思いでした。
 平鍋氏がDeveloper2.0では会社からコミュニティに比重が移るというような話をされていましたが、飯田氏の話でも、会社とコミュニティの境界があいまいになる(する)という話がありました。企業も開発者もオープンソースやそのコミュニティとどうやって付き合っていくかということを真剣に考えなければならない時期に来ていると思います。
 SI2.0ではひが氏が自給自足とコラボレーションということを話されていて、業界の下請構造を問題にされていました。ここは倉貫氏の話とも通じるところがあると思いました。ISIDやTISのような、どちらかといえば元請けのSIerに所属しているエンジニアがこういったことを言い出したというのはとても興味深いです。元請けが下請け、孫請けから利益を搾取する構造はダメだとか言って。うちは中堅なので状況によって元請けになったり下請けになったりしますが、下請構造のような古い体質から脱却できていません。(どこもそうだと思うけど。)というか、下請構造が問題だという発想も全くありません。オフショアは強力に推進していくという話だし。
 あと、コラボレーションの話は、最初の松本氏のSoftware Factoriesセル生産の話と繋がりました。松本氏はベンチャー企業同士がコラボレーションしてという話をされていましたが、水平分業みたいなことが実現できるといいですね。
 家に帰ってDevelopers Summitに行ってきたよと妻に言うと、Developerってテレビでよく言ってるねと言われました。それって、ヒューザーでしょうorz 確かにそうだ。ソフトの開発もマンションの建設も同じような構造的問題を抱えてるってことを示唆してますね。

  • みんなで踊ろうMVC,みんなで創ろうパターンダンス

  羽生田栄一氏(豆蔵)

 一人一人をオブジェクトに見立てて、体を使ってメッセージが伝わっていく様子を表現するという新しい試みでした。確かにオブジェクト同士のコラボレーションというのは動的なものなので、本で読んだりするよりダンスという形の方が分かりやすいですね。
 しかし、恥ずかしさが先に立つので1杯やってからにしたいですね。(^_^)
 あと、デザインパターンを分かってない人もいたのでパターンの説明からしていると時間が足りなかったです。orz