読者です 読者をやめる 読者になる 読者になる

ボクココ

サービス開発を成功させるまでの歩み

ブログを書き続けられる素質について

雑談

ども、@kimihom です。

ブログってのは誰でも始められる反面、記事を書き続けることが非常に困難で大抵の人は挫折してしまうことだろう。続く人はどうやって続けられるのか、私の場合について書いてみたいと思う。

ブログを書くことは教えること

"読まれる"ブログを書くことは独り言であってはならない。自分が持っているものを相手に教えることができてこそ、価値あるコンテンツになる。私は教えることが好きだからここまで続けられてきたと思っている。自分の書いた記事が Web 上のどこかにいる誰かの参考になり、その人の考えが整理されたり課題を解決できたりすることができれば私は記事を書いてよかったと感じることができる。

ちょっと個人的な経験をお話しする。

私は昔から、教えることが好きだった。中学の時に塾に通っていたから数学で先生よりもわかりやすく説明できる自信があった。だから数学の授業が終わってから黒板の端っこで友達に数学を教えていた。それがきっときっかけだったのだろう。友人がきちんと聞いて理解してくれて「なるほど〜」と言ってくれた時に得られる喜びや感動があった。その中学の友達とは今でもそうした個人授業の話で盛り上がったりすることがある。

大学に入ってから塾講師をすることになった。もともと中学数学はかなり自信があり、教えたいと思っていたので私には天職のようなバイトだった。でも、そこにいたのは中学時代の目を輝かせていた友達ではなく、親に仕方なく言われてきているやる気のない生徒たちだった。なかなか教えるのにも身が入らなかったりした。でも私はその時、一つ大事なことを気付いた。給料のために働くバイト程度の感覚で生徒を本当に教えることなんてできない。私が中学の時、なぜ私の友人たちは私の話を一生懸命聞いてくれたのか。それは私が本当に教えたいという情熱を友達が受け取ってくれていたからだと気付いたのであった。そうした思いがなければ、休み時間を割いてまで教えようとなんてしないだろう。てことで、塾講師でも必要なことは、知識ってのもあるけれど、それよりも生徒に教えたいという情熱を感情や口調で表現できるようになることだと私は思った。実際、それを意識すると本当に目を輝かせて勉強してくれる生徒もいたし、もちろんダメだった生徒もいる。それはまぁ人それぞれだけど、受け取ってくれる人はいるってのをそこで学んだ。

ブログで書くことも同じことなのだろう。私が情熱を持って書いた記事はきっと誰かの心に響く。それが全員でなくてもいい。私の中学時代の友達、塾の一部の生徒のように、この記事を読んだ誰かの心を動かし、得られるものがあればそれがブログの書く意味なのだ。

教えた先に得られるもの

教えた先に得られるものはなんだろう?アフィリエイトによる金?そんなのちっぽけだ。それを目的にしたらこのブログなんてとっくに終わっている。

私は Web の何処かにいる誰かが記事を読んだことでわかった!という感動を届けられればそれでいいと思っている。本当に興味のあることを読んでいる時ってのは、人は誰でも目を輝かせる。私はそんな人に何かを教えていいのであれば、何時間でも教えてあげたいと思う。まぁ、そこまで私が教えられることってのもそんなにはないけども。

その目的の達成に必要なのは、私の情熱が記事に反映されていることである。だからこそ私の記事は必ず自分の意見を書いているし、なぜそう思ったのかまで書くように心がけている。その熱い心こそ、読む人の目を輝かせるものだと信じて。

全員が満足する Web サービスを開発することができるのか

スタートアップ

ども、@kimihom です。

前回書いた、Web サービスは機能の多さで勝負してはならない は多くの反響をいただいた。

その記事では、機能を多く追加することによってサーアビスのコアを見失い、尖りを持たないサービスになることを懸念した。サービスはコアを突き詰めることで、本当の強みを得ることができる。

ここで特に日本中、世界中で使われるサービスにしていきたいと考えている方にとっては、そんなんじゃあダメだと思われた方もいるだろう。ではどうしたら全員が満足できるサービスを開発・提供できるのかを考察する。

シンプルベースでカスタマイズ性を突き詰める

