Sharp IS01エミュレータースタート

Sharp IS０１はちょっと・・・・というかかなり特殊なサイズのAndroid端末です。しかもAndroid1.6ということで、今まで開発していたASE Rally Monitor100だと、そもそもアプリが対象外となってしまい、インストールできません。

ということで、IS01で使えるように、別バージョンとして開発をスタートしますが、いかんせん端末がないため、エミュレーター頼みということになります。

ところが、IS01のエミュレーターがまた微妙に起動が面倒。直接AVDマネージャーからは起動できず、コマンドラインからでないと起動できないということらしいです。ということで、以下のサイトを参考に起動してみました。

https://sh-dev.sharp.co.jp/android/modules/sdk/index.php?/sdk

ちょっと手間取りましたが無事起動して、早速テスト。

IS01の起動画面を始めて見ましたが、画面右サイドに、ハードキー代わりのタッチメニューがあるんですね。これなら押しやすいかも。何せ、同じシャープでもDocomoのSH-０３Cのハードキーは、小さくて押しにくいものですから・・・。

IS０１でうまく動けば、かなり使いやすいかな？と改めて期待してみました。テストバージョンを使っていただいている方からの報告を待ちたいと思います。

中華PADへの対応

ここのところ、沢山の方々からASE Rally Monitorに対して興味をいただいており、大変ありがたく思っております。

これまで、

・Galaxy Tab
・Optimus Pad
・IS03
・IS01

と、一般的なスマートフォン以外での利用希望をいただいており、順次対応をしていますが、最近新たなご連絡をいただきました。それは

中国産の格安Androidタブレット

です。

ご存知のとおり、Androidタブレットは、現在国内メーカーのものは殆ど無く、携帯各社からリリースされているものもほぼ１００％が海外メーカーのものです。

したがって、海外メーカーのタブレットというのは特別なものではなく、むしろ海外メーカーの方が積極的と言えるでしょう。奇しくも今日発売される”iPad2”などは、Androidではありませんが、その典型ですね。

さて、そんな中、ネットではよく目にする”中国産の格安Androidタブレット”、通称

中華PAD

ですが、少なからず興味を持っている方もおられるのではないでしょうか？

上はそれなりの値段から、下は１万を切るものまで、サイズも１０インチオーバーのものから、なぜか正方形のものまで、もうそれは多種多様なものがあります。

この中華PADを利用してASE Rally Monitorを利用できないかな？と私自身も思っておりましたが、実は中華PADの多数は、”GPS"を搭載していません。

ASE Rally Monitorでもっとも重要なのが、この”GPS"ですから、GPSを搭載していない端末は当然ながら利用することができません。また、なぜか”Android5.0搭載”などという謳い文句だったり、絶対これは？？というものも結構目につきます。

従いまして、中華PADの場合、まず機種選定からかなり慎重に行う必要があり、且つスペックだけでは読めない部分もあるため、かなりギャンブル的な選択は避けられないかな？と思います。

しかし、そんな過酷な選択条件である中華PADにてASE Rally Monitorの動作テストをしていただける方が現れましたので、ご協力をいただくことにいたしました。

早速、アプリのインストール段階でストップしてしまったようで、どうなるかわかりませんが、お楽しみに。

AndroidスマートフォンのGPS更新レート

