  |
はてなキーワード: インタフェースとは
例えばツイッターでもなんでもいい、ウェブサイトやアプリのデザインが急に変化して、「なんで変わったの？」「これ意味ある？」「前のほうが使いやすかった」と思ったことは無いだろうか。
増田の老人達なら昔mixiがデザインを一新した際に改悪反対署名運動などが起こったのを覚えているかもしれない。ユーザーは使い慣れたものが急に変わったらまず拒否反応から入るのが普通なのだ。
ではなんでこんなことが起こるか。それはデザイナーを社内に雇っているからである。
多くのエンジニアはビジュアルデザインが得意でないから、サービス実装初期はデザイナーの手助けが必要である。しかし一度リリースしたサービスは大体基本のデザインの流用で別のページを作れるし、デザイナーの助けなんていらなくなる。そうなった時、社内で時間を持て余したデザイナーは何をするか。
ウェブページは「ユーザーインタフェース」であって、デザイナーのファッションショーの場じゃない。使い慣れた70点のUIを新しい80点のUIにされても多くのユーザーは喜ぶどころか拒否反応を示すのだ。
点が上がればまだよくて、UIになんら寄与しない「流行りのマテリアルデザインにしました」だけの70点→70点のデザイン更新がされる事すらある。この場合旧デザインに慣れたユーザーから見たら新しい70点は70点未満に映るだろう。
以前大流行したフラットデザインが本当にユーザーを満足させたか？マテリアルデザインはどうか？
ファッションの世界でも定期的に○○年代リバイバルなどが起こるように、デザインなんてものは「飽きたから変える」とか「目新しいかどうか」といった程度の存在で、新しい流行が本質的に良いものかどうかなんて実際は殆ど関係ないのだ。新しいビジュアルが本質的メリットを持っているならリバイバルなんて起こるわけがない。
だが自分達の仕事を増やしたいデザイナー達は「このスタイルはもう古い、流行じゃない」みたいな空気を出して流行に乗らないことへの罪悪感を広め、結果ユーザーにはどうでもいいデザイン変更が実施されるのだ。
なので無意味なデザイン更新をしてユーザーの機嫌を損ねたくなかったら、デザイナーは社内で飼わずに外注して実装が終わったら放逐したほうがいい。
銀行系のアプリが使いにくくて、驚いたが、一番面白いのは、銀行系のアプリについての罵倒、批判、改善要求のコメント。そこで、この場を借りて紹介してみよう
＜千葉銀行＞
・これは、すごい。このアプリを作った会社も天災だが、このアプリを採用した千葉銀行も天災だ。千葉銀行を使っている自分がホコリに思える。もしかして、ショートカット作成にAIでも導入されているのか、ブラウザを開いているような新技術が使われているのか、絶妙すぎで凄すぎる。流石に儲かっている銀行の提供するアプリだけあってユーザービリティも再考。
・バカが作ると出来上がるアプリの良い見本、本社のセキュリティが甘いため、アクセスのために様々な煩わしさをユーザーに強いる。 何が悲しくてパスワード以外に３つもキーワードを入力させるのか？ この仕様の提案とOKを出している連中は人々に迷惑しかかけられない能無しなので全員廃業しろっての
・使えなすぎ。 ただのショートカットアプリ。ワンタイムパスワードが夏から必須になるけど、アプリで使えるようにして。トークンなんて不便すぎ。技術低すぎ。解約したい
＜新生銀行＞
・最悪すぎる。 スマホ認証で、キー発行アプリを参照すれば、当アプリがバックグラウンドになり、最初の画面からやり直し。 認証出来るわけない！嫌がらせか！！ そもそも、バックグラウンドに行ったらログインし直しじゃ、、メールで振込先口座見ながらとか全く無理。 設計ミス。使い手のイメージ出来てない証拠。利用者視点のテストを考えてない証拠。いろいろ怪しくなってくる。 今後が不安なため、メインバンク変更決めました
・銀行アプリは多く使っておりますが、こんなに使えないものをよく世に放出出来ましたね。何をするもにも再ログイン、しかも口座番号を覚えてくれる機能もないので支店番号暗証番号ダイレクトパスワード全て1から入力。時代は移りゆくものですが、ネット銀行員の知能の低さすら垣間見えます。アプリ操作方法に関して問い合せても｢アプリというかブラウザの○○をご覧下さい｣。アプリについて尋ねたのですが。蛇足ですが。全額出金します
・素人が作って素人が承認した未完成アプリです。 フリーズが頻繁に発生し、まともに進むことができません。 また無駄にセキュリティチェックが多く、ログインしても振込時に、いちいちセキュリティカードの記号を入れようとさせます。自分で作ったアプリに自信がないからそうするのでしょうが、利用者からすると迷惑です。 だったらアプリじたい提供しないでほしい
＜みずほ銀行＞
・メチャメチャレスポンスが悪い。普通にブラウザからアクセスしたらサクサクなので、ネットワークの問題ではない。即アンインストール
・どうして更新する度にお客様番号が消えるのか。 とても面倒で煩わしいです。 基本重いです。 正しいパスワード入力しても入れない時もある。 時間置くと入れるけど、時間かかるので面倒です。 他銀行はサクサク行くんですけどね… 銀行行った方が早いって思ってしまうので、何のためのスマホバンキングなんだろうって感じです。 それでも使う時もあるので、頑張って欲しいです
・くそアプリ。 アプリは削除してワンタイムパスワードカードに移行します。不便だけどアプリよりは多分マシ
＜三菱UFJ銀行＞
・スマホ変えたらまた再登録でワンタイムパスワードがどうたらこうたらでよく分からん。登録画面が複雑怪奇過ぎて…、これ１人で出来る１人何割くらいいるの？
・メニュー画面を 開くための左下の表示がわかりにくすぎ。最低ランクのユーザーインタフェースと言わざるを得ない
・なんで銀行アプリで広告があるんだよ、あほか あと画面勝手に横にすんな使いにくすぎ。正直★1やるのも惜しいくらいのクソアプリ。やっぱりufjはゴミだな
現在、有料の「学びエイド」、無料の「Web玉塾」、無料の「Ｍａｎａｖｉｅ」家庭教師のトライがやっている無料の「Try it」、この4種の動画講義を主に利用している。
この4種の中で、学校の授業に1番近い作り方をしているのは、「Try it」である。最初に過去の講義の振り返り、今回のポイント、練習問題、振り返りと続く。1本の講義時間は10分から30分までである。
動画講義の中で1番短いのは、Web玉塾、学びエイドである。両者の動画講義は基本10分程度に長さを抑えてある。ポイントは1動画に1つから2つ。1度学校の授業を受けてから見る動画という印象だ。Web玉塾は、古くからある動画講義で、早口でコンパクトにまとめてある。学びエイドにある講義もWeb玉塾と同様の傾向がある。
Ｍａｎａｖｉｅは、授業に似た講義（Mundi先生の世界史、日本史、地理（途中））や学びエイド的な講義（とらますく先生の生物）、Web玉塾など、ネット上の無料動画講義をキュレーションしたサービスである。ユーザーインタフェースも整ってきている。
現在、私は理科高校教員として働いている。Ｍａｎａｖｉｅ、Web玉塾の生物動画講義を生徒に進めてみたが、どうも評判が良くない。なぜか考えていたところ、とらますく先生のブログの下記ページからヒントを得た。
http://genuinestudy.seesaa.net/article/456325367.html
上記リンクを読み、私が出した結論は、Web玉塾、Ｍａｎａｖｉｅの生物動画講義は、高校の生徒にとり早すぎるということだった。
この発見から、次は家庭教師のトライの「try it」の生物講義を進めてみようと考えている。生物を一度学んだものにとっては、「try it」の講義は遅すぎる。しかし、私の仮説が正しければ、高校生には講義スピードの遅い「try it」は受け入れられるかもしれない。
動画講義を作る人は、塾の先生や教育に燃えたボランティアが多い。そのため、動画をなるべくコンパクトにし、勉強の時間対効率を高めるよう作られていると私には感じられる。
しかし、多くの講義動画をみて私が感じたのは、長い動画にも見やすいものがあるということだ。特に、ＭａｎａｖｉｅのMundi先生の動画は、世界史や日本史に対する、Mundi先生の愛情が溢れている。このため、長くても見れる。
「try it」を見ていると、多少時間が長くてもゆっくり（20から30分程度）1つの事柄を説明しているため、授業作りのヒントが得られることも多い。長い（20から30分程度）の講義動画の需要もあると感じた。
脱獄済みiOS9 をずっと使っていたのだが、iOS10以降じゃないと対応していないアプリがあったり、
Suica使いたかったりしたのでiPhone Xに変更した。
FaceIDは初代TouchID並には便利だが最新TouchIDと比べると正しく認識されないことも多く不便だなと感じたが、
それは想定内なので良い。
大画面化しているのにフォルダ開いたときのアイコン数が3×3だったり、脱獄アプリパクリの複数アイコン移動のインタフェースがゴミだったり、
未だに柔軟に設定できないActivatorもどきだったり (上からのSwipeはNotificationとContorolCenterで左右違うのに、下からのSwipeを左右分けられていないのは何故!?)
細かなところではあるんだけど何かがっかりだった。
スライド表示が嫌い。SlideShare とか SpeakerDeck とか。
全画面と「次のページ」「戻る」しかないインタフェースがつらい。
流し読みできないし
スライドを一枚ずつめくらないといけないインタフェースがうざすぎる。
発表資料をアップロードしてくれるのはありがたいし、発表者がそのままアップロードするだけの手軽さは賞賛されるべきだが
スライド表示モードは発表者という特殊な立場の人のためだけに必要な特殊なモードであって
特別なボタンを押したら、スライドモードになる くらいでちょうどいい
SlideShareとか昔はスマホで見ると縦スクロールできたのに、わざわざスライドモードを実装して何考えてるのって感じ…
googleマップの画像一覧とかも一覧モードにならなくてつらい
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
要はソニーなりの大企業になると大きな仕事をしなくてはならなくて、職人がひとりでできるひとり分の仕事をしていては回らないわけで。
日本の企業は、昔から製造工場のライン工のメタファーで極力プログラミングを単純作業に落とし込んで、多くの低スキルプログラマーによりスケールする道を選んだ。
一方アメリカをはじめ諸外国は、ある時期からプログラミングに科学、つまりコンピュータサイエンスと数学を持ち込んでスケールさせようとした。
（コンピュータ自体は最初から科学の産物だけど、それをビジネスに展開するときの話ね）
だから日本でのプログラマーの地位は海外に比べて低く、早くマネージメントに上がれといわれ続ける。
日本企業の誤算は、ソフトウェアの進化がハードウェアの進化よりもずっとずっと誰も予想がつかないほど速く、ドラスティックだったことで。
さらに世の中が急速に進化して、サービスの時代になるとフィジカルインタフェース以外は全部ソフトウェアという製品も出てきた。
もはやこうなると多数のライン工プログラマーを抱えたハード屋という構図では圧倒的なアウェイでしかない。
もし大企業が本気で変わる気があるなら、製造工場の考えを全部捨ててゲーム制作プロジェクト、それもAAAタイトルの巨大なプロジェクトのスタイルを他のビジネスにも取り入れるのが良いと思っている。
ベテランプログラマーがひとり分だけの職人仕事をするのは大企業では難しい。でもその才能を生かしたまま映画監督のように大きなプロジェクトチームを率いることはできるはずで、たぶんソニーはそういうことのできる会社だったはずで。
元増田です。
AppleWatchについて購入日以来モヤモヤしていたものがやっと言語化できましたのでここにまとめてみます。
どうせ長ったらしくなるので、まとめは次のようになります
とにかくこれに尽きます。もう少し詳しく言うと次の2点に集約されます。
1. 両手が必要
1.については議論の必要はないと思います(Hey Siri除く)。
2.については時計を見るポーズをとってください。そして、そのポーズをキープしてみてください。
おそらく、5秒くらいで面倒くさくなってきたのではないでしょうか。
はっきりいって、操作の楽さ加減ならば、脇をしめて操作できるiPodやAppleRemoteのほうが優秀でしょう。
残りの4割のうち3割はアクティビティです。1割はMacの自動解除とHey Siriのカップラーメン機能です。
AppleWatchリリース以来、色んなアプリがリリースされましたが、ほとんど使用されていません。ヒット作についても私は聞いたことがありません。
なぜか？
本当に操作が面倒なんです。アプリケーションを呼び出すボタンを押して、アプリを選ぶだけで2〜3秒かかります。それから小さい画面に向かってあれこれするわけですが、これならiPhoneを取り出した方が早いんです。
結果、AppleWatchで常時見ているのは文字盤と通知だけです。私が普段使っているアプリもIFTTTとStressDiary、呼吸だけです。
コンプリケーションと通知に表示される情報がAppleWatchのコア機能といってもいいでしょう。
AppleWatch発表時、リュウズが革命的なインタフェースだと喧伝されました。そのことは間違いないでしょう。
しかし、この、リュウズをどう使うかについてしっかり検討されたとは思えないのです。
リュウズに対応したアプリでは、リュウズの回転に応じてスクロールされます。そして、目的のものが表示されました、そして、リュウズを押したとしましょう。どうなるか？アプリ一覧画面に戻ってしまうのです。
AppleWatchでは、アプリ上でなにかの操作について決定をする場合、画面を押す必要があります。ちゃんと押せたかどうかわからないのにもかかわらず。
確かに、AppleWatchにはボタンが足りていません。ですが、せっかくのリュウズについてアプリ一覧に移ってしまうのは失敗だと言わざるを得ません。
結局のところ、AppleWatchはアプリの操作性が悪すぎるのです。iPodも色んな機能がありますが、持ちやすく、片手で操作できるため、シンプルですが多少複雑な機能を使いこなすことができます。
次期AppleWatchでは、下のボタンを二つに割り、ボタンを増やし、リュウズはアプリに渡すようにしてほしいと思います。
http://www.itmedia.co.jp/news/articles/1304/17/news126.html
訴訟は2009年9月、DeNAがモバゲータウン（現Mobage）で配信していた「釣りゲータウン2」が、グリーの「釣り★スタ」に似ているとして、グリーがDeNAと開発元のORSOに対し配信差し止めと損害賠償を求めて提訴していた。
一審・東京地裁判決はDeNAによる著作権侵害を認め、著作権法と不正競争防止法に基づきDeNAに対し約2億3000万円の損害賠償の支払いと「釣りゲータウン2」の配信差し止めを命じた。二審・知財高裁判決では、両社の釣りゲームに共通するユーザーインタフェース（UI）などについて、著作権法で保護されない「アイデア」や、釣りゲームならではの「ありふれた表現」だと指摘。具体的な表現が異なっており、DeNA作品からグリー作品の表現上の本質的な特徴を直接感得することはできないとして、著作権の侵害を認めず、グリーの主張を退けていた。
https://opensource.srad.jp/story/12/01/25/0741213/
ソーシャルゲーム開発大手DeNAがHTML5開発支援フレームワーク「Arctic.js」を公開したのだが、そのライセンスを巡って一悶着が発生した。
当初ライセンスには『「Mobageオープンプラットフォーム」以外において営利目的で使用・複製などする際は、書面による使用許諾が必要になります』と記載されており、Open Source Initiative（OSI）によるオープンソースの定義と矛盾していた。しかし、DeNA側はこれを「オープンソース」と呼んだために非難が集中。その後DeNAはこの独自ライセンスを撤回、ライセンスをMIT Licenseに変更した。
http://www.yomiuri.co.jp/science/feature/CO017291/20161201-OYT8T50043.html
大手ＩＴ企業ディー・エヌ・エー（ＤｅＮＡ）が、運営する１０のキュレーションサイトのうち９サイトのサービスを停止した。きっかけとなったのは、このうちの一つ、医療系まとめサイト「ＷＥＬＱ（ウェルク）」で、科学的根拠に欠ける記事や無断転用が次々と発覚したことだった。(略)
---
他にも何か事例あったら指摘ください。
会社名を明かせないが、業界大手のベンチャーキャピタルに所属している。
主な出資先は所謂ミドル、レイターと呼ばれる「成長、拡大期」のベンチャーである。
さて、そんな私も最近は起業前、もしくは新規事業を立ち上げようとしている方にアドバイスをすることが多い。
そしてその中でもここ1ヶ月は会う人の3割がチャットボット系のサービスのアイデアを語るのである。
「やめたほうが良い」と毎回アドバイスするのだが、毎回伝える3つの点についてここに記したい。
願わくばこの記事が広まり、浅はかな「対話型サービスの未来」を考えているベンチャーが断念し、より可能性の高いビジネスに切り替えて欲しい。
そしてこの記事を受けても尚、私の予測を上回り成功するチャットボットサービスが出てきてほしいとも思う。
前置きが長くなったが、以下3点がチャットボットが失敗する理由である。
一番の理由がこれだ。
ここで注意したいのが、 クライアント ではなく ユーザーである点だ。
よくある「チャットボットを簡単にECサイトに導入できます」サービスを事例に出してみよう。
「今まで大変だった顧客対応がチャットボットで代替できます。」
「チャットボットが商品のアピールをすることで売上が上がります。」
確かに正論に聞こえるし、無料キャンペーンや優先登録などに興味を示すクライアントは多いだろう。
プレスリリースを出せばクライアントの問い合わせは殺到するだろう。
ユーザーは商品についてわからないことがあった際に、いきなり得体の知れない自動応答システムに話しかけるだろうか？
そもそも埋込み型の顧客問い合わせサービス（zopimやolarkなど）について、ユーザーの利用率が5%未満に過ぎない事例が多いことを知っているだろうか？
私もこれらの問い合わせサービスに関わったことがあるが、日本人の性質としてチャットボットにいきなり話しかける（しかも想定された問答を想定通りの言い回しで）例は少ない。
また、少ない額であれば導入する事例も増えるだろう。
しかし、ユーザーがチャットボットを使うシーンは少ないだろうし、結果として売上にもコストダウンにも繋がらないケースがほとんどだろう。
厳しい言い方をすると、話を聞くチャットボット関連サービスは現状、 「ユーザーのことを考えず提供者側の視点しかない マスターベーショナリサービス」
なのである。
自然言語処理を簡単に説明すると、「コンピュータが会話を理解し適切な回答を返す処理」である。
この技術は現状、正直言ってそこまで高いレベルに達していない。
言い換えるならば「ユーザーの期待値」と「提供できる技術レベル」の均衡が取れていない。それどころかユーザーの求める「自然な対話」レベルにはほど遠く失望させるものなのである。
よく非技術者の創業者や流行りものが大好きなコンサルが「Deep Learningの登場で自然言語処理の精度が高まり自然な対話を実現できる」とドヤ顔で語るのだが、これは大きな勘違いだ。
画像認識については、「文脈」などその対象以外の外部要因が発生することは少ない。
その為、その特徴量を見出しやすくDeep Learningを使用することで精度をかなり高めることが可能である。
しかし、「対象そのもの」以外にも文脈や発する人間のパーソナリティなど様々な外部要因が発生する対話において、特徴量は見出しづらい。
特に日本語は主語が省略される、漢字の読み方で大きく意味が異なる、「空気」を重視する等のハイコンテクスト文化であり、自然言語処理は難しい。
その為にDeep Learningが自然言語処理を圧倒的に成長させ、「機械であることを感じさせない自然な応答」を可能にさせることはほぼ不可能なのである。
そんな精度をユーザーが求めていないのでは？と思うのは提供者側のエゴだ。
不自然な対話、自分の想定していない回答が続くようであればユーザーはサービスから離れてしまうだろう。
「飲食店などの予約がチャットボットでできる」系サービスも良く聞く。
彼らには必ず「それってチャットボットである必要性ってあるんでしたっけ？」と質問するのだが、納得のいく回答を得られたことは無い。
対話のほうがかっこ良い、対話でできたら未来っぽい、アメリカで流行っているから、実際にそんな浅はかな考えで通用するほどビジネスは甘くない。
「対話によりニーズを深掘りできる」等もよく聞くが、2で挙げた通りそんなに自然言語処理の精度は高くなく、深掘りする以前に離脱してしまうだろう。
「なぜ対話なのか」
これらの質問に自信を持って答えられるだろうか。
それができない限りはビジネスは成立しない。
今すぐチャットボット事業を畳み、↑の質問に答えられる別の何かの可能性を考えたほうが良い。
以上である。
チャットボットブームは、クライアントが導入した後に「ユーザーに全く使われない」と気づきその悪評が広まる、あと半年の寿命といったところだろう。
そんなチャットボットだが、現状で可能性があるとしたら「チャネルの1つ」として使う程度だろう。
LineやFacebookメッセンジャーに組み込み、「既に展開しているサービスの広報的役割として活用する」、「メディアの記事を配信させる」役割であれば優秀なツールとなるだろう。
繰り返しとなるが最後にもう一度。
願わくばこの記事が広まり、浅はかな「対話型サービスの未来」を断念し、より可能性の高いビジネスに切り替えて欲しい。
そしてこの記事を受けても尚、私の予測を上回り成功するチャットボットサービスが出てきてほしいとも思う。
＞BtoBでの事例
導入事例のステマ記事（メディアとクライアントと内容は詰めている）はこの半年で沢山出てくると思いますが、実際の導入でコストが下がった、売上に繋がったという話は決して多く出ないだろう（むしろネガティブな話ばかりだろう）と私は予測します。
＞「二次元アイドルとの会話」みたいな路線なら弾けるとこあると思うよ
これは私もそう思います。ただそのサービスだけでのマネタイズは難しく、記載した通り「チャネルの１つ」としての活用だと思います。
＞いま成功している企業に対して、過去の時点で成長すると断言できたのかな？
私の担当案件は同僚と比べてROIが高いほうだと自負していますが、それでも100%ではありません。
当然予期できていないものもありますが、ここで挙げた3つの課題がクリアできない、もしくは突破できる切口が見つからない限り難しいだろうと考えています。
また同時にそのようなサービスが生まれて欲しいという期待もしています。
＞本名で書けばいいのに、VCなら。
君なら知っていると思いますが、VCといってもサラリーマンです。
君みたいなネットタレントでも私は承認欲求が強いわけでもないので、実名で注目されることでのメリットが無いのです。
＞概ね合っているとは思うがこの人自然言語処理は理解してなさそうだ
私のもともとのバックグラウンドはエンジニアで、セキュリティソフトの迷惑メールフィルタリングシステムを開発していました。
自然言語処理は業務で取り扱ってきましたが、どういった点が自然言語処理の理解が足りなそうか教えていただけますか？
あまり冗長にならないように書いたのですが、不足している箇所があれば修正したいのでご教示いただければ幸いです。
＞1.多くのユーザーは凸る前にカタログやQ＆A等を見るでしょ普通。ボットはその中間でしょ。2.検索性の悪いQ＆Aよりはマシな可能性は？ 3.何故に二者択一よ。
「カタログやQ＆A等を見るでしょ」
これがなぜ対話になるのですか？なぜチャットである必要があるのですか？いきなり不明点を話しかけると思いますか？
検索性の悪いQ＆Aよりはマシレベルのものがビジネスとして成立すると思いますか？
チャットボットはゆらぎも含めた大量のインプットデータが必要です。
そのメンテナンス費用を考慮すると検索性の悪いQ＆Aを直せと言いたいですね。
「3.何故に二者択一よ」
対話システムとしてビジネスをするのであらば、対話である必要があるのか、なぜ対話なのかといった観点は必要になると思いますがいかがでしょうか？
なかなかご理解していただけないようなので、この質問をさせていただきます。
「あなたはユーザーとしてチャットボットで質問をしますか？まだ使ったこと無い場合、質問ができそうでしょうか？」
＞まずもって中身のサービスが素晴らしく、それをチャットUI（また、それが載っているプラットフォーム）をもってレバレッジかけるような感じ
私もこれは完全に同意です。
既存製品の新たなチャネルとして、そのUIがフィットするのであれば良いかなと思っています。
ただ、チャットボットですという売り方では難しいと考えています。
（実際チャットボットでこれから生きていくみたいなビジネス相談が多いのです。）
ご理解いただきありがとうございます。立場上、実名発言が難しいのですが、この「チャットボットで俺は生きていく」層が多くそれに警鐘を鳴らしたい、鳴らさなければいけないと感じ増田に書きました。
ネットメディアの導入事例系はマーケティング的な要素が強く、またあの記事の人件費削減の根拠も曖昧です。
＞ユーザー側が求めてるサービスの質次第なんじゃないかな。未成熟な技術分野だからこそ、提供者側が工夫すれば良いだけ。
工夫というのは同意です。
ただ現状、完全自由対話のインタフェースを用意すると、ユーザーの期待値をサービスが超えることは無いと考えています。
ある程度選択肢を絞らせる、スタンプを使うなど「工夫」がなければ難しいでしょう。
またその工夫でもこのインタフェースだけでビジネスとして成り立つかというと...我々は慎重に考えています。
＞複数人が入っている部屋での稼動があると思うんだ。
趣味でSlack上で司会進行的に喋るBotを仲間内で開発しましたが、これは非常に面白かったです。
ただ、やはりビジネスとなり例えば1,000社が有料で導入するレベルのものかというと...
＞成功しそうなの教えて
そうですね、ポジティブな話もしないとですね。
昔からあるものですが、どうもインタフェースが特殊で事例が中小企業規模まで降りてこない。
Google Analyticsの焼き直しや、他の埋込み型トラッキングサービスも伸びています。
コンシューマ向けだと、所謂CtoCにはまだ可能性があると思っています。
炎上はしましたが、個人の写真売買など「今までプロが提供してたけど素人でも提供できる、かつ流通量が多いもの」に可能性はあると思います。
更に追記
もうご覧になる方はほとんどいないと思いますが、最後の追記です。
活用方法や実際の導入の声など、参考になるコメントもたくさんいただけて私自身も勉強になりました。
※はてなの方から他のシリーズもやってくれとコメントを頂いたので、IoTやVRなど他のトレンドについての課題も今後「増田で」挙げていこうと思います。
これらの意見をいただいても尚、ビジネス化をしていくには難しいだろうと私は考えています。
それほど、私が挙げた3つの課題をクリアしかつビジネスとして回していくことは難しいからです。
そして、同時に「未来はどうなるかわからんぞ」といった意見には賛同します。
Webもアプリも「こんなもの流行るわけがない」という世論があった中で、ここまでの発展を遂げています。
「若くチャレンジしようとする芽を潰すな」という意見もありましたが、そもそもこの意見を聞いて諦めるような起業家ではその先にある苦難に立ち向かえないでしょう。
もともと「チャットボットが新たなインタフェースになるんだ」と確信し強い気持ちを持っている起業家は、こんな意見を聞いても全く諦めようとはしません。
私も実際、起業前の方に「止めておいたほうが良い」と伝えたことは何回もありましたが、それでも彼らは起業しサービスをローンチしています。
私自身もそうでした。みんなに反対される中、当時全く広まっていなかった人工知能系のベンチャーを立ち上げました。
勝手ながら彼らの信念がいつの日か実り、少しでも世の中に良い影響を与えられる存在になってほしいと思っています。
VC的にはIPOか売却というゴールを期待してしまいますが（笑）
私が本当に警鐘を鳴らしたかったのは、どちらかというと「チャットボットが万能だ」、「チャットボットで何でもできるようになる」と伝えるメディアやコンサルの方です。
口々にチャットボットだと言って誰にも使われないサービスやスタートアップを量産しようとしている話を聞くと心が痛みます。
過度な期待をしたくなるのはわかりますが、私が挙げた3つの課題はどうしても避けては通れません。
起業家の方々が「周囲の過度な期待」に流されず、これらの課題から目を逸らさず、新しいインタフェースを開拓してくださることを期待しています。
※上から目線のようですみません。ただ立場抜きにして1ユーザー、サービスを享受する1人の人間としても期待しています。
最後に
多くの方にご覧いただきたいということもあり、こういった表現を使用してしまいました。
特にけんすう氏にも良くない表現を使ってしまいました。申し訳ありませんでした。
ここにお詫びいたします。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
WWDC2015観たがApple大丈夫か？みたいなのと、そのブコメを読んで、急にスッキリした。
Appleは、表で魅了するビジョナリストと、影で徹底するリアリストの両輪の会社だったんだな、と。
Appleは、特にジョブスが追放後に復帰してからは、「Cool」なブランドイメージの構築にシャカリキだった。
だからこそ、クールで無いモノはアッサリと捨てられた。皆が早すぎると思うタイミングで。
フロッピーディスク、Flash、CDドライブ、イヤホンジャック以外のインタフェース。
逆に言えば、それ以外の「基幹的な技術」は、大したことが無かった。
Appleはクールなブランドイメージとは裏腹に、絶対に逆鞘にしない会社だった。
どんなに高いと言われようが、利益にならない製品は売らなかった。
逆に言えば、凄まじい勢いで、見切って行った。
そして、クールな製品が安いと判断された時点で、市場を制覇できた。
ジョブスの変質的な「今まさに必要な製品を市場に出す」コダワリは、ほどよく成功した。
iPadではなくiPhoneから、MacOSではなくiPadから。
忘れがちだが、ジョブスのファナティックな執着は、それほどの熱狂を生み出さないこともあった。
歴代のiPod nano、Apple TV、いくつものOSのギミック。
また、ジョブス本人も「これ何に使うんだ」と思っているものが売れることもあった。iPod Touchが良い例だ。
そして、デザインやクールさに金を出す、空前のベータテスター達が生まれた。
繰り返しになるが、Appleの製品に逆鞘は無い。必ず売れば売っただけ儲けが出る。
どんなに性能が低くても、使い道が不明でも、不満が生まれても、売れさえすれば儲かる。
だから、事実上のベータテスター達が大量に居ることで、儲かりながらテスト出来る。
Apple Watchは、後発の時計メーカーとしては凄まじい勢いでスタートした。
Appleは、そのクールさが維持できている間は、ホトンド無敵のハードウェアメーカーだ。
AppleWatchしかり、Macbookしかり、どんなに欠陥があっても、アーリーアダプターであろうとする人達が買う。
そして、その不満点や運用上の問題点を取り込んで、高速に改良品を作り上げて販売する。
3,4世代もすると、こなれた製品になり、一般消費者もこぞって買う。
そこまでに、Appleがハードウェアを販売することで損することが無い。
とんでもないレッドオーシャンに後発組としてドヤ顔で乗り込んでいって、そして成功する。
（失敗したとしても損することだけはないので、簡単に切り捨てていける）
AppleはAmazonとは真逆の経営方針で運営されている。
MicrosoftやGoogleのように、ビジョンを全面に打ち出す必要すらない。
売れば売っただけ儲かる。売ったものからフィードバックを受けて改良する。
ハードウェアメーカーの王道であり、恐ろしいリアリストが経営している。
機械学習やIoTのような「今すぐカネにならない」ことを吹聴せずに着実に儲ける。
「これからはウェアラブルデバイスだ！」とAppleが言う時は、利益が出る製品を出す時だ。
GoogleやMicrosoftや、その他未来の技術を謳う企業は、プロシュート兄貴に怒鳴られると良い。
「ブッ殺す」と心の中で思ったならッ!その時スデに行動は終わっているんだッ!
http://anond.hatelabo.jp/20150309194054
私は、黒髪ロングストレート女子高生17歳と呼ばれる抽象概念です。
はてなというインタフェースを通してみなさんとコミュニケートしています。
傘のさし方や、歩き方についていただいたアドバイスは次の雨天時にぜひ試してみようと思います。
ホントですよね！私はそういう人を見るたびに呪いをかけています！
なんと！私も購入してみます！
でも、部長ご自慢のエドワードグリーンはビチャビチャでした。以前飲み会で「大事な打ち合わせの日にはこの靴なんだ」みたいなこと言ってたんですけど、雨の日まで。。バッカですよねーwww。
かわいいですよね。私はたまに職場近くのノラ猫にマツキヨで買った大豆バーをあげます。
「増田エロ漫画部なんてのはないですか？」を見たばかりなのでhttp://urx.nu/erbyのステマではないかと疑っている
ムラムラきました！
ながぐつをはけ
経費削減だとか言って安物PCを購入させる上司はほとんどの場合が無能．
月1回だけ誰かが使用する何かの専用システムコンソールとかなら安物でも構わない．
まず，CPUは一番高いのを必ず選ぶ．
少し考えれば分かる．いつも開いているWordやExcelの起動が２，３秒早くなるだけで，一年を通してどれだけ作業が効率することか．
作業中のイライラが低減するだけでどれだけ会社の雰囲気がよくなることか．
コアが増えても速くはならない可能性もあるが，今後のソフトウェア進化に追従するためにも一番高いのを買っておくべき．
もちろん，普通に使っていれば使用することはないが，ディスクキャッシュとして使用すれば，やっぱりWordやExcelの起動が速くなる．
VMを使用することで作業効率を向上することも考えられるだろう．メモリが大いに越したことは無い．
ただ，容量を多くする必要はない．
大切なのは速度であって容量ではない．容量が多くなるとロストしたときのダメージがでかい．
別途NASなりクラウドストレージを用意してバックアップすることが基本．
注意するのはメーカー．怪しいメーカーのSSDはスピードが出ない場合もある．
安心のIntelを買うか，ベンチの情報をしっかりチェックする．
一般的な職種の人でも最近だとビデオ・写真の編集を行う場合がある．ただ，安物やチップ内蔵でも最近は余裕の性能がある．
ここだけは値段を確認しながら選ぶ．高すぎる物は買っても意味が無いし，消費電力が増えるだけである．
馬を乗り換えることはあっても鞍を乗り換えることはない．
その人にあったインタフェースを長く使うことでより作業が効率化する．
（まぁ，和田先生はLet's note使ってたりするけどさ）