まずサービスの全体像は必ずシンプルにすること。そのシンプルは自分たちのサービスのコアとなるものだけを提供する。ここまでは変わらない。んでその中でもっと便利に使いたい、こういう機能が必要という人がそのうちの30%がいたとする。彼らは設定項目をいろいろいじって機能をより便利に使うことに熱心な人たちだ。彼らにはより細かい機能が使えるようなオプションをひっそりと用意してあげることが策として一つ存在する。

ただ間違っても開発エンジニアはその細かいオプション機能に時間を割くよりも、メイン機能を極めていくことのほうが大事であることは忘れてはならない。そうした30%の人たちのために開発時間を注ぎ込むより、100%の人がもっと満足する機能の改善に注力すべきだ。

なので、この方法はできなくはないが、あまりクールな解決策とは言えない。

機能を外部の開発者が利用できるようにする

サービスのコアを磨き続けつつ、ある人にはこの機能、ある人にはこの機能といったカスタマイズ性をどのように提供するか。その究極が API の公開 だと私は考える。

私たちコア機能を持つサービスは API を通じて外部に機能を提供し、外部開発者の好きなように私たちの機能をカスタマイズできるような環境を用意してあげる。私たちは APIで拡張できる環境さえ用意すれば、サービスのコアに集中することができる。

拡張機能が欲しい人がいれば、外部の開発会社などに依頼して API を使って拡張するようにすればよい。さらに、その外部の開発会社はその資産を使って他の企業にも同様に拡張機能として売り出すこともできれば尚よし。

ただこの策には一つ決定的な課題がある。それは外部の開発者がそのサービスを気に入って、自分たちが拡張しようという気概を持ってもらわねば、APIを公開しても誰も使われないオチになるという点だ。APIを公開したものの、結局 顧客からの要望は増え続けて自分たちが対応しないといけなくなったりする。

だからこそ API を提供してメインビジネスをやろうとしている会社は外部の開発者に寄り添うようになる。開発者が心地よく開発してもらうようにたくさんのノベルティでエンジニアを誘惑するわけだ。API ビジネスはそこに大きな労力を割く必要が出てくる。日本のエンジニアはただでさえそんなに多くないし、こうしたAPIの考え方に共感できるレベルのエンジニアがそこまでいないのが大きな問題な気がする。

この方法を成功させるには2つのどちらかを満たしている必要がある。外部開発者が儲かると思えるほど自社プラットフォーム側で大量の顧客を持っている場合か、その API を外部開発者が導入すればより自社のサービスがよりよくなると確信できるほどのものである場合か、である。

自分たちが API 連携の実装をする

開発する機能が自分たちのコアの機能ではないとしたら、そこに時間をかけるべきではない。かといって第三者の開発者がそんなにすぐに自社の API を使ってもらえるとも限らない。そういう場合は 自分たちが積極的に外部サービスのAPIを利用して拡張機能として顧客に自由に追加できるような環境を用意しよう。

強力なコア機能を持っているサービスが連携すれば、その連携先はとても歓迎してくれる。というか感謝される。一緒にイベントとかやりましょうとか、開発者として発表してくださいとか割と良い関係を築くこともできる。自分たちが API を公開して満足するというよりは 自分たちの API を公開しつつも 自分たちのコアでない機能は外部連携を実現して強くする という方針が良いのではないか、と思う。

他のコア機能を持った良いサービスと良い関係を築くことは、良い信頼関係を生み、良い顧客を呼んでくれる要因にもなる。そうして私たちはまたコア機能の改善に注力でき、さらなる素晴らしいサービスに磨き上げることができる。

終わりに

自分のサービスだけで全員を満足させる、というのは不可能だ。だからこそ他の良いサービスとうまく協働し、エコシステムとして顧客毎に合うような運用ができるように連携・セットアップしてもらうのがいい方法になる。

顧客の要望に全て答えることは一見いいことをしているように見えるかもしれない。しかし、それは他の顧客、シンプルさが気に入っている顧客を不満足にさせる結果につながる。しっかりと自分たちのコアを見つめることができれば、要望を切り分けて"作らない"という英断を下せるような体制を築くことができるだろう。それがゆくゆくは"全員が満足する Webサービス"となることができるのである。

「風立ちぬ」を見ての感想

書評

ども、@kimihom です。

さて今回は風立ちぬって映画を見たので、それについて思ったことを書いてみる。タバコ吸いすぎだが、いい映画だった。

風立ちぬ

