優れたプロダクト・マネージャーの条件 [memo]

どれも共感するものばかり．
Product Hunt Blog - What Makes a Great Product Manager? 10 Product Experts Weigh In

特にこの辺りはプロダクト・マネージャーに限らず，モノ作りに携わる人間なら，誰もが共通して保有すべき属性のように思う．

Ever curious, open to new ideas, perceptive, listens, and evolves through time.

They think of building a product as a continuous cycle of learning, convincing, documenting, refining.

At the heart of PM is knowing how to obtain data, decide what data is relevant, and acting on that data to globally maximize engineering efforts.

I think a good product manager is Customer Driven.

私が個人的に考えるプロダクト・マネージャーとは，プロダクトやサービスを作る上で，"Why do you want to do this?" というシンプルな問いに，プロジェクトメンバーの誰よりも愛情と情熱を持って回答できる人間だ．

UI/UX ここだけの話 大放出 - スマホデザイン忘年会議 #sdkaigi [seminar]

第5回目を迎えた，スマホデザイン会議に参加してきました．今回は，「UI/UX ここだけの話 大放出」というテーマです．

スマホデザイン忘年会議2012 on everevo

そこで今回は、年末ということもあり「スマホデザイン忘年会議」と題して、今まで皆様より質問の多かった下記のような疑問について、ここだけでしかできない、施策・失敗例・成功例・数字などの実例を交えながらトコトン掘り下げていきます！

KPIってどの数字を取ってるの？
UIってどう設計して、どう改善してるの？
UXの評価ってどうするの？デザインvs機能 どっちが大切？
どうしたらワクワクするデザインにできるの？
ユーザーの声はどういった基準でデザインに反映するの？
UCDの実施は具体的にどうするの？
PCとの違いって？スマホだからできることって？

以下，メモです．

---

【fladdict 流の UI デザイン】
by Art & Mobile 深津貴之氏 (@fladdict)
発表資料

iPhoneアプリ設計の極意 の巻末付録に寄稿した，「fladdict 流の UI デザイン」の内容をブレイクダウンして説明．

- コアコンセプトを最初に決める
　- 誰が
　- 何を
　- いつ
　- どう

- 複雑な機能を全てスマホに盛り込むことはできない
　- 何を取って何を捨てるか，が重要
　- 90%のユーザーが必要なことを考える
　→ コア機能を抽出する

- 4つの UI パターンから選ぶ
　- ユーティリティ型
　- ナビゲーション型
　- タブ型
　- 没入型
　→ ペーパープロトで全パターン試して，問題を予見する
　→ 最初に間違えると，その後ブラッシュアップしても使いやすくならない

- ここまでは広く浅く，パターンが決まったら狭く深く
　- 問題と原因を網羅するには，フィッシュボーン図を使う
　- 曖昧な問題を，複数の具体的な問題に分割する

- プロトを繰り返し，フィッシュボーンで洗練させてから，ビジュアルデザイン

- 拡張性
　- 初期バージョンで，ボタンを詰め込みすぎない
　- 将来，機能がいくつか追加されることを前提に
　- 機能を増やして，使いにくくなったら意味がない

- PDCA サイクル
　- Plan
　- Do
　- Check
　- Action
　→ これをきちんと回さないと，誰も使わない，あるいはクライアントしか喜ばないアプリになる

- まとめ
　- 常に立ち返る所 (コアコンセプト) を最初に決める
　- 初期に可能性をしらみ潰す
　- プロトタイピングを何度も繰り返す
　- ここまでやれば，実装は機械作業

所感:
数々のヒットアプリを手掛ける fladdict さんだけあって，説得力があり，内容も具体的．とにかく，この一言に尽きます．

これは1万回ぐらい繰り返し言いたい RT @toshiya: 機能を増やして，使いにくくなったら意味がない #sdkaigi

— Toshiya HASEGAWA (@toshiya) December 21, 2012

【これからの Lean UX の話をしよう】
by 利用品質ラボ 樽本徹也氏　　
発表資料

- もしせっかく作った製品が売れなかったら?
　- 「企画や営業，開発などを強化しなければ」という流れになる
　- 組織がどんどん太っていく
　→ そこで Lean (贅肉・無駄がない)

- 製品開発における最大の「無駄」とは?
　- 誰も使わないものを作ること

- 良い製品は良いアイデアから生まれる?
　- アイデアは仮説に過ぎない
　- 検証していない仮説は単なる「思い込み」に過ぎない

- 検証のプロセス
　- 課題検証
　- ソリューション検証
　- 製品検証
　- 市場検証

- Problem Interview
　- Early adapter の把握
　- Must-have problem の把握
　- 既存代替策・既存製品の把握

- Solution Interview
　- MVP (Minimum Viable Product) の要件定義
　- ユーザーは MVP をいくらで買ってくれるか，という価格
　- 持続可能なビジネスモデル

- 「設計・開発」は，ここからの作業
→ 以上のことは，企画レベルで終えてなければならない

- MVP Interview
→ ユーザーテスト

- メトリクス
　- 総ユーザー数
　- アクティベート数
　- 再利用ユーザー数
　- 有料会員ユーザー数
　- バイラルしてくれたユーザー数

- 会議室で議論しててもダメ，実際のユーザーに触れよ

所感:
アプリ開発に対する「心構え」みたいなものが聞けました．経営陣にも聞かせたい内容．

特にこの一言は心に響きました．

「商売をするんですから，私達は．売れないといけない!」 #sdkaigi

— Toshiya HASEGAWA (@toshiya) December 21, 2012

【Android における UI/UX】
by AKQA 佐藤伸哉氏
発表資料

- UI パターンを知り，Android らしい UI を作る

- Android Design で定義された，アプリの階層構造
　- Top level views
　- Category views
　- Detail/edit view
　→ 極力シンプルに，深い構造を作らない

- 階層構造のより分かり易い考え方
　- 第1階層 (Action Bar = トップレベルの選択階層)
　- 第2階層 (Tab など，カテゴリレベルの選択 = 選択された情報の階層)
　- コンテンツ

- 具体的に実装した例
　- Google Maps, Gmail
　→ 一番参考にすると良いアプリ

- 階層構造を使い易くするコツは Action Bar

- トップレベルの定番パターン
　- Tab Nav. (Scrollable Tab)
　- Pull-down Nav. (Spinners)
　- Drawer Nav. (Drawer)

- コンテンツレベル，情報の表示の定番パターン
　- Visual View
　- Content View
　- Content detail View
　- Thumb-Nail List View
　- Simple List View
　- Split View

- コンテンツレベル，情報のアクションの定番パターン
　- Bottom Action
　- Pull-down Action

- コンテンツレベル，情報の編集の定番パターン
　- Edit First
　- Edit Last

- 以上13パターンを組み合わせて作るのが Android アプリの基本

所感:
基本的な内容に終始したのが残念ですね．佐藤氏にしかできない話をしてほしかった．


【トークセッション】
by TechWave 副編集長 増田真樹氏 x ゲストスピーカー3名

(増田)
ステートメントのまとめ方は?
使われるものを見出し，市場に受け入れられる企画に落とす際に必要な，情報やプロセスは?

(深津)
Amazon は最初にプレスリリースから書き，それが魅力的だと思えたら開発に着手するのだとか．それはアプリ開発にも使える．自分の場合は，100字以内にまとめる．100字にまとまらないなら，要件がまだ曖昧なのでアプリを作る段階ではないと考えている．

(佐藤)
他との差別要因を明確にする．競合と何が違うのか，ユーザーにどんなメリットがあるのか，を考える．「最終的にこれは何なの?」というのを，最初に考える．

(樽本)
逆に，ステートメントを定義しないで，どうやって作るの?

アイデアは，自分やユーザーをよく観察して，なにを不便に感じているかを捉えるところから出てくる (ジョブズみたいに「降りてくる」人もいるだろうけどｗ)．ユーザー調査やグループインタビューからは，アイデアは出てこない．実際にユーザーを見ないとダメ．

(増田)
ステートメントがまとまったとして，それの交渉の仕方は? クライアントの落とし方，妥協の仕方．

(深津)
僕のやり方はかなりイレギュラーですけど…

