WordPressはブログだけでなくECサイトも簡単に構築できるってご存知ですか？
WordPressでブログサイトを構築して運営されている方は大勢いらっしゃると思います。
またCMSとしても使いやすいので、ブログだけでなく企業のコーポレートサイトなど、商用サイトでも今では多く使われています。
しかしWordPressは実はECサイトの構築にも使えちゃうのです。
とはいえ、WordPress単体では通常私達が思うECサイトは作れません。
WordPressをECサイトにするには、カートシステムのプラグインを使います。
WordPressをお使いの方なら、プラグインがどんなものか良くご存知なので深く説明はしませんが、カートのプラグインを使う事で、比較的簡単にECサイトを作る事ができるのです。
もちろんEC専用に開発されたパッケージや、大規模なスクラッチ開発にはかないませんが、比較的簡単かつ安価に構築できるシステムとしては非常に費用対効果の高い、バランスのとれた通販サイトを構築することが可能です。
日本で安価にECサイトを構築する方法といえば、ECキューブが非常に有名ですが、結構癖があり、いろいろな機能を追加したりカスタマイズしたくなると以外と費用が掛かるというのが筆者の印象（あくまでも個人的感想）です。
WordPress+プラグインを使う場合は、ページの作成自体は基本的にWordPress側で制御しますので、かなりこったサイト作成も可能になります。
ただし、カートの機能はプラグインの機能に制限されますので、複雑な決済システムを使いたい場合は、専用のパッケージ製品の方が良いでしょう。
また、webページ作成のスキル自体がまだそれほど無いというような方にとってはカラメルなどのASPサービスの方が、自由度は低いですがその分サイト作成は簡単だと思います。
とはいえ、WordPress + カートプラグインはかなり安価にほどほど自由度の高い（月商数百万規模でも充分な機能がそろっていると思います）通販サイトが作れる手段ですので、これから自分でECサイトを作ってみようと考えている個人事業主や中小企業の方には、是非お勧めしたい手段です。
ちなみに、弊社で構築した帽子の通販サイト ビスポークトーキョー はWordPress + WelCartで構築しております。
WordPressでつくったECサイトがどんなもんなのか実例を見たい方は、是非参考にご覧ください。
ちなみにファッション系の通販なので、海外のファッション通販サイトに多いミニマルデザインを採用しています。
このサイトは日本でよくある通販のデザインとはちょっと違う感じに見えるかもしれませんが、デザインやページの作り方を変えれば、もちろん見慣れた日本の通販サイトのようなページを作る事も可能ですよ。
WelCartは日本製のカートプラグインで、ユーザーも多く使いやすいのでお薦めです。
2014年10月12日日曜日
2014年5月31日土曜日
AdMobが新しくなるそうです
Google AdMobさんから、「 新しいAdMob にアップグレードをお願いします」というメールが届きました。
正直今はアプリの収益化をほとんど諦めているので、SDKの更新だったら放置しようかと思ったのですよ。
弊社のアプリには広告のSDKとして、AdMobとiAdとBehaviAdが入っています。最悪AdMobが止まっても、他の広告が入りますので。
しかし、メールをよく読んでみるとこんな記載が。。。
アップグレードは簡単で、SDK の更新は不要です。
ん？なに？
要するに、アプリ側は変わらないけれどGoogleサイドでの集計方法とユーザーの管理方法（支払関係かな）を変えるので、ユーザー側の管理画面も変えますよ、ということだと勝手に理解した。
「従来版の admob は 2014 年 8 月 31 日にサービスが終了します。この日以降、従来版の admob でアプリを宣伝、収益化することはできなくな」るそうですよ。
しかし、SDKを変えなくても（アプリ側に変更を加えなくても）広告配信の可否をコントロールすることができるのかと、一瞬ちょっとビックリ。
まあ、ちょっと考えたら、新しい管理画面での認証をしていないidには配信しなければ良いだけですね。
また、AdMobに久々にログインしてみて初めてわかったのですが、支払方法の変更もあるようです。
PayPalが使えませんということで、銀行口座の登録をしたのですが、前はPayPalを指定していたのだっけかなあ？ iAdはPayPalだった気がするけど、実はよく覚えていません^^;
アドモブの振込最低額の目安は8,000円（前は¥5,000くらいじゃなかったっけ？）なので、たぶん僕のアプリじゃ一生振込されないだろうなあとは思います。
なにせ、そこそこダウンロードされていたときのAdMobの収益は、実験も兼ねて出稿の原資に回していたので現在の残高はほぼ0ですから^^;
念のため、万が一のことを考え一応アップデートしておきました。
AdMobを入れたのは良いけれど収益化できずに放置している方は、上記のように簡単な作業ですから、念の為アップデートされたほうが良いですよー。
では
正直今はアプリの収益化をほとんど諦めているので、SDKの更新だったら放置しようかと思ったのですよ。
弊社のアプリには広告のSDKとして、AdMobとiAdとBehaviAdが入っています。最悪AdMobが止まっても、他の広告が入りますので。
しかし、メールをよく読んでみるとこんな記載が。。。
アップグレードは簡単で、SDK の更新は不要です。
ん？なに？
要するに、アプリ側は変わらないけれどGoogleサイドでの集計方法とユーザーの管理方法（支払関係かな）を変えるので、ユーザー側の管理画面も変えますよ、ということだと勝手に理解した。
「従来版の admob は 2014 年 8 月 31 日にサービスが終了します。この日以降、従来版の admob でアプリを宣伝、収益化することはできなくな」るそうですよ。
しかし、SDKを変えなくても（アプリ側に変更を加えなくても）広告配信の可否をコントロールすることができるのかと、一瞬ちょっとビックリ。
まあ、ちょっと考えたら、新しい管理画面での認証をしていないidには配信しなければ良いだけですね。
また、AdMobに久々にログインしてみて初めてわかったのですが、支払方法の変更もあるようです。
PayPalが使えませんということで、銀行口座の登録をしたのですが、前はPayPalを指定していたのだっけかなあ？ iAdはPayPalだった気がするけど、実はよく覚えていません^^;
アドモブの振込最低額の目安は8,000円（前は¥5,000くらいじゃなかったっけ？）なので、たぶん僕のアプリじゃ一生振込されないだろうなあとは思います。
なにせ、そこそこダウンロードされていたときのAdMobの収益は、実験も兼ねて出稿の原資に回していたので現在の残高はほぼ0ですから^^;
念のため、万が一のことを考え一応アップデートしておきました。
AdMobを入れたのは良いけれど収益化できずに放置している方は、上記のように簡単な作業ですから、念の為アップデートされたほうが良いですよー。
では
2013年2月18日月曜日
WixページをWebmaster Toolsに登録する方法
WixでつくったウェブページをGoogleのウェブマスターツールに登録する方法です。
自分でウェブページを作成したことのある方は、SEOや数値管理のためにグーグルのウェブマスターツールを使っていることも多いかと思います。
Webmaster toolsは管理するサイトを追加（サイトの所有権を確認）するときに、HTMLファイルをアップロードしたり、タグを埋め込んだりする方法が一般的ですが、WixはHTMLを直接編集することができないのでそれらの方法が取れません。
それでもご安心ください。
Wixで作ったページをウェブマスターツールに追加する方法はちゃんとあります。
Wixのヘルプで調べても日本語のページがなかったりでちょっとわかりにくいので、以下に具体的にやり方を解説します。
なお、このエントリを検索してきた方は、ウェブマスターツールの基本的な使い方はすでにご存知だと思うので詳しくは書きません。ご了承ください。
1.Google Webmaster Toolsで「サイトを追加」する
WixでつくったページのURLを入力して「サイトを追加」をクリック
2.所有者確認
「おすすめの方法」はできないので「別の方法」のタブを選ぶ
3.確認方法
複数ある確認方法のうち「ドメイン名プロバイダ」を選ぶ
「ドメイン名プロバイダ」を選択すると、"TXTレコードをDNS設定に追加しろ"という趣旨のメッセージとともに下の様なコードが表示されるので、これをコピーします。
例： google-site-verification=hogehogexxxxxxxxxxxxxxxxx....
ここまでがGoogleウェブマスターツール側での事前作業です。
なお、まだ「確認」が残っていますので、ページは閉じないで残しておきます。
そして、次からはWix側の作業。
4.Wixにログイン
5.マイアカウントから「ドメイン」を選択
6.マイドメインの中から、追加したいURLの「管理」をクリック
7.ドメインレコードの「管理」をクリック
8.TXT（テキスト）欄の「新しいTXTレコードの追加」をクリック
9.TXT値に3でコピーしたTXTレコードを張りつけて、「追加」
注意：この時、TXT名には何も入れないで下さい！TXT名は空白にしておかなければなりません。
ここまでがWixでの作業です。
次はまた、閉じないでおいたGoogleウェブマスターツールに戻ります。
10.「確認」をクリック
エラーがでなければ、完了です。お疲れさまでした。
すぐにはデータは取れないので、翌日以降再訪して確認してください。
※【おしらせ】この記事はフジヤマワークスコーポレートサイトのブログにも内容をアップデートして転載しました。よろしければそちらもお読みください。
自分でウェブページを作成したことのある方は、SEOや数値管理のためにグーグルのウェブマスターツールを使っていることも多いかと思います。
Webmaster toolsは管理するサイトを追加（サイトの所有権を確認）するときに、HTMLファイルをアップロードしたり、タグを埋め込んだりする方法が一般的ですが、WixはHTMLを直接編集することができないのでそれらの方法が取れません。
それでもご安心ください。
Wixで作ったページをウェブマスターツールに追加する方法はちゃんとあります。
Wixのヘルプで調べても日本語のページがなかったりでちょっとわかりにくいので、以下に具体的にやり方を解説します。
なお、このエントリを検索してきた方は、ウェブマスターツールの基本的な使い方はすでにご存知だと思うので詳しくは書きません。ご了承ください。
1.Google Webmaster Toolsで「サイトを追加」する
WixでつくったページのURLを入力して「サイトを追加」をクリック
2.所有者確認
「おすすめの方法」はできないので「別の方法」のタブを選ぶ
3.確認方法
複数ある確認方法のうち「ドメイン名プロバイダ」を選ぶ
「ドメイン名プロバイダ」を選択すると、"TXTレコードをDNS設定に追加しろ"という趣旨のメッセージとともに下の様なコードが表示されるので、これをコピーします。
例： google-site-verification=hogehogexxxxxxxxxxxxxxxxx....
ここまでがGoogleウェブマスターツール側での事前作業です。
なお、まだ「確認」が残っていますので、ページは閉じないで残しておきます。
そして、次からはWix側の作業。
4.Wixにログイン
5.マイアカウントから「ドメイン」を選択
6.マイドメインの中から、追加したいURLの「管理」をクリック
7.ドメインレコードの「管理」をクリック
8.TXT（テキスト）欄の「新しいTXTレコードの追加」をクリック
9.TXT値に3でコピーしたTXTレコードを張りつけて、「追加」
注意：この時、TXT名には何も入れないで下さい！TXT名は空白にしておかなければなりません。
ここまでがWixでの作業です。
次はまた、閉じないでおいたGoogleウェブマスターツールに戻ります。
10.「確認」をクリック
エラーがでなければ、完了です。お疲れさまでした。
すぐにはデータは取れないので、翌日以降再訪して確認してください。
※【おしらせ】この記事はフジヤマワークスコーポレートサイトのブログにも内容をアップデートして転載しました。よろしければそちらもお読みください。
2013年2月12日火曜日
Facebook Developersから「緊急修正」のお知らせが来たら
少し前ですが、Facebook Developersから
「February 2013 Breaking Changes XXXX(アプリ名)を2013年2月6日までに更新する必要があります」
という緊急修正のお知らせをもらったFacebookアプリの開発者が多いかと思います。
メッセージが来た方は、既に対応済みと思いますが、もしかしたらそのまま放置している方もいるかもしれないのと、このあと３月と４月にも同じメッセージがくると思われますので、念のため対応の仕方をここに書いておきます。
メッセージの中身には
February 2013 Breaking Changes 緊急修正 ○時間前
あなたのアプリ「XXXXXXXX」は、February 2013 Breaking Changesのために更新する必要があります。
アプリが対応したならば、アプリダッシュボードの詳細設定セクションの移行設定を「有効」にしてください。
というような内容が記されていました。
"February 2013 Breaking Changes"というのは、大雑把にいうと、今後Facebookが実施するプライバシーに配慮したユーザー情報へのアクセスルールの改正や、それにともなうAPIの変更やを機能を廃止する"Breaking Changes"の予定のことです。
前回来たのはそのうちの2月実施分のお知らせです。
これは３回に分けて行われる予定で、このあと
March 6, 2013
April 3, 2013
にも予定されています。
※詳細はFacebook Developer Roadmap をご確認ください。
Roadmapに書かれている改修に該当する機能を実装していると、その日以降エラーがでるので、修正対応しましょう。
さて、メッセージに対する対応ですが、放置したり正しい設定をしなかったりすると、いつまでたってもアラートが出続けることになります。
以下が、対応方法です。
まず前提として、Breaking Changesの変更に該当する機能があれば、修正対応をしてください。
アプリ側の対応が完了したら、Developersの設定＞詳細設定に行き
ページ中程の「移行」の欄にある該当するBraking Changes のラジオボタンを「有効」に変更して、「変更を保存」します。
これでそれ以降アラートが出なくなります。
2012年10月6日土曜日
世界のInstagram写真をみられるPlacetagramをはじめました。
新サービスはじめました。
その名は、Placetagram
Place + tag + Instagram で、Placetagram・・・苦笑
Placetagramは世界中の公開されているInstagram写真をみることができます。
位置情報タグが付いているInstagramのメディアを、Google Mapsから逆ジオコーディングした位置情報をキーにして取得します。
Instagram API を利用して、地図上のどこでもみたい場所をクリックすれば、その周辺の最新写真がすぐみえる、気軽に世界旅行気分が楽しめるサイトを作りました。
地図を直接クリックして指定するだけでなく、地名や有名観光スポット・建物の名前などで検索することもできます。
どうそ、お気軽にお楽しみください。
その名は、Placetagram
Place + tag + Instagram で、Placetagram・・・苦笑
Placetagramは世界中の公開されているInstagram写真をみることができます。
位置情報タグが付いているInstagramのメディアを、Google Mapsから逆ジオコーディングした位置情報をキーにして取得します。
地図を直接クリックして指定するだけでなく、地名や有名観光スポット・建物の名前などで検索することもできます。
どうそ、お気軽にお楽しみください。
2012年8月21日火曜日
JSONViewが便利すぎる
InstagramのAPIを使って、OAuth認証を通してブラウザ経由でJSON形式のデータを取得するところまでまでは、とりあえずできました。
取り急ぎJSON形式のまま開いて見てみると
・・・かなり長いです。
ざーっと見ましたが、何がなんだかわかりません・・・
中にあるurlを適当に見繕ってブラウザにぶっ込んでも、当然のようにエラーになります。
うーん、中身を確認するにはPHPかJaveScript書かなきゃいけないんかなあ、大変だなあ、、と思いながら、いろいろ調べてみたところ、なんかすごい便利そうなChrome拡張を見つけました。
それが、JSONViewです。
もとはFireFox用だったみたいですが、Chrome版もばっちり動いてます。
上記のリンクから拡張を追加して、その後JSONをChromeに読ませると勝手にパースしてインデントまでしてくれちゃいます。
日本語が化けるというエントリもありましたが、自分の環境では、ちゃんと表示できてますね。無問題。
これで各APIで取れるデータがどんなもんなのか、事前にお試しで取得してみてさくっと確認できるようになりました。
簡単なプログラムでさえ自分ではほとんど書けない状態の私には、作業効率化のために非常に心強い拡張機能です。
作者さん、ありがとう！
取り急ぎJSON形式のまま開いて見てみると
・・・かなり長いです。
ざーっと見ましたが、何がなんだかわかりません・・・
中にあるurlを適当に見繕ってブラウザにぶっ込んでも、当然のようにエラーになります。
うーん、中身を確認するにはPHPかJaveScript書かなきゃいけないんかなあ、大変だなあ、、と思いながら、いろいろ調べてみたところ、なんかすごい便利そうなChrome拡張を見つけました。
それが、JSONViewです。
もとはFireFox用だったみたいですが、Chrome版もばっちり動いてます。
上記のリンクから拡張を追加して、その後JSONをChromeに読ませると勝手にパースしてインデントまでしてくれちゃいます。
日本語が化けるというエントリもありましたが、自分の環境では、ちゃんと表示できてますね。無問題。
これで各APIで取れるデータがどんなもんなのか、事前にお試しで取得してみてさくっと確認できるようになりました。
簡単なプログラムでさえ自分ではほとんど書けない状態の私には、作業効率化のために非常に心強い拡張機能です。
作者さん、ありがとう！
2012年8月19日日曜日
Instagram API Access Token 取得にエラーがでたら
InstagramのAPIを使ってアプリをつくるために、Access Tokenを取得しました。
途中ちょっと手間取ったので、備忘録としてエントリしておきます。
あっさり、上記の方法でAccess Tokenが取得できました・・・
途中ちょっと手間取ったので、備忘録としてエントリしておきます。
さて、単に写真だけをひっぱってくるくらいであればAccess Tokenは必要ないみたいですが、どうせならフォローしている人の写真をソートしたり、いいねしたりもできるようにしたいので、後でバタバタするより先に取ってしまうことにしました。
※以下は、Developer登録とClient登録が済んでいて各ID取得済みである前提で記載しています。まだの方はこちらのエントリの真ん中辺りを参考にしてください。
ステップ１．ユーザに認証用URLを表示する
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
この時点で、ログインページを表示し、アプリケーションにデータへのアクセス許可を求める確認ページが表示されます。
ステップ２．Instagramサーバからリダイレクトされる
ユーザがログインに成功し、アプリケーションにアクセス許可を与えると、Instagramサーバがredirect_uriにcodeパラメータを付加して呼び出します。codeパラメータで渡された値は、ステップ３で用います。
http://your-redirect-uri?code=CODE
ステップ３．access_tokenを要求する
ステップ２でcodeパラメータを受け取ることができました。この値を使い、指定したユーザ用のaccess_tokenを受け取るためのデータ交換をおこないます。データ交換は、access_token用URLにcodeの値と併せて、いくつかのアプリケーション認証情報をPOSTで送信するだけのことです。必要なパラメータを以下に示します。
- client_id クライアントID
- client_secret クライアントシークレット
- grant_type 現在、"authorization_code"のみ指定することができます。
- redirect_uri 認証リクエストを送信した際にredirect_uriで指定した値です。注意: この値は、認証リクエストで指定した値と完全に一致していなければなりません。
- code 認証ステップで受け取ったcodeパラメータの値
access_token要求は、たとえば次のようになります。
curl \
-F 'client_id=CLIENT-ID' \
-F 'client_secret=CLIENT-SECRET' \
-F 'grant_type=authorization_code' \
-F 'redirect_uri=YOUR-REDIRECT-URI' \
-F 'code=CODE' \
https://api.instagram.com/oauth/access_token
呼び出しが成功すると、OAuthトークンを整形したデータが返されます。
ということで、ユーティリティからターミナルを起動して、上記のコマンドを実行します。最後の一行を入れてreturnキーを押して、２秒程待つと・・・
あれ？エラーです・・・orz
念の為、Instagramから一度ログアウトして、再度ステップ１から再開しCODEを再取得して試してみましたがまたエラーです＿|￣|○
返ってくるメッセージを見ると400エラーのようですが、後ろに"No matching code found"とかも書いてます。うーん、CODEはコピペだから間違う筈ないんだけどなあ。
悩んだときはドキュメントに立ち戻ってみます。
すると上記の下にこんな記述がぁっ！
“サーバ機能を持たないアプリケーション（たとえば、完全に独立したJavaScriptアプリケーションなど）を作成する場合は、上記のステップ３を実行することはできません。つまり、access_tokenを受け取ることも、クライアントシークレットを渡すこともできません。クライアントシークレットは、アプリケーションの管理下にないデバイスに保存することは絶対に避けなければなりません。では、access_tokenを受け取るにはどうしたらいいのでしょう？OAuth 2.0仕様を策定した賢い人たちは、この問題をちゃんと予期しており、暗黙の認証フローを用意したのです。”
あらら、なんか怒られたみたいです。
え、でもcurlってFTPサーバーみたいに動くコマンドなんじゃないの？なんで？？
という疑問は素人が考えても仕方がないんで取りあえず横に置いておいて、その「暗黙の認証フロー」を試してみることにします。
クライアントサイド（暗黙の）フロー
ステップ１．ユーザに認証用URLを表示する
https://instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
この時点で、ログインページを表示し、アプリケーションにデータへのアクセス許可を求める確認ページが表示されます。明示的フローの場合と違い、response_typeパラメータの値が"token"であることに注意してください。
ステップ２．URLフラグメントによりaccess_tokenを受け取る
ユーザがログインに成功し、アプリケーションにアクセス許可を与えると、Instagramサーバがredirect_uriにURLフラグメントとしてaccess_tokenを付加して呼び出します。次のようになります。
http://your-redirect-uri#access_token=ACCESS-TOKEN
URLフラグメントのaccess_token部分を取り出せばおしまいです。
同じ様にエラーでAccess Tokenの取得ができない方は、クライアントサイドフローを試してみて下さい。
Instagram Developer に登録してみた
ちょっと思うところあって、InstagramのAPIをいじってみようと、Developer登録してみました。
APIに関していろいろと参考になりそうなブログを探してみたのですが、あまり最近のは見当たりません。大体2011年のAPIが公開されたあたりのエントリです。
公開されてからあまり大きな変更がされていないということですかね？
FacebookのGraph APIを使う時に、しょっちゅう仕様が変わるので設計に悩んだことがあるので、あまり変更がなさそうなのはいいですね。
とはいえ、InstagramはそのFacebookに買収されたので、今後はどうなるかわかりません。ちょっと心配です…
閑話休題。
APIをいじるには、Developer登録をした後にApplicationの登録をします。
ここまでで参考になったのはこことここです。ありがとうございます。
まだぜんぜんいじっていないので、感想などはまた改めて。
APIに関していろいろと参考になりそうなブログを探してみたのですが、あまり最近のは見当たりません。大体2011年のAPIが公開されたあたりのエントリです。
公開されてからあまり大きな変更がされていないということですかね？
FacebookのGraph APIを使う時に、しょっちゅう仕様が変わるので設計に悩んだことがあるので、あまり変更がなさそうなのはいいですね。
とはいえ、InstagramはそのFacebookに買収されたので、今後はどうなるかわかりません。ちょっと心配です…
閑話休題。
APIをいじるには、Developer登録をした後にApplicationの登録をします。
ここまでで参考になったのはこことここです。ありがとうございます。
まだぜんぜんいじっていないので、感想などはまた改めて。
2012年8月10日金曜日
ダイスキンB6とペーパープロトタイピング
ちょっと前に話題になり、当時は品切れ続出で入手困難だったダイスキン。
私もA6サイズのダイスキンを愛用しております。
用途はとしては、まずはアイデア帳として。
そしてtips的な使い方ですが、A6ダイスキンって（勿論モレスキンもですが^^;）実はiPhoneより一回り大きい位のサイズなので、iPhoneアプリを作る際のペーパープロトタイピングに重宝するのです。
デザイン要素を原寸大に落とした時、片手でもボタンが押し易い位置にあるかとか、表示は見やすいか、指で隠れないか、次のページに遷移したとき操作ミスしがちな配置じゃないか…などなどを手書きとはいえ、実際にさわれるイメージでテストするのです。
写真は当社のアプリQueuence設計時に使った実際のペーパープロトタイプです。
こんな落書きで意味あるのかと思われるかもしれませんが、なかなかどうして、こんなラフなものでも、原寸大で触ってみて初めてわかる事や気が付くことが山のようにあります。
ペーパープロトタイピングをやったことの無い方は、だまされたと思って一度試してみることをオススメします。
さて、本題のB6モレスキンですが、今日久々に地元のダイソーの手帳売り場をチェックしたら見慣れない物を発見したのです。
そう、それがB6モレスキンだったのです！
A6モレスキンよりも2回り程大きいサイズ（あたりまえだ）。
これ、Kindle3とほぼ同じ大きさですね。
ということは、これから流行るだろうミニタブレット向けのペーパープロトタイプにピッタリということです。
ちょっとググったら春位から販売されてたらしいですが、割と小まめにダイソー見てるのに今日初めて見つけたという事は、これもA6と同じくレア商品のにおいがします。
koboやkindle fire向け開発を考えている方は、早めの在庫確保が吉かも？100円だしね
(´・ω・`)
私もA6サイズのダイスキンを愛用しております。
用途はとしては、まずはアイデア帳として。
そしてtips的な使い方ですが、A6ダイスキンって（勿論モレスキンもですが^^;）実はiPhoneより一回り大きい位のサイズなので、iPhoneアプリを作る際のペーパープロトタイピングに重宝するのです。
デザイン要素を原寸大に落とした時、片手でもボタンが押し易い位置にあるかとか、表示は見やすいか、指で隠れないか、次のページに遷移したとき操作ミスしがちな配置じゃないか…などなどを手書きとはいえ、実際にさわれるイメージでテストするのです。
写真は当社のアプリQueuence設計時に使った実際のペーパープロトタイプです。
こんな落書きで意味あるのかと思われるかもしれませんが、なかなかどうして、こんなラフなものでも、原寸大で触ってみて初めてわかる事や気が付くことが山のようにあります。
ペーパープロトタイピングをやったことの無い方は、だまされたと思って一度試してみることをオススメします。
 |
| Kincle3との比較 |
そう、それがB6モレスキンだったのです！
A6モレスキンよりも2回り程大きいサイズ（あたりまえだ）。
これ、Kindle3とほぼ同じ大きさですね。
ということは、これから流行るだろうミニタブレット向けのペーパープロトタイプにピッタリということです。
ちょっとググったら春位から販売されてたらしいですが、割と小まめにダイソー見てるのに今日初めて見つけたという事は、これもA6と同じくレア商品のにおいがします。
koboやkindle fire向け開発を考えている方は、早めの在庫確保が吉かも？100円だしね
(´・ω・`)
 |