先週、外部GPSロガーを入手して、早速更新レート５Hz(1秒間に5回更新）にてテストをしたら、処理が追いつかないようで、表示が引っかかるようになってしまいました。

そこで、少しレートを落として3Hzにて再チャレンジ。

結果は、５Hzよりはマシになったものの、まだ引っかかりはなくなりません。

ちなみに、Androidスマートフォンの更新レートは最短で”1Hｚ”です。

どうやら、この1Hzというのを最短レートにしている意味が分かってきたような気がしないでもないですね。通常、スマートフォンを使ったGPS関連アプリで、もっとも考えられる一般的なものといえば

Googleマップ

だと思います。GPSをオンにした状態でGoogleマップを起動すれば、常に現在地が表示され、カーナビのように表示します。さらに、

Googleマップナビ

を使うことで、まったく普通のカーナビとして道案内してくれます。もはやポータブルナビの時代は終わったと思うことでしょう。

で、これらのアプリでGPSを使う場合、正直1Hzもあれば使用に問題はない感じです。前にも述べましたが、時速60ｋｍ/hの際の秒速は約16.5mです。つまり、直前の案内から16.5m前後に交差点がある可能性があるということになります。これって、よほど街中で込み入っていない限りは走行上の問題にはならないでしょう。

ましては、他のGPS関連アプリも一般的にはこれ以上の更新レートは不要でしょうし、今回のテストのように、更新レートをあげれば、次の処理までの余裕がなくなるため、いろいろ弊害が出ることも想定されます。

ということで、余裕を持ってAndroidスマートフォンのGPS更新レートは1Hzなんだろう、と都合の良い解釈をしてみました。

スマートフォンは携帯電話ではなく、小型PCに通話機能がプラスされている端末だという認識でいますが、物には限界があるということで、過度な期待をすることなく、適材適所の役割を求めていく必要がありますし、そうした認識を持ってアプリを開発することが必要なのかもしれませんね。

Androidスマートフォンに外部GPSを接続

昨日到着した外部GPSロガー「Trip Recorder747pro」を早速設定してみます。

更新レートは1Hz~5Hzまで5段階で設定可能で、付属のソフトをインストールすると簡単に設定できます。更新レートは”Fix Update-Rate"にて選択します。




とりあえず、せっかく5Hzまで設定できるので、5Hzにて設定します。

ちなみに、現在のGPSの各種データは同じソフトにて確認することができます。



室内でもしっかり衛星を捕捉している様子が分かります。Speedが0ｋｍ/ｈでないのは、室内により精度が落ちているため、仕方が無いでしょう。

GPSロガーの設定はこれだけでとりあえず終了。

ただし、ASE Rally Monitor側でプログラムの修正が必要になってきます。というのは、今までの端末内蔵GPSを利用する際には、AndroidスマートフォンのGPS更新レートがMaxで1Hz、つまり1秒に1回でした。で、取得できる速度データというのが、”秒速”。つまり、更新レートが1秒に1回ならば、そのときの秒速をそのまま距離に加えてあげればよかったのです。

で、今回は1秒間に5回のデータ取得になります。つまり0.2秒ごとに取得するわけですが、その際に取得する速度も先ほどと同じように”秒速”になりますので、単純に加算してしまうと、1秒間に5秒速分の距離が加算されてしまいます。

ということで、取得した秒速の1/5を加算すれば良いのですが、実際には浮動小数点から整数へのキャストの際に、ちょっとした問題も発生します。まあ、この辺はそのうち機会があればということで。

早速プログラムを修正していよいよテストをスタート。

まずは、GPSロガーとスマートフォンをBluetooth接続します。一度設定してしまえば、あっけないくらい簡単に接続完了します。

いよいよASE Rally Monitorを起動。この際、スマートフォンのGPSをONにする必要はありません。
既にGPSロガーが接続されていれば、すぐにASE Rally Monitorもスタンバイ完了します。

実際に走行してみると、今までのこま切れ状態から、やたら目まぐるしく距離が動き始めました。

ただ、あまりに一生懸命更新するためか、スマートフォン側の処理が追いつかないような感じで、ある程度追いつかなくなってくると、表示がひっかっかるようになりました。一定間隔でひっかっかるので、処理速度の問題だと思われます。

ということで、今度は３Hzに落としてみてテストをしてみようと思います。

外部GPSテストに向けて

既に何度か報告しているとおり、Androidスマートフォンに内蔵されているGPSは、最短で更新スパンが1秒/1回が仕様となっています。中には違う端末があるかもしれませんので、その場合はご勘弁を。

で、この状態では、トリップメーター及びスピードメーターの更新も1秒毎となるため、

パッ　　パッ　　パッ

という感じで表示され、結構違和感を感じます。慣れてしまえば”こんなもんだ”と思えるのですが、それだけではつまらないので、テストを兼ねて外部GPSを利用してみることにしました。

外部GPSとスマートフォンはBluetoothで接続しますので、まず条件としては

・Bluetooth装備

のGPSロガーである必要があります。GPSロガーは各種ありますが、同じ格好をしていてもバージョンによってBluetoothが装備されていないものもあるので、注意が必要です。

そして、次の条件としては

・更新レートが２Hｚ以上

つまり、2秒に一回以上位置情報を更新するGPSロガーである必要があります。というか、それ以下だとわざわざ外部GPSを使うメリットがあまりないですからね。

中には１０Hz以上というものもありますが、後でも記載しますけど、あまり意味がないです。というのも、仮に時速６０ｋｍで走行しているときの秒速は16.7ｍ程度。1/10秒速は1.67ｍ。1/5秒速は3.34ｍ。ちなみにGPSの位置精度が１ｍ前後。つまり大雑把に言えば、1/10秒測でも誤差によっては2.67ｍになり、1/5秒速でも誤差によっては2.34ｍになるということです。この誤差が時速60ｋｍで走行しているときに許されるか否か？が問題ですが、ASE Rally Monitorのターゲットでは全く問題無しと考えています。

もちろん更新レートが高いほどより正確になる”可能性がある”のですが、処理速度が落ちたり、ｍ単位が切り替わりすぎて読みにくくなったりと、デメリットもあると考えます。また、GPSロガー自体も5Hzと10Hzで倍の仕事をするために、バッテリーの持ちにも影響が出るはずです。

ということで、長くなりましたが、更新レートは2Hz以上で5Hzまでのもので十分かな？と考えます。実際に現在の流通では

・1Hzまで
・5Hzまで
・10Hzまで（かそれ以上）

の3区分ぐらいに分かれますので、今回は5Hzまで対応するものを選択します。

最後に、実売価格ですが、高いものは数十万円以上までありますが、それではスマートフォンでやる意味がなくなります。実際には1万円というのが一つのボーダーラインではないでしょうか？

最終的に私が今回選んだものはこれです。

Transystem社　
Trip Recorder 747pro





Amazonで、急がなくてもよければ、送料無料・代引き手数料込みで1万円をギリギリですがきってます。その他にも同じメーカーのこんなのもあります。

PhotoMate 887


こちらの方が1000円くらい安いです。

なぜ、PhotoMate887にしなかったか？というのは、

・標準で付いてくるソフトで1～5Hzの5段階を簡単に切り替えられる
・アンテナ精度が良い（らしい）
・自動でON/OFF
・稼動時間が倍以上

など、1000円の差以上の価値があると思ったためです。なお、画像でみると同じ大きさのようですが、実際には倍以上違います。PhotoMateは小さめな消しゴムくらいですが、747proは、ちょっと小さなマウスくらいあります。

ということで、GPSロガーを入手し、テストをスタートしました。その様子は次回以降にお送りします。

キャリブレーションモード追加中

ラリーは主催者から提供される”ロードブック”という地図により走行いたします。

このロードブックには、次の交差点までの距離が記載されていますが、これは主催者があらかじめ任意の車両にて計測した距離です。車の距離というのは、ある程度の統一化がされてはいますが、標準状態からタイヤ外形を変えたりすると、距離というのは異なってきます。

よって、ロードブックに記載された距離と自分の車（ラリーコンピューター表示）の距離というものには、必ず誤差が生じてしまいます。

この誤差を補正するために、ラリーコンピューターには距離補正モードがあります。

ASE Rally Monitorにも当初から距離補正を設定できる項目がありましたが、暫定仕様ということで、今までは補正係数を手計算であらかじめ出しておき、この数値を登録するという、かなり面倒な仕様でご迷惑をおかけいたしております。

やはり、なるべく簡単に操作するために、このたび

キャリブレーションモード

を実装してみました。

これは、ロードブックなどで特定区間を走行し、その区間のロードブック記載距離を入力するだけで、補正係数を自動計算し、登録してくれるモードです。

従来のラリーコンピューターでは特別珍しいモードでもないのですが、ASE Rally Monitorでどのように実装するかを試行錯誤していました。

とりあえず、計測開始・終了処理で登録できるので、大分簡単になったかと思います。近々他のアップデートと共に公開予定です。

GPS更新レートを上げたい

レイアウトの対応も少しずつではありますが、進めております。リクエストがございましたら、まずはご相談ください。

さて、これからテストを予定しているのが、

外部GPSによるログ精度の向上

です。

スマートフォンに搭載されているGPSは、現状ではどの端末も

更新レート：1Hz

かと思います（もっと良いものがあったらゴメンなさい）。

1Hzというのは、1秒間に1回位置情報を取得するというものです。Androidアプリの中でも、一般的な位置情報を使うものに関しては、1秒間に1回取得すれば十分なのかもしれません。TC方式のラリーについても、正直1Hzで必要十分かな？と思っています。言い方が悪いですが、所詮GPSです。精度的にもこれ以上頻繁に更新をしたところで、特別なメリットがあるかというと、微妙な感じはします。

私が以前テストしていた海外のとあるラリーコンピューターについては、車速センサーから取得しているにもかかわらず、ディスプレイが液晶だったため、液晶表示が追いつかないためリアルタイムに表示されていませんでした。確か1秒近くスパンがあったような気がします。それでも某WRCワークスなどでも一時期使っていましたからね。

さて、そうは言っても、スムーズに動いた方が少なからずメリットはあります。

そこで、外部GPSロガーを使って、内蔵GPSの代わりにしようという試みをすることにします。

結果などは後日報告できるかと思いますので、今しばらくお待ちください。

昼用配色をテスト

レイアウトについては、確定しているのですが、実際のシチュエーションとしては昼間の車内というのがかなり割合としては大きいと思われます。その場合、スマートフォンならではなのかもしれませんが、ガラス面に入射光が映りこんでしまい、時として視認性が大きく落ちるということがあります。

そこで、カーナビを参考に、昼用の配色を現在テスト中です。

最初は背景すべてを”白”にしたのですが、そうすると真ん中の”緑”がよく見えなくなってしまいます。今回のアプリはこの色に重要な意味があるため、昼用だからといって色を変えることは望ましくありません。

そこで、この部分のみグレーにしてみました。

また、右上の箇所も時間によって色が変わり、これも意味があるため、このような感じになっています。

とりあえず、この状態である程度テストはしてみますが、そもそもハード的に入射光に弱いというのはいかんともし難いので、最終的には日よけ等を作る必要があります。ただ、自動車のメーターやカーナビなどでも、結局は日よけがあるから昼間でも見えるということには違いないため、スマートフォンだけの問題でもなく、あまり極端に考えこむ必要はないかな？と。

ちなみに、昼用⇔夜用は、設定で常時変更できるので、昼でも夜用で使うことは可能です。

まったくもって現在進行形

昨日の夕方から現在に至るまで、もう半端ないくらい揺れています。

私が住むつくば市は、直接の震源からは微妙に離れてはいますが、
震度５を昨晩乱発され、訳分からない状態です。

この1ヶ月、ほぼ毎日震度3以上が1回以上あるという、なんともはやな
状態が続いてしまったため、今では地鳴りを聞くと、大きさが予想できる
までになってしまいました。

北から南から地震に攻められ、まるでフェリーにでも乗って過ごしている
状態で、まさに”地震酔い”という意味が良く分かります。

昨日から発生している茨城と福島の県境を震源とする地震。この状況で
あの辺りの役所周りをする価値観は残念ながら私にはありません。

千葉県・茨城県・福島県・それ以北・・・。現在進行形だというのを日々実感
しています。

ジタバタしても仕方ないので、腹くくってしっかり歩んでいきましょう。

Android 3.0 エミュレーター稼動

とりあえずAndroid3.0のエミュレーターが稼動しました。

ホーム画面はこれ



背景については、カスタマイズできるだろうから置いておいて、画面は少しおしゃれなイメージを打ち出している感じですね。また、エミュレーターということでいくと、デフォルトがLandscape(横画面）になっています。Android 3.0がタブレット用OSだというのがこの辺りでも実感できます。もちろんPortrait(縦画面）でも使用できます。

アプリ一覧はこれ



エミュレーターの動作が遅すぎるため、あれこれ試す気がおきませんが、2.3以前とも別に違和感は無く使えるのではないでしょうか？

ちなみに、現在開発中のレイアウトがこれ



時計の一部がずれているように見えますが、丁度時間が切り替わるタイミングでのキャプチャだったので、不具合ではありません。一応Optimus Pad　8.9インチでしっかり無駄なくスクリーンを使えるようにレイアウトしてみました。Optimus Padの解像度は1280x768です。開発は一応10.1インチ1280ｘ800で行ってますので、たぶんXoomなどでも殆ど同じように表示されると予想しています。

実際にPCのディスプレイでエミュレーターを実寸表示してみると、8.9インチって結構大きいですね。開発しているアプリが自動車の助手席前面に搭載することを想定していますが、8.9インチぐらいになると、見易さは格段にあがる反面、結構存在感が出てきてしまうため、好みが分かれそうです。
最も、大きめのタブレットを好む人は、逆にスマートフォンなど4インチ以下のものは、あまり良い印象を持たないかな？と考えられます。

操作性・視認性で優れるタブレット端末、コンパクトで軽量なスマートフォン。それぞれのシチュエーションで最大限生かされるアプリを開発したいものです。

スクリーンレイアウトの個別対応

既に何度か出てきている問題として

Androidは画面レイアウトの統一が難しい

というものです。

画面サイズだけが違って、解像度が同じならば何の問題もないんですよね。たとえば、同じワイドテレビだと、19インチでも40インチでも、内容は同じで、余白等は基本的にはないですよね。逆に、ワイドテレビと4：3のアナログ時代のテレビの場合は、同じ番組を見ても、左右に余白があったり、上下がカットされたり、フルスクリーンにすると、顔が伸びてしまったりと、様々な問題が発生することは理解いただけるかと思います。

今のテレビだと、自動で解像度を調整して表示してくれるものもありますが、余計な手間が掛かっていることには違いありません。

これがAndroidの場合は、画面サイズと解像度が、そりゃもう端末ごとに違うといってもいいくらい、柔軟性にかけるというか、面倒なんです。

レイアウトを組む際に、ある程度柔軟に対応できる設計を組むことはできますが、これにも限界があり、100％すべてに対応することは現実的ではないと思われます。

実際に”デキる”プログラマーでしたら、何の問題もないことかもしれませんが、いかんせんまだまだ技量不足の私にとっては・・・。

幸い、ベラボウにアプリを使っていただいているわけではないので、この際、希望される方にはできる限りその都度レイアウトを組みなおしたものを提供してみようかな？ということにしてみました。

すべてのバージョンをマーケットに公開すると、いろいろ大変なことになりそうなので、ご購入いただくバージョンは１つとして、もし購入者が端末に最適化したものを希望する場合、個別に対応させていただこうというものです。

レイアウトは基本的に数値を弄るだけですし、端末が多いといっても、ある程度の区分けはできるので、その方が何かと都合がよさそうかな？と。始まったら大変なことになるかもしれませんが・・・。

こういうやり方は、たぶんその筋の業界ではイレギュラーというか、組織としてやっていては利益にならないかもしれません。でも、私のような個人の趣味の延長のものに、貴重なお金を投資していただいた方には、万全ではないかもしれませんが、できる限り対応していくことが感謝の表現かな？と考えていますので、どこまでできるは不安もありますが、がんばってみたいと思います。

Android3.0は果たして！？

先月末にdocomoからOptimus　が発売され、いよいよ日本にもAndroid3.0が上陸して参りました。3.0はタブレット用のＯＳということらしく、いろいろユーザーインターフェースが変更されているようです。

そんな中、早くもASE Rally Monitorご購入者の中にも、このAndroid3.0ユーザーが現れ始めて参りました。

一応、エミュレーターにも3.0用のものが登場しているため、動作確認をしようと思っていたのですが、この3.0エミュレーター、いかんせん動作が重い。今まで開発に使っていたＰＣではエミュレーター自体の起動まで5分近くかかり、起動後もまともに動いてくれません。

2.3までのエミュレーターも重かったのですが、それを超える重さに、もはや実用性にかけるものになってしまっているかな？とちょっと困ったちゃんです。

とりあえず、タブレットユーザーも登場してきているため、早急にタブレット用、主に7インチ以上を対象としたレイアウトを組んで、ASE Rally Monitor100は4インチ程度までのスマートフォン用、7インチ~10インチのタブレット用のもうひとつ、そんな振り分けをする必要がありそうです。

あまりにも端末による統一性が無いため、素人デベロッパーには悩ましい限りです。

iphoneアプリかぁ・・・

ここは”Android"とブログタイトルに銘打っているように、素人によるAndroidアプリ作成中の話をお届けしております。そこでなぜに”iphoneアプリかぁ・・・”となるのか？

それは、現アプリ開発中の段階からすでに、いくつか

”それiphoneの？”

と聞かれることがありました。それが、最近では

”iphoneでは出さないの？”

と変わりつつあります。

分かってはいるんです。iphoneユーザーの方が明らかに多いし、アプリというものに対する理解度もiphoneユーザーの方が進んでいるということも。まったくサラの状態から端末を選び、ラリーのような山の中で遊ぶことをしていなければ、たぶん私もiphoneを選んでいたかもしれません。最も、ラリーをやっていなければ、ラリーアプリは作らなかっただろうから、矛盾するのですが。

iphoneがいけないというわけではなく、それを仕切る某社のエリアが悪すぎるだけで、世界ではたぶんそういう思慮も無いのかもしれません。

ASE Rally Monitorは、自分自身の中で実装したい機能としては最低限クリアしたと思っています。ご利用いただく方それぞれで、評価は分かれるかもしれませんが、今までWRCまで出場してきた経験からすると、たぶん及第点はいただけるのかな？と。

もちろん、ご利用されている方から

”もっとこうした方がいいのに・・・”

というリクエストやご指摘があれば、できうる限り対応していくことには違いありませんが、それは今後実際にラリーの現場で使っていただいていくうちに徐々に出てくるかと思いますので、シーズンが始まったばかりの現在では少し様子をみようと思っています。

そう思っている矢先に、先日も

”ぜひiphoneでも！”

というありがたいお言葉をいくつか頂く中で、やはりiphoneとAndroidの普及度の違いというのを実感しています。

iphoneでも作りたいのはヤマヤマなのですが、いかんせん今の今まで窓際族ということで、禁断の果実を口にしたことがありません。開発そのものよりも、そこに至るまでの投資がかなり必要となり、もしiphone版を有料で出しても元は取れないだろうなぁ・・・・と思うと、貧乏人には中々手を出すことができないというのが現実ですかね。

ただ、こんな私などにも少なからずご期待の声をいただいているわけで、後学の為にも口にしてみようかなぁ・・・・とボンヤリと思っていたりもします。

まずは、だれかMacのスポンサーになってくれないかなぁ。もしくは、Android版で設備投資できないかなぁ、などと甘甘なスタンスで、のんびり進んでみようかな？と思う今日この頃でした。

ロードセクションモード考察

さて、時計＆トリップという基本機能が出来上がったため、いよいよラリーコンピューターとして実際に使える機能を装備することにします。

まず、ラリーと一概に呼んでも微妙にいろいろ違いがあります。バレーボールでは6人制と9人制があり、さらにビーチバレーという2人制というのもありますよね？微妙にいろいろルールは違うのですが、基本的に、

ボールを自陣で落としたら負け

というのは共通するところかと思います。

ラリーについても同じで、基本的には

速さを競う区間で速い人が勝ち

ということです。ただし、それだけではなく、速さを競う区間、つまりスペシャルステージ（SS)と呼ばれる区間へは一般公道を走行して移動します。その移動区間に対して、大会側が何の指示もしない場合、様々なトラブルが発生してしまいます。それを防止するために、移動区間を走行する所要時間を各参加者に与えます。それにより、秩序的に車両が走行することができ、スムーズな競技進行ができます。
その秩序を守るために、移動区間に対する所要時間を正しく守っているか否かについて、減点が与えられます。

この移動区間のことを”ロードセクション”とか”リエゾンセクション”と呼びます。この区間の減点の与え方は様々ですが、WRCなどでもしっかり与えられますので、大変重要な区間であることには間違いありません。

このロードセクションは、ロードブックという道案内図を元に走行しますが、これは交差点形状と距離が記載されています。つまり、

５．４３ｋｍ先の信号がある十字路を右折せよ

という内容が細かく記載されたものです。

従って、再三出てきている”距離”というものが、必須機能であるわけです。また、ロードセクションは基本的に

次のチェックポイントに40分後に到着せよ

という形で指示されます。よって、”時計”というものも必須機能になります。

ではロードセクションで必要な機能というのは、何か？

結論から言うと、”距離”と”時計”があれば成り立つというのは、上記の通りで理解いただけるかと思います。ロードセクションに対しては特別な機能はいらないのでは？

またまた結論から言うと、”その通り”なんです。

でも、今回はあえて”ロードセクションモード”を実装しています。その内容については、次回。

スマートフォンアプリには割り切りが必要？

とりあえず、時計とトリップメーターが完成しました。これで最低限ラリーに必要な機能としては整ったわけです。

しかしながら、一つ壁を乗り越えると、欲が出てくるもので、自分ならではの機能などを盛り込みたくなるものです。

ここで、日ごろ良く思うことがあるのですが、それは

技術屋は技術に溺れる

ということです。まさに、今の原発状況はそうですね。風評被害真っ盛りの茨城県民としてはつらいところです。

社会事情は置いておいて、技術屋さんというのは、持っている技術が高ければ高いほど、技術の追求心というのも旺盛で、現状で満足できない、ゴールが無い人というのは少なくないと思います。

最初、新しいものを作り出すときというのは、そういう追求心が多々必要だと思うのですが、ある段階から、それが必ずしもプラスにばかり働くとは限らないのでは？と思っています。

最初のうちは、スタートラインが近いこともあって、

利用者＞開発者

というものが、いつしかスタートラインから遠ざかれば遠ざかるほど

利用者＜開発者

と目線が移り変わっていってしまうようです。そのため、最初は利用する立場から物を作っていたはずが、結果としてはかなり利用しづらいものになる、そういうことって往々にしてあると思うのです。

これはスマートフォンアプリについてもきっとそうですね。

ASE Rally Monitorも最初の段階では、

時計とトリップメーター

ができれば満足だと思っていました。でも、少しずつアプリの作り方などが理解できるようになると、”もっとこうした方が良いのでは？”と欲望がでてきました。

そこで、ふと原点に立ち返ります。それは

・スマートフォンは操作性が専用のラリーコンピューターより劣る
・GPSの精度や距離表示が必ずしも正確ではない
・これからラリーに触れる方に抵抗が無い程度の操作性
・でも実際に最低限の装備をすることで、ラリーにも使える

というコンセプトや前提があったのです。このコンセプトを踏まえたうえで、改めて実装すべき機能と切り捨てるボーダーラインを決定する必要があります。

切捨てラインのもっとも大前提となったのが

TC方式ラリーで使えるようにし、アベレージラリーは対応しない

つまり、単純な形式のラリーをターゲットとし、距離が１ｍ単位で正確に必要になるアベレージラリーという種類の形式はこの際、ターゲット外とするということです。

これにより、必然的に網羅すべき機能が限定されてきます。

素人だからこそ、割り切りや”できない！”というのは抵抗感が無いのかもしれませんが、いろいろなアプリを使ってみたり、実際に自分で作ってみた感想として、

スマートフォンアプリに完璧を求めるべきではない

という一定の結論が出ました。

ということで、実装すべき次の機能としては、

リエゾン区間機能

の開発ということにしました。