初回に，全画面遷移を書いて見せてしまう．その時点で企画書は無力化し，自分が主導権を取れる．それで最後にはこっそり画面遷移が変わってるｗ

(佐藤)
企画が通せないということは，相手が理解できていないということ．イコール，自分も分かっていないのでは? 努力が足りないだけだと思う．

(樽本)
「チームをまとめる一番良い方法は」と質問を置きかえて答えると，全員ユーザーに会わせること．エンジニアもデザイナーもマネージャーも．

(増田)
ユーザーテストはどのようにやっている?

(深津)
僕は1人でやっているので…予算やリソースがある時はちゃんとやるけど，そうじゃない時は以下の2つの方法．

バーで酒を飲みながら自分のアプリを最後まで説明できるか．自分のオカンが使えるか．

(樽本)
会社内だったら，開発部門以外の人間にちょっと使ってもらう，ぐらいでもかなりのことが分かるはず．

カメラでテスターを撮影するような，ちゃんとしたテストをする時は，必ずテスターの指を撮ること．指は口ほどにモノを言う．

(増田)
機能の削り方，改善の仕方は?

(深津)
機能の向上と利便性は比例しない．それをいかに自分で肌感覚で持ち，相手に肌感覚として持ってもらうか．自分で作っているアプリなら，1週間使わない機能は削っていく．クライアントがいる場合は，プレゼン芸などで無理矢理納得してもらう．「iPhone も最初はコピペがなかった」と言ったり「100徳ナイフ」の画像を見せたり．

意思決定もコスト．選択肢が多いということは，それだけコストがかかる．それを意識しないといけない．

(増田)
素敵なスマホ UI デザインについては，どう考える?

(佐藤)
HTML5 か Native か，で言えば，Native．
Native じゃないとハードウェアが持っている性能を発揮できない．

(深津)
素敵な UI とは，使っている時に，状況とか世界とかを，自分がコントロールしている感覚があるもの．因果関係がしっかりしているというか．

押したいところにボタンがある，消したい時に消せる，みたいな．

(樽本)
まずアプリは役に立たないとダメ．実用性ではなく，その人を喜ばせる，という意味で．

(会場)
アプリのアクセス解析ツールについてはどう考えているか?

(佐藤)
必要ないと思う．

(深津)
アプリに埋め込んだことはあるが，ユーザーの顔を見なくなってしまう．10万ダウンロード以下のアプリには必要ないと思う．

(樽本)
監視するのもいいが，数字が悪化したした時に行動が取れるようにしておく (実ユーザーにアクセスできるとか) の方が大切．

(会場)
お3方が，自分のアプリ以外で，一番好きなアプリは?

(深津)
Paper．
似たようなアプリを作っていたが，Paper で満足して開発をやめてしまった．

(佐藤)
Gmail と Simeji．

(樽本)
MUJI NOTE とか iBooks とか．

---

発表者，及びスタッフの皆さん，素晴らしいセッションをありがとうございました．

クラウド誕生 - セールスフォース・ドットコム物語 / それと，理想的なモノづくり企業が保有すべき要素 [book]

「クラウド」という言葉が一人歩きし，バズワードとなって久しい昨今，クラウドを語らせたら最も説得力がある人の本を読んでみました．

著者は，Salesfoce.com の創業者であるマーク・ベニオフ．
クラウドコンピューティングというと Google や Amazon のような企業を思い浮かべ，Salesfoce.com については名前すら聞いたことが無いという人もいるでしょうが，この企業はクラウドコンピューティング業界ではじめて10億ドルの売上を記録し，460億ドル規模の市場を作り上げたリーダーであり，Forbes に言わせれば 世界一革新的な企業 です．

そして個人的には，マーク・ベニオフは，日本で言えば盛田昭夫や本田宗一郎に匹敵する起業家であると捉えています．いやそんな例えが古くさいのであれば，トニー・シェイと並んで，徹底的な顧客満足と啓発的な会社作りにこだわり，それを成功させた起業家と言えるでしょう．


「クラウド誕生」という本書のタイトルは誤解を与えるかもしれませんが，本書はクラウドの解説を試みるものではなく，そんなベニオフが Salesforce.com という破壊的イノベーション企業をどのように立ち上げ，どのように成長させてきたかを綴ったものです．

- 起業戦略
- マーケティング戦略
- イベント戦略
- セールス戦略
- テクノロジー戦略
- 社会貢献活動戦略
- グローバル戦略
- 財務戦略
- リーダーシップ戦略

というパートに分け，合計111のアドバイスを解説しています．それら1つ1つは2-4ページ程度と読みやすく，小手先のテクニックではない普遍的な哲学であり，彼の理念とそれを具体化した戦術が紐解かれています．

前エントリーで「線引き」についてこんなことを書きましたが，

妥協するところは絶妙に妥協し，譲らないところは1歩も譲らずに引いた線は，直線ではなく，ぐにゃぐにゃした線のはずです．直線なら素人が引いても10回に1回は成功するかもしれないが，ぐにゃぐにゃした線は当てずっぽうでは引けないのです．

Peace Pipe: 「グローバル」って言いたいだけだろ…? [memo]

まさに本書は，ベニオフが引いてきたぐにゃぐにゃした線の軌跡の記録です．特に，技術者であれば「テクノロジー戦略」には共感できるはずだし，上っ面の「グローバル」という言葉を唱える人には「グローバル戦略」を読んで頂きたい．


…さて，会社で働くとは，どういうことでしょうか．

仕事以外に大切なことが沢山ある? それはまったくその通り．
趣味に生きるから仕事は楽で適当に済ませられるものがいい? それも1つの考え方でしょう．

でもせっかく人生の大きな部分を占めるものであるなら，仕事もおもしろい方がいい．なにか，働く喜びを感じられた方がいい．

給料が高い ことでも知られる Salesforce.com ですが，本書でベニオフは「当社が，価格を武器にサービスを販売しているのではないように，報酬を武器にひとを惹きつけているわけではない．もっと持続性のある，他社には真似のできない何かを売りにしているのだ」と明言しています．

あなたは，給料以外に，仕事に何を求めますか?
私の場合は，こんなものを求めています．これらは私が考える，モノづくりを行う企業・組織が保持すべき要素の7箇条です．

- 年齢ではなく，実力による評価
- 顧客に対する，透明性とコミットメント
- ユーザー体験に変革をもたらすことへの，こだわりと情熱
- 人と同じことを是とせず，創造性を促進する，オープンな環境
- 意思決定，ローンチ，変化に対する順応，という3点におけるスピード
- 優秀かつ才能ある人材から成る，瞬発力があり，粘り強く，生産性が高いチーム
- 指示や命令ではなく，メンタリングによる人材育成・人材指導

本書を読む限り，ベニオフのビジョンを実装した Salesfoce.com という企業は，どうやらこれらを兼ね備えているように伺えます．


余談ついでに，バズワードとなった「クラウド」という言葉について，あるエピソードを紹介しましょう．元々は凄腕プログラマー，その後エンジニアとは別の人生を歩んでいる，という友人がいます．その彼がこんなことを言ったことがあります．

もう技術から遠ざかっちゃってて全然分からないんだけどさ，最近「クラウド」って流行ってるじゃない?

あれって，要は API と何が違うの?

一瞬とんでもなく的外れな発言のように思いましたが，次の瞬間ハッとしました．このギークは本質を見抜いていた…少なくとも実体が曖昧なまま「クラウド クラウド」言う輩とは違い，誰も言わなかった具体的な言葉に置き換えてきたのです．事実，本書でベニオフも「クラウド」という言葉については，つきつめて要約すると「クライアント・サーバーモデル」ぐらいのことしか言っていません．


…えっと，後半はいろいろ脱線しましたが，本書は経営者や組織のリーダーはもちろん，テクノロジー業界に携わっているかどうかは関係なく，全てのアントレプレナーシップを持つ人に勧めたいガイドブックです．

当時の一般的なプログラマーは，大がかりで堅牢なコードが美しいと考える傾向があった．私たちは違った．複雑なコードはやがて膨れ上がり，スピードが落ちる．なので，できるだけコードの無駄を削ぎ落とし，最低限に留めようとした．このようなアーキテクチャだと，後に拡張したときでも，問題の切り分けが簡単になる．