| B6ダイスキン。手前はA6ダイスキンです |
2012年5月5日土曜日
iAd Network Settingsは審査終了前にしなければならないというおはなし
次のiOSアプリを申請しました。
といってもまったく新しいアプリというわけではなく、行列待ち時間予測アプリQueuenceの英語版です。
こういう時によくあるのは1つのアプリをマルチランゲージ対応で作り、端末の言語環境で言語を切り替えるやり方です。そのほうがスマートですし、バグ等の対応やバージョン管理、ユーザー対策もしやすいのですが、今回はあえて日本語版と英語版を別アプリにすることを選択しました。
その理由はいくつかあるのですが、一つ大きな理由として、アプリに導入する広告を分けたかったということがあります。
もちろん1つのアプリに複数の広告システムを入れて出し分けるということも可能ですが、今の私のリソースではそれは結構ハードルが高いです。また、いくつも入れてしまうと、例えばそのうちの1つの広告APIが変更されただけで改修しなければならなくなったりするかもしれません。
英語版にも実は2つの広告システムを導入しているので、一方に問題が起こるリスクはあるのですが、3つ入れるよりは当然リスクは減りますし、何か問題があっても日本語と英語でバイナリが分かれている事で、1つの広告システムに問題が発生してもすべての自社製品が世の中から消えてしまう危険性は無くすることができます。
さて、また前置きが長くなってしまいました。
本題はiAdのセッティングについてです。
お察しのように英語版にはiAdを導入しました。日本マーケットではそれほど盛り上がっていない感じですが、英語圏では実際のところどうなのかデータ取りの為にも導入してみたかったのですよ。
iAdの契約や導入については、様々な記事があるのでここでは割愛します。
私が備忘録として書いておきたいのは、iAd Networking Settingのタイミングです。
iOSアプリをリリースするのに、iTunes Connectで銀行情報やら税務情報やらを入力してContractsを作成し、そのついでにiAdのContractも作成していると思います。ですが、このままではiAdは配信されないのです。
iAdは、Appストアに並ぶ前のテスト状態では実機であっても本物の広告は配信されません。テスト時はダミー広告しか表示されないのです。この事が念頭にあったので、本物の広告は審査を通りさえすれば始まる物だと勝手に思い込んでいました。
しかし！実はもう一つ重要な設定が残っていたのです。
Appleに申請すると、iTunes ConnectのManage Your Applicationsに申請中のアプリが登録されますが、ここで登録されたアプリのアイコンを選択すると[Rights and Pricing]や[Manage In-App Purchases]などと並んで[iAd Network Settings]というボタンが出てきます。
この[iAd Network Settings]を押し、アプリのメイン対象年齢の選択が終わらない限りいつまでたっても広告が配信されないのです。
そして重要なのが、この選択は審査が終了する前に行わなければならないのです！
（私は審査終了後に設定するものだと思い込んでいて、あやうく広告が無くなるところでした。あぶないあぶない）もし審査終了（通過）後に気が付いた場合は、再度Submitして上記の期間内に設定しなおさなければなりません。これは大変ですね。
なお、上記の年齢制限ですが、アプリの主な対象ユーザー年齢が17歳以下かどうかをYes/Noで選択します。おそらく配信される広告の内容をコントロールするのだと思いますが、17歳以下にすると広告の総量が減るという情報があるので、私はNoを選択しました。
これからiAdを始めようという方や、導入したけど全然配信されないなあという方は、設定ののタイミングに注意して申請してくださいね。
といってもまったく新しいアプリというわけではなく、行列待ち時間予測アプリQueuenceの英語版です。
こういう時によくあるのは1つのアプリをマルチランゲージ対応で作り、端末の言語環境で言語を切り替えるやり方です。そのほうがスマートですし、バグ等の対応やバージョン管理、ユーザー対策もしやすいのですが、今回はあえて日本語版と英語版を別アプリにすることを選択しました。
その理由はいくつかあるのですが、一つ大きな理由として、アプリに導入する広告を分けたかったということがあります。
もちろん1つのアプリに複数の広告システムを入れて出し分けるということも可能ですが、今の私のリソースではそれは結構ハードルが高いです。また、いくつも入れてしまうと、例えばそのうちの1つの広告APIが変更されただけで改修しなければならなくなったりするかもしれません。
英語版にも実は2つの広告システムを導入しているので、一方に問題が起こるリスクはあるのですが、3つ入れるよりは当然リスクは減りますし、何か問題があっても日本語と英語でバイナリが分かれている事で、1つの広告システムに問題が発生してもすべての自社製品が世の中から消えてしまう危険性は無くすることができます。
さて、また前置きが長くなってしまいました。
本題はiAdのセッティングについてです。
お察しのように英語版にはiAdを導入しました。日本マーケットではそれほど盛り上がっていない感じですが、英語圏では実際のところどうなのかデータ取りの為にも導入してみたかったのですよ。
iAdの契約や導入については、様々な記事があるのでここでは割愛します。
私が備忘録として書いておきたいのは、iAd Networking Settingのタイミングです。
iOSアプリをリリースするのに、iTunes Connectで銀行情報やら税務情報やらを入力してContractsを作成し、そのついでにiAdのContractも作成していると思います。ですが、このままではiAdは配信されないのです。
iAdは、Appストアに並ぶ前のテスト状態では実機であっても本物の広告は配信されません。テスト時はダミー広告しか表示されないのです。この事が念頭にあったので、本物の広告は審査を通りさえすれば始まる物だと勝手に思い込んでいました。
しかし！実はもう一つ重要な設定が残っていたのです。
Appleに申請すると、iTunes ConnectのManage Your Applicationsに申請中のアプリが登録されますが、ここで登録されたアプリのアイコンを選択すると[Rights and Pricing]や[Manage In-App Purchases]などと並んで[iAd Network Settings]というボタンが出てきます。
この[iAd Network Settings]を押し、アプリのメイン対象年齢の選択が終わらない限りいつまでたっても広告が配信されないのです。
そして重要なのが、この選択は審査が終了する前に行わなければならないのです！
（私は審査終了後に設定するものだと思い込んでいて、あやうく広告が無くなるところでした。あぶないあぶない）もし審査終了（通過）後に気が付いた場合は、再度Submitして上記の期間内に設定しなおさなければなりません。これは大変ですね。
なお、上記の年齢制限ですが、アプリの主な対象ユーザー年齢が17歳以下かどうかをYes/Noで選択します。おそらく配信される広告の内容をコントロールするのだと思いますが、17歳以下にすると広告の総量が減るという情報があるので、私はNoを選択しました。
これからiAdを始めようという方や、導入したけど全然配信されないなあという方は、設定ののタイミングに注意して申請してくださいね。
2012年3月15日木曜日
非エンジニアがどのようにエンジニアに指示を出すべきか
 |
