X-over Development Conference 2009

http://itpro.nikkeibp.co.jp/ev/xdev/index.html

9/15(火)、9/16(水)の2日間の開催だったが、9/15だけ行ってきた。エンジニアライフのセッションはとても刺激を受けた!ああいうのは生で聞いた方がテンションが上がってよい気がする。

幸せなエンジニアになるための仕事術

概要
感想
  • 勇気をもらえた気がする。特に心に残ったキーワードを挙げてみる。
    • 仕事は選べるもの。
    • 自分でやるしかない。
    • 理不尽がいや。だからOSS。嫌なら直せばいい。だからメーラーも自作している。通勤時間も長いのが嫌だから地方に住んでいる。
    • エッジがおもしろい。下流がおもしろい。そもそも上流、下流という言葉がよくない。
    • 1日1ハック。
    • 今はチャンス。生産性の高いツールもあるし、スケーラブルなサーバーも安く借りられる。失敗した際のリクスが下がっている。
    • 1回失敗したぐらいであきらめない。
    • 我慢しすぎ。
  • 視点として得られたもの。
    • 普通に考えると不利に思えることが有利に働くこともある。例えば競争が少なかったりする。
    • 現場ではウォーターフォールでも人によってはアジャイルにやっている。
    • プログラミング言語を作る人は頭が良いのでシンプルなものを作ろうとするのでは。Rubyは内部はごちゃごちゃだが、外側はすっきりするようにしている。
    • コンピュータにはムーアの法則が適用されるが、人間には適用されない。ので、人間にフォーカス。
    • システム開発を工場にたとえると、人が機械で、その間をコミュニケーションが流れている。
    • ブルックスの法則にもあるように大きなチームの時点で負け。少人数で高生産のツールを利用する。
    • 量的な変化は閾値を超えると質の変化になる。例えばRailsだと15分でアプリが作れるので、客先で話を聞きながらデモを作ったりも出来る。
    • 大規模だから〇〇という思い込みがあるのでは。今は1人でも大規模なサイトを作れる。
  • まとめると、お二人に共通しているのは以下の点かと。見習おう。
    • 常識に縛られない。思い込みをしない。
    • 自分が嫌だと思ったものを我慢せずに、解決しようと取り組んでいる。
    • 取り組んだものはすぐにあきらめない。
  • 自分の思い込みにとらわれている部分が分かってよかった。もっと自分の心と体が求めているものに対して素直になろうと思った。あと、粘り強く取り組むことが重要なのだと納得できた。

ITpro Challenge! 2009 Light

感想
  • プログラマー最適化問題」竹迫良範氏
    • 「ハードの性能が向上しているので、複雑なアルゴリズムよりも単純なアルゴリズムの方が早いことがある。」みたいなことを言っていた。コンテキストが並列なのか設計+実装+実行+保守のコストなのかは覚えていないが、量が質に転化した1ケースだと思う。
    • とても軽快でメタファとウィットあふれる内容だった。惹きつけ方が半端なかった。ジェットコースターに乗ったような面白さだった。
  • 「Do You See the Light?」角谷信太郎氏
    • 角谷さんが心掛けていることを見習おう。
      • 自分から名乗る。
      • 名札をちゃんと下げる。
    • 他にも大切な言葉を聴けた気がする。
      • すごくなくてもやれることはたくさんある
      • 変化というよりは大切にしたいものに気づこう
      • 変わらないと思い込まない。実際に話してみると、分かってもらえることもある。
      • 独りじゃ生きていけないこと、ひとと関わること、ひとを信じること、我慢しすぎないこと
  • まとめ
    • 聞いてよかった。午前中の時点で帰ろうかと思ったが、残っていて良かった。
    • 一日の疲れが吹き飛んだ。やっぱり、こういうセッションはエネルギーがもらえる。
    • 光が差したw

その他

ITパラダイムシフトにどう向き合うか クラウド・コンピューティング時代のSOAとEA
  • イノベーションを連呼。
  • SOAとかクラウドの定義に関する説明。
  • とりあず部分的に始めると、後で使われなくなるので、全体最適を考えた上で導入すべきとのことだった。IBMのスタンスは小さく始めて大きく育てる立った気がするが。。
