「クライアント」を含む日記 RSS

はてなキーワード: クライアントとは

2016-08-28

ビリギャル」の努力論がどうしても受け入れられない

少し前に学年一のギャルがビリだけど慶応大学がなんちゃらっていう映画流行った。

超絶ブラック企業(月間400時間稼働の制作会社)にいた私は、忙しいにも関わらずワンマン社長命令でこの映画を見に行かせられた。



内容はみんな大好きな「ダメな奴が努力して報われて良かった」系。

ジャンプ漫画みたいなもんだ。

しかも裏話として実は良い高校にいて地頭は良かった等もあるようだ。

そういった裏設定までキン肉マンナルトと同じだなと感じた。



映画自体面白かったし、この先生指導方法共感する部分もあった。

しかし、どうしても受け入れられない描写があった。

いや、正確に言えばこのシーンを大絶賛する周りに対して嫌悪感を抱いてしまう。




それが毎日朝まで勉強して日中の授業中に寝る」というシーンだ。



確かに予備校のほうが指導が的確かもしれない。

それでも授業中に机に突っ伏した状態での睡眠は浅いだろうし、何よりこの根性論会社と同じ気持ちの悪さを感じた。

納期ギリギリ要件追加を行い、計画も何も無視するクライアントと、それを受け入れて社員強要する会社を思い出させた。



ちなみに会社ではこのシーンが大絶賛だった。

「やっぱり寝る間を削ってでも何が何でもやり切ることが大事やな」と社長は涙を浮かべながら熱く語っていた。



もうさ、こういう「ギリギリで頑張って目標クリア」系を賞賛するのやめようよ。

あと寝る間を惜しんでのなんちゃらを賞賛するのやめようよ。



コツコツ頑張ろうよ。

時間より効率を上げることを賞賛しようよ。



結局その数カ月後、私は心も体も壊れて仕事ができなくなってしまった。

1年以上も無職だ。ギャルでは無いが社会でビリになってしまった。

あの映画サムネイル画像を見るたび吐きそうになるんだ。

2016-08-22

http://anond.hatelabo.jp/20160822131652

「こちら弊社、指示書の内容が要件と違う。繰り返す、指示書の内容が要件と違う。再見積の可否を問う。」

クライアントに言ってみたい。

現場からマネージャーにひとこと

指示書の内容が要件と違う場合に、再見積もりの可否を問う交渉力を身に付けて欲しいです。

クライアントとの力関係によっては苦しいところですが、どうかご決断を。

http://anond.hatelabo.jp/20160822123622

2016-08-18

PCデポの件をみると

クソコンサルがなくならないのもわかるし、老害がいなくならない理由もわかるな。


要はできない奴を相手にするから、とりあえず金をふっかけるわけよ

で、あとでクライアントはそんなにコストはかからないはずだといってくるし、ガキは不当な労働ふっかけるなといってくるわけよ

それはそうなんだが、最初お前らができなくて泣きついてきたのを棚に上げるなっていうのは無視される

声をあげられなければコンサル老害の勝ちってわけだ

2016-08-13

プレミアムフライデー

実施

クライアント「月曜朝一でお願いします」(金曜17:45)

実施

クライアント「月曜朝一でお願いします」(金曜14:45)

2016-08-06

宣伝会議とかブレーンとかでさ

今回の文藝春秋の(アニメか?)の広告みたいな、世の中を読めずに炎上した事例の特集とかやんないかな?

普段裏方で、責任クライアントにとってもらうのが広告だけど、

ウケた広告なんかだと、ここら辺の雑誌クリエイティブディレクターが「ドヤァァァ」って出てくんじゃん。

でも、世の中読めずに失敗の決定をしちゃった経緯って、事例として学べる事もあると思うんだよね。

2016-08-02

個体値計算話題になっている件

http://gigazine.net/news/20160802-pokeiv-pokemon-go/

GIGAZINE経由で話題になっているサイトの仕組みについて、私はあのサイトの作者でないけど、解説してみます

 

ブコメを眺めていて問題視されてるのは

 

A. パスワードが盗られのではなかろうか

B. ポケGO勝手操作されるのではなかろうか

C. Tokenの管理杜撰だと危険ではなかろうか

 

の3点と思われます

以下、危険性について述べます

実際に中の人がどういう運用しているか中の人次第なので、信じるか信じないかという話になるから、水掛け論がはじまるだけなのでやめときます

 

まずAについて

Pokémon Trainer ClubについてはYes。そりゃパスワード入れてますもの

Google AccountsについてはNo。あくまでもパスワード入力する先はGoogleになるので、他のサイトは介在できない仕組みです。

以下、Pokémon Trainer Clubについては自明なので言及しません。

 

Bについて

Yes

どのくらいの長さの時間使えるかは分からないですが、Access Tokenかセッションのどちらかの有効期限内では、勝手操作出来るものと思われます

 

Cについて

可能性は低いがYes

ただしポケGO実装次第です。

 

以下、理由を。

まず彼のサイト認可取得方法は、OAuth2という物にもとづいています

これは、あるサイト上のユーザリソースを、外部のサイト若しくはプログラムから操作する場合に用いる方法です。

OAuth2自体オープンかつセキュアな仕様ですが、運用によっては当然危険な事が起こりえます

よって、Aについては(Google Accountsならば)No。そもそもパスワードを受け渡さないための仕組みだからです。

 

さてこの仕組ですが、認可を得るための方法は幾つかの手段があります

ココでは彼のサイトで使っている方法(AndroidアプリiOSアプリなどのための認可手段)だけを説明しますと、

1. OAuth2 ClientIDを用いてAuthorization Codeを取得

2. Authorization CodeをOAuth2 ClientIDClient Secretを用いてAccess Tokenに分解。Authorization Codeは一回のみ使用できる(あってますよね?)

3. Access Tokenを特定場所に投げることで、サイト側はユーザ情報を知ることが出来る

となります

 

彼のサイトで用いているアクセス範囲確認できるのは、ここでAccess Tokenを用いて取得できるのは、Google Accountsのメールアドレスくらいです。

コードコピーする仕様になっていますが、それは1と2の間で行われています

もし何らかの手段でConsumer Secretを知っているなら、Access Tokenに分解する作業は彼のサイトで行っている可能性が高いと思われます

しかし、普通Client Secretサーバサイドに置き、APIで分解する形が多いと思われます

分解された後のAccess Tokenは一定期間で有効状態が切れます

 

Client IDある意味オープン情報なので、コード発行画面までは、知っている人なら比較的たやすく表示させることが出来ます

よって、「ポケモンGOが」と表示されているのは、このClient IDが本物だから出ているのであって、彼のサイトの作者がそういう詐称行為を行っているわけではないです。

 

ここからは、Android用のtokenの動きを知らないので推測となります

Access Tokenは1時間弱の短い期間で有効期限が切れます

