カテゴリー別アーカイブ: イベント

ITmedia Virtual EXPO 2012を視聴してみた。

先月になりますがITmedia Virtual EXPO 2012を視聴したのでそのときのメモを公開します。
メモの内容には聞き間違い等あるかもしれませんがご容赦ください。

今回視聴したのは下記の3つです。
・セキュリティ専門家が斬る!Anonymousの影響と人の脆弱性
・変貌するWebの世界― クラウドとクラウド・デバイスのインパクト
・LINEを生み出したNHN Japanの開発風土とは

——————————————————
セキュリティ専門家が斬る!Anonymousの影響と人の脆弱性
——————————————————

攻撃はきまぐれ
他人に攻撃をけしかけている雰囲気がある

調査してから攻撃する
攻撃できるという確信を持ってから行う(事前に仕込んでいる)

sip(シップ)のスキャン急にが多くなる

じわじわ攻撃を受けているサイトもある

政府機関のサイト、有名企業のサイト:
年中何らかの攻撃を受けている、報道もされない
=攻撃慣れしているしびくともしない
=攻撃慣れしている人たちから見るとそんなにたいした攻撃ではなかったりする場合もある

ちゃんと構築していれば防げるレベル

過去に見つかった脆弱性などが狙われる(2,3年前のもの)

ちゃんと対策をしていれば8割は防げる

さくっと侵入できるケースは少ない

メディアの注目を高めるために攻撃をやっている
ITに関係のない人まで知っている

チュニジアでの攻撃に日本人が参加していた

DDos攻撃に同時参加する人数
多くても2桁ぐらい
botが使われることが多い

javascriptをわざと踏ませて関係ない人間を攻撃に荷担させる場合もある

いまさら聞けないアノニマス
http://www.atmarkit.co.jp/fsecurity/special/172anon/01.html

セキュリティは楽しいかね?
http://d.hatena.ne.jp/ukky3/

複数のサービスをまたがった攻撃もある:
サポートセンターへの電話で情報を取得
メールのやりとりなど

サポートセンターの攻撃対応も必要
Facebookの情報で分かるような内容で本人確認してはいけない

オレオレ詐欺:
ソーシャルエンジニアリングの一つ

セキュリティ:疑うところから始まる

仕組みとしてセキュリティを高めていく
(ワンタイムパスワードなどを当たり前にしていく)

使う側でも分かるアプローチが必要

————————————————————-
変貌するWebの世界― クラウドとクラウド・デバイスのインパクト
————————————————————-

2012年:21世紀の二つ目の10年の始まり

最初の十年:911に始まり311(東日本大震災)で終わった。
携帯電話の爆発的普及
クラウドの登場と発展(googleの登場、amazon ec2の登場、microsoft azureの登場)
2007年iphoneの登場
2008年androidの登場

iphone,android等のクラウド端末の台数がpcを上回る勢い

トランジスタの数も15倍に

日本のスマホ普及率:先進国で最低クラス
・ガラケーの成功も原因

現在では1つのチップに中国の人口ぐらいのトランジスタが集積されている
(1970年には2000個ぐらい)
今後一つの電子、原子を制御するレベルまで小さくなってくる

Tegra3:5つのコアをもつ(公称は4つ)
製品への採用が進んでいる
スマホのスペックがpcを上回っていく

これからの5年間:
トランジスタの数は200倍になる

日常生活のあらゆる所にCPUが存在
すべてがネットワークにつながる力を持っている

Gang of Four:
Google
Apple
Facebook
Amazon

2011年に起きたこと:
6月icloud
9月facebookが8億人突破
11月amazon kindle fire登場

それまで自前のクラウドとクラウドデバイスを持っているのはgoogleしかなかった。
microsoft:windowsphoneの発表
facebook:クラウドデータセンターを稼働、携帯にも参入

去年一年でクラウドとクラウドデバイスを持つプレーヤーが形成された(非常に大きな変化)

日本:通信障害が発生するようになった。
ブロードバンドの帯域もスマホによって瞬く間に消費される。

スマホ:電池の持ちを良くするために制御信号を多発する

PC:データ量大、制御信号小
スマホ:データ量小、制御信号大

スマホ:ずっとネットに接続しているアプリが多数ある
実際には細かな接続/切断を繰り返している=多量の制御信号を送る

androidはiphoneよりも制御信号をたくさん送る
android4.0では改善されている

これからおきること:
新しいネットワークメディアの躍進
ネットワークマーケットの台頭

HTML5が鍵になる

2020年:世界人口の大部分がスマホを持つ(ネットワークにつながる)

すべての経済行動がネットワーク上で行われるようになる

AJAX:ブラウザとサーバがユーザのアクションに従って動的に動く
→これがリアルタイムに動くようになる

HTTP:文書の転送のためにデザインされた。
HTML5websocketはこれを改善する
(データ量減少、現在の通信方式とも共生できる)

ネットワークメディアに期待されるもの:
コミュニケーション、情報共有、豊かな自由時間

情報は誰のものかという問題を多くの人が意識し始める

コンテンツサービス、クラウドの利用:
日本は少し遅れている

音楽市場:
iTunesが圧倒的シェア

spotify:音楽をリアルタイムで共有できる

アメリカでは新旧メディアの対立がある:SOPA
著作権の強化、ISPによる特定サイトの遮断などまでが争点となっている

プライバシー問題:
日本ではプライバシーを守る意識が高い

電話初期、普及を妨げた最大の問題は交換手が会話の内容を聞けることだった
やがて危惧よりも利便性の方がそれを上回った

Appleの位置情報取得問題その後:
取得自体はやめていない
プライバシーポリシーに明記されるようになっただけ

Gang of Fourのプライバシーポリシーの特徴:
常に変わる
ビジネスと結びついている
事前了承が得られていればよしとする合意が形成されてきている

プライバシー観も変化していく

—————————————–
LINEを生み出したNHN Japanの開発風土とは
—————————————–

開発プロセスの違い:
ライブドア:企画→開発→デザイン
ネイバー:企画とデザインが同時に動き出す→開発
プロトタイピングが激しい

エンジニアリングだけで戦える時代でもない
エンジニアリングはあって当然、その上で武器を持たなくてはならない
(デザインなど)

ネイバーは400人(4割ぐらい)がエンジニア

Javaをよく使う
スマホに注力している

オープンソースのプロダクトをよく使っている

LINE:
メッセージ数がとても多い
Hbaseにデータを保存
アーラン(エリクソン)を使っている

これを使わなければ行けない、という決まりはない

