サービス開発

WEB開発者から見た、Pepperアプリ開発ファーストインプレッション

皆さんこんにちは、OYOYO-PROJECTです。

既にご存知の方が多いとは思いますが、今年、2015年2月にソフトバンクよりヒューマノイドロボット、pepperが一般向けに発売されます。

価格もヒューマノイドロボットとしては破格の値段設定で、ついに家庭の中にロボットが普通に存在する未来がすぐそこまで来ています。

Screen Shot 2015-01-20 at 00.10.31

このロボット、僕にとっての一番のポイントはオープンプラットフォームであるという点です。
開発環境が一般のデベロッパーへ解放されているので、何かしらのプログラミング経験者であれば、比較的簡単にロボットアプリケーションを開発することができます。

さらに、ロボットを所有していなくても、秋葉原にある「アルデバラン・アトリエ秋葉原」へ行けば誰でも、タッチ&トライの開発体験を行うことができます。

今回は普段WEB開発を行っている僕が、pepper開発を始めて感じたファーストインプレッションを書いてみたいと思います。

開発環境
pepperのアプリケーション開発は専用のソフトウェア、Choregraphe(コレグラフ)を使用します。
Choregrapheは一つ一つのモーションや処理があらかじめプログラムされている”ボックス”と呼ばれるアイテムをドラッグ&ドロップするだけで、様々な処理を手軽に実現させる事が出来ます。

Screen Shot 2015-01-20 at 00.13.15

と説明すると、「なーんだ、コード書けないんじゃん」と思われがちですが、実はこの”ボックス”は、ほとんどの場合Pythonで書かれており、ボックスをクリックするとテキストエディタが立ち上がり、そのボックスを実現しているPython コードが表示されます。

Screen Shot 2015-01-20 at 00.16.43

表示されたPython コードを編集してボックスに機能を追加していくことができます。

また、ボックスライブラリには”空のボックス”も存在し、自分で一から書き上げることもできます。

この仕組みは非常にバランスが良く、プログラムを書けなくても、プリセットされたボックスをドラッグ&ドロップするだけで、ロボットを動かすことができる反面、プログラムが書ければ、オリジナルのPythonボックスを作り、自由度の高い開発を行うことができます。

できること
かなり個人的な意見ではありますが、pepperは変に制限されていないです。
この手のハードウェアの場合、開発者がいじれる部分とハードの開発元しか弄れない部分のように意図的にできることを制限しているものが多いと思うのですが、今のところそのような壁にぶち当たってはいません。
Linux(pepperの場合はGentoo)に手足が生えたようなイメージです。
いろいろなことが出来そうで、本当にワクワクしています。

できないこと
しかし、pepperは世界初のコンシュマー向けロボット。
(世界初は語弊があるかもしれませんが、今までここまで完成され、プラットフォームとしてしっかりとデザインされたロボットがあったでしょうか?)

第1号のため、出来ないことは多いと思います。

ハード的制約上、人間より関節が少なかったり、指を一本一本動かすような、細かい動きを作ることはできません。

現状、比較対象になるコンシュマー向けロボットが存在しないので、できないことはあまり浮かんできません。
今後pepperアプリを作っていく過程で、不自由な点は出てくるかと思います。

デザイン
よくある話なのですが、初見で「キモい」と感じる方が多いそうです。
僕の場合、pepperの動きの滑らかさに驚いた部分が大きく、デザインのついて何を思ったのかは正直、覚えてないのですが、キモいという印象は無かったと思います。

pepperと触れ合う時間が増えるにつれて、優秀なデザインだと思うようになりました。
pepperはご存知の通り、ソフトバンクと仏アルデバランとの共同開発ですが、ソフトバンク側でのコードネームが太郎、アルデバラン側でのコードネームがジュリエットと、両者で性別が異なります。ロボットなので性別は無いが公式設定だそうです。

変にキャラクター化されていないということは、後々ソフトウェア的に様々なキャラクターを表現できる事に繋がります。