| 出張中の飲料水333 |
過去に仕事でエンジニアと関わることがあったり、開発会社に外注依頼をしたことがあったりすると、ちょっとは要求定義の仕方が分かっているかも知れません。ですが、自分で直接エンジニアに指示を出すとなると、SEが間に入ってくれる外注仕事とは違い仕様を自分できめる必要があります。
もちろんすべてをきちんとエンジニアの要求とおりに仕様決めすることはできないでしょう。私もできません。では、どうすべきか。
私見ですが、少なくともメインとなる機能の動きを事細かにシミュレートして、絵に描けるくらいにまで分解しておけば、エンジニアがどのようなコードを書けば実現できるか想像できる仕様書に落とせると思います。
以下は、私の実例です。
私はSEが作る様な仕様書は書けません。何度かチャレンジしたことはありますが断念しました。仕様書を書く代わりに、主にワイヤーフレーム（画面遷移図）やフローチャートを作ります。それとそのアプリがどんなことをどのように実現するかの企画書で、フローチャートでは表せない「中身」を事細かに書いておきます。
ワイヤーフレームは自分で思いつく限り、細かく遷移を書きます。どこに何をどう入力し、どこにどんなボタンがあり、ボタンを押すとどの画面に移り、そこで何が起こるか。すべてのインターフェイスに対し起こせるアクション毎に、その先の画面や出力内容を書いていきます。画面遷移に表せない裏側の処理などは、吹き出しで該当するところに細かく記入していきます。
ワイヤーフレームを作るときは、最初は手描きでもいいでしょうが、できればなるべくツールを使ってパーツなども実物に近いイメージで作ると良いでしょう。私は以前はパワポやVISIOを使っていましたが、今はcacooを使っています。cacooにはiPhoneやAndroidのパーツがステンシルとして登録されているので、アプリのワイヤーフレームを作るのにはとても適していると思います。
手描きからcacoo等で清書してみると、ボタンや他のパーツの配置が意外と大変なことに気が付きます。手描きだと描きながら都合のいいようにパーツを勝手にデフォルメして配置しがちですが、往々にして、そのままではユーザビリティが最悪になります。コーディング時に「こんな筈じゃなかった」と後悔しないように、なるべく早い段階で実物を想定したワイヤーフレームを作ることを強くお勧めします。
可能であれば、その段階でプリントアウトしてプロトタイプを作り、データを入力したりボタンを押して（もちろん真似だけ）、画面が遷移する場面でその画面の紙にしたりしながら、ユーザビリティのチェックをするべきです。できれば第三者にも協力してもらって忌憚の無い意見を貰っておきましょう。
どうしてもワイヤーフレームに落とし込めない、またはどのような画面にすれば実現できるか思いつかないものは、何をどうしたいかをなるべくこまかくフローチャートに整理しておきます。そして実際の制作段階に入る前に、素直にそれを見せて、どうすればプログラムでそれが実現できるか、エンジニアと相談してください。
間に営業さんがいる場合には、その営業さんに事前に相談するといいでしょう。開発会社の営業にはエンジニア出身の方が結構いらっしゃるので、もしそういう方がいればどんどん相談してアドバイスももらっておくと、後の工程がスムーズにいくと思います。
そうしてエンジニアには企画書とワイヤーフレームとフローチャートなど作った書類をすべて渡して、自分がどんなことをやりたいのかを理解してもらいます。そのうえで質問があれば（普通あると思います）質問をしてもらい、お互いが理解できたところで制作に入ります。
今まで程度の違いはあれ、ほとんど以上のような流れでエンジニアと仕事をしてきました。
おそらく足りないところを都度都度エンジニアさん達が補完してくれていたので、これでもなんとかなっていたのだと思いますが、なんとかなっていたのは事実なので、他の方でも応用できると思います。
さて、どんなサービス（アプリ）を作りたいか分かったところで、次は、開発言語や開発環境はどうするの？ということになると思います。
もしかすると、ここで「ん？何それ？」となる非エンジニアがいるかもしれないので、次はその辺を書きますね。
2012年3月5日月曜日
ベトナムでの仕事内容
さて、そろそろ今回の仕事のことをちゃんと書いておきましょう。
今回のベトナム訪問の目的は、弊社のアプリ開発を委託しているバイタリフィ・アジアさんに伺って、直接ディレクションをすることです。
日本にいる時から、ChatWorkやRedmineを使って結構細かいところまでほぼリアルタイムで指示は出せていました。しかし、自信を持ってサービスを世の中に出すには、こちらの意図通り通りのものを納品してもらうために、同じ場所で同じ物を見ながら直接ディスカッションして細部を詰める必要があります。『神は細部に宿る』です。
バイタリフィさんとしても、先頃リリースされたスタートアップ向けオフショア開発サービスの条件として、発注者に一度は直接ベトナムに来てもらうことを求めています。
これは現地で直接指示を出すことでブリッジエンジニアの工数を減らしたり、通常受託側がアサインしなければならない日本人スタッフの人件費を削減したりする目的があります。しかしながらこれには単純なコスト削減だけではなく、日本人もベトナム人も同じ人間なので直接顔を合わせ握手した人とのほうが結果的に仕事を良い方向に導くことができるという効果があります。
私自身日本にいてネット越しでやりとりしている段階では、工数の見積もりなどにちょっと不満に感じるところもありましたが、こちらに来てみたら一つ一つの機能の実装は早いし、日本にいた時はほとんどもらわなかった逆提案も毎日のよう出てくるので、日々品質を上げていけているのを実感しています。
あと強いて言えば、ベトナムの現地スタッフは素直すぎて私の設計を文字通り忠実に再現しようとするので、ある意味融通が利きません（むしろ自分が作り易いように勝手に仕様変更されちゃうよりはよっぽどやり易い文化ではありますが…）。例えば、私の書いた画面遷移図であるパーツの色が一つだけ抜けていたりすると、わざわざそっくりそのまま作り込んできたりします（そっちのほうが面倒なのに）。そういったちょっとしたストレスも、対面でやりとりすることによって随分減っています。
よほどスキルの高いチームかカリスマリーダーでもいない限り、遠隔地同士ネット越しだけで満足できるものを作り上げるのは至難の業です。特にこれから事業を始めようというスタートアップであれば尚更コストのみで品質を担保することはかなり厳しいでしょう（企業での開発経験が無い方は特に）。
そこを直接開発現場に入るこの方式は、刻一刻と発生する諸問題に触れて品質アップに繋がる経験を積むことができ、かつ人間的なコミュニケーションも取れ、結果的に品質も（日本からメールで指示を出しているだけの場合よりも）上げることができる、一石二鳥のシステムだと思います（休みがあれば観光だってできちゃいます ^^）。
また、弊社は「ひとり会社」ということもあり、今後もバイタリフィさんとは継続的にお付き合いしていくことになると思います。そういう意味で、単なる「クライアント」と「委託先」の関係ではなく、「チーム」の一員として自分を受け入れてもらう為にも、今回のベトナム訪問は重要な意味を持ちます。
具体的なこちらでの仕事内容としては、ベトナムに来る前の時点でレビュー版に機能の実装をほぼ終えていましたので、日々更新されるレビュー版を使っての細部調整や、現場からの意見やアイデアの検討、意図通りに動かなかった機能の善後策、動作テスト、レビュー時に出たバグの対応等を主に行っています。
バイタリフィ・アジアはブリッジエンジニアに日本語のできるベトナム人スタッフを充てています。というかブリッジエンジニアだけでなく、エンジニア百数十名のほとんどが日本語とその他にも英語や中国語も操れるというアグレッシブで優秀な人達です。
こういう優秀な若者達が日本人の何分の一という物価の下で働いている（誤解の無いよう書いておくと、ここのエンジニアはベトナム国内ではかなりの高待遇です）訳ですから、日本から仕事が出て行くのも仕方の無いことかもしれません。今後彼らがどんどん経験を積んでいけば、スキルやアイデア面でも日本が追い抜かれる日が来るかもしれません。そうならないためには、日本の若者達にももっと勉強してどんどん世界に出て行って、いろいろな物を見て考えて経験して、どん欲になんでも吸収して成長して欲しいと思います。そうしないと負けちゃうと切実に感じましたね、今回の出張で。もちろんおじさんの私も負けてはいられませんが。
閑話休題、ブリッジエンジニアと日本語でコミュニケーションできることで、機能的な部分はおそらく日本とベトナムで分かれたまま一度も顔を合わせること無く納品まで進めることも可能でしょう。しかし繰り返しになりますが、同じ場所で顔を合わせて作業することで、その品質は何倍にも高まります。
スタートアップであれば、金は無くとも溢れんばかりの情熱とアイデアと理想はある筈でしょう。その情熱でアイデアを直接ぶつけベトナムの若者達と切磋琢磨して、世の中に貢献できるような素晴らしいサービスを作っていく、それがスタートアップ向けオフショア開発サービスの本質だと思います。
ところで、バイタリフィ・アジアでは、近いうちにホーチミンオフィス内にコワーキングスペースを設置して、当面無料で解放するそうです。今後世界中の若者（じゃなくても）がこの場所に集まり、そしてここからアジアや世界各国へと旅立っていくことを想像すると、なんだかわくわくしてきます。
※自分なりに感じたスタートアップがオフショア開発をする際のtipsを、今後別エントリで書いて行く予定です。何かの参考になれば幸いです。
 |
