Hatena::ブログ(Diary)

mnishikawaの日記 このページをアンテナに追加 RSSフィード

2010-09-28

[]Google Developer Day 2010レポート

9/28に東京国際フォーラムで行われたGoogle Developers Day 2010に参加してきました。


最初に、イベントに参加してみて思ったことを少し書きます。

参加登録時に挑戦したDevQuizが楽しく、イベント前から開発者にGoogleテクノロジに関心をもたせてしまう仕掛けがすばらしいと思いました。

イベント当日は、ちょっと人数が多すぎて身動きがとりにくかったのと、タイトなスケジュール、まとまり過ぎてる発表内容で、私が勝手に期待していた「開発者同士の意見交換の場」ではなかったのが(個人的には)残念。これまでGoogleテクノロジ関係のイベントは参加したことの無い私の問題かもしれないのですが、入りにくい空気も若干ありました。(これを機に、GTUG界隈にも顔を出すようにしたいですが・・・。)

Googleテクノロジーは誰でも使えるし企業自体がプロセスを公にしててオープンな印象を受けますが、Linux Symposiumみたいな参加者全員が当事者(そのテクノロジーの作り手)であるオープンソースコミュニティの集まりとは大きく違っていて、あくまでも企業イベントなのだと感じました。メインプレイヤーはGoogle、参加者はGoogleテクノロジーのAPIユーザーであると考えると納得がいきます。作ってるものの目的が違うので比較するのも意味が無いことなのですが、オープンさの度合いには大きな開きを感じた一日でした。

初めての場ということもあり、自分が当初思い描いていた期待とのギャップはいろいろ感じたものの、Googleのやろうとしてることは面白いし価値があると思います。

それを支えるテクノロジーも面白いです。進化のスピードもすごい。

GoogleDeveloperDayは、Googleテクノロジーを知って、使ってみて、どうビジネスにつなげていくかを考える場としては、とても充実してました。

Googleテクノロジーを使ってる技術者は是非参加しておきたいイベントだと思います。

今回、基調講演で取り上げられていたテーマは、大きく分けると以下の4つです。

後のレポートで詳細なメモを書きますが、ここでは各テーマの感想をまとめてみました。

HTML5 & Chrome

Webは、HTML5の登場で、これまでの「できる」「できない」という議論から、より快適で実用的なものが要求されてくる。そして、それを実現するためにはテクノロジーの進化が必要。開発者もこれを知った上で活用しなければならない。

GoogleHTML5を明確に強く推していってくれるのは心強い。Chromeのパフォーマンスと、開発ツールの充実を進めているのも良いニュースで、それを聞けたのは大きな収穫だったと思う。

クラウドプラットフォーム(GoogleAppEngine)

GoogleAppEngineはメンテナンスやライセンス、テストなど、プロダクト・サービスを作るうえで大きなウェイトを占めていた悩み事を、テクノロジーによって減らして行くというアプローチ。マネージャやエンジニアは、本当のサービス・製品価値の向上に時間を使える。今回のツールのデモでも、革新性の一端が垣間見れたように思います。