-- Marc Benioff / 本書「テクノロジー戦略」アドバイス53「強固な基盤となる試作品に長期的に投資しよう」より

新規顧客を獲得する第一歩として，その顧客の海外支店に狙いを定めるのは大変に有効だ．

-- Marc Benioff / 本書「グローバル戦略」アドバイス87「地域を一括りに考えないこと」より

あらゆる業界のひとたち (特にテクノロジー業界がそうだが) が，1年間でできることを過大評価し，10年間でできることを過小評価している．

(中略)

目の前の機会を逃してはならない．想像し，発明し，破壊し，善を成そう．これまでとは違ったやり方で自分のアイデアを追及するには，熱意が必要だし，理不尽になる必要もある．それに，少しおかしいと思われるぐらいでなければならない．しかし，そのことには価値があるし，そこに投資すればするほど，人生はより大きなものとなる．あらゆる人々の成功を考えれば，必ず報われる．そのことは私が約束する．

-- Marc Benioff / 本書「最終アドバイス」アドバイス111「すべてのひとを成功させよう」より

クラウド誕生 セールスフォース・ドットコム物語

「グローバル」って言いたいだけだろ…? [memo]

「グローバルに活躍できる人材育成を…」とか「グローバルなビジネス展開を…」みたいな話は時折耳にしますが，そんなことを声高に言っている人に限ってその内容が単に「英語が話せること」とか「海外展開すること」だったりしてゲンナリすることもあります．

製品における個別最適という観点で考えてみたいと思います．

世界の国々で文化やトレンド，ライフスタイルが違うことは言うまでもなく，ビジネスを行う対象国の事情を汲み取ったモノ作りが大切と一般的に言われます．その為に，日本の殻にこもらず，積極的に外の世界を見ることが重要だと．

否定はしませんが，もう少し深く考える必要がありそうです．

例えば iPhone や iPad など，単一モデルで世界を席巻している製品は，どう説明するのでしょうか (キャリアの違いから生じる差分や，日本ではデフォルトでカメラのシャッター音が消えない等，厳密には若干の地域差分はありますが)．

「クールな製品であれば，文化やライフスタイルを越えてヒットする」ということ?

…全然違う．

iPhone/iPad は，ハードウェアやソフトウェアの基本部分は世界共通でも，その上に乗るコンテンツ，つまり iTunes ストアは国ごとに展開されており，規約やライセンスも各国で異なります．音楽やビデオに限らず，自分好みのアプリをインストールするという一般的な使い方において，エンドユーザーレベルではまったく別の，国ごとに見合ったコンテンツ流通経路を通じて製品を体験していると言えます．単に，日本では未だ iTunes Match が使えないという点だけ取りあげても，iOS デバイスがもたらすユーザー体験は日本とアメリカで大きく異なるでしょう．

要するに，iPhone/iPad のモノ作りにおいて，Apple はあくまで「プラットフォーム」を提供し，国ごとの細かいカスタマイズはコンテンツ (ストア)，サードパーティー，アプリ開発者の側に振って，線引きをしているのです．

サービスではどうかと，Facebook に目を向けてみます．

例えば「コネクションサーチ」は，日本におけるユーザーの確保，また mixi という先行者がいる中でリリースされた，日本独自機能です．一方で，アメリカにおける Quora のようなサービスの台頭を受けて同じような Q&A 機能をリリースしたり，「特定のスマートフォンを特別扱いしない」と明言していたりします．

ソーシャルグラフという価値提供，及びそれを成長させ囲い込むというビジネスモデルを軸に，やはり一貫した線引きがありそうです．

言いたかったことは，「なんでもかんでも国ごとにテーラリングすれば良い」というものでもなければ，「世界に通用するカッコいいサービス・製品を作ろう!」という単純な話でもない，ということです．

仕様だけでなく，販売やサポートにまで広げると，さらに話は複雑化するでしょう．どこまでを本社に集約させ，どこから現地化するのか，何をどこまで個別最適するのか．その手段と目的は何か．

…のような戦略，及びそれを考えられる人．
それが私が考える，グローバルの定義です．

自社の状況やカルチャーを肌感覚で持ち，対象製品やサービスとビジネスの特性，及び対象地域の環境や文化を理解し，それを具現化する為の手段を複数提示して，それぞれのメリット・デメリットを精査した上でトレードオフのバランスを取り，多種多様なステークホルダーとコミュニケーションを取って合意形成を図り，線引きを行う．

以前も書きましたがこの線引き，妥協するところは絶妙に妥協し，譲らないところは1歩も譲らずに引いた線は，直線ではなく，ぐにゃぐにゃした線のはずです．直線なら素人が引いても10回に1回は成功するかもしれないが，ぐにゃぐにゃした線は当てずっぽうでは引けないのです．

エンジニア type の取材を受けました [memo]

[コラム] ソニー「ソフトウェアスペシャリスト認定コンテスト」が伝える時代の変化～開発者の想像力が未来を支える～ ｜エンジニアtype

Web と家電 - 第25回 HTML5とか勉強会メモ #html5j [seminar]

第25回 HTML5とか勉強会に参加してきました．
1月18日 第25回 HTML5とか勉強会(東京都)

会場がソニーさんということもあって、今回は「Webと家電」をテーマに勉強会を開催したいと思っています。 普段とちょっと毛色の違うテーマですが、楽しみにしていてください！

以下，メモです．

---

【ゲーム，新聞，家電業界などの HTML5 への対応】
　by KDDI 総研 小林雅一さん (@mkoba1000)

- Flash → HTML5 への移行が最も進んでいるのはゲーム産業
- ゲーム産業への影響
　- 開発者の裾野が広がる (C や Java より学習コストが低い)
　- カジュアルゲーム・ソーシャルゲームの促進
　- (売り切りではなく) サブスクリプションモデルへの移行
　- 顧客データベースの価値上昇 (ユーザー ID など)
　- ユーザーへの露出を最大化した企業が勝つ

- 家電への対応における2つの問題
　- ウェブ上の動画コンテンツ
　　- 放送局はコンテンツをウェブに出さない
　　- YouTube などのネット動画は解像度が低い (但しこれは時間が解決する)
　- リモコンなどの既存 UI と，ウェブのミスマッチ
　　- Siri のような音声操作が登場してくる
　　- CES でも音声操作やフリーカーソル操作の取り込みが見られた

- 自動車への対応
　- HTML5 ブラウザで + LTE の車内システム
　　- HTML5 はネイティブより遅いが，LTE によるスピード向上でバランスが取れる

所感:
HTML5 とはあまり関係ない話が多く，CES の動画の紹介に留まったのが残念．ネットと家電がもっと親密な関係になった時の UI は大きな問題でそこへの検討が命題，という指摘には同意するが．最後にあった，LTE などのインフラ向上により，パフォーマンスがバランスされる，というのは興味深いポイント．


【家電にもブラウザがあるさ】
　by オペラ・ソフトウェア ダニエル・デイビスさん (@ourmaninjapan)

- ウェブが家電を拡張する
　- OperaTV ストア，及びプリンタやキッチンがネットに繋がった事例
　- UI が簡単になる
　- 製品の特徴が活かせる
　→ キラーアプリが必要

- 家電がウェブを拡張する
　- 家の中のいろんな場所でウェブサーフィン
　- PC や携帯なしでもウェブが利用できる生活
　- デバイスや環境の判断は難しい
　→ 環境の判断が楽にならないとダメ

- ウェブと家電のコミュニケーション
　- ウェブなら…
　　- WebSocket・Web Messaging が使える
　　- ハードウェアとの連携もできる
　　- ファインダビリティは低下する
　　- コピーライトの保護が難しくなる
　→ 下の2つを解決する手段の1つは DLNA (但し http との併用が難しい)

所感:
やはりこちらも，HTML5 というよりは，ウェブ (インターネット) と家電，という論点だったように思う (いや，それが今日の主題なんだけど)．ウェブと家電が相互に拡張し合う，というのは興味深いコンセプト．本当にそんな未来にしたい．

ああ，やってやるぜ RT @naotake テレビがネットを変えるぜ。Fri Jan 22 17:01:51 via SeesmicToshiya HASEGAWA
toshiya

【 Web Intents 入門】
　by オープンウェブ・テクノロジー代表・C.A.Mobile フェロー 白石俊平さん (@shumpei)

