Font Awesome on WordPress

Font Awesome, the iconic font and CSS toolkit

  1. Open the Custom CSS page (Dashboard > Appearance > Edit CSS)
  2. Edit as the example below
    • Specify the content by Unicode to change a icon (the highlighted chars in the image)
@import  "https://maxcdn.bootstrapcdn.com/font-awesome/4.6.3/css/font-awesome.min.css";

/*
Welcome to Custom CSS!
To learn how this works, see http://wp.me/PEmnE-Bt
*/

.entry-content h3:before, .entry-content h4:before {
    font-family: FontAwesome;
    content: "\f0c8  ";
}

クレカを使わずに損しているのは誰か

日本の成人のうち半数以上がクレジットカードを利用したくないと考えている。そしてその理由は、思考停止と誤解にもとづいている。

昨夜、そんな報道を目にした。

内閣府は1日、クレジットカード利用に関する世論調査の結果を発表した。「クレジットカードを積極的に利用したいか」との質問に対し、「そう思わない」との回答は57・9%で、「そう思う」39・8%を大きく上回った。
朝日新聞デジタル

なお、内閣府の元資料は h28-credit.pdf から閲覧できる。

なぜクレカは日本で普及しないのか

資料によると、調査対象者がクレジットカードを利用しない理由は下記の通りだ。

  • 不便を感じない (55.4%)
  • 紛失・盗難により第三者に利用されるおそれがある (41.3%)

これらは誤解にもとづいているのだが、そのせいで日本の消費者は知らず知らずのうちに損してしまっている。

現金決済は不便である

クレカやICカード決済でわずらわされることはないはずの現金決済の不便な点をあげてみよう。

  • お釣りを渡すのに時間がかかる
  • お釣りは間違いが発生しうる
  • 銀行から引きおろさないと使えない
  • ログが残らないので家計簿をつけるか覚えておかないといけない
  • 落としたり盗まれると、戻ってくるように祈るしかない(後述)

ただ、「不便を感じない」とアンケートを答える人は本当に不便かどうかではなく「考えるのが面倒くさい」「使わないほうがいいと聞いた」「なんとなく不安」といった理由を持っているようにも読める。

クレカは現金よりも安心安全

まず、一般的なクレジットカードは紛失・盗難について現金よりも安心できる。次の通り整理してみた。

  • クレジットカード: 落とせばコールセンターに電話一本で利用停止、また、不正利用があっても返金措置がある
  • 現金: 運良く財布が戻ってくることを祈ることしかできない

犯罪者が現金を好むのはなぜか

ところで筆者は財布のスリにあった経験があるのだが、そこで起こったことは象徴的である。

犯罪者は現金だけ抜いて、財布やクレジットカードはその場に捨てていく。それはなぜか。現金はトレースが難しく、犯罪者にとって好都合だからである。

先日、日経に載っていた The Economist の記事によると、この犯罪者の特性は世界中で変わることはない。

前出のロゴフ氏は「イタリアやギリシャなどの国は統治能力が弱く、それゆえ脱税やその他の犯罪率が高い。これが高額の現金を保有する誘因となっている」と考えている。給与の一部を封筒に詰めて現金で支払う習慣の根は深いところにあるのだ。
日本経済新聞

日本のクレカ手数料は高いまま

実は現金の決済コストはクレカなどに比べて高い。

消費者は現金にはコストがかからないと思うかもしれないが、銀行や小売店にとってはそうではない。現金は数えたり、まとめたり、運んだりする必要がある。汚れを落とし、時には交換する必要がある。さらに、偽造がないか監視し、保管して、窃盗にも備えなければならない。国内総生産(GDP)の0.5~1%前後に当たる金額が現金の管理に毎年費やされているのだ。
日本経済新聞

事業者の都合なんて知ったこっちゃない?
しかしこの高コストな決済手段のつけは消費者に転嫁される。たとえ現金決済派であってもそのつけからは逃れられない。

クレカ普及しない
→クレカ会社のマージン比率下がらない
→クレカ利用者だけに負担させられない規約なので店は商品代金に上乗せる
→現金派も割高のマージンを間接的に支払う

日本のクレジットカード手数料は3%〜5%といわれているが、驚くべきことにEUはその10分の1以下だ。

国による差をなくすため、欧州連合(EU)の欧州委員会は2015年12月、カード決済の手数料に上限を設けた。デビットカード決済については0.2%、クレジットカード決済の 場合は0.3%だ。
日本経済新聞

