2011年12月28日
とことん手抜き家計簿ソフト構想
ふと思いついただけのものだけど、とりあえずメモ
市販の家計簿ソフトはだるい？
これは性格にもよるが、以前家計簿マムを使っていて、最初は便利だと使っていたんだが、細かい部分に不満があったり、なにより同じ商品名を毎回入力するのが面倒くさい。
一応、一度登録するとリストに登録されて候補が出るようにはなるんだが、登録した名前でしか反応しない。
これが、レシートを元に入力してると、店によって名前が違うから使いにくい。
たとえば、コカコーラ500mlのペットボトルを買うと、ある店では「コカコーラ 500ml」、違う店では「PET コカコーラ」などなど。なんか微妙にころころ変わる。
そして、登録項目が増えると当然候補も増えるわけで、やっぱり手間がかかる。
バーコードで管理を考える
すべてではないが、基本的にスーパーなどで市販されているメーカー商品にはすべてJANコードというバーコードがついている。
日本製品だと49から始まる13桁くらいのアレ。
それをバーコードリーダーで読ませればいい感じに楽に管理できるのでは？
すべてがJANコードではない
バーコード管理でネックなのが、すべてがJANコードというわけではないということ。
いわゆる店内コードというもので、店内のみに使用されるもの。
たとえば、店で調理した魚とか肉とか寿司とか総菜とかそういうもの。
が、これらを作るたびに登録しなおしてるほど手間をかけてるとは思えないので、基本的に1度登録すれば店内コードも固定化されているのではないかと考えている。
なので、ダイエー+なんとか上寿司みたいな組み合わせで店内コードを登録すればいけるかも。
バーコードデータをどこからひっぱるか？
ある程度は、アマゾンとか楽天とかのウェブAPIサービスを使えば自動化できるが、すべてがわかるわけではないし、ましてや店内コードとか無理である。
そこで、バーコードデータベースをソーシャル化して、つまりみんなで協力してデータベース作ろうぜ！というわけである。
店内でバーコードリーダーを使うのは怪しい人
店内で商品をかごに入れるたびに、バーコードリーダーを持ってピッとかやってたらあやしい人レッテルがもれなくもらえる。
下手したらライバル店の調査とか思われて、止められるかも。
そもそも、リーダー自体が1万近くと結構高め。
帰ってから家でリーダーを使うならいいが、店頭でやるなら方法は2つ
QRコードが読めるんだから、1次元バーコードも読むことはできるはずである。
２，JANコードの最後の5桁くらいを手で入力
バーコードは国番号+メーカーコード+商品コードという構成なので、この商品コードに該当する部分だけを入力すれば候補は多くても2，3程度のはずだ。
どっちにしても、文字を入力しないという点ですぐれているが、データベースができていないと使いようが無い。
安直な発想は誰もが思いつく
このバーコード管理方式の家計簿が画期的な発想か？というとだいたい誰もが1度は思いつく考えなわけで、実際にそういうサービスもある。
このサイトは商品1つ登録すると1ポイントもらえて、500ポイントから交換できるとか。
なんでこんなポイントがつくかというと、あなたの買い物情報をマーケティング情報として売ってその一部を還元してるから。
すでにある物を使うというのも選択肢の1つ。
いまバーコード家計簿ソフト（サイト）を作って運用がうまくいくか
サイトの構成次第じゃなかろうか。
大手みたいにポイント還元とか現金還元とかは個人ではまず無理だ。
アイディア勝負で、たとえば店舗の割引情報や価格情報を共有したりとかいろいろ組み合わせればそこそこ集まるのではと思う。
ただ、データベースは膨大になるので、やはり環境的に厳しいかも？
結論、とりあえず放置
アイディアだけ書いておいて、もしかしたらそのうちもっといい案が思いつくかもしれないのでそれまで放置。
手帳リフィル作成ソフトの構想
いま現在、オリジナルの手帳リフィルを表計算ソフトで作って使っているが、それを専用ソフト作ってやりたいな〜という気持ちがあるのでアイディアだけメモ。
リフィルデザイン
いまのところ表計算ソフトで作ってるものでおおむね満足しているのであんまり高機能なものはいらないかも。
ただ最終的なデザインは満足してても、そこに至るまでのデザインの微調整が非常に面倒くさく時間がかかるので、専用ソフトでそこら辺が楽になればいいなと。
個別データ取り扱い
ここでいう個別データとは、リフィル内に書き込む予定とか住所録とか。
表計算ソフトだと、一度リフィル面に書き込むと、データを追加したり位置がずれたりしたときに全面的に書き直さないといけないという面倒くさいことも。
あと、デザインを変えたいと思ったときも1から全部書き換えないといけないとか。
ということで、データの取り扱いはすべてcsvでインポート/エクスポートして、データの構造自体はシンプルに。
リフィルデザインデータ
リフィルデザインも作ったやつをインポート/エクスポートできればいろいろ便利だな〜と思うが、さすがにcsvだけでデザイン管理をするのはかなり厳しい。
たぶん、xmlを拡張した仕様になるはず。
デザインの共有
上のデザインデータにもつながるが、自分よりも優秀なデザインリフィルを考えてくれる人が現れるはず！
ということで、リフィルデザインを共有する仕組みが必要。
ただ、これはソフトだけでなくサーバーの準備とかも必要。
開発言語
どの言語で作ろうか考え中だが、Adobe Airがデザインなどでいい感じな気がする。
Javaならよく使っているが、Airのアプリをいろいろ見る限りセンスがありそうなので、流れに乗ってみたり。
でも、実際に作ってみてだめそうなら他の言語に移るかも。
そんなわけで、ただいまAdobe Airの開発入門をだらだら見ながらどうっすっかな〜と考え中。
なにせ他にも作りたいものがあるので、なかなか進まない…
でも、ソフト作りたいランキングの中では結構上位だよ！