その後のAccess Tokenの取得は、一回ユーザが認可すると再度の取得には認可画面による対話操作必要としない仕組みを使い、アプリケーション内で自動的に取得できるような実装になっているんではないでしょうか(AndroidiOSに詳しい方、補足願います

また、Access TokenはセッションDB内で管理し、クライアントアプリ側には戻さないのがよくある姿ではないかと思います

(ステートフルは重いからとクライアントに戻す実装をしている場合もあるとは思いますが)

よって、通常であればAccess TokenがBはセッション持続中若しくはAccess Tokenの生存期間中の短い時間ならYes

Cは可能性は低いものの、Access Tokenをクライアントに送り返す仕組みにしてあり、彼のサイト側でそれをDB等に保存してあるならばYES

となります

 

私は基本的サーバサイドの人なので、クライアントサイドの常識はそーじゃねーよって話もあるかとは思います

その時は…すいません。と、予め謝っておきます

2016-07-22

ボランティアについて考察

http://www.asahi.com/articles/ASJ7663TXJ76UTQP026.html

ブコメ読んで気になったので持論を整理した.


ボランティア本質は志願者の自主性であり,募集者と応募者の契約だと考える.従って,どんなに条件が厳しく,かつ無償ボランティア募集をしたとしても,その募集違法性がなく,かつ自主的に応募する者がいる限り外野が何かを言うことは基本的意味がない.

また,募集者側が一方的に莫大な利益を得て,応募者に配分されなかったとしても,契約が成り立っている以上そのことを批判するのは筋が通らない(納得できないのであれば応募しなければいいため).

しかし,同時に以下のような議論は別途成り立つと考えられる.

A. ボランティア精神を煽ることは本質的おかし

前述の通り,ボランティア本質は志願者の自主である

従って,他者に対してボランティアすることを指示したり,強制したりすること,及びボランティア精神が足りないと嘯くことは原義に反する.

そのような場合は「無償労働」「奉仕」「奉公」のようなより適切な表現をすることが望ましい.

同時に,オリンピックのような大規模かつ成功させることが必須となるイベントにおいては,国民ボランティア精神のような曖昧ものに頼るのことはそもそもおかしい.

仮に無償ボランティアであることを押し切った結果人材不足となりイベントが失敗に終わったとしても,その責任は全て運営者に帰するものであり,ボランティアを呼びかけられた側に一切の非はない.

B. 無償ボランティアは関連分野の衰退に繋がる

生活がかかっておらず,時間に余裕がある学生によく見受けられるが,無償あるいは格安でいいから働きたいという人がいることがその関連分野の衰退に繋がるということがボランティアに限らず考えられる.

これはある意味ではダンピングであり,「他の人は同じことをもっと安くやったのになぜやってくれないのか」という一部のクライアントが常用するロジックに繋がっていく.

そのような意味では,労働に対しては(正当な)報酬が支払われるべきという資本主義原則に則り,募集者,及び応募者を批判することは正当である


C. 無報酬責任所在曖昧になる

報酬を支払うということは労働に対して責任を負わせ,報酬を貰うということは労働に対して責任を負うことである

応募者の精神という比較曖昧ものに則った無償ボランティア必然的責任所在曖昧になるため,追加労働契約履行等の「お願い」は出来ても「強制」は困難である

そのようなリスク回避したい場合,そもそも無償ボランティアに頼るべきではない.


D. 応募者の見識に対し,助言として批判することはできる

法に従っており,募集に対し自主性をもって応募者が契約を結んでいる限り,根本的にはそのことに対し何かを言うことは意味がない.

しかし,その契約が応募者の見込み違いや錯誤によるものだとすれば,外部のものが応募者に対し制止の助言をすることはそうおかしいことではない.

直感的に言えば,奴隷募集に対し自主的に応募した応募者に対し,本当に奴隷になっていいのか,奴隷を甘く考えていないか,あるいはBのような関連分野に対する影響を指摘することはできる.


E. そもそもボランティア無償であるとは限らない

冒頭の朝日新聞のような場においては「そもそも、ボランティアとは、社会のために自ら進んで、無償で働くもの。」と言われることが多く,日本においても大多数の認識はその通りであると考えられる.

しかし,非営利団体営利目的としなければ金銭のやり取りをしていいように,自主性という原則さえ守られていれば,交通費宿泊費といった実費のやり取りをすることや,最低限の報酬を支払うことも立派なボランティアであると考えられる.

2016-07-21

僕は、社畜として死にたかった

僕は何のスキルもなく頭も悪いコミュ障デブ不細工でまさにゴミクズなんだけど、自分が売ってる商品のことはとても好きだ。

色々出来ないことも多くて不便なとこもあるけど、すごいことが出来る商品なんだ。

僕はゴミクズ自分自身の代わりに自分の売っている商品自分自身として思い込んで、そうして人生ではじめて自己肯定感を覚えることが出来て、本当に毎日しかった。




商品の改良プロジェクトが始まって、僕はとても嬉しかった。

すごい商品だけど色々出来ないことも多くて歯がゆい想いをしていた。「出来ないこと」はいつも同じだからだ。この点をクリアしたらもっと売れるのに、もっと使いやすくなるのに、って。

僕が入社した当時の上司は、商品の改良をほとんど諦めていた。そんなコストがかかることを口に出せる空気ではない、と上司は思っていたように記憶している。

から僕も、改良は出来ないという前提でいた。僕の上司も辞めてしまって、たくさんのひとがいなくなって、結果的に、僕みたいに何にもできないクズでもそこそこの裁量権を持てるようになったんだけど、大幅な改良は出来ないと思い込んでいたし、でも何か変えなければいつか時代遅れになって全く売れなくなってしまうだろう、という焦りが常にあって、僕はそれをとても恐れていた。僕にとっては、やっと意味を持ち始めた僕自身価値が再びゼロになることと同義だったからだ。

から、改良に着手出来ることが決まって、僕は本当に嬉しかった。本当に嬉しかったんだ。




そして、そのプロジェクトが取りやめになってしまった今、僕の毎日はまた無価値ものに戻った。

取りやめになったのは、僕がやっぱりコミュ障仕事ができなかったことが原因の1つ。いや、僕ごとき経営判断材料の1つになったなんておこがましいかあなた担当でなくても取りやめていた、と偉いひとは僕に言った。それは自暴自棄になった僕を慰めるために形式上発せられた、発することを強いられた空虚言葉だったような気もするし、結局のところお前に出来ることなど何もなくお前の存在はまったく影響を及ぼさないのだ、という正当な評価あるいは本心から感想だったような気もする。

いずれにしてもプロジェクトは取りやめになった。僕はお情けで仕事を辞める猶予をもらって、まだ仕事を続けさせてもらっている。




作業自体プロジェクト開始前と同じなんだけど、だからこそ、毎日地獄だ。

すごい商品だけど色々出来ないことも多くて歯がゆい想いを毎日するんだ。この点をクリアしたらもっと売れたはずだった、もっと使いやすくなるはずだった、と、僕にもっと価値があれば実現出来たはずの未来を想いながら、自分自身の無価値さを思い知らされ、それらすべてを押し隠し、笑顔をとりつくろってクライアントに惰性で商品を売り込む。なんとむなしいことだろう。無価値な僕にはぴったりな仕事かもしれない。

そもそも無価値な僕に認められたのは、仕事を続けることではなく、仕事を辞める猶予だ。来年5月納品の案件について、担当欄に僕の名前を入れて見積書を作る。その頃たぶん僕はこの会社はいないが、たぶん商品自体存在するだろうから問題はないだろう。






あのとき仕事をやめたくなかったけど、やめないことで僕に何か出来ると勘違いしてたみたいだ。

ただでさえ仕事が出来ないくせに、このところずっと仕事が手につかなくて、なんでこれで給料でてんだろ、って、いっそ不思議だ。

あのとき辞めてた方が、この商品にとってもよかったんだろう。僕がいなくなれば、もっと頭の良いひとが受け持ってくれてきっともっと良いものにしてくれるに違いない。



僕は、社畜として死にたかった。

価値な僕自身から目をそらして、思考を停止させた社畜のまま死にたかった。

なんて贅沢な苦しみなんだろう、さっさと死ねばいいのに

2016-07-20

熊本地震の際「ライオン動物園から逃げだした」とデマを流した人間逮捕された。

そろそろ例の弁護士クライアント青年誹謗中傷し続ける人間逮捕されてもいいころ合いだ。

2016-07-16

WebデザインWebシステムは、相手企業事業が失敗しないように話を進めるべき

雑談

最近LINE株式上場(証券コード:3938)したようだ。一時は高値で5,000円まで上がったが、安値4,310円(2016年7月16日 17:44現在)まで下がり、なんと690円も下がっている。一瞬の差し足で儲ける連中は賢い。

流行統計的手法deep learning(機械学習人工知能)を駆使し、株価が3,000円台まで下がるタイミングは何月何日か?を探り空売りできないかを考える今日この頃

さてここからが本題。金融に関する仕事コンサルタントなどはできないと思い、とりあえずWebシステムもどき、あるいはWebサイトらしきものを作る仕事を始めた人の愚痴である

商品販売広告戦略立案Webサイト制作までの流れ

まずA社が商品販売するところから、B社がWebサイト制作をするまでの流れを簡単にまとめた。

[Step1]:商品を売ろうと企てる

[Step2]:商品の開発期間・開発コスト広告集客を考える(Plan)

[Step3]:2におけるチラシ・ホームページ外注に投げる

[Step4]:外注先がそれらを一件○万円で引き受け、広告完成(Do)

[Step5]:広告効果がどれだけであったか?を調べ、問題点について調べる(Check)

[Step6]:商品販売を取りやめるべきか?広告の打ち方を変えるかの改善を図る

[Step7]:改善された広告販売戦略を基に動き直す(Action)

さて、かの有名な電通鬼十則( こちら参照)にも「「大きい仕事」と取り組め。小さい仕事は己を小さくする」と言う言葉がある。

先日その大きい仕事のお膝元というべき会社で、Step4を担当している人と話した。それが意外に俺と同じ事を考えててビビった。って事は日本広告業界すべてが、派手な物を作って...って発想なのかと思った。

さて案件の規模が小さい程[Step1〜7]全体の大部分に関与でき、大きい程[Step1〜7]全体が見渡しにくく、関与もしにくい場合もある。そして自分アクションを起こしたが、結局[Step1〜7](PDCA)全体が回ってない事もあるのは何処も一緒なようだ。

もちろん自分は[Step4]の工程の1部品として動いていて、基本1〜7の大枠の中の1部品として動いているに過ぎない。ここでStep4の仕事をしていて愚痴りたい事の1つに、「[Step4]の人たちって、どうして[Step4]の事しか考えないのだろうね?」と言う事だ。以下その愚痴を書きたい。

愚痴:デザイナーに居る「俺が作ったデザインすばらしい」な意識高い系

どうも俺は「俺が作ったデザインすばらしい」「よそがやらないようなデザイン」をひけらかす為に話を進めている場合程、やる気なく仕事している。

過去の嫌な事例

過去酷いと思ったのは、[Step1〜3]側のクライアント会議で決まった内容を、[Step4]のこちら側で無理矢理ひっくり返した物を作った事だ。無論自分らの意見を押し通すのも商談の上で必要な事もあるが、必要ないならやらなくて良いと思う。

上は上で「クライアントでなくウチがやりたいんだ」と一点張り。それに対し、実際に手を下す俺は「既に決まった物なのに、そもそも全体の進捗を狂わす事はないんじゃない?ただただ作業日数も増え、俺のやることも増えるだけだし、俺そこまで能力ないし」と思っていた。

その結果中間会議クライアントに「やらない方がいいんじゃないですか?」と言われ、ざまーみろと思った事もあったっけ(笑)。こうなると「俺はこんなに素晴らしいと思っているのに、お前はそう思わないのか」と言う流れになり、相手からすげえ嫌がられることも少なくない。

確かに「とりあえず始めて見て反響を見る」と言う事も重要だ。しかしながらStep4の自分らが、デザインをひけらかすが目的ならこれは論外だ。以上。こうして俺はデザイン仕事ではやりたくないなあと思うようになった。

商品広告をお客さんに見てもらい、売上を上げる事がそもそものやる事

この時自分がやっていた仕事は、「商品Pの広告ターゲットとする客層のx%に見てもらい、商品Pにおける売上高をy%向上させる」事の一部ではなかろうか?ならば見た目自慢よりも、サイトに依ってお客さんにどれだけ反応が呼べたか?という事を調べ、クライアントと一緒に[Step5〜7]に活かす事も重要だと思う。

サイトの見た目、機能SEO(検索エンジンソーシャル対策)などがそれぞれバラバラなのもいけない。そしてそもそものところで「どのようなお客さんに見てもらったり使ってもらったか?」「そもそもの事業戦略」が無視されている。

そんなに見た目や機能重要か?必要最小限で良いか会社事業が回るようなものにする事こそ、自分ら[Step4]の人間のやる事だと思う。

クライアント、各Step毎の人と連携する姿勢を忘れない

そのためにクライアント、各Step毎の人と連携する姿勢を忘れてはいけない。先ほどの愚痴みたいに各Step毎にバラバラに行動するようなやり方は、今後世界的にも流行らないと予想する。又、システムホームページが内製化されるのも、Step毎の連携を良くする為である

ツールを作る事に頼らず、他のみんなができるように

さて、商売柄わからないことがあると、はてなブログQiita、StackOverflowなどのレシピサイトを見る事が多い。ここで最近Qiitaを読んでいて、「マーケティング担当者にSQLを完全マスターさせた話:Qiita」と言ういい記事があったので紹介したい。以下デザインの話から離れるが、是非聞いて欲しい。

みなさんこの試みをどう思うだろうか?俺はこの動きに賛成だ。俺の推測を書くが、恐らくこの会社社員数は多くて100人前後まで位で、上記の[Step1〜7]までの多くの部分を1社で担当していると思う。

無論顧客情報や売上情報に関するデーターベース(SQL)にアクセスし、それを分かりやすく画面に表示してくれるアプリはあるはずだ。これをみて経営商品を売るのをどうしていくか?を考えて行く訳だ。

例えば、1ヶ月に100回以上データベースに対し特定の処理がなされるのなら、アプリにした方が良い。しかし「この時だけ単発にデータベースに○○な処理をさせて、△△な事を調べたい」と場合もあるはずだ。こうなってくると、「マーケッターの人に単発のSelect案件を片付けてもらおう♪」という流れになる。

以下何故この作戦必要かを熱く語る。例えばファミコンボタンは「Aボタン、Bボタン、STARTキーSELECTキー十字キーしかなく、それ以外の事は一切できない。これはアプリケーションも同じで、アプリケーション化する事でユーザーの動きを制限することにつながる。

必要最小限に仕事をまとめたい場合は別だ。しかし今回の場合「火属性の敵に対し、どう対処するか?」「そもそも相手属性E_1,E_2,…,E_nに切り分け、それぞれに対しどう対処するか?」の場合ならば敵の弱点も変わってくる。そのため制限ありだと対処できないケースも出て来る。

こうなれば「賢者すっぴんすっぴんすっぴん」では某エ△スデスに勝てないだろう。それに賢者戦闘不能の時はもう冷あせもんだ。レイズアレイズ、フェニックスの尾がないときは、誰がケアルエスナしてくれよう。そこで全員が「賢者、赤魔導士、赤魔導士、赤魔導士」位ならば、賢者が忙しい時にケアルが使えてラクだし、全体を有利に進める事が可能になる。

[Step4]の会社にいる立場としてこんな選択が出来るのが羨ましい。なので新しくツールを作るだけが選択肢ではなく、みんながある程度できるようにしておきたい。

その為に自分は何ができ、どうしていきたいか

以下その為に自分は何ができ、どうしていきたいか?について話す。まず自分学生時代、どちらかと言えばxとyが嫌いだった人が絵や音楽をやる事もあるようだ。俺はその逆で、絵を描くのをサボってでもxとyをやり続けていたい人だった。なためどうも絵が好きな人音楽好きな人の話が抽象的に感じる事がある。(俺、Webシステムの方がリクツが分かるほうだから得意かも...)

起業は無いものとして考えた時、どの道Step1〜7のPDCAサイクルなど早々回りゃしない。ならば、少しでも自分の出来そうな方で仕事したいと思っている。わがままを言えば[Step1〜3]寄りの仕事がしたいと薄々思っている。

このまま堅い商売を続けるなら、それこそ物理学者みたいに世の中の物事を数値やy=f(x)化し、扱いやすくしてやりたいとも思う事もある。例えば商売なら、未来予測しきる無敵の関数y=f(x)を編み出してもうけるとか。

又は経営層やマーケッターがxとyを見やすく、確認やすくするデーターベースツールの開発が出来て、売っぱらう事ができれば…(用語言うなら、Microsoft PowerBIと言ったツールかな?)

xとyをフル活用することで、できる限り失敗しない線を探して勝ちを拾う。又はマーケッターなどの人と協力し、無難商品Pを売る上での最強の市場(=有利な戦場)を見つけて行ければとも思う。

最後に「無理に成功を夢見る」ではなく、「出来る限り失敗しないように無難にやる」「無難にやる策を模索する」で行きたい今日この頃。まあ、難しいんだけどな。

2016-07-14

断言しよう、チャットボットブームは去るし関連ビジネスも失敗するよ

会社名を明かせないが、業界大手ベンチャーキャピタル所属している。

主な出資先は所謂ドルレイターと呼ばれる「成長、拡大期」のベンチャーである

私自身も一回事業立ち上げ、売却した経験を持つ。



さて、そんな私も最近起業前、もしくは新規事業を立ち上げようとしている方にアドバイスをすることが多い。

そしてその中でもここ1ヶ月は会う人の3割がチャットボット系のサービスアイデアを語るのである

「やめたほうが良い」と毎回アドバイスするのだが、毎回伝える3つの点についてここに記したい。



願わくばこの記事が広まり、浅はかな「対話サービス未来」を考えているベンチャーが断念し、より可能性の高いビジネスに切り替えて欲しい。

そしてこの記事を受けても尚、私の予測を上回り成功するチャットボットサービスが出てきてほしいとも思う。



前置きが長くなったが、以下3点がチャットボットが失敗する理由である



1. ユーザーの利用シーンが無い

一番の理由がこれだ。

ここで注意したいのが、 クライアント ではなく ユーザーである点だ。

よくあるチャットボット簡単ECサイトに導入できますサービスを事例に出してみよう。



彼らはこういった切口で法人クライアントに売り込む。



「今まで大変だった顧客対応チャットボット代替できます。」

チャットボット商品アピールをすることで売上が上がります。」



確かに正論に聞こえるし、無料キャンペーンや優先登録などに興味を示すクライアントは多いだろう。

プレスリリースを出せばクライアントの問い合わせは殺到するだろう。



しかし、その先のユーザーのことを考えているだろうか?

ユーザー商品についてわからないことがあった際に、いきなり得体の知れない自動応答システムに話しかけるだろうか?

そもそも埋込み型の顧客問い合わせサービス(zopimやolarkなど)について、ユーザーの利用率が5%未満に過ぎない事例が多いことを知っているだろうか?



私もこれらの問い合わせサービスに関わったことがあるが、日本人性質としてチャットボットにいきなり話しかけるしかも想定された問答を想定通りの言い回しで)例は少ない。

