SOLG System Blog

いまさらのお話ですが、
以前、ここで紹介したクソゲーの続報がありました。

クソゲーをあまりにもたくさん作りすぎて
しかも、あんまりにも売れなかったので、
当時ゲーム会社最大手の「ATARI社」の経営が傾き
倉庫一杯の不良在庫を頭に来て、
こっそりと夜中、トラックで運び出し
でっかい穴を掘って埋めてしまったという都市伝説のやつです。

そして、その伝説が本当だったかどうか、
発掘してみようという馬鹿なお話です。

「クソゲーで宝探しがマジだったでござるの巻」
http://iaseteam.eshizuoka.jp/e1079888.html

あれですが、本当にあったようです。


すげーな!アメリカ、本当に埋めちゃうんだ。

http://www.inside-games.jp/article/2014/04/27/76337.html
http://blog.esuteru.com/archives/7653104.html

この都市伝説は
コンピュータの世界では歴史的な出来事
経済のお話でも有名な出来事である
「アタリショック」に係るお話です。

ちなみにこの「アタリショック」により
アメリカのTVゲーム市場は壊滅的な打撃を受けます。

そもそも、この「アタリショック」
なぜ起きたのかというと
クソゲーがあまりにも多くなりすぎたせいです。

当時のTVゲームでは
どれが面白いという情報が皆無でした。

だから、粗製濫造しても製作者側は誰も何も気にしないし
売る側も適当に陳列していました。

すごく頑張って良いゲームを作っても
適当に陳列されたら
どれが面白いゲームか
消費者にはわかりません。

消費者はゲームを買うということは、
ある意味、賭けの状態だったのです。

抱き合わせもありました。
ゲーム機本体を買うときに
おまけでソフトを付けます。

当然少し高くなるわけですけど
個別に買うよりも安い。
しかも、どれが面白いゲームかわからないわけですから
抱き合わせでついてきたゲームが
ゲーム機全ての価値を決めます。

結局、つまんないゲームが幅を利かせて
市場が壊滅したというわけです。

伝説のクソゲー「E.T」は
すでに終末を迎えていたゲーム市場に
最後のひとオシをしたに過ぎません。


しかし、現在は、アメリカはもちろん、全世界で
コンピュータゲームは当たり前のように存在します。

それは何故かご存知ですか?

それは日本のお陰です。

昭和58年（1983年）7月15日に誕生した
ファミリーコンピュータ(以降ファミコン)は
NESという名前で、海外でも大ヒットしました。



そもそも、ファミコンが登場した当時
日本でもTVゲームは他もにたくさん出ていました。

セガのSG-1000、エポック社のカセットビジョン等、
競合はたくさんありました。
カセットを入れ替えることで
別のゲームを遊ぶことができる点も
別に目新しいものではありませんでした。
(伝説のクソゲー「E.T」もカセットですし。)

つまり、ファミコンは
成熟市場に後発参入したなんら新しい点のない製品に過ぎなかったのです。
じゃあ、何故、ファミコンは
世界中でTVゲーム市場の一人勝ちが出来たのでしょうか?
ましてや、壊滅状態になったアメリカで。

それはゲームセンターのゲームを
ファミコンで遊ぶことが出来たためです。



ゲームセンターのゲームは
ゲームセンターで遊ぶことが出来ます。
つまり、面白いか、そうでないのかは
すでにゲームセンターで評価が定まっています。

ゲームセンターで人気のゲームがTVゲームでできれば
そりゃ、みんな飛びつきます。

ここで間違えていけないのは
TVゲーム市場が壊滅したと言っても
みんなゲームが嫌いなったというわけではないのです。

「面白いゲームがどれかわからない」ので
「買うことができなくなった」だけです。
面白いゲームならば、みんな、喜んで買う市場が消えたわけではないわけです。

また、既に知名度のあるゲームを移植して、
家庭でできるようにしたこの手法は
宣伝費の削減にも貢献しました。

しかし、この手法、今となっては
誰もが思いつくことの一つだと思いませんか?

それは今となっては、家庭用ゲーム市場というものが
とても大きな市場規模であり、
一般の生活に普通に溶け込んでいるためです。

しかし、この当時はそうではありませんでした。

TVゲームとは、どこまでいっても子供の遊びであり
おもちゃメーカーが
電子回路を組み合わせて作っていたものです。

高性能なCPUを組み込んで周辺回路を設計するような
ビジネスコンピューティングとは程遠いものでした。

必然的に
CPUを搭載したコンピュータと呼べるものは少数派で
たとえ、搭載していたとしても
コンピュータの処理能力を活かすことの出来ない
非常に性能の低いものでした。

とてもとてもゲームセンターのゲームができるほどの性能を持ったゲーム機はなかったのです。

そして
みんながみんな
「その程度のもので十分」
という認識だったのです。

しかし、ファミコンは違いました。

ゲームセンターのゲームが出来ることを念頭に、
高性能なCPUを組み込むだけでなく
画面表示のための高機能なカスタムチップを開発し搭載しています。

しかも、このカスタムチップの仕様を決めるに当たり、
宮本茂さんをはじめとしたゲームデザイナーの要望を取り入れています。
これも当時としては画期的なことでした。

結果、ゲームが作りやすく、高性能なファミコンは
その名の通り家庭のコンピュータとしての地位を築いていくわけです。