- Web Intents とは何か
　- Android の「インテント」を web アプリ同士で実現する仕組み
　- 2011年6月に Google がアイデアを公開し，現在は W3C で標準化作業中

- Web Intents をプログラムから利用する
　- <head> に <intent> タグを書くとサービス登録できる
　- 情報を渡す先を選択し，そこから結果を返せる
　→ ここの詳細に興味あれば，白石さん資料 のサンプルコードを参照して下さい

- Web Intents はウェブをどう変えるか
　- Web サービス間の連携がスムーズになる
　　- 「Tweet」ボタンや「いいね!」ボタンが消える
　　- ファイルの処理方法を自由に選べる
　　- Web アプリが「忘れられる」ことが減るのでは?
　　　(少なくとも，そう考える事業者が多くなれば Web Intents は急速に広まる)
　　- その他，認証・課金処理など様々なユースケースが考えられる
　- ローカルとクラウドの境界を超える
　　- コンタクトの情報取得
　　- 画像編集も，ローカル・クラウドのギャラリーから画像取得
　- ホームネットワークでの応用
　　- スマホで遭遇した YouTube コンテンツを TV で視聴・操作
　　- レコーダー内の動画をタブレットで視聴

- ホームネットワークと Web Intents の検討課題
　- UA にデバイス (サービス) をどう登録するか
　- Web アプリ ⇔ デバイス間の通信処理をどう実現するか
　　- デバイスディスカバリ
　　- デバイスとの永続的な通信の確立
　　- デバイスとの通信プロトコルを処理するのは UA なのかアプリなのか

- 仕様書

所感:
確かにウェブサービスの在り方は大きく変わりそう．ただ単体サービス側にはメリットあるけど，SNS みたいなサービスにはどうなんだろう? 家電と組み合わせた時の可能性はいろいろありそう．っていうか白石さんの説明がめちゃくちゃ分かりやすかった．さすがだ．


【 HTML5 で画像編集アプリ!】
　by GENOVA 所属・デジタルハリウッド講師 山崎大助さん (@_AIR_NOTE)

【アクオスのインターネットボタン押してみた】
　by 株式会社コネクティ 若狭正生さん (@wks)

この2つはライトニング・トークだったので，メモは割愛しますね．

---

家電に HTML5 はまだまだ来ない．Canvas があれば Flash の置き換えはできるかもしれないけど，家電のアプリプラットフォームには至らないし，WebGL には懐疑的．スマートフォンやタブレットに目を向けても，あと数年はアプリ至上主義が続く…というのが個人的な見解です．

最近やたら「クラウド・クラウド」言われますが，家電においては，必要なデバイスが httpd を内包していてデバイス間でコミュニケーションを取り合い，必要に応じてクラウドにデータを get/put する (JSONP などで API は透過に見える) とか認証する，みたいなモデルもあると考えています．

昔は GREE のオープンソーステクノロジー勉強会などによく参加しましたが，この手の勉強会は，内容そのものは USTREAM で中継されていることが多いので，むしろその後の懇親会が醍醐味でしょうね．今日は参加しなかったけど．

発表者，及びスタッフの皆さん，素晴らしいセッションをありがとうございました．

「アーキテクチャ中心設計手法」を翻訳しました [arch]

もう1度言います．

やっと，やっとこの本を紹介できる日が来た．
「鉄板」である．自信を持って紹介させて頂こう．

以前このブログで紹介した，"Architecting Software Intensive Systems" を翻訳しました．今週発売になります．
Peace Pipe: 全てのアーキテクトに読んでほしい - Architecting Software Intensive Systems [arch]

本書の内容は上記リンクをご参照頂くとして，自分が携わったことを差し引いても，「ソフトウェア」に関わる全ての同志に自信を持ってお勧めしたい書籍です．

アーキテクチャ中心設計手法 アンソニー・J・ラタンゼ

私が人生において学んだ、3つの原則がある。

1) インスピレーションはビジョン、発見、そして発明の始まりである。
2) 誠実な勤勉さと決意があれば、どんなことでも可能である。
3) 奢ることなく、人生の全てをかけて己を向上させる心構えを持て。

--中略--

日本において関わった仕事をとても誇りに思っている。私の生まれ育った小さな農村から地球の半分も離れた場所で、私が何年もかけて学んだこの3つの原則を同じように尊重するエンジニアたちに、私は出会ったのだ。

--中略--

エンジニアは独特の世界観を共有しており、エンジニアリングについて語る際、これらの違いに関わりなく自然と互いに引き寄せられる。私たちは皆、日常において同じ苦しみと楽しみを経験している。つまり世界中のエンジニアは、特別な血族関係にあると言えないだろうか。

-- Anthony Lattanze (日本の読者に向けたメッセージより)

様々な技術が台頭し、また廃れていく秒進分歩の今日において、本書は魚を与えるのではなく、釣り方を説いている。

--中略--

そして自信を持って、本書を組織のマネージャに勧めて頂きたい。変革の提唱者にだけではなく、その権限を持つマネージャにも、本書は確かな気づきを与えるに違いない。

-- 長谷川 倫也 (訳者あとがきより)

いつか技術系の就職面接で… [memo]

あなたは Twitter で何人からフォローされていますか?
いくつのリストに入れられていますか?

今日何回 Twitter にポストしましたか?

これまでに App Store で何個アプリを買いましたか?

セキュリティと，新しいものを開拓する意志．あなたはどちらが怖いですか?

Flickr には動画もポストできますが，それは最大何秒か知っていますか?

じゃあその90秒が，5分になったとしたら，世の中にはどのような影響がありますか?

あなたのブログは，月間何 page view ですか?

人気や知名度は置いといて，Twitter と Friend Feed はどちらが優れたシステムだと思いますか?

Posterous はあれ程優れたシステムなのに，なぜ流行らないのですか? もしくは Posterous を優れたシステムだと思わないなら，その理由を述べて下さい

Tumblr の面白さを，あなたの言葉で述べて下さい

日本は昔…実は今も鎖国ですが，なぜ今日には出島すらないのですか?

いつか技術系の就職面接でこんな質問が当たり前のように聞かれるような時代が来れば，はっきり言ってめちゃくちゃおもしろいと思う．

クラウドシステムを人体に例えると [memo]

昨日の飲み会で，妙に腑に落ちた話です．

ヒトの体は，幾多の進化を経て創造された芸術品のようなもので，理想のシステムアーキテクチャも人体に例えられるのではないかと．

例えば脳にあたる，システムの肝となるデータベースやエンジンはあるかもしれません．でもそこで全てやろうとしてしまうと，頭でっかちになってしまう．

筋肉のような，鍛えれば鍛えるほど強くなるようなスケールする仕組みが必要です．何を脳に置いて，何を分散させるか．

「マネタイズする仕組みは肝臓かなー」とか色々話しているうちに，

あと必要なのは生殖器だ!

と (笑)．

半ば無理矢理ですが，要はユーザーが増えていくようなサービスを作りましょう，ということでした．

[Web開発者のための] 大規模サービス技術入門 - データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) 伊藤 直也 田中 慎司 技術評論社 2010-07-07

俺様が一番ヘビーユーザーです [memo]

スティーブ・ジョブズの，「なぜアップルは好調なのですか?」と聞かれた時の答えは，「愛」だったそうです．他の会社は単純に製品に対する愛が足りないのだと．

ユーザーは神様と言われます．
顧客視点は，確かに重要でしょう．

でも，「俺様が一番ヘビーユーザーです」と言えるぐらい，自分が作るものを愛し，心の底から自分が欲しいと思えるモノ作りがしたいと思います．

我々開発者は，直接エンドユーザーと会話ができません．
作った製品やサービスを通して，エンドユーザーと会話をするんです．

「あ，こいつ分かってないな」と思われたら，もうおしまいなんです．
分かっていない人が作っているモノは，どうしたってクールじゃないんです．
なにがクールかと言えば，カルチャーが入っていて，ストーリーがあるものです．

自分でやりたいことがはっきりしていなければいけません．
そしてエンドユーザーがあきらめていることを，開発者が気付かなければいけない．

欲望に忠実に作るんです．
自分が作るものは，実体験に基づき，自分が一番分かってなきゃいけないんです．