入力技術の進化(Google日本語入力

入力は重要なインタフェースにも関わらず、これまでほとんどイノベーションが起こらなかったという謎の分野。Google日本語入力、音声入力は、現時点でのベータ版でも革新性を感じさせるものだし、今回の発表内容を聞いているだけでも、今後の進化に期待しても良いと思いました。


Life cycle of developers

私がGoogleに良いイメージを持っているとすれば、エンジニアの生活を革新的な技術と同じレベルで重点テーマに挙げてくるところなのだと思います。食事が無料だとか、20%ルールとかいろいろと聞きますが、実際、Googleのエンジニアのみなさんはどう考えているのかは知る機会がありませんでした。今回「Googleエンジニアの日常」というセッションがあり、この関心のあったテーマについて、直接話を聞くことができました。

開発の障壁を取り除き、エンジニアの生産性を上げて、プロダクトの価値を最大化するための工夫がいたるところで感じられます。日頃から、私たちが取り組んでいることの、さらに進んだ実践事例の一つを知ることができました。


その他

メインテーマではないものの、個人的には気になっていた「プログラミング言語Go」のお話も聴けました。コードのメモリ展開のメカニズムなど、内部構造も織り交ぜながらのお話で、Goの言語としてのポジションが少し読み取れました。システム記述言語、大規模開発言語は革新が望まれる分野で、Goはそこを目指せる。今後、いじってみたい言語としてとても興味を持てました。


以下、受講した各セッションの詳細メモ(拾った情報を片っ端から。)を書いていきます。



[]GDD2010:基調講演

GoogleDeveloperDay2010の基調講演の全メモです。


Webの話

及川さん登場

  • Web標準の推移
    • Webがアプリケーション化している。
    • こうした要求にこたえたのがHTML5
    • 特定のベンダーの独自技術ではなくopenな技術が核となる。
    • 囲い込みもないし、技術の組み合わせによる新しいサービスが生まれる。


HTML5

慶応大学 一色さん登場(W3Cということで。)。

  • 慶応がMITなどがホストとして参加しているW3Cコンソーシアムをやってるが、一色さんがそこの長をしている。
  • HTML5でWebが大きく変わってきている。
  • W3Cは世界に400社、ボランティアで1800人が参加。世界中で使えるWeb標準を書く、みんなで育てる。


再び、及川さん登場

  • 機能を持っているかどうかではなく、次のフェイズに進んでいる。
  • パフォーマンス、実用化のフェイズへ。
  • デモ
    • IEのテスト用(2D)コンテンツ
    • 熱帯魚を増やしていくデモ
    • Chrome標準で250匹表示させると、FPSが7〜8に落ちてしまう。
    • これをGPUを使うことで、20以上になる。
    • GPUアクセラレーションをブラウザに対応させている。カナリービルド、stableビルドに反映していく。
    • 3次元ではより効果を発揮する。
      • 3Dの魚デモ
      • →このデモのように、ただできる(機能)ではなく、パフォーマンス・実用性に、フェイズが変わることで、新しいものが作れるようになっているのがわかります。


Googleエンジニアの北村さんがデモに登場。

  • Googleのホーム画面を90度回転
    • CSSスタイルシートで簡単にできる。
    • Macのモーションセンサーで、画面をズームイン、ズームアウト、傾き検知
    • 検索も普通にできる。用途はみなさんで考えましょう!
  • ボイスサーチ
  • HTML5 studio
    • HTML5のデモサイト
    • ローカルファイルアクセスのデモ
    • JavaScriptでローカルファイルに簡単にアクセス、写真のサムネイルを表示するデモを行う。

  • ファイルアクセス


Chrome Web Store
  • Googleの今後の課題と提案
    • 見つけやすさ
      • どうやって、ユーザーは魅力的なサイトに行き着くのか?口コミなどもあるが、現状、確立した手段がない。Windowsアプリは、量販店に行って目的のものを買える。年賀状アプリケーションなど。
    • マネタイゼーション
      • 広告がひとつの柱であるが、パッケージソフトのような収益構造は作れないだろうか?

HTML5




Android

ティム・ブレイさん(Androidのえらい人)登場。

  • 概要
    • 何故、Androidなのか、googleが注力しているのか?
  • なぜモバイルなのか?
    • 6.8 billion humans
    • 4.1 billion mobile debice
    • PCベースのアクセスをモバイルからのアクセスが超えた。モバイルに大きな機会がある
    • AOLに比べて、i-modeのアクセスが増加ペースを上回った。
    • iOSはさらにその5倍以上の伸び率でアクセスが増えた。
    • Androidは、今のところiOSの伸びを上回っている。
    • モバイルの大きな可能性が読めるデータを提示した。
    • GoogleI/Oで展示されたAndroid端末
      • 90デバイス
      • 21のマニュファクチャー
      • 50キャリア
      • 49カ国
    • 来年の今頃にはもっと標準的な端末になるだろう
  • Androidマーケットの新しい機能実装が続いている。
    • 音声検索
    • similerTab
    • AppMarketのコメント、エラー報告
    • ライセンシングサーバー →ライセンスチェック
  • Enterprise features
  • better security
  • remote wipe
  • MS exchange service




GoogleAppEngine
  • エンジニアが、システムを作るのに収集できるサービス提供
    • Easy to build,
    • easy to maintain,
    • easy to scale


  • App engine growing
    • 90K developers
    • 130K apps active every week
    • 5.5B pageview/week
    • 日本Appエンジンのアクセス数が世界2位

  • 成功事例
  • エコポイントシステム


    • ITマネージャの悩み
    • IT予算の60%は保守である。
      • 新しい開発や、イノベーションに費やされていない。これら、オーバーヘッドを減らしていきたい
  • Googleはイノベーションを重視する、効率を重視する。
  • Googleは保守をサポートしたい。

  • Roadmap
  • Javapnese Developer community


クラウド時代のポータビリティ
  • データポータビリティ
  • APPポータビリティ
    • オープンスタンダードにこだわる
    • 別のクラウド環境への移行も容易にする。
  • Google Web Toolkit&SpringRoo

ベンさん登場

・SpringRooのGoogleAppEngineの活用デモ

 →GWTを使って、基本的なパッケージを導入していくことで、

  数コマンドでWebアプリケーションをサクッと作るデモ



Google日本語入力

及川さん登場

  • Input
    • Webアプリケーションが増えていくと、ユーザーとのインタラクションが増えてくる。ユーザーはキーボードや音声を使ってデータを入力していく。この入力にイノベーションの可能性が存在する
    • 日本語入力、非英語圏に関して、必要な機能が提供できているだろうか?
    • 今回のイベントでは、Google日本語入力の開発背景を説明した冊子を配布
  • IMEは重要な機能にもかかわらず、しばらくイノベーションがおきていなかった。
  • 変換効率の高い、日本語入力を、他の分野にも拡大したい
  • Google transliteration」
      • まずはバックエンド公開。フロントエンドのJavaScriptエンジンは後日公開。
    • Google transliterationデモ
    • TransliterationAPI
    • GETを発行して、その結果をとってくる、シンプルな使い方。
  • Google日本語入力テクニカルイベント
    • コードリーディングを含めたイベント
    • 10/23開催(10/10締め切り)


GoogleDeveloeprDayについて

石原さん登場

  • DevQuiz
    • Applied: 4904
    • Passed: 1481
    • Best Score:41.94
    • Pass Score:23.22(SuperHacker)

  • Life cycle of developers
    • Googleでは、コードを書くだけではなく、レビューを通らなければ、世に出すことはない。コードだけではなく、コメントをいかにわかりやすくするのかが重視される。これを厳密にやることで、Googleはプロダクトの価値を上げている。
  • 潜在的に可能性のある人を招待するために、SuperHacker以外の枠を設けた。
  • 新しいDeveloper層を取り込みたい


[]GDD2010:プログラミング言語 Go

プログラミング言語 Go

鵜飼 文敏


Go言語とは何か
  • 2009年11月10日にオープンソース公開
    • コントリビュートしてるのは125名(2010/09)

  • 特徴

主流なプログラミング言語C++Java)、