ユーザーが使わなければクライアントも離れる。



無料期間でクライアント数は増えるだろう。

また、少ない額であれば導入する事例も増えるだろう。



しかし、ユーザーチャットボットを使うシーンは少ないだろうし、結果として売上にもコストダウンにも繋がらないケースがほとんどだろう。


厳しい言い方をすると、話を聞くチャットボット関連サービスは現状、ユーザーのことを考えず提供者側の視点しかない マスターベーショナリサービス」

なのである



2. そもそも自然言語処理の精度はそこまで高くない

自然言語処理簡単説明すると、コンピュータが会話を理解し適切な回答を返す処理」である

この技術は現状、正直言ってそこまで高いレベルに達していない。

言い換えるならばユーザー期待値提供できる技術レベルの均衡が取れていない。それどころかユーザーの求める自然対話レベルにはほど遠く失望させるものなのである



よく非技術者創業者流行ものが大好きなコンサルが「Deep Learningの登場で自然言語処理の精度が高まり自然対話を実現できる」とドヤ顔で語るのだが、これは大きな勘違いだ。

画像認識については、「文脈」などその対象以外の外部要因が発生することは少ない。

その為、その特徴量を見出しやすDeep Learningを使用することで精度をかなり高めることが可能である



しかし、「対象のもの」以外にも文脈や発する人間パーソナリティなど様々な外部要因が発生する対話において、特徴量見出しづらい。