新しいテクノロジーにも手を出している

社内の交流も多い
技術系スタッフの統合もハードルはなかった

スマホアプリのスタッフの統合が一番早かった

LINEが最初のネットの入り口になってくる
SDKを提供
サードパーティーも巻き込んでいく

SDK:
HTML5とJavascriptで提供される

LINEが生まれた背景:
スマホに注力したかった
スマホで流行るもの=コミュニケーション、ゲーム、写真
ゲーム、写真はすでにサービスを提供していた
企画が変容していってLINEになった

企画はだいぶ削られた(欲張った機能など)

企画者が尊重される
LINEは15人ぐらいで始まった

大規模なシステムの経験者を求めている
(インフラ経験者など)

次のアーキテクチャなどを先回りできるエンジニアが理想

ユーザー数で倍を目指している
未知の領域に入ってきている

現場に関しては開発陣の影響力が大きい

コードが書けることとマネージメントができることは別の才能だと考えている
得意なことをやってもらっている

PHPカンファレンス2011へ行ってきました(2)

PHPカンファレンス2011に参加してきたので、その時のメモを公開したいと思います。
PHPカンファレンス2011へ行ってきました(1)の続きになります。
メモの内容には聞き間違い等あるかもしれませんがご容赦ください。

———————–
スタートsphinx
———————–

Sphinx:ドキュメントツール

ツリー構造の記述を行う
PDFを出力することができる

インストール
Windows:スタンドアロンで使える
Unix:easy_install(Phython)を使ってインストール

sphinx_quickstartコマンドで
最初のプロジェクトを作成、設定を行う

活用事例
・ドキュメントページの作成
・symfonyのマニュアルにも使われている

———————–
Cena-DTA:HTML5のローカルDBを使ったアプリ開発
———————–
Web SQL Database
→ブラウザの中でRDBを使えるようになった

Cena-DTA:
1回の登録で登録+変更が行える

mySQLのDBを作成し、そこに接続する

HTMLのソースから直接データをダウンロード/アップロードできる

サーバ側:PHP+mySQLで作られている
クライアント側:jQueryのプラグインを使う

サーバでデータを受け取って登録する部分がPHPで作られている

———————–
Large-Scale Data Processing
with Hadoop and PHP
———————–
Facebook:12TB/1日のデータが追加されている(2010年)
google:一か月あたり400PBのデータを扱っている

180GBのデータを読み取るのに45分かかる
メモリの量にも限度がある

解決法:パラレルI/O

I/Oボトルネックの問題:
データのあるところにコンピューティングリソースを持っていく

例:apacheログに対する処理
マッパー:ログを書き出すイメージ
 ↓
リデューサー:各IPごとに書き出す集約を行う

hadoop:
SQLのクエリを書く必要がない
Facebookでのデータの増加にも対応できている
Yahoo、Twitterでも使われている

インプットフォーマットを使うことによって
どのデータをどのように分けるかということを指定できる

障害に強い仕組みになっている

Hadoopは主にJavaで開発されているが、
PHPなどでもリデューサーは書ける

HadooPHP:HadoopでPHPを使うためのフレームワーク

———————–
Microsoft ? PHP ~ 3rd Stage ~
WebMatrix + Windows Azure!
———————–
マイクロソフトとPHPの歴史:
Windowsプラットフォームインストーラー

Windowsウェブマトリクス

Windows Azure+PHP

Windowsウェブマトリクス:OSSを使う/一から作る
→サイト作成に必要な機能を搭載

PHPのメジャーなアプリは殆ど収録されている

ASP.NETのテンプレートも使える

既存のサイトをウェブマトリクスに移行することもできる

エディタ機能もある
SSLの有無なども設定できる
ソースに問題があるかどうかチェックできる

DBの編集もできる
無償でダウンロードできる

あわせて使えるもの:
IEのF12キーを押す⇒開発ツールが使える
Expression Web Super View

Azure:空色の、という意味
WindowsサーバーベースのクラウドOS

ウェブマトリクスで作成したものを
Windows Azure上で動かすことができる

Azureのテンプレート作成
 ↓
ソースコードをコピー
 ↓
テスト環境を作成
(バーチャル環境のようなものができる)
 ↓
Azureへのパッケージ生成

リモートデスクトップでログインして
更新作業を行うこともできる

Azureのメリット:
・Paasなので管理いらず
・データセンターは数十万台規模

事例
トヨタ、ゲームサイトなど

EC-CUBE DAYでも話をする予定

———————–
徳丸本に学ぶ
安全なPHPアプリ開発の鉄則2011
———————–

■安全なPHP入門書で学ぶ:
XSSとSQLインジェクションぐらいは正しく覚える
セキュリティの甘いサンプルが載っている本もある

■入力、出力処理をしっかりやる
バリデーション
制御文字のチェック
「安全なSQLの呼び出し方」=IPAが公開している
準備文を使う

htmlspecialcharsを正しく使う

ファイルアップロードには罠がたくさんある:
アップロードされたファイルがPHPとして実行される
ファイル名が衝突してしまう

■文字コードのセキュリティを気にする
5c問題

■クリックジャッキング対策をする
クリックジャッキング:
透明なiframeを正しい画面の上に表示させて、
違う操作をさせること

X-FRAME-OPTIONSヘッダを指定する
(古いブラウザは対応していない)

CSRF対策をする

パスワードの保存はハッシュ化を繰り返す

7文字ぐらいのパスワードではすぐに破る
ツールがある

ハッシュ値にSalt値をつけるのがベター

ストレッチング:
ハッシュ化する計算を何度も繰り返す

■PHPのバージョンアップにとことん付き合う

———————–
ライトニングトーク
———————–

Making DSL with []
Paml→テンプレートエンジン
PHP:配列とハッシュの区別がない

PHP技術者認定試験:
ウィザード試験が始まる

sismo:
ciTool
テストツール
githubに対応
symfonyと同じ会社が作っている

Symfony2HttpCache
リバースプロキシを使う
→Cacheカーネルを使う
 4倍ぐらい速くなる

クラウドを比べてみた:
HDDのスピード=かなり違う
GMO:1インスタンスに物理HDDを1つアサインしている

Symfony:behatというテストツールがある

PHP祭
10月15日、16日に大阪で開催

PHPBugs
バグ候補を指摘してくれる
(これから作成)

プロジェクトの規模が大きくなると
おかしいといわれているところが
本当におかしくなる

Ethna2.6
PHP5.3に対応

PHPカンファレンス2011へ行ってきました(1)

