Hatena::ブログ(Diary)

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

2014-04-20

Google Glassを眼鏡として使ってみたよ

| 02:48

Google GlassGoogleの開発しているメガネ型のウェアラブルデバイスです。米国時間4月17日、新しいアップデート適用されており、現在、Google GlassのバージョンはXE16(XEはExplorer Edition、開発者むけバージョン)です。

バージョンXE16からは(非公式ながら)日本語による音声操作にも対応が始まりました。電脳コイルが(限定的ながらも)すぐそばに、という感じで面白いデバイスです。

といいつつも、自分自身が近視なので、この手の眼鏡型デバイスを活用することもないだろうと思ったのですが、ひょんなところから使用する機会に恵まれたので改造ついでに感想メモ。

※日本国内ではエアプレーンモードで運用。

Glassに眼鏡を付けてみた

というわけでGlassを眼鏡として利用すべく、レンズをつけてみました。ややこしいなぁ。つまり、こうなります。

f:id:hdk_embedded:20140223154639j:image:w200f:id:hdk_embedded:20140223154650j:image:w200f:id:hdk_embedded:20140223154659j:image:w200

レンズ部分の制作は表参道にあるメガネフレームのセレクトショップ「KAMURO 青山店」さん。普段はサングラスやインポートのフレームを取り扱ってるお店です。

今回は無理なお願いにも関わらず試行錯誤の上、メガネアタッチメントをオーダーメイドで作ってもらいました。よく見ると分かりますが映像投影部に干渉しないように左右のレンズのサイズが異なっていたり、爪で固定していたり、と特殊な構造になっています。気になる方は問い合わせてみてくださいね。

この状態で生活してみた結果

今回の眼鏡化でGoogle Glassは自分にとってただの眼鏡です。強度の近眼なので掛けないと何も見えません。もうつけるしか選択肢はないところまで追い込みました(自分を)。

f:id:hdk_embedded:20140421014703j:image:w480

せっかくなので数日つけっぱなしで生活したのですが、結論としてはGoogle Glassは単純に便利な時計でした。

物珍しいフェーズ(つまり無駄に機能を使う)を通り過ぎれば開発機にしては電池の持ちも良いんじゃないの?というぐらいですね。

電脳コイルのような電子戦が繰り広げられるわけでもなく「ぼくサッチー」としゃべる巨大な構造物に追いかけられることもなく。近い印象のものを探すとしたら、昔の人にとっての懐中時計、腕時計の感覚、なのかなぁ。

壁掛け時計やチャイムがあれば腕時計を持つ必要なんかないのだけど腕に付けただけでチラッと確認できる利便性。そんな感じです。

新しいインターフェイスなりの未来と課題がある

たとえば上をチラッと見上げたらディスプレイがオンになり、時計がでる。そのまま"OK, Glass. Take a picture"で(恥ずかしければウィンクでも)写真を撮れます。

日本だとここまでですが写真や動画、ボイスコマンドによる音声認識機能はコミュニケーションのために用意されており、簡単にShare, replayできるように設計されています。

スマートフォンを通じて行う作業をより簡単にできる(そして単純化されている)。Google Nowのように天気や移動先の路線情報を表示したり、SNSの投稿、通話があれば音声で返信できます(XE16からはビデオハングアウトの機能は削られました。あんまり使われなかった、とのこと。まだまだ完成したデバイスではなく試行錯誤してる感じがすごい)。

ただし、このあたりの操作が自然かといわれたら全然そうではない。違和感がある操作が多いです。独り言のようなボイスコマンドやウィンクは慣れない操作でした。

フィーチャーフォン全盛のときにスマホを持ってるような見た目に対する違和感よりも、今回のような行動の違和感は、もうちょっと深い感じがします。

ただ外国ではハンズフリー通話が浸透してるので、そういう人たちからしたら日本人が感じるほどでもないのかな。

最後に。Glassを付けてどうしても困ったのがトイレ(公共)です。どう考えても抵抗感がマッハでした。ここだけは普通の眼鏡と掛け替えたことを付け加えておきます。

このあたりは(事前に目を通した)Google Glassの注意事項としてもいくつか挙げられていますが

基本的には、他人に敬意を払うこと、これに尽きるかと。

かけたまま生活していると、(Glassについて知らない人が多いので)不思議な目で見られますが、質問に答えてどういうデバイスか伝え、軽く試してもらうと周りの人は面白がってくれました。

さらにプレイバシーの問題が大きい場所では入るまえに外すべきでしょうね。携帯電話の利用が適さない場所、カメラの利用が適さない場所は、同様にGlassも適さないです。

試していて、いくつかの未来と課題がみえましたが触ってて面白いデバイスなのは間違いなく、開発者(Googleのいうところのexplorer)にとっては良いデバイスです。

