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

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

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が主流になるかもしれない。

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

Photoshopファイルを納品したらレイヤーのいくつかにクライアント悪口があって指摘されて

あれ俺いつこんなの書いてしまってたんだろう・・・っていうオカルト話は意外と多い

2016-06-19

ソシャゲの片隅で

ソシャゲの片隅で。ホントウソかの判断貴方におまかせ(笑)

ソシャゲ宣伝にとてもお金がかかる

 目立とうとおもうと、ソシャゲ大作の開発費と同レベルお金が飛んでいく。ゲームの出来が良ければ宣伝に金かけるだけの価値があるが、良くなければ只の悪夢。でも、宣伝しなかったらどんなに良いゲームでも人の目に触れず、開発費用回収すら困難になる。

ソシャゲは金払う人はほんの一部

  そもそも金払ってくれる人はそのゲームDLしてくれたユーザの数%。ただ、この人たちの異常な金の払いっぷりで、全運用費用運用スタッフ宣伝費、インフラ代金、開発費用借金全部を余裕で返済できるだけのお金が集まる。このあたりがほんとに異常。こみ隊長がいうようなガチャ規制入ったら、ほぼ全員(トップセールス10常連ですら)思うように金稼げなくなって一気にソシャゲ業界終わる。

宣伝リリース完璧でも...

 宣伝タイミングが事前実施リリース実施でとにかく金ぶち込みまくって理想的にやれたとして、初動1週間の1日あたりのプレイユーザ数を上回ることが出来るゲームはきわめてまれ(正直居ないかもと思わざるを得ないレベル。)スマホの上位5位ぐらいのトップレベルセールス常連らの1日あたりのユーザ数は、まあ業界的に今後二度と起きないと思った方がいいレベル奇跡

大作レベル資金を渡しても、資金にみあったクオリティソシャゲをちゃんと作れる会社まれ

 とても多くのデベロッパが十分な資金時間を渡しても、正直詐欺といわれても仕方がないレベル成果物しか出せない。なので、大作のソシャゲ開発はとてもリスクが高い。リスク要因考えるだけでも、サーバ技術ダメクライアントアプリ技術ダメ音楽・サウンド・挿入アニメダメグラフィックダメPM/ディレクションダメ会社ダメ(笑)等など、ダメになる要因洗うだけでも、沢山ある。まあ当たり前の話、自分で全部ちゃんと出来るなら、その会社自力ソシャゲ出して只のデベロッパからはすでに脱却してるはずだから当然といえば当然。胴元というのは、いつの時代でも、有利で儲かる立場なんで、誰でも胴元になりたいよね?

RPGしか正直金にならないか

 今の所、RPGは、ユーザらがゲーム中でソコソコわかりやす継続的に何か作業がやれる上に、ゲーム運用側も作業量収入バランスやすいから。なので、結局ソシャゲ業界RPGばかりになる。なお、ユーザのやれることいっきに増やそうとして、いわゆるMOオープンワールド系のゲームにしちゃうのは、相当にゲーム設計運用ノウハウがないと無理。オープンワールド系は運用ノウハウが無いと、ユーザがすぐに何していいかからなくなるので、結局ビジネス面で詰む。

マルチユーザの対戦なんて

 ソシャゲ運用から見ると、マルチユーザの対戦の機能なんて、正直、肉料理についてくる前菜サラダぐらいの価値しかない。無いとソシャゲの見栄えが寂しい一方で、開発は技術的に難易度無駄に高い上に、1日に遊ぶ全ユーザの2〜3割ぐらいしか遊んでくれない。しかゲームのメインにしようものなら速攻ユーザが逃げる。この場合悲惨で、残ったユーザガチ勢ばかりになって益々初心者入ってこなくなるわ、結局ガチ勢もいつも同じ面子ばかりと対戦になり正直飽きて継続しないわで、たちまちゲームビジネスが詰む。実際ユーザの遊び方を計測しても、正直実はみんなシングルプレイで十分なんだろ?と思う行動ばかりのご様子。正直頭痛い。ただ、ある程度のマルチユーザの対戦機能があると、新規ユーザ獲得に役立つ(プレイヤー友達誘う正当な口実になる)気がするのと、高課金者らが継続的に金を突っ込む為の理由の1つにできるかもしれず。また、対戦を口実に運営施策が入れやす場合があり、結果、ゲームの盛り上げ感を出しやすいかもね。ゲーム運用からは、費用対効果の面では、無いと寂しいが、頑張ってみてもいいとこ無しという機能

1年程度で十分な利益を出せる状況にならなかったら閉じるしかない

 ちゃんと宣伝しているのにいまいち売れないまま1年もたっちゃうと、どう宣伝しようが、何しようが、ユーザほとんど反応しなくなる。同時に、ソシャゲ流行りも変わるので、結局詰む。こうなったら借金精算して、次行こ、次!

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

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を腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

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は今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

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は使うべきではありません。

