考察

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

皆さんこんにちは、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です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OYOYO-PROJECTはウェブサービス(ウェブアプリケーション)を開発するサークルですが、メンバーは僕一人です。

一人でアプリケーションを開発・運営することについて考えてみたいと思います。

やらなければいけいないこと

ウェブサービスの開発は通常複数名のチームで開発することが一般的です。

  • プロデューサー/ディレクター
  • デザイナー
  • フロントエンドエンジニア
  • バックエンドエンジニア
  • ネイティブアプリエンジニア

プロデューサー/ディレクター
プロデューサーやディレクターと呼ばれるメンバーは全体の統括、スケジュールの管理、マネジメント等、アプリケーションが円滑に運用出来るように各所の面倒を見る担当です。アプリケーションの宣伝なども担当します。

デザイナー
名前の通り、ウェブアプリ、ネイティブアプリのデザインはもちろん、サービスの全般的なデザインを担当します。

フロントエンドエンジニア
皆さんがブラウザでアクセスする「WEBページ」を担当します。WEBページを使いやすく、見やすく、PCでもスマートフォンでも綺麗に表示できるようにするのがフロントエンドエンジニアです。

バックエンドエンジニア
皆さんが直接見ることはありませんが、例えば皆さんがSNSに投稿した日記のデータをDBに保存させたり、それを検索して表示出来るようにしたり、不正なアクセスが出来ないように、セキュリティーを考慮しながらデータを加工するプログラミングを書き、サーバーの維持・管理を行います。

ネイティブアプリエンジニア
スマートフォンなどでウェブサービスを使いやすくするために、ウェブサービスに「アプリ形式」の玄関を作るエンジニアです。
iPhone向け、Android向けのアプリを開発します。

と、このように、ウェブアプリケーションというものは通常4〜5名、最低でも2〜3名で開発を行うのが一般的です。
(あくまで一例として上げたものですので、上記に沿わないウェブサービスもあるかと思います。)

しかし、OYOYO-PROJECTは一人で運用しているわけなので、1人で全ての役割を行う必要があります。
でも、僕はいわゆるスーパーハカーではありませんし、超人でもないので、到底全ての役割を完璧にこなすのは無理です。
じゃあどうすればいいのか。

「すべての役割を完璧にこなそうとはしない。必要最低限、出来ない部分は切り捨てる。」

はい。最低限の実装、不必要と判断できる部分は切り捨てる。
これしか方法はありません。
ではどこを切り捨てればいいのか。

「セキュリティ、アクセシビリティ、ユーザーエクスペリエンス」

ウェブサービスには大きく3つのセクションがあると考えています。

まず、セキュリティーは言うまでもなく、サービスの安全性です。
データの保存方法、サーバーの運用管理、アカウントのパスワード管理などです。

つぎにアクセシビリティ、つまりアクセスのし易さ、PCでもタブレットでもスマホでもフィーチャーホンでも、何でもアクセスできる。これがアクセシビリティです。

そして、ユーザーエクスペリエンス、ユーザー体験、ユーザーがウェブサービスを使った時に喜んでくれるか、楽しんでくれるか。
主に見た目であるデザインや、メニューボタンなど、各種ボタン操作時の演出などです。
この3つの中でOYOYO-PROJECTでは優先順位を決めて実装を行っています。

セキュリティ、ユーザーエクスペリエンス、アクセシビリティの順番です。

セキュリティー
まず、絶対に切り捨ててはいけないのがセキュリティ。
セキュリティの部分では最低限ではなく、標準以上の実装を心がけています。
なのでセキュリティは切り捨てることは出来ません。むしろ付け足す必要があります。

ユーザーエクスペリエンス
ユーザーが一つのウェブサービスを思い浮かべるときのイメージは「ユーザーエクスペリエンス」が全てです。
ユーザーエクスペリエンスが悪い=出来の悪いサービス、という事になってしまいます。
なにせ、ユーザーが実際にウェブサービスを利用する際の「利用体験」を生み出している部分ですので、とても重要です。
しかし、OYOYO-PROJECTは「慢性的人的リソース不足」なので、切り捨てが必要になってきます。
最低限のユーザーエクスペリエンスを保証しつつ、実装上時間がかかる部分、サービスの利用に影響のない部分は切り捨てます。
具体的にはデザイン時に色で悩まない、こだわらない、無駄に画像を作らない。ボタンのクリックイベント等の演出を行わない、などです。

アクセシビリティ
アクセシビリティは門戸を大きく広く開けて、たくさんのユーザーにウェブサービスを利用してもらえるように配慮します。
PC向けのサイト以外にも、スマホ向けサイト、またはフィーチャーホン向けのサイトも準備することもあります。
その他にも、スマートフォンを利用しているユーザーがログイン無しで、簡単にウェブサービスを利用できるようにスマホ用に専用のアプリを準備したりします。
たくさんのユーザーに使ってもらうためには大変重要な項目です。

しかし、アクセシビリティこそ、OYOYO-PROJECTでは切り捨てる必要のある部分です。
セキュリティーを下げて、ユーザーの信頼を損なうよりも、ユーザーエクスペリエンスを下げて、ユーザーの満足度を下げるよりも、アクセシビリティを下げて、利用できる端末を絞るほうが、ウェブサービス全体のクオリティを落とさずに済むからです。

ただ、ウェブサービスを運用しているということは、たくさんのユーザーにサービスを使ってもらう必要があるわけなので、実際は一番手をかけたい部分でもあります。
ウェブサービスは利用してもらえてナンボですので。

というわけで、OYOYO-PROJECTでは

「すべての役割を完璧にこなそうとはしない。必要最低限、出来ない部分は切り捨てる。」

「セキュリティ、ユーザーエクスペリエンス、アクセシビリティの順番で考える」

ことで、一人でウェブサービスの開発を行っています。
ですが、何も好きで一人で開発しているわけではありません。
興味がある方はぜひ、OYOYO-PROJECTに・・・・

次回は一人で開発することのメリットとデメリットを書いてみたいと思います。

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