Developers Summit 2011参加メモ(1日目)

創発 未来につながるために 世界に帆を立てるために Developers Summit 2011に参加してきました。記憶が薄れない前に、ノートに取ったことを以下にまとめておきたいと思います。基本的にはこのブログで日ごろ書いている内容と同様に、エンタープライズ開発やプログラミング技法、アジャイル開発プロセスなどを中心に話を聞いてきました。
なお、多くの講義資料はhttp://www.slideshare.net/event/developers-summit-2011で公開されていますし、詳細な議事録は他にも多くの方が記述されています(http://devsummary.miukoba.net/)ので、ここでは私が参加した講演に対して、私が(主観的に)感じたことも含めて書いていきたいと思います。(聞き間違えていた箇所があれば、ご指摘いただければと思います。)

【17-B-1】エンタープライズパッケージ開発の今

梅田弘之 氏が進行役となり、小野和俊 氏、小林達 氏、萩原純一 氏の3人に順次意見を伺うという形式で、「エンタープライズパッケージ開発の今」について議論されました。私は知らなかったのですが、登壇者の方々の所属している会社はMIJIというコンソーシアムに参加しているそうです。日本のソフトウェアパッケージは完全に輸入超過の状態となっています*1が、日本のソフトウェア製品を世界に向けて発信していくというのを目指している団体のようです。
エンタープライズといっても、一般のSIの受託開発とは違い、各社アジャイル開発手法を取り入れているということで、ペアプログラミング、TDDなど具体的なアジャイル開発手法の導入事例について説明がありました。特に、私の印象に残ったのは以下の点です。

  • ジョエルテストは有効。(小野氏)
  • パソコンは遊びの道具なので一人にすると半分は遊んでしまう*2からペアプロの方が工数が得になることもある。(小野氏)
  • ペアプロとソロプロの使い分けをしているがコミットレビューは必ずペアで実施している。(小野氏)
  • ペアプロスキルとプログラミングスキルとは分けて考えるべき。(小野氏)
  • テスト自動化とテストファーストは別物として考えるべきで、たとえば後者はプロトタイプでは必須でない。(小野氏)
  • ペアプロは疲れるし、上司に遠慮する必要もあるので片方が帰りたくなったら帰宅するルールを作っている。(萩原氏)
  • コーチング、QMSなどの手法は特に導入していない。(萩原氏)
  • ペアプロは導入していないが、一日の半分はふらふら遊んでいる人がいる(?)(小林氏)

残念ながら時間の関係もあったのか、それぞれの登壇者の説明を聞く形式で、パネルディスカッションのように深い議論にはなりませんでした。

【17-C-2】クラウド上でのエンタープライズアプリケーション開発

英語講師予約システムをGAE(Slim3利用)、Force.com、Amazon Simple DB、Azureで実装検証した結果の報告が行われました。簡単なサンプルアプリケーションですが、こうした予約システムでは同一の講師に対して複数の受講生から同時に予約が入ってしまうなどのバグは絶対に避ける必要があります。CAP定理により、NoSQLを使ってスケーラビリティを求めようとすると、RDBでは当たり前に保障されている読み取り一貫性や複数テーブル更新時のトランザクション原子性が保たれないなどの問題があります。具体的なPaaSのテクノロジーを利用した場合に、こうした問題をいかに解決するかについて、検討事例が説明されました。工夫次第でNoSQLでもエンタープライズアプリケーションは構築可能であるとのことでした。ただし、現時点ではパターンカタログ化されていませんが、しばらくすれば経験がカタログ化されるのは確実でしょう。
Force.comは裏でRDBを使っているので、一般的なNoSQLとは一応別ですが、作成したアプリケーションの特性に応じて従来のRDBとNoSQLを正しく使い分けることも大切なのではと私は思いました。

【17-B-3】チケット駆動開発〜タスクマネジメントからAgile開発へ〜

もともと「もう一つのTDD」ということで提唱されたチケット駆動型開発(TiDD)について説明されました。発表者の方は以下の書籍の著者でもあります。(私は翔泳社ブースにて購入)

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