風立ちぬ

以下は私が受け取った感想ってだけなので、まぁあんまり深く突っ込まれたりすると困るので気軽に読んでいただけたらと思う。

"矛盾"

私がこの映画で一番しっくりきた言葉が「矛盾」である。主人公の同期でライバルである本庄が雑談めいて話していた矛盾についてだが、この映画全体に言えることのように思えた。

P.S. この記事書いた後に調べてみたら、宮崎監督自身が「矛盾」って言葉を使ってこの映画を表現していて、びっくりした

その矛盾に対する自分の答えを、宮崎駿はそろそろ出すべきなんじゃないか。僕はそう思った。年も年だし。これはやっておくべきじゃないか、と」(2013年5月9日、東京新聞より)

私が宮崎アニメで一番すきな"耳をすませば"と、この"風立ちぬ"はかなり大きな相関を持っているように思う。"耳をすませば"では、自分の信じる道を生きるその美しさを私たちに教えてくれている。しかし、この"風立ちぬ"は、夢を追い続けることで失ってしまう代償のようなものをリアルに描写しているように見えた。

この映画の最大の矛盾は、彼は純粋に飛行機を作りたいのに、それは戦争に使われるということだと思う。自分が作りたい飛行機を作ったら、それはたくさんの人を殺してしまうのだ。それでも彼は飛行機を作ることを選択した。そして妻が結核という難病を患っていたのにも関わらず、彼は仕事に打ち込んだ。それほど彼の夢への意識は強く、空を自由に飛ぶ飛行機の設計士になりたいという思いに向かって忠実に動いていたのだ。

しかし、大きな夢を実現した(最後のシーン)瞬間、今まで大切にしてきたものを失ってしまったことに気づく(妻や飛行機に乗った人々)。それはもう終わったことで戻ってくることはできない。夢に向かって突き進んでいった結果、同時に多くの人を亡くしてしまったのだ。その矛盾に対する悲しさや現実と向き合って、それでも生きねばならない。私にとって"風立ちぬ"はそんな映画だった。

私が大好きなシーン

風立ちぬの後半はそりゃあもう悲しい悲しいの連続なんだけども、その中で私がとても大好きな1シーンがある。それが、主人公の彼が主催となって開催した「自主的な勉強会」だ。その空間にいる人たち全てが目を輝かせ、未来の理想の飛行機について語り合っている。彼らの目的は「いい飛行機を作る」それだけであり、その先どんな使われ方になろうとかは一切存在しない。男たちの夢とロマンが詰まったあのシーンはこの映画で最大の見所だと思う。こちらもワクワクするし、あのシーンで得られるワクワクな心こそ、夢に向かって突き進んでいる状態そのものような気がしている。夢を見つけ、何かに夢中になった時に得られる高揚感をあのシーンでうまく表現されているように見えた。

私が抱える矛盾

さて現実に立ち返って、インターネットの世界に生きる私の矛盾についてもちょっと触れておきたい。

「インターネットは人々の生活をより便利にした」とはよく言われる。確かにインターネットで人と人との距離は劇的に短くなったし、今までやっていた作業は全部自動化され、あらゆるものがコンピュータに置き換わった。

しかし、私はインターネットこそが現在の不況や格差を生み出している根幹のような気もしているのだ。今までコンピュータがなかった時は、その作業を「人」がやっていたわけで、それだけで仕事がたくさんあったのだ。それが全部コンピュータに置き換わった今、その人たちがやれることっていうのはどんどん失われているし、今後もロボットが台頭すればますます格差は広まっていくだろう。

そんな中で私たちは常にイノベーションという言葉を使って、人々の生活を変えようとしている。その変わった先にあるのは、便利になったという明るい話の反面、その裏でたくさんのものを失うこととなる。

それでも私はやらなければならないというか、やりたいのだろう。主人公が空へ抱いていた希望のように、私も私が作ったサービスでたくさんの人に影響を与えたいと思っている。それこそが彼が空に描いていたロマンのように、インターネットが存在するのだから。

"生きて"。風立ちぬで最後に放たれる言葉だ。色々な矛盾と戦いながら、私たちはこれからも生きていかねばならない。

制約のあるところに創造は生まれる

雑談

ども、 @kimihom です。