日本の消費者は、この割高な手数料を支払続けることになる。
思考停止と誤解が私たち個人や日本社会にもたらしている損失は小さくないだろう。

保険商品の運営費20%弱から30%強って恐ろしいですね

インデックスファインド、特に確定拠出年金 (DC) 向けの商品だと投資信託報酬は0.2%代〜高くても0.4%代半ばくらいです。

投資信託のモーニングスター[ ファンド情報 ]

それなのに、生命保険の運営費は約20%弱〜30%強とのこと。むろん、半自動的に運営できるインデックスファンドとの単純な比較は難しいのですが、それほど手数料を払う価値があるかは考慮にいれておくべきです。

保険料から引かれる運営費の割合は、大半の商品で開示されていません。とても自慢できる水準ではないのでしょう。ライフネット生命は、商品別に保険料に見込みで含まれる保険会社の運営費の割合を開示していますが、おおむね20%弱から30%強といったところです。
東洋経済オンライン

これってライフネット生命は公開していてこの値段ですから、開示していない他社の商品は押して知るべしですよね。

保険料の内訳もすべて公開しています | 生命保険・医療保険のライフネット生命

この高い手数料をふまえても生命保険は必要でしょうか? 僕の答えは次の通りです。

  • 子供がいない場合: 不必要
  • 子供がいる場合: 必要
    • 収入保障保険
    • 逓減定期保険

子供ができた場合でも、いわゆる「三角の保険」を契約するつもりです。
でも、今は子供をもつ予定はないので心の準備だけして、深くは考えていません。

それではよい保険ライフを!

新卒エンジニアの転職

先週末 2016-08-26 がグリー株式会社での最終出社日でした。
あとで自分で見返したり、あわよくば誰かの参考にしてもらったりするために、思うところを書き起こしておきます。

私服の従業員のイラスト(男性) | かわいいフリー素材集 いらすとや

経歴

アルバイトのときから、ちょうど4年間ほどお世話になりました。その間、研修を除くと5つのチームを異動しました。

0. 入社まで

  • 志望動機は2点。この2つは今から見てもよい判断基準だったと思う。
    1. 創業者がエンジニアだったこと
    2. プラットフォーム事業を世界展開していたこと。ちなみに GREE Grobal Platform (GGP) と呼ばれていた。
  • 就活のイベントで @naoya さんと話す。
    • 当時勉強していた応用情報技術者試験を「やってもしょうがないよ」(意訳)と言われ衝撃を受ける。
    • 「外資系企業はHQと日本支社じゃ全然違うことが多いから気をつけて」(意訳)とアドバイスをもらった –のにもかかわらず、次の転職先は外資系の日本支社です
  • 世間は就活も本格的に始まっていない中、2月には内定をもらい「終活なう」ツイートを達成する — 当時は生前整理のことを指すとは知る由もなかった
  • 内定者期間のあいだにコンプガチャ問題がインターネットを騒がせる。このこともあり、現在に至るまで2013年が新卒採用の最盛期。
  • プログラミング歴は短め。業界には小学生のころから始めましたっていうひとも珍しくないなか、僕は大学生になって始めた遅めのスタート組です — 一般論としては早いにこしたことはないんでしょうが、はてブのホッテントリなんかを見ていると30歳ではじめているひとなんかも見かけるので僕の経歴も参考になるかと思います

1. 2012年5月〜 プラットフォーム部 (アルバイト; 8-9, 1-3月は勤務なし)

  • 最初期はコミット権がなかったためpatchを作って渡していた思い出。
  • Gitの操作に不慣れでわけがわからなくなったためGitHubでフォークしたレポジトリを消そうとして誤って本家レポジトリを消失させる。詳しくは下記。

2. 2013年4月〜 Bootcamp

  • 全体研修: 割愛。
  • エンジニア研修: 某動画サイトのクローンサービスを作成するなど。

3. 2013年6月〜 プラットフォーム部

  • 社外でも著名な方など、優秀なシニアのかたに設計やコードのレビューをしていただいて得難い経験ができた。まともにテストコードを書き始めた。思い出深いタスクが多い。
    • 2段階認証の導入: (僕の貢献は小さいが) チームとして全社MVPを獲得。
    • リスト攻撃の対応・対策: セキュリティに興味を抱くきっかけとなった。
    • GREEサービスへのIdPによるログインを導入: Facebook, Google+, Yahoo! Japanをサポート。オープンな仕様に則りつつ、1人で設計から実装までやったので勉強になった。