昨日PHPカンファレンス2011に参加してきたので、その時のメモを公開したいと思います。
当日は大勢の人が熱心に耳を傾けていました。
会場が満席で聞けない話があったのが少し残念と言えば残念でした。
メモの内容には聞き間違い等あるかもしれませんがご容赦ください。

——————
基調講演
——————-

PHPがブレイクしたのはver4.0(2000年)
PHPカンファレンスも2000年から
2004年ver5.0→オブジェクト指向
2009年ver5.3
ver5.4→5.3に比べると地味なアップデートになる

PHP
リリースサイクル1年
ライフサイクル3年(バグ修正2年、セキュリティ修正1年)

PHP5.4
9月半ばにβ版
今年中にはリリース
セーフモード、レジスタグローバル、マジッククォートはなくなる
SQLiteはver3のみとなる
5.3に比べて19%〜43%高速化
trait:コードを再利用する仕組み
  多重継承よりもシンプル
オープンタグの短縮形が追加
配列の簡略定義が可能
配列デリファレンシング、
2進数表現が可能に
不正なUTF-8に対するチェックの強化
Unicode6.0のケータイ絵文字を収録

セキュリティに対して:
基本を守る
最新の情報をチェックする

Coverity→ソースをチェックするツール?
Coverityでスキャンした結果、PHPの品質は高かった
もっと高かったもの=Ruby

PHPの成功理由
・小規模〜大規模なサイト(Facebook,Yahoo!)までサポート
・言語がシンプルでドキュメントが充実
・必要十分な現実的な解を提供している
(キラーアプリの存在、モバイル対応、新標準への対応)

————————————————–
PHPライブラリの歩き方・作り方
————————————————–

技術の動向によって、ライブラリに求められる機能は増えていく

主なライブラリ
PEAR:570ぐらい
PECL:270ぐらい

Rubyなどでは1万を超えている

欲しいものがなければ作るしかない

ライブラリのパッケージ名:
ネームスペースを使うと良い
まだ使われていないものを使う

クラス読み込みの定義:PSR-0に従う

PSR-0に従うと
require_once,class_existsを使う必要がなくなる

例外処理:SPLを使う

マジックメソッドは学習を困難にさせる

ライブラリ:パッケージにまとめて配布する

Pyrus:
任意のディレクトリにPEARパッケージをインストールできる
パッケージの作成もできる

紹介していた本:
オープンソースの育て方

PHPカンファレンス2011へ行ってきました(2)へ続きます。

「Devcon 2011 【Vol.1】iPhoneアプリNOW ~もっとiPhoneアプリ開発が面白くなう~」へ行ってきました。

昨日パソナテック主催の「Devcon 2011 【Vol.1】iPhoneアプリNOW ~もっとiPhoneアプリ開発が面白くなう~」へ行って、講演を聞いてきたので、その時のメモを公開します。一部聞き違いの部分があるかもしれませんがご容赦ください。会場の入り口が農場みたいになっていて驚きました。人もそれなりに多かったです。

—————————————-
iPhone/スマートフォン市場
の現在と未来
—————————————-

ファインマン→スマホに特化した会社

2008年7月11日:
iPhoneが日本で発売された年

ゆるふわ育成ソーシャルゲームMEGU
→30万ダウンロード

開発者支援サービスも行っている

・ソーシャルサービス
・位置情報
・AR
→のびている

スマホで変わったこと:
スケジュール帳が不要
ノートPCを持ち歩かなくなった

新しい市場ができる時:
ライフスタイルが変わる
(例:ウォークマン)

世界のケータイの契約数:50億
うちスマホは3億(推測)

アメリカの出荷シェア:
アンドロイド 40%
iOS 26%

日本:
2012年に出荷されるケータイの過半数がスマホに

国内のiPhone:500〜550万台(推測)

米国ではアンドロイドの契約数が
iPhoneの契約数を超えた

スマホのアプリ:
2年後には1〜2兆円の市場規模へ

アメリカ:
ゲーム、ソーシャルネットワークアプリの
シェアが高い

日本:
ブックのシェアが高い

アプリ内課金するものが増えている

有料アプリから無料+アプリ内課金に移ってきている

成功したアプリ:
・AngryBirds
・PaperToss
・太鼓の達人

アンドロイドの課題:
・マーケットの乱立
・キャリアが多い
・機種依存の問題
・OSバージョンの違い
・審査基準の問題

3〜5年で:
スマホ、タブレットPCが一般的に

5〜10年で:
既存のPCがなくなる

10〜15年で:
ウェアラブルの時代が来る

iPhone,iPadはMac化する

アンドロイドはガラケー化していく

ウェブアプリ化が進んでいく

マーケティング思考が大事

スマホは進化の通過点に過ぎない

—————————————-
生き残るアプリをつくる。育てる。
—————————————-

ゆるふわ育成ソーシャルゲームMEGU:
シンプルな育成ゲーム
利用者は女性が多い
無料アプリランキング1位になった

アイデアの模倣は恥ではない:
どんどん模倣して自分のビジネスに取り込む

MEGUが参考にしたもの
・ポストペット→ペットを飼う
・ポケモン→図鑑を埋める
・たまごっち→育成する

アプリの容量:20M以下にする
(20M以上になるとwifi以外でダウンロードできない)

twitterとの連携も重要

企画:
6割のおもてなし
3割のエゴ
1割の商売っけ

・iPhone3Gでも快適に動作
・iOS3.1でも動く
→機会損失を防ぐ

サーバ
→google app engineを利用
 できるだけアプリ内で処理

ランニングコスト
最初:1万5千円/月
現在:7万円/月

作成したもの:
・ブログ
・ツイッター
・BGM
・テーマソング
・オープニング動画

ダウンロードした8割の人が会員登録
→オープニング動画のおかげ

情報の活用
カスタマーサポート
電子メールでのサポート
→ユーザの声が届くようになる

アップデートは頻繁に行う
3つ先のアップデートまで考えておく

レビュー・評判はしっかり確認する

ユーザはランキングが大好き

ユーザのリテラシーは低い

ユーザはつながりを求めている

やりこむユーザも多い

バランス調整が難しい

広告は意外ともうかる

AppStoreでユーザが見る順番
1、アイコン
2、タイトル
3、説明文
4、スクリーンショット

説明文は各国語のものを用意する
スクリーンショットは5枚全部登録する

カテゴリ:アップデート時に変更できる

—————————————-
ユーザ!ユーザ!ユーザ!
デベロッパの技術がユーザーを
楽しませるアプリ開発のシカケ
—————————————-

