RecoCheckが本気を出してきたので、位置情報サービスについて考えてみた

やっとリクルートの位置情報サービス「RecoCheck」が本気を出したようです。

これぞリクルートの底力「RecoCheck」にクーポン55000件

株式会社リクルートが開発した位置情報系アプリ「RecoCheck」 が大幅にバージョンアップし、5万5000件以上のクーポン、口コミ情報を表示できるようになった。リクルート傘下のレストラン情報サービスの「ホット ペッパーグルメ」、美容情報サービスの「ホットペッパービューティー」、旅行情報の「じゃらん」、クーポン情報の「ポンパレ」と連携し、各サイトに掲載さ れている情報をRecoCheckで利用できるようになった。

リクルートが位置情報サービスをスタートした時点で、こういう展開は目に見えていたので、逆に遅いと感じるくらいでした。
というのも位置情報を使ったWEBサービスは、スマートフォンの普及もあっていろいろリリースされてますが、日本ではリクルートが参入してきたら勝ち目薄いよな～って常々感じてたからです。

位置情報サービスがなかなか普及しないのはコンテンツが薄いから？

位置情報を扱ったWEBサービスは、foursquare、はてなココなどの単体のサービスだけでなく、mixi、FacebookなどSNSの一機能としても数多く提供されています。

しかし、どのサービスも、まだまだコンテンツが薄く、普及してるとは言い難いです。

現在の位置から周辺の店の一覧は豊富に取得できるけど、その店自体の情報が無いってのがほとんどで、
結局、位置情報サービス使って店探すよりも、Google先生に聞いたりぐるなび、食べログで調べたほうが早いなんてことのがざらです。

位置情報サービスも、CGMにカテゴライズされるので、本来はユーザがコンテンツを更新していき、
情報が揃っていくんですが、どうもユーザ自身がコンテンツを生成する意欲をかきたてる要素が薄いんですよね。
ユーザが現在の位置を記憶するチェックイン機能も、最初はもの珍しさからチェックインしてたけど、
いつの間にかレスポンスもメリットもないので辞めたなんて声をよく聞きます。
（foursquareは、その辺りがうまくチェックインによってバッチがもらえるというゲーム性を付属させています）

こういう背景があるので、リクルートが参入するってなった時は、ついに日本でも普及するか！ってワクワクしました。
ご存知の通り、リクルートは、Hot Pepperやじゃらんなどお店に関するサービスを幅広く提供しているので、店情報のデータベースと位置情報を合わせれば、他のサービスよりも頭一つ抜けるのは確実です。

しかし、RecoCheckサービス開始当初は、何を読み間違えたのか普通の位置情報共有サービスでした。
（広報の人がTwitterでユーザと交流してるくらいしか他社との違いがなかった・・・・・）
まぁ、鳴かず飛ばずだったんじゃないですかね～

そんなこんなで、 やっとRecoCheckが他のサービスと連携し始めたので、
今まで以上に店の情報が豊富になり、サービスの利便性が上がってきました。 
これに触発されて、ぐるなび辺りも位置情報サービス始めたら、もっと盛り上げるんじゃないでしょうか。

位置情報サービスで重要なのはソーシャル性

リクルートが既存のお店データベースを使って位置情報サービス提供しちゃったので、他社は参入が難しくなるかと言うと、
まだまだ参入の余地はあると思います。
というのも、位置情報サービスでは、お店情報からくる利便性よりも、今いる位置情報から、
周囲の人や前に行った人達とコミュニケーション取れたり、コミュニティを形成したりできるのが、このサービスの肝だったりします。
そのへんをうまくサービス化してるのはまだまだ無いですね。
なので、お店情報はそんなに豊富でもないが、ソーシャル性が優れているサービスなら、まだまだ戦っていけるし、勝てると思います。
facebookとかSNSで上手いことすれば面白い機能が提供できると思うのですが、
どうなんでしょうか、あんまり力入れる気ないんですかね・・・・・。

日本は携帯の普及率も良いし、スマートフォンも流行ってきたので、海外先行ではなく、国産の位置情報扱ったWEBサービスで面白いサービスが出てきてほしいですね。