特に日本語主語が省略される、漢字の読み方で大きく意味が異なる、「空気」を重視する等のハイコンテクスト文化であり、自然言語処理は難しい。

その為にDeep Learningが自然言語処理を圧倒的に成長させ、機械であることを感じさせない自然な応答」可能にさせることはほぼ不可能なのである



そんな精度をユーザーが求めていないのでは?と思うのは提供者側のエゴだ。

自然対話自分の想定していない回答が続くようであればユーザーサービスから離れてしまうだろう。



3. 対話である必要性が無い

飲食店などの予約がチャットボットでできる」系サービスも良く聞く。

彼らには必ず「それってチャットボットである必要性ってあるんでしたっけ?」質問するのだが、納得のいく回答を得られたことは無い。


対話のほうがかっこ良い、対話でできたら未来っぽい、アメリカ流行っているから、実際にそんな浅はかな考えで通用するほどビジネスは甘くない。

対話によりニーズを深掘りできる」等もよく聞くが、2で挙げた通りそんなに自然言語処理の精度は高くなく、深掘りする以前に離脱してしまうだろう。



「なぜ対話なのか」

「なぜ対話でなくてはいけないのか」

「なぜ対話サービスが従来型のリストサービスを上回るのか」

これらの質問に自信を持って答えられるだろうか。