従来のプロセスは障害の発見のみに注力し、段階的な改善プロセスというのが軽視されがちでしたが、TiDDの導入によりこうした経験を生かしたプロセスが導入できるようになるそうです。そして、TiDDにより作業抜けを無くすと同時にプロジェクトの活性化が図れるそうです。
なお、チケットの管理には

  • ワークフロー型(起票には管理者の承認が必要。手順もれ削減)
  • オープン型(誰でも自由に起票できる。作業漏れ削減)

の2種類があるそうです。
BTS自体はバグ管理システムとして以前からあるのですが、このツールを単にバグ管理だけでなく、タスク管理に活用するという新しい使い方により以前とまったく違った効果が得られるという点で、TiDDAjaxみたいな存在とのことでした。
個人的にはTicketの粒度をどう考えるかという点がポイントになりそうだと思いました。No Ticket、No Commitを徹底させるには、従来のタスクカードのように気軽に起票できることが大切だと思いますが、あまり自由にしてしまうと管理性が下がります。Redmineの親子チケット機能を活用したり、レポート機能を活用したりするような工夫が有効だと思います。

【17-E-4】未来はどこにいても誰にでも平等にある。 未来を創るのは自分自身だ。 〜SIerの中で生きるということ〜

SIerの将来については、このブログでもいろいろ書き綴ってきたので、かなり期待していました。講演内容が決まったのが結構後の方だったこともあり、他のセッションに比べると空席が目立ちましたが、さすがにスーツ率が高かったように思われます。講演者の川島氏はTISでアーキテクトをされている方で、業務では入社以来、10年以上にわたって特定のお客様先に常駐されて仕事をされているというバリバリのSIer技術者の方です。ただし、上流専門でプログラミングをしないSEというわけではなくて、以下のようなオープンソースの開発にも携わっておられます。*3
Google Code Archive - Long-term storage for Google Code Project Hosting.
Google Code Archive - Long-term storage for Google Code Project Hosting.
講演の最初のメッセージは、SIerは製造業や建設業ではなくてサービス業になるべきという主張がありました。美容院の腕利きのスタイリストのようにお任せでもいいようにやってくれる、プロフェッショナルなサービスを提供できるようになるべきとのことでした。上流だけに限ると従来のコンサルティングファームに近い感じなのですが、実装まで含めて面倒を見るプロフェッショナルサービスを提供する集団として生まれ変わるということでしょうか。今のSI業界もリファクタリング可能だと思います - 達人プログラマーを目指してなどで、私が主張してきたことと共通点もあるかと感じました。(SIerはIT業界のゼネコン構造の象徴なので、そこまで変わるとSIerでなくなってしまうという主張もあるかと思いますが。)
あと、興味深かった点は従来権限がプロジェクトマネージャーに集中していて、技術者たるアーキテクトの専門性が発揮できていないという点です。

  • ITA プロジェクト計画に責任を持つ
  • PM プロジェクトの遂行に責任を持つ

ということで、戦国時代で言えば、ITAは戦略を司る軍師、PMは侍大将のようなものですから、ITAにはもっと権限と責任が与えられるべきということだと思います。実際、システムのアーキテクチャにより組織の体制が左右されるというコンウェイの法則についても紹介されました。
同業者として全体的には共感できる内容だったのですが、やはり、どうしてもSIer脳の発想というか、万能なアーキテクトやPMが多数の無能なプログラマーを統率するという、大人数の人月ビジネスの枠組みが前提となっているような気がしました。アジャイル開発のようにアーキテクトやPMなどの上位職だけでなく、個々のプログラマーの専門性やスキルがもっと尊重されるようにならなくては、SIerは本当の意味で顧客にとって価値のあるサービス業には生まれ変われないのではないかと思いました。

【17-C-5】Spring as a Cloud Platform