HtDP - これからプログラミングを学ぼうとする人が読むべき本 [software]

How to Design Programs - An Introduction to Programming & Computing M Felleisen MIT Press 2001-02-12 by G-Tools

これまた The Tech Guy で紹介されていたのですが，Leo が「プログラミングを学ぼうとする人は読むべきだ」と勧めていたのがこの HtDP (How to Design Programs) という本．実は私も読んだことはないのですが，デザインの本質が体系的にまとめられているということで，紹介しておきます．
How to Design Programs


ことプログラミングに関しては「習うより慣れろ」は当てはまらない．一度悪い癖がつくとなかなか抜け出せないし，最初に基本から入っておくと後から断然有利になる．

この HtDP は，Scheme を用いて解説をしている．Scheme というのは Lisp をベースとした言語で，あの弾さんに言わせれば「心の故郷」
404 Blog Not Found:(use gauche); 書評 - プログラミングGauche

で、schemeって何かといえば、うーん、誤解を恐れずに言えば、全てのプログラマーの心の故郷。
--中略--
PerlにしてもPythonにしてもRubyにしてもJavaScriptにしても、あれこれやっているうちにいつかSchemeにたどりつく。

404 Blog Not Found:初心者向け言語もいろいろ

Computer Scienceをきちんと教えている学校の多くは、最初の一年の前半に scheme を教えて、後半に C と assembly language を教えている。

確かに C# や Java や PHP などを知っていれば就職に有利かもしれないが，急がば回れということで，HtDP を片手に DrScheme (フリーの Scheme 開発環境) を弄び，Scheme をじっくり習得してみるのも手かもしれません．

全てのアーキテクトに読んでほしい - Architecting Software Intensive Systems [arch]

やっと，やっとこの本を紹介できる日が来た．
「鉄板」である．自信を持って紹介させて頂こう．

Architecting Software Intensive Systems: A Practitioner's Guide Anthony J. Lattanze

著者の Anthony Lattanze は，CMU (Carnegie Mellon University: コンピューターサイエンスの名門・コンピューターサイエンス部門では2009年全米大学ランキング3位) の教壇に立つ一方で，SEI (Software Engineering Institute: ソフトウェアに関する最も権威ある研究機関の1つ・CMM やプロダクトラインの開発などが有名) のシニアメンバーを務める．ちなみに CMU と SEI は密接な関係にある (SEI は CMU のキャンパス内にあり，CMU によって運営されている) が，両者のスタッフを務めるのは現在彼1人である．

…などと書くと「理論ばかりのアカデミック・アカデミックした頭でっかち」という印象を持つかもしれないが，私に言わせれば Lattanze ほど現場の感覚を合わせ持った研究者はいない．というのも，元々彼は実企業で15年の経験を持つ叩き上げで，現在は世界中で企業のコンサルを行う傍ら，市場の製品を受注し自身で設計・実装している．先日 CMU が優勝した無人車レースではナビゲーションシステムを担当し，Google がスポンサーのロボットを月に飛ばすコンテストでも実装を担当している．現在もバリバリにコードを書く，筋金入りのアーキテクトなのである．

実はこのブログに何度も登場している「某 SEI アーキテクト」とは全て彼のことである．以前書いていた ソフトウェアアーキテクチャのエントリー も，彼から学んだことを，本人の許可を得て掲載したものだ．

私は光栄にも本書の監修の一部を依頼され，ちょうど去年の今頃から半年あまりかけて本書の原稿をレビューした．まだ原本を読んでいないので，どれだけ私の指摘が反映されたかは分からないが，少しでも本書の出版に貢献できたとしたら，これ以上の喜びはない．



内容について紹介すると，本書は大きく3つのセクションに分かれている．

セクション1は，ソフトウェアアーキテクチャについて抑えておきたいコンセプトが網羅されている．イメージとしては，SEI のシリーズでありアーキテクトのバイブルとされる Software Architecture in Practice (実践ソフトウェアアーキテクチャ)

のエッセンスを抜き出し，その内容をさらに進化させたものと言ってよいだろう．SEI のシニアメンバーでありながら，SEI が提唱している一部の理論については「考えが古すぎる」「現実に即していない」と自身のスタンスを貫いてきた彼が，ソフトウェアアーキテクチャの基礎を紐解いている．

セクション2は，本書の真髄とも言える ACDM (Architecture Centric Design Method) の解説だ．ACDM とは Lattanze が1999年から研究をはじめ，本書ではじめてその全貌を明かす渾身の開発プロセスである．ADD は設計にしか特化しておらず，ATAM は評価にしか特化していない．また CMM，RUP，XP，Scrum などは，本質的な部分は「設計しろ」としか言っていない…といった問題がある中で，数々の企業に携わった Lattanze が，その経験の集大成として提唱するソリューションだ．言わば「アーキテクトの活動手順書」であり，読めば目から鱗がポロポロと落ちてくるだろう．

セクション3では，実際の適用方法について言及している．一般的に方法論というものは，いつだって理想的な形で述べられており，時にはあまりに現実離れしている．だが彼はセクション2で ACDM の理想形を示した上で，セクション3で「では実際にどう適用すれば良いか」について，明瞭に答えている．


自信を持って断言するが，今日ソフトウェアアーキテクチャを語る上で，これほど現実的かつ，要所を分かりやすくおさえている書籍は存在しない．また本書で豊富に紹介されているテンプレートは，すぐにでもドキュメンテーションに役立つだろう．


まだ完全に成熟していないソフトウェア工学の世界において，いわゆる「王道」は存在しない．手法もプロセスも山のように転がっているが，どれもそのままでは使いものにならない．

それは当たり前なのだ．一口にソフトウェア開発といっても，その規模や形態は千差万別である．その中でやり方が一意に決められるのであれば，極端に言えば開発は全て自動化できてしまう．

そのままでは使えないという点では，本書も同じかもしれない．だが本書が他と違うのは，明確な視点に基き，とことん現場目線で書かれており，「実際に自分の組織・開発に適用するにはどのようにカスタマイズして取り込めば良いか」が，自ずと導き出されるという点であろう．


プロセスは，それが良いか悪いかではなく，そもそもプロセスが「ある」ということがまず重要である．もしあなたがアーキテクトという立場で，組織としてやり方が確立されており，過去のプロジェクトが全て大成功というなら，ACDM など必要ないだろう．だがもし私と同じように，理想と現実の狭間にもがき，それでも日々の開発を推し進めて製品やサービスをリリースしながら，少しでも良いやり方を模索しているなら，本書は必ず何かしらのヒントを与えてくれるはずである．

GoF が言っていること，Gamma が言っていること，Bushman が言っていること，Shaw や Garlan が言っていること，我々が SEI で言っていること，これらは重複もしているし，相反もしている．

なぜなら，まず第1に粒度がバラバラであるからで，そして第2に視点が明確になっていないからだ．

この2つだけでも，万人を混乱させるのに十分でしょう?

この議論にウンザリしているから，もう自分で本を書こうと思ったんだ．

-- Anthony Lattanze

ソフトウェアエンジニアリングに重要な10のコンセプト [software]

「デスマーチ」を提唱した Edward Yourdon のプレゼン資料より．
Top Ten Software Engineering Concepts, v10 - The Yourdon Report

1つ1つのコンセプトから適切な外部リンクが貼ってあり，とても読み応えがある．

同時に，「詳細については外部リンク参照」ということは，各コンセプトにおいてこの資料中に書かれていることは Yourdon が「特に重要」と考えている点であると読み取れるかもしれない (例えば「インクリメンタル開発」においては「デイリービルドアプローチを使え」など)．

「イテレーション」について「そのオブジェクト指向バージョンがリファクタリングである」とか，「再利用の重要性」について「その Web 2.0 バージョンがマッシュアップである」などといった着眼点も興味深い．

そして最後の「まとめ」スライドの1行目が

Technology is not the key issue

というあたりが，いかにもデスマーチの Yourdon らしいではないか．


ひとまずこのエントリーでは紹介だけ．

1. You can't control what you can't measure
2. Peopleware
3. Incrementalism
4. Iteration
5. Repair costs if defects leak downstream
6. Tradeoffs are non-linear
7. Reuse is important
8. Risk management is key
9. Consistency trumps brilliance + death-march
10. Don't reinvent the wheel