| バイタリフィアジアが入居するビル |
今回のベトナム訪問の目的は、弊社のアプリ開発を委託しているバイタリフィ・アジアさんに伺って、直接ディレクションをすることです。
日本にいる時から、ChatWorkやRedmineを使って結構細かいところまでほぼリアルタイムで指示は出せていました。しかし、自信を持ってサービスを世の中に出すには、こちらの意図通り通りのものを納品してもらうために、同じ場所で同じ物を見ながら直接ディスカッションして細部を詰める必要があります。『神は細部に宿る』です。
バイタリフィさんとしても、先頃リリースされたスタートアップ向けオフショア開発サービスの条件として、発注者に一度は直接ベトナムに来てもらうことを求めています。
これは現地で直接指示を出すことでブリッジエンジニアの工数を減らしたり、通常受託側がアサインしなければならない日本人スタッフの人件費を削減したりする目的があります。しかしながらこれには単純なコスト削減だけではなく、日本人もベトナム人も同じ人間なので直接顔を合わせ握手した人とのほうが結果的に仕事を良い方向に導くことができるという効果があります。
私自身日本にいてネット越しでやりとりしている段階では、工数の見積もりなどにちょっと不満に感じるところもありましたが、こちらに来てみたら一つ一つの機能の実装は早いし、日本にいた時はほとんどもらわなかった逆提案も毎日のよう出てくるので、日々品質を上げていけているのを実感しています。
あと強いて言えば、ベトナムの現地スタッフは素直すぎて私の設計を文字通り忠実に再現しようとするので、ある意味融通が利きません（むしろ自分が作り易いように勝手に仕様変更されちゃうよりはよっぽどやり易い文化ではありますが…）。例えば、私の書いた画面遷移図であるパーツの色が一つだけ抜けていたりすると、わざわざそっくりそのまま作り込んできたりします（そっちのほうが面倒なのに）。そういったちょっとしたストレスも、対面でやりとりすることによって随分減っています。
よほどスキルの高いチームかカリスマリーダーでもいない限り、遠隔地同士ネット越しだけで満足できるものを作り上げるのは至難の業です。特にこれから事業を始めようというスタートアップであれば尚更コストのみで品質を担保することはかなり厳しいでしょう（企業での開発経験が無い方は特に）。
そこを直接開発現場に入るこの方式は、刻一刻と発生する諸問題に触れて品質アップに繋がる経験を積むことができ、かつ人間的なコミュニケーションも取れ、結果的に品質も（日本からメールで指示を出しているだけの場合よりも）上げることができる、一石二鳥のシステムだと思います（休みがあれば観光だってできちゃいます ^^）。
また、弊社は「ひとり会社」ということもあり、今後もバイタリフィさんとは継続的にお付き合いしていくことになると思います。そういう意味で、単なる「クライアント」と「委託先」の関係ではなく、「チーム」の一員として自分を受け入れてもらう為にも、今回のベトナム訪問は重要な意味を持ちます。
具体的なこちらでの仕事内容としては、ベトナムに来る前の時点でレビュー版に機能の実装をほぼ終えていましたので、日々更新されるレビュー版を使っての細部調整や、現場からの意見やアイデアの検討、意図通りに動かなかった機能の善後策、動作テスト、レビュー時に出たバグの対応等を主に行っています。
 |