ウェアラブルの世界でもAndroidがベースなところがAndroidが十分に浸透したのだなぁ、という別のところでも感慨深いわけですが。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140420

2014-03-24

ABC2014s Effective Android開発トラックまとめ

| 08:42

Effective Android開発トラックの発表資料まとめです。

f:id:hdk_embedded:20140321133617j:image:w360

5つのセッションすべてでほぼ満員。立ち見がでるほど盛況でした。

EclipseAndroidアプリケーション開発が許されるのは小学生までだよね / @sys1yagi

タイトルは釣りですが内容は濃いです。

Android Studio First Step Guide / @mhidaka

Android Studioレイアウト、パネルなど最初の一歩を解説。Eclipseから乗り換えよう!(埋め込みになぜか失敗するのでリンク先から見ていただけると…)

できる!ART! / @checkela

でむやんが贈るAndroidのART話。これであなたもARTマスター!

ヒトが教える!LLVM / @sui_moti

きつねさんでもわかるLLVMコンパイラを自作するためのガイドブック〜の著者でもある柏木餅子さんのLLVMトーク(そして本人は名前から女性と間違われていた!おとこです!)

f:id:hdk_embedded:20140321164623j:image:w300

Fireside Chat

著者35人のうち20人があつまりました!本を作るときの裏話やおすすめの章、新技術についてなど。

f:id:hdk_embedded:20140321141326j:image:w360

「いえーい、ピースピース!」

当日のサプライズとして達人出版会さまで発行している電子書籍アップデートを発表。

電子版「Effective Android」も、インプレスジャパンの紙版の内容を取り込んだ最新版にアップデートされました!

Effective Android
TechBooster
達人出版会
発行日: 2013-08-29
対応フォーマット: PDF, EPUB

TechBooster ブース

当日はコミュニティブースも出展してました。@yanzm, @vvakameが座ってるときも。インプレスさんのサイン会ではやんざむ本が痛恨の売り切れでEffective Androidを代わりに購入いただくなど波乱も…!

f:id:hdk_embedded:20140321093043j:image:w300

当日販売していた、わかめねこストラップ。@vvakameのアイコンが本人によってグッズ化したわけですが、なにも知らない層からは良く分からないけどかわいいストラップ、と認識されていたようです。


そのほか講演者資料があがれば、随時追加します。お疲れ様でした!

2014-03-20

ABC2014sに参加します

| 03:42

3月21日(金) Android Bazaar and Conference 2014 Springに参加します。

会場は秋葉原UDXです。

今回はEffective Android執筆のご縁から、EAトラック(全5セッション)があります。

http://www.android-group.jp/conference/abc2014s/conference/effective/

UI、総勢20名のFiresideChat、Android StudioLLVM、ART、アクセシビリティ、OpenGLESと盛りだくさんの内容です。是非お越しください。

mhidakaもAndroid Studioについて話します。

Effective Android
TechBooster
達人出版会
発行日: 2013-08-29
対応フォーマット: PDF, EPUB

また、サークルTechBoosterとして「か8 TechBooster」ブースを出展いたします。

こちらでは2種、物販の取り扱い、また配布物としてチラシがございます。

ひとつはAndroid UIステンシルシート。3つ折りするとAndroid(Nexus 5)相当のサイズになる紙のUIキットです。厚紙を使用していますが画面サイズと同じ幅で型を抜いているためプロトタイプを作るときに役立つ便利アイテムです。

1つ200円、5セット1000円で販売予定です。ABC土産にどうぞ(完全に営業です)。

f:id:hdk_embedded:20140320032909j:image:w600

もう片方はみんなのアイドル、vvakameねこストラップ。限定100個。定価は1000円です。イベント終了1時間前より800円です。ねこなのにチキンレースですね。どうしても欲しい人は早めにブースをお尋ねください。@vvakameさん持ち出し企画です。全部売れたらバリエーションが増える(かも?)!

f:id:hdk_embedded:20140320032908j:image:w450

あと、いくつか発表があります。Twitter等で随時公開しますが、ABCのEffective Androidトラックにご注目ください。

単純に声をかけていただけるだけでもうれしいです。当日、ブースにてお待ちしています。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140320

2014-02-12

AndroidのExternal Storageの開発者向けまとめ

| 20:59

Cookpadさんのpotatotips (iOS/Android開発Tips共有会) 第4回に行ってきました。

https://github.com/potatotips/potatotips/wiki/potatotips-4

f:id:hdk_embedded:20140212205530p:image:w480

External Storageは拡張ストレージと理解するとよいと思います。内部ストレージの場合もあれば、外部ストレージの場合もありますがSDカードは利用しない方向で収束しつつあります。主にセキュリティの問題ですね(ファイルシステムFAT32なのが痛い)。