日本Javaユーザグループの幹事であり、現在はSalesforceコンサルタントをされている河村嘉之 氏の講演です。Javaは終わったのか、Java EEは終わったのかという点に対して、今後もSpring Frameworkは面白いとのことです。私の以下のブログでも書いていますが、まったく共感する内容でした。SpringはエンタープライズJava開発者に夢と希望を与えている - 達人プログラマーを目指して
講義の中で、時間軸、垂直軸、水平軸への3方向へのSpringの拡張について説明がありました。

  • 開発環境(ビルド)→実行環境→運用環境(時間軸方向への拡張)
  • 下方向にはVMWare、OS(SuSE Linux)、上方向にはRoo、Grailsのような上位FW(垂直方向への拡張)
  • vmForce、GAE連携、プライベートクラウド(水平方向への拡張)

以下の資料も参考になります。Springの今
後半は実際のコード例を示しながらのvmForceの紹介がありました。(ただし、デモではない。)JPAの設定は一部書き換える必要がありますが、コードはほとんどそのままでForce.comのDBを参照できるようです。(もちろん、実際には単純にRDBをそのままForce.comに移行できるわけではないそうです。)

【17-C-6】SpringのこれからとJava開発者向けの次世代RAD、Spring Roo

Stefan Schmidt 氏はオーストラリアでSpring Rooの開発にも携わっているVMWareコンサルタントです。講義の前半はSpring Rooを使った開発のデモ、後半は(Rooだけでなく)Spring Frameworkの将来のロードマップについての紹介でした。
前半のRooの説明では、以下の点について説明がありました。

  • getter、setter、toString()などはAspectJで自動的に追加されるのでコードの記述が不要(もちろん、必要なら追記できる)
  • Rooは日本語を含めて現在9ヶ国語をサポート
  • 以下のUIテクノロジーをサポート(予定)
  • 既存のテーブルを元にした自動生成。

なお、Grailsとの違いで、Rooの特徴としてRooは完全に開発時のツールであり、実行環境はPure Springのアプリケーションなのだという点を強調していました。そういう意味では、実績重視のSI案件への導入の敷居も低いはずだと思います。
後半はこの春にもうすぐ登場予定のSpring 3.1の以下の新機能について紹介されました。

  • 環境プロファイル(開発、ステージング、本番などでBean定義を使い分けられる)
  • キャッシュ抽象化
  • 会話管理(ただし、デフォルトはステートレス。クラウドではやはり原則ステートレスがよいとのこと)
  • Servlet3.0対応、JSF2.0対応

また、今年の夏には早くもSpring 3.2が登場する予定とのことです。

その他、以下のプロジェクトについても紹介されました。

【17-D-7】C#(VB)プログラマのためのF#入門

私は.NETの開発経験はほとんどないのですが、Scalaと共に、.NETと親和性の高い関数型言語として知られるF#についてちょっと興味があったため参加しました。

  • 関数型言語では式が主役(手続き型は文が主役)
  • 関数でさえ値
  • すべての言語要素が式
  • より安全
    • パターンマッチ
    • Option型によるnullの回避
  • 型が軽い(簡単に型が定義できる)
  • キーワードが少ない
  • |>演算子
  • コンピテーション式
  • use束縛

などについて、説明がありました。
F#の弱点については

  • IDEサポートが弱い
  • Express Editionがない(無料で開発環境を作ることは一応可とのこと)
  • 日本語の情報が少ない

とのことでした。ただ、言語系の日本語の本は充実しているという一般的な傾向の例に漏れず(エンタープライズ開発者が負け組として軽蔑される日本のSI業界って - 達人プログラマーを目指して)F#の本は既に日本語の本も出ているようですね。

実践 F# 関数型プログラミング入門

実践 F# 関数型プログラミング入門

プログラミングF#

プログラミングF#

最後に、ロジックの記述はF#、画面デザインはC#VBという使い分けが重要との事ですが、まったくその通りかなと思いました。
2日目はこちら。Developers Summit 2011参加メモ(2日目) - 達人プログラマーを目指して

*1:ソフトウェアの輸入超過とオフショア開発

*2:ゲームやツイッターなど

*3:Ask the speakerコーナーで質問した際には、少なくとも現在までは、SIerプログラマーとして生きるということは、プログラミングは趣味と割り切って業務と切り離して行う必要があるとも。私としては、今後は業務でもプログラマーの価値が認められるようになってほしいと思いますが。