4. 2014年11月〜 Garage Studio

  • C++11 on Cocos2dx でタワーディフェンスゲームを制作する研修。
    • ゲームプログラミングの奥深さの一端に触れられた。
    • 経路探索はライブラリ使用が不可だったのでA*アルゴリズムを自前実装した。
    • 当時まだ不安定だったCocosStudioに頼ったことは反省している。

5. QAグループ (以降、カレンダーが閲覧できなくなったので異動時期不明)

  • 割りと自由にしていたが、ビジネス面での貢献度が低かったので反省している。
    • e2eテストを書いたり
    • Test導入の手伝いをしたり
    • テストライブラリを作成したり

6. Japan Game事業本部

  • Docomoのdゲームに内製ゲームを移植するプロジェクトにアサインされた。
    • コードベースはあったものの、モダンなPHPに移行したり、AWS使ったりなど、パイロットプロジェクトとしての側面もありliterally換骨奪胎だったので重めのタスクばかりだったがオンスケでリリース。
    • 運用に乗り出してからも、新機能を実装して本家へ逆輸入したり、自動化で運用の負担を減らしたり、わずかながら消費面でも貢献できたのが良かった。
    • ウェットな文化に馴染まなかったこともあり、タスクだけこなしていると「技術力はあるが、やる気のない人」として評価され気味だった。ただ、他の複数の事業から誘いをいただくなど、仕事ぶりを見てはもらっていたと思う。
    • 正直にいうとウェブゲーム開発に情熱を見いだせず苦しかった。主力事業が好きな分野であることは大切。

7. 投資インキュベーション事業本部

  • ARINE [アリネ] リリース。今から改善してサービスを伸ばしていくフェーズで抜けることになってしまい心苦しいところ。
    • 新卒研修ぶりにRailsを使用して馴染むわぁという感じ。プロダクトへのオーナーシップが強かったこともあり、コードを書く楽しさはグリーにいた4年間で1番大きかった。
    • 定例ミーティングなどを通して田中さんの考え方に多く触れられたのはとてもよい経験だった。

失敗談

FailConっぽい題材として僕の失敗談を掲載しておきます。

1. 非開発者のためのGitHubレポジトリを消すのがどれほどありえないことか解説

スクリーンショット中心に説明してみますと、まずですね…

Danger Zone - github.com

こんな危なそうなページの、危なそうなボタンを押して、

Are you ABSOLUTELY sure? - github.com

「君、ほんっとーに消したいんだよね?」とか聞かれるのもものともせず、フォームにレポジトリ名を入力して、さらに「私はこの操作がもたらす結果を理解しているのでリポジトリを削除してください」と半ば脅しをきかせているボタンを押して、はじめてレポジトリを消せるんですよ。「やり直せないよ、これ」って言われてるのに。

これをやっちゃう人っているんですね? はい、僕です。

「アルバイトのエンジニアがレポジトリを消したらしいぞ」と聞いた諸先輩方は、きっとstupid userのミームを思い浮かべたことでしょう。

Stupid user meme

むろん、こういう権限を絞る機能は GitHub Enterprize (GHE) にもあるのですが、まさかこんな底なしの阿呆がおろうことかと当時は設定されていませんでした。
※このエントリをご覧の方で心当たりのある方がいらっしゃいましたら、今すぐ権限制御することをおすすめいたします。

なぜこんなことをやったかというと、僕の場合、当時はremoteが2つ以上あるレポジトリを経験したことがなかったのでrebaseでコンフリクトなどが起きてどうしようもなくなって自分でforkしたレポジトリを消すことに麻痺するようになっていたのだと記憶しています。

幸い、プロダクションなどへの影響はなく、消し去られたソースコードも分散型バージョン管理システムの恩恵をこうむり事なきをえましたが、ありえない失態として今でもいじられます。

素晴らしいアーキテクチャをありがとう、リーナス。

やってよかったこと・これからも続けたいこと

1. 技術書を読む

  • 読書は、水泳の「息継ぎ」のようなものです。継続的に息継ぎしないと長距離を泳ぐことはできません。
    • 情報技術の基礎を修めたひとですら日々勉強しているなか、いわんや独学者をや。※特に良かった本は後述しています。
    • 技術書に限らず、読書は良質なインプットです。まさに “Garbage In, Garbage Out” といえますが、よい仕事をするのに良質なインプットは欠かせません。
    • 読書のインプット効率は大変によく、大抵の本は著者と10回飲みに行っても足りない内容が書かれていますし、あわよくば著者とともに1つのプロジェクトを完遂したとしても得難い内容が書かれています。

