webブラウザの気持ちになってコードを書きたい
2016年11月18日
こんにちは。webエンジニア1年生です。
HTML/CSS/javascriptの「書き方」がなんとなくわかり始めてきた気がするこの頃です。
ふと気になることがあります。
「HTML文書はwebブラウザによってどのように処理され最終的にページとして描画されるの？」
「webブラウザってGPUを利用する事ってあるの？あるならどんなケースで利用されるの？」
気になりませんか？ググってみました。調べればなんでも情報が得られるってほんとうに素晴らしい世の中。
1. HTML文書はwebブラウザによってどのように処理されるの？
結論を言えば下記辺りのページをなんとなく眺めればなんとなく理解できてしまうはず。
とってもわかりやすく解説されてます。
ブラウザの仕組み: 最新ウェブブラウザの内部構造
ブラウザにやさしいHTML/CSS
理解するに越した事はないですがwebコンテンツを作るという立場ならば、とりあえずの理解はなんとなくできれば良いのかなと思っています。仕様は各レンダリングエンジンによって異なるし、仕様すら日々変わっていくだろうから、現状の仕様を端から端まで完璧に理解する必要はかならずしも無いなぁと個人的には思います。が、動作の概略を理解する事はwebコンテンツを作る上で有益なのは間違いない。「書き方」だけでなく「動作」を知る事で、webで可能な新しい表現・最適化・デバッグの面できっと助けになる。はず。
なにかを極めるには、それよりも下のレイヤーの技術も含めて理解する事が大切だと誰かに言われました。
2. 「webブラウザってGPUを利用する事ってあるの？あるならどんなケースで利用されるの？」
そもそもGPUとは？という詳細は端折りますが、描画機能に特化したCPUと並列で動作できるハードウェアとでもいいましょうか。いろいろなGPUアーキテクチャが存在するので、細かい動作や機能は異なりますが、ぼんやりとしたイメージとして、3D空間上にポリゴンを描画するいわゆる「3D描画」を行う事が可能なモノの思って大差ないかと。GPUを利用した2D画面の描画も、3D空間上において、いわゆる”板ポリ”にテクスチャを貼り付けて描画する為、まとめて3D描画と呼んでしまいます。
もちろん描画ユニットとしてだけでなく、科学シミュレーションや話題の機械学習の分野等では、GPGPU 等と呼ばれる汎用的な並列計算を行うSIMD演算器のようなユニットとしても活用されています。ゲームアプリケーションの分野でもポストエフェクトの処理をGPGPU(ComputeShader)で実装する等のケースがよくあります。
ちなみにですがこのGPU、スマホにはどうせ非力なGPUがのっているんだろうというイメージがありますが、iPhoneなんかは使えるGPUがのっていたりします。むしろ統合型のGPUがのっているPCなんかとくらべても優秀です。Androidも含めてそれなりのスマホなら使えるGPUが載っています。しかもユニファイドメモリ。
http://itstrike.biz/apple/iphone/28870/
本題に戻りこのGPUですがwebブラウザではどのように活用されているのでしょうか。ググってみるなんとなくわかってきました。すべてを網羅しているわけではないですが例えば以下のようなケースで使用されるようです。
- GPUレイヤーを用いて処理負荷を削減するAccelerated-Compositing
- WebGL
- Videoのハードウェアデコード
javascriptではなくCSSでアニメーションさせればGPUが使われるケースがあるらしく、Accelerated-Compositingを想定したコーディングの戦略が存在するなど、奥が深くて面白そうです。処理負荷をどうにかしなければならない最適化の案件等がもしあったら試してみたい。
Web-based Signage コンテンツ開発ガイドライン
WebGLの方は説明するまでもないかと思いますが、OpenGL ES(現状は2.0)をサポートするブラウザ用のグラフィックスAPIです。
あくまで個人的にはですが、WebGLは理解はすべき層であって、使いやすさや実装の速さという点ではそのラッパー/上位のライブラリーであるthree.jsなんかを使うのがよいのかなあというのが肌感覚です。WebGLで書ける方がそれは勿論かっこいいですが。昨今のグラフィッスAPIはDirextX12/Metal/Vulkan等、低レベルの波がきていて、パフォーマンスを得る代わりに複雑度が増してコード記述量がとっても多くなってきてます。ライブラリ開発者やエンジン開発者はここを理解しかつ叩く必要があるかと思いますが、アプリケーションプログラマは、これらの低レベルのライブラリをある程度理解しつつ、先人の努力にあやかり上位のライブラリなりを使うのが開発効率としてはよいのかなあと感じています。繰り返しですがあくまで、WebGL→three.jsを触ってみての現時点での個人的な感想です。
なんにせよWebGL(three.js)をがっつり使うお仕事がほしいなあ。
ささっと斜め読みした程度の理解なので、もっとブラウザの気持ちが分かるように精進します。
HTML/CSS/javascriptの「書き方」がなんとなくわかり始めてきた気がするこの頃です。
ふと気になることがあります。
「HTML文書はwebブラウザによってどのように処理され最終的にページとして描画されるの？」
「webブラウザってGPUを利用する事ってあるの？あるならどんなケースで利用されるの？」
気になりませんか？ググってみました。調べればなんでも情報が得られるってほんとうに素晴らしい世の中。
1. HTML文書はwebブラウザによってどのように処理されるの？
結論を言えば下記辺りのページをなんとなく眺めればなんとなく理解できてしまうはず。
とってもわかりやすく解説されてます。
ブラウザの仕組み: 最新ウェブブラウザの内部構造
ブラウザにやさしいHTML/CSS
理解するに越した事はないですがwebコンテンツを作るという立場ならば、とりあえずの理解はなんとなくできれば良いのかなと思っています。仕様は各レンダリングエンジンによって異なるし、仕様すら日々変わっていくだろうから、現状の仕様を端から端まで完璧に理解する必要はかならずしも無いなぁと個人的には思います。が、動作の概略を理解する事はwebコンテンツを作る上で有益なのは間違いない。「書き方」だけでなく「動作」を知る事で、webで可能な新しい表現・最適化・デバッグの面できっと助けになる。はず。
なにかを極めるには、それよりも下のレイヤーの技術も含めて理解する事が大切だと誰かに言われました。
2. 「webブラウザってGPUを利用する事ってあるの？あるならどんなケースで利用されるの？」
そもそもGPUとは？という詳細は端折りますが、描画機能に特化したCPUと並列で動作できるハードウェアとでもいいましょうか。いろいろなGPUアーキテクチャが存在するので、細かい動作や機能は異なりますが、ぼんやりとしたイメージとして、3D空間上にポリゴンを描画するいわゆる「3D描画」を行う事が可能なモノの思って大差ないかと。GPUを利用した2D画面の描画も、3D空間上において、いわゆる”板ポリ”にテクスチャを貼り付けて描画する為、まとめて3D描画と呼んでしまいます。
もちろん描画ユニットとしてだけでなく、科学シミュレーションや話題の機械学習の分野等では、GPGPU 等と呼ばれる汎用的な並列計算を行うSIMD演算器のようなユニットとしても活用されています。ゲームアプリケーションの分野でもポストエフェクトの処理をGPGPU(ComputeShader)で実装する等のケースがよくあります。
ちなみにですがこのGPU、スマホにはどうせ非力なGPUがのっているんだろうというイメージがありますが、iPhoneなんかは使えるGPUがのっていたりします。むしろ統合型のGPUがのっているPCなんかとくらべても優秀です。Androidも含めてそれなりのスマホなら使えるGPUが載っています。しかもユニファイドメモリ。
http://itstrike.biz/apple/iphone/28870/
本題に戻りこのGPUですがwebブラウザではどのように活用されているのでしょうか。ググってみるなんとなくわかってきました。すべてを網羅しているわけではないですが例えば以下のようなケースで使用されるようです。
- GPUレイヤーを用いて処理負荷を削減するAccelerated-Compositing
- WebGL
- Videoのハードウェアデコード
javascriptではなくCSSでアニメーションさせればGPUが使われるケースがあるらしく、Accelerated-Compositingを想定したコーディングの戦略が存在するなど、奥が深くて面白そうです。処理負荷をどうにかしなければならない最適化の案件等がもしあったら試してみたい。
Web-based Signage コンテンツ開発ガイドライン
WebGLの方は説明するまでもないかと思いますが、OpenGL ES(現状は2.0)をサポートするブラウザ用のグラフィックスAPIです。
あくまで個人的にはですが、WebGLは理解はすべき層であって、使いやすさや実装の速さという点ではそのラッパー/上位のライブラリーであるthree.jsなんかを使うのがよいのかなあというのが肌感覚です。WebGLで書ける方がそれは勿論かっこいいですが。昨今のグラフィッスAPIはDirextX12/Metal/Vulkan等、低レベルの波がきていて、パフォーマンスを得る代わりに複雑度が増してコード記述量がとっても多くなってきてます。ライブラリ開発者やエンジン開発者はここを理解しかつ叩く必要があるかと思いますが、アプリケーションプログラマは、これらの低レベルのライブラリをある程度理解しつつ、先人の努力にあやかり上位のライブラリなりを使うのが開発効率としてはよいのかなあと感じています。繰り返しですがあくまで、WebGL→three.jsを触ってみての現時点での個人的な感想です。
なんにせよWebGL(three.js)をがっつり使うお仕事がほしいなあ。
ささっと斜め読みした程度の理解なので、もっとブラウザの気持ちが分かるように精進します。
[Rails]Railsのバージョンを上げたことでspatial_adapterが使用できなくなりました
2016年01月14日
遅くなりましたが、明けましておめでとうございます。
今年もよろしくお願いいたします。
さっそくですが、本題に入ります！
今回はRails4.2にて標準搭載となったActive Jobを使用したいために、Railsのバージョンをあげたところspatial_adapterが使用できなくなってしまった件について話していこうと思います。
標準のRailsではMySQLのgeometry型が取り扱い使いづらいため、使いやすくしてくれるgemです。
githubにて色々な方が公開されているため、実際に使用したものが気になる方はこちらをごらんください。
githubを見ていただいた方は、お分かりになったかと思いますが、
ActiveRecordのバージョンが3.2.0 and upとなっており、Railsのバージョンが上がったことで合わせてActiveRecordのバージョンが上がったので、対応していないバージョンになってしまいました。
どのようにエラーが出たかというと…
マイグレーションなど処理実行時に以下のようなエラーがでてしまいました。
原因箇所については、dbに関わりそうなgemを１個ずつ削って調査しました…
google先生にいろいろ教えていただいたところ、Rails4.2でgeometry型を扱うにはactiverecord-mysql2spatial-adapterを使用すればいけるとのこと。
ただ、インストールされているActiveRecordのバージョンが4.2だったため、今回はこちらのactiverecord-mysql2spatial-adapterを使用させていただきました。
ではマイグレーションから…
うまくいったので、次はgeometry型の値を取得してみます(実際には他にもテーブル生成しました)。
むむむ…
geometry型のはずの値が数値となっていました。再度いろいろ調べてみるとrgeoとrgeo-activerecordのgemが必要ということでインストールしてgeometry型の値を取得。
むむむむむむ…
結果は変わらず、geometry型のはずの値が数値となっていました。なにがおかしいんだと思いながらactiverecord-mysql2spatial-adapter-42のドキュメントを再読…
すると、db設定のadapterを「mysql2」ではなく「mysql2spatial」にするという記述があったため変更してgeometry型の値を再度取得。
見事geometry型の値を取得することに成功しました！
ちなみに、データについてはspatial_adapterのgem使用時に登録しておいたデータでも問題なくgeometry型の値を取得できましたが、どうやらspatial_adapterのバージョンが低いとそのままでは使用できず、sql文でgeometryからxy値を取得して変換をしないとエラーとなるようです。
Railsのgemは便利なものが多く、一度環境さえ作成できればかなり簡単に開発が行えるのですが、Ruby、Railsのバージョンを上げ、使ってたgemが使えなくなった際、どのgemが使えなくなったのか原因調査が難しく、代わりを見つける、または、自作しなければならないということになり、結構難易度が高いなーっと改めて実感しました。
gem周りについては、とにかく経験を積むしかないと思うので、また同じようなことがあれば情報共有ということで書いていければと思います。
では、今回はこの辺りで！
今年もよろしくお願いいたします。
さっそくですが、本題に入ります！
今回はRails4.2にて標準搭載となったActive Jobを使用したいために、Railsのバージョンをあげたところspatial_adapterが使用できなくなってしまった件について話していこうと思います。
spatial_adapterとは
標準のRailsではMySQLのgeometry型が取り扱い使いづらいため、使いやすくしてくれるgemです。
githubにて色々な方が公開されているため、実際に使用したものが気になる方はこちらをごらんください。
Rails4.2でのspatial_adapterのエラー
githubを見ていただいた方は、お分かりになったかと思いますが、
ActiveRecordのバージョンが3.2.0 and upとなっており、Railsのバージョンが上がったことで合わせてActiveRecordのバージョンが上がったので、対応していないバージョンになってしまいました。
どのようにエラーが出たかというと…
マイグレーションなど処理実行時に以下のようなエラーがでてしまいました。
$ bundle exec rake db:migrate
rake aborted!
NoMethodError: undefined method `type' for "varchar(255)":String
原因箇所については、dbに関わりそうなgemを１個ずつ削って調査しました…
Rails4.2では何を使えばいいのか？
google先生にいろいろ教えていただいたところ、Rails4.2でgeometry型を扱うにはactiverecord-mysql2spatial-adapterを使用すればいけるとのこと。
ただ、インストールされているActiveRecordのバージョンが4.2だったため、今回はこちらのactiverecord-mysql2spatial-adapterを使用させていただきました。
ではマイグレーションから…
$ bundle exec rake db:migrate
== 20151225060238 DeviseCreateUsers: migrating ================================
-- create_table(:users)
-> 0.0109s
-- add_index(:users, :email, {:unique=>true})
-> 0.0123s
-- add_index(:users, :reset_password_token, {:unique=>true})
-> 0.0134s
== 20151225060238 DeviseCreateUsers: migrated (0.0368s) =======================
うまくいったので、次はgeometry型の値を取得してみます(実際には他にもテーブル生成しました)。
$ rails c
Loading development environment (Rails 4.2.5)
irb(main):001:0> l = Location.first
Location Load (0.3ms) SELECT `locations`.* FROM `locations` ORDER BY `locations`.`id` ASC LIMIT 1
=> #Location id: 1, geom: 0
irb(main):002:0> l.geom.class
=> Fixnum
むむむ…
geometry型のはずの値が数値となっていました。再度いろいろ調べてみるとrgeoとrgeo-activerecordのgemが必要ということでインストールしてgeometry型の値を取得。
$ rails c
Loading development environment (Rails 4.2.5)
irb(main):001:0> l = Location.first
Location Load (0.3ms) SELECT `locations`.* FROM `locations` ORDER BY `locations`.`id` ASC LIMIT 1
=> #Location id: 1, geom: 0
irb(main):002:0> l.geom.class
=> Fixnum
むむむむむむ…
結果は変わらず、geometry型のはずの値が数値となっていました。なにがおかしいんだと思いながらactiverecord-mysql2spatial-adapter-42のドキュメントを再読…
すると、db設定のadapterを「mysql2」ではなく「mysql2spatial」にするという記述があったため変更してgeometry型の値を再度取得。
$ rails c
Loading development environment (Rails 4.2.5)
irb(main):001:0> l = Location.first
Location Load (0.2ms) SELECT `locations`.* FROM `locations` ORDER BY `locations`.`id` ASC LIMIT 1
skip_logging (1.7ms) SHOW FIELDS FROM `locations`
=> #Location id: 1, geom: #RGeo::Geos::CAPIPointImpl:0x3fd68132ac34 "POINT (138.48486379999997 35.0239507)"
irb(main):002:0> l.geom.class
=> RGeo::Geos::CAPIPointImpl
irb(main):003:0> l.geom.x
=> 138.48486379999997
irb(main):004:0> l.geom.y
=> 35.0239507
見事geometry型の値を取得することに成功しました！
ちなみに、データについてはspatial_adapterのgem使用時に登録しておいたデータでも問題なくgeometry型の値を取得できましたが、どうやらspatial_adapterのバージョンが低いとそのままでは使用できず、sql文でgeometryからxy値を取得して変換をしないとエラーとなるようです。
まとめ
Railsのgemは便利なものが多く、一度環境さえ作成できればかなり簡単に開発が行えるのですが、Ruby、Railsのバージョンを上げ、使ってたgemが使えなくなった際、どのgemが使えなくなったのか原因調査が難しく、代わりを見つける、または、自作しなければならないということになり、結構難易度が高いなーっと改めて実感しました。
gem周りについては、とにかく経験を積むしかないと思うので、また同じようなことがあれば情報共有ということで書いていければと思います。
では、今回はこの辺りで！
アプリ開発の第一歩
2015年12月18日
こんにちは。最近好きなOSがMarshmallowなマツナガです。
今回は、アプリ開発についてのお話です。
プログラマが作る成果物は多岐に渡っています。社会のインフラ・基盤システム、会社の業務効率化のためのシステム、ネットワークやインフラの基盤システム、オペレーションシステム、プログラミングを支援する様々なライブラリーや開発環境、Webサイト、Webサービスなどなど、プログラマが書いたコードは私たちの生活の様々な場面で動いています。
そんなプログラマが開発するモノの一つに「アプリ」があります。僕の業務経歴はというと、社会インフラのシステム開発、業務システム開発、Webサービスの開発という道を辿ってきて、５年ほど前から「アプリ開発」も行うようになりました。
そもそも「アプリ開発」というプログラマの職種が一般化してきたのはいつからでしょうか。
アプリケーションという言葉は昔からありましたが、今のように「アプリ」という呼称はあまり使われていませんでした。Windowsの世界では90年代後半頃から「窓の杜」というサイトが開設され、アプリケーションが公開されるようになりましたが、当時は、アプリケーションは、フリーウェアとかシェアウェアという名称で呼ばれていました(久しぶりの窓の杜を見てみたら、サイトの説明は「Windowsアプリ・フリーソフトのおすすめ情報」となっていました）。
アプリという言葉が一般的になったのは、やはりiPhoneが普及するようになってからだと思います。Apple が iOS (当時はiPhone OS)向けにアプリケーションを開発する環境を提供して、開発されたアプリケーションを公開するApp Storeを開設したのが2008年7月です。この頃からiPhoneで動くアプリケーションは「アプリ」と呼ばれるようになり、アプリを開発するアプリ開発者と呼ばれるプログラマが増えてきました。
現在のアプリの状況については、先日、弊社の高山がブログエントリーに書いたとおり、
2015年11月24日時点、それぞれ下記のようになっています。
AppStore（iOS）：1,734,110（開発者 386,443）
GooglePlay（Android）：2,055,365（開発者 569,909）
参考：https://www.appannie.com/apps/ios/top/?_ref=header&device=iphone
プログラマがプログラムを作るきっかけは、プログラミングの習得という目的もありますが、一般的にはクライアントからの開発の委託です。職業プログラマであれば大抵はこのパターンです。
しかし、一方で、日曜プログラマと言われるプログラマが開発したアプリケーションをフリーウェアとして窓の杜などで公開するようになったり、Googleなどからが公開されたAPIを使ってWebアプリケーションを作ったりと、「自分が実現したいことを自分で作るプログラマ」が徐々に増えてきました。
これは開発ツールが手に入れやすくなったり、クラウドの普及により開発環境が簡単に使えるようになったりといった要因はもちろんありますが、自分が作ったアプリを全世界の人々に配信できるApp StoreやGoogle Playといったアプリストアの存在はとても大きいと思います。
こういった環境が整っていくことで、全世界で素晴らしいアプリが次々と世に出てくることになりました。アプリ普及の黎明期にこのムーブメントを牽引したのは、誰かに開発を委託されてプログラムを開発するプログラマではなく、「自分が実現したいことを自分で作るプログラマ」にほかなりません。
そして、アプリ開発というスタイルが浸透した今、まわりのみんながアプリ開発をしているので、自分もアプリ開発をしたいのだけど、何を作ったらいいのかわからない、といった声が聞こえるようになってきました。
アプリを開発するのであれば、JavaやSwiftといったプログラミング言語を学ぶことで開発はできます。しかし、当たり前ですが、何を作るかが決まらなければアプリは完成しません。アプリは、業務システムのように大規模で多くの開発者で作るようなものではなく、むしろ１人〜数人で開発されるコンパクトなものが多いので、プログラマがアイデア出しから完成まですべてを担う傾向にあります。
そうなると、やはりアプリを勉強したいけど何を作ったらいいかわからない、作るものが思い浮かばないのでアプリ開発に取り組みたくても、取り組めないとった状況が発生しがちです。
昔話になりますが、今から10年前、Web2.0と呼ばれた時代がありました。GoogleがGoogleマップをリリースし、様々な企業がAPIを公開し、様々なWebサービスが次々と開発されました。当時、Googleマップは凄く新鮮で、地図と何かを組み合わせることによって、新たな価値を生み出す環境をもたらしてくれました。
そのような体験の中でわかったことは、どのようなサービスやアプリを作ろうかと考える時に、何か素材があるとアイデアが出やすいということでした。10年前はGoogleマップが地図という素材を提供し、それを使った様々なアイデアが生まれ、実現されました。
そして現在は、オープンデータがその役目を担っているのかもしれません。政府や全国の自治体がオープンガバメントの流れの中で様々なデータの公開を始めています。
静岡県は2013年に全国に先駆けて「ふじのくにオープンデータカタログ」を開設、静岡市も今年10月、「静岡市オープンデータカタログサイト」を公開しました。
アプリを作りたいけど、どんなアプリを作ったらよいかわからないと迷ったときは、オープンデータカタログサイトに公開されている様々なデータを眺めてみるとよいかもしれません。そのとき注意することは、ひとつのデータを使って何かアプリを作ろうと考えるのではなく、いろいろなデータを掛け合わせてみることをお奨めします。静岡市の場合は、道路保全課、廃棄物処理課、生活安全保全課、観光交流課といった部署が作成したデータが公開されています。
おそらく、この中には、各部署では活用されていたものの、組織をまたいで活用されることはなかったデータがかなりの数含まれているはずです。
こういったデータがオープンデータとして公開されると、これまで決して重ねて使われることがなかったデータを重ねることが可能になります。例えばゴミ収集のデータと観光地のデータを重ねて眺めてみると、何かが見えてくるかもしれません。
このようにいろいろなデータを掛け合わせて見ていくと、今まで見えてこなかった課題が浮き彫りになってきます。そして、それが地域がかかえる課題の解決のきっかけになる可能性が充分にあると思います。僕はそれを見つけるのがプログラマとしてのオープンデータの活用の面白さなのかなと思います。
今回は、アプリ開発についてのお話です。
そもそも「アプリ」って何だ？
プログラマが作る成果物は多岐に渡っています。社会のインフラ・基盤システム、会社の業務効率化のためのシステム、ネットワークやインフラの基盤システム、オペレーションシステム、プログラミングを支援する様々なライブラリーや開発環境、Webサイト、Webサービスなどなど、プログラマが書いたコードは私たちの生活の様々な場面で動いています。
そんなプログラマが開発するモノの一つに「アプリ」があります。僕の業務経歴はというと、社会インフラのシステム開発、業務システム開発、Webサービスの開発という道を辿ってきて、５年ほど前から「アプリ開発」も行うようになりました。
そもそも「アプリ開発」というプログラマの職種が一般化してきたのはいつからでしょうか。
アプリケーションという言葉は昔からありましたが、今のように「アプリ」という呼称はあまり使われていませんでした。Windowsの世界では90年代後半頃から「窓の杜」というサイトが開設され、アプリケーションが公開されるようになりましたが、当時は、アプリケーションは、フリーウェアとかシェアウェアという名称で呼ばれていました(久しぶりの窓の杜を見てみたら、サイトの説明は「Windowsアプリ・フリーソフトのおすすめ情報」となっていました）。
アプリという言葉が一般的になったのは、やはりiPhoneが普及するようになってからだと思います。Apple が iOS (当時はiPhone OS)向けにアプリケーションを開発する環境を提供して、開発されたアプリケーションを公開するApp Storeを開設したのが2008年7月です。この頃からiPhoneで動くアプリケーションは「アプリ」と呼ばれるようになり、アプリを開発するアプリ開発者と呼ばれるプログラマが増えてきました。
現在のアプリの状況については、先日、弊社の高山がブログエントリーに書いたとおり、
2015年11月24日時点、それぞれ下記のようになっています。
AppStore（iOS）：1,734,110（開発者 386,443）
GooglePlay（Android）：2,055,365（開発者 569,909）
参考：https://www.appannie.com/apps/ios/top/?_ref=header&device=iphone
プログラマがプログラムを書くきっかけが変わった
プログラマがプログラムを作るきっかけは、プログラミングの習得という目的もありますが、一般的にはクライアントからの開発の委託です。職業プログラマであれば大抵はこのパターンです。
しかし、一方で、日曜プログラマと言われるプログラマが開発したアプリケーションをフリーウェアとして窓の杜などで公開するようになったり、Googleなどからが公開されたAPIを使ってWebアプリケーションを作ったりと、「自分が実現したいことを自分で作るプログラマ」が徐々に増えてきました。
これは開発ツールが手に入れやすくなったり、クラウドの普及により開発環境が簡単に使えるようになったりといった要因はもちろんありますが、自分が作ったアプリを全世界の人々に配信できるApp StoreやGoogle Playといったアプリストアの存在はとても大きいと思います。
こういった環境が整っていくことで、全世界で素晴らしいアプリが次々と世に出てくることになりました。アプリ普及の黎明期にこのムーブメントを牽引したのは、誰かに開発を委託されてプログラムを開発するプログラマではなく、「自分が実現したいことを自分で作るプログラマ」にほかなりません。
そして、アプリ開発というスタイルが浸透した今、まわりのみんながアプリ開発をしているので、自分もアプリ開発をしたいのだけど、何を作ったらいいのかわからない、といった声が聞こえるようになってきました。
アプリを開発するのであれば、JavaやSwiftといったプログラミング言語を学ぶことで開発はできます。しかし、当たり前ですが、何を作るかが決まらなければアプリは完成しません。アプリは、業務システムのように大規模で多くの開発者で作るようなものではなく、むしろ１人〜数人で開発されるコンパクトなものが多いので、プログラマがアイデア出しから完成まですべてを担う傾向にあります。
そうなると、やはりアプリを勉強したいけど何を作ったらいいかわからない、作るものが思い浮かばないのでアプリ開発に取り組みたくても、取り組めないとった状況が発生しがちです。
昔話になりますが、今から10年前、Web2.0と呼ばれた時代がありました。GoogleがGoogleマップをリリースし、様々な企業がAPIを公開し、様々なWebサービスが次々と開発されました。当時、Googleマップは凄く新鮮で、地図と何かを組み合わせることによって、新たな価値を生み出す環境をもたらしてくれました。
そのような体験の中でわかったことは、どのようなサービスやアプリを作ろうかと考える時に、何か素材があるとアイデアが出やすいということでした。10年前はGoogleマップが地図という素材を提供し、それを使った様々なアイデアが生まれ、実現されました。
そして現在は、オープンデータがその役目を担っているのかもしれません。政府や全国の自治体がオープンガバメントの流れの中で様々なデータの公開を始めています。
静岡県は2013年に全国に先駆けて「ふじのくにオープンデータカタログ」を開設、静岡市も今年10月、「静岡市オープンデータカタログサイト」を公開しました。
アプリを作りたいけど、どんなアプリを作ったらよいかわからないと迷ったときは、オープンデータカタログサイトに公開されている様々なデータを眺めてみるとよいかもしれません。そのとき注意することは、ひとつのデータを使って何かアプリを作ろうと考えるのではなく、いろいろなデータを掛け合わせてみることをお奨めします。静岡市の場合は、道路保全課、廃棄物処理課、生活安全保全課、観光交流課といった部署が作成したデータが公開されています。
おそらく、この中には、各部署では活用されていたものの、組織をまたいで活用されることはなかったデータがかなりの数含まれているはずです。
こういったデータがオープンデータとして公開されると、これまで決して重ねて使われることがなかったデータを重ねることが可能になります。例えばゴミ収集のデータと観光地のデータを重ねて眺めてみると、何かが見えてくるかもしれません。
このようにいろいろなデータを掛け合わせて見ていくと、今まで見えてこなかった課題が浮き彫りになってきます。そして、それが地域がかかえる課題の解決のきっかけになる可能性が充分にあると思います。僕はそれを見つけるのがプログラマとしてのオープンデータの活用の面白さなのかなと思います。
JANOG35に行ってきました
2015年01月27日
こんにちわ、高山です。
突然ですが、みなさんはJANOG(http://www.janog.gr.jp/)というグループを知っていますか？
JANOGにつては、サイト上に下記のように説明されています。
JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。
(http://www.janog.gr.jp/information/)
1977年に設立とあるので、かなり歴史のあるグループですね。
過去には、DeN◯とか、◯ahooなどがホスト主催を務めてきたようです。
実は、高山も今まで知りませんでした。。。
今回、JANOGが年に1度行うイベント「JANOG35 Meeting」（今回35回目なので35）を、弊社が参加しているfinoというNPO法人(http://www.fino.jp/)がホスト主催する事になり、高山も行ってきました。
と言いつつ、本開催ではなく、懇親会に行っただけですけど。。。
こちらもサイトにある通り、「JANOG ミーティングではインターネットに於ける技術的事項、および、それにまつわるオペレーションに関する近々のトピックスや研究結果など有志による発表が行われます。」ということで、ネットに関連する技術を3日間に渡り、全国のネット事業者が集まり最新の技術について発表し、話し合う場です。
実際、全国の多くの事業者が参加していて、よく耳にする会社がずらずらといらっしゃいました。
その「JANOG35 Meeting」の2日目の夜に懇親会が開かれ、どんなものかと参加してきました。
場所は、グランディエール ブケトーカイ（http://www.grandair-bridal.jp/）で行われ、会場は300人程が入っており、大賑わいでした。
そして各所で名刺交換が行われており、自分もいくつかの会社さんと名刺交換をさせて頂いたり、お話をさせていただきました。
そんななか、料理をいただきながら話をしていたら、話の流れでセミナー？を開催することが決まったりして、既に緊張しています。。。
2月初旬にはセミナーの会場を決定する事になり、どんどん話が進んでいます。。。詳細は後日。
「JANOG35 Meeting」のように、なかなか静岡では全国規模でネット事業者が集まることがありません。
懇親会だけではありましたが、他の会社さんのエンジニアさんと話し、繋がりを作ることができたのは有意義な時間でした。
これからもどんどん顔を出していきたいと思います。
ちなみに、開催の様子はニコニコ動画に纏められていますので、興味のある方は御覧ください。
http://ch.nicovideo.jp/janog/video
突然ですが、みなさんはJANOG(http://www.janog.gr.jp/)というグループを知っていますか？
JANOGにつては、サイト上に下記のように説明されています。
JANOGとは
JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。
(http://www.janog.gr.jp/information/)
1977年に設立とあるので、かなり歴史のあるグループですね。
過去には、DeN◯とか、◯ahooなどがホスト主催を務めてきたようです。
実は、高山も今まで知りませんでした。。。
今回、JANOGが年に1度行うイベント「JANOG35 Meeting」（今回35回目なので35）を、弊社が参加しているfinoというNPO法人(http://www.fino.jp/)がホスト主催する事になり、高山も行ってきました。
と言いつつ、本開催ではなく、懇親会に行っただけですけど。。。
JANOG Meetingとは
こちらもサイトにある通り、「JANOG ミーティングではインターネットに於ける技術的事項、および、それにまつわるオペレーションに関する近々のトピックスや研究結果など有志による発表が行われます。」ということで、ネットに関連する技術を3日間に渡り、全国のネット事業者が集まり最新の技術について発表し、話し合う場です。
実際、全国の多くの事業者が参加していて、よく耳にする会社がずらずらといらっしゃいました。
その「JANOG35 Meeting」の2日目の夜に懇親会が開かれ、どんなものかと参加してきました。
場所は、グランディエール ブケトーカイ（http://www.grandair-bridal.jp/）で行われ、会場は300人程が入っており、大賑わいでした。
そして各所で名刺交換が行われており、自分もいくつかの会社さんと名刺交換をさせて頂いたり、お話をさせていただきました。
そんななか、料理をいただきながら話をしていたら、話の流れでセミナー？を開催することが決まったりして、既に緊張しています。。。
2月初旬にはセミナーの会場を決定する事になり、どんどん話が進んでいます。。。詳細は後日。
まとめ
「JANOG35 Meeting」のように、なかなか静岡では全国規模でネット事業者が集まることがありません。
懇親会だけではありましたが、他の会社さんのエンジニアさんと話し、繋がりを作ることができたのは有意義な時間でした。
これからもどんどん顔を出していきたいと思います。
ちなみに、開催の様子はニコニコ動画に纏められていますので、興味のある方は御覧ください。
http://ch.nicovideo.jp/janog/video
共有サーバのホスティングサービスについて総点検してみたよ
2014年11月24日
私がお客様のところでよく尋ねられることの一つに
Webサイトを置くなら、どのサーバーが良いの?というものがあります。
どれが？と言われましても
実はどれでもいいんじゃないかと思う場合も多いのです。
各社サービスにしのぎを削り、細かな部分で違いはあるものの、顧客満足度では大差がないと思うからです。
とはいえ、お客さまのサイトの条件から、選んではいけないサービスというものは確かに存在します。
それは大別して3種類の中からの選択になると思います。
A.資金的に余裕があり、そこそこ安心のサービスを選択する
B.自己責任でお値打ちだけど専門知識が必要なサービスを利用する
C.初心者向けでお値打ちなサービスを利用する
言うまでもなくCを選択してAは期待できません。
Bならば自己責任でがんばれば、Aに近づくことができるかもしれませんが、Cでは無理です。
そして、多くの場合、サイトの作成するお客様はCを選択したがります。
ぶっちゃけて言いますとCに多くを期待をするのは無理というものです。
ですがですね、同時に各社がサービスの充実にしのぎを削っている事実もあるわけです。
そこで、有名ドコロのホスティングサーバの現時点のサービス(2014.11.23)で
私個人の超恣意的な視点かもしれませんが
Cに位置すると思われるサービスについて、調べてみました。
果たして、結構使えるサービスが多くなっているのか?
注目した点はPHPのバージョンです。
PHP5.2、ましてや、5.1.6以下のバージョンしか使用できないサービスだと
現代的なコーディングにはできないので
必然的にアレな、いやいや、誤解なきよう、サービスとして、ちゃんとしているけど、
私がおすすめするとなると・・・んがんぐな、サービスということになります。
結果は以下のとおり。
●さくらのレンタルサーバー
http://www.sakura.ne.jp/plans.html
PHPのバージョンは標準5.2
バージョンは5.2～5.4または4.4を利用できる。
Rubyが使える。
●ロリポップ！レンタルサーバー
http://lolipop.jp/manual/hp/cgi/
PHPのバージョンは5.4.32 ・ 5.3.15 ・ 5.2.17を利用できる。
Ruby1.8.7、1.9.3が使える。
●ヘテムル
http://heteml.jp/service/function/
PHPのバージョンは5.3.28、5.4.27を利用できる。
あとGitが使える。
Ruby1.8.*、1.9.3、2.0.0、2.1が使えるが、Ruby on Rails は非対応。
Ruby on Rails は
http://sqale.jp
をすすめている
●ファーストサーバ
http://www.fsv.jp/spec/
PHPのバージョンは5.3.xを利用できる。
●WebARENA 共用サーバ SuiteX
http://web.arena.ne.jp/suitex/spec/index.html
PHPのバージョンは5.1を利用できる。
Ruby1.8が使える。
●CPIシェアードプラン
http://www.cpi.ad.jp/shared/detail/php.html
PHPのバージョンは5.2.8、5.3.6、5.3.28、5.4.25、5.5.9 、5.5.16を利用できる。
あとGitが使える。
お名前.com 共用サーバー SD
http://お名前.com/server/sd/spec/
PHPのバージョンは5.5.x（初期設定）、5.4.x を利用できる。
Ruby1.8.7が使える。
GMOクラウド iCLUSTA+
http://faq.isle.jp/FaqItem?i_faqId=335&i_categoryId=0
PHPのバージョンは5.3.17を利用できる。
Ruby1.9.3が使える。
●Xserver
http://www.xserver.ne.jp/manual/man_program_soft.php
PHPのバージョンは4.3.9、5.1.6、5.3.3、5.2.x、5.4.x、5.5.xを利用できる。
Ruby1.8.5、1.9.3、2.0.0が使える。
●OCN メール＆ウェブ ビジネス
http://www.ocn.ne.jp/hosting/function/mw2/version.html
PHPのバージョンは5.5.7、5.4.23、5.3.28を利用できる。
Ruby1.8.6が使える。
意外なのですがPHPのバージョンで
結構新し目のものが使えるサービスが多いです。
(5.1.6が多いと思っていました。)
いやー、さすがですね。
反対にRubyについては動くものの
Ruby on Rails が動くサーバとなると
結構、厳しめですね。
というかほとんどは公式では非対応のようです。
情報があったのも、さくらのレンタルサーバーぐらいです。
http://iwatakenichi.blogspot.jp/2007/08/ruby-on-rails-on-sakura.html
(非公式)
共有サーバの世界では
なんだかんだ言ってもPHPが主流のようですね。
(もっといろいろ使えればいいのに)
いろいろと調べた中で
この中で私が良いなぁと思ったのは
・ヘテムル
・CPIシェアードプラン
でしょうか。
何故ならばGitが使用できるので
作成したプログラムをリリースするときにFTPでちまちまアップする必要が無いためです。
GitでPullすれば、それだけで本番に適応できるわけです。
これはすごい便利。
しかし、それはお客さまにとって初心者向けではないし、メリットとはいえないところはあります。
この辺り、結局、選択は難しいですね。
ところで
PHPのバージョンですが
上記のホスティングサービスで、既存ですでに稼働しているプログラムを配置しているサーバも
軒並み、問答無用にバージョンを上げたところが有りました。
案の定、プログラムが動かなくなり
弊社でも困ってしまった事がありました。
制作して年月が経過しているので
当方が勝手にサポートできないのです。(瑕疵担保責任が無いため)
それこそ勝手にやったら、お客さまのデータを勝手に弄ったことになりますから。
冒頭に言ったように
私がお客様のところでよく尋ねられることの一つに
Webサイトを置くなら、どのサーバーが良いの?というものがありますが、
やっぱり、なかなか難しいものがありますね。。
やはり、お客様の条件をご確認させていただきながら
お客様にお伺いした時点の最適なご提案をさせていただく他ないですね。
これからもつど最適解をご提案させていただきます。
というのが今回の結論でした。
Webサイトを置くなら、どのサーバーが良いの?というものがあります。
どれが？と言われましても
実はどれでもいいんじゃないかと思う場合も多いのです。
各社サービスにしのぎを削り、細かな部分で違いはあるものの、顧客満足度では大差がないと思うからです。
とはいえ、お客さまのサイトの条件から、選んではいけないサービスというものは確かに存在します。
それは大別して3種類の中からの選択になると思います。
A.資金的に余裕があり、そこそこ安心のサービスを選択する
B.自己責任でお値打ちだけど専門知識が必要なサービスを利用する
C.初心者向けでお値打ちなサービスを利用する
言うまでもなくCを選択してAは期待できません。
Bならば自己責任でがんばれば、Aに近づくことができるかもしれませんが、Cでは無理です。
そして、多くの場合、サイトの作成するお客様はCを選択したがります。
ぶっちゃけて言いますとCに多くを期待をするのは無理というものです。
ですがですね、同時に各社がサービスの充実にしのぎを削っている事実もあるわけです。
そこで、有名ドコロのホスティングサーバの現時点のサービス(2014.11.23)で
私個人の超恣意的な視点かもしれませんが
Cに位置すると思われるサービスについて、調べてみました。
果たして、結構使えるサービスが多くなっているのか?
注目した点はPHPのバージョンです。
PHP5.2、ましてや、5.1.6以下のバージョンしか使用できないサービスだと
現代的なコーディングにはできないので
必然的にアレな、いやいや、誤解なきよう、サービスとして、ちゃんとしているけど、
私がおすすめするとなると・・・んがんぐな、サービスということになります。
結果は以下のとおり。
●さくらのレンタルサーバー
http://www.sakura.ne.jp/plans.html
PHPのバージョンは標準5.2
バージョンは5.2～5.4または4.4を利用できる。
Rubyが使える。
●ロリポップ！レンタルサーバー
http://lolipop.jp/manual/hp/cgi/
PHPのバージョンは5.4.32 ・ 5.3.15 ・ 5.2.17を利用できる。
Ruby1.8.7、1.9.3が使える。
●ヘテムル
http://heteml.jp/service/function/
PHPのバージョンは5.3.28、5.4.27を利用できる。
あとGitが使える。
Ruby1.8.*、1.9.3、2.0.0、2.1が使えるが、Ruby on Rails は非対応。
Ruby on Rails は
http://sqale.jp
をすすめている
●ファーストサーバ
http://www.fsv.jp/spec/
PHPのバージョンは5.3.xを利用できる。
●WebARENA 共用サーバ SuiteX
http://web.arena.ne.jp/suitex/spec/index.html
PHPのバージョンは5.1を利用できる。
Ruby1.8が使える。
●CPIシェアードプラン
http://www.cpi.ad.jp/shared/detail/php.html
PHPのバージョンは5.2.8、5.3.6、5.3.28、5.4.25、5.5.9 、5.5.16を利用できる。
あとGitが使える。
お名前.com 共用サーバー SD
http://お名前.com/server/sd/spec/
PHPのバージョンは5.5.x（初期設定）、5.4.x を利用できる。
Ruby1.8.7が使える。
GMOクラウド iCLUSTA+
http://faq.isle.jp/FaqItem?i_faqId=335&i_categoryId=0
PHPのバージョンは5.3.17を利用できる。
Ruby1.9.3が使える。
●Xserver
http://www.xserver.ne.jp/manual/man_program_soft.php
PHPのバージョンは4.3.9、5.1.6、5.3.3、5.2.x、5.4.x、5.5.xを利用できる。
Ruby1.8.5、1.9.3、2.0.0が使える。
●OCN メール＆ウェブ ビジネス
http://www.ocn.ne.jp/hosting/function/mw2/version.html
PHPのバージョンは5.5.7、5.4.23、5.3.28を利用できる。
Ruby1.8.6が使える。
意外なのですがPHPのバージョンで
結構新し目のものが使えるサービスが多いです。
(5.1.6が多いと思っていました。)
いやー、さすがですね。
反対にRubyについては動くものの
Ruby on Rails が動くサーバとなると
結構、厳しめですね。
というかほとんどは公式では非対応のようです。
情報があったのも、さくらのレンタルサーバーぐらいです。
http://iwatakenichi.blogspot.jp/2007/08/ruby-on-rails-on-sakura.html
(非公式)
共有サーバの世界では
なんだかんだ言ってもPHPが主流のようですね。
(もっといろいろ使えればいいのに)
いろいろと調べた中で
この中で私が良いなぁと思ったのは
・ヘテムル
・CPIシェアードプラン
でしょうか。
何故ならばGitが使用できるので
作成したプログラムをリリースするときにFTPでちまちまアップする必要が無いためです。
GitでPullすれば、それだけで本番に適応できるわけです。
これはすごい便利。
しかし、それはお客さまにとって初心者向けではないし、メリットとはいえないところはあります。
この辺り、結局、選択は難しいですね。
ところで
PHPのバージョンですが
上記のホスティングサービスで、既存ですでに稼働しているプログラムを配置しているサーバも
軒並み、問答無用にバージョンを上げたところが有りました。
案の定、プログラムが動かなくなり
弊社でも困ってしまった事がありました。
制作して年月が経過しているので
当方が勝手にサポートできないのです。(瑕疵担保責任が無いため)
それこそ勝手にやったら、お客さまのデータを勝手に弄ったことになりますから。
冒頭に言ったように
私がお客様のところでよく尋ねられることの一つに
Webサイトを置くなら、どのサーバーが良いの?というものがありますが、
やっぱり、なかなか難しいものがありますね。。
やはり、お客様の条件をご確認させていただきながら
お客様にお伺いした時点の最適なご提案をさせていただく他ないですね。
これからもつど最適解をご提案させていただきます。
というのが今回の結論でした。
SwiftはObjective-Cを置き換えるか
2014年11月10日
アプリ開発をしているマツナガです。
弊社では年末から年明けに向けて、新しいiPhoneアプリをいくつか開発しています。iOSのアプリ開発には、Objective-Cという言語を使用します。このObjective-Cという言語、iOSアプリ開発がこんなに盛んになるまでは、Macで動作するアプリケーションを作る言語として存在していましたが（もともとはMac OS XのベースになったNeXTで使われていた言語）、一般的な開発者はふれることのない言語でした。
しかし現在では、iOSの登録開発者数は900万に達しており（WWDC 2014でのTim CookのKeynoteより）、ここに登録されている開発者の大半がObjective-Cを習得して開発を行っています。
そして、WWDC2014では開発者にとって衝撃的な発表がありました。iOS / OS X向けの新しい開発言語「Swift」の発表です。
iOSアプリを開発するために、Objective-Cを学んだ開発者達の悲鳴が聞こえてきそうです。もちろん、Objective-CでのiOSアプリの開発がすぐにできなくなるわけではなく、iOS 8になってもObjective-Cでアプリは開発できます。これまで習得した技術が無駄になるわけではないのですが、ギークな開発者は早々にSwiftに移行していくでしょう(今年WWDCに参加した友人の話では、発表されたばかりのSwiftを使ってプログラムを書き始めた開発者がいっぱいいたとのことです)。
そこで、今後のアプリ開発において、Swiftを採用するかどうかのポイントについて考えてみます。
既存のアプリはどうするか？
すでにObjective-Cで開発されたアプリをSwiftに移行するかどうかという問題です。そもそも、Objective-CのコードをボタンひとつでSwiftに変換する魔法のツールは今現在存在していません。もともと複雑怪奇な文法を持ったObjective-Cのコードをモダンかつシンプルな記述で書けるSwiftに置き換える作業は、結構骨の折れる作業です。一度、数百行程度のコードでトライしてみましたが、とっても辛かったです。すでに公開しているアプリケーションで、大きな改造もなく、保守メンテナンスフェーズにあるアプリに関しては、Swiftに置き換えるメリットはないように思います。また、Swiftで書かれたコードはiOS 7以降しか動作しません。iOS 6での動作保証がマストである場合は、Swiftは選択肢から外れることになります。
新規にアプリを開発する場合どうするか？
まったく新しいアプリを開発する場合、または、すでに公開しているObjective-Cで開発されたアプリを心機一転リニューアルする場合、Swiftを採用するかどうかのチェックポイントです。
1.既存のコードが再利用できるか
まったく新しいアプリを開発する場合でも、これまで開発したObjective-Cのコードを再利用はしたいものです。リニューアルする場合も同様です。これについては、Swiftは、Objective-Cとの互換性を保証していますので、問題ありません。SwiftからObjective-Cのコードを呼ぶこともできますし、Objective-CからSwiftのコードを呼ぶこともできます。
プロジェクト内にSwiftとObjective-Cのコードを共存させる場合には、以下のサイトが参考になります。
F60K - Objective0CとSwiftの組み合わせ方まとめ
また、iOSのライブラリーを管理できるCocoaPodsを使ってインストールできるライブラリーの大半もObctive-Cで書かれていますが、これについても、Swiftのコードから呼び出すことができ、問題なく利用することができました。
Qiita - SwiftでCocoaPodsを使う
2.言語の習得コスト
Swiftは学習しやすい言語かどうかというポイントです。Objective-Cは、C言語をベースにしていると言いながらも、C言語の開発者も戸惑ってしまう括弧[ ]の使い方が独特である点や、そもそも誕生から約30年経過していることもあり、モダンな記法ができるかと言えば、少し無理がある状況ではありました。Swiftはもちろんそういった反省点から生まれた言語ではありますし、今もっとも新しいプログラミング言語であることもあり、他のモダンな言語のいいとこ取りをしているプログラミング言語といっていいでしょう。「Pythonに似てる」、「Rubyに似てる」とか、はたまた「C言語に似ている」とか開発者のつぶやきがTwitterのタイムラインからも見て取れます。そういった意味では、言語としての習得コストは低いと思います。PythonやRubyあたりを使っている開発者であればさほど習得には時間はかからないでしょう。
しかし、言語自体を習得できてもそれだけでは、アプリは開発できません。これはSwiftに限ったことではないですが、アプリを開発するには、そのアプリ専用のフレームワークの使い方を習得することが必要だからです。iOSの場合は、まずは「UIKit」の使い方を覚える必要があります。UIKitは画面を構成するViewやTableViewやボタンなどユーザーインタフェイスに関わる機能を司るフレームワークです。また、画像処理を行うフレームワーク、位置情報を扱うフレームワークなどなど、高機能なアプリを作ろうとすればするほど、覚えなければならないフレームワークは増えていきます。これは、Objective-CでもSwiftであっても覚えなければなりません。ここの習得コストは両者ほぼ同じといえます。逆にいうと、これらフレームワークをObjective-Cを使って覚えた開発者は、この知識をそのままSwiftで使うことができます。これは大きなメリットです。あとは、Swiftの言語を覚えるだけでよいのですから。
では、これからアプリを開発する人は、どちらを選択すればよいでしょうか？ フレームワークについての学習コストは両者同じであるとするならば、学習コストの低いSwiftを選択するのが賢明だと考えます。ただ、現段階では、Objectice-Cに関する参考図書やWebの情報も少ないかもしれません。Swiftをばりばり書いている先輩社員もそう多くはいないと思います。しかしそれは時間の問題です。Objective-Cをバリバリ書いている開発者は、またたく間にSwiftを習得してWebで情報をどんどん発信していくからです。
3.開発効率について
SwiftはObjective-Cよりも、記述を簡略化でき、見通しのよいコードが書ける印象を持ちました。Objective-Cはひとつのクラスを定義するには、ヘッダファイルと実装ファイルの２つのファイル構造になっていましたが、Swiftではひとつのファイルでひとつのクラスを記述することができます。ソースが増えてくると、結構、ヘッダファイルと実装ファイルをいちいち開いて行ったり来たりする時間が無駄だなと思っていたのですが、Swiftではこの作業が軽減できそうです。
言語仕様を習得しさえすれば、記述するコードはかなり減らすことができ、デバッグ工程の作業も減らせそうなので、開発効率は向上すると思います（一方で、iPhone開発は、iPhone 6から画面サイズが増えてしまったのでそのための開発コストといった問題があるのですが、それは別の話）。
いろいろ自問自答した結果、弊社で、年明け頃に公開予定のアプリは、Swiftで書くことに決めました。これまで、いくつもの言語が誕生してきましたが、Swiftは、これまで新たに誕生した言語とは少し違う起源を持ち、違う進化を遂げていく言語なのだと思います。
弊社では年末から年明けに向けて、新しいiPhoneアプリをいくつか開発しています。iOSのアプリ開発には、Objective-Cという言語を使用します。このObjective-Cという言語、iOSアプリ開発がこんなに盛んになるまでは、Macで動作するアプリケーションを作る言語として存在していましたが（もともとはMac OS XのベースになったNeXTで使われていた言語）、一般的な開発者はふれることのない言語でした。
しかし現在では、iOSの登録開発者数は900万に達しており（WWDC 2014でのTim CookのKeynoteより）、ここに登録されている開発者の大半がObjective-Cを習得して開発を行っています。
そして、WWDC2014では開発者にとって衝撃的な発表がありました。iOS / OS X向けの新しい開発言語「Swift」の発表です。
iOSアプリを開発するために、Objective-Cを学んだ開発者達の悲鳴が聞こえてきそうです。もちろん、Objective-CでのiOSアプリの開発がすぐにできなくなるわけではなく、iOS 8になってもObjective-Cでアプリは開発できます。これまで習得した技術が無駄になるわけではないのですが、ギークな開発者は早々にSwiftに移行していくでしょう(今年WWDCに参加した友人の話では、発表されたばかりのSwiftを使ってプログラムを書き始めた開発者がいっぱいいたとのことです)。
そこで、今後のアプリ開発において、Swiftを採用するかどうかのポイントについて考えてみます。
既存のアプリはどうするか？
すでにObjective-Cで開発されたアプリをSwiftに移行するかどうかという問題です。そもそも、Objective-CのコードをボタンひとつでSwiftに変換する魔法のツールは今現在存在していません。もともと複雑怪奇な文法を持ったObjective-Cのコードをモダンかつシンプルな記述で書けるSwiftに置き換える作業は、結構骨の折れる作業です。一度、数百行程度のコードでトライしてみましたが、とっても辛かったです。すでに公開しているアプリケーションで、大きな改造もなく、保守メンテナンスフェーズにあるアプリに関しては、Swiftに置き換えるメリットはないように思います。また、Swiftで書かれたコードはiOS 7以降しか動作しません。iOS 6での動作保証がマストである場合は、Swiftは選択肢から外れることになります。
新規にアプリを開発する場合どうするか？
まったく新しいアプリを開発する場合、または、すでに公開しているObjective-Cで開発されたアプリを心機一転リニューアルする場合、Swiftを採用するかどうかのチェックポイントです。
1.既存のコードが再利用できるか
まったく新しいアプリを開発する場合でも、これまで開発したObjective-Cのコードを再利用はしたいものです。リニューアルする場合も同様です。これについては、Swiftは、Objective-Cとの互換性を保証していますので、問題ありません。SwiftからObjective-Cのコードを呼ぶこともできますし、Objective-CからSwiftのコードを呼ぶこともできます。
プロジェクト内にSwiftとObjective-Cのコードを共存させる場合には、以下のサイトが参考になります。
F60K - Objective0CとSwiftの組み合わせ方まとめ
また、iOSのライブラリーを管理できるCocoaPodsを使ってインストールできるライブラリーの大半もObctive-Cで書かれていますが、これについても、Swiftのコードから呼び出すことができ、問題なく利用することができました。
Qiita - SwiftでCocoaPodsを使う
2.言語の習得コスト
Swiftは学習しやすい言語かどうかというポイントです。Objective-Cは、C言語をベースにしていると言いながらも、C言語の開発者も戸惑ってしまう括弧[ ]の使い方が独特である点や、そもそも誕生から約30年経過していることもあり、モダンな記法ができるかと言えば、少し無理がある状況ではありました。Swiftはもちろんそういった反省点から生まれた言語ではありますし、今もっとも新しいプログラミング言語であることもあり、他のモダンな言語のいいとこ取りをしているプログラミング言語といっていいでしょう。「Pythonに似てる」、「Rubyに似てる」とか、はたまた「C言語に似ている」とか開発者のつぶやきがTwitterのタイムラインからも見て取れます。そういった意味では、言語としての習得コストは低いと思います。PythonやRubyあたりを使っている開発者であればさほど習得には時間はかからないでしょう。
しかし、言語自体を習得できてもそれだけでは、アプリは開発できません。これはSwiftに限ったことではないですが、アプリを開発するには、そのアプリ専用のフレームワークの使い方を習得することが必要だからです。iOSの場合は、まずは「UIKit」の使い方を覚える必要があります。UIKitは画面を構成するViewやTableViewやボタンなどユーザーインタフェイスに関わる機能を司るフレームワークです。また、画像処理を行うフレームワーク、位置情報を扱うフレームワークなどなど、高機能なアプリを作ろうとすればするほど、覚えなければならないフレームワークは増えていきます。これは、Objective-CでもSwiftであっても覚えなければなりません。ここの習得コストは両者ほぼ同じといえます。逆にいうと、これらフレームワークをObjective-Cを使って覚えた開発者は、この知識をそのままSwiftで使うことができます。これは大きなメリットです。あとは、Swiftの言語を覚えるだけでよいのですから。
では、これからアプリを開発する人は、どちらを選択すればよいでしょうか？ フレームワークについての学習コストは両者同じであるとするならば、学習コストの低いSwiftを選択するのが賢明だと考えます。ただ、現段階では、Objectice-Cに関する参考図書やWebの情報も少ないかもしれません。Swiftをばりばり書いている先輩社員もそう多くはいないと思います。しかしそれは時間の問題です。Objective-Cをバリバリ書いている開発者は、またたく間にSwiftを習得してWebで情報をどんどん発信していくからです。
3.開発効率について
SwiftはObjective-Cよりも、記述を簡略化でき、見通しのよいコードが書ける印象を持ちました。Objective-Cはひとつのクラスを定義するには、ヘッダファイルと実装ファイルの２つのファイル構造になっていましたが、Swiftではひとつのファイルでひとつのクラスを記述することができます。ソースが増えてくると、結構、ヘッダファイルと実装ファイルをいちいち開いて行ったり来たりする時間が無駄だなと思っていたのですが、Swiftではこの作業が軽減できそうです。
言語仕様を習得しさえすれば、記述するコードはかなり減らすことができ、デバッグ工程の作業も減らせそうなので、開発効率は向上すると思います（一方で、iPhone開発は、iPhone 6から画面サイズが増えてしまったのでそのための開発コストといった問題があるのですが、それは別の話）。
いろいろ自問自答した結果、弊社で、年明け頃に公開予定のアプリは、Swiftで書くことに決めました。これまで、いくつもの言語が誕生してきましたが、Swiftは、これまで新たに誕生した言語とは少し違う起源を持ち、違う進化を遂げていく言語なのだと思います。
iPhone 6に最適化されたアプリとは
2014年09月24日
画面サイズが大きくなったiPhone 6 / iPhone 6 Plus
ついに、9月19日に、iPhone 6 とiPhone 6 Plusが発売されました。全世界で、発売から３日間で、1600万台の販売台数を記録しており、相変わらずiPhoneの人気は衰えずといったところです。
今回のiPhone 6 / iPhone 6 Plus、もっとも大きな特徴は何でしょうか。やはり、いちばん目につく点は画面サイズが大きくなったことです。現役の機種の解像度をまとめるとこんな感じになります。
| 機種 | ピクセル解像度(高さ x 幅) |
| iPhone 4S | 960 x 640 |
|---|---|
| iPhone 5 / 5c / 5s | 1136 x 640 |
| iPhone 6 | 1334 x750 |
| iPhone 6 Plus | 1920 x 1080 |
iPhone 6 Plusに至っては、これはフルHDの解像度です。リビングにあるフルハイビジョンテレビの解像度がギュッと手のひらサイズ（よりちょっと大きなサイズ）に収まってしまいました。
ここで注目したいのは、今回のiPhone 6では、画面の高さだけでなく、幅まで大きくなったということです。しかも、高さと幅がそれぞれ違うiPhone 6とiPhone 6 Plusの２機種が同時に発売されたことです。
画面サイズと開発者の苦悩
2年前、iPhone 5が発売されたとき、これまでのiPhone4 / 4Sから画面サイズが縦に伸びたことにより、アプリ開発者はアプリの縦長のサイズ対応を強いられました。ただ、Appleは対応されていないアプリのために、iPhone 5にiPhone 4 / 4Sの画面サイズそのままの大きさで表示するモードを残してくれました。iPhone 5の縦サイズが1136px、iPhone 4 / 4Sの縦サイズが960pxですから、その差分の176pxの半分の88px分を上下に黒い帯を表示した状態で、iPhone 5に対応しないアプリは起動できました。
しかし、これでは、せっかく大きくなった画面を充分に使えなくなってしまいます。ユーザーの利便性を考えるならば、きちんと縦長サイズの対応をすべきです。iPhone 5発売以降、アプリ開発者たちは、いわゆる"縦長対応"に奔走しました（今となってはよい思い出です）。
さて、あれから２年の月日が経ちました。今度は、高さだけでなく、幅まで大きくなったiPhoneの登場です。しかも、２サイズも増えました。アプリ開発者にとっては2年前の悪夢が４倍になってやってきたといったところでしょうか？
まだ、iPhone 6 / iPhone 6 Plusが発売されて1週間も経っていないこともあり、App Storeでも 新しいiPhoneの画面サイズに最適化されたアプリはあまり多くありません。AppleのiPhoneの発表イベントでは、これまでのアプリは手を加えることなく、新しいiPhoneで動作すると、ワールドワイドプロダクトマーケティング担当上級副社長のPhil Schillerが話していました。
iPhone 5の発売の時のように、今回も対応していないアプリも動作するような仕組みが提供されたわけです。やれやれ、一安心、、、でしょうか？
では、新しいiPhoneのサイズに最適化されていないアプリは、実際どのように表示されるのでしょうか。実際に試してみました(左からiPhone 4S、iPhone 5s、iPhone 6 、iPhone 6 Plusです)。
どうでしょうか、ぱっと見、問題なく表示されているように見えますね。しかし、よく見てみると、画面サイズが変わっても、iPhone 4Sをのぞいて、表示されている内容がすべて同じです。新しいサイズに対応していないアプリは、縦と横方向に拡大表示する、というのが、今回の対応されていないアプリへの仕様というわけです。
iPhone 5の時は上下に黒帯を入れればよかったのですが、今回は幅も大きくなったので上下だけでなく、左右にも黒帯を入れるというのはあり得ませんしね。
しかし、これでは、せっかく大きな画面を手に入れたのに、１画面あたりの情報量は変わらないということになってしまいます。しかも、画面をそのまま拡大しているので、文字も大きくなり、文字も画像も全体的にボヤッとした感じに表示されてしまっています（これ、実機で確認するとよくわかります ）。
このブログを書いている時点では、facebookもiOSアプリも、新iPhoneの画面サイズに最適化されていません。「iPhone 6でfacebook見てると、文字大きくてお年寄りになった気分だ」と言っている人がいましたが、確かに、大きな画面に大きな文字なので、このユーザー体験はないよなぁと思ってしまうわけです。
特にiPhone 6 Plusの方が画面が大きい分、お年寄り感はより強いと思います。せっかく大きな画面をiPhoneを手に入れても、しばらくは、大きな画面の恩恵を預かれる機会はまだまだ少ないといってよいでしょう。かなり残念感を感じるところです。ここは、開発者さん達の頑張りに期待するしかありません。
では、使っているアプリが新しいiPhoneのサイズに最適化されているかどうかは、どうやって判断すればよいでしょうか？
起動してみて、何となくボヤってしているなと感じれば、まず、対応されていません。また、「iOS 8に対応しました」と書かれていても、iOS 8での動作は大丈夫だけど、新しいサイズに対応しているとは限らないので注意が必要です。
ちなみに、App Storeで確認すると、対応アプリは以下のように記載されています。
このように、「このAppは、iPhone5、iPhone 6 および iPhone 6 Plusに最適化されています」と表示されていれば、新しいサイズに対応したアプリということになります。
画面サイズに最適化したアプリは快適なUIを提供してくれる
では、新しいサイズに対応したアプリはどのような感じになるでしょうか。
文字サイズはすべてのiPhoneで同じ大きさとなり、表示される内容も大きな画面ほど、多くなっているのが一目瞭然ですね。
iPhone 6 Plusで最適化していないものと最適化したものを並べるとこんな感じです。
脱・画面サイズに依存したアプリ開発
これからiPhoneアプリを開発する場合は、4つの画面サイズに適応したものを開発しなければならなくなります。iPhone 6が出る前は、iPhone 4S と iPhone 5の２サイズの対応（縦方向の対応）をしていればよかったのに、これからはさらに２つのサイズに対応しなければなりません（しかも縦方向だけでなく、横方向も）。
これに対する答えは、ただひとつです。
「どんな画面サイズでもきちんど動作するアプリを作る」
言い換えると、画面サイズに依存したアプリは開発しないということです。これについては、実はiOS 6の頃に画面サイズに依存しない開発ができるようAppleが環境を用意してくれていました。「Auto Layout 制約」を定義するというものですが、この仕組みに基づいてアプリを開発すれば、新しいサイズのiPhoneが追加されても比較的スムーズに新しいサイズに適応できるようになります。
Auto Layoutを使うということは、名前から想像できるかもしれませんが、ボタンや入力フィールドの位置を絶対位置として定義してデザインするのではなく、このボタンは画面の右端から○ピクセル、この入力フィールドは、左右○ピクセルの余白があって、幅は可変、といったように定義することになります。Auto Layoutを使った設計をしていない開発者は、今後、Auto Layoutを使った設計が必須となるでしょう。すべからくアプリデザインの手法も変更しなければなりません。
最後に宣伝ですw
今回、例で紹介しました「womoグルメアプリ」は、iPhone 6 / iPhone 6 Plus発売日から、新サイズに適応したバージョンアップ版をApp Storeで公開しています。今なら、500円でランチが楽しめるアプリ限定クーポンもついています。新しいiPhoneを手に入れた方も、ぜひ、womoグルメで静岡のグルメ店を探してみてください。
（続）ソーシャルな時代におけるプログラマーという職業
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のシステムが作れるかもしれません。しかし、これまでの開発手法やコスト感覚を大幅に変えないと、プロジェクトは成功しません。これまでの開発手法を実行するだけの時間もコストも与えられないのですから。
で、この文章のタイトルであるソーシャルな時代のプログラマーはどうあるべきなのでしょうか？もちろん、安くて早い開発を要求され、ただ、長時間労働を強いられているだけではいけません。先にコンピューターシステムの本質は、人間の能力を超えるスピードで作業を行うためのものだと書きました。それを実現するためのものがプログラムです。実は、システム開発は何かと手作業が多いのです。プロジェクトが大人数になればなるほど、ドキュメントやプログラムの量が増えたり、作業の分担や、進行など人の調整も複雑になります。ドキュメントやプログラムに間違いがないかとか、人の割り当てなどもわりとアナログな手作業で行われている場合が多いのです。
ならば、そういった手作業をコンピューターにやらせればよいのです。そのためのプログラムを書く技術力は現場のプログラマーであれば持ち合わせているはずです。実際に、そういった考えのもと開発を支援するさまざまなツール（しかも無料で使えるもの）が、増えてきています。そしてこれらのツールは、エンジニアが置かれてる環境を改善しようと作ったものですから、実によくできています。必要は発明の母です。そういったツールを使うことで、システム開発の効率は大幅に向上するはずです。もちろんそれが物足りなかったら、カスタマイズするなり、さらに効率をあげるためのツールを自ら作ることを考えるとよいでしょう。
ソーシャルな分野では、とにかく技術の進歩が早い。しかし、その一方で、人間はいちど作り上げた仕組みや環境を変化させることにはどうしても億劫になりますが、それでもプログラマーは、早く、安くを望まれる環境の中で、自ら開発効率を上げるための努力をしつづけることが必要です。