ライトウェイト言語(Python,Rubyなど)

これらの良い点を取り入れた特徴




godentaku - Goで作った電卓

四則演算のパッケージはすでに揃っているが、あえて処理を書くことでプログラムを理解する。

  • 入力:bufio

func (*Reader) ReadBytes


packageを調べれば、こうした関数が調べれる。

godocというドキュメント

引数の型などを確認できる。


複数の値を返せるのがgoの特徴。


  • 出力:fmt

func Printf


いわゆるprintf

"%v"与えられた変数に応じた最適な表示を行うフォーマット指定



% 6g main.go  →64bit用コンパイル


6.out

実行バイナリ


  • int
    • ビット長を明確に指定しないと計算してくれない。
      • 違う型でも演算してしまって起こるエラーを防ぐため

nbuf = buf[1:]


   →参照をひとつ進めて代入



   string(buf[0:i])

  配列はデータであり、

  stringとして参照するときはimmutableな配列に内部的に変換して表示に使われる。

  文字列は基本的にはUTF-8文字コードが前提



type Ast interface {

String() string

Eval(env* Env) Ast

}


あるメソッドを備えたオブジェクトを受け取れる型

Ast型にの変数に代入できるのは、これらのメソッドが定義されている型のオブジェクト

Astにいれて使う方はこれらのメソッドを定義する。

演算は型をそろえないとコンパイルエラーになる。

実は、メモリ内では同じ扱いになったりするのだが、

コンパイラ、実行時はちゃんと評価してはじく。


  • map: variable table
    • いわゆるハッシュテーブル
    • intやstringをキーにして値参照できる。
    • そのmapにキーに相当する値があるかどうかを確かめるには、2つの受け取り用変数でmapを参照する

  (例)

  if v, found := map[hoge]





(例)

  if sym, ok := stmt.(Symbol);




 defer func() { ... }


その関数を呼ばれる前にかならず呼ばれる処理を実装することができる。

try, catchに相当する処理を実装するときに使う、


  • packageにする
    • ファイルを分割する
    • メインのファイル
      • import に"./godentaku"
      • godentaku.Read(line)
    • パッケージのファイル
      • package godentaku
      • 大文字で始まるとグローバルに参照できる。小文字で始まる場合はパッケージ内だけで参照できる。
    • 標準パッケージにコントリビュートする
      • codereviewでレビューしてもらう必要がある
    • googlecode でパッケージ公開


[]GDD2010:マーケットライセンシングを使って Android アプリケーションを守るには

マーケットライセンシングを使って Android アプリケーションを守るには

トニー チャン


マーケットライセンシングとは?
  • Androidマーケットに出ているアプリライセンスでコントロールすることができる。
    • Licence Verification Library(LVL)がサポートされていればOK
    • APIlevel3〜