エンジニアとしてユーザを優先して考える

エンジニアの仕事:ユーザを喜ばせる

よりよいユーザエクスペリエンスを提供するため、
エンジニアは企画から公開まで関わるべき

企画:
優先順位の決定
実演可能性
よりよい案を出す

設計:
ユーザエクスペリエンスにアドバイスができる

開発:
プロになる
より早くより正確に
どこに答えがあるのか

テスト:
しっかり行う
自動テストでなくてもよい

公開:
ユーザからのフィードバック
KPTを行う

ユーザと一緒に育ち、一緒に成長する

メモリ管理:
C,C++のプログラマは心配不要
失敗するとアプリが落ちる

マルチスレッドは使い方を考える

NSZombieを使う:
デバッグ用メッセージが出力できる

開発合宿で効率の検証

英語ができないとよい仕事はできない
・WWDC2010のビデオを見てみる
・英語圏で質問してみる

ユーザを喜ばせる
メモリは命

goo.gl/DqIUkで
ドキュメントがダウンロードできる

—————————————-
iPhone/スマートフォン市場に求められる
エンジニア、求人動向のご紹介
—————————————-

パソナの案件:
1日に400〜500件

デベロッパの案件が多い

ビジネス思考が求められている

常に変化をとらえられるようになる
サービス目線で考える

楽天テクノロジーカンファレンス2010へ行ってきました。

楽天テクノロジーカンファレンス2010へ参加してきたので、その時のメモを公開させて頂きます。当日は楽天の三木谷社長、まつもとゆきひろさんの講演を生で聞くことができました。

聞き違い等あるかもしれませんがご容赦ください。
なおUSTREAM等でも当日の様子が公開されているみたいです。

———————-
特別講演
———————-
楽天:
・英語公用語化
・国際化している

グローバル化する意味:
・世界における日本のGDPシェア:
 2006年は12%
 予測では2050年には3%になる
→情報格差が縮まっている

アマゾン・Eベイ:
・売り上げの半分はアメリカ以外
・広範囲に広がっている

国際化は技術的にも良い:
技術者も世界に広がっている

自国の言葉に翻訳された技術書を読んでいるのは日本人ぐらい

楽天→70%の売り上げを海外で上げることを目指す

世界中のエンジニアを束ねていきたい

ソース・アプリをどうシェアするか→プライベートクラウドによるグローバルネットワーク
・グローバルエンジニア
  日本語のできないエンジニアも参加できるようにする
・オープンソースストラテジ
  できるだけオープンソースでやっていく
・クラウド
  生産性の向上
  パブリッククラウドの利用
・RIT(楽天技術研究所)
  さらに広げていく

一流の技術者:
グローバルに活躍している

オープンソースの強化

パブリッククラウドの利用・提供:
・プライベートクラウドに取り込んでいく

ソフトの世界でも世界レベルを目指していく

楽天:
・パートナースタッフを含めて1万人
・技術が重要になってくる

オープン化、テクノロジーの差別化
→これをやりきることが重要

ハードルを乗り越えていくということにロマンや大きな喜びを持つ

楽天主義=今までやってきた事による収穫

過去に買収しグループ化した会社が大きなシナジーを生み出す
→楽天経済圏

国際レベルでビジネス/技術の共有を行い強くなる

熱い心/夢が重要

———————-
基調講演「グローバル・エンジニア」
———————-

自分の限界は自分で決める
→壁を突き破る必要がある

成功するために:
・成功とは何かを定義する
・成功の定義は人によって違う
・定義しなければ何をして良いのか分からない

成功例:
・金持ち
・名声を得る
・最強になる(能力の最高を目指す)
・平穏に暮らす
→自分で決めなければならない

人生は平等ではない:
・貧乏、金持ち、才能・・・
・理不尽でもある

成功のために向かう方向(ゲームのルール)は似ている

人間の本質;今と昔でそんなに変わらない

ゲームのルール:
・目標を持つ
  短期(1~5年以内)=現在予測できる目標
  長期(人生の目標)=テクノロジーの変化は影響しない目標、適切に立てる
  中期はいらない(予測できない、無理)
・行動する

自分自身であれ:
・(まつもと氏)プログラミングが好きだった=どこから来るかわからない強み
・好きな分野、情熱を持ち続けられるかどうか

そして実際に行動する:
・行動無くして成功なし

運・タイミングもある=かなり大きい
・Rubyでは英語のドキュメントを作成した
  →外国人の目に触れた

成功する確率は上げられる:
・時間的に
  最後までいれば勝者
  成功するまでやる
  ただし100%ではない
・ラーメン代分のもうけ
  コスト削減→ラーメンだけで生活
  軽量言語→簡単に作れる
  クラウド→初期費用を抑えられる
  ラーメン代分のもうけがあればよいと考えると
   →思い切って挑戦できる
   →失敗しても痛みが少ない
・空間的に=どこで戦うか
  専門分野で(ニッチなところ)
  広いマーケットで(ある程度お客さんがいる)
  矛盾:人がいないところでは成功できないが、
     ニッチなところでしか成功できない=ロングテール理論

グローバルなマーケットで世界に届くためのコスト
・物流
・通信
・言語
・意識

物流と通信の壁:
・20年前は海外にメールが送れなかった
・現在は壁がなくなった

言語と意識の壁:
・まだ壁がある
・北欧→英語が通じる(英語を話せないと生きていけないことを知っているから)
・日本もそうなる

自分の言葉に伝える価値があればひどい英語でも聞いてもらえる

伝える気があるか、
外に出て行く気があるか、が重要

Rubyメーリングリスト:
15年前の購読者数:200人
現在:数千人

Rubyのユーザ:
・世界で百万人を超えている
・世界が共感してくれている

今まで見ることのできなかった風景を見ることができる
→日本だけでは勿体ない

日本語でブログを書く:
・日本人にしか見てもらえない
・英語で書けば世界中の人から見てもらえる
・まだ見ぬ友と出会わないのは勿体ない

—————————————————–
HTML5 とその先にある Web of Data
—————————————————–
この内容はWebサイトでも公開されている

HTML:
・ハイパーリンク付き文章ファイル(基本はこれ)
・シンプルな役目が世界を広げる
・ウェブサイトを作成する時の材料(20世紀の定義)

ウェブブラウザ経由で見れるもの:
・見れる範囲がものすごく広がってきた
  mail、SNS、ブログ、ワープロ・・・
→今ではアプリ動作環境となっている