ちなみにExternal Storageにはプライマリとセカンダリ(2個目以降)が設定できます(Android OSビルド時。メーカー側の設定ですね)。

KitKat以降もSDカードを使いたい場合、セカンダリとしてマウントしていくことになりますが、適切な権限を付与しにくいのでメーカー側が用意するファイラ以外から利用できない、と考えたほうが良さそうです。

(今回は拡張ストレージの使い方については省略してます)

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140212

2014-01-29

なぜ見積もりはバラバラになるのか?「モバイル見積もり勉強会」 #モバイル見積 を通じて分かったこと

05:07

2014/1/24(金)19:00-21:30 に スマホアプリを新規作成したらいくらかかる?モバイル見積もり勉強会 #モバイル見積 を@youten_redoと共催しました。

勉強会の目的と資料等

開始前の、勉強会の目的は「見積もりのノウハウ共有とかそんなのが1割とあとは興味本位が9割」という具合でした。

今回、勉強会を通じて色々な発見があったので、見積もりという単語のあいまいさと考え方についてエンジニア視点でメモしておきます。

割と書きたいことだけ書いていること、ケーススタディの一つなので汎用性の高い話ではなく特定分野のお話ということ、を念頭に置いてください。

共催者、参加者の感想は

に詳しいので詳細は割愛します。

資料はこのあたりです。興味があれば見てください。


こちらの画像は画面遷移仕様

f:id:hdk_embedded:20140129022616p:image:w360

画面遷移の数は少なく、わかりやすいですが、地図表示にGPSが必要、NFC,iBeaconを使いたい(試作要素)、サーバー連携などがポイントとなってくるAndroid/iOS対応モバイルアプリです。

アプリ自体の解説と各チームの見積もりについては