Microsoft 離反

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 EE

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のシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を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の思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

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を学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-06-14

http://anond.hatelabo.jp/20160614230825

は?なんでわざわざクライアント用のlinuxOSの名前理由なんて調べなきゃなんないんですか?

そもそも何が言いたいのかよく分からない。

もっとはっきり書いてくれる?何が言いたいのか分からない

何をどう調べてないの?

コミュニケーションってそういうもんでしょ?

2016-06-12

http://anond.hatelabo.jp/20160612112533

・隣の「まとめ役」より偉い人がいれば、その人をターゲット

 (最終的に、まとめ役の上席に伝わるように、その前の順番(社内の序列人間関係)を間違えずに)共感を積み重ねる、根回しを積み上げる。

 で、異動なりなんなりをお願いする

・被パワハラさんのお友達になってやる

自分が、別の場所パワハラ声が聞こえない部署など)に異動を申し出る

会社をやめる



ぐらいかな。

音声の証拠を集めたところで使う場所がなきゃ意味がない。

それに、録音するのなら、被パワハラさんへの同意も得るべきなので、単なる正義自己満足しかないと思う

クライアントを、社内のみっともない事情に巻きこむのは、みっともないからやめた方がいい。マジで

へたしたら会社の信用度にかかわる。



残念だけど、増田には、今のところはまだ、この問題解決する能力はないのかも。

諦めるか、逃げるか、踏ん張って社内政治をやって解決させるか。お好きな道をどうぞ。

プロカメラマンレタッチ写真現像と加工について

http://b.hatena.ne.jp/entry/s/medium.com/mediumjp/2b0da4969e65

ここのブコメを見て危機感を覚えたのでちょっと書く。

だいたいはここらへんのコメント

id:koiz アメリカでは、光を思いっきり入れたクリエイティブが求められることが多い(特に西海岸だし、スイムウェアは)。自分センスで左の方がいい!この写真家はクソ!ってなる人がrawデータを貰いたがるタイプなのだと予想

id:Memeo このレタッチ写真屋が勝手にやったんじゃなくて用途デザイン案に従って仕上げたもんなんじゃない?/ カレー作って今からルー入れようって時に「もうそれでいいから食わせろ」と言われても困るだろう。

で言い表されてると思ったんだけど、スターを集めてるブコメでは誤解が解けてないようなので。

まず、カメラマン仕事理解していないひとが多い。カメラマン写真家と違って、クライアント要求にあった写真を撮るのが仕事なんだよね。「フレアがわざとらしい」とか「レタッチ前の写真のほうが好き」と言っている人は、カメラマンじゃなくてクライアントセンス文句をつけている。

次に、本文でも親切に「レタッチを前提として撮っている」と書いてあるように、レタッチは下手な写真ごまかす手段としてではなく、クライアントの望む理想的写真を作り出す手段として使っている。「RAW現像を前提としてあえて暗めに撮っておき、現像時に明るくすることで暗部の階調を残す」というようなテクニック常套手段。なのでレタッチ前の写真が下手という指摘は外れているし、そういう誤解があるからこそ元データを納品したくないんだよ。

記事カメラマン立場からRAWデータを渡せない理由説明し、それでもクライアント不利益が少ないことを説明して理解を求める内容。「RAWデータは作りかけのもの自分名前で世に出したくはない」「そのことでクライアント不利益が生じないようきっちりと仕事をしているので、理解してほしい」「しかカメラマン側も事前に契約を詰めるなどの取り組みは必要」という流れ。その流れを踏まえてブコメを読むと、とんちんかんブコメがかなり多いことがわかる。

いわゆる写真の加工に対して、アレルギーを持った人が多いんだろうなと再認識させられた。身の回りにある写真ほとんどが加工済みだし、iPhoneで撮った写真でさえ元から強烈な補正がかかってる。ここまで写真が身近になった今だからこそ、写真現像レタッチについてカメラマンからも発信していかなければならないと思った。


以下コメントへの突っ込み

id:toksato 結局なんでレタッチ前の写真を渡さないのかよくわからなかった。

本文中に"レタッチが終わるまでは、自信を持って「自分作品です」とクレジットを付ける気にはなりません。"って書いてある。

ただ、元記事は「レタッチデータを渡したくない理由」「レタッチデータを渡す必要が無い理由」「同業カメラマンへの提言」がまぜこぜに書かれていて、主旨が読み取りづらいとは思う。

id:Akamemori お前それフィルムカメラでも同じ事言えんの?

ブコメで多数指摘されてるけど、銀塩時代も加工の技術はあった。現像プリントの段階で、色味やコントラストシャープネス、粒状性は変えられるし、覆い焼き部分的な明るさを変えることもできる。デジタルで幅が広がったのは確かだけど。