2. プライベートで業務と違うことをしてみる

  • 新しい技術を試す、ライブラリ開発、iOS/Androidアプリ開発、ウェブサービス開発、各種コンテストなど。
    • 仲間内・あるいは自分用の organization を作成してみるのもよいでしょう。僕は最近ボッチ organization announce をつくりました。
    • 新しい言語に馴染むためにProject Eulerを解く人がいますが、それに類する方法としてライブラリを作成してみるのも1つの手です。細かく切りだされたコード片だと見通しも効きやすく、要件を実現するために必然的に他の良質なプロジェクトのコードを読むことになるので勝手に手元にベストプラクティスがたまっていきます。
    • 業務で利用しているOSSへコミットする心理的障壁も下がります。
    • 誰しも新しい技術を試したいものです。業務でみさかいなく導入するひとは迷惑ですが、勝手によそでやる分には誰からも文句を言われません。そのうち加減も分かってくるものではないでしょうか。
  • アウトプットで成果を出すのがビジネスパーソンの役割です。ソフトウェア開発者の場合、こんなに魅力的な練習場がころがっているのですから、利用しない手はありません。

3. 大学院に通う

  • 僕は品川にあるJAISTの社会人コースに通い始めました。週末は授業でなくなりしんどいですが、仕事をするわけではないのでリフレッシュにはなります。
  • 学業は良質なインプット。仕事とのバランスをとっていれば相互によいフィードバックとなります。
    • 実務経験は研究にも活きると実感しています。というのもACM CCS 2015の論文で git のメタデータを訓練データとして用いたアプローチがあったのですが、ずっと学術畑にいるとにピンと来なかったりするのではないでしょうか。僕が git について語るのは皮肉ですが。

読んでよかった技術書10選

良書といっても限りがないので、特定のプログラミング言語やミドルウェアに依存しないWeb系の本をあげておきます。

  1. 徳丸本
    • セキュリティとは、プロとアマで最も違いがでる分野ではないか。いわゆる「非機能要件」なので明示されないことも多いが、安心してユーザーに使ってもらうためには欠かせない。社内の「後輩新卒エンジニアにおすすめする本は?」という企画でも推薦した。
    • セキュリティ関連の本では『Hacking:美しき策謀』も大変な良書。”Hacker’s delight”を体験できるので興奮しながら読めるが、メモリモデルやネットワークプログラミングなどコンピュータサイエンスの入門書としても活用できる1冊となっている。
  2. コードコンプリート
    • 新卒時に社内の勉強会で読んだ本。複数人開発をするための導入用にかかれており、まさに新人にうってつけの内容だった。
    • 輪読しているときは「そんなことわかってるよー!」と思う箇所も多かった覚えはあるが、それほど網羅的に書かれているということだ。
  3. リーダブルコード
    • 多くの先輩エンジニアが「あー、これ新人には読んでおいてほしいわ」とつぶやいているのを見かけ、焦って読んだ覚えがある。膨大なコードを読んで分かってくる勘所を程よく1冊にまとめたことが評価されている理由だろう。
    • ソフトウェア開発業では「名付け」が大切な仕事の1つだが、本書は filter と書くよりも extract と書いたほうが意味が誤解されにくいなど具体例まで載っているので新人でも理解できた。名付けはより良いソフトウェアを書くためだけならず、マーケティング面でも重要である。— cf. 名前重要 by Matz
  4. Webを支える技術
    • Webとは何か。どんな技術要素がwebをwebたらしめているのか。
    • Web = REST = ULCODC$SS (Uniform Layered Code on Demand Client Cache Stateless Server) とブレイクダウンしていく。
    • 筋のいいURLは実装依存でなくリソースをあらわす名詞になっている、など。
  5. ふつりな
    • OSの提供するAPIやストリームの概念、パイプとフィルタのパターンなど。
    • 著者の美意識がほとばしる淡泊だが硬派で渋い文章。憧れる。
  6. SQLアンチパターン
    • 特定のRDBMSに依存しないアンチパターン集で、組織内の共通言語づくりができる。データベース設計が糞だと他が芋づる式に崩壊していくのでアプリケーションの根幹をなす。
    • 正規化などは知っている前提なので類書を当たるとよい。
    • O’Reilly JapanからDRMフリー版が購入可。
  7. テストから見えてくるグーグルのソフトウェア開発
    • 原題は “How Google tests Software” だけど、邦題のほうが本書の趣旨に沿っている。
    • 自動化などを「どこまでやるべきか」迷っている人は必見。むろんケースごとの規模でペイするかは変わってくるが、「ここまでやっている」事例を知っておけば自分のなかで判断軸をもてる。
  8. パタヘネ本
    • 授業の教科書として使用した。
    • 読み終えると「MIPSはいいぞ」ってなる。rebuild.fmなどでもよく言及される。
  9. ジョエル本
    • 著名なオピニオンリーダーの本。
    • 何が書いてあったかは忘れたが、かなりよかったという記憶の残滓だけはあるので入れてみた。
  10. 実践 機械学習システム
    • 動物本から唯一のランクイン。個人的には意外と動物本に「これぞ」というものは多くない。特に入門書は当たりが少ない印象。
    • Machine learningは流行しているが、本書は書名に偽りなく「実践」できる内容が詰まっている。研究ですぐに役だったが、それだけにここにあげた他の本に比べると廃れやすいかも。
    • DRMフリーはO’Reilly Japanからどうぞ。