最近その通りだなーと思う言葉の中に、「制約のあるところに創造は生まれる」という言葉がある。これを最初に耳にしたのは、意外にも高校サッカーでの記事だった。

「制約があるからアイディアと工夫が生まれる」、初4強・國學院久我山の逆転の発想(小澤一郎) - 個人 - Yahoo!ニュース

私たちの現在の働き方 (資金調達や人材の確保などをせず、自らの限られたリソースの中で最大限のプロダクトを作る) というのに非常に似ていると感じ、共感したのを覚えている。

あらゆることにおいて大事なのって、「自分で考える」ってことだと思うのよね。何もしなくても満足できるような十分な環境では、"考える"ということを放棄してしまう。主体性とでも言い換えられるかもしれない "考える"っていう行為は教育によって鍛えなければならない最重要課題だと私は考えている。自分で考えることができれば、自分が何をしなきゃいけないのかが他に左右されずに的確に決めることができる。"意思決定を自分でできる"っていう力は、どんな仕事でも、どんな場面でも活躍する貴重な財産なのだ。

その上で、制約があれば創造(自分で考える)が生まれるのであれば、その制約を積極的に課すべきなんじゃあないかと思った。

Web サービスにおける制約の効果

私が Web サービス関連の仕事をしているので、サービスにおける制約とも照らし合わせてみる。

Web サービスにおいて最も(と言っていいかはわからないが)制約を課しているのは Twitter の 140文字制限だと思う。と言っても日本語だと140 文字もあればかなり言いたいこと言えるので、あまり問題になっていないかもしれない。しかし英語で140文字制限はスペースも含んでの計算になるのでなおさらクリティカルな制約だ。それでも Twitter の原型を生み出し、一旦は Twitter から追い出されながらも去年復帰した Jack Dorsey は以下のように述べている。

Jack Dorsey曰く、Twitterは140文字制限を維持する | TechCrunch Japan

Twitter はそもそもあらゆる制約から生まれたサービスだ。ことの発端は2 週間でサービスのプロトタイプを作るという社内ハッカソン的な取り組みの中で、 Jack と Biz の2人が Twitter の原型を作ったのだった。これも 2週間という制約や 2人という制約があったからこそサービスの核心だけを突き詰められたと言えるだろう。後に Twitter で正式な機能として作られた、ハッシュタグやメンションの機能も、ユーザーが制約の中から自ら使い方を見出し、普及していった創造の機能に過ぎなかった。それを Twitter が後に正式に機能として提供したのが現在なのである。

ユーザーは制約があったとしても、その制約の中でより便利にするにはどうしたらいいか考えることができる。むしろその"考える"ってプロセスがサービスを使う上でより面白くさせる一つの要因だとも思う。制約のないなんでもできるサービスってのは、概して大量のオプションやマニュアルが必要となり、ユーザーは自分で考えるのではなく、その方法を学ぶというプロセスが必要になる。どちらが好きかといえば、大部分が前者であることは間違いない。

終わりに

人は何か課題があれば解決したいと思うもの。現代はあらゆるものが解決されすぎていて、自分で考えるということがしにくい世の中になっている。困ったらインターネットで検索すればいいし、欲しいものがあればネットで買うことができ、寂しくなったら SNS を見ればいい。

こんな便利すぎる世の中で必要なのは、「自分からあえて制約を課す」という考え方なのではないだろうか。私は"ストイック"という言葉が好きなのはそこにあるような気がするのである。

JavaScript SPA 周りの議論で出た私なりの答え

Rails JavaScript

ども、@kimihom です。

ここ最近、ずっと React.js か jQuery かみたいな話題が定期的に持ち上がってきている。事実、私も最近の JS ライブラリの人気に疑問を呈した人物の一人である。この記事を書いたのも1年前か。

なんだかんだで SPA から jQuery に戻った話

そして、現在も jQuery(厳密に言えば jquery-rails) でアプリケーションを書いている。そしてその決断を特に後悔したことはない。本記事では、よく聞くReact とかに移りたい理由をもとに、私なりの回答を記すことにする。

jQuery の DOM 地獄から解放されたい

「jQuery で DOM 操作なんてもうしたくないんです」これこそ React や Angular を使う最大の理由であることが多いかと思う。確かに jQuery の DOM 機能は頑張ればいろいろなことができるので、無法地帯になりやすいという性質を持っている。

