教える

ご縁があって、学校でWeb制作を教えることになりそうです。

学校と言ってもWebクリエイター向けのコースではなく、アパレル系を目指す人の応用としてのWeb制作なので、HTML/CSSを少しさわって、パーツ切り出して、ブログでもカスタマイズできればいいかな、という程度です。

でも、まだ理事長にお会いしていないし、シラバスも作ってる途中なので、本当に4月から始まるのか不安。目標はまず授業に行くこと…ですかね。リハビリがんばります。

教わる

ポルトガル語から遠ざかること13年。

すっかり錆び付いたポル語力を復活させるべく、ポルトガル大使館主催のポルトガル語教室に申し込んでみました。ついでにかみさんも巻き添えに、入門クラスに入ってもらいました（笑）

こちらも続けられるといいな。

あ、年賀状ですが、7日までに出せませんでした。すみません。寒中見舞いを出せればいいな、と思っています。やっぱりデザイン屋なんだから、自分でデザインをしたい、と思ったものの、

年末進行→忙殺→ダウン→気付いたら松の内が終わってた

と、まあ毎度毎度のパターンで敗北しました。うう、今年の年末こそ年賀状を作るぞ！（11ヶ月も先だけど）

『HOME’S』が、東京23区および東京都市部に在住の男女を対象に2007年から開始している「住みたい街」ランキングを今年も発表。3年連続で【吉祥寺】が1位となり、2位【自由が丘】に3倍以上の得票差をつけ、圧倒的な人気を実証した。

引用元: 都民が選ぶ住みたい街「吉祥寺」が3連覇 オリコンランキング

自分の中では、もっと城南の方が人気かと思ってましたけど、中野、高円寺、府中、三鷹、国立みたいな京王・中央線辺りが結構上の方に入ってますね。どこも行ったことがありますけど、確かにそれぞれ住みやすそうですね。

個人的に、次に住みたい街は「西荻窪」かな。駅の周りはごちゃっとしているんですけど、カフェや雑貨のお店がここ数年で増えて楽しそうなのです。吉祥寺にも自転車ですぐだしね（結局吉祥寺かよ。笑）。

• いまさらですが、10/31のF-siteは楽しかったです。でも、翌日親戚を訪ねて行ったりしていたら、翌週の前半はつぶれてました。二次会も行かなかったのに。
• 体重が増えました。秋はご飯がおいしいよね（苦笑）
• 名刺が刷り上がりました。もう人と会う前に自宅のプリンタで作らなくてもよくなりました。
• 今やっていること。
  Ajax気味。でもライブラリをちょっといじる程度で、何か作っている手応えはまるでないのです。
  あと、マーケティングのお勉強。eコマースで役に立ちそうな書籍やサイトがあったら教えてください。
• 今やりたいこと
  1. WordPressのごく小さな勉強会。
     割と概論で終わってしまう勉強会が多いので、ハンズオンでテーマを作ったりすると楽しそう。
  2. WordPressのたたき台用テーマ（テンプレート）の自作。
     こんなテーマ
     http://www.plaintxt.org/themes/sandbox/
     http://wp.vicuna.jp/
     でもそれぞれに少しずつ使いづらいところがあるのです。
  3. WordPress MUを少しずつ動かしてみる
  4. AIRを少しずつさわってみる
     職場の雰囲気的に（笑）でもAIRにちょっと逃げ込む。
• 今やらなければいけないこと。
  たくさん。

では、この辺で。おやすみなさい。

「業績の上がらないWebサイトは、いくらかっこよくても意味がない」

というものです。これは、自戒を込めています。

クリエイター、特にデザイナーは当然かっこいいビジュアルを作り上げたいと考えます。ある意味、当たり前すぎることですが、この点は見過ごされがちです。多くのデザイナーは、情報アーキテクチャ（IA）やマーケティングに長けているわけではありません。デザイナーは自分のクリエイティビティを生かして、一生懸命「かっこいい（きれいな）デザイン」を作り上げようとします。

それ自体は全く問題ありません。見た目のよくないデザインより、見た目のよいデザインがいいに決まっています。問題は「ビジュアルがきれいなWebサイトと、業績の上がるWebサイトは別」という認識が関係者で共有されていないことです。

発注サイドにいてすら、かっこいいデザインが上がってくると、それに満足してOKを出してしまいがちです。ここで見た目のことは一旦置いて、プロジェクトの目的に適っているかどうか、ユーザーにとって使いやすいかどうか、必要があれば第三者によるテストなども行って評価してみましょう。

まとめると、デザイナーもディレクターも発注者（Web担当者）も、プロジェクトのメンバーは皆Webサイトで実現したいことを明確にした上で目標を共有し、忘れないようにしましょう、ということです。脱線しそうになったら、軌道に戻しましょう。リリースしてからも、きちんと効果を測定して、得られた結果を次のステップに生かしましょう。

今日、連休初日は結局寝てましたね。ここしばらく睡眠があまり取れなかったので、体が夕方まで動かなかったです。