総括

グリーのような優秀で真面目な人が多い職場で一緒に働けてとても感謝しています。おかげさまでまだまだ三流ではありますが、プロフェッショナルな開発者の第一歩をふみだせました。

タイトルの転職についてですが、志望動機にも記した通り、広く世界に通用するプロダクトに携わっていくという軸は変えずに新しい環境で挑戦します。

付記

「エンジニア」について

  • 本エントリはソフトウェア開発者を広く「エンジニア」と呼称する慣習に則りました。実際名刺のタイトルも「エンジニア / Engineer」でした。ただ、タイトルについては業務の実態はともかく、ビジネス上必要であればソフトウェアのみならずハードウェアもハックせよとの意図が込められているかもしれないです。

ウィッシュリスト

『21世紀の資本』で日本があまり「触れられていない」理由

『21世紀の資本』訳者解説――ピケティは何を語っているのか / 山形浩生×飯田泰之 | SYNODOS -シノドス-

上掲の記事中に「『21世紀の資本』では、日本のことにほとんど触れられていません」との指摘がある。

wc_countriesRef. Textual analysis on “Capital in the Twenty-First Century” – It works!

この点について客観的に述べるためにスクリプトで数え上げてみたのだが、『21世紀の資本』がよく言及するのはフランス、アメリカ、イギリスであり、そこから離れてドイツ、日本と続く。

つまり、日本は5番目に多く文中で言及されていたわけだが、これを多いとするか少ないとするかは読者の捉え方次第である。「GDP大国なのだから本来ならばもっと触れられてよいはず」と考えるひとにとって物足りない言及回数であろう。

同書を未読である人のために補足すると、同書は18世紀からのデータを扱っており(それがピケティの仕事が評価される一つの大きな理由でもある)、長い期間を扱っているためイギリスやフランスといった旧帝国主義国の登場が多い。

ピケティ博士の出身国であり有力な帝国であったフランス、次いで2度の世界大戦を経て巨大国家へと成り上がったアメリカ。3番目にはフランスをしのぐ国勢を誇った大英帝国時代を背景とするイギリス、そして4番目にEU最大の経済規模を誇るドイツ。日本は、これらの4カ国に次いで日本への言及数が多かったのである(今回は単純なワードの数え上げだったためドイツを下回ったが、文意としては私は日本はドイツよりは多く触れられていたような印象を受けた)。

むろん、記事中で飯田氏が紹介している「日本型の格差」も興味深いことには違いないが、例えその点に本文中で触れたとしても「世界で最も平等である日本やベルギーですらも、トップ10%あるいはトップ1%への資本の集中の範囲外ではない」という文脈にすぎないのだから、記事中の反応は日本人として寂しいという意見にすぎない。

つまり、わざわざ日本が触れられていないのは、ユーロ圏やアメリカから得られた結論からは大きく外れず、それらの理論が援用できるからに他ならない。

「日本特殊論」には逃げられず、あくまで世界の趨勢に正面から向き合っていかなくてはならないのである。

21世紀の資本

Textual analysis on “Capital in the Twenty-First Century”

The 16 words used 500+ times

