SPIKA近況

久しぶりの更新です。

SPIKAの改修と本業の方でかなりばたばたしておりまして、ブログの更新までに手が回らない状態です。改修自体は佳境に入っていて指摘されていた問題は一通り修正される予定です。以前のようなcouchdbにべったりの設計を止め、アプリの実装にバックエンドに使うデータベースに依存しないようにしました。なので、例えばmysqlをストレージとして使うようにアプリの変更なしでバックエンドを書き替えるような事ができるようになります。これでさらにいろんな人のニーズに柔軟に対応できるようになるのではと思っております。

あと、協業の話もいくつか貰っていて、リリース後に某上場企業から相談を貰いまして、面白い取り組みを始める事になりました。

この事でコミュニティーに反映できるようにSPIKA自体もさらによくしていけると良いと思っております。

この件は近くリリースできる状態になると思うので、その時アナウンスできると思います。

ではでは

Spikaを公開して起こった事

久しぶりにブログを書きます。

10月の最初に弊社のオープンソースプロジェクト Spika をリリースしました。最初の1週間は全く反応が無く、30個近くのブログにプレスリリースを出したのですが、最終的に掲載して頂いたのは、TechWaveさんとMoongiftさんでした。

この期間は全くユーザーの反応が無かったので、かなり落ち込みました。Spika自体は今年に入ってから着手してまして、社員の誰かの稼働が空いた時に、日頃お客さんの要望に答える事を優先して、自分の好きな様にアプリが書けないフラストレーションを解消するプロジェクトとして進めておりました。オープンソースでモバイルメッセンジャーを作ると言うアイデアは僕のアイデアでして、SNSが流行った後にビジネスSNSが流行した流れがあったので、モバイルメッセンジャーでもビジネス利用の流れがあっても良いのでは無いかと思ったのがきっかけでした。ただ、僕たちは日本に居ないので営業力は皆無に近くどのようにして注目を集めるか考えた結果オープンソースにしました。

その後、Techwaveさんが記事にした後に全ては動き出しました。はてぶは400以上が付き、トップ２まで一瞬で上り詰めました。

そして、バックエンドの作りの問題を指摘され、瞬く間にネガティブコメントがネット中にポストされて行ったのでした。。

はてブのコメントやFacebookでも言及され、Twitterは細かく追っていませんが相当言われていると思います。

うちはアプリ制作専門だったので、バックエンドはあれば良いや程度だったのですが、まさかここまで突っ込まれるとは思っていませんでした。正直代表である僕が音頭を取っていたプロジェクトで良かったと思います。大きな会社でこういう状態になった場合、信用を失う自体になり、責任問題にもなるでしょう。会社が小さいうちに経験して良かったと思っていますが、大きめの組織でオープンソースプロダクトを作る際はまじ気をつけましょう。。

その後、レガシーズ 公式ブログ — PHPerはSpikaのどこを見たのか？　の記事とか、twitter上で名だたるPHPerの方々に建設的な意見を頂く事が出来て、問題となっている部分を１から書き直す方針が立ちました。それが今から1週間くらい前で、僕自身で土,日,月と3日で基本的な所は書き直しました。

週末だけで素のPHPからSilexで実装しなおしたSpika-Serverの気合には驚嘆せざるを得ない。 https://t.co/epIqPk36T2

— Yusuke Ando (@yando) 2013, 10月 17

日本を代表するPHPerの方からこんなコメントを貰ったりして大分テンションが上がりました。

そして、なんと昨日今日とSpika Hackathon を開催して頂き、問題となっていた部分のソースコードは一切無くなり、Travis CIにも対応し、さらにリファクタリングまでして、最初の状態と比べたら生まれ変わったと言ってもおかしく無い位のレベルまで改善されました。Techwaveさんの記事にして頂いてから２週間で全て起きた事です。

Spika Hackathon に参加してきた

上記のブログに主に何を改善したか書いてあります。

さらにVagrantにも対応したので、"vagrant up"というコマンド一発で開発環境が立ち上がる様になりました。Vagrantがスゲーとか、Composerがスゲーとか、ソース規約テストがウザいけど良い仕事するとか色々書きたいと事は山ほどあるのですが、今回は技術的な話は避けたいと思います。