id:atoh 契約時にきちんと詰めろってだけの話だった。

id:aromabird 契約次第としか中間制作物も納品義務のある契約なら納めるし、無ければしない。別料金。ただそれだけ。

本文で"撮影の前には、契約が成立しています。""これは、プロカメラマンである以上、事前にしっかりと内容を詰める責任があります。"ときっちり書いてある。このコメントに星が集まってるのが理解不能なんだけど、みんな本文最後まで読んでないの?

id:nasuhiko レタッチっていうかほぼRAW現像の話だろこれ。翻訳者がわかってないのか、それらも含めて原文がレタッチって言ってるのか。プロでさえ1枚のベストショットの背後に何十何百という失敗ショットがあるのは同意

海外の"retouch"は現像も含めた写真の加工全体を指す。"no retouching"なら、撮影後いっさい手を加えていない写真のこと。

id:kazoo_oo 追記でぐだぐだと契約だなんだ言い訳してるけど、前段ではそのrawファイル自分より優れた現像者に出会可能性を潰すことの理由説明できてないよね。 </bockquote>

これは文章の読み取り方の問題自分よりも優れた現像者に出会可能性は潰しきれないが、カメラマン側の能力で相当小さくしている。カメラマンの被る不利益との天秤で、原則RAWデータを渡すことはできない。ただし信頼関係契約次第で対応することはできるというのが本文の論。

IT業界クライアントが「あとで使うから作ったソースコードや旧バージョン全部ちょうだい」って言ったら普通に断られると思うんだけど、それと同じ話。

id:jassmaz jpegだけ送られてきたらキレるわ。rawファイルもいらない。psd + pngを送るのが常識では?

psd+png常識というのには同意。その上で、クライアントが求めるものはまちまちなので、契約をしっかり詰めておきましょうというのが本文の内容。

id:oscdis765 これ右がレタッチ後なんだよね?左のが良いのが沢山あるんだけど

id:mfigure 上手けりゃ、原版渡せとは言われないでしょ。加工後の方が上手いといえない写真が多いんだけど、よく言うわ。

id:kantei3 思いあがっている。あと、左の方が良い写真が多いので、都合のよい例すら選べない低能なんだな、と。

id:paradisemaker いやー、商売が成立してるんならいいけど、元々のカメラの腕が良くないし、レタッチもそれほど上手くない。デジタル時代カメラマンって感じだなぁ。

この手のコメントが多いのが本当に悲惨使用イメージが頭にあるクライアントカメラマンと話しながら詰めた結果、右みたいなタイプ写真希望にあったというだけ。あなたたちがどっちがいいと思おうがまったく関係ない。仕事で右みたいな写真が好まれがちだからこそ、private workもそういう味付けにしてポートフォリオとして公開しているんだろう。

デジタル時代カメラマン」ってのがよくわからない。フイルム時代、大多数の人が見ていた写真は加工の入ったプリントと、よくて現像済みのネガぐらいで、RAWデータに相当する未現像ネガは見られなかったはずなんだけども。

id:zheyang う~ん、今でも撮影時に設定を絞り込んで、レタッチを最小限にしてる人もいるんじゃないか?/作例のレタッチフレア)がわざとらしくてCGくさい。この人の写真家としての腕がちょっと怪しい。

写真家カメラマンは違う。「写真道」でも極めるならともかく、クライアント希望に適う写真を納品するという立場において、レタッチ忌避する理由はどこにもない。最高の成果物を納品するためには、「撮影時に設定を絞り込んでレタッチを最小限にする」より「撮影時に設定を絞り込んだうえでレタッチで仕上げる」のほうが良いというだけ。フレアがわざとらしいとか、クライアントに言うべき。

id:xevra くだらんこだわりだ。写真家カメラマンは違う、カメラマンならとっとと出せ。単に現像スキルに自信がないってだけなんじゃないの? 面倒臭い奴に発注するのはやめたい。

5000枚の未選別データを欲しいならそうするけど、それには相互信頼関係必要だし、契約段階から要求しておいてほしいという話。

id:aceraceae いらないとこ白飛びさせるの好きな人なんだなってことがわかった。

この人の好みもあるかもしれないが、クライアント希望にもあっているからこそそれで納品されたんよ。あと向こうの雑誌広告ちょっと見ればわかるけど、こういう派手でやり過ぎっぽい写真はかなり好まれてる。

2016-06-10

http://anond.hatelabo.jp/20160610084553

2011年ガラケーのピークで

それからは高機能スマホシンプルガラケーという住み分けがなされるようになったために

新機種が出ても従来ほどの機能はないようになった

Wi-Fiテザリングクライアント対応PCサイト表示ができなきゃ話にならないとおもいスマホに変えたのが2年前