それができない限りはビジネスは成立しない。

今すぐチャットボット事業を畳み、↑の質問に答えられる別の何かの可能性を考えたほうが良い。


以上である

チャットボットブームは、クライアントが導入した後に「ユーザーに全く使われない」と気づきその悪評が広まる、あと半年寿命といったところだろう。



そんなチャットボットだが、現状で可能性があるとしたらチャネルの1つ」として使う程度だろう。

LineFacebookメッセンジャー組み込み、「既に展開しているサービス広報役割として活用する」、「メディア記事配信させる」役割であれば優秀なツールとなるだろう。



繰り返しとなるが最後にもう一度。



願わくばこの記事が広まり、浅はかな「対話サービス未来」を断念し、より可能性の高いビジネスに切り替えて欲しい。

そしてこの記事を受けても尚、私の予測を上回り成功するチャットボットサービスが出てきてほしいとも思う。




追記


一部コメントについて返信させていただきます



BtoBでの事例

そんなステマ記事をよく反例として書けますね...

導入事例のステマ記事メディアクライアントと内容は詰めている)はこの半年で沢山出てくると思いますが、実際の導入でコストが下がった、売上に繋がったという話は決して多く出ないだろう(むしろネガティブな話ばかりだろう)と私は予測します。



>「二次元アイドルとの会話」みたいな路線なら弾けるとこあると思うよ

これは私もそう思います。ただそのサービスだけでのマネタイズは難しく、記載した通り「チャネルの1つ」としての活用だと思います




>いま成功している企業に対して、過去の時点で成長すると断言できたのかな?

私の担当案件は同僚と比べてROIが高いほうだと自負していますが、それでも100%ではありません。

当然予期できていないものもありますが、ここで挙げた3つの課題クリアできない、もしくは突破できる切口が見つからない限り難しいだろうと考えています

また同時にそのようなサービスが生まれて欲しいという期待もしています



本名で書けばいいのに、VCなら。

君なら知っていると思いますが、VCといってもサラリーマンです。

君みたいなネットタレントでも私は承認欲求が強いわけでもないので、実名で注目されることでのメリットが無いのです。



>概ね合っているとは思うがこの人自然言語処理理解してなさそうだ

私のもともとのバックグラウンドエンジニアで、セキュリティソフト迷惑メールフィルタリングシステムを開発していました。

自然言語処理業務で取り扱ってきましたが、どういった点が自然言語処理理解が足りなそうか教えていただけますか?

まり冗長にならないように書いたのですが、不足している箇所があれば修正したいのでご教示いただければ幸いです。



>1.多くのユーザーは凸る前にカタログやQ&A等を見るでしょ普通ボットはその中間でしょ。2.検索性の悪いQ&Aよりはマシな可能性は? 3.何故に二者択一よ。

カタログやQ&A等を見るでしょ」

これがなぜ対話になるのですか?なぜチャットである必要があるのですか?いきなり不明点を話しかけると思いますか?



検索性の悪いQ&Aよりはマシな可能性は?」

検索性の悪いQ&Aよりはマシレベルのものビジネスとして成立すると思いますか?

チャットボットはゆらぎも含めた大量のインプットデータ必要です。

そのメンテナンス費用考慮すると検索性の悪いQ&Aを直せと言いたいですね。



「3.何故に二者択一よ」

対話システムとしてビジネスをするのであらば、対話である必要があるのか、なぜ対話なのかといった観点必要になると思いますいかがでしょうか?



なかなかご理解していただけないようなので、この質問をさせていただきます

あなたユーザーとしてチャットボット質問しますか?まだ使ったこと無い場合質問ができそうでしょうか?」




>まずもって中身のサービスが素晴らしく、それをチャットUI(また、それが載っているプラットフォーム)をもってレバレッジかけるような感じ

私もこれは完全に同意です。

既存製品の新たなチャネルとして、そのUIがフィットするのであれば良いかなと思っています

ただ、チャットボットですという売り方では難しいと考えています

(実際チャットボットでこれから生きていくみたいなビジネス相談が多いのです。)



>ナゼに増田にとは思うが、社員ならしゃーないとも。

理解いただきありがとうございます立場上、実名発言が難しいのですが、この「チャットボットで俺は生きていく」層が多くそれに警鐘を鳴らしたい、鳴らさなければいけないと感じ増田に書きました。




LOHACOチャットボット人件費削減に成功

ネットメディアの導入事例系はマーケティング的な要素が強く、またあの記事人件費削減の根拠曖昧です。

サービス広報としては優秀だったと思いますが。




ユーザー側が求めてるサービスの質次第なんじゃないかな。未成熟技術分野だからこそ、提供者側が工夫すれば良いだけ。

工夫というのは同意です。

ただ現状、完全自由対話インタフェースを用意すると、ユーザー期待値サービスが超えることは無いと考えています

ある程度選択肢を絞らせる、スタンプを使うなど「工夫」がなければ難しいでしょう。

またその工夫でもこのインタフェースだけでビジネスとして成り立つかというと...我々は慎重に考えています



複数人が入っている部屋での稼動があると思うんだ。

アイデア面白いと思います

趣味Slack上で司会進行的に喋るBotを仲間内で開発しましたが、これは非常に面白かったです。

ただ、やはりビジネスとなり例えば1,000社が有料で導入するレベルのものかというと...



成功しそうなの教えて

そうですね、ポジティブな話もしないとですね。

個人的にはBIツール可能性がまだまだあると考えています

からあるものですが、どうもインタフェース特殊で事例が中小企業規模まで降りてこない。

Google Analyticsの焼き直しや、他の埋込み型トラッキングサービスも伸びています

コンシューマ向けだと、所謂CtoCにはまだ可能性があると思っています

炎上しましたが、個人の写真売買など「今までプロ提供してたけど素人でも提供できる、かつ流通量が多いもの」に可能性はあると思います




更に追記

うご覧になる方はほとんどいないと思いますが、最後の追記です。


予想以上の反響をいただいて驚いています

活用方法や実際の導入の声など、参考になるコメントもたくさんいただけて私自身も勉強になりました。

はてなの方から他のシリーズもやってくれとコメントを頂いたので、IoTやVRなど他のトレンドについての課題も今後「増田で」挙げていこうと思います



これらの意見をいただいても尚、ビジネス化をしていくには難しいだろうと私は考えています

それほど、私が挙げた3つの課題クリアしかビジネスとして回していくことは難しいからです。

そして、同時に未来はどうなるかわからんぞ」といった意見には賛同します。