ブルーオーシャン戦略で言えば
TVゲーム市場は間違いなくレッドオーシャンで
しかも、壊滅的な状態になっていたわけです。

しかし、
ゲームセンターのゲームができること
そのために
妥協しないコンピュータを構成すること
を徹底することで
競合他社が存在しないブルーオーシャンに変えることが出来たということです。

さらに
情報誌の連携・充実
ライセンス契約により他社がゲームを開発して販売すること
をおしすすめ
世界中のTVゲーム市場で不動の地位を築いたわけです。

我々がアプリやWebサービスを制作するにあたり
極力、粗製濫造をしないこと
そのためには
何を大切にしなくてはいけないのか?

「アタリショック」から「ファミコンの席巻」までの流れの中で
学び取るものは数多くあるように思います。  

画面サイズが大きくなった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グルメで静岡のグルメ店を探してみてください。
  

最近すっかり涼しくなり、外も秋のにおいがしてきましたね！
秋冬が好きなので、テンションが上がりつつある望月です。

すっかり忘れ去られている、勉強用の「おもちテストサイト」・・・。



今回は、これを少しだけ成長させてみました。

メッセージを送れるようにしてみた

使用しているBootstrapのテンプレートには、メールフォームがあります。
そのままでは正しく動作しないので、望月にメールが届くようにしてみます。

望月にメールが届くようにする

Bootstrapテンプレートはとても親切で、メール送信のためのphpファイルが既に用意されています！！！




ファイルを書き換える際の説明もちゃんとあります。（英語・・・）

入力されていない項目があると「No arguments Provided!」とエラーが出て
フォームからPOSTで受け取った値を当てはめながら件名、本文、ヘッダーをつくり、
toアドレスへメールを送信という流れでしょうか。

ということで、toアドレスを自分のものに変えてみました。
そして、実はテンプレートから電話番号入力欄を削除しているので、その部分の入力チェックもはずします。
さっそくメールを送ってみましょう。




↓





フォームで入力した内容が、きちんと送られてきました。
ただし、フォームからメッセージを送信した後のサイト側は




このとおり、真っ白です。(なんと不親切なんでしょう！)

ということで、もう少し変えていきます。

(仮)送信完了画面をつくる

真っ白画面ではさすがに良くないので、簡単な送信完了画面をつくりました。
メッセージありがとう！という文章と、トップページへのリンクがあるだけですが＾＾；




完了画面をモーダルウィンドウで表示して、はじめからトップページに戻っているようにしようと思ったのですが、うまく動作しなかったのでまた試してみます。。。


そして、このままでは送信完了画面でリロードするたびに、メールが送信されてしまいます。
入力内容の確認もできません。
まだまだ改良の余地ありです・・・。

最後に

次回のブログ当番の時には、いろいろ完成させてプラスαに進みたいと思います！
それから、コードを画像ではなくコードのまま載せられるように調べます！

以上
  

さっそく本題に入っていきます。
システム開発の工程について、もうちょっと自分の考えを書いていきたいと思います。

まずは、システム開発時に私が現状やりやすいなーっと思っている工程から。

【開発工程①】
01.要件定義
02.外部設計（概要設計）
03.内部設計（詳細設計）
04.テストケース作成
05.コーディング
06.テスト
07.リリース

前回書いた工程とほぼ変わりはないのですが、テストを一纏めにし、結合テストと総合テストをまとめた内容を行います。
単体テストを除いた理由としては、デザインとシステムが密接に関わるため、システム側のみの単体テストの意味があまりないからです。
また、結合テストと総合テストをまとめた理由としては、基本的には画面の表示、操作のテストとなり、結合テストと総合テストで内容の差があまりないためです。

基本的には設計を重視し、それ以外の工数を削減するというシステム開発の工程です。
テストについては現状手動でやっていますが、いろいろ調べてみるとテストを自動化するツールが結構あるので、
単純な部分はツール、複雑な部分は手動で行うようにして、できる限り手動でやる部分を少なくすることで、
ミスや工数の削減につながるのではないかと思います。

次に、個人的にはこれができたら一番いいんじゃないかなと思う工程です。

【開発工程②】
1.要件定義
2.コーディング
3.リリース

要件定義後、実際にコーディングをしてしまう方法です。
設計書などの文章ではなく、実際動くものを作っていくので、お客様は作っているもののイメージがしやすく、
設計書、テストケース作成などの工数をすべてコーディングにまわせるので、システムの作りこみに専念できると思います。
また、この方法での最大のメリットは、動くものをどんどん作っていくので、SEが主導となって開発ができる点です。

この方法については、かなりメリットが多いのですが、
その分、全体像を把握した上で、動くものをどんどん作っていかないとならないので、SEとしての高い技術が要求されます。


ざっくりと二通りの工程を書いてみましたが、もちろん他にもいろいろなシステム開発の工程はあります。
正直、どれが正解でどれが間違いかはなく、ユーザの要求、開発規模等に合わせ臨機応変に変えていくのがベストではないかと思います。
そのためには、現状の開発工程がやりやすいからと固執せず、まず様々なシステム開発の工程を経験した上で、メリット、デメリットを把握し、使い分けられるようにしていかなけれいけません。

ということで、次の開発では開発工程から考えてシステム開発を行っていきたいと思います。