SIerもWebサービス企業も加点思考なのでは？

今週頭くらいに、読んだブログで興味深かったのが以下のブログです。

SIerからWebサービス事業会社の転職で気をつけるべき２つのこと

はてな界隈で有名なブロガーさんの記事で、よく拝見しているのですが、
特に今回の内容は、自身が両方のビジネスを体験してるので、読んだ後も考えさせられる内容でした。

概ねなるほどな～という内容だったのですが、一点だけ自分と考えてるポイントが違うとこがありました。

それが、こちらの内容です。

減点思考ってのは１００をスタートして１００からどんどん減点していくことで、最終的に点数の高いものが良いという考え方です。受託開発では基本的にこの考え方です。

　　　　～省略～

Webサービスはそうはいきません。なので、加点思考とでもいいましょうか、0点からいかに100点に近づけていくか、というのが求められます。

SIerに代表される受託開発は減点思考、Webサービスは加点思考だという点です。

僕は基本的には両方加点思考、ただし、種類の違う加点思考だと思ってます。

受託開発に必要なのは、０からスタートし、100点を目指す加点思考で、
Webサービスは、０からスタートし、100点どころか1000点（それ以上）というように終わりのない加点思考が求められると思ってます。

受託開発では、ユーザの求めるシステムを開発するのが目的です。
ヒアリングや要件定義の段階で、お互いに100点の基準を作成し、定めた100点を目指し、開発していくのが受託開発です。
そのため、開発段階で、作成者サイドで、良かれと思って機能を追加して120点のシステムを作成しようとしても、
ユーザが求めていない限り、不要の産物となります。
（上司からいらんことするなっと言った指摘も入ります）
あくまでも定めた基準のシステム開発が求められます。

一方、Webサービスは、作成者がこれは面白い、もしくはこれは流行る考えるシステムを開発していきます。
作成前に作成者サイドで100点の基準はある程度作成するでしょうが、開発時はもちろんのこと、
リリース後にも、ユーザの反応等でどんどん機能追加が必要な終わりのない加点思考が求められます。
これは、どんなWebサービスがヒットするかわからないので、サービスを続けていく限り、
利益の為、作成者サイドで試行錯誤が求められるからです。
使用するユーザも地域や時代によって変化するので、ニーズにあったものにサービスを適用させていいくこともWebサービスの重要な点で、
これにも終りの無い加点思考が求められます。

ざっくりとした説明ですが、まとめると受託開発はゴールの決まったもので、
Webサービス開発は、ゴールの無いものだということです。

どちらが良いかは人によります。
上記の点を勘違いして、IT企業というくくりで就職してしまうと、入った後で開発が苦痛になったりすると思います。（僕が若干そうです）

それぞれ開発者が自身にあった環境で開発していくことで、良いシステムを創っていき、日本のIT業界も盛り上げていきたいですね。

TVでインターネット？？

ダラダラ、RSSリーダの記事を消化しつつ、ながらテレビといった感じで、
アフター５を満喫していると、テレビで奇妙なCMが流れていました。

テレビでtwitterやfacebookが見れるインターネットテレビ！BRAVIA！

どんなテレビやねんと興味深くCM見ても、いや、TVでインターネットは不要やろって結論しか思いつかなかったです。

TVの横窓に、twitterやfacebookといったWEBサービスを表示できたりyoutubeを流せたりできるというのがこのTVの売りのようですが、
そもそもテレビの見方って大きく分けて２種類だと思ってます。

１．何か作業してて、とりあえずテレビつけっぱの「ながらTVパターン」
２．スポーツ観戦や映画など「がっつり見るパターン」

とりあえずTVつけておいて、別の作業しつつ、TVから気になるワードが聞こえてきたらTVから見るという、１の「ながらTVパターン」で、
たまに見る画面にtwitterやfacebook流れていてもスルーするでしょうし、
２の「がっつり見るパターン」でも、がっつり見たい時に横窓にネット表示されても欝陶しいだけで、速攻消されるでしょうね。

TVでインターネット見れてもうれしいポイントが伝わってこないので、あきらかに不要な機能だと思うのですが、
これもとりあえず高機能を売りにして他社と差別化を図ろうとした結果なんですかね～。