Webアプリも「こんなもの流行るわけがない」という世論があった中で、ここまでの発展を遂げています



「若くチャレンジしようとする芽を潰すな」という意見もありましたが、そもそもこの意見を聞いて諦めるような起業家ではその先にある苦難に立ち向かえないでしょう。

もともと「チャットボットが新たなインタフェースになるんだ」と確信し強い気持ちを持っている起業家は、こんな意見を聞いても全く諦めようとはしません。


私も実際、起業前の方に「止めておいたほうが良い」と伝えたことは何回もありましたが、それでも彼らは起業サービスローンチしています

私自身もそうでした。みんなに反対される中、当時全く広まっていなかった人工知能系のベンチャーを立ち上げました。



勝手ながら彼らの信念がいつの日か実り、少しでも世の中に良い影響を与えられる存在になってほしいと思っています

VC的にはIPOか売却というゴールを期待してしまます(笑)



私が本当に警鐘を鳴らしたかったのは、どちらかというと「チャットボットが万能だ」、「チャットボットで何でもできるようになる」と伝えるメディアコンサルの方です。

口々にチャットボットだと言って誰にも使われないサービススタートアップを量産しようとしている話を聞くと心が痛みます

過度な期待をしたくなるのはわかりますが、私が挙げた3つの課題はどうしても避けては通れません。

起業家の方々が「周囲の過度な期待」に流されず、これらの課題から目を逸らさず、新しいインタフェース開拓してくださることを期待しています

上から目線のようですみません。ただ立場抜きにして1ユーザーサービス享受する1人の人間としても期待しています



最後

過激表現などを使ってしま申し訳ありませんでした。

多くの方にご覧いただきたいということもあり、こういった表現使用してしまいました。

特にけんすう氏にも良くない表現を使ってしまいました。申し訳ありませんでした。

ここにお詫びいたします。

2016-07-11

http://anond.hatelabo.jp/20160711184103

書き方わるかった

公式クライアントを使ってるツイッターユーザー初心者が多く

ベテランツイッター廃人公式は使わない(公式への不満と不具合過去経験上)

その場合公式で表示される絵がスマホPCで表示されなくなる

というかPCは高確率絵文字が潰れるので、公式アカウント絵文字を使うべきではない

2016-07-09

電車10分遅れる

約束した時間クライアントが1時間遅れる

・頼んだ食事20分経っても来ない

・頼んだ食事に毛が入っていた

・夜寝ようとした直後の隣の子供の夜泣き

満員電車に乗ってくるベビーカー

満員電車で泣く子供

・自宅付近で大声で喋る主婦ども

にキレないようになると大人だなって思える

2016-07-07

良く分かる「みずほ銀行デスマーチ

やあ、デスマーチってるかい

実はデスマーチ基準ってのがあって、7時間寝られるか。

なんと自宅に居る時間は5時間だけ?継続してたらデスマーチよ。

法律守って作業者が自宅に9時間いられるようにマネジメントするのがお仕事

(鎮火の初動は、終電まで働かせといて健康管理自己責任とか言う人の排除から

というわけで、みずほ銀行最近また話題になったので、振り返ってみよう。

銀行権力闘争根本原因

さて、みずほ銀行吸収合併は、こんな感じ。

で、記憶に新しい2011年東日本大震災システムトラブルの影響で、

システム刷新して再発防止するぜ!というのが2012年スタートの話。

みずほコーポレート銀行みずほ銀行吸収合併されて、

みずほコーポレート銀行みずほ銀行改名

はい、クソメンドクサイですね。

モメにモメるぜ銀行格式の話

しっかし、この合併って超ややこしくて

第一銀行が1873年(明治6年)創業

安田銀行1880年明治13年)創業

日本銀行1881年明治14年)創業

日本興業銀行1900年明治33年)創業

とか並べると、ウワー関わりたくね-って判るでしょ。



今のみずほ銀行は、旧みずほコーポレート銀行なので、旧富士銀行なのね。

法人格法律上会社人格)も、SWIFTコード世界的な銀行識別番号)も、旧富士銀行のを使ってる。

でも、日本国内で使う統一金融機関コードは、旧みずほ銀行で、旧第一勧業銀行で、旧第一銀行なのね。

なぜなら、旧第一銀行統一金融機関コードは0001で、旧富士銀行が0003だから

なんでマルチベンダーなのよ

ベンダーってのは企業システムを納入する業者だと思ってね。

銀行システムを納入すると継続的に儲かります保守とかで。

しかも、元みずほコーポレートたる興銀は企業向けメインで、元みずほ銀行は個人向けがメイン。

AKB宝塚歌劇団合併したみたいなもんスよ。そりゃ一歩も引かないわな。

自分とこのシステムが他行の軍門に下るのは承服しがたい。

という政治的決着を経て、

銀行としての本懐は第一勧銀の富士通

信託として信頼と実績の富士日本IBM

外向けに儲かってるところは興銀の日立

全銀システムはそもそも開発保守をずっとNTTデータがやってるんで、そこしかやるところがないという)

なぜデスマーチが終わらないのか

あのね、マルチベンダー地獄っていうのは、違うのよ。

全銀ネット使うなら、NTTデータ噛ませないのはありえない。

そして三菱東京UFJ銀行の開発はちゃんと終わりました。あそこも無茶やりました。

ポイントは、どの派閥が主導権を握って、有無を言わせないか

UFJ派閥抗争で完全に疲弊しきった所を、天下の三菱御三家東京三菱銀行が救済しました。

から、旧UFJ系(日立)は「実利で残した」という形で、東京三菱側(IBM)が完全にコントロールしてた。

主導権が完全に旧東京三菱側にあるので、旧UFJ(旧三和銀行)がなんか言っても鼻で笑われるレベルね。

まりクライアント(依頼主)側の命令系統キッチリしてるかどうかが全て。

結局みずほシステムって完成するの?

家を建てる時にさ、大工左官職人と配管職人ガラス屋と設備屋が居るから完成しないとか、無いでしょ。

それぞれの職人にそれぞれの指示をして、結果として一つの建物ができるのはそんなに珍しく無い。

(もちろんちゃんと連携しとかないと穴空いてないか換気扇付けられんとかあるんだけど)

から、誰かが主導権を握れば普通に完成するよ。

例えば、みずほ銀行の現頭取の林さんは富士銀行の人。

だもんで、日本IBMプロジェクトマネージャーに全権委任して、組み直せば終わるよ。

みずほ銀行内の揉め事は、全部林さんがOK/NG決めて、IBMPMが采配して進める。

要は、クライアント(依頼主)側の意思統一ができていないのが一番の問題

これは、ベンダーがーとか多重請負構造がーとか、そういう問題じゃない。

第一勧業銀行富士銀行日本興業銀行合併が終わってないのが問題

(外面の話じゃなくて、内部的に一つにまとまってるかってことね)



つうか、みずほ情報総研音頭取らないの謎だけどな。

自社もまともにできてないのにSIとか臍が茶を沸かすぜ。


追記その1

みんなコダワルねぇ。

ヤヤコシイということだけ判ればエエのに。

とするじゃろ