ドキュメントプラットフォームからアプリケーションプラットフォームへと進化した
→この変化に根本の規格から対処することになったものがHTML5

HTML5:
・仕様書800ページ超
・アプリプラットフォームとしての規格が増えた
・タグの種類が増えた
・XHTMLの後継でもある
 →きっちり受け継がれている
  XHTML=HTMLにXMLをマシン用に埋め込んだもの
・ページのタイトル、時間、個人のデータを入れるタグができる

セマンティック:
→意味論=ロジックに基づいて処理できる(~ウェブ)
・厳密性が求められている
・単一コンテキストを持つ閉じたネットワークでは有効

Web of Data:
・広大な地域に分散している研究員がデータを共有できるようにしたもの=ウェブ
・WebはもともとDB
・上記のことをきちんととらえ直してみる=Web of Data

リンクがコンセプト:
・関連する情報は役に立つ
・DBに対して貼られているリンクは1.41万個

DBpedia
BBC(英)の辞書

関連づけられたDBが存在することが大切

楽天のWeb of Data:
・WebAPIの公開
・研究所内でのデータ公開(Webからデータを抽出したもの)
・サービスの統合
・実験的な取り組み
・RDFストア

国会図書館:
RDFのデータを提供している

市民レベルの動きもある

LinkedData.jp

これからは自律・分散・協調+データ生成
→意識を変えていく

———————————————–
インターネットガバナンス徒然2010
———————————————–
JPNIC:
IPアドレス事業、インターネット基盤整備を行っている

インターネット:
・拡大している
・誰でも使うようになっている
・回線速度も速い

インターネットにも公共政策が必要になってきた

機器の標準化、ネットワークデザイン、相互接続といったインフラとアプリケーションによって便利になってきた

社会的な生活が営めるようにルールを決めていく→情報社会

社会規範と使い方→考えていく必要がある

何らかのルールを決めていかなければならない

インターネットにはルールがある、
そしてルールは自分で変えられることを知る

変える手順を知る

ルール策定の前提
・オープンフォーラム
 誰でも参加できる
・みんなで決める(ボトムアップ)

コミュニケーションは英語
・相手を正しく理解する
・自分の考えを正しく理解する
・黙っていては分かってもらえない

インターネットガバナンスに関わっている団体:
・IETF:技術標準化
    日本人100人参加
・APNIC:インターネットレジストリ
     2012年にIPV4が枯渇する問題などを扱う
     日本人16人参加
・IGF:インターネットに関する様々な問題を討議する
   政府・市民団体も参加

JPNICのサイトで情報を提供している

アプリケーションエンジニア→サービスを提供している
インフラエンジニア→サービスを受け付ける部分を担当
サービス事業者→知らなければいけないことが多い

サービス提供者の疑問=ルール等を気にする必要はあるのか?
・ルールはどんどん変わっていく
・ルールを知っていることで多面的にみれるようになる
・使っているOSがIPV6に対応しているか
・お客さんはIPV6、IPV4バラバラでアクセスしてくる
・日本だけで使われている訳ではない
・どこかで使われ始めたものは必ず影響として出てくる
・ルールに従っておくことで、イレギュラーな対応は減る

自律・分散・協調

なぜ地域毎にレジストラがあって、その中で
ルールを決める必要があるのか?
・地域の事情をくみ取る必要がある
・地域ごとに良い意味での競争がある

日本人の意見ははずれが少ないと思われている

世界で意見を通す場合:
・たくさんの他国の人と話して理解する、分かってもらう

現場の人が政策に関わることも大事

世の中のことを見聞きして世界へ出て行く

———————————————–
楽天ブックスiPhoneアプリ開発日誌
~導かれし者たち~
———————————————–
デバイス推進チームが開発

2008年12月:
・楽天トラベルアプリ

2010年6月:
・楽天ブックスアプリ
 雑誌立ち読み
 商品が買える

2010年7月:
・楽天イーグルスアプリ

2010年8月:
・楽天リサーチアプリ
・iPadアプリ

Android版アプリもリリースされている

2010年9月:
・旅メモ
・楽天証券アプリ
・楽天銀行アプリ

総計で12アプリ→力を入れている

Webのスマートフォン対応も進めている

2007年~
アクトビラ向けサービス

楽天ブックスアプリ:
2010年8月~

iJungle=イノベーション・プラットフォーム
    アプリがたくさん生まれた

担当サービスをアプリ化
→やりやすい

うる☆てく

当初社内にはiPhoneアプリのノウハウがなかった

兼務でアプリ開発

アプリで目指すもの:
・自分が使いたいもの
・シンプル
・ブラウザでの体験を越える

WebAPIを利用:
戻りはXML

ライブラリによって
パースにかかる時間に差がある(XML)

NSXMLParserがよい

libXML2もある
→アプリではこちらを採用

NSOperationqueue:
処理実行数などを制御できる

楽天ブックスアプリ=8つの機能がある

デフォルトで付いてくるサンプルプロジェクトが学びやすい

Webの決済機能をすべてカバー

暗号化→カテゴリを使う

NSURLRequest:
HTTPSでオレオレ証明書が使えない

リリース時は非公開クラスは使わない

iPhone4対応もすることになった

NSOperationに注意

画像名の後に@2Xを付ける(例:ul@2x.png)
→iPhone4に対応してくれる
 サイズの違う画像ファイルを2つ入れておく

Xcodeの設定を変えることでデバッグ情報が増える

——————————————–
トークセッション「ITエンジニアのから騒ぎ
~グローバルエンジニアへの道~」
——————————————–
海外で働くこと
・仕事の内容は変わらない
・生活で引っかかるポイントは人によって違う
・ソースコードで通じるところもある(図とソースコードが一番通じる)
・楽しめる、楽しめないは人による
・実際に話をするのが一番通じる
・少し時間が過ぎれば同じになってくる
 心配するほどのものではない(転職と同じくらい)

日本と海外の違い
・外国人は実利をとる
(仕事の進め方やシステムの拡張性に対する考え方など)
・バージョンアップ
  日本人は保守的(ノウハウが溜まってきてから行う)
  海外ではすぐに新しい物を使う(問題が出てきてから考える)
・海外では人の入れ替わりが多い=過去にこだわらない

日本と海外のエンジニアの違い
・プロジェクト内での役割分担などは同じ
・時間の使い方が違う(プライベートと仕事のバランス)
  海外→残業して無理やり終わらせたりはしない。やれる範囲でやる。
     サイドビジネスを掛け持ちでやっている人も多い(残業できない)
     マネージャーが絶対無理をさせない