辞書のような説明書が必要な高機能国産携帯電話が、使いやすさに特化しユーザが自分の好きなようにカスタマイズできるiPhoneに完敗してる時点で、何でもかんでも付ける高機能は、今のニーズにあっていないってそろそろ気づいてもいいと思うのですが・・・・・。

このTVは売れるでしょうか、自分では買わないですが、売れたかどうかだけは知りたいです。

突出した人材を活かせないとか言うてますが

第3回　「突出した人材」を活かせないIT業界、低い女性の管理職比率

 何ともまぁ、ネタにして下さいオーラ満々なタイトルですが、
中身もつっこんで下さいな感じなのでエントリーにしてみました。
（会員登録してないんで、１ページ目しか読めませんでしたが＾＾；）

１ページ目を要約すると、
多くのIT企業では、突出したIT人材を確保できていないし、いても使えていない
という事を書いています。

このページで対象となってる突出したIT人材とは、
「IT分野において斬新な発想を形にできる才能をもち、製品やサービスのイノベーションで活躍するような人材」
だそうです。
いやいや、欲張りすぎやろ！


そもそも、斬新な発想を形して、製品やサービスのイノベーションで
活躍できるような人が、日本のような行動に制約が多くなり、
年功序列で歳を重ねないと決定権をもてる役職に
就けない会社にはわざわざ入らないでしょうね。

自分で会社を起こすか、海外のベンチャー基質の強い企業で働いたほうが
能力を活かせると思いますし、そういうフィールドで活躍してほしい。

会社は、トータルで優れていないが、ある点で能力を持った人達が
チームを組んでいい物を生み出して行く場所だと考えているので、
パーフェクトな人を欲しがるよりも、今いる人達の能力を見直して、
良いサイクルが生み出せるように注力すべきなのじゃないかな～っと。

なんてことを、記事を読んだ時に感じたので、
つらつらとブログのエントリーにしてみました。

・・・・・・・こういうネタなら、twitterでつぶやくだけでもよかったな。

インフラ構築におけるアジャイル開発とクラウドコンピューティング

前回のエントリーでは、ウォーターフォールモデルを経験して感じた問題点と
それらを改善しようと、最近注目を浴びているアジャイル開発について書きました。

今回も前回に便乗してアジャイル開発を取り上げたいと思います。
ただし、今回は、サーバ構築やネットワーク構築を行う、インフラ担当のエンジニアにとっての
アジャイル開発について書いていきます。

では、本題。
アジャイル開発は、主にソフトウェア開発を想定しているせいか、
インフラエンジニアにとっては非常に導入が難しい手法だと言えます。

というのもアジャイル開発の利点を考えた時、

• 成果物は、実際のシステム
• 小さな機能を一つずつ開発して、大きなシステムを構築するためクライアントの追加要求や変更要求にも柔軟に対応できる開発

などが挙げられますが、これを、インフラ構築で適用しようとした場合、大きな障害が発生するからです。

それは、サーバやストレージといった機器の調達作業です。

インフラ構築する際には、ウォーターフォールモデルでいう、基本設計や詳細設計の期間に機器の発注作業をし、
機器が導入されて初めて構築作業に移ります。

そのフローに、アジャイルのような柔軟な開発手法を取り入れた場合、機能追加の度に、発注が必要となったり、サーバ導入した際には、
ベンダーの保守も併せて導入しようとすると、サーバ毎に保守期間に差異が出たりで運用側に余計な作業も増やすことになります。

こう言った理由から、インフラエンジニアによって、アジャイル開発のような
システム開発中に柔軟に対応していく手法は、相性が悪いといえます。

じゃあ、インフラエンジニアは、今後未来永劫、ウォーターフォールモデルを
採用し続ける必要があるのかと言うと、そこで今流行りのクラウドコンピューティング（以下、クラウド）の登場です。

従来のコンピュータ利用は、ユーザー（企業、個人など）がコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは「ユーザーはインターネットの向こう側からサービスを受け、サービス利用料金を払う」形になる。

（クラウドコンピューティングより引用）

クラウドは、今や多種多様なサービスで用いられ、
猫も杓子もクラウドって言うくらい、IT業界では普及し始めています。

