HTCの「目標失敗率」は95% - masayang's diary
先日、雑感にて某ゲーム会社の失敗プロジェクト率について取り上げたが、その後「HTCの失敗率はもっとすごい」という話を聞いた。驚くなかれ95%。 調べたら2009年12月のWiredで取り上げられていたようだ。 Wired Gadget Lab: Strapped to Android, HTC Takes a Dizzying Ride to the Top →HTC社のR&D失敗率目標は「95%に設定されているよ」というお話。 失敗する、それも早い段階で失敗しておくことで、より深みにハマってからの失敗を避ける。そのことが、より速い研究開発と製品化につながる。だから95%の目標失敗率。 “It’s no longer a mystery what it takes to create a differentiated handset,” says Greengart. Handset ma
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
Agile2010 Day Three - masayang's diary
本日も我が道を行く。 From Estimate to Contract - Choosing the Right Model for Your Situation Becoming Agile: Designing a Transition Plan from Waterfall to Agile From Estimate to Contract - Choosing the Right Model for Your Situation Chris Shinkle/Jim LaRue両氏による好発表。基礎となっているのは「熊とワルツを」で紹介されているモンテカルロ法を使ったプロジェクト見積もり変動シミュレーション。このシミュレーションを元に、契約をFFP(Firm Fixed Price: 定額)にするのか、T&M(Time and Material: いわゆる人月課金)にするのか、ハ
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
Android 2.2の目玉10点 - masayang's diary
developer.com: Top 10 Android 2.2 Features Developers Can't Wait to Use (1) Flash 10.1とAIRのサポート (2) C2DMによる通知処理 現在は個々のアプリが個々のサービスにポーリングをかけることで、トラフィックおよびバッテリー消費が激しくなっているが、新たにGoogleがサポートするC2DM(Cloud to Device Messaging)フレームワークを活用することにより、この問題点が解決される模様。 (3) 企業利用対応強化 盗難時の機能抑止ないしは内容消去。 (4) 性能改善 JITコンパイル対応やコード最適化で2.1より数倍性能が向上。 (5) 音響再生やストリームメディア再生のAPI改善 (6) SDKの大幅な改善 アプリケーションのインストール先にSD Cardを指定できるようになる。
Agile Japan 2010 - masayang's diary
Twitterの#aj10にて、ざっと流れを追うことができる。 便利な時代になったのぉ。 大手SI屋は、これでも「Agileは自分たちには関係ない」と思い続けるのだろうか... 以下、印象に残った書き込み。 あー言っちゃった…『SOAはナンセンスですね』御意。 #aj10 http://twitter.com/bohnen/statuses/11918830743 児玉:「そこはいいポイント。アジャイルで発注してくれた会社は、大きな会社に発注するつもりがない。大企業は高いと思っている。だからちいさなうちに発注してくれている。」 #aj10 http://twitter.com/kawaguti/statuses/11917905609 Agile化の流れを見ていると、小型で燃費のいい車を作れずに衰退していったアメリカ自動車産業を思い出すんだよね。事業構造も自らの体質も変えることができず、徐
若者よ！ 外国語を学んで備えよう！ - masayang's diary
題名は釣りです。 でもね、もし民主党と愉快な仲間達が本気で円安と財政破綻まっしぐらな政策を実施して$1=360円時代再来、なんてことになってしまったらどうなると思います？ 「円安を活かして豊かなモノづくり日本の復活だ！」なんて、おっさん達が読む夕刊紙に書かれているような陳腐なハッピーエンドにはならんわけですよ。 輸入に頼っているエネルギーや原材料価格は上昇しちゃうでしょう。生活に必要な物資・サービスの価格が上昇して暮らしにくくなります。 一方、派遣労働の禁止だのなんだのと労働者を保護する政策ばかり強化したら、企業側は採用を減らすか、もっと規制の緩い他国に生産拠点を移すでしょう。下手したら研究開発機能や、もしかしたら本社ごと海外に行ってしまうかもしれない。 結果、国内に残るのは職を失った人達。そこに物価高が襲ってくるわけです。どうするか？ 手段は二つ。 手段１...海外に行って稼ぐ。 いわゆ
Agile失敗パターン三部作 - masayang's diary
Allan Kelly氏の「Agile失敗三部作」を適当に日本語訳してみた。 Agileで失敗する時 続・Agileでうまくいかないとき まだあった・Agileでうまくいかないとき 読めばわかってもらえると思うけど、「Agileだからうまくいかない」というわけではない。 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 二番目と三番目は、それぞれAgile計画管理、そしてAgile開発手法に特化した話だが、ぎゅっと圧縮すれば「経験がなければ問題が起きている事
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
力技 - masayang's diary
問題 2520は、1から10までの全整数で割り切れる最小の数です。 1から20までで余り無しで割れる数のうち、最小のものを求めなさい。 で、出てきたコードがこれだってさ... for ($i=1;$i<=99999999999;$i++) { $num = 20*$i; if ($num%19 == 0) { if ($num%18 == 0) { if ($num%17 == 0) { if ($num%16 == 0) { if ($num%15 == 0) { if ($num%14 == 0) { if ($num%13 == 0) { if ($num%12 == 0) { if ($num%11 == 0) { if ($num%9 == 0) { if ($num%8 == 0) { if ($num%7 == 0) { if ($num%6 == 0) { if ($num
安物買いの銭失い...開発をアウトソースしてはいけないという事例 - masayang's diary
機内で読んだWall Street Journal（紙媒体版）2007年12月7日金曜日A1面の記事より Boeing Scrambles to Repair Problems With New Plane 要旨 次期旅客機787Dreamlinerの開発が遅れている 最大の理由は自社開発ではなく、アウトソース活用を試みたこと 機体の設計開発をアウトソースしたのはボーイング91年の歴史で初の試み アウトソースした理由 機体素材に炭素繊維を使う787は基礎研究だけで大きな投資が必要だった 開発投資額は100億ドル(1兆1000億円)に達する 開発投資を抑えるため、部品供給メーカ達に設計開発を委託（アウトソース） 発生した問題 多国にまたがるアウトソース 言語の壁 米国では想定していなかった各種規制 孫請けに仕事を分散させることによるオーバーヘッド 同じ企業なら会って話せば済むのに、大量の文書
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