実装のよくある間違い
  • サンプルそのままつかう
  • コードのobfuscate忘れ
  • NOT_LICENSEDが帰ってきてもアプリを終了しないという実装
  • テスト漏れ

Tips
  • コードの難読化

テクニックのひとつで、リバースエンジニアリングをやりにくくする。

コンパイルされたアプリは変更することができない

    • ProGuardツール
      • GPLで公開されている。

  • switchステートメントをifに変更
    • HASHを使って新しいステートメントにかえる。
    • レスポンスコードを摩り替えるため。使われていない関数を削除したり、追加できる。
  • onCreateメソッドは難読化できない。Androidが直接参照しているためだ。
  • 頻繁なリリースをする、
  • クラックしにくくする

How to get started
  • サインアップ
  • インテグ
    • ManifestにLVLを追加
    • Policyの定義
    • ServerManagedPolicy
    • StrictPolicy
  • テスト
    • テストアカウントを設定してレスポンスをテストできる。



参考文献
  • 「Market License developer guide」
  • LVL issue tracker
  • これに関するいくつかのブログポストもあるので、参照すること。


[]GDD2010:Google エンジニアの日常

Google エンジニアの日常

山内 知昭


山内さん


どんな仕事してるの?
  • 仕事の種類
    • SWE(Software Engineer)
      • Googleの製品・サービスを作る人
    • PM(Product Manager)
    • SRE(Site Reliability Engineer)
      • Googleのサービスを動かし続けている人
    • Ops(Operations ?)
      • 社内サービス開発する人
    • エンジニアが発想、設計、実装、launch
      • 最初から最後まで関わる。



どんなマシンを使っているの?


ソースコード

  • 基本的に全世界・全プロジェクト共通のリポジトリ
    • VCSコマンドを直接実行することは少ない。
    • さまざまなラッパーや補助システムがある。
  • コードレビューが必須。
  • かなり徹底していて、機能実装レビューだけでなく、言語として正しいかのレビューもある。
  • OpenSourceは管理が別

データ
  • ホームを含む様々なディレクトリNFS
  • どの端末でも同じホームで作業できる。
  • どの端末でも同じコマンドが実行できる。
  • ジョブの入出力などの大容量データはGFS

ビルド

ジョブ実行
  • 世界中のデータセンターの計算クラスタが自由に使える。
  • クォータの制限はあるが、かなり大きい
  • 同じバイナリをローカルでも実行可能
    • テスト実行で便利
  • 他のプロジェクトの生成ファイルにもアクセスできる。
    • 中間処理の終わったWebページなど、アノテーションのついてるWebデータを使ったりできる。
    • 前処理で思い処理をスキップして、自分のやりたいことに使えたりする。


仕事の進め方
  • 体制
    • 世界中から開発に参加
    • ロダクト単位のコアチームの構成
      • ある程度地理的な配置を考慮。
      • VCでつないでチームミーティング
      • 時差があるとさすがにしんどい
    • 個々のプロジェクトは少人数(1〜数人)
      • FtoFコミュニケーションは重要
      • 必要に応じて出張して開発
      • メール中心で、チャットを使う人もいる。
      • グループウェア(カレンダー、バグトラッカー)

  • 英語です
    • 日本人同士なら日本語で話すが、読み書きは英語です。
    • ダメな英語でも許してくれます。
    • 話すのはともかく、聞けないとしんどい。



ローンチプロセス
  • 確認項目
    • クオリティ
    • インパクトは十分か
    • セキュリティ
    • リソースは足りてるか
    • メンテナンスできるか
    • 法律に違反してないか
    • 関連チームへの確認
    • などなど
  • エンジニアが主体的に関わっていく範囲は広い



個人と組織
  • 好きな仕事ができてるか?
    • 半分Yesで半分No
  • Noの理由
    • アメンバーになるには、コアチームがいないとしんどい
    • 他のエンジニアのサポートがないとしんどい
  • Yesの理由
    • 20% Projectなら比較的自由にプロジェクトを選べる
    • Full-time projectでも課題発見・解決は最良の範囲
    • 親切な人や使えるリソースが多い


仕事以外の職場環境
  • オフィスに来るのが楽しくなる仕掛け
    • 食事、お菓子や飲み物が無料
    • オフィスデコレーション、遊具、マッサージ
    • 各種クラブ(カメラやグルメ、スポーツ、ダンス・・・)
      • Google日本だけで55のクラブ活動があるそうです。
  • チームの絆を深める仕掛け
    • 仕事中のおしゃべりはOK。休憩自由
    • 各種イベント、オンサイト・オフサイトミーティング