・女性の仕事への参加の仕方が違う

エンジニアにとっての英語
・英語使うきっかけ=オープンソースの作者にメールを送った
・相手とどうコミュニケーションしたいのかが重要
・少し話し始めると通じる(共通の言語ができる)
・アメリカ人は他国の人が話す英語に慣れている

やりたいことをアピールしておくとチャンスが回ってくる

PHPカンファレンス2010へ行ってきました。(その2)

PHPカンファレンス2010で講演を聞いてきた時のメモ書きの続きです。聞き違いの部分などもあるかと思いますがご容赦下さい。

9/25 テックデイ
—————————–
基調講演 「PHP Then and Now」
—————————–
PHPの歴史
1993年 mozaicウェブブラウザ
1994年 PHP1
1995年 PHP2:今のような構文になった。オブジェクト指向ではなかった。

2005年 完全なオブジェクト指向へ

最新ver5.3:
・ver4に比べて高速
・スタック実装の改善
・例外処理も高速でシンプル
・コンパイラも高速かつサイズ小
・Win版は40%性能改善
・全体的に5~15%高速化

目玉となる機能:
・closuresの実装
処理の間に関数を呼び出せる
・namespaceの実装
バックスラッシュを1文字で扱える
・メソッドがどのクラスで実装したのか分かるようになった(__CLASS__)
・ガベージコレクションの実装/工夫
・NOWDOC、gotoの追加
・__DIR__の追加
・php_fpmの実装
・php.iniのユーザ向けファイル→.user.ini
・opensslの強化、openidの実装

変数でクラス名、メソッド名を指定できる

日付取得処理の改善:
・第三木曜日をイテレータで取得できたりする
・datecreateformat

この講演の資料:
talks.php.net/show/phpjp10
で公開される

古いバージョンのPHPソース:
museum.php.net
でダウンロードできる

—————————-
フレームワークアップデートLT
—————————-
CakePHP:
・リファクタリングが進んでいる
・PHP5専用になる
・PHPUnitの導入
Lithium:
・PHP5.3専用のフレームワーク
・ドキュメント 1.0のリリース時に用意される
Ethna:
・2009年10月2.5.0リリース
・UTF-8化
・国際化対応
・3.0開発中
racho:
・Object.php
・Doctest
・PHP単体で動く
Agavi:
・IISのサポート
・Azureのサポート
・例外処理の連結
codelgniter:
・世界第二位
・2011/2/19に東京でイベント
・軽い、覚えやすい、拡張が容易
ZEND:
・ドキュメントのアップデート
・コンポーネントの追加
Symfony:
・2.0開発中
・Httpkernel
・HttpAceralator=レスポンスをキャッシュ
・profiler

————————–
HiPHoP for PHP
————————–
facebook:
・ユーザは80億分/1日ぐらいの時間をサイトで使っている
・毎月30億枚の写真がアップロードされる
・1億人が利用している

PHP:
・言語の中で最も処理に時間がかかる
・メモリ使用量が多い

facebookでは、PHPのソースを他の言語でも再利用している

HipHoP for PHP:
・PHPのソースをC++に変換
・C++をコンパイルして実行

処理の流れ:
ソースの分析→型の推定を行う→コードを生成/出力

HipHoP用にソースを書き直さなければならない部分もある:
・eval()、create_function()
・順番(関数の定義順)は意味がなくなる
・コンパイルには時間がかかる→インタプリタを使う(HPHPi)
・apacheなしでも動く

HipHoP:
・オープンソース化されている
・PHPエクステンションをサポート
・5秒かかっていた処理を1秒に短縮
・実際の処理時間は2分の1程度になる
・PHPの最適化が限界に来たので開発された

————————————————-
Microsoft ♥ PHP ~ 2nd Stage ~
WebMatrix 登場!
————————————————-
IIS7でPHPサポート:
実行環境までマイクロソフトが作成している

SQLserverと接続するドライバも開発されている(PDOも使える)

PHP環境作成ツール:
Web PI→PHPのインストーラ=Web環境を作成する
Web Matrix→Webサイトを構成する

上記のツールの特徴:
・IISを個別にインストールする必要はない
・簡易的に様々な開発が行える
・DBクエリの実行も行える
・テンプレートも存在している(ASP用)
・ブラウザを切り替えて表示を確認できる
・SEOのチェックができる(外部サイトも可能)

http://microsoft.com/webに情報がある

————————————————-
文字コードに起因する脆弱性とその対策
————————————————-
Unicode: /¥ → MS標準: ¥

多対一の変換になるもの=文字化けが発生する

UTF-8:
・1〜4バイトで文字を表現
・5C問題は発生しない

半端な先行バイトによるXSS

5C問題:
・shift_jisで0x5cのコードが存在する文字を利用することによる問題
・SQLインジェクションに利用される

charsetの定義は正しく行う
→脆弱性が発生する場合がある

対策:
・最新のPHPを使う
・文字コードの指定をさぼらない
・mb_xxxxxx関数を使う

————————————————-
PHPストリーム概説
————————————————-
ストリーム:
・何でもファイルのように扱える、標準入出力みたいなもの
・Get、Postの指定、リクエストヘッダ等

ストリームフィルタ:ストリームを加工できる

————————————————-
新潟アクセス修飾子のご提案
————————————————-
アクセス修飾子:
public
protect
private

zendエンジンを修正することで修飾子を追加することができる

エラーメッセージの出力部分を探してそこからソース解析する

zend中間表記+パースの部分を修正する

————————————————-
PHPの中の人によるパネルディスカッション
————————————————-
PHPによって容易にウェブにアクセスできるようになった

PHP6での国際化:
・いまのところプランはない
・Unicode対応を急ぎすぎた

様々な機能を追加:
・使いやすさが減少して行く心配がある

型のチェックを厳しくするとソース全体へ影響を与える

内部をすべてUTF-8化する取り組み→4年位続いている

PHPのコミッタ:世界で1500人位いる

一人がすべてを決めるのではなく、
グループがコンセンサスをとりながら開発して行く形が望ましい

ユニコード対応:
マルチバイト圏の開発者はまだ少ない

facebook側:理想を言えばPHPの方でユニコード対応してほしい

————————————————-
ライトニングトークス
————————————————-
■CodeIgniterをベースとしたCMS「seezoo」をオープンソースでリリース
seezoo:
・CMS
・codelgniterを使っている
・2010/10/1に安定版をリリース