クラウドの特徴にみられる、「必要な機会に必要なリソースを提供する」を用いれば、
機能を追加する度に、機器発注する必要が無くなり、リソースを提供してもらうことで、
インフラ構築でもアジャイル開発ができちゃうってわけです。

インフラに引きづられて、アプリ開発でもアジャイルを
より導入しやすくなるので、なおいいですね。

そもそもクラウドコンピューティングが普及すれば、
インフラエンジニアの数は減るという意見をよく聞きますけど、
それは安易すぎると思います。

クラウドを利用するに当たって、
・どのくらいのリソースがシステムで適切なのか？
・クラウド上でインフラ環境を最適化するにはどうすればいいのか？
・クラウドコンピューティングサービスで順応しないミドルウェアはどうするのか？
といったように、まだまだインフラエンジニアの必要な場面はクラウドでもあります。

一見、アジャイル、クラウドコンピューティング
という単語だけを見ると、つながりは見えにくいですが、
使用の仕方だけでソリューションを提供できる幅が広がります。

というわけで、前回に引き続き、今回もアジャイル開発について書きました。
いつまでも同じような方法でシステム作って、デスマしてヒイヒイ言うのではなく、
多角的視点で柔軟なシステム開発を行っていきたいですね。

ウォーターフォールモデルとアジャイルソフトウェア開発について

システムエンジニアになって早くも半年が過ぎて、
初めて参画したプロジェクトもやっと終わりが見えてきました。

ウォーターフォールモデルによるシステム開発に一通り関わる事ができましたので、
ウォーターフォールモデルを通じて自分なりに感じた事と
最近注目を浴びているアジャイル開発についてまとめます。

ご存知の通り、日本のシステム開発のほとんどはウォーターフォールモデルで行われます。

ウォーターフォールモデルを簡単に説明すると、
開発プロジェクトを作業工程に分割して、時系列に行っていくモデルです。

例： 「要件定義」→「基本設計」→「詳細設計」→「開発」→「テスト」

このような感じで、一つの作業工程が完了してから、
次の作業工程に移っていき、開発していく手法です。

ウォーターフォールモデルは古くからある開発手法ですが、
現在でも、ほとんどのシステム開発で用いられています。

日本のシステム開発では外注を多様するため、
工程作業がはっきり分割できるウォーターフォールモデルは相性が良いみたいです。
（要件定義～基本設計まではA社で、詳細設計～開発をB社に外注みたいな感じ）

この開発手法は、作業工程が明確に分かれているため、各作業工程で成果物が求められ、
その成果物にOKが出て、やっと次の工程に移れます。

成果物と言っても、システムを納品するのは最終的にテスト作業が完了した後なので、
ほとんどの工程ではドキュメントが成果物となります。
今回参画したプロジェクトでも、ドキュメント作業が多く、wordやexcelがいつも以上に嫌いになりました。

要件定義工程では、要件定義書。
基本設計工程では、基本設計書。
詳細設計工程では、詳細設計書。
といった風に、各工程できっちりと成果物を作成し、
それを基に次の工程に移っていきます。
モデルの性質上では、後戻りはせず、計画性の高い開発ができます。

しかし、システム開発に携わった人なら経験あると思いますが、
いくら綿密な計画を立てても、作業の後戻りが発生しないなんてことはありません。
また、クライアントがシステムを触れるのは、全行程が完了した後なので、
実際にシステム触ってみて、想像してたのとは違うなんてことも起こります。

クライアントの要求が途中で追加又は変更になって、
後戻りバンザーイ状態なんてのも誰しもが経験したことがあるのではないでしょうか。
システムの要件は変更するけど、納期は変更しないなんてドＳなクライアントに
当たった時には、連日の徹夜作業が待っています。

ウォーターフォールモデルでは、各工程できっちり成果物を出すので、
後戻りが発生すると、 多くの時間が要求されます。

福の神がついてたはずが、いつの間にかキングボンビーになってたように、
計画性の高いプロジェクトからデスマーチプロジェクトに変貌します。