そうそう、mixiアプリは試しにいくつか入れていて、テトリスくらいで満足していたのですが、カーレーシングゲーム（と言ってもパーツ変えたり、イベントで経験値上げたりという感じ）や菜園育成ゲームが意外によく出来ていて、ちょっと手の空いた隙にいじったりしています。

告白します。開発者アカウントを取ってベータ版から見ていたのですが、その時は「どーせ、流行んないよ」とか思っていたんですよ。ところが、リリースしてみると最初とまどいを見せていたユーザーも、少しずつアプリを入れて、今では結構なユーザーが何らかのアプリは入れて、少なからず継続的に楽しんでいるようです。

意外に思ったこと

結構女性のユーザーさんがアプリを試しているんですよね。上に書いた育成ゲームはビジュアルも可愛いし、他のマイミクの農作業を手伝ってポイントが上がったりするので、似たような種類の別アプリも含めて、結構プレイしているようです。

mixiアプリモバイル

モバイル版も着々と開発中のようです。モバイルではモバゲー、GREEを追う立場になるので、どういう展開になるか少しだけ楽しみです。

フジテレビの人気バラエティ番組「はねるのトびら」のコーナー「短縮鉄道の夜」は、「アケオメ」「ドクモ」「マンキツ」と短縮される若者言葉の正式名称を答える人気コーナーです。
（中略）
このコーナーで「PV」とでました。私の口をついてでたのはホームページの閲覧単位である「ページビュー」。ところが正解は「プロモーションビデオ」。故マイケルジャクソンさんが革命を起こしたミュージッククリップが世間一般的な「PV」です。そしてある朝、家電量販店のチラシに「ウイルス対策」とあり、何が掲載されているのかと目をやるとそこにあったのは「空気清浄機」でした。さらに「クッキー」という単語に過敏に反応し「業界脳」の切り替えができていないことを反省します。
PVとはなんだ。それはマイケルが変えた世界 | Web担当者Forum

はい、自分の脳味噌も完全にネット脳になっていました。もちろんそれでよい立場の人もいるわけですが、自分はWeb制作の発注元の方と直接お話しをすることも多く、相手が皆さんネットに通じているとは限らないのです。

自分のようにクライアントとクリエイター、エンジニアのハブになるような立場の人間は、それぞれの世界の言葉を知り、正しく翻訳して橋渡しをする必要があります。視野は広くもっておきたいものです。

時代を感じますなあ…

でも自分の関心は、楽天の次に何が来るのか、ということの方にあります。

「残業プログラマの雑記」のid:zan-gyo様から追記記事のトラックバックをいただいたので、拝見しました。

とある商品が複数個購入された場合に端数の累積をどのように扱うかは店舗次第ですが、一般的には購入者側に負担が少なくなるように処理するのが普通かと思います。

（中略）

• 端数処理を 切捨て で行う仕様の場合は単価毎に消費税の端数処理を行い数量で掛けると金額が少なくて済むのでEC-CUBEの現行の仕様で問題ありません。
• 端数処理が 四捨五入 か 切り上げ の場合は単価毎に端数処理を行うと誤差が累積します。

今回私が携わったBtoBサイトでは「税抜き価格入力に対する四捨五入」が条件でしたのでお客様の負担を軽減するためには端数処理の計算方法の変更の必要が発生したというわけです。

なるほど。確かにEC-CUBEの仕様（たまたまローカルに入っていたver.2.3.3で動作を確認しました）によれば、端数処理を「四捨五入」「切り上げ」にした場合、税額が本体価格の5%を超えるケースが発生します。これは購入者側にしてみれば便乗のように見えてしまい、よい印象を与えないと思います。

自分もFileMakerで請求書のデータベースを作る際、税込価格から税額を求める式では「税込金額×消費税率」の端数を切り捨ててから「税額」を出し、「税込価格−税額」を「本体価格」としました。上記と同じく「税額が5%を超えるのは印象がよくない」という考えからです。

尚、EC-CUBEには４つめの端数処理方法が存在します。大抵のBtoCサイトではこの方式を選択してカスタマイズするのが最も安定する方法かと思います。それは

• 消費税を０％に指定して
• 単価を税込価格で入力する。

画面表示時に税額を逆算する必要はありますが仕様として押し付けてしまえば一番無難かもしれません。

引用元: EC-CUBE 追記 - 残業プログラマの雑記

その通りだと思います。総額表示の趣旨からしても、税込価格で取引すべきということですから、消費税分を逆算するのが無難だと思います。

開発者が料金計算ができない。(超致命的！)

• 複数商品の価格を税別から計算する計算式がなぜか
  [ 端数処理(単価 * 税率) * 数量 ]
  + [ 端数処理(単価 * 税率) * 数量 ]
  + [ 端数処理(単価 * 税率) * 数量 ]
  + [ 端数処理(単価 * 税率) * 数量 ] = 合計
  になっている。