いずれシリーズ的に1つ1つ取り上げてみたいなーと思ってます．

Keep It Simple, Stupid [arch]

今日も SEI のとあるアーキテクトと話す機会があったのだが，非常に興味深いエピソードを聞いたので紹介したいと思う．

内容としては「シンプルにいこう」という話．ソフトウェア工学の技術や手法を体得すればするほど，必要以上に設計やプロセスを複雑にしてしまう傾向がある．例えば「トシヤ」という名前のスペルを示したい時に，私自身が "TOSHIYA" と書けば済むものを，「まず俺が "T" を書くから，"O" を書く役割を他の人に与えて，次の "S" を書くプロセスとしては…」みたいなことをしていないだろうかということだ．

そしてこんなエピソードを話してくれた．

アポロがはじめて月に行った時，「宇宙ではペンが使えない」という問題があった．無重力の世界では，インクが落ちてこない為，ペンで文字が書けないのだ．

そこで NASA は，莫大な時間とコストをかけて，無重力でも使えるペンを開発した．アメリカは，この極端に需要が低い高価なペンに投資をしたわけだ．

ところでそんな時，ロシア人はどうしたと思う?

鉛筆を使ったのさ!

…落ちません? 目から鱗．

要は KISS ということですね．


最後に少し脱線するが，KISS とは "Keep It Simple, Stupid" の略．
KISS principle - Wikipedia
ニュアンスまで含めて意訳すると，「こねくり回してんじゃねーよバーカ，単純にしとけよ」といったところだろうか．"KIS (Keep It Simple)" で良いところを，わざわざ Stupid (バーカ) を足してまで口づけの kiss とかけているところが，いかにもアメリカらしいと思う．ユーモアのセンスがあるんだかないんだか，なんでいつも若干上から目線なのか，という意味で．

ソフトウェアアーキテクチャはプロジェクトを救うか [arch]

金曜の夜に同僚と飲みに行き，「ソフトウェアアーキテクチャ」や「ソフトウェアアーキテクト」の定義を何時間も議論するのもどうかと思うが…

彼の「アーキテクチャ」の定義は制約を形にしたもの．「アーキテクト」の定義は監視役．

私の「アーキテクチャ」の定義は意思決定 (もしくは意思決定ツール)．「アーキテクト」の定義は組織によって変わる (高層ビルの建築家と木造住宅の建築家は別物)．

「意思決定」を補足すると，よく「線引きをする」という表現が使われると思うが，本来引かれるべき線は直線ではなく，ぐにゃぐにゃした線ではないだろうか．直線なら素人が引いても10回に1回は成功するかもしれないが，ぐにゃぐにゃした線は当てずっぽうでは引けない．視野を広く持ち，制約・ビジネスに対する影響・トレードオフなどを鑑みて，妥協するところは絶妙に妥協し，譲らないところは1歩も譲らずに引いた線とその表現がアーキテクチャだと思っている．では，これらのことをまったく考えずに引いた当てずっぽうの直線はなにかと言うと，それもまたアーキテクチャだ．つまり意識する・しないに関わらず，ソフトウェアにはアーキクチャが必ず存在する．

言葉の定義に興味がある方はこのあたりもご参照頂きたい (1つ目のリンクはコメントも含めて)．
Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal: What is Software Architecture
Peace Pipe: ソフトウェアアーキテクチャ その2 - 「ソフトウェアアーキテクチャ」とは [arch]

そもそも曖昧なこれらの言葉を，一般的に定義しようとすることは不毛だろうが，組織やプロジェクトに特化した共通の定義 (解釈) があることは重要だと思う．その意味では，我々の組織においてアーキテクチャがどう作用しているか・するべきかといったこの日の議論も多少は意味があったような気がする．


アーキテクトについて言えば，それは人ではなく役割だ．だから規模の小さいプロジェクトなら1人がプロジェクトリーダーとアーキテクトの2役を担っても良いし，逆に大きいプロジェクトでは，アーキテクトと呼ばれる人が2人以上必要なケースもあるだろう．アーキテクトのグループを複数のプロジェクトに配置する場合もあるかもしれない．

所詮は役割でありそれ以上でも以下でもないので，例えばアーキテクトとプロジェクトマネージャーと一実装担当者において「どちらが偉いか」を決めるものではない．権限は明確になっている必要があるが，どうもその権限や仕事内容が「偉い・偉くない」に結びつきがちなのはなぜだろうか．


同僚は「ソフトウェアアーキテクチャはプロジェクトを救わない」と主張していた．私も結論としては同意見だが，アーキテクチャはプロジェクトマネージメントを促進するので，間接的に救うことはあると思っている．

ところでこの日は チムそば で飲んでいたのだが，「アーキテクチャはプロジェクトを救えないかもしれないけど，チムそばのラーメンは世界を救うんじゃないかと思う」という彼の発言には私も同意．

途中から酔いがまわってあまり覚えていないので，自分の主張については補足ヨロシク > 本人

35 Useful Source Code Editors [memo]

良いエディタを使うことは，基本中の基本．
35 Useful Source Code Editors Reviewed

良いエディタを選択することが最初のステップ．
もし既に自分の手に馴染むエディタを使っているなら，他のエディタを試すのは時間の無駄．

-- Bram Moolenaar (7 Habits For Effective Text Editing 2.0 より)

Matz x Dan x Daiji 「エンジニア進化論」 [seminar]

404 Blog Not Found で，いつも鋭い視点を披露している小飼 弾さんを，いつか生で見てみたいとは思っていたが，その彼が私のアイドル まつもとゆきひろ さんと対談するとなれば，これは行くしかないじゃないか．

「てくらぼ」オープニングイベント スペシャル対談開催

プログラミング言語「Ruby」の開発者まつもとゆきひろ氏、オープンソースプログラマー小飼弾氏、ファシリテーターに平田大治氏をお迎えしてトークセッションを開催します。

テーマは「エンジニア進化論」エンジニアとしてこれからどうあるべきか？を軸に議論していただきます。来場された方にエンジニアが進化して行くためにどの様な事が必要なのかを感じていただければ幸いです。

まつもとさんは，時折鋭い言葉を混ぜながら，いつも通り飄々淡々と話していた．はじめて見る生ダン・コガイは，想像通りユーモアとウィットに富み，そのブルドックケチャップソース並みに濃いキャラ (褒め言葉) を，いかんなく発揮しまくっていた．トークセッション自体も「ファシリテーターからの質問」「事前に Web で募集された質問」「会場からの質問」と分けられ，上手く構成されていたように思う．

この日一番心に残ったのは，「エンジニアが進化していく為にはどのような事が必要と感じますか?」という質問に対する，まつもとさんの回答．

差別化ですね．

エンジニアなんてどこにでもいる．エンジニアでもプログラマでも，他の人が見た時に，100人いたら同じ100人として扱われる．交換可能なら「あなたがダメなら他の人でいい」ということになる．

自分にとっては自分がすごく大切なのに，社会にとっては自分は交換可能という，切ないギャップがあるわけですよ．

僕は学生の頃からひらがなで名前を名乗っている．こんなどこにでもある名前だから，少しでも差別化したかった．

一芸に秀でることです．僕には Ruby という名刺代わりのソフトがある．希少価値を高めて交換可能ではない人間になることです．

社会には「みなさんと同じようにやりなさい」という同調圧力がある．「空気読め」なんて言われるけど，同調圧力なんて聞かなくていい．会社がそれを認めてくれないなら，能力を伸ばして他のところに行けばいい．

今日はこのことだけ言おうと思って来ました．

これに対して弾さんの，

違いにこそ価値があるのに，お金にならないことがある．

違いを誰にでも分かる形で示すことが重要で，「誰にでも分かるけど，俺にしかできない」というのが最強だと思う．

できない時は逃げてもいいけど，その場合は徹底的に逃げること．逃げている人は，大体手段と目的が逆転してしまう (逃げることが目的になってしまう)．そういう人ほど逃げ遅れる．

それと，組織を上手く利用すること．

進化の前に製造しなくていはいけない．正しいことをする前に生き残らなくてはいけない．"Right (正しい)" より "Left (残る)" が大事 (右左の right/left とかけている)．