| アグレッシブ過ぎて ビルを貫通した木 |
こういう優秀な若者達が日本人の何分の一という物価の下で働いている（誤解の無いよう書いておくと、ここのエンジニアはベトナム国内ではかなりの高待遇です）訳ですから、日本から仕事が出て行くのも仕方の無いことかもしれません。今後彼らがどんどん経験を積んでいけば、スキルやアイデア面でも日本が追い抜かれる日が来るかもしれません。そうならないためには、日本の若者達にももっと勉強してどんどん世界に出て行って、いろいろな物を見て考えて経験して、どん欲になんでも吸収して成長して欲しいと思います。そうしないと負けちゃうと切実に感じましたね、今回の出張で。もちろんおじさんの私も負けてはいられませんが。
閑話休題、ブリッジエンジニアと日本語でコミュニケーションできることで、機能的な部分はおそらく日本とベトナムで分かれたまま一度も顔を合わせること無く納品まで進めることも可能でしょう。しかし繰り返しになりますが、同じ場所で顔を合わせて作業することで、その品質は何倍にも高まります。
スタートアップであれば、金は無くとも溢れんばかりの情熱とアイデアと理想はある筈でしょう。その情熱でアイデアを直接ぶつけベトナムの若者達と切磋琢磨して、世の中に貢献できるような素晴らしいサービスを作っていく、それがスタートアップ向けオフショア開発サービスの本質だと思います。
ところで、バイタリフィ・アジアでは、近いうちにホーチミンオフィス内にコワーキングスペースを設置して、当面無料で解放するそうです。今後世界中の若者（じゃなくても）がこの場所に集まり、そしてここからアジアや世界各国へと旅立っていくことを想像すると、なんだかわくわくしてきます。
※自分なりに感じたスタートアップがオフショア開発をする際のtipsを、今後別エントリで書いて行く予定です。何かの参考になれば幸いです。
2012年2月29日水曜日
ベトナムでオフショア開発
さて、海外のリソースで開発と聞くと、意思疎通はどうなんだと心配になるかと思いますが、私がお願いしている会社に関しては問題なくコミュニケーションが取れています。
その要因としては、ブリッジエンジニアが日本語の読み書きOKだということが大きいと思います。
また、日本人スタッフが常に数名ベトナムに常駐していますので、いざという時には現地スタッフを良く知る日本人に間に入ってもらえるという安心感もあります。
日々のコミュニケーションは、チャットワークとredmineを使います。
質問や要望は主にチャットワークで。各種指示や、業務上の問い合わせ、仕様の確認等テクニカルなやりとりはredmineでタスク毎にチケットを発行して管理しています。
はっきり言って、過去自分が複数の会社でやってきたプロジェクトよりもシステマティックに管理できているといっても過言ではありません。
日本とベトナムの時差は２時間。夜型になっている自分からすると、現地が２時間遅れというのはちょうど良い感じがします。
これが例えばシリコンバレーだと17時間遅れで昼夜逆転となり時差以上にやりにくいことこの上ない。月曜や週末がズレているのも緊急時はイライラの元なので、時差が少ないのは本当に良いと思います。ま、シリコンバレーに外注する人もいないとは思いますけど…
その要因としては、ブリッジエンジニアが日本語の読み書きOKだということが大きいと思います。
また、日本人スタッフが常に数名ベトナムに常駐していますので、いざという時には現地スタッフを良く知る日本人に間に入ってもらえるという安心感もあります。
日々のコミュニケーションは、チャットワークとredmineを使います。
質問や要望は主にチャットワークで。各種指示や、業務上の問い合わせ、仕様の確認等テクニカルなやりとりはredmineでタスク毎にチケットを発行して管理しています。
はっきり言って、過去自分が複数の会社でやってきたプロジェクトよりもシステマティックに管理できているといっても過言ではありません。
日本とベトナムの時差は２時間。夜型になっている自分からすると、現地が２時間遅れというのはちょうど良い感じがします。
これが例えばシリコンバレーだと17時間遅れで昼夜逆転となり時差以上にやりにくいことこの上ない。月曜や週末がズレているのも緊急時はイライラの元なので、時差が少ないのは本当に良いと思います。ま、シリコンバレーに外注する人もいないとは思いますけど…
2012年2月26日日曜日
外部リソースで開発するということ
さて、私はエンジニアではないですが、会社はIT系ですので、もちろんアプリやソフトウェアを作ったりします。
しかしエンジニアではないので、自分では作れません。
エンジニアではないですが、エンジニアと同じ文脈で話をするためにそれなりに勉強はしてきました。
HTMLやJaveScriptは趣味でちょっといじったので、社内イントラの自部署ページを一人で作ったこともあります。
Xcodeを使ってiOSアプリのプロトタイプを独力でなんとか作れるくらいの知識もあります。
でも、「商品」として世に出すアプリを責任を持って作るかというと、たぶんいつまでたってもできません。
前職をやめてから３ヶ月程独学での勉強中心に過ごしましたが、やっぱり身にはつきません。才能はもちろん歳のせいでもあるとは思いますが。
自分でできないとなると、アプリの制作は外部リソースを使うしか選択肢はありません。
勿論自分で商用アプリ作れるようにもっと勉強するという考え方もあるでしょうが、それが実現する為に何ヶ月（何年）掛かるかわかりません。
この世界はスピードが勝負です。
リーンスタートアップを実現するために、自分で勉強して身につける時間と、外部リソースを探して納品するまでの時間を秤にかけて、最終的に外部リソースでの制作を選択しました。
外部故の大変さもありますが、今のところ概ね巧くまわっています。
ちなみにその外部リソースは、実はベトナムにあります。
オフショア開発というヤツです。
次回以降は、そのオフショア開発についてもいろいろ書いていきます。
しかしエンジニアではないので、自分では作れません。
エンジニアではないですが、エンジニアと同じ文脈で話をするためにそれなりに勉強はしてきました。
HTMLやJaveScriptは趣味でちょっといじったので、社内イントラの自部署ページを一人で作ったこともあります。
Xcodeを使ってiOSアプリのプロトタイプを独力でなんとか作れるくらいの知識もあります。
でも、「商品」として世に出すアプリを責任を持って作るかというと、たぶんいつまでたってもできません。
前職をやめてから３ヶ月程独学での勉強中心に過ごしましたが、やっぱり身にはつきません。才能はもちろん歳のせいでもあるとは思いますが。
自分でできないとなると、アプリの制作は外部リソースを使うしか選択肢はありません。
勿論自分で商用アプリ作れるようにもっと勉強するという考え方もあるでしょうが、それが実現する為に何ヶ月（何年）掛かるかわかりません。
この世界はスピードが勝負です。
リーンスタートアップを実現するために、自分で勉強して身につける時間と、外部リソースを探して納品するまでの時間を秤にかけて、最終的に外部リソースでの制作を選択しました。
外部故の大変さもありますが、今のところ概ね巧くまわっています。
ちなみにその外部リソースは、実はベトナムにあります。
オフショア開発というヤツです。
次回以降は、そのオフショア開発についてもいろいろ書いていきます。
登録:
投稿 (Atom)