Here is the most frequent words in “Capital in the Twenty-First Century”*1.
A chart of most frequent words in "Capital in the Twenty-First Century"

Word Times
capital 2366
income 2156
percent 1935
wealth 1508
national 908
countries 883
tax 870
century 786
rate 741
growth 728
inequality 666
france 624
top 579
world 549
states 542
united 500

Count of countries and regions

Word count by countries and regions
Ref. wc_countries

Count of years, decades and centuries

Word Times
2010 384
nineteenth 317
twentieth 262
2012 141
1910 136
eighteenth 137
1950 132
1970 128
1980 112
1914 109
1945 104
1970s 88
1980s 86
2013 82
1990 81
1913 75
2000 75
1900 69
1820 58
1870 52
cat var/wc.csv | awk -F',' '{if ($1 ~ /1[8-9][0-9][0-9]|20[0-9][0-9]|nineteenth|twentieth|eighteenth/) print $1","$2}'

General aggregation

Number
Total words 258837
Unique words 10468

Sources

Footnote

  1. Precisely, the list doesn’t contain stop words. In this research, I referred MySQL 5.5 Full-Text Stopwords to extract words.

『21世紀の資本』を読んだあとにオススメな本ってあるのかしら

『21世紀の資本』訳者解説――ピケティは何を語っているのか / 山形浩生×飯田泰之 | SYNODOS -シノドス-

『21世紀の資本』の読後に気になってくるのは、資本の集中に対するアプローチってどんなものがあるんだろうという話である。その答えは、ちょうど上掲の記事の後半に触れられているが、もう少しこれを掘り下げた本が読んでみたい。

  • グローバル累進課税
  • 固定資産税
  • 相続税
  • 累進所得税

といった各種税がもつ社会的な意味が知りたい。そんなに技術的に突っ込んだ話はいらないから、「租税論」の範疇に入るんだろうか。例えばベーシックインカムと相性のいい租税とか、どう組み合わせて運用するのがいいのかとかは、捕捉率などの細かな運用面の話に終始してしまっておもしろくないんだろうか。

せっかくピケティが「グローバル累進課税」という議論のたたき台を用意したのだから、それへのアンサーがあっても良さそうなものだが。

また、上に引用した千葉市長の言葉が、為政者が代弁するトップ1%都合に過ぎないのか、はたまた市民の益となる見解なのか、僕には検討がつかない。ということで、この辺りの事情を勘案して判断できるようでいたいと考えている。

21世紀の資本

プログラミング授業の教育体制

newspicks.com: 文科省有識者会議、小学校のプログラミング教育案を大筋了承

プログラマとして仕事している立場から見ると、優秀なプログラマにもソフトウェア開発するだけじゃなくて、教えるほうが好きな人も山ほどいるので人材の供給には不足することはないと思います。問題はそれを教育の現場にどう繋げるかですが、UdacityなどのMOOCは大いに参考になりますね。

ただ、一部の小学生にはUdacityのような完全オンラインもまだ早いでしょうから、プログラミング教育は、オンラインを主として、現場の補助員を従とする体制が向いていると思います。

僕らのころの小学生時代はゆとり教育が始まったころでしたが、毎日とても楽しかった思い出しかないです。でも、これからの世代はマインクラフトでプログラミングの授業をやったりボカロで音楽の授業をやったりペンタブで図工の授業をやったり、できるんでしょうね。もっと楽しそうだし、そうなるよう応援していきたいです。

望むべくは教育業界にはやりがい搾取のきらいがあるので優秀な教え手には正当な報酬が支払われてほしいですが、個の時代ですから自然とスポットがあたるはずでそんなに心配もしていません。

エアコンがクールでない問題

クールなエアコンがほしいです。クールなエアコンがどういうものか書いてみます。

まず、クールなエアコンにリモコンはありません

僕が温度を気にかける必要はなく、全自動で快適な温度になります。

暑いときは「暑い」と言うと、それで調整してくれます。

部屋にいる人のことは覚えます。部屋に複数人いるときは、暑がりの人が涼しくなるようにしてくれます。

クールなエアコンには、タイマーも、電源もありません

24時間付けっぱにしたほうが電気代が安くあがるのは本当かどうか。そんなことは人間が考えなくて済みます。

エアコンがコストも考慮して運転します。室温などのデータは集計サーバへ送られ、外気温や室温を考慮して統計的に最適な管理をしてくれるのです。

ルンバも真っ青なクールなエアコンの発売を心待ちにしております。