だが私が思うのは、 jQuery で複雑な DOM 操作なんてする必要がないということである。そもそもの発想として、JavaScript で状態管理をするという考え方自体に問題があるのではないか。状態を保っている根幹はサーバーにあるDBであり、それを無理にフロント側で持とうとするから大変なことになる。Web の特徴として、"常にオンラインであること前提でいい"というのがあると思う。オフライン対応の Webアプリケーションを作るという話はなしということにとりあえず同意していただいたとして、そうすれば常に最新情報が取ってこれる前提で物事を考えてよいことになる。

となると大活躍する Rails の View オプションは、remote: true だ。これを a タグや button タグ、 form タグなどで追加するだけで Ajax 化できる。さらにそのイベントは ajax:successajax:beforeSend, ajax:error などで結果をキャッチできる。

するとどのような実装ができるかというと、レンダリングは常にサーバーサイドで行うことができる。jQuery でやるべきことは、 Ajax でリクエストを送り、帰って来た HTML をそのまま html(response.body) と言った感じで描画すればいいのだ。そうすれば面倒なDOM操作なんて一切必要なく、 Rails を使っているのであれば html.erb で動的なレンダリングを実現できる。今回のサンプルは Turbolinks を使わない場合のパターンだが、 Turbolinks でもほぼ同等のことが可能だ。Turbolinks を使えばデフォルトで HistoryAPIも備わっているので、戻るボタンも簡単に実現できる。ちなみに私は自前で History API を使って実装した。

Rails を使っている人たちはぜひ一度、なぜ Rails は jQuery を今でも採用し続けているのか、なぜ Controller を生成した時にCSS, JS ファイルも一緒にできるのかを考えてみて欲しい。私なりの答えを書くとRails のレールに乗りながら SPA を作るなら、以下のようなコードになるのではないかと思っている。頭の中で書いただけなので動作保証はしないので注意。

- layout
<div id="base">
   <%= link_to "Ajax!", remote: true, class: "getUsers" %>
    <div class="wrapper"></div>
</div>

- controller
class UsersController < ApplicationController
  layout false

  def index
    @users = User.all
  end
end

- view
<div id="userCtrl">
  <ul>
    <% @users.each do |u| %>
        <li><%= u.name %></li>
     <% end %>
  </ul> 
</div>

- css
#userCtrl {
  # userCtrl だけに適用する CSS
}

- js
$(function() {
  $(document).on("ajax:success", '#userCtrl .getUsers', function(q, data, xhr){
    $("#base .wrapper").html(data);
  });
});

私はこの開発方法を見つけた時、実に美しいと感じた。それぞれの影響を最小限に抑えつつ、 Rails の View を完全に活用して jQuery としての SPA を実現できた、と思った。そして今もなおこの方法で DOM 操作をほとんど行わず、 Rails の View をうまく活用することで Rails のレールに乗っている。こうすれば Rails のレールに乗りながら SPA を簡単に作れる。DOM なんてのは一切出てこないし、フロントエンドでの状態管理も存在しない。複雑な JavaScript コードとはおさらばできる。

Rails で AssetPipeline を使わなかったり、 jQuery じゃなくて React-Rails みたいなものを使っている方は、上記の jquery-rails の使い方を知った上で そのような選択をしたのだろうか? 自ら進んで Ruby on Rails からの レールを外れるという選択をした方には、それなりの苦労が必ず発生する。 Rails の思想と反する行為をしているわけだからね。

スマホとかタブレット、IoT 機器とかと統一した APIを中心としたアーキテクチャにしたい

私もこの考え方がすごい好きだった。 Web ってのはあくまで端末の1つに過ぎず、 API がすべての中心となりサービスの根幹となるものであると考えていた。確かにその考え方だと上記方法は利用することができず、 SPA フレームワークを使わないといけない。

ただ、 Web とその他で圧倒的に違う点が一つある。

それが先ほど申し上げた「Webはオンラインであることが保証できている」という点である。だからこそ常に最新のHTMLコードは ブラウザ側でなくサーバー側で持っていられるようになるわけだ。これがスマホとかだとそうはいかないので、スマホ側でうまくアプリないDBとかに保存して描画したりする必要が出てきてしまう。

API に関して言えば、そんなに機能が複雑になることはないだろう。だから そこはそもそも Rails である必要もないだろうし、別で作るべきだと思っている。同時接続とか多くなるだろうし。