ワークライフバランス
  • 仕事時間の裁量は自由度が高い
    • 海外とやりとりすることがあると、朝早く、夜遅くにシフトしてる人もいる
  • 有給のほかに疾病休暇もあるので、
    • もしものために有給を残しておくとかの心配はいらない
  • 1週間まとめて休んで家族旅行とか普通。
  • 父親は育休(4週間)とれる。
  • 休みは取りやすい雰囲気です。


採用活動
  • エンジニアの採用は、エンジニアの大事な仕事
  • エンジニアが見て、「これは!」と思えば、面接へ。
  • 電話面接。オンサイト面接
    • 人事や管理職ではなく、現場のエンジニアが面接。
    • ホワイトボードにコードを書くことも。
    • 面接官は合否の判断と、その客観的理由をレポートする。

  • 必要なもの
    • 英語はできないと入った後しんどい
      • 山内さんはあまりできなかったが、入社2週間後には海外で仕事させられた。慣れない英語でなんとかサバイバルしていかないといけなかった。
    • 技術
      • さまざまな分野を知ってるほうがいい
      • CPUの仕組みからソフトウェアデザインまで
      • 表層的でない理解がもとめられる「なぜそうなのか?」
    • 人に指示する力ではなく、自分で作れる力を重視
    • きれいなコードを素早く書けること。

山内さんのケーススタディ
  • 文学部から工学部に変えた。
  • SIerに就職、2つ会社を経験
  • Googleの募集をWebで見て、レジュメを送った。
  • 1年後、再度応募して、今度は受かる。

他の会社と違うところ
  • どのオフィスに所属しても、エンジニアとしては対等
    • 時差や規模などがハンディではない
  • エンジニアがエンジニアを評価する。
    • 採用でも人事評価でも。
  • リソースが多い
    • 世界中のデータセンターを実際に使える。何テラを自由に使えるのはすごいところ
    • 全コードが同じリポジトリなので、他のプロジェクトのコードもすぐに使える。
    • さらに、それを作った人にすぐに聞ける。
    • 物理的なものだけでなく、人的リソースも多い。


[]GDD2010:Android でリアルタイムゲームを開発する方法: リベンジ

Android でリアルタイムゲームを開発する方法: リベンジ

クリス プルエット

クリスさん
  • Androidの「ディベロッパーアドポケイト」
  • Googleに入る前はゲーム会社にいた
  • 「ワンダのレプリカ島」というゲームを開発

端末の種類
  • ゲームアプリは、パフォーマンスが気になる。端末重要。
    • 端末が多くなると、対応が難しいのではないか?
      • 端末の種類が多いが、大きく分けると2つの世代に分かれる。

   第1世代(古い端末)HT-03A相当

    だいたいQualcommMSM7200A 400MHzぐらい

    HVGA

    OpenGLES1.0

    30ヘルツないに5000頂点

    60ヘルツで1024頂点は問題ない

   第2世代

     500-1000MHz

     OpenGL2.0

      2.0になるとシェダーが使える

      ハードウェア補助

     WVGA

     30ヘルツ 3万頂点

     30ヘルツを超えられない端末も存在。


端末の特徴
  • 画面サイズ、解像度
  • インプット機能
  • OpenGL
    • テクスチャフォーマット:ATITC? PVRTC? ETC1?
      • 端末によって対応が違う
      • ほとんどのテクスチャはETC1で対応してるのでお勧め
    • OpenGLバージョン
      • AndroidのManifestで記述できるので、対応してない端末をはじける
    • GL_EXTENSIONS


Android端末のバージョン
  • ほとんどが2.1か2.2
  • マルチタッチ(2.1〜)などの機能要件によって、対応バージョンが決まる。
  • 1.6から画面サイズ対応
  • クリスさんのゲームは、1.5ベースで開発して、全バージョンに対応するのはそれほど難しくなかった。
  • HightMap Profiler
    • レンダリングにかかった時間などをプロファイルできる。
    • プロファイルでベンチマークとった
      • HT-03Aは頂点の数が増えるほど描画に時間がかかってくる
      • 秒間、30フレームを確保できないと、ゲームとしてはストレスを感じる
      • Xperiaはどんなに描画しても、画面のSyncにあわせて表示しているので、頂点の数が変わってもパフォーマンスがかわらない。ただし、30ヘルツを超えることができない。


LODの価値
  • 奥のものを簡単に描画するテクニック
  • 描画数を大幅に減らせるので、パフォーマンスを稼げる。
  • ゲーム会社は普通に使ってる技。
  • かなりきれいな画面が作れるはず。