というのも，なんとも彼らしい．

ちなみに「では生き残る秘訣は?」という返しについて，まつもとさんはインテルのアンディ・グローブの "Only paranoid will survive" という言葉を引き合いに出しながら，「アンテナを高く持つこと」と話していた．


以下，その他興味深かった話の要約．
(Matz = まつもとゆきひろ・Dan = 小飼 弾)

---

今注目している言語は?

(Matz)
Erlang とか．．．
(他にもいくつか挙げていたがメモできなかった)

今後コンピューターに入るコアの数が増えていく．今までは CPU が速くなれば自動的にプログラムが速く動いたが，コアが増えるとソフトウェア側が対応しなくてはいけなくなる．

Erlang が提示しているモデルはその解になる…かもしれない．Ruby にその機能を取り込めるかどうか検討している．隣の芝生が青いので，どれぐらい青いかを見てみようと．

(Dan)
プログラミング言語の枠を超えて言うなら，注目というよりも危機感を感じているのは日本語．10年だとまだだけど，でも20年後だと最新技術は英語じゃないと学べない時代が来るかもしれない．

(Matz)
確かに，例えばマレーシアだとコンピューターの授業も本もみんな英語．自国語でコンピューターを最後まで学べるのは日本とドイツぐらい．日本語がレアだということは自覚しておいた方がいい．

オープンソースは最高か?

(Matz)
最高．

(Dan)
「最高」と言うからには2番目3番目のソフトウェアを定義できることになる．オープンソースで作ったのにオープンじゃないものがいっぱいある．例えば Google とか．もしオープンソースが最高ならば，なぜそうじゃないものが残っているんだろう?

最高の中にも，「飯が喰える」のか「遊べる」のか，いろいろある．一次元の議論ではない．

(Matz)
Ruby は最初からオープンソースにしようと決めていた．金を取っていたら Ruby は存在しなかっただろうし，僕は他の仕事をやっていただろうし，今の収入もなかったと思う．

エンジニアには英語は必須か?

(Matz)
必須ではないが，英語以外だと情報に時間差があること，英語を知っているとアドバンテージがあることは確か．

(Dan)
必須．英語を知っていた方が儲かる．

つまらない，と思いながらプログラミングをすることはあるか?

(Matz)
ない．

(Dan)
頭で考える時は良いが，手を動かしている時はかったるい．

(Matz)
ふーん…
僕は頭の中では書けない．手を動かさないと書けない．

プログラマ35才定年説は本当だと思うか?

(Matz)
人間の能力として35才ぐらいにリミットがあって…という話なら反対．

でも日本の社会の圧力として35才ぐらいでマネージメントの方向に行かされて…という話なら，なんかありそうな気がする．

「プログラミングすりゃーいいじゃん」って思うけど．

(Dan)
逆説的になるが，およそプロというのはプロフェッションにくっついてくる技術だけやっていればいいわけではない．プロである以上，会社とか上司といったインターフェイスを上手くこなすことが必要．

今の若い人，例えば小学生に，エンジニア (プログラマ) という職業を勧められるか?

(Matz)
「まあなればいいんじゃないの?」と思う．世の中には，ほっといてもモノを作る人がいる．そういう人がエンジニアになるべきで，モノ作りに関心がない人にはエンジニアは向かない．

それを決めるのは自分自身．

なぜ日本では技術者志望の減少・理系離れが進んでいると思うか?

(Matz)
動機づけが何なのかという問題．楽な仕事やワリのいい仕事の為に逃げて行っただけだと思う．

(Dan)
理系のセンスが無い人は，何をやってもきつい．理系から文系の転向はありえるが，その逆は見たことがない．これが全てを物語っている．

2人のロールモデルは?

(Dan)
ロールではないが，「これでいいんだ」と背中と押してくれたのは Larry Wall (Perl を作った人)．

(Matz)
弾さんとは違う理由で Lary Wall．Programming Perl という本はジョークに溢れ，読み物としてとてもおもしろい本だった．

(Dan)
確かに彼は，ソフトウェアエンジニアリングに笑いを持ち込んだ人だと思う．

(Matz)
ただ，彼が作った言語はいかがなものかと思う (笑)．言語デザインだけは僕の方がマシにできる．

Rails をどう思っている?

(Matz)
気持ち複雑なところ．

Rails によって Ruby を知ったり使ったりしている人がいることは確か．ただ，Rails を作った人は (若くて Ruby を学んで1年足らずで Rails を作り，Ruby の歴史や背景も知らなかった為) Ruby のしきたりやルールが分かっていない．

「そこまでしますか，フツー」と言いたくなることもある．でも概ね感謝しています．

PHP はカリスマから見てどうなのか?

(Matz)
プログラマとして成功するまえに，コンピューターサイエンスの知識を持っている必要がある．その知識を深めれば深めるほど，PHP に対して不満を言いたくなるかもしれない．

(Dan)
ところで，もともと Rails は PHP でやりきれないことを解決する為に生まれたんだよ．

エンジニアにブログは必須だと思うか?

(Dan)
転職のチャンスになる．はてなとかライブドアみたいな会社だと，ブログを書いていないと人として認められない．

(Matz)
誰でも最初から大きな会場でプレゼンできるわけではない．でも自分のブログだったらアウトプットを公開することができる．

(Dan)
ブログを書く時にはつっこまれることを恐れないこと．叩かれて強くなる．「分からない」と言うことは恥ずかしいことではないし，就職にも絶対に不利にならない．

(Matz)
アウトプットを公開して，そのフィードバックをもらって，それをインプットとしてまたアウトプットを出す…という繰り返しをすることで人は成長する．その為の道具としてはブログは最適だと思う．

"Architecture Governance" という考え方 [arch]

Hitchhiker's Guide より．

Architecture Governance

These cross-cutting issues should be subject to what I call architecture governance.
--中略--
The best way to guarantee proper handling of these concerns is to provide guidelines from day 0.

アーキテクチャには，設計・デザインをはじめとする技術的側面はもちろんありますが，アーキテクチャがシステムを「統治する」という考え方は，なかなか本質を突いていると思いました．

Remember The Milk ハッカー (と猿) とのランチ [diary]

今や私の生活の中になくてはならない，最強のオンラインタスク管理サービス Remember The Milk (以下 RTM)．

実際にこれがあるのとないのでは効率が全然違う．日本語化もされているし携帯からもアクセスできるので，使ったことが無い人はぜひ試してみるべきだと思います．

高い機能性，かゆい所に手が届くユーザビリティや洗練された UI は言うまでもないが，Gmail や Quicksilver をはじめとする多くのアプリとの連携，Google Gears が発表されてからたった5日で対応してオフライン機能を実装してしまったという開発スピード (これ驚愕)，さらにはたった3人で40万のユーザーを抱えるサービスに成長させ，しかもその3人のうち1人は猿のぬいぐるみというユニークさなどから，私はすっかり魅了されています．

彼等は今東京に来ていて，昨日交流会がありました．
Remember The Milk 交流会 in 東京！
Remember The Milk is coming to Tokyo!

残念ながら昨日はどうしても外せない用事があり参加できなかったのですが，ダメ元で「月曜にでも会えない?」と聞くと「いーよ．ランチはどう?」との返事．びーっくり．しかも私の職場がある品川までわざわざ来てくれました．

RTM の Omar Kilani・Emily Boyd・そして Bob T. Monkey (猿のぬいぐるみ) と．


以下，本人達の許可を得て，話した内容の一部を紹介します．


本当にたった2人で開発してるの?

(Omar)
そう，ホントに2人．
でも猿の社員がいることを忘れないで．彼をみくびっちゃいけない (笑)．

ソフトウェア開発において，可用性を保ちつつユーザビリティとパフォーマンスを両立させるのはとても難しいけど，その辺りはどうアプローチしている?

(Omar)
基本的にはシステムから無駄を取り除いて最適化する作業の繰り返し．

コードベースの最適化もあるけど，行き当たりばったりの開発はしていない．アーキテクチャを計画的に考えて，きちんと前もってデザインするようにしている．

(Emily)
「難しい」というのはできない理由にはならないからね．

設計ってどれぐらいしてるの?