■日本一の twitter bot サービス twitter bot GENERATOR
twittbot:
・twitterボットを作成できる
・138万/1日つぶやき
・twitter全体のつぶやきの1%を占める

■激安VPS + nginx + PHP-FPM
nginx:HTTPサーバ、メモリを消費しない

■PirumではじめるオレオレPEARチャンネルサーバー
Pirum:
・PEARチャンネルを管理するツール
・PEARからインストールできる

■PHP で 3D プログラミング
phpopengl:OPENGLを使っている

■やったーPHPでPEGパーサコンビネータできたよー
OpenPEARPEG:
・パーサコンビネータ
・パーサを記述できる

PHPカンファレンス2010へ行ってきました。

先週のことになりますが、PHPカンファレンス2010という催しで講演を聞いてきましたので、その時のメモ書きを公開させて頂きます。聞き違いの部分などもあるかと思いますがご容赦下さい。USTREAM等でも当日の様子が公開されているみたいです。

9/24 ビジネスデイ
———————————————————————————–
基調講演 「GREE Platformの現状と今後の取組について」
———————————————————————————–
お題:
・どのようにしていきたいのか
・オープン化してみて

2010年7月の会員数→2100万人以上(mixi、モバゲーも同じくらい)

Nintendo DSの販売数=3000万台
→GREEも同じスピードで成長

30代以上の会員も3~4割存在

GREE:オープン化でアプリの充実を目指す(会員数3000万を目指す)

ソーシャルゲーム市場は数億円規模に:
2011~2012年には本格的になる見通し

ソーシャルゲーム:
・開発費を抑えてスモールスタートが可能
・広告費も段階的に増やして行け、かつ高い利益を目指せる

運用/PDCAの重要度が高い

2010年6月末オープン化開始:
・改善を続けていかないとプラットフォームとして育たない
・画面/仕様を変更
・パートナーさんのアプリをCMで紹介(GREEが全額を負担)
・コンサルティングを行う

オープン化の結果:
・ユニークユーザー数の増加
・自社開発ゲームへのネガティブな影響はなし
・サイト導線を改善し、課金額・会員数も増加

4つのポイント:
・オープン=参入しやすい
・サービス改善=変更・改善を繰り返してゆく。トラフィックも変わってくる
・コンサルティング=データの提供、データに基づいたアドバイス(パートナーとともに成長してゆく)
         ゲームはそのまま公開してうまくいくケースは少ないので、ベータ期間を設けたりする
・プロモーション支援=年末までに30タイトルのTVCM(GREEが全額負担)

今後の展開:
・スマートフォン対応(アンドロイドがくる)
・アジア・北米への展開

—————————————————–
モバイル ソーシャルアプリの開発と運用
—————————————————–
ウノウ(株):フォト蔵を運営

まちつく:300万インストール

オープンソーシャル:
・ユーザはプラットフォームを介してアクセスする
・友達・自分情報を取得できる
・APIを利用する
・OAuthで機種/個人を特定する

OAuth(opensocial_php_client)→グーグルコードのサンプルソースが参考になる

OAuthが使えるライブラリ:
・OAuth Consumer And Server Library for PHP
・Pear OAuth
・PECL OAuth
→Pear OAuthが一番良い

毎回データを取りに行くと遅くなる=キャッシュ、キューを使う処理が必要

APIがつながらないことが多いので、そのための処理が必要

オープンソーシャルのサポート側:
・問い合わせが多いのでシステム化が必要(1日最高でメール1000通)
・問い合わせを減らす工夫が必要
・重い負荷のかかった機能を一旦切り離して停止させる覚悟も必要

オープンソーシャルの運用:
・エンジニアに負担をかけないようにする
・ユーザアクセス数の少ない時間帯にメンテナンスを行う

オープンソーシャルの設計・企画:
・友達リストを取得するような処理は重いので避けた方がよい
・APIをできるだけ使わないようにする
・一日一回しかできない機能=午前4時などに更新するようにするとトラフィックが安定する
・やっている時にニヤッとしてしまうような機能がソーシャルには重要

オープンソーシャルの開発方法:
・Proxyサーバ、sandobox+firemobilesimulatorを利用
・もしくは通常のサイトとして開発

システム構成:基本はLAMP環境
・memchache→これがないと死ぬ
・Q4M
・Nginx→プロキシ
(下記二つは運用・設定ファイルの更新に利用)
・Puppet
・Capistrano

DB:
・可能な限りメモリを増やす
・ボトルネックはDISKアクセス
・できるだけデータをメモリにのせる
・レプリケーションはあまり効果がない
・マスター分割すると性能が2倍になる(ただし開発コストも増大)

フレームワーク:
・symfony(ORMに詳しくなくても実装できる)

swfEditor:swfのバイナリを書き換えられるツール

—————————————————–
~モバイルオープンソーシャルにも対応!
~ OpenPNE Ver3.6紹介
—————————————————–
手嶋屋:OpenPNE(2005年スタート)を開発、オープンソース化した会社

SNS:情報ネットワーク社会のさきがけ
   週100~150サイトが新規開設されている

エンタメ系のSNSが多い(オンラインゲーム、ファンクラブ、ケータイゲームなど)

OpenPNE:日立、NEC、セイコーエプソン、バンダイ等で使われている

OpenPNE3.0:
・つぶやき機能を追加
・日記、ランキング、コミュニティもあり
・機能は着脱可能、モバイルでも利用可能
・モバイル対応

Symfonyを利用している:
・OpenPNEのプラグインはSymfonyのプラグイン機能を利用している
・OpenPNEソースはSymfony開発時に参考になる

Ver3.7以降、最新のモバイルオープンソーシャルに対応していく:
・twitter機能に対応
・iPhoneにも対応予定

OpenPNEを利用している150万ユーザークラスのサイトも存在している

資料はあとでブログに公開される(という話でした。)

—————————————————–
大ヒットソーシャルアプリの裏側
—————————————————–
ソーシャルアプリ:
・SNSの機能が使えるアプリ
・APIなどを利用する
・集客コストがかからない
・OpenSocialAPIを使うことによる開発コストの削減

誰も考えないようなテーマ、独自の機能を考えることが重要

他社との差別化をしないと生き残れない

恋したキャバ嬢:
・大ヒット
・負荷がすごい(最大2000PV/sec)

競合他社とテーマが重なった場合、新規機能を追加して差別化をしていかないとだめになる

手戻りが発生するとリリースが遅くなる(機会損失)
→自ら提案することで企画の意図が分かるようになり、手戻り減につながる