パフォーマンスを高める方法
  • ★必ずVBOを利用
    • パフォーマンスが大きく上がる。
  • VBOの数を減らす

  • 第一世代端末から第2世代端末までランタイムでスケール
    • GL_EXTENSIONSは役立つ
  • 第2世代のみの端末を狙うゲームならGLES2.0を利用

"ワンダ"の実装事例
  • キャラクタスクリプトは draw_textureを利用
  • タイルをひとつのVBOからタイルのスキャンラインにした。
  • GLSurfaceViewが便利
  • NDKで高速化
  • アプリがポーズしたときの対策
    • ゲーム中にRAMがクリアされたときの対策が必要
    • 中断してほしくない場面は、GLSurfaceViewをいじって復帰対策をした。


学んだこと
  • 操作設定は必要
    • キーコンフィグレーション
      • 端末ごとについてるボタンが違うので、これをつけると好評だった。
      • 最初から考慮しておかないと、あとからつけるのは大変だと思う。
  • InputSystemを、InputInterfaceクラスと分離することで、設定を分離した。
    • ゲーム側のコードを変えずに入力の幅を広げられる
  • これって面白いだろうか?
    • プレイヤーが死んだポイントで、サーバーにデータを送る仕組みを入れた。
    • プレイヤーが死んでるところをマッピングすると、難しい箇所がわかるようになった。
    • 20万人ぐらいのデータをとったら面白い。
    • Androidサーバーにデータを送るのはすごく簡単!
  • Webサーバーをつけた
    • デザインをちょこっと変えたいときに、シェーダーのデータを流し込めるようにする。


ゲームを作るにあたって
  • ”楽しいゲームには「革新」より「面白さ」のほうが大事”
    • Jonathan Blow, author of Braid


Androidマーケット上のゲームダウンロード回数
  • 5月からゲームのダウンロード回数が大幅に増えた
    • ダウンロードラインキングは全ジャンル中2位
    • Androidユーザーの一番関心があるのがゲーム。
    • Liteバージョンがほとんどの場合用意してある。

Useful Links

2010-03-09

[]アジャイルジャパンに行こう!

実行委員やってるので告知します!

4/9(金)〜4/10(土)に、「Agile Japan 2010」が開催されます。

Agile Japan 2010

ナレッジマネジメント(知識経営)の生みの親である野中郁次郎先生(一橋大学名誉教授)や、Alan Shalloway氏をキーノートに迎えました。楽天、DeNAといったWebサービス開発におけるアジャイル実践の報告や、官公庁でのアジャイルプロジェクトの事例、大規模開発での報告など、事例セッションも充実しています。

また、『ぷよぷよ』『BAROQUE』などのヒット作を生み出したゲームデザイナー米光一成氏(立命館大学教授)によるワークショップなど、実践的なコンテンツも盛りだくさんです。

ついでに、僕もファシグラワークショップやります。

3/19(金)までに登録いただくと早期割引で安くなります。

お申し込みはお早めにどうぞ!


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Agile Japan 2010』

  ―体験しよう!考えよう!行動しよう!日本のアジャイルはここにある ―

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

今年のテーマは「体験しよう!考えよう!行動しよう!」です。

Agile Japan 2010 は、ビジネスの現場で活かせることを目的としています。

アジャイルと深い関わりを持つ第一級のオーソリティを招へいした講演を

予定しています。

しかし講演 を聞くだけの場でなく、実践の場として活用していただき、

必ず参加者の皆さんが「持ち帰れる」ものを提供したいと考えています。

開催日は、2010年4月9日(金)・10日(土)

開催場所やプログラム等の詳しい情報は、Agile Japan の Web サイトをご覧ください。

 http://www.agilejapan.org/

皆様のご参加を心よりお待ちしております。

★ ご案内------------------------------------------------------------------★

開催日程:2010年4月9日(金) - 10日(土)

開催場所:日本アイ・ビー・エム株式会社 本社セミナールーム

【アクセス】http://www-06.ibm.com/jp/ibm/map/hq.html

参加対象:

IT関連企業、ユーザ企業に所属され、ソフトウェア開発のプロジェクトマネージャ、チームリーダーの方

参加人数:200名

主催:

 アジャイルジャパン2010 実行委員会

共催:

 Agile Alliance

★ キーノート講演者紹介--------------------------------------------------★

■ 野中 郁次郎 氏

一橋大学大学院国際企業戦略研究科 名誉教授

Scrumの祖父といわれる野中氏に、まずScrumとは何か?をお話いただき、

知識創造と組織、プロセスのあり方まで幅広く現場のマネジメントについて

ご講演いただきます。

欧米型のトップダウンオンリーのマネジメントがなぜうまくいかないか、