男の子キャラのpepper、女の子キャラのpepper、ボクっ娘キャラの………

いわば素体のように、味付け次第で様々なキャラクターを表現出来ると思います。

WEBエンジニアとして
ウェブサービスはブラウザからアクセスし、ブラウザがサーバーと通信することで、機能を実現しています。

ウェブサービスの本質はブラウザからウェブページへアクセスして、情報をやり取りすることではありません。
ブラウザがウェブサーバーに接続し、サーバーに溜まっている膨大なデータを加工したり、サーバーのマシンパワーで様々な処理を行った結果を取得できる点です。(バズワードのクラウドを思い浮かべてもらうと分かりやすいと思います。)

今までウェブサービスはブラウザから利用したり、スマートフォンの専用アプリから利用されてきました。どちらも平面的で、受動的です。

ここに新たにコンシュマー向けロボットが加わります。

ロボットはウェブブラウザやスマートフォンとは異なり、人の形をしています。

ウェブブラウザやスマートフォンよりも、かなり人間の近く、ロボットを介することで、ウェブサービスは更にインタラクティブなものになっていくと思います。

アルデバランのブルーノCEOも「ロボットは究極のインターフェース」と言われていますが、その通りだと感じています。

ウェブサービスの新たなUI,UXとして、pepperは非常に魅力的かつ、様々な可能性を秘めていると感じています。

と、いうわけでpepper開発のファーストインプレッションです。
アルデバランアトリエ秋葉原に7、8回お邪魔をし、アプリコンテストに向けて開発をする上で感じたことです。

pythonを全く触ったことがなかった僕でも、楽しくpepperアプリ開発ができているので、とてもおすすめです。

都内近郊にお住まいの方は、まずはアルデバランアトリエ秋葉原へ行って、タッチ&トライに参加してみてはいかがでしょうか。

ウェブサービスをリリースする際の完成度

皆さんこんにちは、OYOYO-PROJECTです。

今日はウェブサービスをリリースする際の、完成度について考えてみたいと思います。

世の中に出回っている製品の殆どが100%、完成された形で出回っています。

ですが、ソフトウェアの世界、特にウェブ上で提供される、委託開発でない、いわゆる自社製サービスの場合殆ど、最初のリリース時点で100%完成されているサービスというのは少ないと思います。

これはソフトウェアと通信という性質上、作成したものをリリース後、いくらでもアップデート出来るという特性も一因ですが、昨今の開発志向である、プロトタイプ的なサービスをローンチし、利用者の反応を確かめながらアップデートしていくことで、最初から作り込んだはいいが、利用者のニーズに合っていない、という失敗を避ける目的もあります。

はじめから製品を100%の状態でリリースせず、あえて20〜30%の状態でリリースし、利用者の反応を確かめつつ、開発を継続するか判断します。

僕も作ったはいいが、誰も使ってくれない。利用者のニーズに合っていなかったという状況はとても辛いので、出来るだけこのような手法を取り入れて開発したいと思っています。

ただ、個人的に思うのは、このような開発志向の落とし穴として、
「簡単なものしか作らない」
「作りこまなくていい」
「プロトタイプ程度のリリースでいい」
と、いうような、開発するサービスそのものが「小さいもの」になり易いのではないかと思っています。

100ページの本を書くための20~30%と、1000ページの本を書くための20~30%では明らかに作業量は異なります。
そして、完成された本のクオリティーも違ってくると思います。
(分厚い本がいい本というわけではありませんが、あくまで譬え話です。)

また、完成度が20~30%でリリースした時のユーザーの反応と、60~70%でリリースした時の反応も異なると思います。
もう少し作りこめがヒットしたかもしれないサービスを、20〜30%でリリースした為に、サービスを殺してしまうということもあるかと思います。

勿論これは開発しているサービスによって異なる事ですので、一概には言えませんが、リリース時の完成度も気をつける必要があると思います。

