（続）ソーシャルな時代におけるプログラマーという職業
2014年07月07日
こんにちは、マツナガです。前回「ソーシャルな時代におけるプログラマーという職業
」について書いてみたのですが、山本ゆうごさんにも読んでいただいたようで、もう少しこの話題について掘り下げてみます。
山本ゆうごさんは、以下のように書いています。
これまで優秀なプログラマーの価値は、洗練されたプログラムコードが書ける、バグが少なく品質の高いプログラムを書けることでした。もちろん、こういった価値は今も変わってはいません。しかし、ソーシャルな時代にソーシャルなサービスを開発することに身をおいた（おかされた）プログラマーは楽しいプログラムを作らなければならない。今までソフトウェアが工業製品と見做された環境でコードを書いてきたプログラマーが、ソーシャルサービスの開発チームに入ったら、かなりのギャップを感じるはずです。
ソフトウェアが工業製品であるのなら、それはきっちりとした仕様が決められています。プログラマーはその仕様通りにプログラムが正しく動くことに最大限の努力を注ぎます。では、これがソーシャルなサービスだったらどうでしょう。そもそも、ソーシャルなサービスの目的は、前回も述べたとおり、正しい計算をコンピューターにさせ、人間の作業時間の効率化を図るものではありません。
どれだけ多くの人に使ってもらえるか、どれだけ多くの人に楽しみや感動を与えられるか、そこを考えてプログラムを書かなければなりません。どういうコードを書いたら、多くの人に使ってもらえるのでしょう。多くの人を感動させることのできるプログラムとはどんなものなのでしょう。残念ながら、明快な正解はありません。むしろ、誰も使ってもらえない、感動を与えるどころか、とてもつまらないプログラムになってしまう可能性もあるわけです。
つまり、ソーシャルなサービスの開発にとって、プログラマーはプログラムが正しく動くことだけを考えていればよいというわけではなくなってきているのです。むしろ、ちょっと乱暴な言い方ですが、正しく動くことは二の次で、とにかくダウンロード数を増やすことやPVを稼ぐことが目的とされる状況もあったりするのです。
今までのプログラマーの価値が明確に変わったターニングポイントは、Web2.0といわれたあの時代だったのかなと思います。「Web2.0」という言葉は単なるバズワードだった、という評価も少なくはありません。この言葉を提唱したティム・オライリーは、Web2.0とは「旧来は情報の送り手と受け手が固定され送り手から受け手への一方的な流れであった状態が、送り手と受け手が流動化し誰でもがウェブを通して情報を発信できるように変化したweb」のことだったと言っています。この頃から、情報の受け手もWebのコンテンツを作る主役になってきたわけです。情報の受け手が楽しみ、コンテンツを作っていく、そこに楽しみを求め、新たなビジネスモデルが誕生してきました。
そして、もうひとつのターニングポイントは、iPhoneの誕生です。正確にいうと、AppleがApp StoreというプラットフォームとiOSのSDKを開発者に公開し、iOSで動くアプリを誰もが作って公開できるようにしたことです。この時点から、プログラマーは使ってもらうアプリを作ることが第一の使命になりました。楽しみや感動を与えるアプリをプログラマーが自ら考え、コードを書き、App Storeで公開、販売をしました。WWDC 2014で、現在、App Storeには120万のアプリが登録されていると発表されました。登録されている開発者は900万人に達しているそうです。この事実を受け止めると、明らかにプログラマーという職業は再定義されたと思うのです。しかし、このような議論の中に、単純に、クリエイティビティがプログラマーに求めらるようになったと考えるのは早計です。
人が楽しいと思うことを考えられるのは人間です。プログラマーだって人間です。ほら、コード書けるプログラマーの方が、人を楽しめること一歩先にできるんだよ。
」について書いてみたのですが、山本ゆうごさんにも読んでいただいたようで、もう少しこの話題について掘り下げてみます。
山本ゆうごさんは、以下のように書いています。
「コンピュータが「計算機」だった時代は、絶対プログラムは間違えちゃいけない。今も銀行のシステムとかは同じレベルの品質要求。正しく速く計算するのが提供価値。
それがソーシャル時代になると、どうなるか。
正しいプログラムではなく、楽しいプログラムでないといけない。
10年越しのローン計算ができるプログラムではなく、二週間おきのイベントに対応してリリースしなくちゃならない。」
これまで優秀なプログラマーの価値は、洗練されたプログラムコードが書ける、バグが少なく品質の高いプログラムを書けることでした。もちろん、こういった価値は今も変わってはいません。しかし、ソーシャルな時代にソーシャルなサービスを開発することに身をおいた（おかされた）プログラマーは楽しいプログラムを作らなければならない。今までソフトウェアが工業製品と見做された環境でコードを書いてきたプログラマーが、ソーシャルサービスの開発チームに入ったら、かなりのギャップを感じるはずです。
ソフトウェアが工業製品であるのなら、それはきっちりとした仕様が決められています。プログラマーはその仕様通りにプログラムが正しく動くことに最大限の努力を注ぎます。では、これがソーシャルなサービスだったらどうでしょう。そもそも、ソーシャルなサービスの目的は、前回も述べたとおり、正しい計算をコンピューターにさせ、人間の作業時間の効率化を図るものではありません。
どれだけ多くの人に使ってもらえるか、どれだけ多くの人に楽しみや感動を与えられるか、そこを考えてプログラムを書かなければなりません。どういうコードを書いたら、多くの人に使ってもらえるのでしょう。多くの人を感動させることのできるプログラムとはどんなものなのでしょう。残念ながら、明快な正解はありません。むしろ、誰も使ってもらえない、感動を与えるどころか、とてもつまらないプログラムになってしまう可能性もあるわけです。
つまり、ソーシャルなサービスの開発にとって、プログラマーはプログラムが正しく動くことだけを考えていればよいというわけではなくなってきているのです。むしろ、ちょっと乱暴な言い方ですが、正しく動くことは二の次で、とにかくダウンロード数を増やすことやPVを稼ぐことが目的とされる状況もあったりするのです。
今までのプログラマーの価値が明確に変わったターニングポイントは、Web2.0といわれたあの時代だったのかなと思います。「Web2.0」という言葉は単なるバズワードだった、という評価も少なくはありません。この言葉を提唱したティム・オライリーは、Web2.0とは「旧来は情報の送り手と受け手が固定され送り手から受け手への一方的な流れであった状態が、送り手と受け手が流動化し誰でもがウェブを通して情報を発信できるように変化したweb」のことだったと言っています。この頃から、情報の受け手もWebのコンテンツを作る主役になってきたわけです。情報の受け手が楽しみ、コンテンツを作っていく、そこに楽しみを求め、新たなビジネスモデルが誕生してきました。
そして、もうひとつのターニングポイントは、iPhoneの誕生です。正確にいうと、AppleがApp StoreというプラットフォームとiOSのSDKを開発者に公開し、iOSで動くアプリを誰もが作って公開できるようにしたことです。この時点から、プログラマーは使ってもらうアプリを作ることが第一の使命になりました。楽しみや感動を与えるアプリをプログラマーが自ら考え、コードを書き、App Storeで公開、販売をしました。WWDC 2014で、現在、App Storeには120万のアプリが登録されていると発表されました。登録されている開発者は900万人に達しているそうです。この事実を受け止めると、明らかにプログラマーという職業は再定義されたと思うのです。しかし、このような議論の中に、単純に、クリエイティビティがプログラマーに求めらるようになったと考えるのは早計です。
人が楽しいと思うことを考えられるのは人間です。プログラマーだって人間です。ほら、コード書けるプログラマーの方が、人を楽しめること一歩先にできるんだよ。
ソーシャルな時代におけるプログラマーという職業
2014年06月02日
こんにちは、マツナガです。今回は少し堅い話です。
唐突ですが、僕の職業は何かと言われると、名刺上は、「テクニカルスペシャリスト」ということになっています。そして往々にして、それってどういう仕事？と聞かれます。
特に、ITの業界ではない人に説明する時には、結構苦労します。そういう場合、iPhoneのアプリ作る仕事とか、○○○というWebサイトの開発とかをしています、というと、何となく分かってもらえます。
アプリ作る仕事とか、の「とか」にアプリ作ってるだけじゃないんだよという含みを持たせているんですが、Webやアプリ開発を行う前は、もっと業務よりの（どちらかというと裏方の）システム開発をやっていたので、「コンピューターのプログラムとか作るような仕事」と説明していました。この場合「コンピューター」という言葉がミソです。プログラムを作るという部分は想像しにくいので、「コンピューター」という言葉を入れることで、「あぁ、そっち系の仕事なんだな」と何となく理解してもらえてました。
コンピューターのシステム開発において、プログラムを書く仕事のみを専門にしているエンジニアもいます。いわゆるプログラマーです。しかし、システム開発はプログラマーだけでは行えません。プログラムは書かないけれど、お客さんの要望を聞き、どんなコンピューターやハードウェアが必要かを分析し、プログラマーがプログラムを記述するための設計図を作成する役割の人もいます（システムアナリストやSEと呼ばれたりします）。また、プログラマーたちが仕事を円滑にできるよう、外部との調整を行ったり、進行に遅れがないかを管理し遅れが生じそうな場合は、対策を講じるなど、そういった役割を行う人もいます（プロジェクトマネージャーと呼ばれたりします）。このように各人がそれぞれの役割をこなしながら、一定の品質を保ち、適正なコストで、指定された納期までに開発が終わるようシステム開発は進行されます。
さて、前置きが長くなりましたが、今回は、ITの開発の現場はもっと多様化しているんだというお話です。
さきほど、システム開発における役割の話をしました。しかし、今では、これら役割をひとりで担う場合も増えています。また、品質はさほど優先されず、それよりも、これまで適正と思われていたコストよりもかなり低いコストで、しかも、これまでよりもかなり短い期間で開発を行うというケースが増えてきています。
こう書くと、ITの仕事って、やはり、低賃金で長時間労働を強いられるお仕事だよねという話になりがちです。企業がITに対する投資を絞り、とにかく早く安く開発をしてくれと、システム開発会社に要求し、現場のプログラマーたちはそのしわ寄せをくらって過酷な労働を強いられているのでしょうか？ 安く、早く作らなければならなくなった理由は何なのでしょうか？
ちょっと視点を変えてみましょう。近年のITの中で注目されている分野は何でしょう？ もちろん、銀行や交通など私たちの生活を支えているシステムや、経理システムなど企業の業務を円滑に進めるためのシステムもありますが、ネットの記事で日々取り上げられ、ITの花形の分野として見られるものは、 やはり、SNSやゲーム、スマートフォンのアプリなどになるでしょう。いわゆるソーシャルなシステムやアプリです。求人も多く、新しい技術を積極的に採用しているのもこの分野です。
そもそもコンピューターシステムというものは、人間がこれまで、そろばんや鉛筆を使って手作業で行っていたことをコンピューターにプログラムを実行させることで、人間の能力をはるかに超えるスピードで作業を行うためのものです。したがって、システムの価値は、例えば、1000人かかって1ヶ月かかる作業を、わずか数分で終わらせることができるといった効率化にあると言えます。1000人の人件費を圧縮できるのであれば、数千万円かけてコンピューターシステムを導入するのは、企業活動において理にかなっています。
では、昨今注目されている、SNS、ゲーム、スマートフォンのアプリ。これらの価値は何でしょうか？人間の能力を超える作業をコンピューターに行わせ、作業効率を向上させるものでしょうか？ 実は、このことが、安くて早い開発を求められる原因のひとつなのです。
ソーシャルなシステムやアプリの大半の目的は、それらを使ってもらうことで、何かを宣伝したり、人を集めたり、ひいては可処分時間をどれだけ奪えるかを求めたられたりするものです。つまり、その存在意義が、コンピューターの本質である人間の能力を超えた作業を行うという目的ではなく、どれだけ宣伝効果があったかであったり、会員をどれだけ集められたかといったことが目的になります。
したがって、単純に人件費の圧縮といった指標で効果が測れるものではありません。乱暴な言い方をすると、効果があるかどうかは博打のようなものかもしれません。もちろん、事前分析によって効果を予測する手法はありますし、そういった研究をしている企業もあります。しかし、いくらコストをかけるのが適正で、その効果がどの程度のものなのかが測りにくいということから、失敗するリスクも考えて、できるだけ、安く作って欲しいという作用が働きがちになると思います（失敗したらコストかけなかったんだもん、という言い訳もできますし）。また、こういった分野のものは他社との競合が激しいため、他社よりも早く結果を出したいですし、失敗したらすぐ別の方向に舵が切れるよう考える必要があります。すべからく、とにかく早く作って欲しいという要求が出やすいと思います。
つまり、こういったITの分野において、従来通りの価格や期間を前提にシステム開発の計画を立てるのはそもそも的外れなのです。特にこれまで、企業向けのシステム開発を行ってきた会社が、人材とこれまでの技術ノウハウをもとに、ソーシャルな分野を手がけようとすると、コストや期間の面でかなりのギャップを感じます。もちろん、こういった会社はエキスパートなエンジニアを多く抱え、高いレベルの技術力を持ち、豊富なマネージメント経験を持ったプロジェクトマネージャーが存在します。場合によっては素晴らしいSNSのシステムが作れるかもしれません。しかし、これまでの開発手法やコスト感覚を大幅に変えないと、プロジェクトは成功しません。これまでの開発手法を実行するだけの時間もコストも与えられないのですから。
で、この文章のタイトルであるソーシャルな時代のプログラマーはどうあるべきなのでしょうか？もちろん、安くて早い開発を要求され、ただ、長時間労働を強いられているだけではいけません。先にコンピューターシステムの本質は、人間の能力を超えるスピードで作業を行うためのものだと書きました。それを実現するためのものがプログラムです。実は、システム開発は何かと手作業が多いのです。プロジェクトが大人数になればなるほど、ドキュメントやプログラムの量が増えたり、作業の分担や、進行など人の調整も複雑になります。ドキュメントやプログラムに間違いがないかとか、人の割り当てなどもわりとアナログな手作業で行われている場合が多いのです。
ならば、そういった手作業をコンピューターにやらせればよいのです。そのためのプログラムを書く技術力は現場のプログラマーであれば持ち合わせているはずです。実際に、そういった考えのもと開発を支援するさまざまなツール（しかも無料で使えるもの）が、増えてきています。そしてこれらのツールは、エンジニアが置かれてる環境を改善しようと作ったものですから、実によくできています。必要は発明の母です。そういったツールを使うことで、システム開発の効率は大幅に向上するはずです。もちろんそれが物足りなかったら、カスタマイズするなり、さらに効率をあげるためのツールを自ら作ることを考えるとよいでしょう。
ソーシャルな分野では、とにかく技術の進歩が早い。しかし、その一方で、人間はいちど作り上げた仕組みや環境を変化させることにはどうしても億劫になりますが、それでもプログラマーは、早く、安くを望まれる環境の中で、自ら開発効率を上げるための努力をしつづけることが必要です。
唐突ですが、僕の職業は何かと言われると、名刺上は、「テクニカルスペシャリスト」ということになっています。そして往々にして、それってどういう仕事？と聞かれます。
特に、ITの業界ではない人に説明する時には、結構苦労します。そういう場合、iPhoneのアプリ作る仕事とか、○○○というWebサイトの開発とかをしています、というと、何となく分かってもらえます。
アプリ作る仕事とか、の「とか」にアプリ作ってるだけじゃないんだよという含みを持たせているんですが、Webやアプリ開発を行う前は、もっと業務よりの（どちらかというと裏方の）システム開発をやっていたので、「コンピューターのプログラムとか作るような仕事」と説明していました。この場合「コンピューター」という言葉がミソです。プログラムを作るという部分は想像しにくいので、「コンピューター」という言葉を入れることで、「あぁ、そっち系の仕事なんだな」と何となく理解してもらえてました。
コンピューターのシステム開発において、プログラムを書く仕事のみを専門にしているエンジニアもいます。いわゆるプログラマーです。しかし、システム開発はプログラマーだけでは行えません。プログラムは書かないけれど、お客さんの要望を聞き、どんなコンピューターやハードウェアが必要かを分析し、プログラマーがプログラムを記述するための設計図を作成する役割の人もいます（システムアナリストやSEと呼ばれたりします）。また、プログラマーたちが仕事を円滑にできるよう、外部との調整を行ったり、進行に遅れがないかを管理し遅れが生じそうな場合は、対策を講じるなど、そういった役割を行う人もいます（プロジェクトマネージャーと呼ばれたりします）。このように各人がそれぞれの役割をこなしながら、一定の品質を保ち、適正なコストで、指定された納期までに開発が終わるようシステム開発は進行されます。
さて、前置きが長くなりましたが、今回は、ITの開発の現場はもっと多様化しているんだというお話です。
さきほど、システム開発における役割の話をしました。しかし、今では、これら役割をひとりで担う場合も増えています。また、品質はさほど優先されず、それよりも、これまで適正と思われていたコストよりもかなり低いコストで、しかも、これまでよりもかなり短い期間で開発を行うというケースが増えてきています。
こう書くと、ITの仕事って、やはり、低賃金で長時間労働を強いられるお仕事だよねという話になりがちです。企業がITに対する投資を絞り、とにかく早く安く開発をしてくれと、システム開発会社に要求し、現場のプログラマーたちはそのしわ寄せをくらって過酷な労働を強いられているのでしょうか？ 安く、早く作らなければならなくなった理由は何なのでしょうか？
ちょっと視点を変えてみましょう。近年のITの中で注目されている分野は何でしょう？ もちろん、銀行や交通など私たちの生活を支えているシステムや、経理システムなど企業の業務を円滑に進めるためのシステムもありますが、ネットの記事で日々取り上げられ、ITの花形の分野として見られるものは、 やはり、SNSやゲーム、スマートフォンのアプリなどになるでしょう。いわゆるソーシャルなシステムやアプリです。求人も多く、新しい技術を積極的に採用しているのもこの分野です。
そもそもコンピューターシステムというものは、人間がこれまで、そろばんや鉛筆を使って手作業で行っていたことをコンピューターにプログラムを実行させることで、人間の能力をはるかに超えるスピードで作業を行うためのものです。したがって、システムの価値は、例えば、1000人かかって1ヶ月かかる作業を、わずか数分で終わらせることができるといった効率化にあると言えます。1000人の人件費を圧縮できるのであれば、数千万円かけてコンピューターシステムを導入するのは、企業活動において理にかなっています。
では、昨今注目されている、SNS、ゲーム、スマートフォンのアプリ。これらの価値は何でしょうか？人間の能力を超える作業をコンピューターに行わせ、作業効率を向上させるものでしょうか？ 実は、このことが、安くて早い開発を求められる原因のひとつなのです。
ソーシャルなシステムやアプリの大半の目的は、それらを使ってもらうことで、何かを宣伝したり、人を集めたり、ひいては可処分時間をどれだけ奪えるかを求めたられたりするものです。つまり、その存在意義が、コンピューターの本質である人間の能力を超えた作業を行うという目的ではなく、どれだけ宣伝効果があったかであったり、会員をどれだけ集められたかといったことが目的になります。
したがって、単純に人件費の圧縮といった指標で効果が測れるものではありません。乱暴な言い方をすると、効果があるかどうかは博打のようなものかもしれません。もちろん、事前分析によって効果を予測する手法はありますし、そういった研究をしている企業もあります。しかし、いくらコストをかけるのが適正で、その効果がどの程度のものなのかが測りにくいということから、失敗するリスクも考えて、できるだけ、安く作って欲しいという作用が働きがちになると思います（失敗したらコストかけなかったんだもん、という言い訳もできますし）。また、こういった分野のものは他社との競合が激しいため、他社よりも早く結果を出したいですし、失敗したらすぐ別の方向に舵が切れるよう考える必要があります。すべからく、とにかく早く作って欲しいという要求が出やすいと思います。
つまり、こういったITの分野において、従来通りの価格や期間を前提にシステム開発の計画を立てるのはそもそも的外れなのです。特にこれまで、企業向けのシステム開発を行ってきた会社が、人材とこれまでの技術ノウハウをもとに、ソーシャルな分野を手がけようとすると、コストや期間の面でかなりのギャップを感じます。もちろん、こういった会社はエキスパートなエンジニアを多く抱え、高いレベルの技術力を持ち、豊富なマネージメント経験を持ったプロジェクトマネージャーが存在します。場合によっては素晴らしいSNSのシステムが作れるかもしれません。しかし、これまでの開発手法やコスト感覚を大幅に変えないと、プロジェクトは成功しません。これまでの開発手法を実行するだけの時間もコストも与えられないのですから。
で、この文章のタイトルであるソーシャルな時代のプログラマーはどうあるべきなのでしょうか？もちろん、安くて早い開発を要求され、ただ、長時間労働を強いられているだけではいけません。先にコンピューターシステムの本質は、人間の能力を超えるスピードで作業を行うためのものだと書きました。それを実現するためのものがプログラムです。実は、システム開発は何かと手作業が多いのです。プロジェクトが大人数になればなるほど、ドキュメントやプログラムの量が増えたり、作業の分担や、進行など人の調整も複雑になります。ドキュメントやプログラムに間違いがないかとか、人の割り当てなどもわりとアナログな手作業で行われている場合が多いのです。
ならば、そういった手作業をコンピューターにやらせればよいのです。そのためのプログラムを書く技術力は現場のプログラマーであれば持ち合わせているはずです。実際に、そういった考えのもと開発を支援するさまざまなツール（しかも無料で使えるもの）が、増えてきています。そしてこれらのツールは、エンジニアが置かれてる環境を改善しようと作ったものですから、実によくできています。必要は発明の母です。そういったツールを使うことで、システム開発の効率は大幅に向上するはずです。もちろんそれが物足りなかったら、カスタマイズするなり、さらに効率をあげるためのツールを自ら作ることを考えるとよいでしょう。
ソーシャルな分野では、とにかく技術の進歩が早い。しかし、その一方で、人間はいちど作り上げた仕組みや環境を変化させることにはどうしても億劫になりますが、それでもプログラマーは、早く、安くを望まれる環境の中で、自ら開発効率を上げるための努力をしつづけることが必要です。
怪しげだったものが世界を作る
2014年04月29日
ここ最近のPC関連の技術トレンドで外せないのは仮想化だと思います。
さてこの仮想化って何が便利なの?というのが本日のテーマでございます。
皆さんのお持ちのPCは1台なら1台分の働きを期待します。
(変な言い回しですがご勘弁ください。)
ところが、現在のコンピュータは、今や一部の特殊な処理を除けば充分な性能を持ちます。
つまり、1台でも1台分の働きだけだと、もったいないのです。
ましてや、最近のCPU(中心回路)は1つのチップの中に複数個収められていることがほとんどです。
つまり、1台のPCでも、中を見ると複数台のPCがギュッと入っている状態なのです。
引用:http://ja.wikipedia.org/wiki/Hyper-V
もちろん、皆さんがお持ちのPCが複数台になると言っても意味がわかりませんし、必要性も普通はほぼないでしょう。
仮想化が注目を浴びているのは「サーバ」周辺です。
例えば
ホームページを置くために必要なWebサーバ
仕事の大切なデータを保管し、共有するファイルサーバー
経理情報なんかを処理する汎用機なんかもありますね。
当社も仮想化はもう欠かせないものになっています。
Webシステムを開発するときに必要なのは、もちろんWebサーバーですね。
1台のWebサーバーで、複数のWebシステムを開発する場合、色々と考えなくてはいけない問題があります。
例えば、本番では、1つの専有サーバーで運用するシステムでも、開発は複数のWebシステムが同居する環境で開発するとします。
しかし、もうこの時点で、すでに本番サーバーと開発環境が同一ではなくなり、場合によっては、開発環境でテストしてOKを出しても、本番環境でもう一度テストしなくてはいけない事態が発生します。
つまり、本来は1つのWebシステムで1つの専有開発サーバーが理想的なわけです。
(本番サーバーと完全に一致させた環境で)
仮想化はこんな時に役立ちます。
ベースOSの上に複数の仮想的なハードウェアを構築し、このハードウェアの1つをサーバーとして使用するわけです。
仮想的なハードウェアに対し、OSのインストールも行い、まるっきり本当に1台のサーバーとして、開発サーバーを構築するわけです。
そして、構築した開発サーバーはそのままコピーして本番サーバーにすることも可能です。
そうすると環境もシステム構成も完全に一致した開発環境と本番環境が手に入るというわけですね。
これならば信頼性の高い動作テストが行えます。
これは我々にとってすごくありがたいことです。
というわけで、当社の開発環境は大部分を仮想化して構築するようになりました。
ところで、最近では物理的なハードウェアをコピーして、仮想的なハードウェアに変換するP2Vという技術もあります。
古いハードウェアの場合、補修パーツがすでに存在しない場合もあります。
このため、古いハードウェアをまるっと仮想化して、延命化するわけです。
例えば古い経理システム等、専用ハードで昔から使っているようなシステムの場合、仮想化は救世主のような技術なのです。
また、Webホスティングサービスの会社も、仮想化した1台を提供するサービスをすれば、専有サーバなのに、共有サーバと似た値段で提供できると考えました。
それがVPSです。
安いところでは、数百円から提供するようになりました。
サービスにばらつきがあり、ひどいところもありますが、何しろ専有サーバをかなりやすいコストで利用することができるので、とても今流行サービスだと思います。
http://kakaku.com/pc/rentalserver/ma_0/s1=3/
Amazon Web Servicesもその一つと考えても問題ないでしょう。
(厳密にはクラウドサービスになっていきますが、それはまた、次回に・・・)
https://aws.amazon.com/jp/
で、この仮想化技術、昔はエミュレータとよく呼ばれていました。
そう、以前ご紹介したこれと根っこが同じ考えなわけです。
http://iaseteam.eshizuoka.jp/e1110170.html
当初は怪しげでなんだか信頼の置けない技術だったわけです。
しかし、考え方は昔からあり、様々な面で利用されてきました。(信頼性は低いけど)
Macintoshでは68K MacからPowerPCに変わるときにOS標準で搭載されましたし、Mac OS XのCarbonやRosettaも同じ考え方だと思います。
http://ja.wikipedia.org/wiki/Mac_68K%E3%82%A8%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%BF
http://ja.wikipedia.org/wiki/Carbon
http://ja.wikipedia.org/wiki/Rosetta
※考えてみればMacはアーキテクチャが変わるたびに、綱渡りをして完成度の高いエミュレータを出していたわけですね。すごい!
ところは今は仮想化はトレンド。
何しろ、インテルまで通常のPCにIntel VTという機能を盛り込んでいるぐらいです。
当初はハッカーのおもちゃだったPCが、ビジネスの主流になり、今に至る流れの中、このトレンドも同じ流れの中で進化していったわけですね。
今や、怪しげな技術ではなく、背広着たオッサンたちにとって、非常に重要な技術になったわけです。
つくづくPCの世界は不良がスタンダードを作るのだなぁと思った次第。
不良でヒッピーだった某お人
さてこの仮想化って何が便利なの?というのが本日のテーマでございます。
皆さんのお持ちのPCは1台なら1台分の働きを期待します。
(変な言い回しですがご勘弁ください。)
ところが、現在のコンピュータは、今や一部の特殊な処理を除けば充分な性能を持ちます。
つまり、1台でも1台分の働きだけだと、もったいないのです。
ましてや、最近のCPU(中心回路)は1つのチップの中に複数個収められていることがほとんどです。
つまり、1台のPCでも、中を見ると複数台のPCがギュッと入っている状態なのです。
引用:http://ja.wikipedia.org/wiki/Hyper-V
もちろん、皆さんがお持ちのPCが複数台になると言っても意味がわかりませんし、必要性も普通はほぼないでしょう。
仮想化が注目を浴びているのは「サーバ」周辺です。
例えば
ホームページを置くために必要なWebサーバ
仕事の大切なデータを保管し、共有するファイルサーバー
経理情報なんかを処理する汎用機なんかもありますね。
当社も仮想化はもう欠かせないものになっています。
Webシステムを開発するときに必要なのは、もちろんWebサーバーですね。
1台のWebサーバーで、複数のWebシステムを開発する場合、色々と考えなくてはいけない問題があります。
例えば、本番では、1つの専有サーバーで運用するシステムでも、開発は複数のWebシステムが同居する環境で開発するとします。
しかし、もうこの時点で、すでに本番サーバーと開発環境が同一ではなくなり、場合によっては、開発環境でテストしてOKを出しても、本番環境でもう一度テストしなくてはいけない事態が発生します。
つまり、本来は1つのWebシステムで1つの専有開発サーバーが理想的なわけです。
(本番サーバーと完全に一致させた環境で)
仮想化はこんな時に役立ちます。
ベースOSの上に複数の仮想的なハードウェアを構築し、このハードウェアの1つをサーバーとして使用するわけです。
仮想的なハードウェアに対し、OSのインストールも行い、まるっきり本当に1台のサーバーとして、開発サーバーを構築するわけです。
そして、構築した開発サーバーはそのままコピーして本番サーバーにすることも可能です。
そうすると環境もシステム構成も完全に一致した開発環境と本番環境が手に入るというわけですね。
これならば信頼性の高い動作テストが行えます。
これは我々にとってすごくありがたいことです。
というわけで、当社の開発環境は大部分を仮想化して構築するようになりました。
ところで、最近では物理的なハードウェアをコピーして、仮想的なハードウェアに変換するP2Vという技術もあります。
古いハードウェアの場合、補修パーツがすでに存在しない場合もあります。
このため、古いハードウェアをまるっと仮想化して、延命化するわけです。
例えば古い経理システム等、専用ハードで昔から使っているようなシステムの場合、仮想化は救世主のような技術なのです。
また、Webホスティングサービスの会社も、仮想化した1台を提供するサービスをすれば、専有サーバなのに、共有サーバと似た値段で提供できると考えました。
それがVPSです。
安いところでは、数百円から提供するようになりました。
サービスにばらつきがあり、ひどいところもありますが、何しろ専有サーバをかなりやすいコストで利用することができるので、とても今流行サービスだと思います。
http://kakaku.com/pc/rentalserver/ma_0/s1=3/
Amazon Web Servicesもその一つと考えても問題ないでしょう。
(厳密にはクラウドサービスになっていきますが、それはまた、次回に・・・)
https://aws.amazon.com/jp/
で、この仮想化技術、昔はエミュレータとよく呼ばれていました。
そう、以前ご紹介したこれと根っこが同じ考えなわけです。
http://iaseteam.eshizuoka.jp/e1110170.html
当初は怪しげでなんだか信頼の置けない技術だったわけです。
しかし、考え方は昔からあり、様々な面で利用されてきました。(信頼性は低いけど)
Macintoshでは68K MacからPowerPCに変わるときにOS標準で搭載されましたし、Mac OS XのCarbonやRosettaも同じ考え方だと思います。
http://ja.wikipedia.org/wiki/Mac_68K%E3%82%A8%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%BF
http://ja.wikipedia.org/wiki/Carbon
http://ja.wikipedia.org/wiki/Rosetta
※考えてみればMacはアーキテクチャが変わるたびに、綱渡りをして完成度の高いエミュレータを出していたわけですね。すごい!
ところは今は仮想化はトレンド。
何しろ、インテルまで通常のPCにIntel VTという機能を盛り込んでいるぐらいです。
当初はハッカーのおもちゃだったPCが、ビジネスの主流になり、今に至る流れの中、このトレンドも同じ流れの中で進化していったわけですね。
今や、怪しげな技術ではなく、背広着たオッサンたちにとって、非常に重要な技術になったわけです。
つくづくPCの世界は不良がスタンダードを作るのだなぁと思った次第。
不良でヒッピーだった某お人
◯◯◯には向かない職業
2014年04月04日
皆さんは「プログラマー35歳定年説」を聞いたことがありますか?
プログラマーはせいぜい35歳まで
脳みその柔軟性もなくなり
才能も体力も枯れ果てて
全く役立たずの人間に成り下がってしまう、という説です。
さてさて、現在、私の周りを見渡してみますと
一線級の現役エンジニアで35歳以上はゴロゴロしています。
Web業界にどっぷりでアジャイル開発が基本の弊社では
なんだか必然的にそういう人が多くなっています。
さてさて、弊社の35歳以上メンバーを紹介してみますと・・・
松永さん 4◯歳
アプリをガリガリ作る怪しげなおじさん
過酷な状況でもニコニコしながら、難なくこなす。
(きっと腹黒いに違いないナイスガイ)
山口さん ◯◯歳
プログラムをガリガリ書く主婦
100台近くある社内の全てのPCのトラブルを引き受けたりするすごい人(変態かもしれない)
高山くん 35歳
ああもうなんだか
色々なネタのオチに使える人
そして私、近藤も40代です。
※写真はイメージです。
なんだよ、35歳過ぎても現役じゃないか
と、そこで調べてみました。
こんな記事がありました。
35歳定年説の真実
ようはやはりそういう現象は存在するということらしい。
しかし、上流工程のエンジニアや管理職に出世することで現場から離れることも一因とのこと。
本当にそうかなーと思う次第です。
でもう少し調べると
どうやら私なりの結論に至りました。
プログラムのトレンドの移り変わりや
プログラム技術の発展が関わっているように思います。
例えば、今のトレンドではハード周りならならクラウドでしょうか
プログラム技術なら無名関数ですね。
弊社の35歳以上組は
ある意味仕方なく、ある意味好奇心で
こういうのをチャレンジしたりします。
(山口さんは主婦ですがアプリ開発のためにMacintosh Airを購入しています。)
確かに年令を重ね、経験値も増し、出世はするでしょう。
そうなった人で現場から遠ざかる人もいるでしょう。
そうして使い物にならなくなる人もいるのはわかります。
しかし、これを寿命と言っていいのか?ということです。
ここでひとつ思い至ったわけです。
昔、オブジェクト指向が理解できるか、できないかで
プログラマーの壁が生まれた時期がありました。
(調べたら未だにあるようです。)
理解できたと言って、自慢気になっている人もいました。
こいつらのお陰でオブジェクト指向がある意味宗教みたいになった面もありました。(所詮、便利にする道具じゃないか)
つまり、プログラムの技術革新や進化の中で
拒否する人と、拒否しない人がいて
若いうちは逆らえないから
上司の言うままに習得した技術も、出世すれば習得しないわけです。
つまり、単に向いていないだけじゃん。
寿命って言うな。ってことです。
マルチタスクOSになった今のWindowsの基礎を作った
デヴィッド・カトラーは60歳超えてもソースコードを自ら記述しています。
森田将棋の森田和郎さんは『サムライスピリッツ零』等のプログラムを担当し、一昨年、57歳でお亡くなりになるまで現役のプログラマーでした。
結局、「プログラマー35歳定年説」とは
ある種の向いていない人たちのずいぶん馬鹿にした話なんじゃないかと
私は結論づけたわけなのです
(間違ったらすみません。)
ちなみに私、近藤が最近楽しく学んだのはFuelPHPでした。
このフレームワーク、欲しい機能が色々最初から入っている。すごい!!
プログラマーはせいぜい35歳まで
脳みその柔軟性もなくなり
才能も体力も枯れ果てて
全く役立たずの人間に成り下がってしまう、という説です。
さてさて、現在、私の周りを見渡してみますと
一線級の現役エンジニアで35歳以上はゴロゴロしています。
Web業界にどっぷりでアジャイル開発が基本の弊社では
なんだか必然的にそういう人が多くなっています。
さてさて、弊社の35歳以上メンバーを紹介してみますと・・・
松永さん 4◯歳
アプリをガリガリ作る怪しげなおじさん
過酷な状況でもニコニコしながら、難なくこなす。
(きっと腹黒いに違いないナイスガイ)
山口さん ◯◯歳
プログラムをガリガリ書く主婦
100台近くある社内の全てのPCのトラブルを引き受けたりするすごい人(変態かもしれない)
高山くん 35歳
ああもうなんだか
色々なネタのオチに使える人
そして私、近藤も40代です。
※写真はイメージです。
なんだよ、35歳過ぎても現役じゃないか
と、そこで調べてみました。
こんな記事がありました。
35歳定年説の真実
ようはやはりそういう現象は存在するということらしい。
しかし、上流工程のエンジニアや管理職に出世することで現場から離れることも一因とのこと。
本当にそうかなーと思う次第です。
でもう少し調べると
どうやら私なりの結論に至りました。
プログラムのトレンドの移り変わりや
プログラム技術の発展が関わっているように思います。
例えば、今のトレンドではハード周りならならクラウドでしょうか
プログラム技術なら無名関数ですね。
弊社の35歳以上組は
ある意味仕方なく、ある意味好奇心で
こういうのをチャレンジしたりします。
(山口さんは主婦ですがアプリ開発のためにMacintosh Airを購入しています。)
確かに年令を重ね、経験値も増し、出世はするでしょう。
そうなった人で現場から遠ざかる人もいるでしょう。
そうして使い物にならなくなる人もいるのはわかります。
しかし、これを寿命と言っていいのか?ということです。
ここでひとつ思い至ったわけです。
昔、オブジェクト指向が理解できるか、できないかで
プログラマーの壁が生まれた時期がありました。
(調べたら未だにあるようです。)
理解できたと言って、自慢気になっている人もいました。
こいつらのお陰でオブジェクト指向がある意味宗教みたいになった面もありました。(所詮、便利にする道具じゃないか)
つまり、プログラムの技術革新や進化の中で
拒否する人と、拒否しない人がいて
若いうちは逆らえないから
上司の言うままに習得した技術も、出世すれば習得しないわけです。
つまり、単に向いていないだけじゃん。
寿命って言うな。ってことです。
マルチタスクOSになった今のWindowsの基礎を作った
デヴィッド・カトラーは60歳超えてもソースコードを自ら記述しています。
森田将棋の森田和郎さんは『サムライスピリッツ零』等のプログラムを担当し、一昨年、57歳でお亡くなりになるまで現役のプログラマーでした。
結局、「プログラマー35歳定年説」とは
ある種の向いていない人たちのずいぶん馬鹿にした話なんじゃないかと
私は結論づけたわけなのです
(間違ったらすみません。)
ちなみに私、近藤が最近楽しく学んだのはFuelPHPでした。
このフレームワーク、欲しい機能が色々最初から入っている。すごい!!
android開発環境について、あれこれ
2014年01月15日
androidの開発環境は、いろいろなものが登場しています。
そこでざっとオサライをしたく思いまして、調査しました。
●androidの定番開発環境 Javaで開発(eclipse + Android SDK)
androidでは当初からJAVAの開発環境として、上記の組み合わせが推奨されてきました。
このための関連本もたくさんあります。
androidの開発者はアプリをできるだけたくさん作ってほしかったらしく、エンジニア人口の一番多い開発言語Javaを開発言語として採用したそうです。
考えてみればandroidはLinuxベースなので、別にどの開発言語でも良かったわけですね。
●C/C++で開発(eclipse + Android SDK + C/C++開発ツール + Android NDK)
LinuxベースならばC/C++というのも有りかと思いましたら、やはりありました。
AndroidのアプリケーションはDalvikと呼ばれる仮想マシン(バーチャルマシン)の上で動作しています。
DalvikはJava言語で記述されたプログラムの実行環境です。一般的なJavaで記述されたアプリケーションはDalvikを介して実行されるため、Native(C/C++)で書かれたプログラムよりも実行速度が遅くなってしまいます。
NDKは動作速度を向上するために使われるほか、
C/C++環境で開発された資産をライブラリとして(わざわざJavaへ移植しないでよい)活用できるといった利点もあります。一方でJavaの恩恵（GCなど）が得られない、アーキテクチャに依存するなどデメリットもあります(NDKを使うとアプリケーションの動作環境が限られ、対応外のアーキテクチャでは動きません)。
なお、Android 2.2以降では、JIT(Just in Time)コンパイラが導入されて動作速度は改善されています。
eclipseを使用する形はJavaとあまり変わりはないかもしれません。
詳しい組み込みの手順は以下のサイトに有ります。
http://www.kkaneko.com/rinkou/js/andkwin.html
●Javascriptで開発
1.PhoneGapで開発
http://phonegap.com/
PhoneGapは、アドビシステムズが開発しているオープンソースのモバイルデバイス用フレームワーク「Apache Cordova」のディストリビューションの1つです。もともとはカナダのNitobi社が開発を行っているスマートフォン向けのハイブリッドアプリケーション制作のためのフレームワークでした。2011年にアドビ社が、Nitobi社を買収し、現在はオープンソースであるCordovaをアドビ社が配布する時は、PhoneGapという名前になっているそうです。
JavaやObjective-Cを書かなくても、HTMLやCSS、JavaScriptだけで、iOS（iPhone／iPad／iPod touch）・Androidアプリを作成できます。このフレームワークでは、JavaScriptからネイティブAPIへのブリッジ機能を提供しているので、Webの技術を利用して作成したコンテンツからデバイス固有機能を利用できます。
こちらもeclipseを使用する形はJavaとあまり変わりはないかもしれません。
http://www.atmarkit.co.jp/ait/articles/1107/26/news109.html
1-2.PhoneGapベースの統合開発環境
以下は統合された開発環境をクラウドサービスです。開発者はアプリ開発の一連の作業をすべてWebブラウザを通じて行うことができます。
制限付き無料で開発できます。有料の場合の利用料はどちらも似たようなものです。
「Monaca」
http://monaca.mobi/ja/
「Adobe® PhoneGap™ Build」
https://build.phonegap.com/?locale=ja_JP
2.Titanium Mobileで開発
http://www.appcelerator.com/titanium/
http://faq.titanium-mobile.jp/
Titanium Mobileとは、Appcelerator社によるスマートフォン対応アプリケーションの開発環境です。iOS（iPhone／iPad／iPod touch）・Androidアプリを作成できます。
PhoneGapはHTML5やJavaScriptが「そのまま」アプリ化されますが、Titaniumは、一旦JavaScriptをコンパイルしたものがアプリとなります。
統合開発環境として「Titanium Studio」がリリースされており、これだけでまとめて必要なツール類が一気にインストールできます。
ここで紹介している他の開発環境に比べて組み合わせて複数インストール必要もなく、また、PCの環境変数を設定追加する必要もないため、一番簡単なインストール環境かもしれません。
http://titanium-mobile.jimdo.com/titanium-studio%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8Bandroid%E3%82%A2%E3%83%97%E3%83%AA%E9%96%8B%E7%99%BA/%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%82%92%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%B9%E3%81%97/
無料で利用できるのは“Community”プランです。ほかのプランは有料（最初のひと月は無料）ですが，Appcelerator社のサポートが受けられるほか，有料のモジュールが使えるなどさまざまな利点があるようです。
3.Unityで開発
http://japan.unity3d.com/
Unity は、Windows と OS X 上で動作する統合型のゲーム開発環境です。iOS、Android、Windows、Mac OS X、Web、Wii U、PlayStation3、Xbox 360 など様々なプラットフォームへ向けた高度な 3D アプリケーションを制作することが出来ます。
JavaScript、C#、Boo の3つの言語の好きなものを利用して、スクリプトを作成し、オープンソースの .NET プラットフォームである Mono の上でスクリプトが実行されます。
ゲームの舞台となる3Dのシーンの構築ツールなど、はっきり言ってこれは別世界の統合開発ツールです。
UnityとUnity Proの2種類のライセンスがあります。
プロバージョンは1500ドルですが、レギュラーバージョンは無料でダウンロードできます。
プロバージョンではテクスチャーへのレンダリング、オクルージョンカリング、グローバルライトニング、ポストプロセッシングエフェクトといった機能が追加されます。一方無料バージョンではスプラッシュスクリーン（スタンドアロンのゲームにおいて）やウォーターマーク（ウェブゲームにおいて）の表示が絶対に必要です。
●Webサイトをアプリ化
ブラウザアプリのように要はWebサイトをアプリっぽく作ってしまう手法です。
すごく簡単にすぐにでも構築できます。
ただし、Google Playストアには登録できませんけど。
●番外編
よくわかりませんがBasicでも開発できるようです。
下はテトリスのサンプルコードです。Basicで書かれています。
https://code.google.com/p/simple/source/browse/trunk/simple/samples/Tetris/src/com/google/devtools/simple/samples/tetris/Tetris.simple
●それではどれが良いのか
下記のように一長一短があります。
モバイルアプリ開発手法の特徴比較
ハイブリッド(PhoneGap/Titanium)はだんだん改善はされてはいますが、ネイティブで作られたアプリに比べて速度が遅いと感じるケースが多いそうです。
また、PhoneGapは、あくまでHTMLやJavaScriptを使ってアプリを作るためのツールです。
アプリを作る ためのフレームワークやテンプレートが提供されている訳ではありません。
jQuery MobileやSencha Touchといった、ユーザーインターフェースを作るためのツールを組み合わせるのが主流のようです。
(Titanium StudioはOS標準のUIを利用すること前提としています。)
個人的には手のこんだものでなければ、「Titanium Studio」が一番気軽に開発でき、破綻が来たらネイティブ開発(Java)が一番、問題が少ないように感じました。
なんだか当たり前の結論で申し訳ありませんが…
※ところで定番の開発環境は旧公式統合開発環境 Eclipse から 新公式 Android Studioへ移行していますね。
「PhoneGap」も組込みできるようです。
http://www.auraline.co.jp/tech-lab/?p=180
そこでざっとオサライをしたく思いまして、調査しました。
●androidの定番開発環境 Javaで開発(eclipse + Android SDK)
androidでは当初からJAVAの開発環境として、上記の組み合わせが推奨されてきました。
このための関連本もたくさんあります。
androidの開発者はアプリをできるだけたくさん作ってほしかったらしく、エンジニア人口の一番多い開発言語Javaを開発言語として採用したそうです。
考えてみればandroidはLinuxベースなので、別にどの開発言語でも良かったわけですね。
●C/C++で開発(eclipse + Android SDK + C/C++開発ツール + Android NDK)
LinuxベースならばC/C++というのも有りかと思いましたら、やはりありました。
AndroidのアプリケーションはDalvikと呼ばれる仮想マシン(バーチャルマシン)の上で動作しています。
DalvikはJava言語で記述されたプログラムの実行環境です。一般的なJavaで記述されたアプリケーションはDalvikを介して実行されるため、Native(C/C++)で書かれたプログラムよりも実行速度が遅くなってしまいます。
NDKは動作速度を向上するために使われるほか、
C/C++環境で開発された資産をライブラリとして(わざわざJavaへ移植しないでよい)活用できるといった利点もあります。一方でJavaの恩恵（GCなど）が得られない、アーキテクチャに依存するなどデメリットもあります(NDKを使うとアプリケーションの動作環境が限られ、対応外のアーキテクチャでは動きません)。
なお、Android 2.2以降では、JIT(Just in Time)コンパイラが導入されて動作速度は改善されています。
eclipseを使用する形はJavaとあまり変わりはないかもしれません。
詳しい組み込みの手順は以下のサイトに有ります。
http://www.kkaneko.com/rinkou/js/andkwin.html
●Javascriptで開発
1.PhoneGapで開発
http://phonegap.com/
PhoneGapは、アドビシステムズが開発しているオープンソースのモバイルデバイス用フレームワーク「Apache Cordova」のディストリビューションの1つです。もともとはカナダのNitobi社が開発を行っているスマートフォン向けのハイブリッドアプリケーション制作のためのフレームワークでした。2011年にアドビ社が、Nitobi社を買収し、現在はオープンソースであるCordovaをアドビ社が配布する時は、PhoneGapという名前になっているそうです。
JavaやObjective-Cを書かなくても、HTMLやCSS、JavaScriptだけで、iOS（iPhone／iPad／iPod touch）・Androidアプリを作成できます。このフレームワークでは、JavaScriptからネイティブAPIへのブリッジ機能を提供しているので、Webの技術を利用して作成したコンテンツからデバイス固有機能を利用できます。
こちらもeclipseを使用する形はJavaとあまり変わりはないかもしれません。
http://www.atmarkit.co.jp/ait/articles/1107/26/news109.html
1-2.PhoneGapベースの統合開発環境
以下は統合された開発環境をクラウドサービスです。開発者はアプリ開発の一連の作業をすべてWebブラウザを通じて行うことができます。
制限付き無料で開発できます。有料の場合の利用料はどちらも似たようなものです。
「Monaca」
http://monaca.mobi/ja/
「Adobe® PhoneGap™ Build」
https://build.phonegap.com/?locale=ja_JP
2.Titanium Mobileで開発
http://www.appcelerator.com/titanium/
http://faq.titanium-mobile.jp/
Titanium Mobileとは、Appcelerator社によるスマートフォン対応アプリケーションの開発環境です。iOS（iPhone／iPad／iPod touch）・Androidアプリを作成できます。
PhoneGapはHTML5やJavaScriptが「そのまま」アプリ化されますが、Titaniumは、一旦JavaScriptをコンパイルしたものがアプリとなります。
統合開発環境として「Titanium Studio」がリリースされており、これだけでまとめて必要なツール類が一気にインストールできます。
ここで紹介している他の開発環境に比べて組み合わせて複数インストール必要もなく、また、PCの環境変数を設定追加する必要もないため、一番簡単なインストール環境かもしれません。
http://titanium-mobile.jimdo.com/titanium-studio%E3%81%A7%E3%81%AF%E3%81%98%E3%82%81%E3%82%8Bandroid%E3%82%A2%E3%83%97%E3%83%AA%E9%96%8B%E7%99%BA/%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%E3%82%92%E3%81%A4%E3%81%8F%E3%82%8B%E3%81%B9%E3%81%97/
無料で利用できるのは“Community”プランです。ほかのプランは有料（最初のひと月は無料）ですが，Appcelerator社のサポートが受けられるほか，有料のモジュールが使えるなどさまざまな利点があるようです。
3.Unityで開発
http://japan.unity3d.com/
Unity は、Windows と OS X 上で動作する統合型のゲーム開発環境です。iOS、Android、Windows、Mac OS X、Web、Wii U、PlayStation3、Xbox 360 など様々なプラットフォームへ向けた高度な 3D アプリケーションを制作することが出来ます。
JavaScript、C#、Boo の3つの言語の好きなものを利用して、スクリプトを作成し、オープンソースの .NET プラットフォームである Mono の上でスクリプトが実行されます。
ゲームの舞台となる3Dのシーンの構築ツールなど、はっきり言ってこれは別世界の統合開発ツールです。
UnityとUnity Proの2種類のライセンスがあります。
プロバージョンは1500ドルですが、レギュラーバージョンは無料でダウンロードできます。
プロバージョンではテクスチャーへのレンダリング、オクルージョンカリング、グローバルライトニング、ポストプロセッシングエフェクトといった機能が追加されます。一方無料バージョンではスプラッシュスクリーン（スタンドアロンのゲームにおいて）やウォーターマーク（ウェブゲームにおいて）の表示が絶対に必要です。
●Webサイトをアプリ化
ブラウザアプリのように要はWebサイトをアプリっぽく作ってしまう手法です。
すごく簡単にすぐにでも構築できます。
ただし、Google Playストアには登録できませんけど。
●番外編
よくわかりませんがBasicでも開発できるようです。
下はテトリスのサンプルコードです。Basicで書かれています。
https://code.google.com/p/simple/source/browse/trunk/simple/samples/Tetris/src/com/google/devtools/simple/samples/tetris/Tetris.simple
●それではどれが良いのか
下記のように一長一短があります。
モバイルアプリ開発手法の特徴比較
| Webサイトをアプリ化 | ハイブリッド(PhoneGap/Titanium) | ネイティブ開発(Java C/C++) | |
| スキルレベル | ◎ | ○ | △ |
| パフォーマンス | △ | ○ | ◎ |
| デバイス依存性 | ◎ | ○ | △ |
| 開発時間 | ◎ | ○ | △ |
| 開発ライフサイクル | ◎ | ◎ | △ |
| 可搬性 | ◎ | ○ | △ |
| デバイス機能利用 | △ | ○ | ◎ |
| パッケージング | △ | ◎ | ◎ |
| 拡張性 | △ | ◎ | ◎ |
ハイブリッド(PhoneGap/Titanium)はだんだん改善はされてはいますが、ネイティブで作られたアプリに比べて速度が遅いと感じるケースが多いそうです。
また、PhoneGapは、あくまでHTMLやJavaScriptを使ってアプリを作るためのツールです。
アプリを作る ためのフレームワークやテンプレートが提供されている訳ではありません。
jQuery MobileやSencha Touchといった、ユーザーインターフェースを作るためのツールを組み合わせるのが主流のようです。
(Titanium StudioはOS標準のUIを利用すること前提としています。)
個人的には手のこんだものでなければ、「Titanium Studio」が一番気軽に開発でき、破綻が来たらネイティブ開発(Java)が一番、問題が少ないように感じました。
なんだか当たり前の結論で申し訳ありませんが…
※ところで定番の開発環境は旧公式統合開発環境 Eclipse から 新公式 Android Studioへ移行していますね。
「PhoneGap」も組込みできるようです。
http://www.auraline.co.jp/tech-lab/?p=180
来年のアクセス目標を上手に立てたい！
2013年12月13日
こんばんは。とおやまです。
（↑ 弊社オフィス。クリスマスツリーと、誰もいない金曜の夜・・・の図）
いよいよ12月も残り少し！来年に向けて目標を立てている方も多いことでしょう。
わたしは、来年のwomo（うーも。自社webサービスです）の成果目標を検討しています。うう。そろそろ・・・急がなきゃですね。
webサイトのアクセス推移を見ていると、いつも惑わされるのが季節や流行、テレビなどの影響。
対処する術（明らかにトレンドがあるキーワードだったり、逆に、トレンドの影響はスルーすると決めていたり）がある場合は良いですが、そうではないwebサイト、多いですよね。
そこで今回は、この「トレンド」なるものとどう向き合うか、考えたいと思います。
一般的なトレンド、季節要因。
自分たちで行う施策以外に、アクセスの増減に影響するトレンドの代表格は、「季節」。
その影響はサイトによって様々ですが、まずは一般に言われているものを知りたいな、ということで調べました。
他にも、一般的には、各月で1日多かったり少なかったり、土日が他の月と比べて多かったりして変動するでしょう。
サイトに特徴的なトレンド要因はあるか？
さらに、運営しているwebサイトに特徴的なトレンドがある場合は、来年の計画に盛り込んだほうがいいはずです。
明らかにトレンドがある例。
家電はわかりやすいものが多くていいな・・・とつい思ってしまいます。
トレンドがびみょうな例は、こんな感じ。
（あえて微妙になるようにキーワードは選別しています。）
鍋はわかりやすいですね！でも他のは・・・なぜ8月に「ラーメン」・・・。
つまり、月毎の絶対値で比較すると危険、という話。
トレンドの影響がわかりにくい場合、少しの数字変動にビクビクしてしまいがちです。
影響がわかりにくい理由としては、下記があるでしょう。
・多種多様なキーワードやコンテンツを持っている
・季節的影響を推測しにくいコンテンツ
・利用者の属性が幅広い などなど・・・
実際のwomoの事例をご紹介します。
これは、とあるサービスのとある数字（アクセス数と書きますが）の推移です。
7月、8月まではうんうん、なかなかいいぞ、と思っていたのですが9月からアクセス数が下降したため、大変に動揺したのは、何を隠そう、私自身です。こうなるとつい口から出てしまうのは、「き、季節要因ではないでしょうか・・・」というセリフ。
でも、昨年の数字と比較してみると・・・
なんと！
夏に盛り上がった数字は、昨年からの数字の伸びでみるとそうでもないことが判明。逆に10月は、落ちたように見えましたが、昨対ではしっかり伸びているではありませんか！
このように、月別の絶対数値のほか、昨年比やキーワードの流行などを添えるだけで、見え方がずいぶん違います。
そもそも、数字を月別に、合計で比較するのはナンセンスでは？
webサイトにとって大事なのは、「いつ」「だれに」「どのコンテンツが」閲覧されているかということ。（ほかに、「なにで」「どのように」なども。）
そう考えると、webサイトの成果を月別に、合計で確認すること自体がイマイチな感じがしませんか？だって、一つのサイトの中にある様々なコンテンツを、様々な人が見るのだから。コンテンツは、ひとつひとつ、それを求めている人たちにしっかり届けたい。だから、成果の推移は、同じサイトの中でも、コンテンツごとに違うはずです。
実例を示します。
これは、womoネットというサイトの特集カテゴリだけを抜き取ったアクセス数推移。
9月末のシンデレラナイトイベント、
10月末のハロウィン特集、
11月末のクリスマス特集の良さがつたわるというもの！自画自賛！（来年はもっとたくさん特集しなきゃ！）
ですが、同じサイトを合計値の推移で見ると
ぼやけてしまう。
トップページや、会員ログインページなどのアクセスが圧倒的に多いからです。個別に成果を確認すべきコンテンツを把握して、大事な数字を見逃さないようにしたいですね。モチベーションにもつながりますし。
とはいいつつも、やっぱり目標は月別、合計で立てるわけで・・・。
カテゴリ別の数字が伸びても、サイト全体の数字が伸びなければ評価としてはよくありませんので、やっぱり目標は月別、合計になるのはやむをえないです。その場合は、しっかりデータをためて長期的に数字を追うのが良いのだと思います。そうすれば、わかりづらいトレンドも、だんだんと理解できてくるのではないでしょうか。
また、「本当にトレンドの影響なのか？」を検証するには特設ページなどを作ると良いでしょう。狙ったタイミングでアクセスが多ければ、それはおそらくトレンドだと考えることができます。
以上、つたない分析ではありますが何かの参考になれば幸いです。
これで心の整理もついたので、来年の目標、しっかり立てるぞ！
追伸、最近、私達SEチームでは、静岡のお好み焼き＆居酒屋「晴 ハル」さんが流行っています。
ここのお好み焼き、カリっとしていて、生地にしっかり味があって美味しいです。
ランチパスポートで500円なので、毎週水曜日のSEチームランチでリピってますし、チーム忘年会でもおじゃまさせていただきました。
（詳しくは womoグルメ へ。）
そう、つまり何が言いたいかというと、
みんな！忘年会！クリスマス！そう、クリスマス！
飲みに行こうぜ！！！！私は行く！
→ 毎年大好評の企画、忘年会特集を見てくださる方はこちらへ！！
→ クリスマス特集を見てくださる方はこちら。カップル向けのおしゃれなディナーが勢揃いしています！
それでは、また。よろしくお願いします。
（↑ 弊社オフィス。クリスマスツリーと、誰もいない金曜の夜・・・の図）
いよいよ12月も残り少し！来年に向けて目標を立てている方も多いことでしょう。
わたしは、来年のwomo（うーも。自社webサービスです）の成果目標を検討しています。うう。そろそろ・・・急がなきゃですね。
webサイトのアクセス推移を見ていると、いつも惑わされるのが季節や流行、テレビなどの影響。
対処する術（明らかにトレンドがあるキーワードだったり、逆に、トレンドの影響はスルーすると決めていたり）がある場合は良いですが、そうではないwebサイト、多いですよね。
そこで今回は、この「トレンド」なるものとどう向き合うか、考えたいと思います。
一般的なトレンド、季節要因。
自分たちで行う施策以外に、アクセスの増減に影響するトレンドの代表格は、「季節」。
その影響はサイトによって様々ですが、まずは一般に言われているものを知りたいな、ということで調べました。
他にも、一般的には、各月で1日多かったり少なかったり、土日が他の月と比べて多かったりして変動するでしょう。
サイトに特徴的なトレンド要因はあるか？
さらに、運営しているwebサイトに特徴的なトレンドがある場合は、来年の計画に盛り込んだほうがいいはずです。
明らかにトレンドがある例。
家電はわかりやすいものが多くていいな・・・とつい思ってしまいます。
トレンドがびみょうな例は、こんな感じ。
（あえて微妙になるようにキーワードは選別しています。）
鍋はわかりやすいですね！でも他のは・・・なぜ8月に「ラーメン」・・・。
つまり、月毎の絶対値で比較すると危険、という話。
トレンドの影響がわかりにくい場合、少しの数字変動にビクビクしてしまいがちです。
影響がわかりにくい理由としては、下記があるでしょう。
・多種多様なキーワードやコンテンツを持っている
・季節的影響を推測しにくいコンテンツ
・利用者の属性が幅広い などなど・・・
実際のwomoの事例をご紹介します。
これは、とあるサービスのとある数字（アクセス数と書きますが）の推移です。
7月、8月まではうんうん、なかなかいいぞ、と思っていたのですが9月からアクセス数が下降したため、大変に動揺したのは、何を隠そう、私自身です。こうなるとつい口から出てしまうのは、「き、季節要因ではないでしょうか・・・」というセリフ。
でも、昨年の数字と比較してみると・・・
なんと！
夏に盛り上がった数字は、昨年からの数字の伸びでみるとそうでもないことが判明。逆に10月は、落ちたように見えましたが、昨対ではしっかり伸びているではありませんか！
このように、月別の絶対数値のほか、昨年比やキーワードの流行などを添えるだけで、見え方がずいぶん違います。
そもそも、数字を月別に、合計で比較するのはナンセンスでは？
webサイトにとって大事なのは、「いつ」「だれに」「どのコンテンツが」閲覧されているかということ。（ほかに、「なにで」「どのように」なども。）
そう考えると、webサイトの成果を月別に、合計で確認すること自体がイマイチな感じがしませんか？だって、一つのサイトの中にある様々なコンテンツを、様々な人が見るのだから。コンテンツは、ひとつひとつ、それを求めている人たちにしっかり届けたい。だから、成果の推移は、同じサイトの中でも、コンテンツごとに違うはずです。
実例を示します。
これは、womoネットというサイトの特集カテゴリだけを抜き取ったアクセス数推移。
9月末のシンデレラナイトイベント、
10月末のハロウィン特集、
11月末のクリスマス特集の良さがつたわるというもの！自画自賛！（来年はもっとたくさん特集しなきゃ！）
ですが、同じサイトを合計値の推移で見ると
ぼやけてしまう。
トップページや、会員ログインページなどのアクセスが圧倒的に多いからです。個別に成果を確認すべきコンテンツを把握して、大事な数字を見逃さないようにしたいですね。モチベーションにもつながりますし。
とはいいつつも、やっぱり目標は月別、合計で立てるわけで・・・。
カテゴリ別の数字が伸びても、サイト全体の数字が伸びなければ評価としてはよくありませんので、やっぱり目標は月別、合計になるのはやむをえないです。その場合は、しっかりデータをためて長期的に数字を追うのが良いのだと思います。そうすれば、わかりづらいトレンドも、だんだんと理解できてくるのではないでしょうか。
また、「本当にトレンドの影響なのか？」を検証するには特設ページなどを作ると良いでしょう。狙ったタイミングでアクセスが多ければ、それはおそらくトレンドだと考えることができます。
以上、つたない分析ではありますが何かの参考になれば幸いです。
これで心の整理もついたので、来年の目標、しっかり立てるぞ！
追伸、最近、私達SEチームでは、静岡のお好み焼き＆居酒屋「晴 ハル」さんが流行っています。
ここのお好み焼き、カリっとしていて、生地にしっかり味があって美味しいです。
ランチパスポートで500円なので、毎週水曜日のSEチームランチでリピってますし、チーム忘年会でもおじゃまさせていただきました。
（詳しくは womoグルメ へ。）
そう、つまり何が言いたいかというと、
みんな！忘年会！クリスマス！そう、クリスマス！
飲みに行こうぜ！！！！私は行く！
→ 毎年大好評の企画、忘年会特集を見てくださる方はこちらへ！！
→ クリスマス特集を見てくださる方はこちら。カップル向けのおしゃれなディナーが勢揃いしています！
それでは、また。よろしくお願いします。
ゲーミフィケーションで思うあれこれ
2013年11月18日
ゲーミフィケーション。少しこの業界の人ですと、最近では当たり前の使い古された言葉に感じる人も多いかと思います。
(業界の人以外では、聞きなれない言葉でよね。ごめんなさい。)
この業界の人ならば、改めて問いますが皆様はゲーミフィケーションって、あなたはどのような定義をされますか?
実は、この言葉、定まっていないのです。
だいたい固まっているのは、広義の意味では、ようするに、ゲームっぽくて役に立つものならなんでも。
狭義ならば、ゲームのノウハウを利用して、ユーザに体験させるための最適なフィードバック設計のノウハウのこと。
・・・広義でも狭義でも、なんだかよくわからないですよね。
そもそもここで言うゲームとはなんでしょうか?
例えばRPG。コンピュータゲームが流行る前からのRPGと言えば、ダンジョンズ&ドラゴンズに代表されるテーブルトークRPGです。
でも、テーブルトークRPGって、みんな知りませんよね。
では、コンピュータゲームのRPGって、元祖は何ですか?有名なところならばウルティマかウィザードリィです。
しかし、これ、遊んだことのある人のほうが今は少数派なんですよね。
それでは、今となってはほとんど死に絶えたジャンル、アドベンチャーゲームって知っていますか?
代表的なアドベンチャーゲームといえば「ミステリーハウス」でしょうか?
・
・
・
あー違う。違う。
・
・
・
こんなものを紹介しているとどんどん本質から遠ざかります。
つまり、何が言いたいのかというと
それはゲームではないということです。
ゲーミフィケーションとはゲームではないということです。
ゲーミフィケーションとはゲームのノウハウを利用した取り組みのことです。
そして、それは体験です。
ゲームはある時期から素晴らしいインタフェースを備えました。
そのエポックメイキングはみなさんもお馴染みのドラクエです。
ドラクエはファミコンで登場しました。
それまではRPGといえばパソコンでした。
パソコンはキーボードがあり、ファミコンにはありません。
それまでのパソコンのRPGは、キーボードでコマンドを入力していました。
例えば「GO WEST」とか。
これで西に移動するわけですね。キーボードが対話のインタフェースだったのです。
ファミコンにはそれはありません。
そこで、十字キーで場所を移動し、ウインドウを表示し、あらかじめ用意された選択肢を選ぶ、コマンド選択型のインターフェースが登場したのです。
これは衝撃でした。
それまでは、難しすぎて、遊ぶこと、そのものが難しかったコンピュータゲームがだれでも手軽に遊べるゲームになった瞬間だからです。
ファミコンの登場に合わせ、パソコンのゲームもそれまでと変わり、だれでも楽しめる種類のものが増えていきました。
(全般的にファミコンよりも難易度は高めで、操作も複雑でしたが。)
ともかく、これ以降、コンピュータゲーム=ゲームはインターフェースの進化とともにありました。
例えば、個人的にプレイステーション1で最強のインターフェースをもつゲームは、このゲームだと思います。
今となってはとても低い性能のプレイステーション1でテクノ風の音楽のテンポに合わせ、VJっぽくインターフェースが小気味よく展開していきます。
(その分いろいろなところを犠牲にしたゲームでしたが)
さてさて、そして、ここまで書いて、ここから私が言いたかったことに入らせていただきます。
私はゲーミフィケーションがゲームのノウハウを利用したものであるならば、ゲーミフィケーションについて書かれたビジネス書は全く無駄だと思っています。
そもそもビジネス書を読むターゲット層は、本当にゲームが好きですか?
ゲーミフィケーションはゲームが好きで好きでたまらない人が、生み出すインターフェースの別の形です。
(と、私は思います。)
そういったゲーミフィケーションとは何か?ということです。
一時期、「Dの食卓」で一世を風靡したゲームクリエイター「飯野賢治」氏は、ゲームの表舞台から去ってしまいました。
そして、その後、彼は街角のサイネージ端末にゲームのノウハウを活かして提供していたのです。
その彼が手がけていた仕事はゲーミフィケーションという言葉がある前からのゲーミフィケーションでした。
http://www.fyto.com/services01.html
http://www.canvas.ws/jp/workshop/ws29/report.html
しかし、2013年2月、42歳の彼は故人となりました。
おそらくはゲーミフィケーションという言葉は流行り言葉で、すぐに廃れるでしょう。
しかし、ゲームが試行錯誤のすえ、生み出した優れた体験感覚やインタフェースは、今後も廃れることはないでしょう。
彼の死を惜しみつつ2013年の終わりに近づいた今日、この時を我々はより良い製品はどうあるべきか。
我々は知恵を一生懸命に絞り、次の時2014年、また次の年でより良くしていきたいと思っています。
なお、私はモンハン4のハンターランクを最近やっと開放しました。
(こんなペースでは本当に優れたゲーミフィケーションは遠いなぁと思いつつ)
(業界の人以外では、聞きなれない言葉でよね。ごめんなさい。)
この業界の人ならば、改めて問いますが皆様はゲーミフィケーションって、あなたはどのような定義をされますか?
実は、この言葉、定まっていないのです。
だいたい固まっているのは、広義の意味では、ようするに、ゲームっぽくて役に立つものならなんでも。
狭義ならば、ゲームのノウハウを利用して、ユーザに体験させるための最適なフィードバック設計のノウハウのこと。
・・・広義でも狭義でも、なんだかよくわからないですよね。
そもそもここで言うゲームとはなんでしょうか?
例えばRPG。コンピュータゲームが流行る前からのRPGと言えば、ダンジョンズ&ドラゴンズに代表されるテーブルトークRPGです。
でも、テーブルトークRPGって、みんな知りませんよね。
では、コンピュータゲームのRPGって、元祖は何ですか?有名なところならばウルティマかウィザードリィです。
しかし、これ、遊んだことのある人のほうが今は少数派なんですよね。
それでは、今となってはほとんど死に絶えたジャンル、アドベンチャーゲームって知っていますか?
代表的なアドベンチャーゲームといえば「ミステリーハウス」でしょうか?
・
・
・
あー違う。違う。
・
・
・
こんなものを紹介しているとどんどん本質から遠ざかります。
つまり、何が言いたいのかというと
それはゲームではないということです。
ゲーミフィケーションとはゲームではないということです。
ゲーミフィケーションとはゲームのノウハウを利用した取り組みのことです。
そして、それは体験です。
ゲームはある時期から素晴らしいインタフェースを備えました。
そのエポックメイキングはみなさんもお馴染みのドラクエです。
ドラクエはファミコンで登場しました。
それまではRPGといえばパソコンでした。
パソコンはキーボードがあり、ファミコンにはありません。
それまでのパソコンのRPGは、キーボードでコマンドを入力していました。
例えば「GO WEST」とか。
これで西に移動するわけですね。キーボードが対話のインタフェースだったのです。
ファミコンにはそれはありません。
そこで、十字キーで場所を移動し、ウインドウを表示し、あらかじめ用意された選択肢を選ぶ、コマンド選択型のインターフェースが登場したのです。
これは衝撃でした。
それまでは、難しすぎて、遊ぶこと、そのものが難しかったコンピュータゲームがだれでも手軽に遊べるゲームになった瞬間だからです。
ファミコンの登場に合わせ、パソコンのゲームもそれまでと変わり、だれでも楽しめる種類のものが増えていきました。
(全般的にファミコンよりも難易度は高めで、操作も複雑でしたが。)
ともかく、これ以降、コンピュータゲーム=ゲームはインターフェースの進化とともにありました。
例えば、個人的にプレイステーション1で最強のインターフェースをもつゲームは、このゲームだと思います。
今となってはとても低い性能のプレイステーション1でテクノ風の音楽のテンポに合わせ、VJっぽくインターフェースが小気味よく展開していきます。
(その分いろいろなところを犠牲にしたゲームでしたが)
さてさて、そして、ここまで書いて、ここから私が言いたかったことに入らせていただきます。
私はゲーミフィケーションがゲームのノウハウを利用したものであるならば、ゲーミフィケーションについて書かれたビジネス書は全く無駄だと思っています。
そもそもビジネス書を読むターゲット層は、本当にゲームが好きですか?
ゲーミフィケーションはゲームが好きで好きでたまらない人が、生み出すインターフェースの別の形です。
(と、私は思います。)
そういったゲーミフィケーションとは何か?ということです。
一時期、「Dの食卓」で一世を風靡したゲームクリエイター「飯野賢治」氏は、ゲームの表舞台から去ってしまいました。
そして、その後、彼は街角のサイネージ端末にゲームのノウハウを活かして提供していたのです。
その彼が手がけていた仕事はゲーミフィケーションという言葉がある前からのゲーミフィケーションでした。
http://www.fyto.com/services01.html
http://www.canvas.ws/jp/workshop/ws29/report.html
しかし、2013年2月、42歳の彼は故人となりました。
おそらくはゲーミフィケーションという言葉は流行り言葉で、すぐに廃れるでしょう。
しかし、ゲームが試行錯誤のすえ、生み出した優れた体験感覚やインタフェースは、今後も廃れることはないでしょう。
彼の死を惜しみつつ2013年の終わりに近づいた今日、この時を我々はより良い製品はどうあるべきか。
我々は知恵を一生懸命に絞り、次の時2014年、また次の年でより良くしていきたいと思っています。
なお、私はモンハン4のハンターランクを最近やっと開放しました。
(こんなペースでは本当に優れたゲーミフィケーションは遠いなぁと思いつつ)
静岡県民待望の新感覚サービス。開発者の熱い思い。
2013年08月21日
こんにちは！
今日は、静岡県民待望の、新感覚イベントサイトがOPENするので記念に社内インタビュー記事を掲載いたします。
何がそんなに、静岡県民を待たせたのか、何が新感覚なのか。
生みの親でSOLアイアーキテクト代表の山本が語らせていただきます。
---- どんなサービスなんですか？
サービス名は、「tumugu （つむぐ）」。
イベント情報をつむぐ、イベントと利用者のみなさんとの関係をつむぐ、サービスを利用するすべてのみなさんの思いと思いをつむぐ、という意味が込められた名前で、ちょっと特徴のあるイベント情報サイトです。
静岡に暮らすみなさんにもっとぴったりの情報をお届けしたいとずっと思っていました。
イベントを検索できるサイトは、東京で作られたものだったり大規模すぎたりして、静岡のみなさんにはしっくりきていないんですよね。
実は、静岡にも本当にたくさんのイベントがあって、ホームページやブログでも情報は流れています。
でも散在していて、まとめて探すのはすごく大変。
そこでこのサービスは、「静岡県内のイベントをたくさん見る」「口コミでイベントを広める」「みんなが知りたいことを聞く」ことができるようにしました。
イベント情報を集積して検索しやすくしたらみんなが楽しく使ってくれるんじゃないかという発想です。
---- なるほど。確かに、イベント情報はどっかにまとまっていればいいのにな～と思っていました。
そうですよね。
私自身、休日に子供と遊びに行くとしても、いつも近場の公園かデパートを選んでしまっていましたが、このアプリで探してみると、すごくいいですよ。
使った人にしか、このしっくり感はわからないと思います！
---- しっくり感ですか？
はい。実はログイン時にFacebookと連携していただくと、弊社独自の言語解析エンジン「Lotus（ロータス）」によって、自分にぴったりの情報を優先して表示してくれる機能があるんです。
---- ほう。言語解析エンジンですか。
（近藤）もー！本当にたいへんだったんだよー！ロータスの開発はー！！！
---- ちょっ。割り込まないでください。（近藤は、弊社のシステムエンジニアであります。）
（突っ込み無視） ロータスというのは、Facebookに書き込んだ情報を解析して得られたサービス利用者の属性と、各イベント情報を解析して得られた属性とをマッチングさせるエンジンです。たとえば、「犬が好き」な方がいますよね。その方には、数ある情報の中から犬の情報を優先してお出しできるようになっています。さらに、小型犬が好きなら小型犬の、ペキニーズが好きならペキニーズの情報をお出しします。
---- なんだかそれってすごいですね。
でしょう。そのうえ開発期間も短かったから、ほんと辛かった（涙）。
---- その辛さはどうやって乗り越えたんですか？
それはね、作りたいものがあるのならば
システムエンジニアたるもの、
男は黙ってコーディング、涙が出てもコーディング、夢の中でもコーディング、これだよ。
---- （(；゜Д゜)ｶﾞｸﾌﾞﾙ
というのは冗談ですよ。でもやり遂げた後の泥酔は気持ちよかった。
---- その機能が、しっくり感を演出しているというわけですね。
（山本）そうです。使った方には、なるほどと思っていただけるのではないでしょうか。新感覚だと思います！
たとえば今週末に静岡のデパートでどんな催し物があるのか、その日の当日の新聞折り込みでチェックしている方。tumuguなら、もっと早くその情報をご提供できますよ。
情報がマッチする精度は、tumuguを使えば使うほど高まります。また、システム的にももっと良くしていきます。
欲しい情報が簡単に、早く手に入る感覚。楽しんでいただきたいですね。よろしくお願いします。
そういえばそろそろ社員旅行の季節だな～と思い、昨年の社員旅行の写真とともに本インタビューをお送りいたしました。
今年の社員旅行先も、tumuguで決まる・・・のか！？（いいけど・・・）
●ご案内ページ
http://www.iarchitect.co.jp/tumugu/
●スマートフォンサイト
http://tumugu.me/
●iPadアプリダウンロード
https://itunes.apple.com/us/app/id686934319?mt=8&ign-mpt=uo%3D4
すごいwebマーケティングをしている、とあるアパレルメーカーの広告メールを分析してみた
2013年08月10日
こんにちは、とーやまです。昨日、「しずおか”おまち”で夏祭り」イベントサイトをオープンしましたよ！ぜひご参加下さいね。
さてさて、先日、入門機械学習 読書会＠静岡 4回目に行ってきました。
勉強会の前にみんなで集まってお昼ご飯食べたり、おみやげもらったり、和やかな勉強会です。
↑こちらは、清水のB級グルメ、もつカレー。夜の打ち上げでいただきました。うまー。
「機械学習」って何か、ということを簡単にお伝えしますと、
それはまさに バイオハザードの「レッド・クイーン」であり、
ターミネーターの「スカイネット」であり、
手塚治虫の火の鳥に出てくるロボットたちであります。
コンピュータに情報を集めて分析させることで、何らかの規則性や判断基準などを抽出していこうとすることで、アルゴリズム（算数の証明問題を解くような感じ）を発展させていくこと。集合知とか、統計とかに関係が深いです。
この勉強会に参加して、はや４回目が終わりました。
そろそろ何かできるだろってことで、ずーっと仕事でやりたいなと思ってた自社webサービスに送られるメールの分析をすることにしました。
ただその内容はブログでは書けないので、試しに某アパレルメーカーさんからのメールで実験してみることにしましたよ。
このメーカーの会員になっていると、メール受信やらポップアップ通知やら来ます。靴下を頂いたこともあります。ありがとうございます。
そのメールを、いったい何時に受信しているか？をRを使ってまとめてみよう。きっと、マーケティングに最適な時間に送信されているはずなので、参考にさせていただきますね。ホクホク。
1.受信したメールのリストを取得
2.RStudioでリストを読み込む
3.とりあえず受信時刻をグラフ化
4.もそっと見やすい形に変更
1. 受信したメールのリストを取得
わたしはthunderbirdを使ってるので、アドオンでImportExportToolsを追加して、あとは右クリック > フォルダ内のすべてのメッセージをエクスポート > インデックスのみ(CSV)を選ぶだけで、受信メールのリストが出力できます。
かんたん。
ただ、この企業からのだけが欲しかったから、まずはメールをフォルダ分けして、そのフォルダの受信リストを出力しました（ImportExportToolsでフィルタをかけようとしてもうまくいかなかった）。あ、当然だけどUTF-8で出力されますー。
さて、取得できたら、欲しいのは時間だけなので、リストの受信日時の列だけのリストに加工しました。
できあがったのはこんな感じのリスト。
なんだかすでに答えが見えてる気がしますが、とりあえずRを自分なりに動かすことが大事だと思うのでこのまま突き進みます。
2. Rstudioでリストを読み込む
リスト読み込みます。
mail.gu <- read.delim('GU_20130623-0641.csv',sep=",",stringsAsFactors=FALSE,header=TRUE,na.strings="")
はい。で、日付と時刻の列を作ってみました。
maildate <- strsplit(mail.gu$DATA," ")
maildate <- matrix(unlist(maildate),ncol=2, byrow=TRUE)
mail.gu <- transform(mail.gu,DATE=maildate[,1])
mail.gu <- transform(mail.gu,TIME=maildate[,2])
よし。ここまでで、データはこんな感じになりましたん。
3. とりあえず受信時刻をグラフ化
グラフ化します。
ggplot(mail.gu,aes(x=TIME))+geom_histogram(binwidth=1)
その結果。
むう、もうちょっと見やすくせねばね。
4. もそっと見やすいかたちに変更
何時台に受信してるかがとりあえず集計できればいいかな？ってことで、TIME列から「時」だけ取り出そうと思ったんですけど、
mailtime <- strsplit(mail.gu$TIME,":")
これだけだとエラーが出ました。
Error in strsplit(mail.gu$TIME, ":") : non-character argument
え〜。ちゃんとTIMEを文字として処理してくれないのかな？ってことで
mailtime <- strsplit(paste(mail.gu$TIME,""),":")
これでうまくいきました。
（※ここでエラーが出なかった方は、この行を無視していただいたらうまく動くようです。）
あとはこんな感じ。
mailtime <- matrix(unlist(mailtime),ncol=2, byrow=TRUE)
mail.gu <- transform(mail.gu,HOUR=mailtime[,1])
ggplot(mail.gu,aes(x=HOUR))+geom_histogram(binwidth=1)
はい。結果がこれ。
なんかまだイマイチじゃん。なんで最後に８がでてるんだろ？
って調べたら、ggplotが勝手に文字列ソートしてくれれるらしいです。そこで、reorderを使うようにしました。
mailhournum <- as.numeric(as.character(mail.gu$HOUR))
mail.gu <- transform(mail.gu,HOUR_NUM=mailhournum)
ggplot(mail.gu,aes(x=reorder(HOUR,HOUR_NUM)))+geom_histogram(binwidth=1)
ここのコード、もっと短くできるかも。
それで、これが結果。
できた〜！
ふー。よかった。何曜日にたくさん来るかとかも調べたいですね。答えはわかってる気がしますけど。
そういうわけで、いつも粘り強く教えてくださる講師のみなさま、ありがとうございます。次回は掛川で7/27に開催予定、楽しみです。
参考書はこちら
参考にしたサイト
http://rfunction.com/archives/1499
http://www.okada.jp.org/RWiki/?R%A4%CE%CA%B8%BB%FA%CE%F3%BD%E8%CD%FD%B4%D8%BF%F4#i846e199
http://d.hatena.ne.jp/triadsou/20110701/1309496186
さてさて、先日、入門機械学習 読書会＠静岡 4回目に行ってきました。
勉強会の前にみんなで集まってお昼ご飯食べたり、おみやげもらったり、和やかな勉強会です。
↑こちらは、清水のB級グルメ、もつカレー。夜の打ち上げでいただきました。うまー。
「機械学習」って何か、ということを簡単にお伝えしますと、
それはまさに バイオハザードの「レッド・クイーン」であり、
ターミネーターの「スカイネット」であり、
手塚治虫の火の鳥に出てくるロボットたちであります。
コンピュータに情報を集めて分析させることで、何らかの規則性や判断基準などを抽出していこうとすることで、アルゴリズム（算数の証明問題を解くような感じ）を発展させていくこと。集合知とか、統計とかに関係が深いです。
この勉強会に参加して、はや４回目が終わりました。
そろそろ何かできるだろってことで、ずーっと仕事でやりたいなと思ってた自社webサービスに送られるメールの分析をすることにしました。
ただその内容はブログでは書けないので、試しに某アパレルメーカーさんからのメールで実験してみることにしましたよ。
このメーカーの会員になっていると、メール受信やらポップアップ通知やら来ます。靴下を頂いたこともあります。ありがとうございます。
そのメールを、いったい何時に受信しているか？をRを使ってまとめてみよう。きっと、マーケティングに最適な時間に送信されているはずなので、参考にさせていただきますね。ホクホク。
1.受信したメールのリストを取得
2.RStudioでリストを読み込む
3.とりあえず受信時刻をグラフ化
4.もそっと見やすい形に変更
1. 受信したメールのリストを取得
わたしはthunderbirdを使ってるので、アドオンでImportExportToolsを追加して、あとは右クリック > フォルダ内のすべてのメッセージをエクスポート > インデックスのみ(CSV)を選ぶだけで、受信メールのリストが出力できます。
かんたん。
ただ、この企業からのだけが欲しかったから、まずはメールをフォルダ分けして、そのフォルダの受信リストを出力しました（ImportExportToolsでフィルタをかけようとしてもうまくいかなかった）。あ、当然だけどUTF-8で出力されますー。
さて、取得できたら、欲しいのは時間だけなので、リストの受信日時の列だけのリストに加工しました。
できあがったのはこんな感じのリスト。
なんだかすでに答えが見えてる気がしますが、とりあえずRを自分なりに動かすことが大事だと思うのでこのまま突き進みます。
2. Rstudioでリストを読み込む
リスト読み込みます。
mail.gu <- read.delim('GU_20130623-0641.csv',sep=",",stringsAsFactors=FALSE,header=TRUE,na.strings="")
はい。で、日付と時刻の列を作ってみました。
maildate <- strsplit(mail.gu$DATA," ")
maildate <- matrix(unlist(maildate),ncol=2, byrow=TRUE)
mail.gu <- transform(mail.gu,DATE=maildate[,1])
mail.gu <- transform(mail.gu,TIME=maildate[,2])
よし。ここまでで、データはこんな感じになりましたん。
3. とりあえず受信時刻をグラフ化
グラフ化します。
ggplot(mail.gu,aes(x=TIME))+geom_histogram(binwidth=1)
その結果。
むう、もうちょっと見やすくせねばね。
4. もそっと見やすいかたちに変更
何時台に受信してるかがとりあえず集計できればいいかな？ってことで、TIME列から「時」だけ取り出そうと思ったんですけど、
mailtime <- strsplit(mail.gu$TIME,":")
これだけだとエラーが出ました。
Error in strsplit(mail.gu$TIME, ":") : non-character argument
え〜。ちゃんとTIMEを文字として処理してくれないのかな？ってことで
mailtime <- strsplit(paste(mail.gu$TIME,""),":")
これでうまくいきました。
（※ここでエラーが出なかった方は、この行を無視していただいたらうまく動くようです。）
あとはこんな感じ。
mailtime <- matrix(unlist(mailtime),ncol=2, byrow=TRUE)
mail.gu <- transform(mail.gu,HOUR=mailtime[,1])
ggplot(mail.gu,aes(x=HOUR))+geom_histogram(binwidth=1)
はい。結果がこれ。
なんかまだイマイチじゃん。なんで最後に８がでてるんだろ？
って調べたら、ggplotが勝手に文字列ソートしてくれれるらしいです。そこで、reorderを使うようにしました。
mailhournum <- as.numeric(as.character(mail.gu$HOUR))
mail.gu <- transform(mail.gu,HOUR_NUM=mailhournum)
ggplot(mail.gu,aes(x=reorder(HOUR,HOUR_NUM)))+geom_histogram(binwidth=1)
ここのコード、もっと短くできるかも。
それで、これが結果。
できた〜！
ふー。よかった。何曜日にたくさん来るかとかも調べたいですね。答えはわかってる気がしますけど。
そういうわけで、いつも粘り強く教えてくださる講師のみなさま、ありがとうございます。次回は掛川で7/27に開催予定、楽しみです。
参考書はこちら
参考にしたサイト
http://rfunction.com/archives/1499
http://www.okada.jp.org/RWiki/?R%A4%CE%CA%B8%BB%FA%CE%F3%BD%E8%CD%FD%B4%D8%BF%F4#i846e199
http://d.hatena.ne.jp/triadsou/20110701/1309496186
女性がわくわくするコンテンツ、今月もたっぷり公開です！
2013年07月23日
こんにちは！システムエンジニア改めwomoのウェブ副編集長のとおやまです。
本日は、弊社が静岡の女性向けに運営「womo（うーも）」のフリーペーパー発行日＆webサービス更新日！
webでも、新しいコンテンツをたくさん公開することができました。
その一部を、３つご紹介します。ちょっとだけエンジニア視点を混ぜながら。どのコンテンツもおもしろいですよ～！
1. シンデレラナイト 一夜限りのスペシャル300人女子会！！
女子の、女子による、女子のためのイベント 「シンデレラナイト」 特設サイトがオープンしました！
ご覧になったら、絶対に行きたくなりますよ！私、スタッフとして連れてってとお願いしてみたのですが、チケットを買えと一蹴されました・・・え～、強気～（何様；）。とにかく魅力的なイベントです。当日が楽しみ！
それにしても、よくできたサイトです（・・・自画自賛できるほどに！！）。
スマートフォンにも完全対応しています。
ベース構築は、PHP（Zend Framework）で行っていますが、制作にシステムエンジニアの手は入っておりません。デザイナー（兼HTMLコーダー）だけでとてもスピーディーに制作しました。
そんなことが出来たのはなぜか。もちろん、関わった2人のデザイナーが優秀なことは間違いありません。
そしてさらに、陰の立役者が一人。それは、womoのためのワークセットを構築した、近藤です。
例えば、このサイトはPCもスマートフォンも同じURLです。
クライアントの端末がPCかスマートフォンかを判断し、どちら用のテンプレートを使うべきか勝手に制御してくれるのです。
（こんな感じのワークセットです。→）
ちょっとしたことですが、こうした工夫の積み重ねが、効率化につながっています！
2.womoビューティー ネイルタイプ診断
私はあんまりネイルしないので、診断結果は オールシーズン×シンプル がオススメと出ました。
中でも個人的にいいなぁ～と思ったのはこのネイル。
http://shizuoka.womo.jp/beauty/shop/menudetail/serviceid/3420/ID/188
今回のネイルタイプ診断は、ちょっとしたオマケ機能なので、サクサク軽快に動かしたかったです。
そこで使用したのが JSBin というwebサービス。
ブラウザの1画面で、HTMLもCSSもJSも書けて、変更のたびに勝手に更新してくれて、DOM操作やエラーまで確認できて、更にはバージョン管理まで自動でしてくれるすごいサービスです。webサービスなので、そのままスマートフォン実機でも動作確認できます。
普通に作ってたら、書いて⇒リロードして⇒確認 という作業を繰り返すのが、 書いて⇒書いて⇒書いて⇒完成！ になる感覚。ちょっとしたコーディングならすぐできちゃうかも！？便利でした。
3.クーポンがもっと便利に！ PCで確認したクーポンを、自分の携帯に送信！
womoには、いっぱいクーポン情報が載っています。
エステ初回割引や、ヘアサロンのカラー割引、居酒屋さんで乾杯無料！なんてのも。
クーポンは、印刷またはスマートフォン画面提示のどちらでも利用可能なので、
パソコンで見つけたクーポンを、お店でスマートフォンでサクッと見れたら便利ってことで、クーポンをメール送信できる機能が付きました。
今や、womoのお客様のうち60%以上の方がスマートフォンをお使いです。
（弊社サービス womoビューティー のご利用環境統計 →）
きっと、生活の様々なシーンで（電車で、カフェで、おうちで、友達と、お昼休みや、子育てしながらでも）お使いいただいているのだろうな、とうれしくなります。
ありがとうございます。
もっと、女性が使いやすいサービスになるよう工夫していく所存です！
他にも、弊社のサービスやイベントは魅力たっぷり！ぜひご利用ください。そしてお気軽にご感想お寄せ下さいね。
まさかの、ここまで読んでくださった同業（システムエンジニア）の男性の方。優しい貴方。
womoプレミアム合コンをおすすめしますぞ！！花火大会の前に、運命の人との出会いをサポートします。
http://womo.jp/campaign/goukon1306/w/0
それでは、アディオスアミーゴ！
本日は、弊社が静岡の女性向けに運営「womo（うーも）」のフリーペーパー発行日＆webサービス更新日！
webでも、新しいコンテンツをたくさん公開することができました。
その一部を、３つご紹介します。ちょっとだけエンジニア視点を混ぜながら。どのコンテンツもおもしろいですよ～！
1. シンデレラナイト 一夜限りのスペシャル300人女子会！！
女子の、女子による、女子のためのイベント 「シンデレラナイト」 特設サイトがオープンしました！
ご覧になったら、絶対に行きたくなりますよ！私、スタッフとして連れてってとお願いしてみたのですが、チケットを買えと一蹴されました・・・え～、強気～（何様；）。とにかく魅力的なイベントです。当日が楽しみ！
それにしても、よくできたサイトです（・・・自画自賛できるほどに！！）。
スマートフォンにも完全対応しています。
ベース構築は、PHP（Zend Framework）で行っていますが、制作にシステムエンジニアの手は入っておりません。デザイナー（兼HTMLコーダー）だけでとてもスピーディーに制作しました。
そんなことが出来たのはなぜか。もちろん、関わった2人のデザイナーが優秀なことは間違いありません。
そしてさらに、陰の立役者が一人。それは、womoのためのワークセットを構築した、近藤です。
例えば、このサイトはPCもスマートフォンも同じURLです。
クライアントの端末がPCかスマートフォンかを判断し、どちら用のテンプレートを使うべきか勝手に制御してくれるのです。
（こんな感じのワークセットです。→）
ちょっとしたことですが、こうした工夫の積み重ねが、効率化につながっています！
2.womoビューティー ネイルタイプ診断
私はあんまりネイルしないので、診断結果は オールシーズン×シンプル がオススメと出ました。
中でも個人的にいいなぁ～と思ったのはこのネイル。
http://shizuoka.womo.jp/beauty/shop/menudetail/serviceid/3420/ID/188
今回のネイルタイプ診断は、ちょっとしたオマケ機能なので、サクサク軽快に動かしたかったです。そこで使用したのが JSBin というwebサービス。
ブラウザの1画面で、HTMLもCSSもJSも書けて、変更のたびに勝手に更新してくれて、DOM操作やエラーまで確認できて、更にはバージョン管理まで自動でしてくれるすごいサービスです。webサービスなので、そのままスマートフォン実機でも動作確認できます。
普通に作ってたら、書いて⇒リロードして⇒確認 という作業を繰り返すのが、 書いて⇒書いて⇒書いて⇒完成！ になる感覚。ちょっとしたコーディングならすぐできちゃうかも！？便利でした。
3.クーポンがもっと便利に！ PCで確認したクーポンを、自分の携帯に送信！
womoには、いっぱいクーポン情報が載っています。
エステ初回割引や、ヘアサロンのカラー割引、居酒屋さんで乾杯無料！なんてのも。
クーポンは、印刷またはスマートフォン画面提示のどちらでも利用可能なので、
パソコンで見つけたクーポンを、お店でスマートフォンでサクッと見れたら便利ってことで、クーポンをメール送信できる機能が付きました。
今や、womoのお客様のうち60%以上の方がスマートフォンをお使いです。（弊社サービス womoビューティー のご利用環境統計 →）
きっと、生活の様々なシーンで（電車で、カフェで、おうちで、友達と、お昼休みや、子育てしながらでも）お使いいただいているのだろうな、とうれしくなります。
ありがとうございます。
もっと、女性が使いやすいサービスになるよう工夫していく所存です！
他にも、弊社のサービスやイベントは魅力たっぷり！ぜひご利用ください。そしてお気軽にご感想お寄せ下さいね。
まさかの、ここまで読んでくださった同業（システムエンジニア）の男性の方。優しい貴方。
womoプレミアム合コンをおすすめしますぞ！！花火大会の前に、運命の人との出会いをサポートします。
http://womo.jp/campaign/goukon1306/w/0
それでは、アディオスアミーゴ！