日本的経営のよさはどこにあるのか、といった企業全体のマネジメントの視点から、

現場のリーダーとしてのミドルマネジメントのあり方や、実践知型リーダーシップ

(Phronetic Leadership) について語っていただき、現場を元気にする、

現場から知識創造をしていくためのヒントを共有できればと考えています。


■ Alan Shalloway 氏

Net Objectives社CEO、シニアコンサルタント

変遷するビジネスニーズの中で、アジャイルソフトウェア開発で注目を

浴びてきた過程をたどり、現在の最新潮流と、アジャイルの今後について解説します。

アジャイル手法の中では依然として、スクラムが最も利用されていますが、

企業のシステム開発が大規模化かつ多様化する状況において、今後もスクラム

採用していくには限界があると考えられます。

一方でリーン思考が高まる中、より大規模で複雑な開発プロジェクトに

アジャイル開発の手法を取り入れ、企業の俊敏性を確保するために、

ソフトウェア業界はいまアジャイルの新しいパラダイムを必要としています。

このようなアジャイルの今後の展望についての見解とその根拠を、

AlanShalloway氏が語ります。


★ スポンサー・後援一覧--------------------------------------------------★

スポンサー:

 Agile Alliance

 日本アイ・ビー・エム株式会社

 株式会社コンポーネントソース

 マイクロソフト株式会社

 株式会社ディー・エヌ・エー

 株式会社 永和システムマネジメント

 社内SNSSKIP

後援:

 アジャイルプロセス協議会

 オブジェクト倶楽部

 すくすくスクラム

 日本XPユーザグループ

 プロジェクト・ファシリテーション・プロジェクト

 astah* ユーザーズコミュニティ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2010-02-06

[]”アジャイル”をもう一度考えてみよう。(XP祭り関西2010)

XP祭り関西2010に参加してきた。


講演も面白かったし、以前からずっとお会いしたいと思っていた方々ともイベント終了後もじっくりとお話することができ、とても充実した一日でした。ありがとうございました。


しかし、イベントの内容に関してふりかえると、途中からかなり頭の中がもやもやと曇ってきた。

もやもやすることは、自分の考えの及んでいなかった領域を発見したということでもあるので、これをきっかけにいろいろと考えてみたい。

まず、私はこうしたアジャイルの実践事例を共有する場に行くと、発表者が思わず使ってしまう「勇気」とか、「信頼」「覚悟」などの、時・場面・人によってぶれのある言葉は、何か他の言葉に置き換えられないのかなあといつも考えてしまう。時には「愛」とか言ってしまう人もいるが、正直ジンマシンが出るほど苦手だ。

たとえば、「勇気」という言葉。

この言葉を使ってしまう理由もよくわかる。

「うまくいった!なんだろうこの感覚は。そうか、これが勇気か!」

この言葉は、経験した人だからしっくりくる言葉のはずだ。

残念ながら、この感覚を経験したことが無い人には理解が及ばない。

だから、「勇気を持って踏み出しましょう」って言っても、一番動いて欲しい人は動かないし、説得力も無い。

ドメインの言葉で、その意識を考えるべきではないか。

発表者には、自身の感覚の表現ではなく、聞き手の行動・思考を促すためのできるだけ具体的な話をして欲しい。


アジャイルは、ビジネス視点でシステム開発を考える性質上、避けては通れない「人」の問題にフォーカスするため、特にこうした話になりがちだ。

特に最近は、前後の話やその発言をした場の雰囲気も知らず、youtubeやustream、slideshareなどでその部分だけを切り出して見てしまう事も多いので、「勇気」とか「信頼」のような、ぶれのある単語はかなり慎重に使いたい。

言葉だけを切り出して見た人が、精神論であるとか、宗教っぽさ(マイナスイメージな意味での)を感じるといわれても、反論の余地が無いだろう。


今回のXP祭りのテーマは、『アジャイルマインドを育もう』だった。

顧客のビジネス価値の最大化を目指す開発を行うには、メンバー全員が、アジャイルな考え方でプロジェクトに望まなければならない。(言い換えると、ビジネス価値を引き上げるための開発ができているプロジェクトは、往々にしてアジャイルなプロジェクトになっている。)つまり、プロジェクトメンバー全員でアジャイルを心がけることができていれば、良い開発ができるはずである。『アジャイルマインド』を育めば、プロジェクト、顧客、会社、さらには、業界が良い方向に導かれる。

では、その過程はどうするのか。私の現場ではどうやって取り組めばいいのか、何を考えれば良いのか。または、何かヒントは。これを探求し、知ったことや考えたことを共有したい。

これが、私のイベントの期待であり、可能性だった。

