2013年3月 のアーカイブ


あいかわらずのニッチなネタ。
「いわゆるガラケーのWEBサイトの対応はいつまで続くのか?」という問題は開発の現場でたびたび話題にのぼる。

「ゆるやかに減りつつも完全にゼロになるのは大分先」だろうという結論にだいたい落ち着く

あるあるネタ的な内容であるけれど、おおよそこの結論になる。理由はざっとこんな感じ。

まだユーザーがいる

実際にユーザーがいるのは揺るぎない事実。スマホに乗り換えるケースがどんどん増えているものの、携帯ショップに行けば僅かではあってもガラケーも選択肢として用意されている。
誰もがスマホに移行したいわけではないのも事実だし、スマホを使った結果、ガラケーの方が便利なのでは無いかということを言う人も。
現状の認識として、ガラケーの後継サービスがスマホであるということが決定的な状態では無い雰囲気でもある。

サービスが継続している

ガラケーからWEBにアクセス出来てしまう。今のところ出来なくなるというアナウンスは出ていないし、恐らくしばらくは出ないだろう。
インターネット接続サービスとしてメールとWEBアクセスをまとめて提供している限りは、無くすのは難しいのではないか。

注目がスマホにシフトしただけでは

スマホのサービスがイケイケな状態なので、相対的に地味になってきているだけという説。サービスは継続しているわけで、使っているユーザーがスマホの足を引っ張っていると考えれば目の敵にする傾向だって想像できる。
若干思い込みの部分もあるものの、お金に結びつきにくい存在になっているだけで、現状維持としてありつづけるサービスと考えるのは確かに無茶な話ではない。

でも開発現場が減っていますよね

ガラケープラットフォームがメインとして開発されるプロジェクトは圧倒的に少なくなったようだ。
実際、お手伝いさせてもらっているところでもガラケーもしますけどね…といった感触。切り捨てはしないけれど対応デバイスの一つであり、深追いして開発が手間取るなら機能削りましょう、という言葉が簡単に出る。

その結果

よくあることで、新規の開発者や蓄積されて資料の活用が減ることで、サービスの企画も差し障りの無いものになりやすい。
FlashLiteバリバリのサイトを作ろうという企画を立てるならばスマホのアプリを充実させた方が良いとか。
ガラケー特有の仕様についても深くケアされることが減り、cookieを使えない端末があることや、表示できる容量についての検討などもそこまでキッチリされなくなった印象がある。
大雑把に言えば開発に工数をあまりかけなくなった。

それでもサービスは残る

ということで最初に戻ってしまう。
言ってしまうと日陰の技術になりつつあるガラケー開発だけど、華やかでないにせよ、それでもお仕事としてまだまだありますよね…という部分は間違いない。

新しい技術だけは技術では無いけれど、進化の速度が早い業界の中ではもう恐ろしいほど古い技術になってしまったんだなぁと思うと、不思議な気持ちになったりする。


WEBサイトでメールを送る機能を考えることはある。一言で「メールを送る」と言っても実は決めないといけないことは色々あるのでメモ。

メールのタイトル

いわずもがな。サイトで共通の先頭に定形の言葉を付ける場合など、事前に決めておいた方が良い。

メールの本文

サイトで共通の書式やフッターがあるのであればそれも早めに意識しておいた方が後々の修正作業の時に楽。

携帯キャリアに送信する場合、別の文面を送信する対応を考慮する必要がある。
最近はスマートフォンで受信するケースもあるものの、必ずそうだとは限らないので、その場合には内容を考慮しないとならない。
特に、本文中に携帯電話でアクセス出来ないURLを含む場合は不具合につながってしまう。

携帯専用の文面では、絵文字やデコメといった装飾方法を使う場合がある。
携帯電話ユーザーの割合などを考えるとそこまで頑張るのかどうか、という問題はあるものの、あるといえばある。

メールのFromのアドレスと名称

携帯電話に送信するケースには、着信拒否を解除してもらう旨をアナウンスする必要がある。

Fromのアドレスに返信があった場合も考慮を入れる必要がある。
返信されても対応出来ない旨のアナウンスがあったとしても、返信出来てしまうのがメールの仕組みであるし、アカウントを用意しないでuser unknownといったデフォルトの英文メールを返してしまうことで混乱を引き起こしてしまうのであれば、日本語の簡単な文面を返すようにしておいた方が無難。

Fromのアドレスと一緒に名称を入れるのかどうかも検討する。

メールのToのアドレスと名称

入力されたメールアドレスと名前の項目を使うのがよくあるケース。
同じ内容を管理用のアドレスに送信するといった運用が発生することもある。さらに異なる内容の本文を送信する場合もあり、そうなると送信処理は2つあるという風にした方が後々のメンテナンスでは楽。

添付ファイルありますか

添付ファイルを送る場合にはメールのサイズが多くなってしまうことで転送量が増えることを考慮する必要がある。
普通のメール送信の場合にはそこまででなくても、WEBサイトからの送信の場合には想像以上の送信件数になってしまう場合がある。

送信する時刻

ユーザー操作をトリガーで即送信する場合だけでない。
決まった時間であったり、操作から数時間後といったケースではその旨のアナウンスが必要であるし、深夜に送信する場合、送信先が携帯電話であるとクレームにつながることがあるので注意。

エラーメールの対応

メール送信先でuser unknownになって戻ってくるだけでなく、送信先ドメインが存在しなくてエラーになることもある。

文字コード

基本、日本人用のメール送信が前提であることが殆どだと思うが、対象が海外向けや特定の国内向けであることもある。その場合には文字コードをどうするかの確認は重要になる。UTF-8で済ませられるのかどうかは国によって異なるし、文字化けしていないのかどうかの確認体制から気にかける必要がある。