と言う訳で、公開して、評価されて、酷評されて、いろんな方々にアドバイスを受けたり、実際にコードを書いてもらったりと、２週間で色々なことが起きました。このスピード感が中々心地よいのと、個人的にはまぁ酷い状態ではありましたが、公開するまで気づかなかった事なので、リリースして良かったと思っています。お陰で今まで知らなかった方々と、実際にお会いはしていませんが、やり取り出来ましたし、Webアプリの最新技術を勉強する良い機会が出来ました。ビジネスの話も何件か進んでおります。ただ、全ては僕が代表でうちが小さな会社だったから特に大きなダメージは無かったのだと思います、やはり社会的責任の大きい会社の一部としてオープンソース製品をリリースする際は気をつけた方が良いと思いました。

今後ですが、

• APIの分割化 (10月25日くらいまで )

• プッシュ送信部分の書き直し

• 管理管理画面

を予定しています。

まだPHPコミュニティーの方々には色々とアドバイスをお願いすると思いますが、何卒よろしくお願い致します。

最後に、Spikaを紹介して頂いた方々、良くも悪くも評価して頂いた方々、twitter上で建設的なアドバイスを頂いた@yandoさん、そして、Spika Hackathon でコードを実際に書いて頂いた、@NAKANO_Akihitoさん、@kuzuhaさん、@yuya_takeyamaに心から感謝致します。

上記の変更が終ったら今度はグローバルに展開して行きたいと思っております。今後もSpikaを何卒よろしくお願い致します。

PS.Spikaをビジネスに活用したいとか、社内で利用したいとかある方はお気軽にお問い合わせ下さいー

ロンドンで人気なアプリ10

音楽もですが、これからのインターネットビジネス（って言い方も古いですが、、）とかモバイルのビジネスモデルはローカライズが重要なキーになると思っています。facebookの若者離れが良く言われますが、端末のスペックの向上と、モバイル通信環境の高速化、それに合わせてソーシャルアプリの変化も加速している気がします。常に新しい物が出続け、飽きっぽい若者は数ヶ月前に流行ったアプリなんぞ目を向けずインストールしては消されて行くのではないでしょうか。

その中で毎日立ち上げてもらう為にはただ新しい、流行っているだけでなく別の訴求ポイントを持つ必要があると思います。色々あると思うのですが、ローカライズは個人的に重要なポイントになって来ると思います。ただ言語を訳すだけのローカライズでなく、その地域に合った使われ方、機能のローカライズって言うんですかね。。。そんな所に注目しています。香川県民しか分からないようなうどんの写真共有アプリとか。。こう言うと凄く安っちい感じですが、漠然とそんなイメージを持っています。

そんな事を考えていたらこんな記事を見つけたので紹介