今回、ウォーターフォールモデルでの開発を経験して、
このモデルが抱える問題点についても経験できました。
多くのドキュメントに時間を取られて、肝心の現場作業を圧迫したことも少なくありませんでした。
（まぁ、それは僕がドキュメント作成に慣れていないってのも理由なんですけどね・・・）
それだけでなく、途中でクライアントの要求が増えて、急遽対応したことも・・・・・。
その度にリスケする作業は終電帰りの機会を見事に増やしてくれました・・・・・。

このようにウォーターフォールモデルだけでは、プロジェクトが破綻してしまう恐れがあるため、
後戻りも考慮した柔軟な開発手法も注目されています。

そのひとつが、アジャイルソフトウェア開発（以下、アジャイル開発）です。
wikipediaには以下のように記載されています。

アジャイルソフトウェア開発とは、ソフトウェア工学において、

迅速且つ適応的にソフトウェアを開発を行う軽量な開発手法郡の総称である。

（アジャイルソフトウェア開発より引用）

アジャイル開発とは、一つの確立された開発手法でなく、
いくつかの定義があり、それを基に確立されたソフトウェア開発手法の総体です。
その為、アジャイル開発と言っても、いろいろと種類があり、それぞれに長所短所があります。

さすがに現在公開されているアジャイル開発の手法を全部紹介すると長くなるので、
アジャイル開発によく見られる特徴といえば、以下のような感じですね。

1. 少人数精鋭のチームをつくる。
2. システム全体をいくつかの機能に小分けする。
3. 小分けた機能を一つずつ作成していき、全体を作成。
4. 一つの機能にかける時間は数週間レベル。
5. 成果物は、実際に動くシステム。
6. ドキュメント類は極力少なくする
7. クライアントの要求や変更に対応しやすい。
8. クライアントが、早い段階で、実際に動くシステムを目にするので、システムの齟齬が発見しやすい。
9. システム開発の途中でのクライアントの要求にも対応しやすい。

紹介されている情報では、ウォーターフォールモデルの問題点を
解決できる開発手法で、より良いシステムが作成できそうです。

ただ、日本での導入実績は非常に少なく、正当に評価することは難しいです。
また、最初の方にも記載しましたが、日本のシステム開発は実際の開発を
外注なんてザラにあるので、アジャイル開発は現実的に難しいようです。

しかし、クライアント目線からしたら、ドキュメントばかり見せられて、
肝心のシステムは最後のお楽しみでは不安要素が大きいと思います。
（そのせいか、やたらとミーティングが多いんですよね～）
プロジェクトの早い段階で動くシステムを見て、
自分が想像してたベクトルとあっているかなどをチェックしたいはずです。

過酷な現場が多い、システム開発ですが、
いつまでも同じようなシステム開発をするのではなく、
うまくいかなかったときは、違う手法も試すくらい柔軟になっていってほしいものです。
今後、日本でもアジャイル開発のような柔軟なシステム開発が増えていくことを期待します。

「エンジニアとしての生き方」という本が面白かったので紹介

「エンジニアとしての生き方」を読みました。

内容がとても興味深く、ノンストップで読めるくらい面白かったので紹介します。

Twitterでこの本を紹介した時には、
「若手エンジニアやIT系の学生には特におすすめです。」
 ってつぶやきましたが、お勧めどころか読むべきですね。
ぜひ読んで今の日本のIT業界について考えてほしいと思いました。



簡単に本ついて紹介すると、
この本は著者、中島さんのブログ：「Life is beautiful」の記事や
雑誌：「Web+DB PRESS」に掲載された記事などから構成されています。

ただ、ブログ記事や雑誌掲載記事が記載されているのではなく、
関連する個々の記事が章単位にまとまってあります。
そのため、著者の考えがストレートに伝わり、
今までブログや雑誌を読んだことのある人にも楽しめる内容です。

日本のITに業界に対して、疑問や不満を多少でも抱えている人にとって、
「そうそう、その通り！」って読んでて声に出るくらいストレートに記載されています。

著者のエンジニアに対する考えや自分に適した職を選ぶ基準
なども記載されているので、悩める若手エンジニアの人や、
近い将来、エンジニアとして活躍しようと考えているIT系の学生の方にとっては、
自分のキャリアを再度考察しようと思える一冊です。

