モバイルアプリ向けプラットフォーム、MEAP(Mobile Enterprise Application Platform)とは何なのか。
MEAPという言葉をご存知でしょうか？
最近、日経コンピューターなんかにもちらっと出始めていますが、
Mobile Enterprise Application Platformの略で、そのまま訳すと、
企業で使用するモバイルアプリ向けのプラットフォームです。
調査会社のガートナーが2008年のレポートの中で使い始めた言葉で、
ガートナーは以下の条件に当てはまる企業はMEAPを検討する価値があると言っています。
・３つ以上のモバイルアプリをサポートしている
・３つのモバイル用OSをサポートしている
・少なくとも３つのバックエンドのデータソース（既存システムとか）と連携が必要
MEAPとはアーキテクチャであり、考え方です。
別に、技術標準があったり、この機能を持ってないとMEAP製品とは言えないというのはありません。
とはいえ、一般的にMEAPをうたっている製品が良くサポートしている機能はあります。
次の図は以前社内の技術報告会で使った資料ですが、青い部分が良くMEAPを実装した
製品で提供されている機能です。
ここでは大きく４つの機能群に分類してみます。
１．サーバー側でどんなモバイルアプリでも必要になりそうな共通機能を
提供することで開発コストを下げるための仕組み。
認証、データのキャッシュや同期のようなアプリから使用される機能を提供する。
２．バックエンドのシステムに接続しに行くためのコネクター
例えば、DBへのアクセスや、Webサービス、FTPなどにノンコーディングで接続できる、など。
３．複数OSでの開発を用意にするようなクライアント側のSDK
サーバ側のAPIをクライアントから使いやすいように
SDKを提供していることが多いようです。
４．アプリや、ユーザなどを管理するための管理機能
次回、MEAPのニーズについて書きます。
オフショア開発を選んだ理由ー世界中のエンジニアとチームを組む
今、NCDCのいくつかのプロジェクトでは、ベトナムで開発を進めています。
何故かというと、もちろんコスト面もあるのですが、近いうちに実現させたいなぁと思っていることがあるのです。それは世界中の優秀なフリーランスの開発者でチームを作って製品を開発することです。
日本だけではなく、グローバルで開発者を募ることで、ベンチャーでは普通雇えないようなデベロッパーを集められるんじゃないかと思っています。
どこかの企業に発注すると、エース級と、普通のプログラマーが混在したチームになります。これはしょうが無いですよね。自分もSIerに居たから良く分かります。
会社という仕組みの中では、ある程度の規模で人を集めるとなると、エースばかりを雇うことは難しい。そうすると複数のプロジェクトにエース達を分散させないと、プロジェクトの数がさばけない。
今の時点で、オフショアのラボ型契約で単価は安いし、メンバーは1人1人面談しているので皆、結構優秀です。
ただし、あるボスの下に所属している人から選抜するから、どうしてもエースばっかりは出してくれない。例えば、隣の部門から優秀な人を引き抜いてくれたりはしないわけです。
ですので、これから目指しているのは、自社メンバー主体で個人のデベロッパーを雇う。
個人のデベロッパーはグローバルから募集する、の２点です。
たくさんの問題が予想されます。
例えば、
・国民性や、言語の違いによる認識がずれてた
・リモートで作業することによる意思疎通のオーバーヘッドや、どう作業を管理し、評価するのか
・モチベーションをどう上げてもらえるか
今年はリモートで海外のエンジニアと仕事をすることに慣れて、自分達のスキルを上げないと行けないし、インフラを整えるための準備期間だと位置づけています。
こちらもどうぞ。
ベトナム・オフショア開発（準備編） キックオフに行ってきました
ベトナム・オフショア開発（準備編） キックオフに行ってきました
この週末は海の日で、三連休でしたね。
日本は休みだけど、日本以外は平日ということで、月曜日にベトナムのIT企業に訪問してきました。ベトナムまで行って、打ち合わせをした理由は、自社で新しく立ち上げたプロジェクトのキックオフのためです。
日曜日に移動して、月曜日の朝から夕方まで打ち合わせて、月曜日の深夜に日本に帰国するという日程でした。書いているだけで、思い出して疲れてきます・・・。
フォーはしっかり食べてきました。
事前準備
設計から一緒にやってもらえる会社を探していたので、少し前から、何社かに事前に担当してもらえる候補のエンジニアの方とインタビューをさせてもらっていました。
インタビューの観点としては、開発だけを依頼するのではないため、
・アーキテクトのロールができる人をアサインしてもらえるか、
・リモートでの開発でもコミュニケーションが取れそうか、
という２点です。
やっぱり経験のあるエンジニアは、こういう場合どうなるの？と良いポイントを質問してくるし、やったことないポイントでもこんな風にやったら行けるんじゃないの？という案が、筋のいい方式ですよね。
契約のタイプ
請負型と、ラボ型と良く呼ばれる２つのタイプがどこの会社もありました。
ラボ型契約では、何人かのエンジニアでチームを組む契約をして特に成果物を定義しません。今回は自社の製品を常に開発し続ける目的なのでラボ型を選択しました。ラボ型では生産性が、発注側のコストに大きく影響するので、特にエンジニアとのインタビューは重視すべきです。要件をどれだけでも追加、変更できますが、ちゃんとものができあがるかの責任はこちら（発注側）にあります。
こちらがお客さんから請負契約で受けている案件は、仕様もスケジュールも費用もだいたい決まっているので、同じオフショア開発でも請負型の契約をしています。請負契約の場合、生産性はある意味、受けた側の中の話です。
今回のキックオフでは、事前に話もしてあったので、特にアーキテクトをやってもらうAnh Leは議論にも積極的で、いいチームができました！これからプロジェクトをやっていくのが楽しみです。
RT @Roy_S_Kim 終わった！！と言いたいけど、まだ一件会議と食事がある。その後に深夜便で帰国。写真は会議の様子。向こうも積極的に議論してくれて良かった。 pic.twitter.com/25jVLG105I
— ryohei sogo (@rsogo) 2013, 7月 16他にもベトナムの先進的な別のIT企業にも話を聞いてきたので、また書きます。
日本Androidの会の2013年6月定例会に行ってきた
日本Androidの回に行ってきました。
https://www.android-group.jp/event/event19.html
内容は下記でした。
1.HTML5最新動向: オフラインで動くPackaged Web Appのクラウド利用
2.Android最新動向: Google GlassのUI/UXとGlass Wareの作り方
3.Android最新動向: Google IO報告 & Android Studio
会場はデジタルハリウッドさん。
1.HTML5最新動向: オフラインで動くPackaged Web Appのクラウド利用
Androidの会に参加してます。丸山先生のPackaged Web Appの話から。Offline enabed by default、Cloud enabed by default。
— ryohei sogo (@rsogo) June 25, 2013Packaged Web AppはHTML5で作るんだけど、オフラインでも動くっていうのが当たり前。
一方で、クラウドと連携するのが当たり前。
Packaged Web App。標準化、互換性がなー
— ryohei sogo (@rsogo) 2013, 6月 25先生の資料でもchromeのパッケージなんかを使っている部分もあって、やっぱり作る側からすると多くのユーザに使ってもらいたいという思いがあるから、どのブラウザでも動いて欲しい。一方で先進的な機能は一部のブラウザでしか動かなかったりというジレンマがある。
まあ、Chromeだったらスマフォでも、PCでも動くというのは、それはそれでありかも知れない。
Packaged Web App。クラウドとの連携。ローカルに書いて、Syncする、か。
１．自分で作る時は、容量制限は考えないとな。
２．ファイルのステータス。（synced/local/conflict）。リモートからローカルか、リモートからローカルかの方向も管理。
ふーん。
— ryohei sogo (@rsogo) June 25, 2013この辺のサーバとのデータの同期周りは自分で開発しているので、それが仕組みとして提供されたら便利。
3.Android最新動向: Google IO報告 & Android Studio
GCM新機能。
１．多数のメッセージを多数のデバイスに迅速に配信できる。
２．アプリからGCM経由でサービス側にメッセージ送信
３．通知領域の同期。複数台で通知を見ているとき、一方で通知を見ると、もう一方でも通知を見たことになる。
— ryohei sogo (@rsogo) June 25, 2013Google I/O 2013のフィードバックと、Android Studio。これからAndroid Studioの話。
— ryohei sogo (@rsogo) 2013, 6月 25海外のエンジニアはIntelliJ好きだね。
Android Studioはまだまだバグもあるし、実プロジェクトならEclipseだろう、というお話。チーム人数多くて、開発環境を標準化するならEclipseだろうね。
逆に数人でやるなら、Android Studioを試してみるのもありかも。
Androidでおしゃれなデザインをするために参考になるサイト
僕はアプリのデザインを考えるとき、Pinterestで集めている好きなデザインを眺めて、こんな感じかな？というので始めます。
それ以外で、最近参考になったサイトをいくつか。
Designing For A Maturing Android
http://mobile.smashingmagazine.com/2013/05/08/brave-new-world-designing-for-a-maturing-android/#comment-648794
Androidで成熟したデザインをするためのポイントが解説されてる。
Android niceties
http://androidniceties.tumblr.com/
Androidのかっこいいアプリのスクリーンショットを集めたサイト。
20 Great Examples of the Flat Trend in Web Design
http://line25.com/articles/20-great-examples-of-the-flat-trend-in-web-design
Googleと言えばFlat Design、Flat DesignといえばGoogleかWindows8ということで、Flat Designのサンプルが集められているサイト。
最近Google カレンダーアプリの時間設定も変わりましたね。
教育とゲーム。宿題をやらせるためにゲームを設計してみた。
子供は宿題やらないし、なわとびを練習しろっていってもやらない。
言うこと聞かないし。
なので、今、ある取り組みを実験しています。
やる気がでるように、こちらがやって欲しいと考えていることをベースにゲームを設計しています。
Scott Rogersが書いた「レベルアップのゲームデザイン」という書籍にはゲームの定義が書いてあります。（ゲーミフィケーションに関して書いてあると期待して読んだら、本当にゲームのデザインについての本だった。。。）
一人で遊ぶハンドボールは、ただの暇つぶしかもしれません。でも、そこにルールと 目標を加えると、暇つぶしからケームに変わります。ルールは、例えば「ボールを投げるのは右手で、キャッチするのは左手」とか「ボールを落とさずにキャッチし続ける」と いったものです。目標達成となる条件は、「ボールを10回連続でキャッチしなければならない」でどうでしょう。失敗とみなす条件は、「ルール違反、または勝利条件未達成」 とします。これでもうケームを作ったことになりますね。
ゲームを設計って言っても超手書き。アプリなんか作ってません。
シナリオとゴール
ある時、こんな手紙がさりげなく机の上に置いてあります。
さらわれた、姫の名前はぬいぐるみの名前や、ペットの名前でOK。
ここでは簡単なシナリオと、達成すべきゴールが予め子供に提示されています。
王様になりきって重々しく、姫の救出を依頼します。
ゴールを邪魔する障害と、障害を乗り越えるためのルール
別の紙で、地図が書いてあってゴールまでの課程を定義しています。
ゴールを邪魔するのは地図上にいるモンスター。
モンスターとの戦いはパパかママとの「じゃんけん」です（毎日のことなので、道具とか使うと親がめんどくさい）。
姫に近づくにつれて、モンスターをやっつけるための「じゃんけん」で勝たないといけない回数が増えていきます。もちろん、最後にはラスボスが居ます。
がんばった時の報酬
ゴールまでの課程にある障害を越えていくために、いくつかのお助けアイテムがあります。
「まほう」勉強すると覚えます。
「ひっさつわざ」運動するとできるようになります。
「ぶき」仕事（手伝い）をしたお金で買える。
例えば、魔法を使うとじゃんけん２回分勝った分に相当します。便利ですねー。
「魔法を覚えるためには頭が良くなくてはいけないから」みたいな、なんか理由を付けてあげると、子供の中での妄想が膨らみます。
どのくらいやると、魔法を覚えるのかは、子供のやる気や、進捗を見ながらチューニングします。うちでは、それぞれ１日１回やるともらえるシールを１０枚集めるごとに魔法とかを覚えます。
魔法などにはレベルがあって、いっぱいシールを集めると、どんどん強いのを覚えて行きます。
子供のやる気はでたのか
成果としては、結構、やってくれて５月はこんな感じ。「まほう」「ひっさつわざ」「ぶき」をもらうためのシールがほぼ毎日貯まりました。
飽きないように、小イベントを定期的に挟みました。例えば、しばらく「まほう」「ひっさつわざ」「ぶき」がもらえない日が続いている時は、「漢字道場」が開催され、いくつかの漢字が覚えられたら、「普通ではもらえない（と、ゲーム設計者である私が定義した）武器」が手に入ります。
いやー、ソーシャルゲームを設計するのってこんな感じなんでしょうね。
いかに飽きさせずに、ドロップさせずに、課金させるか、みたいな。
比較評価！モックアップ作成ツール「Justinmind」と「AppGyver」のPrototyperを使ってみた
モックアップ作成ツールとは
ここで言及しているモックアップとは、実際のアプリを作る前にUIだけを確認するために用意するものです。僕も実際のプロジェクトの中で、関係者に事前にモックアップで合意を取ってからアプリの開発に入ります。
同じジャンルのツールで一番有名なのはBalsamiqでしょうか
モックアップ作成ツールとして、同じPrototyperという名前のツールがJustinmind社とAppGyver社からでています。どちらも静止画だけでなく、動的なモックアップを簡単に作ってデザインや操作感の検証を行えるツールです。
どちらのツールも非常に今注目されているツールですが、コンセプトが結構違うので自分のやりたいことによって選択する必要があります。
Justinmind社のPrototyper
http://www.justinmind.com/prototyper/features-build
Freeプランで使っています。今までメインはこちらを使ってきました。
概要
iPhone/iPad、Android、Webのデザインテンプレートが予め用意されており、それを使ってGUIを組み立てていきます。
組み立てたUIにアクションを埋め込むことができて、ブラウザでアプリが動いているかのように操作することができます。ボタンの背景にイメージを設定することもできるので、作り込んだデザインも用意することができます。
自分の使い方
アプリの特徴的な画像（ロゴ、グラフのイメージ、写真など）以外はテンプレートのデフォルトの部品でざくざくモックを作っていきます。
この時点で、このUIで何かできるのか、どんな情報が見られるのか、とのような配置、構成なのか、といったビジュアル以外のデザインはできあがるので、関係者や、想定ユーザに動くイメージを見てもらって検証します。
ここまでできているとアプリの開発には入れるので、Illustrator、Photoshopを使ったビジュアルデザインと並行して開発に着手します。
このツールでビジュアルまで凝ったモックを作り込むのは手間がかかるので、逆にIllustrator等で作ったイメージでビジュアルは評価して、改善を繰り返しています。
このツールの良い点は、デザインして設定して公開する機能が一つになっているので、その場で、デザインを直して公開という作業がスピーディーに行けます。
AppGyver社のPrototyper
http://www.appgyver.com/
Freeプランでは３画面までしかサポートしてないので、Basicプランで使っています。
概要
デザインテンプレートとかないです。デザイン済みのイメージをアップロードするところからはじめます。
そして、アップロードされたイメージに領域を指定して、アクションを埋め込んで行きます。
例えばボタンの場所をマウスで囲って、別の画面へ遷移するアクションを設定します。
作ったモックはURLや、QRコードを使って他の人にシェアでき、このツール用のスマフォアプリが用意されているので、そのアプリ上でモックを動かして評価します。
このモック実行用のアプリが、iPhone/iPadだとさくさく動いて良いですが、Android（Galaxy S3とSony Tablet Sで評価）ではアプリが頻繁に落ちてしまいました。
自分の使い方
Illustratorで先にビジュアルデザインを作ります。この段階では、デザイナーさんではなく自分でやりますので、あまり凝ったことはやりません。Illustrator用のiPhone/iPad、Androidのデザインテンプレートを使ってさくさく作ります。テンプレートは例えばこんなの。
それをAppGyverのツールに取り込んで、アクションを設定した後、関係者にシェアします。
こちらツールの良い点は、Illustratorで画面を作るので、自由度が高くてどんどんUIを作り込んで行けること。Justinmindのやつでは、ここにこの部品入れたいんだけど、なんか入らない・・・、ということもたまにあります。AppGyver側の設定操作も画面上を枠で囲って、アクションを埋め込むという直感的なもので良いです。
ただ、デザインが別ツール故に、デザインを修正して公開までのステップがJustinmind社のと比べると多いです。がんがん修正が発生するフェーズでは面倒に感じます。
面白いのはモックの元になるのは画像だったら何でも良いので、手書きのイラストを写真で取って取り込んでも良いわけです。後はパワポで作ったイメージとかも。