終わりに

今回の話は Rails に限った話であり、例えばそもそもバックエンドがシンプルな Node.js の Express などを使っているのであれば、 SPA を選択してフロントエンドゴリゴリで頑張るという考え方もあると思う。本記事はあくまで Rails にレールを乗って SPA を作るための提案の1つである。

Web サービスは機能の多さで勝負してはならない

スタートアップ

ども、@kimihom です。

近年はいろいろなサービスがあるが、サービス開発者の中で勘違いしやすいのが 「機能は多ければ多いほどいい」「他社サービスがこんなことやってるからウチもやらないと」「お客さんがこんなこと言ってるから実現しないと」 といった考え方だ。自分たちのサービスにその機能は本当に必要なのかを考えず、ただ闇雲に機能を追加していく。その行く先にあるのは「複雑で、誰も使いたがらないシステム」である。理解するのに、慣れるのに何日間もかかるようなシステムを誰が喜んで使いたいだろうか?残念ながら、今の日本のサービスはそんなのばっかりだ。

なぜこのような考え方が生まれるのか

機能を闇雲に追加していくことのメリットは、「自分が何も考えなくてもいい」ということだ。他社のを参考に、ユーザーの意見を参考に言われるがままにパクって作ればいいだけなのだから。多少は自分たちのサービスっぽくカラーを添えるだけで OK、しかも実装には時間がかかるしリリースすれば仕事をした感じがする。自分たちが頑張って作ったから、きっと使ってくれるよね! っていう自己満が得られる。

その根底にあるのは、全員が喜ばなくても、誰かが喜べばいい。まぁ無いよりあった方がいいよね。 という考え方だ。その繰り返しにより、A機能はあの人には便利だろうし、B機能はあの人に使ってくれるだろうという発想になる。

エンジニアにとっては機能を追加するのは簡単だ。多少はシステムの影響を考える必要があるが、コードを消すことをあまりしなくて良い。ひとまずリリースまで持っていけばビジネス側の人からも文句は言われないだろうという気持ちになれる。

デメリット

割と一般的なこの考え方がダメな理由は3つある。

1つ目は、ほとんどの人はその機能を使わないという点だ。機能が多いほどそのサービスを学習するコストが生まれてしまう。最初から使い続けている人ならついてこれるかもしれないが、途中から入ってきた人があまりに多すぎるメニューのどれを使わなければならないのか困惑させてしまう。その時点で「嫌々そのサービスを使っている」ということになる。ぶっちゃけ BtoB とかだと会社でこれ使うと決まったから、とかそういう理由で使わさせられているから文句を言えずにやっているという現実もあるのかもしれない。でもそんな Web システムを使って仕事をして幸せになるのは誰だろうか?

2つ目は、メンテナンスコストだ。先ほどエンジニアにとって追加は簡単と言ったが、今後ますます機能を追加して行った時に、それらが絡み合ってどこがどうなっているのか把握できなくなるという問題がある。後から入ってきたエンジニアがそのカオスな機能だらけのシステムをメンテナンスしろと言われたら翌日には退職したくなるだろう。それほどまでに複雑になりすぎたシステムをメンテナンスするのは困難なことだ。それでいて開発よりもテストに時間をかけるようになってしまい、開発速度がどんどん遅くなっていく。最終的には根幹の機能なんて絶対に手を出せないようなシステムが出来上がっていく。残業を増やしているのは、自らが作り上げたその複雑なシステムのせいだと気付いた頃にはもう手遅れなのだ。

3つ目に自分で考えるということを放棄しているという点だ。他者から意見をそのまま機能に反映すると、一見考えているように見えて、そもそもの「なぜこのプロダクトはあるのか」を考える習慣がなくなってしまう。例えば、「人々の健康をよりよくするアプリ」を開発しているのに、いつの間にか「アプリを起動してほしいから占い機能を追加しよう」みたいな愚行にも同意してしまったりするのだ。"そんなことしないやろ"と思っている方、こういう話がマジであるので気をつけていただきたい。私はそれを経験して、自分で作るプロダクトは絶対に芯を曲げたくないと思ったのだ。自分たちが実現したい世界は何なのか、これを持っていないとユーザーを困惑させる機能ばかりを作ってしまい、しまいにはサービスに共感できなくなってユーザーが離れて行く結果となる。