「エンジニアとしての生き方」おすすめです！

iPad2 3Gをおすすめする２つの理由

早速ですが、iPad2 3Gをゲットしました！

３日程使用してみて、iPhone使い始めた時くらいの利便性を感じてます。

はっきり言って、３G過小評価してました。
これは便利です。

てことで、iPadの購入を考えてる人や
wifiモデルを視野に入れてる人向けに3Gモデルの良さを
今時のhow to本ぽく
「iPad 3Gをおすすめする２つの理由」
と題して紹介します。


ではでは本題に入ります。

1.持ち運びがしやすくなった
初代の時に比べて軽さと薄さが向上してるおかげで、
外出用途として使いやすくなりました。
外でネットするのに、いちいちwifiスポット探すのってめんどいですよね。
外でネットする時は大抵時間に制約がありますし、
そんな時、３Gモデルなら場所を気にしなくてもネットができます。
（地下鉄以外）
逆に外出が多い人には３Gモデルでないとなかなか使用しないかもしれませんよ。

２.カメラ搭載
これが最大の理由かもしれませんね。

初代はカメラがついていなかったので、
ネット閲覧用もしくは電子書籍用くらいでしか
紹介されていませんでした。

今回、カメラが搭載されたことによってネットを見るだけでなく、
カメラを用いた情報発信ができるようになりました。
例えば、写真撮って、その写真を用いたブログをアップするなんてことがiPadで可能になりました。
また、現状3G回線ではFacetime使えないですが、
それは後々アプリとかでカバーできるかもしれないですね。
そうなれば、外にいながら好きな人とfacetimeで会話ができるようになりますね。

これはwifiモデルでは無線環境が必要という制約があるので、
大きなメリットだと思います。
iPadにカメラ搭載されたことによって、
世界カメラみたいなARアプリももっとおもしろくなりそうですね。


以上がwifiモデルでなく３Gモデルをおすすめする理由です。

無線ルータ持っている人はwifiモデルで十分だと思いますが、
そうでない人は3Gをおすすめします。
「iPad購入したけど家でしか使ってなくて、やっぱノーパでいいや」
なんて宝の持ち腐れになるかもしれません。

３Gモデルは月々回線料が必要ですが、飲み会を一回我慢すれば支払える金額です。

飲み会一回我慢するだけで、日々の生活が格段に便利になるので、

iPad2 3Gモデル思い切って購入してみてはいかがでしょうか。

卒論とやらについて

今日も会社でもみくちゃになりながら仕事を終え、

RSSを消化してるとはてブに何とも香ばしいネタがあがっておりました。

卒業論文の指導を放棄した大学教授

この意見に対して、togetterでまとめられている批判的な意見として、

添削するのも教授の仕事っていうスタンスが多いですね。

まぁ、論文添削するのも仕事っていうのも一理あるっちゃあるんですが、

別に見なくてもいいんじゃない？ってのが感想です。

先生の仕事で重要なのは、論文を指導するのではなく、

論文を書くまでの過程の中で、

どれだけ学生と研究テーマについてディスカッションしてきたか

ではないでしょうか。

学生が興味のあることを先生に伝えて、

それに対して先生が長年培った知恵で装飾し、

研究として成立させるのが学生の論文だと思うんですよね。

逆にテーマ、創意工夫、論文のすべてにおいて、

教授のOKを貰えないとダメとなると、正直、誰の研究かわからなくなるし、

面白くも何とも無い。

論文を書くまでに、学生と教授がテーマに対して十分推敲していれば、

論文としての道筋を大幅に外れることもなくなります。

後は、学生がどれだけ自分の言葉で研究のストーリーを、

表現できるかに掛かってくるので、先生が論文を添削するかどうかは、

対して問題でもないというわけです。

まぁ、論文とか研究っておかたーいイメージがありますが、

自分の興味のあることを研究し、世間に公表するってのは

人生でそうそうない良い機会ですので、

この時期、論文に追われて徹夜してる学生のみなさん、頑張ってください。

new posts!!

ブログは、これで５回目（過去4回はすぐに辞めました•••）ですが、

気が向くままに更新していきたいと思います。