ロンドンで愛されているアプリ10個 (http://thenextweb.com/uk/2013/06/02/londons-top-10-mobile-startups/)

AppStoreのトップ10とかでなく、愛されているアプリです。こういう情報は住んでいないと分からないので、凄く参考になります。まぁいちいちここで一つ一つコピペしても意味が無いので、興味がある方は元記事を見て下さい。

地域に根ざしたアプリ、ニッチに始めてグローバルに育てるというモデルがやり易い形になるかもしれませんね。

クロアチアのスタータップ紹介 - BabyWatch

先週にうちのスタッフがこれ http://inventures.eu/shift-conference-puts-split-on-the-startup-map に参加してきてボロボロの結果だった訳ですが、そこで1位に取ったスタートアップの本気度が凄かったので紹介します。

http://babywatchome.com/

超音波センサーをiPhoneのイヤホンジャックに接続して胎児の状態を自宅で見れるという。。。クロアチアと言う辺境の地でもこういう事やってる事を知ると世界を見ると山ほどすげーアイデアを持っているのに資金が足りなくて諦めている人たちは山ほど居るんでしょうねー、インドとかも凄そうですよね。

Squareもそうですが、この仕組みは結構面白いなぁと思って調べてみたら意外と簡単に実現出来そうですね。

http://web.eecs.umich.edu/~prabal/projects/hijack/

イヤホンジャックから電源とI/Oを提供するブリッジみたいなのもあるみたいでして、ちゃんとググれば結構安く手に入るのではないでしょうか。

AppCrawlrが結構すごい

膨大な量になりつつアプリですが、自分が面白いと思うアプリを探すのも一苦労というか探す事自体がめんどくさく、新しいアプリを探すくらいであればソーシャルゲームに500円位課金して暇をつぶした方が楽なのですが、本業となるとそうは行きません。

http://appcrawlr.com/　はストアが用意しているカテゴリーの枠に加えて独自のタグ付けを行いストアに用意されていないカテゴリーでアプリを探す事が出来ます。一言で言うと「タワーディフェンス」ゲームを一覧で見れるサービスです。AppStoreはまだましですが、GooglePlayのカテゴリー分けは酷いですよね。ゲームのカテゴリーを決めた人間はゲームに何か恨みでもあるのかと思うのですが、それを奇麗に整頓してくれます。カテゴリー分けも「ダイエット」「貯金」「子供向け」「ひまつぶし」等、ニーズ毎に整理されていてます。デザインでかなり損していると思うのですが、個人的にはかなり重宝しています。ぜひお試しあれ！

スマホアプリ開発のオフショア発注先を選定する6つのポイント

　初めましてクローバースタジオ代表の安江です。弊社クロアチアのザグレブという場所で日本向けにスマホアプリの開発を行っております。設立して4年になりますが、私自身は経営者であり、エンジニアであり、ブリッジでありと何でもやってますが、今日はブリッジSEとして今までやって思った事を書きます。

オフショア開発ですが、日本に居た頃（もう10年も前になりますが）と比べると小規模開発でも選択肢の一つとして上がってくる様になったと思います。ただ海外との取引となると二の足を踏んでしまう方が多いと思います。この記事はそのような方に少しでも役に立てばと思い書いています。

１. 内製 >> 外注=オフショア
　いきなりオフショア否定ですが内製出来るだけのリソースと資金があれば内製に勝る物はありません。オフショアで開発を回せるだけのノウハウの取得が目的であれば話は別ですが多少エンジニアのスキルが低くとも内製できるのであれば迷わず内製にして下さい。ただ、日本国内の外注とオフショアを比べると余り違いは無いかと思います。コミュニケーションはどっちにしろメールかスカイプだと思いますし。実際に会って物事を進めるメリットと言う物は余り無いと感じています。

２.日本語で直接やり取り出来るブリッジが居るか

　日本語の話せる外国人ではなく普通に日本語でやり取りが出来るかと言う意味です。アプリ開発はそもそも仕様書を細かく決めても余り意味が無いので直接言葉やメールで仕様を決めながら進めるのが普通です。その際に言葉の違いを気にしながらやり取りしてるとそれだけで疲れてしまい、細かい仕様のずれは「まいっか」となりがちですが、まいっかでは済まない場合もあるので、最初から日本語で安心してやり取りが出来る所を探しましょう。

３.エンジニアがいる
　「は？」って感じですが、発注国内でさらに外注のヒエラルキーを辿ってしまう事もあります。そうなるとプロジェクトの成功率は間違いなく０となり担当者の睡眠時間の確保は絶望的となるでしょう。一度社内プロジェクトをインドに発注して安く押さえようと思ったのですが向こうにも営業会社みたいなのがあり、さらに開発会社に発注しているようだったのでキャンセルした事があります。Webサイトの写真には200人以上のスーツを来た人たちが写っていたのですが、やはりちゃんと現地に行って確認するのがベストだと思いました。

４.担当者がシステムを分かっているか
　担当者が営業畑出身となると抽象的な話しか出来なくなり、メモリ管理の話とか、ネットワーク関連の細かい挙動などの仕様を詰める事が難しくなり終盤の詰めが甘くなってしまいます。担当者はコードを理解している必要は無いですが、コードレベルでの話を少なくともブリッジとして全う出来るだけの知識は必要となります。

５.コードの所有権は自分たちの物になるか
　なんとなくNDAだけ結んで進める事が多いいですが、これだけは先に確認しましょう。コードの所有権が無いとバグの修正がにっちもさっちも行かなくなった際に完全にお手上げ状態となります。所有権だけでなくgitで常に進捗確認する事も明言しておいた方がいいです。

６.デイリーで進捗出来るか
　アプリ開発は仕様を決めずに進める事が普通なので、プログラマー自信が脳内補完して進める事が多々あります。それ自体は規模の差はあれある程度は仕方の無い事です。ただ、間違った方向に進めてしまった際にどの方向修正のタイミングが遅くなると無駄な作業を進めてしまいエンジニアのモチベーションを下げてしまう事になります。で、最終的に行き着くのは毎日ベースの報告と確認にどっちにしろなります。担当者もシンドイですがどっちにしろそうなるので最初からデイリーの進捗会議は可能か確認しましょう。

オフショア開発のプロセス全般に対して書こうと思ったのですが、思ったより長くなってしまったので、選定する際のポイントだけにしてこの辺で終了します。次回はオフショア開発でのプロジェクトの進め方に関して書こうと思います。

テスト

とりあえず書いてみるテスト