しかし、今回のイベントの流れでは、そのまま文字で表しただけでは、おそらく参加者によって認識がまちまちであると思われる『アジャイルマインド』とは何か、その先にあるものは何か、について一切共有することなく、一方通行で話が進んだ。

このズレは、パネルディスカッションで表面化し、私の中でもやもや感として現れた。

上記の期待・可能性を示した通り、『アジャイルマインド』は大切だ。それに、それぞれの発表がいい話だっただけに、ちょっともったいなかったのかも、と思った。


今回の件でも再認識したのだが、アジャイルの重要性や効果を端的にアウトプットするのは難しい。

だからといって、安易に何かに例えたり(メタファーとか言って誤魔化されることが多いので、安易にそっちに逃げる。)しては、場合によっては余計に不正確に伝えてしまいかねない。

時間がかかって面倒なことかもしれないが、現場(職場)、場面によって、誇張することなく、確実に言葉を探して伝えるべきだ。

考える事。

こうしたもやもやを感じたら、考えて、少しでもいいので、正確に伝えることを積み重ねていかないといけない。


アジャイルについてもう一度考えよう。

2009-01-24

[]XP祭り2009

祭り2週目。

充実した内容のセッション、終わった後の焼肉と、おなかいっぱいの一日でした。

基調講演

平鍋さん、木下さんによるAgile2008レポート。

気になったポイントのメモ。


「AgileUX(User Experience)」

Agile2008の印象的キーワード。

ユーザーからのフィードバックが無ければよいものは作れない。

UXを実現する開発手法として、Agileは非常にマッチする。

UserExperienceセッションでは、アイデア,意見を貼るかんばん。色使いなど、工夫している。

イベント自体のUIにこだわっている。

  • 絵葉書によるセッション誘導
  • フィードバックかんばん
ベンチャーが積極的にAgileに取り組んでいる。
Kanbanブーム
  • Scrum板など。記事紹介なども増えている。
  • かんばんの本来の意義に回帰。
    • 後工程で必要になったら、タスクを引っ張ってくる。pullで使う。WIPを最小限に。
    • Doneがはけないと、Doingに入れてはいけない運用の紹介など。
思ったこと

CE Linux ForumでLinuxイベントのレポートを聞いていても感じることだが、

海外のイベントは参加者全体の一体感がすごいなと思う。

Linuxなら、カンファレンスなどの議論がきっかけでカーネルの技術革新が起こるし、

Agileもその場にいた人が現場を変える。

イベントに参加した人全員で、業界を動かしている。

一回行ってみたいなぁ。


最後の質疑応答

以下、個人的な感想です。

  • 「プロジェクトの成功の定義が違う」
    • 契約・期間を最初にしっかり決めて進めるような開発スタイルが一般的な日本では、顧客とゴール・価値を共有して進めていくという、Agileのスタイルとの発想の転換をすぐに伝えるのが難しいと感じた。Agileをただの開発プロセスのひとつという領域で見ているうちは、前に進まない。何故、Agileをやるのかということを、しっかりと伝えていきたい。
  • Agileのプラクティスには、エンジニアがすぐに効果を感じ取れるものが多い。とにかくやってみる。現場から伝えていくアプローチも同時に進めていくのが、我々の役割。


PF入門ワークショップ(PFP)

  • 田村さんのPF解説中に、平鍋さんが見学に。平鍋さんの前でPFについて説明するという、すごい状況に。やっぱ緊張したのかな。
  • PF体験ワーク。
    • ソフトウェア開発の変わりに、チームでトランプを並べるというゲームをする。朝会、KPTによるふりかえり、ニコカレでチームの生産性を向上させ、ゲームのスコアをあげていく。
    • 僕もいち参加者としてワークに参加しました。ゲームはシンプルなだけにすごい熱くなる。KPTでふりかえりしていても、活発な意見が出てきた。短時間だったが、ワーク終了後は、チームで一体感も感じられた。PF入門の目的だけじゃなく、このワークをやるとチームワークが強まるかもしれない。実際の開発チームでもやってみると面白そう。
    • ふりかえりでは、参加者とのディスカッションも盛り上がった。PFを導入するということではなく、私たちは現場でどういったことができるか?という前向きの意見が多かった。

PFP関西のワークショップでも、こういった意見交換をもっと積極的にやっていきたいと思いました。



終わった後

公式の懇親会の後、荷物運び用のランエボで、数人と大阪市方面へ。一人が「ラーメンを食いたい」とか言い出したので、おいしいテールラーメンが食べれる焼肉屋さんへ。ラーメンどころか、がっつり焼肉食べてました。

おなかいっぱいです。