/*合併前の法人格リスト 第一勧業銀行, 富士銀行, 日本興業銀行*/

/*ここから2002年*/

社名変更(みずほ銀行, 吸収合併(吸収合併(第一勧業銀行, 会社分割(富士銀行, 富士リテール)), 吸収合併(新規設立(みずほ統合準備銀行), 会社分割(日本興業銀行, 興銀リテール))))

社名変更(みずほコーポレート銀行, 吸収合併(富士銀行, 日本興業銀行))

/*ここから2013年*/

社名変更(みずほ銀行, 吸収合併(みずほコーポレート銀行, みずほ銀行))


追記その2

第一勧業銀行第一銀行から来てることは知らなくて良いなんてコメントは甘い甘い。

日本では古いほうがエライ。それは実にシンプル帰属意識や誇りに結びつく。

今をときめく日本銀行よりも第一銀行(第一国立銀行)の方がエライのよ。

まり第一勧銀の方が富士よりも格が上だと思ってたりする。


んで、明治創業の三行がプライドを漲らせたママ

  1. 一般人相手預金業務を第一勧銀の富士通システムにする
  2. 企業相手の貸付業務を興銀の日立システムにする
  3. 信託業務は富士日本IBMシステムにする
  4. 信管理とか項目名どうする?
  5. 合併元それぞれの銀行マンがそれぞれのシステム担当者に違うこと言う

よしもと新喜劇AKB宝塚歌劇団合併したみたいな話に例えると

「この衣装リストはどう管理しますか?」

衣装衣装で良いだろ」

「じゃあそれで」

「おい衣装セットリストは揃えるのが常識だろ」

レビュー衣装は別で管理が良いな」

「えぇ……」

小道具って衣装とセットにしますか?」

「しないだろJK」「含めるに決まってるだろ?」「千秋楽だけ生花衣装扱いで」

「えぇ……」

「どうかな?公演の日取りは決まってるけど」

「「「おおむね順調です!」」」

(オマエラマジいいかげんにしろよ)

追記その3

はいはい結論だけ読みたい人ようこそ。産業

(三行で正確に知りたいってのは業腹ってもんだ)

期日があるし作り出してから摺合せとか、そりゃ炎上せずにはいられない(相川七瀬感)

2016-07-06