企画と一体になる=楽になる

負荷について:
ユーザ固有のデータ=アクセス、更新頻度高
→ソーシャルアプリでは特に負荷が高い、マスターDBへの負荷集中

Ganglia=オープンソースのモニタリングソフト

Symfonyがベース

画像合成処理:
・キャッシュは非効率
・ローカルファイルはI/Oアクセスが増える
・素材ファイルのみキャッシュ+GD高速化で対応

マスターDB対策:
・なるべくDBに接続しない
・クエリ最適化
・使わなければ接続を切る

DBコネクションの節約方法:
・memchacedの利用
 DB更新時にキャッシュも更新
・APCキャッシュ→更新が少ないときに有効
・KVSの利用(TokyoTyrant)
 1.データ消滅の心配がいらない
   →頻繁に更新されるステータスに有効
 2.不整合が起こりうる
   →例外が発生してもユーザが得をするかたちで解消できるような処理の流れを作る
・スレーブDBを利用
 レプリケーションの遅延は起こりうる 

APIとの通信:
・レスポンスタイムアウトは普通に起こりうる
・APIへのリクエスト→DB更新とは分ける

—————————————————–
Scaling the Worlds Largest Social Gaming Network
世界最大ソーシャルネットワークゲームのスケーリング
—————————————————–
Zyngaのミッション:ゲームを通じて世界とつながる

ソーシャルゲーム:
・プレイが簡単で楽しい
・他人とつながる

月間ユーザ2億4000万
ゲームの体験者数:3億2000万

拠点は世界にある:
・世界のインターネット人口の10%がプレイしている

Facebookのトップゲーム:Zyngaが占めている

一週間に1000台のサーバを増設することもある

データ量1PB

システムの構成:
Webサーバ ー memchache - DB

サーバはすべて水平方向にスケール:
・キャッシュし、非同期

完全に自動化、API化されている

APIレスポンスキャッシュ内蔵

KVSを利用

DBはデータストアとしてのみ利用する

持続型memchached(membase)を利用
→分散型KVS
・速度、柔軟性がある
・クラスター内に存在している

利用しているもの:
membase
mcmux
(上記2つはオープンソース)
pecl-memchached
FontLabel

ゲームごとに作り方が違う

既存のソースを流用しているため、
特定のフレームワークに頼る必要は無い

XP祭り2010 ~ アジャイル学園祭~ 2010/09/04

昨日「XP祭り2010」というイベントに参加して、アジャイル開発に関する話を聞く機会があったので、その時に話を聞きながらつけていたメモを公開させていただきます。聞き違いの部分もあるかもしれませんがその点はご容赦ください。

XP祭り2010は企業などが行うカンファレンスと違い有志の方が行われているイベントだったのですが、来場されている方もとても多く、活気のあるイベントでした。話を聞き終わった後、早速書店でアジャイル開発の本を購入しました。

———————————–
オープニング ~XP入門
———————————–

XP→優れたソフトを開発すること

  ソフト開発の多くはカイゼンである

  人が大切
  最もよい自己になるためのプロセス

焦点
* プログラミング技術
* コミュニケーション
* チームワーク

ニコニコカレンダーもXP

価値とプラクティスの隔たりを埋める

カイゼン:少しずつ良くしていく、できることから良くしていく

紹介されていた書籍:XPエクストリーム・プログラミング入門

———————————–
招待講演 ~アジャイル×テスト開発プロセスを考える
———————————–

コンテキストを意識する
→雑誌や他人のうまく行ったやり方がそのままうまく行くことはない。

※コンテキストとは:デバイスが使われている状況を意味する。例えばある時点で
 デバイスを使用しているユーザーなど。
参考:ウィキペディア

ウォーターフォールかアジャイルかで
品質の有利/不利はない。

ウォーターフォールがうまく行かない原因→人災
 上流工程で矛盾が発生すると、下流工程では直しづらい
 組織・体質的なものもある

目標となる品質:
計画において定義し、共有することが大切

Wモデルに沿って、テストモデルを構築するためのプロセスが必要

※Wモデルとは:
Vモデルの改良版開発モデル。Vモデルの作り込みプロセス(要求定義、要求仕様、アーキテクチャ設計、詳細設計)内で、各プロセスに対応する試験を設計・レビューすることで、素早いフィードバックを得ながら開発を行う。
参考:
http://log2remember.blogspot.com/2009/08/w.html

テスト設計を早期に行うことによって設計のもれなどに気づくことができる

開発にあわせてテストモデルを育てていく、質を上げていく

———————————–
アジャイル開発の現在・過去・未来
~今を知り、源流を訪ね、先を見据える~
———————————–

XP(エクストリーム・プログラミング)→アジャイル

既存のウォーターフォールモデル:
・ITに関わる人はシステムのことだけ考えがち
・システムには使われない機能が多く存在している

ウォーターフォールの欠点:
・開発しているうちに市場のニーズが変化している

アジャイル型開発:
・ビジネスとITが一体化
・戦略を作りながら進む
・短いサイクルで分析、設計、実装、テストを並列に行う
・ホールケーキを小さく切ってショートケーキをいくつか作るのではなく、最初からショートケーキをいくつも作っていくイメージ

アジャイル:本を読んで覚えるのは難しい
      コンテキストが現場によって大きく違う

アジャイルの元になったもの:
・リーン(トヨタシステムが源流)
・スクラム
・XP

アジャイル現状の課題:
・大規模化
・組織改革
・UX(ユーザーエクスペリエンスデザイン:ユーザーがある製品やシステムを使ったときに得られる経験や満足など)

注目を浴びているもの:
・kanban

アジャイルを採用している企業:
・セールスフォース
・富士通
・リクルート
・良品計画

業務とシステムは表裏一体

kanban:アジャイルからのスピンオフ
 説明のできるような形でアジャイルを推進する
 価値を一つずつ後の工程に流していく

kanban:1日で1個完成させることを365日繰り返す 仕掛かり小
ウォーターフォール:365日で1個完成させる 仕掛かり大

kanban→WIPとリードタイムを少なくする

※WIPとは:Work In Progress、仕事・開発の進行状況
※リードタイムとは:作業の着手から終了までに要する時間のこと

アジャイル失敗の原因:経験不足+カルチャー
           経験者がいた方が良い

アジャイルでよく使われるツール:エクセル

スクラム方式で実践しているところが一番多い

スクラム憲章、アジャイル宣言というものがある

紹介されていた書籍:アート・オブ・ディベロプメント

アジャイルは海外ではとても活気がある