SOAから見た,クラウド時代のアーキテクチャ
  • http://www.arclamp.jp/blog/archives/xdev2009_soa_cloud_report.html ← ご自身のブログでスライドを公開されています。
  • 用語の定義に非常に気を遣っていた。アーキテクチャらしいと思う。
  • かなり砕けた感じで、ラフにテンポよくメリハリを持って話していた。とても聞きやすかった。
  • エコポイントのサイトをSalesForceがやったのは衝撃なのに共感。Sitesによってインターネット側にも画面出せるようになったので、今後事例が増えていく気がする。Force.comプラットフォームは生産性も高いしね。
  • 密(データベース共有とかレプリケーション)だろうか疎(Webサービス)だろうが、スキーマの変換コストは変わらない。スキーマの変換コストを下げるにはスキーマの共通化を行うしかない。
クラウドを活用したSOA実践アプローチ
  • http://itpro.nikkeibp.co.jp/article/NEWS/20090915/337270/
  • プロセスと一括りせず業務プロセスと作業プロセスの2つに分けて考える。作業プロセスはある担当者レベル、業務プロセスはそれより粒度が大きい感じ。資料を見直してみたが、いまいち定義がはっきりしない。
  • SOAでは 「要件定義 -> 基本設計 -> 詳細設計 -> 実装・テスト」 のフェーズを順番どおりに実施し、その中で必要な成果物をキッチリ作る必要があるとのこと。でも、その図を説明しながらアジャイルと言っていたのはなぜ?これはウォーターフォールだと思うのだが。。
RIAを生かした業務システム事例
  • Sliverlightを選んだのは.NETの開発者スキルを流用できるため。
  • デザインはデザイン会社に協力してもらう必要がある。
  • Sliverlight内にロジックをすべて置いて2層構造に出来るが、ロジックを置き過ぎると重くなる。プレゼン層はUIロジックのみで、APサーバーにロジックを置くべき。
  • 画像をクライアント側でキャッシュすると言う要件があり、ディスクを使ったところ速度が出ず、メモリを使うようにした。
Silverlight×ExpressionでRIAフロントエンドを「創る」
  • 概要
    • http://itpro.nikkeibp.co.jp/article/NEWS/20090915/337281/
    • RIA開発の課題は以下とのこと。どれも当たり前のことだが新規技術を導入する際は改めて確認すべきことだろう。
      • ユーザビリティに対する考慮の欠如。単なるC/Sの焼き直しになっている。コストを掛けた割りにROIがない。
      • 画面要件定義の遅延。動的なのでモックアップではなく動くものを見ないと話が進まない。度重なる機能追加。
      • 実現可能性の検証漏れ。実装段階になって実現できないことが判明する。
      • 性能が出ない。見た目は良いし、機能としても問題ないが、性能が悪くて使い物にならない。
    • RIAではシステムとデザイナーのチームを分けていると上手く機能しないので、統合したチームにすべき。そこではシステムだけでなくデザインにも目を配れるインフォメーションアーキテクトが必要。
    • チーム内の役割分担が重要。
    • UI設計は簡単ではない。
    • ExpressionBlendのプロトタイプ作成機能であるSketchFlowには手書き風のフォントが存在する。これは一般的なフォントだときれいなため完成された印象を受け、アイディアが浮かばなくなるためとのこと。
  • 感想
    • チーム内の役割分担が重要とのことだったが、これって結構大変で、悪く転ぶと責任を押し付け合いになる。そういう意味で、アジャイルにおいて担当者ではなくチームで取り組むと言うのは、計画を立てることが困難なことを受け入れるのと同様に、役割分担を明確にすることが困難なことを受けれているのだと思った。
    • SketchFlowで手書き風フォントがあるのが興味深かった。確かに書き易さというか自由度でノートに勝るものはない訳で、将来的にはキーボードとタブレットを統合したようなデバイスが出てくるのだろうか。文字の入力はペンよりキーボードの方が早いから、タブレットだけだと困るかな。それとも、まったく現在と異なるインタフェースのデバイスが出てくるのかな。

まとめ

  • ライトニングトークとか対談とかはエネルギーをもらえる。
  • SOAとかSilverlightとかいった概論や技術、製品の話は普段から情報収集していれば知っている程度の内容である。そのため、知らないテーマについて聞きに行くべき。
  • 聞いていて疲れたセッションは話す内容にメリハリがない気がした。スライドに書いてあることは一瞬で読めるのだから、書いていないことを中心にテンポよくメリハリを利かして話す必要があると思った。
  • 来年はエンジニアライフだけ参加かな?
  • 日記書くのに時間かけすぎ。ノーパソ買って、その場である程度書くようにした方がいいのかしら。