共催者のページ(http://greety.sakura.ne.jp/redo/2014/01/post-41.html)に詳しくあるので割愛します。


このエントリではアプリの内容については触れていませんので、前述のエントリを読んでなくても以下は読める…と思います。


この記事の諸注意

今回の勉強会の要件項目と数字だけをみて自社に適用しようとすると必ず失敗するので、そのあたりご理解の上、読み進めてもらえると助かります。

わかっていればいいんですが「相見積もりの中央値とっときゃなんとかなるのでは…」、「なるほど、これぐらいのアプリだと中央値が業界標準なのかな…」とか考えてる人がいたら(これらの見積もりがすべて外れている可能性を考慮してないので、自分で確認しないと何かあったとき)爆死するよ、僕知らないからね。というぐらいのニュアンスです。

なぜこうも見積もりはバラバラになるのか?

この勉強会では見積もり差が最大で10倍程度ついてしまいました。

答えはわりと簡単で、見積もりに関連する要素が多いから&見積もりという言葉が差す範囲がみんなバラバラ(=顧客、開発者間で一致しない。主催者でさえも)だからです。わかりやすい要素を選んで図示してみました。

f:id:hdk_embedded:20140129022617p:image:w480

図は、エンジニアが普段慣れ親しんでるプロジェクト工程の例です。今回、仮想案件見積もりを実施しましたが要件定義を読んで「これはまだまだ変更される恐れがあるな」と考えるか「要件に対して工数が最小化する仕様でつくろう」と考えるかで全く違ってきます。受け入れテストでどこまでサポートが必要なのか、要件定義書自体を作ってくれるのか、受注したら自分たちでメンテして運用する必要があるのか…(仮想案件では対象外とした)。色々なケースが想像できます。ここでは工程が抜ける程度なので影響は限定的です(それでも認識違いがあるとツラいレベル)。


当然、工程だけじゃなくて、プロジェクトをどうとらえるか、の考え方にも影響されるので、このあたりも見積もりをむずかしくします。

f:id:hdk_embedded:20140129022618p:image:w400

定例会議があれば交通費が余分に必要になりますし、作業に使うはずだった工数も吸われます。仕様の詳細化のタイミングで仕様変更があるかも知れません。その手戻り、仕様未決定の部分はリスクとして管理されるべきでしょう。未決定の部分を詰めるためにはモックによるプロトタイピングが必要かもしれません(これらは見積もり時には検討していない作業かもしれませんね)。


お客様と仕様を交渉したり、テスト対象を決めたりする作業が多いのであれば、エンジニアだと効率が悪いという話になるでしょう。そうなればディレクターなりプロジェクトマネージャなりをアサインして、より本格的なマネジメントが必要です。当たり前ですが大規模になればなるほど作業は細分化され、個人で把握している範囲は狭くなります。


また必要なら間接部門や営業費、利益を加えなくてはいけません。今回は簡単化のため間接費やら全部含めて40,000円/人日としました。このあたりはどう考えても会社ごとに事情が違うはずです。

なので数字だけ見て議論しても誰も幸せにならないです。

(あとコンペという形式をとるならそれにかかる費用などを間接的に回収する必要がありますし、受注するために追加の仕様を提案して盛り込むとか、普通の作業見積より+αの手の込んだことが必要です…)。


何度かの交渉の中で、このような意識の差をすり合わせる、というのが現実的な打ち合わせです。勉強会ではこのあたりまでできなかったので結果としてリスクの取り方、仕様の考え方がチームごとに異なり、差が広がった感じです。


この結果を見ると勉強会でやるとうれしいことは、このあたりの数字の詳細化ではなくて、エンジニアによる要件を落とし込む際の考え方やノウハウの共有、ディスカッションと考えられます。

多分、勉強会の運営側で厳密に仕様を固めて変動要素をなくしていくと、見積もり精度は上がるはずです。しかし自明な作業を機械的にやる感覚に近くなり、勉強会で試す意味が薄くなりそうです。


今回は、当初の目的であるノウハウ共有については、参加者の間で、ディスカッションできたみたいで良かったです(ほんとうなら自分が参加者になりたかったんだけど)。

実際の結果は見積書の金額より作業項目と工数など規模感をみてもらったほうがより当日の視点に近い感覚で読めると思います。


見積もりの基準値はないのか?

見積もりのための技術を一般化して基準値を求めよう、という考え方もあると思います。今回の勉強会では、仮想案件に対して複数のチームが見積もるという形を取りましたが、実際に適用するにはいくつか不備があります。

大きく前提条件が異なるので、このあたりは残念ながら参考になりません。


エンジニアの共通認識として、最初から仕様が固まっていれば(納期とか実現可能性とか気になるものの、このあたりがクリアされていれば)、たいていの場合大丈夫という感覚があります。

本当にだめなのはいつまでたっても仕様が決まらないことと、繰り返される仕様変更です。あなたは、『デスマであることを理解しながらも、なすすべなくデスマに突っ込んでいくエンジニア』を何人も見てきたはずです。

リスクマネジメントの重要性

しかし、最初から仕様が固まっていることはほとんどない、というのもご存じのとおりです。

正しいプロジェクトでは、これらはリスクとして管理され、期間を区切り、リスクを最小化します(どうしようもないリスクは放置することもままある)。


場合によっては受託契約を要件定義、製造、など工程や期間で切ってしまうのもいいでしょう。全く読めないなら派遣契約のほうが良いかもしれません。

与えられた権限次第ですが、契約の種別、期間なども選択肢でしょう。ただこのあたりになるとエンジニアじゃなくてマネージャ職っぽいですね。

見積もりでリスクをどう考えるか、で見積もり結果は大きく異なってくるでしょう(見切れた作業では差は表れにくいです)。


とある業界の常として、重複した期間で0.5人月ずつアサインされた人は、必ず1人月以上の仕事をさせられる法則がある(と筆者は信じている)ので、

アサインする人の数で、見積もりの基準として、考えるのがいいかもしれません。

また、さっきから都合上、人月ベースで話してますが本来の見積もりは、機能単位での金額しか出てこないはずです。

どうしても見積もりの基準値が欲しい場合は、プロジェクトの業界統計IPAがまとめている)や社内の統計情報を参考にするとよいです。

プロジェクトごとメトリクス計測していれば工程ごとの作業工数、不具合検出率などから予測値が得られます。計測した項目から重要そうなパラメータを利用して見積もると割と納得度が高いです(※過去の統計が必ず通用するわけではないので精度が上がるか?については難しいところです。一般的に差分開発であれば精度は高くなります)。

このあたりはプロジェクト管理、メトリクス計測ですね。

相手との関係性で成り立つ「見積もり」

結局のところ、見積もりは双方の関係性(予算、人件費、また双方の持つ技術力など)から出すものなので個別の議論はあまり意味がない、という身もふたもないところに着地します

(特に付き合いのある会社間では、これぐらいのクオリティになるだろうな等、ある種の信頼関係もあるはずです)。支払った金額に対して納得できる価値を提供できるか、という本質的な関係性が残ります(双方が納得して評価するために見積もりが必要、とも言えます)。

最後に

今回「見積もり」というセンシティブなタイトルを付けた勉強会でしたが(見積もりの重要性を十分認識したうえで)、エンジニアが要件を分解してみて、

  • スマホアプリ特有の注意点の洗い出しであったり(9patchどうしよう、とかデザインパーツどう受領するの、とか)
  • 最新の評価方法であったり(何機種で評価するのが適切なのか、どのような評価が行えるか)
  • 効率的な作業のブレイクダウン手法(作業を分割する際にわかりやすい方法はどれだ?)

が学べる、またはディスカッションできる、これらの情報交換が目的としたほうが得るものが多いんだろうな、というまとめでした。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140129