コンピュータ言語言語ごとの特徴を俺が教えてやる(異論は認める

コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある(特徴のない言語は廃れていく)。

まり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。

なお、取り上げるのはある程度広く使われている言語に限りたいと思う。

TL;DR

言語 概要
C言語 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグやす
C++ マニアック言語、高速、習得大変
Java サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる
C# 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語
Perl 広く使われていたが今は若干時代遅れのスプリクト言語。汚い
Python Perlにかわって主流になりつつあるスクリプト言語。綺麗
PHP Web開発にフォーカスされたスクリプト言語一世を風靡した。
Ruby とても綺麗なスクリプト言語
JavaScript ブラウザで実行出来る唯一の言語言語自体はいまいちだが、ブラウザ事情需要あり
Go サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語

詳細

C言語

メモリに直接アクセスして書き換えるといったコンピュータ機械語に近い言語構文を持つため、高速な処理が可能言語

コンパイラ歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語

一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディング効率が良くなく、多種多様バグを生みやすい側面も持つ。

ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。

C++

C言語オブジェクト指向を導入した言語C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。

C言語の速度を維持したままオブジェクト指向テンプレートなどの効率的記述可能にしようとした意気は真っ当だったのだが、

当時最先端だった色々な技術思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。

C++理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。

速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。

Java

サーバサイドで安全コードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。

当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリ解放忘れというバグを生まず、

サーバサイドなどで何千時間動作するソフトウェアに適した言語として受け入れられた。

必然的エンタープライズ用途で利用されることが多く、各種ツールなども豊富人海戦術がしやす言語という側面も出てきた。

一方でブラウザHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。

ガラケーアプリや(ちょっと違うが)Androidなど、クライアントサイドでも使われることがある。

プログラミング言語最初Javaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。

C#

クライアントサイドで安全コードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。

元々はWindowsクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。

マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。

Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。

自作ゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。

Perl

ほぼ全てのLinuxディストリビューションに含まれており、ツールや様々な用途で使われていた。

上に紹介したC、C++JavaC#のようなコンパイル言語とは違い、(少し語弊はあるが)1行ずつ実行してエラーがあれば止まるスクリプト言語である

ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である

20年近く前にWebCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。

しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存コードもどんどん別の言語に置き換えられていることが多い。

日本大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。

Python

後発のスプリクト言語。こちらもほぼ全てのLinuxディストリビューションに含まれており、それゆえに広く使われている。

インデントまで言語仕様規定することで、誰が書いても読みやすコードになるように考えられている言語である

Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。

ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。

最近だとマシンラーニング系のライブラリPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。

最初に覚える言語としては良い選択肢だろう。

PHP

Web開発に特化したスクリプト言語CGIの代わりに使われ始め、一世を風靡した。

以前CGIWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。

またphp.net豊富ドキュメントスニペットのおかげもあり、開発初期の効率が大変に良い言語である

残念なことに、言語API設計がいけていない点が多く、一部の人から蛇蝎の如く嫌われている。

今でも根強い人気があり、海外でも小規模プロジェクト最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。

Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。

なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。

Ruby

綺麗なスクリプト言語日本発で世界的に普及している数少ないIT技術の一つ。

言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWebフレームワークの登場で、Webアプリでの採用例も一気に増えている。

基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである

スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語

サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。

一方で、なぜかRuby採用するWeb側のフレームワーク(具体的にはprototype.jsCoffeeScriptはいつもクソなので、そちらは深入りしないのが吉。

JavaScript

ブラウザで動くスプリクト言語ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語

言語としてはプロトタイプベースオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。

言語仕様イマイチで、大変バグを生みやす言語であり、また関数スタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが

ブラウザで動く言語現在これしかないので、大きなシェアを持っている。

一部の物好きがサーバサイドでこの言語を使おうと(主にnode.jsで)四苦八苦している(とはいえ、1つの言語Webサーバが完結するのは大きなメリットだ)。

ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。

まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。

Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である

最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsサーバサイドもできるしで、意外とオススメだったりする。

GO

C、C++Javaと同じでコンパイル言語サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語

その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。

それ以外の目的ではあまりこの言語採用するメリットはないが、ニッチ用途ピンポイントで抑えており、これから広く利用されることも期待される。

コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである

まとめ

繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。

ここに挙げた言語は何らかの特徴があり、何らかの用途必要なので生き残っている。

その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。

2016-07-05

非邑社会型のオンラインRPGはまだか

現在オンラインRPGは、ユーザーユニークデータサーバー毎に管理する為、基本的データ登録したサーバーの内部でだけプレイ可能な邑社会システムである

世界中の誰とでも共闘できるとかいううたい文句クライアントアプリ提供されるが、上記のサーバの縛りが適用されるため、実際は同一言語で同一地域ユーザ以外はほとんどアクセスすることはない。

私がプレイしたゲームだとだいたい日本人20歳40歳程度の野郎ばっかりで、女子とかなにそれお前が担当しろよって感じありました。



この状況を打破し、邑社会から外の社会サーバとの縦横無尽の移動を可能にするには、ユーザーデータサービス提供側がサーバで一元管理するのではなく、ユーザーPCまりクライアント側の方に置き、ユーザーデータのものアクセスキーにして世界各国のどのサーバにでも接続できるようにシステムを組むべきなのだと思うのよ。

この形式にすればずっとアクセスしていない単に登録だけしたユーザデータサーバの肥やしとなり、サーバ登録上限を逼迫する原因になることもない。

興味を失ったり、リアルで死亡するなどしてアクセス不可能になった人物のデータはそもそも淘汰されていき、その管理を行うのはサーバ側の人間ではなくてユーザー自身である



問題点になるのはユーザデータ改ざんだ。

はてさて。

Digital Analyzer Zeroかいブログの「イラスト作成依頼の難しさ」の記事

消される前に読めて本当に良かった。

こんな「自分絶対に正しい」と思って疑わないクソのクソ記事、そうそう読めるもんじゃない。

クライアント奴隷

今月の初笑いありがとう

2016-07-01

アドレス帳登録している人にだけ自動返信したい

1週間くらい休むことになったので、アドレス帳登録している人にだけ自動返信がしたい

使っているメールクライアントthunderbirdアドレスは自前のレンタルサーバドメインで発行している

なんかググっても来たメール全てに自動返信する方法ばっか引っかかるけどないのかなあ

2016-06-25

Instagram広告

ナイキとかUNIQLOとかメルカリかいうやつの広告がちょいちょい挿入されるのはまぁいいかと思っていた。

でもなメチャコミ(はてなだったら許容できる)だけは無理だわ…。伊勢丹Tポイントカード導入したくらいの嫌さ。せめて元のイメージに合うクライアントにしてほしい。それが難しいならイメージにそぐう広告を作ってほしい。電車の中で見たいのに見るのが憚れる感じ。tumblrotsuneさんをフォローしていた頃を思い出した

2016-06-24

無能の人

私の言葉をさえぎって注意してくる人がすごく多い。



私「クライアントが◯◯と言ったので…」

A「それは■■って答えなきゃだめだよ」

私「ええ、■■って答えましたよ」



いつもこれ。

ちゃんと対応してるのに、無能の人あつかい

いろんな人にこれされる。

何がいけないんだろうか。



私が「できない人」っていう前提が相手の中にあるからかな。

地味にしんどいわ。

2016-06-21

未練

https://twitter.com/miraihack/status/745059267535765504

ストーキングにならずに静かに待つ。

忍耐力が試されるけれど、これも自分の試練だろう。

ヒロイズム自己陶酔したりはしないが、まだ人を信じることは出来た。



https://twitter.com/miraihack/status/745068110076510209

ちなみにいま周期的に生理前でして、以前私の交友関係について

PMSの苦しさを男はしょせん理解しきれないだろうと思う - 接客業はつらいよ!のように書かれたことがありまして、

生理前が落ち着くと状況も少し変わってくると信じている自分がいます



https://twitter.com/miraihack/status/745095191313276928

いま病院で待合中。私の友人や知人の約10人くらいほぼ全員に、

私は断捨離されたのでこれ以上深追いしたり待ったりするのを諦めて別な女性仕事に没頭した方が良いと勧められましたw

帰宅してから少し寝て頭を冷やして考えるようにします⊂二二二( ^ω^)二⊃



https://twitter.com/miraihack/status/745102212133621760

でも今の時期に私を断捨離して良いんだろうか。

ピルを飲んでいたしお互いにできちゃった結婚に流れ込むのがいい」という話になっていたので特に何もアレだったのだけど、

飲み忘れは無くて生理前になったのかな。

妊娠したら喜んで責任をとるつもりでいたけどその点が心配。もちろんその時は認知する。



https://twitter.com/miraihack/status/745104430018617344

何の連絡もないから連絡が来たら考えるか。

「お互いの安心のためにお互いに検査を受けよう」という話もまだ実現されていないけれど…。

3か月あったので何かの病気であっても既にという状態

「その時はうつされても良い」と言われていたけど、私の検査を待たなくて良いのだろうか。



https://twitter.com/miraihack/status/745135575112421376

実は今日相馬実家一時帰宅する日だった。

「来月から交際している女性と一緒に東京暮らします」という話を持ち帰る予定だったけど、

蜃気楼のように消えてしまったのと昨日までの疲れがあったので、土曜日に延期させてもらった。



https://twitter.com/miraihack/status/745143023252561920

ごめんなさい、誘惑に負けて元彼女電話してしまいましたw 

「お留守番サービス接続します」だったので、

留守電「色々迷惑掛けてゴメンね。生理の方ちゃんと来ているかな?来ていなかったら連絡ください」

伝言を入れてしまった寝る直前のお昼。



https://twitter.com/miraihack/status/745154505302409216

ます。いつも寝元には彼女から「今からそっちに向かうねー!」

電話が掛かってくるかもしれないとスマホを横に置いて寝ています

そういう時に起こしてくれるのはクライアントおっさんだったりしますがw

2016-06-20

全てのCOBOLエンジニアはだいたい糞である

この記事を読んだ。

http://anond.hatelabo.jp/20160619185731


COBOLエンジニア、現Rubyエンジニアとして増田記事がどうしても許せなかったので反応してみる。

この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。

汎用系の現場でもRuby現場でも優秀な人はたくさんいたし。


今では信じられないほどの経験を当時(といっても2年前)はしていた。

改めて今、RubyというかRailsを始めてよかったなーと思う。

そこで僕が経験した糞だった現場をご紹介したい。

(もちろん業界特有ということもあると思うが)


インデントは定規で計る

いやー、これが一番ひどかったな。

まず静的デバッグ(机上デバッグ)といってコンペアファイルソースコードコンパイルログをそれぞれ紙出しして提出用(クライアント)、リーダー上司用の3部印刷する。

全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。

1セットあたり印刷に15分くらいかかったかな。


そしてインデントレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。

媒体のインデントをどうチェックするかって?

定規で計るんだよ。半角スペースが5ミリだったっけな。

それで5ミリずれてたら指摘するんだよ。目がつかれたよね。

っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。



ログを紙出ししてマーカー塗る専属社員がいた

これもびっくりだよね。

専属社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。

ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。

大卒の、しかも僕より先輩の社員たちだったな。

そんな人達サービス残業しているのを見て悲しくなったよね。


ネットは使えない。リファレンスは紙媒体(常に貸出中)

これはクライアント金融特有なんだと思う。

ネットは使えない。現場に入る時も持ち物チェックとかあるしな。

リファレンスは紙媒体だったよ。

でもセキュリティ観点からマスターの1冊のみ。

常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。



まだまだあるんだけど、これだけでもひどい現場だったなーって思う。

そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。

最後の方レビュー適当なって品質下がってバグ生んでたし。

Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。

それでも、やっぱりRubyのほうが未来があるよ。

この先もっともっとブラックボックスフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。

認めたくない気持ちはわかるけど、時代エンジニアも合わせていかなくちゃいけないんじゃないかな。