じゃあ何で勝負するのか

それは、自分たちが一番強みとできる機能の開発に集中することだ。例えば自分たちが画像処理に強みがあるのなら、画像処理の精度を上げることに最大の努力を払うことだ。それに時間をかければかけるほど、他社はそのクオリティを生み出すことができなくなる。その道を踏み外して SNS 機能とかを実装し始めると、そのサービスはもう他のサービスと同じようなサービスになってしまうのである。

自分たちが本当に勝負したい機能を究極にまで磨いていく。その熱意こそが素晴らしいサービスを生み出すのである。 Google の "検索" のようにね。

スタートアップの可能性

逆に考えると、今の日本の IT には複雑で多機能すぎるサービスで溢れているからこそ、私たちスタートアップでもシンプルさとコアの最高なメイン機能を武器にして勝つ可能性があるということの裏返しでもある。一度でもユーザーに感動を与えられたならば、そのユーザーはずっとそのサービスを使い続けてくれることだろう(意味不明な機能を追加しない限り)。

このことはもちろん理想論に過ぎないことはわかっている。だけど、それを信じられるかで未来のサービスの成功か失敗かは見えてくると思っている。他人や他社にすぐ左右されない、芯の通ったスタートアップが増えれば、きっと素敵なサービスがどんどん出てくると思う。

旅と友達とフェイスブック。

雑談

ども、@kimihom です。

新しい気づきのあったブログをふと読むきっかけがあった。そんな中で自分の思いを雑談っぽく語ろうと思う。

ひとりで生きる強さの裏側には、誰かといられない弱さがある。 - いばや通信

この記事の本文中では以下のような言及があり、この一節が私にとって新しい気づきを得られた。

旅に出る人間は不幸だ。根をはる場所を見つけた人間は幸福で、根をはる場所を探し求めてさまよい続ける自分のような人間は、たぶん、不幸だ。いつでも、どこでも、どこまでも、遠くまで行くことができるという強さではなく、いつまでも同じ場所にいることができない弱さがある。

場所を探し求めてさまよい続ける というのがうまく的を得た表現に感じた。一般的には旅はすべきものという認識が圧倒的に多い。旅をすれば、新しい視野や人との出会い、そして記憶に残る何かを生むことができる。友達と旅をして、写真をたくさんとって、フェイスブックに投稿する。いいねをたくさんもらったりコメントをもらったりすることでその繋がりを実感できる。一般的な"幸せ"というのはそういうことのように感じられる。

しかしその行動の裏には、「現実の毎日が退屈で、どこか現実を離れて飛び出したい。」という気持ちの裏返しであるとも言える。人は日々、もの足りない何かを探して旅に出る。本文中にある 根をはる場所を見つけた人間 とは、私は自分の一生をかけてチャレンジしたいことを見つけた人のことを言うのだと思う。根をはる場所を見つけるには、根をはってしたい何かを持っている必要がある。人はそれを見つけられない、見つけても自信がないからこそ、根を張り続けることができない。だから現状を逃れて旅に出て新しい刺激を探し続ける。

人は一人では生きられない

人は一人では生きられない。誰かに支えられながら生きている。だからみんなと協力して生きていこう。

この言葉は本当によく言われていて全くもってその通りなんだけども、あまりに人に依存しすぎるのも危険なように思える。その人なしでは何もできないといった状況、つまり頼りっきりになりすぎると返って大きな危険を生む。人はいついなくなるのかわからないし、人は誰だって変わっていくからだ。頼りっきりになってしまうと、そんな状況に陥った時、立ち直れなくなるほどのダメージを受ける。それをいつまでも引きずって、次の頼りっきりになる人を探そうとする。同じくまたきっといつかはいなくなるのに。

ここで私が思うのは、人に依存する関係ではなく、感謝しあう関係にしようということだ。依存はそれが無くなると悲しみや妬みに変わるが、感謝の心は感謝していた何かを失った時にでも持ち続けることができる。そして感謝されるように努力することは、人に依存されるように努力することとは違って、優しい心があるように思う。

終わりに

グダグダと書き連ねてしまったが、まとめると以下の2言かな。

  • 何かを探すより何かを信じよう。
  • 人に頼るのではなく人に感謝しよう。

なんか説法みたいな感じで終わってしまったw