• 単価に課税処理してから数量で増したら端数処理の差が累積して大変なことに。

引用元: EC-CUBEはここが酷い。 - 残業プログラマの雑記

EC-CUBEのコードの問題はひとまず置いて（1.x系の時はテンプレートがtableレイアウトで途方に暮れたりしていましたが）、今回は引用部分について考察してみます。大本締め、財務省の説明は下記の通りです。

Ｑ５
「総額表示」への移行に伴い、レジシステムを変更する必要はあるのですか？

Ａ
「総額表示義務」は、値札や広告などにおいて「消費税相当額を含む支払総額」の表示を義務付けるものであってレジシステムの変更を義務付けるもの ではありません。しかし、「総額表示」の下で、「税抜価格」を基に計算するレジシステムを用いている場合には、下の例のような問題が生じ、消費者との間で トラブルが発生する場合があります。したがって、このような場合（税抜価格が20円で割り切れない商品・サービスを扱っている場合）には、 「税込価格」を基に計算するレジシステムに変更するなどの対応が必要になると考えます。

〔値札の表示〕157円（税抜150円）

※157円の商品を２個販売した場合

• 「税込価格」を基に計算：157円×２個＝314円
• 「税抜価格」を基に計算：150円×２個×1.05＝315円

消費者は、1個157円の商品を2個買えば314円のなると思いますが、請求金額が315円になってしまう。

引用元: 平成16年4月から「総額表示」が義務付けられています：財務省

「レジシステム」を「ショッピングカートシステム」に置き換えるとよくわかります。で、実際他はどうしているのだろう、と思って訪れた某モールR内のお店。支払い方法の表示は下記のようになっています。

お支払総額は以下の通りです。
(商品代金×1.05)＋(送料\600)

（中略）

消費税について

• 消費税率　5％
• 消費税計算順序　１商品毎に消費税計算
• １円未満消費税端数　切り捨て

では、実際79円（税抜76円）の品物を3つ、カートに入れてみます。結果は以下の通り。

税抜76円の商品に5%掛け、端数を切り捨てて税額を3円と計算。合計して9円を加算しているので、財務省の説明に従った計算になっています。ちなみに、税抜商品合計に5%を掛けて切り捨てた金額は11円です。

ネタ元の方も気にされているところですが、事業者から国などへ納付する税額って「課税売上高−課税仕入高×5%を切り捨て」で計算しますよね。徴収額の合計で計算することも可能なのかな。税務に詳しい方のつっこみをお待ちしております。

まとめ

EC-CUBEの消費税計算と総額表示は、今の仕様で正しいです。

ちなみに、総額表示は「消費者に対して商品やサービスを販売する課税事業者が行う価格表示を対象」としているので、個別見積によるBtoB取引などは、総額表示の対象ではありません。

税務など法律関係はややこしくて、エンジニア泣かせですね。本当にお疲れさまです。

（17:09 追記）

これが答えかな。

Ｑ６

一領収単位（レシート）ごとの端数処理の特例（旧消費税法施行規則第22条第１項）は、どうなっていますか？

Ａ

従前の規則第22条第１項（課税標準額に対する消費税額の計算の特例）は、 事業者が、代金決済のたびに、代金を税抜価格と消費税相当額とに区分して領収し、発行するレシート等にその消費税相当額の１円未満の端数を処理した後の金額を明示している場合に、消費税の納税申告にあたり“売上に対する消費税額”を計算する際、その明示された端数処理後の消費税相当額を基に計算（いわゆる積上げ計算）を行うことができる特例ですが、これは、「税抜価格」の表示を前提に、決済段階で上乗せされる消費税相当額の端数処理に伴う事業者の負担等に 配慮して、少額･大量の取引を行う小売業者等を念頭に設けられた特例制度であったことから、「税込価格」の表示を行う総額表示が義務付けられたことを踏まえ、廃止されました（平成16年４月１日）。

しかし、それまで「税抜価格」を前提とした値付け等を行ってきた事業者が多いこと、また、「税込価格」を基に計算するレジシステム等に変更する必要がある場合でも、レジシステムの変更にはある程度時間を要する方もいると考えられることなどを踏まえ、以下の経過措置が設けられています。

（中略）

2.
「税込価格」を基礎とした代金決済を行う取引（総額表示義務の対象とならない事業者間取引等を含む。）「税込価格」を基礎とした代金決済を行う際に発行される領収書等において、その領収金額に含まれる消費税相当額（その領収 金額に5/105を乗じて算出した金額）の１円未満の端数を処理した後の金額を明示している場合に限り、その明示された端数処理後の消費税相当額を基に消費税額の計算を行うことができる特例が当分の間の措置として設けられています。

引用元: 平成16年4月から「総額表示」が義務付けられています：財務省

なるほど。原則廃止だけど、経過措置として残すということでよろしいですかね。

参考：課税標準額に対する消費税額の計算の特例｜消費税｜国税庁