(Omar)
もちろん UML を使ったりはしないけど，プロトタイプを作ったりテストコードを書いたりはたくさんしている．

いずれにしても前持って考えておくことは重要だよ．

スケーラビリティの考え方は? あなたにとって「システムがスケーラブルである」とはどういうこと?

(Omar)
これもデザインに組み込まれている必要がある．

(Emily)
ただユーザーが何をリクエストするか，次に何をやるべきかは完全に予想できないので…

(Omar)
そういう時は基本的に書き直すよ．スマートリストを作った時はほとんどのコードを書き直した．捨てるコードが動いているコードでも関係ないよ．俺のコードだ．全部頭の中に入ってる．

UI やユーザーエクスペリエンスについてのポリシーは?

(Emily)
Simplicity!
とにかく速く，簡単に．

ベーシックなことは簡単にできつつも，複雑な使い方をしたいユーザーにはそれができるようにしている．

新しい機能を追加する時はものすごく慎重に考えるんです．「これによって RTM の simplicity が損なわれないかどうか」って．

Remeber The Milk の UI には Fragile Findability の美学 があると思うんだけど，これって狙ってやってるの?

(Emily)
「使えば使うほど好きになる UI」っていうのは意識している．例えどんなに小さい機能でも，それについてとことん考えるようにしている．

(Omar)
全ての人がヘルプドキュメントを読むわけじゃないからね．最初は簡単に使えるけど，使っていくうちにどんどん新しい機能が発見できるようになっているんだよ．

(Emily)
そもそも「タスク管理」なんてそれ自体は楽しい作業じゃないでしょう? だから RTM を使って，それが少しでも楽しくできるようにしたいんです．

フロントエンドとバックエンドで担当を分けてるの? 開発言語とかは?

(Omar)
Emily は UI をデザインして，HTML や CSS を書く．あとヘルプドキュメントやユーザーサポートも Emily の担当．

Javascript 以降が自分 (Omar) で，Emily の UI/UX を AJAX で実現したり，バックエンドは PHP と Python で書いている．

テストはどうしてるの?

(Omar)
機能によるかな．
テストスイートがあるものもあれば，コードを書く前にテストを考える場合も書いた後に考える場合もある．家族やまわりの人に試してもらったりとか．

機能自体のテストはもちろんだけど，それによってユーザビリティやパフォーマンスが損なわれないかは常に意識している．

どうして Google Gears にあそこまで早く対応できた?

(Omar)
あの時は大変だった．でもただやるだけだよ．
技術的におもしろければ，とにかくやりたくなるんだ．

(Emily)
あの時は (Google Gears には関係ない) look & feel の変更も同時にやってしまった．「これもついでにやっちゃおう」みたいなノリで．

RTM はどうやってはじまった? 最初からここまで大きくする自信はあった?

(Omar)
Gmail にインスパイアされたんだ．あれはウェブにおけるアプリの在り方を変えたと思う．

我々は大学で知り合って，いくつかプロジェクトを一緒にやったんだ．それで2人で，とにかく「ベスト」なタスク管理ツールを作ろうということになった．

もちろん最初からここまで大きくなるとは思っていなかったよ．

なぜ RTM はユーザーに受け入れられたんだと思う?

(Emily)
やっぱり RTM が人々の生産性を上げ，生活を効率的にしたからだと思う．

(Omar)
あと，基本的に我々はストップしないんだよ．常に外部からの刺激 (Google Gears や iPhone など) を受けて新しい機能を実装し続けている．そのポリシーが気に入られているのかも．

今ではそれが当たり前に思われていて，「iPhone が発売されて2日もたっているのになぜ何も発表しないんだ?」なんて言われたよ (笑)．

今後の RTM の展望は?

(Omar)
We want RTM to be everywhere!
とにかくどこからでも RTM が使えるようにしたい．他のいろいろなサービスやデバイスに対応して，どこからでもタスク管理ができるようにしたい．

(Emily)
ユーザーの嗜好は様々だし，国によって使われ方も違うから，できるだけ多くの人に対応したいと思っている．

Omar はとてもシャイなかんじで，最初はうつむき加減にあまり目を合わせず話していたのに，技術の話になるとまっすぐ私の目を見てハキハキ話していたのが印象に残っています．2人ともとてもいい人で，なぜかランチまで奢ってもらっちゃいました．私が「いやそりゃいくら何でも…」と引き下がらないでいると，「もう支払いの話はやめよう．楽しかったからいーよ」と．このブログは翻訳サービスにかけて読んでくれると言っていたけど，なんか手伝えることあったら手伝うよ，ホント．

昨日の交流会のレポートもいくつかあがっているようです．
Remember The Milk 交流会に行ってきましたよ！！！
mootoh.log : Remember The Milk 交流会 in 東京 に行ってきた !

こちらはご参考．
無料タスク管理サービス「Remember The Milk」日本語版の使い方 - GIGAZINE
Peace Pipe: Remember The Milk で便利な21の検索 [lifehack]

開発者の信念みたいなものに触れて，ますます RTM に愛着がわいた気がします．

GREE Labs 第11回 オープンソーステクノロジー勉強会 [seminar]

半年以上ぶりの開催となった GREE Labs オープンソーステクノロジー勉強会．

第11回 オープンソーステクノロジー勉強会 - GREE Labs
今回は少し毛色が違うけど，とにかく純粋な技術の話に飢えていました．

いつも通り，資料・podcast・ログなどは GREE Labs のサイトにアップされるはずなので，さらっとレポートします．


【Adobe AIR が拓く Web 2.0 on Desktop の世界】
最初のセッションは，アドビシステムズ (株) ダイナミックメディアエバンジェリストの太田氏による，正式版リリース直前の Adobe AIR (Flash 技術を利用したデスクトップアプリの実行環境) と Flex (RIA の統合開発環境と SDK) の紹介．

AIR は，Web アプリのリッチ化や API の公開・オープンソース化などといった Web の現在を見据えて Adobe が提唱する実行環境で，その最大の特徴は Web 標準の技術だけでクロスプラットフォームのデスクトップアプリが開発できること．これにより，低コストでブラウザに束縛されない自由な表現方法を持つアプリが開発できるだけでなく，ローカルストレージや Drag & Drop などの機能が利用できる．

同じような技術には Yahoo ウィジェットや WPF (.Net フレームワーク)，JWS (Java) などもあるが，Ajax がそのまま稼働するのは AIR だけ．WebKit (Safari のブラウザコア) も組み込まれている．実際に太田氏の PC では，良く見るブログパーツのウィジェットがデスクトップ上で動作していた．太田氏に言わせれば，「そもそも .Net や Java は根本が Web ではないし，AIR は Yahoo ウィジェットをもっと押し進めている」とのこと．

さらに AIR は携帯プラットフォームも視野に入れているらしい．最近ではガジェットをサポートするデジタルテレビも珍しくないが，いずれは家電におけるアプリケーション開発にも影響を及ぼすかもしれない．

ところで Adobe といえば，Adobe Reader や Flash Player などの「クロスプラットフォーム (これ大事)」クライアント提供はもとより，次世代の javascript と言われる ECMA Script Edition 4 や PDF 仕様の AIIM 提出などの標準技術確立サポート，2005年の Macromedia 買収など，目指すソリューションに対して着実な歩みを見せている．オープンソースに対する取り組みについても，自社のツールやライブラリのオープンソース化を計画していたり，Mozilla 財団へ数万行のソースコードを寄贈しているとのこと．太田氏の話からもそのブレない理念が伝わってきた．

それと，太田氏のプレゼンが非常に上手かったことをつけ加えておきましょう．とても饒舌だったし，なにより質問に素早く的確に答えていた．技術の紹介 (売り込み) をする時には，こういう要素ってすごく重要だと思う．

Adobe Labs
Flex User Group
akihiro kamijo (Adobe の Flash 担当の方のブログ)


【着せ替える Flash Lite】
もう1つのセッションは GREE の井口氏から Flash Lite (携帯電話用の Flash サブセット・今の携帯にはほとんど搭載されている) の活用法を，実際の GREE のケータイコンテンツを用いて説明．

携帯電話専用ということで，端末のパフォーマンスやセキュリティの観点などから非常に制約が多い Flash Lite において，開発時に苦労した点やその回避方法などが紹介されました．