サービスの完成度を高めることは非常に重要ですが、リリース時にどれくらいの完成度でリリースするのかという、タイミングもとても重要なのではないかと思っています。

という、完成度について考えてみました。

じゃあ、自分はどうなのか。
OYOYO-PROJECTではウェブ上で簡単にビジュアルノベル(ADV形式)が作成できるサービス、「KAGUYA」のリリースを予定していますが、完成度は恐らく、2%程度なのではないかと・・・・
(なんだよ!)

今月リリース予定なので、ぜひご期待ください!

一人でアプリケーションを作るということ②

皆さんこんにちは、OYOYO-PROJECTです。

今回は「一人でアプリケーションを作るということ」の続きを書いてみたいと思います。

前回の記事
一人でアプリケーションを作るということ①

前回、一人でウェブサービスを作るとき

「すべての役割を完璧にこなそうとはしない。必要最低限、出来ない部分は切り捨てる。」
「セキュリティ、ユーザーエクスペリエンス、アクセシビリティの順番で考える」

という考え方を紹介させていただきました。

今回は一人でウェブサービスを作るときのメリット・デメリットを考えてみたいと思います。

一人でウェブサービスを作るメリット

  • 気兼ねなく開発できる
  • 思いついたことをすぐ試すことが出来る
  • 開発レベルを一定に保つことが出来る

一人でウェブサービスを作るデメリット

  • 全ての作業を一人で行わなければならない
  • やりたいことが全て出来ない
  • フルスタック開発を行う必要がある

気兼ねなく開発できる
一人でウェブサービスを開発する最大のメリットはこれです。
一人で開発するということは、開発メンバーが自分しか居ないので気持ちは楽です。
誰かに作ってもらった場所にダメ出しをし、作り直しをしてもらうのは精神的に辛い部分がありますが、自分しか居ないので、作りなおすのは自分。
ですから、時間が許す限り作り直す事ができます。

思いついたことをすぐ試すことが出来る
思いついたこと、すぐ試せます。
なんせ、自分で作って試せばいいので、やる気さえあればすぐ試すことが出来ます。

開発レベルを一定に保つことが出来る
開発者が自分しか居ないので、開発レベルを一定に保つことが出来ます。
プロジェクトチームの中に、レベルが低い人、極端にレベルが高い人が混ざってしまうと、コードの品質が一定に保てないものですが、自分しか居ないので、レベルも何もありません。逆に自分がレベルアップしなければコードの品質は下がる一方です。

そして、ここからはデメリット
全ての作業を一人で行わなければならない
一人しか居ませんので、すべての工程を一人で行う必要があります。
ウェブデザイン、サーバー周り、フロントエンド開発、バックエンド開発、ネイティブアプリ開発など、一つの事に集中して開発を行うことが出来ません。
また、個人的に僕の場合ウェブデザイン→バックエンド開発など、作業の切り替えが得意ではないので、作業を切り替えるときロスタイム時間が発生していしまいます。

やりたいことが全て出来ない
やりたいことを全て行うことが出来ません。
複数の作業工程が待ち構えているため、一つひとつの工程がどうしても「浅く」なってしまいます。
ですから、クオリティーコントロールがとても難しいです。
(まあ、半分言い訳のような感じですが。)

フルスタック開発を行う必要がある
これはデメリットなのか微妙な所ですが、結果的にフルスタック開発を行う必要があります。

「ウェブデザイン、サーバー周り、フロントエンド開発、バックエンド開発、ネイティブアプリ開発」

一つのことに集中して開発することが出来ませんので、実装面でも技術面でも「広く、浅く」なり易いです。
フルスタック開発というと何やら凄いことをやっていそうですが、僕の場合「広く、浅く」ですので、一つのことに特化している方に比べると、技術面では雲泥の差です。

というわけで、今回はメリットとデメリットを無理やり上げてみました。
次回は、ネタが浮かんでいませんが、このシリーズをもう少し続けます。