「勉強会」の記事 - Crieit

StudyCode #5 技術と好奇心参加メモ

2019-03-20T20:50:55+09:00

StudyCode #5 技術と好奇心参加メモ

法律はなぜITに冷たいのか

発表者：伊藤太一さん
本職は裁判官（法律に基づいて弁護士職務を経験中）

法律の二つの側面

「行為規範としての法律」「裁判規範としての法律」の2つの作用がある。

行為規範としての法律

法を犯すとペナルティがあるからやめておこうという、犯罪行為を抑制するための作用。
「将来」を向いた前向きな使い方。
一般の人がよく使うのはこっち。

裁判規範としての法律

犯罪行為の後、事後処理のツールとしての作用。
判決を介して強制執行可能。

「過去」を向いた後ろ向きな使い方。
捜査機関がよく使うのはこっち。

捜査機関の発想

客観的証拠から入る……が当たり前のように見えて、実は関係者外の人とは大きな認識のずれを生むことがある。

なぜそうなるのか

行為者の目線は主観→客観（行為規範としての見方）
捜査側からすると客観→主観（裁判規範としての見方）

客観から見ると言うこと

街中で銃を持っている人を観たら客観的に「危ない」と思う。（わかりやすい）

でもITは「悪意のあるマルウェア開発」と「善意のためのマルウェア開発」は見た目上は同じように見える。

「客観面」ってどうやって決めるの？？？
そこで出てくるのが「社会通念」。

Magic word "社会通念"

最近話題の「コンピュータの通常動作に対する一般人の期待」は？

Youtubeの広告はOK?
消えないバナーはOK?
CoinhiveはOK?
JavaScript imitationはOK??

ITは日進月歩の世界で線引きができない。

(例えばセキュリティ界隈の中だけでやる、などのような）Closedな環境であればあえてmaliciousなものを流すのはOK(同意があると考える）。

でもOpenな環境では……　→　「一般人の通念」を判断しないといけない
→　結局、裁判官が主観で決めるしかないんじゃないの？
　→　よくわからない

#### じゃあどうすればいのか
外形だけでは意図がわかりづらい。

客観→主観のアプローチを逆手にとるしかない
→　主観面を明示化するしかない。自分がどういう意図でやってるのか、をOpenにする

つまり「悪意がないことの明示」すればいい？
でもそれを明示するということは「開発者は危険性があるという認識を持っている」と見られてしまうかも。
→　決まった解は今ない
→　業界標準やルールを定めていくことに効果があるかも。

現状は主観面でしっかり守るしかない。
主観を客観化しておきたい。

政治はなぜ技術を潰すのか

発表者：坂井崇俊さん
山田太郎参議院議員の元公設秘書

政治家って思ったより人間くさい。
政界に入る前は「政治家はすごいブレーンから情報を聞いて冷静に判断していく人たち」思ってたが実は、自分達の支援者や秘書という狭い範囲内で見聞きして判断する。

技術と政治に関するニュース

Winny
Coinhive
ループプログラム補導事件

政治が技術を潰す例はいくつもある。

政治家の世界

Twitterの世界と永田町の世界は断絶している。

なにかイベントがあったとき、人を集める方法としてFAXを使うのが普通な世界。

政治家は、ばっさり言ってしまうと、「票」と「カネ」（＋信条）で動く人達。

法律ができるまでの流れ

省庁で法案骨子作成
審議会・調査会
パプリックコメント募集
法案作成
与党事前審査
国会審議
公布・施行

基本的に下にいけば下に行くほど変えにくくなる。

法律の運用方法

裁判
議員の働きかけ
世論

の三点をもとに「省庁の通達」がでて、現場での運用に落ちる。

警察の構造

警察は実は法律から遠いところにある。
警視庁・都道府県警は国会内閣→国家公安委員会→都道府県公安委員会を経て伝わる。
（立法の意図が伝わりにくい構造になってる）

圧力団体

票とカネをバックに（政治家を経由して）行政に働きかけ、政府から法律通達を出させる。
あまり良いイメージはないが、議員からすると国民からどれくらいのサポートが得られるかを図るための指標になる（民意を知ることができる）。

政治家にアプローチするには？

実は議員は国会で質問するためのネタを探している。
（自分のアピールポイントになるし、自分の信条に合えばそこまでハードルは高くない）

こんなテーマだと喜ばれる

タイミング性
- 法案審議のタイミング、省庁から報告書が上がったタイミング、事件が起きたタイミング
ニュース性があるか
- みんなニュースに出たい
- 国会で質問のための「パネルを持つ役」はすごい人気がある
支援してくれている人に喜ばれるか

政治家や官僚が新しい技術が嫌いな理由

何となく怪しいと思ってる
自分には関係ない
- ノリでサマータイムやっちゃおうみたいな人たち
事故・事件が起きたら責任を問われる
- 変えた結果何か起こったら責任が発生
既得権者が反対する
- エンジニアは票やカネに結びつかないと見られてる（票が可視化されてない）
議員は規制を作るのが仕事

日本とアメリカの法律の違い

日本は「やっていいこと」が書かれている
- （新しい技術が出たときに、書かれてないのでできない）
アメリカは「やってはいけないこと」が書かれている
- （新しい技術が出たときでも、書かれていないからできる）

提案

勉強会の分科会として小委員会を作ったらどうか。
- エンジニアの地位向上
- 技術的視点に立った法律問題の解決
- 技術者の立場から考える法律の課題・問題

議員会館って意外と簡単に勉強会を開ける（平日だけだけど）。
→　（FAXで）議員に勉強会の告知を出せば、議員や秘書が来てくれるかも

JavaScriptで人生が変わった話

発表者：松田光秀さん
フリーランスエンジニア

家出少年→とび職→高校入学→jQuery→起業→フリーランス。

23歳で高校に通ってjQueryにハマり、その後ひたすらバイトしながらオープンソースライブラリを思いついて起業。
その後、JavaScriptで自由視点映像を作って、その後お金に目が眩んでフリーランスへ。

今はHACKER'S JAILをやろうとしている。
→　エンジニアのための私塾。
HACKER'S JAIL

感想：問題が地味に面倒だった。（3問目とか）

今年スマホアプリを作ってプログラマーになった40代女性の話。

2018-12-17T05:35:42+09:00

約6年ぐらい前、「C言語がわかるならiPhoneアプリを作ればいい」と言われた時、私はMacを持っていませんでした。Macは憧れの対象ではありましたが高級品で、当時、職業訓練校に行っていた身としては買えると思っていなかったのです。（話が前後しましたが、その職業訓練校でC言語を習いました。）

去年（2017年）12月、私は4月から働いていた派遣をやめることにしました。そしてMacを買いました。Macを買うのに必要なのはお金だけではなく、思い切りでした。
何十年Macに憧れ続けて、このまま死ぬのか？死ぬまで憧れ続けて、買わないまま死ぬのか？

今買えるお金があるなら、買おう。

ちなみに、その頃までの私の主な職業はテストエンジニアでした。書くとしてもテストコードだけ。
専門学校は出ていないし、前述の職業訓練を受けるまでは学校で習ったこともありません。
プログラマーという職業もずっと憧れであり、なかなか手が届かないものでした。

そして今年（2018年）1月、iPhoneアプリ開発の入門書を手にして本の通りにやってみたところ、謎のエラーが出て、先に進めなくなりました。
モチベーションも低下して、どうしたものかと思っていた頃、若宮さんの話をTwitterで目にしました。

若宮さんは、80代でiPhoneアプリを作った、エンジニアではない女性です。
ものすごく勇気をもらえました。

私のアプリを作りたいという思いは死ぬまで消えないだろう。
死ぬまで、たとえ病の床にあったとしても「アプリ作りたかったなぁ・・・」と思い続けるだろう。
ならもういい加減、諦めるのをやめたらどうなんだ？

当たり前に開発をしている人から見たら、いちいち大げさかもしれませんが、
憧れが強すぎるあまり、「開発者」というものが、遠い遠い存在になっていたのです。

私を大好きなことから遠ざけていたものは「自分にはできない」という無力感と決めつけでした。
こんな程度の私には無理なんだ、そんなすごいことできるはずがない、
アプリ開発なんて、私よりもっとすごい、もっとできる人しかできないのだ。

そんな謎の思い込みを持っていました。

作るのは別になんでもよかったんです。
ただ、スマホアプリというのは小さい世界で完結できる。一人でも作れそうだったから。

そして諦めるのをやめた私は、
本の著者の掲示板に質問を送り、最初のエラーは解決し、
またわからなくなったらそこで質問し、
ドットインストールにも入会し、わからなかったら質問して、

わからないことはネットで検索しまくって、それでもわからなかったらまた後日検索して、
新しい本を何冊か買い、勇気をもらえるブログを読んでモチベーションを上げ、

アマゾンプライムで孤独のグルメをヘビロテしながら、
iOSアプリを3つ、春に完成させました。

友達が、私の作ったシンプルなゲームを気に入ってくれました。
どこの誰か知らない人たちが、私の作ったアプリを使って遊んでくれています。
毎日誰かがダウンロードしてくれている。
誰かのスマホで私の作ったアプリやゲームが動いている・・・。

一年前の自分にその未来を話したところで、信じなかったと思います。

それだけでもとても嬉しいことだったのですが、
私はずっとプログラミングしていたくて、そうするにはそれを職業にするのがてっとり早い。
でも体力ないので徹夜とか長時間は無理。のめり込むからやれるけど、多分それやると倒れる。
というわけで正社員募集してた会社に問い合わせて、パートで時短で、プログラマー採用してもらいました。

そして半年後にはパートも辞めてフリーになりました。
パートしてた会社から仕事もらえる予定です。

半年で独立するなよって言われるかもしれませんが、会社はOKしてくれたし、
毎日同じ会社に同じ時間に行くのってものすごく向いてないんです。

あともう一つ、IT勉強会にも憧れていて、仲間がほしくて、10月に開催してみました。
https://smartphoneapp.connpass.com/
そしたらものすごく楽しくて自分が満たされたので、12月にも開催して、
地方だし参加者も少ないですが、やっぱりとても楽しくて。謎に楽しい。

なのでこれからも続けていこうと思います。

自分が思っていたよりも、世界はとても優しかったです。
やりたいことをやりたい！といったら、協力してくれるし、叶えてくれる。
こんな私でも、一番好きで叶えたかったことを叶えられました。

いちばん自分に厳しくきつい言葉をかけていたのは自分自身でした。
世界は優しい。Twitterも優しい。いいねもシェアもひとつひとつに感動しています。

読んでいただきありがとうございました！

面白法人カヤックに学ぶUIとは関係ないUXの話 Osaka Mix Leap Study #26

2018-10-22T07:14:52+09:00

最近UXといえばUIをどうするかみたいなイメージがすぐ湧いてしまいますが、UXはあくまでユーザー体験の事であり、UIが全てではありません。Osaka Mix Leap Studyにて、面白法人カヤックのデザイナー岩瀬さんが面白く、ためになるお話をしてくださいました。

今回は「ぼくらの甲子園！ポケット」というスマホゲームで実際にやっている例をもとにしたお話です。

ぼくらの甲子園！ポケットとは？

ぼくらの甲子園！ポケットというゲームは2014年9月にリリースされたゲームです。

スマホの野球ゲームは自分が監督になり理想のチームを作る、というものが多いのですが、このゲームは複数のプレイヤーがチームを組んで他のチームと戦う、という一風変わった形のゲームです。

このゲームのUXとは

UXというのは本来は User Experience つまりユーザー体験ですが、このゲームの開発陣は「友情エクスペリエンス」と呼んでいるとのことです。

このゲームはユーザーに提供したいものが他のゲームと異なり、「友情体験」を提供したい、というゲームとのことです。ゲームの中で他の誰かと繋がる機会があり、その人達のために何かをしてあげたり、また一緒に遊びたいと思えること、そういった事を重要視しています。また、仕様を決めるときもいかに友情体験を生み出せるか、というところを優先して決めていくそうです。

「甲子園」というのは世の中的に誰でも共通認識があり、高校球児になりきりやすく、重要な体験が生まれやすいとのことです。スポーツゲームというよりは、「高校球児RPG」だそうです。

具体的にどういった体験によりゲームを良いものにしているのかを紹介していきます。

友情エピソード

ユーザーが体験したことを投稿できる機能がゲーム内にあるとのことです。その投稿数は現在4,000件ほど。冊子にして配布したこと等もあったようです。

例えばこのゲームは9人の仲間を見つけないと試合をすることができません。ゲームに登録してもそこまでは何も遊ぶことができないのです…。すごい話ですが、「まさに弱小野球部のドラマ」と言われていました。それに関連して下記のような友情エピソードがありました。

ぼくポケをはじめて２年になりますが、最初は試合にも出られませんでした。
試合に出られたのは３ヶ月後のこと。

しかし全く歯が立たない。
それでも諦めずに頑張っていき、だんだんとチームメンバーとの結束も強くなっていきました。
そして遂に１年で甲子園常連校にまで成長しました。

最初にチームになった部員も誰ひとり欠けることなく現在もチームメイトです。
ありがとうございました。これからもがんばっていきたいです。

仲間と一緒に頑張った体験、それ自体がユーザーにとって素晴らしいものなんですね。たしかにこれこそ本当の意味でのUXという気がしてきます。よくよく考えるとUXはUXであり必ずしもUIとは関係がないものなんですよね。

面白いのは、このあと説明する仕様を読んでから前述のエピソードを読むと更にすごみが増す、というところです。なかなかこのゲームは一筋縄では測れないゲームでした。

ゲームの仕様が過酷

なんとこのゲームは１日４回、決められた時刻に試合をしに行かなければならないそうです。そのため試合をサボったりするとチームメンバーに怒られます。つまり甲子園常連校ということはおそらくほとんど全ての試合に出ているということなんですよね…かなり大変そうです。

実際に、既婚者中心のチームがあったようで、家庭の事情からみんなあまり時間が取れず、妻のいないところでこそこそとプレイして、見つかりそうになったらいきなり「妻が来た、落ちます」とだけチャットを残して退散していなくなる、みたいな事があるようです。そしてチームメイトも明日は我が身と戦々恐々。

遊園地にいって空いている時間で参戦したり、奥さんと喧嘩中に参戦したり。すごいのはそんなこんなで初優勝まで行けたということ。これは確かに友情エピソード投稿をしたくなる気がします。

他にも、手術台の上でやってくれた人もいたそうです。お医者さんも「手術台の上でゲームをしていいか」なんてはじめて聞かれたと言っていたそうです。

友情体験のためならなんでも作る

ある日プランナーが「野球じゃなくてもいいんじゃない？」といったことで、野球以外のイベントも色々と追加されることになったようです。

釣り
ダンジョンでドラゴン討伐
マネージャーと自転車で帰るチャリ走系

等

どれも野球ではないですが、仲間と一緒にいる気持ちで遊べるように、という部分などは一貫して作られていました。ユーザーに提供したい体験(UX)を純粋に追求して作っているそうです。

みんなが集まる場所をつくる

WebデザインのUI/UXといえば操作性にこだわることでユーザーの体験を良くしていくというところですが、あくまで友情体験を高めることが重要なため、１画面で操作しやすく、というよりは２画面になってでも高校野球の雰囲気を出せる画面にして、没入感を高めるような演出を増やすことを重視しているそうです。例えば教室、グラウンド、喫茶店など。

皆で集まり、待ち合わせるという体験そのものに喜びがあるため、その世界にいられることが感じられるように記念写真のようなアングルを意識した画面デザインを設計したりしています。

甲子園新聞

甲子園新聞というのはこのゲームの最高報酬です。甲子園で優勝したチームだけに送られるものです。

この甲子園新聞の驚くべきところは、全部フォトショップにより手作りされているというところです。しかも、ユーザーが要望すると運営がなんとなくそれっぽく対応してくれるということで、だんだんとユーザーの要望がエスカレートしてしまい、今ではかなりの要望が増えて来ています。

今ではもうテニスやファンタジーの背景にしてほしいだったり、ユーザーのアバターすらもう全然違うものにしてほしいという要望だったりで、野球とは関係なくなるレベルで様々な要望が来るとのこと。

ユーザーのチャットで色々と要望の発言があるので、それをスプレッドシートにメモして、関係ありそうなものを抽出してまとめる、という感じでめちゃくちゃ大変とのことでした。

しかも優勝が決まるペースが２週間に１回のため、そのスパンで作成されているとのこと…。大変すぎます。

しかも優勝後は他のチームに移ってしまうユーザーもいるため、解散する前になんとか翌日には新聞を出したい、という感じで命がけでやっているそうです。（昔はもうちょっと早く出していたけどさすがに無理になってきたとのこと）

「人の心を動かすには手をかけるしかない」という事を言われていました。

ぼくポケ会議

運営とユーザーが集まって色々とブレストを行う会議が時々開催されているそうです。言うならば運営とユーザーの友情。

スマホゲームをやっていると結構厳しい意見も多いのですが、そういう意見を言うユーザーを場に呼んだらどうなるだろう、と思い招いてみたところとても良い方で、ゲームに対して思い入れを持っているからこそ厳しい意見が出てくるという事がわかった、というエピソードがあったそうです。

たしかにユーザーからしても「なんで運営は分かってくれないんだ」というようないらだちって結構多そうですよね。実際に意思疎通をしてわかりあえるということもよくあることですので、非常に有用そうに思いました。

他にも

・アバター入いの名札つくった
・トレーディングカードみたいにした
・キラカードを入れた（キラシールを貼るのが非常に大変だった）
・過去甲子園新聞を全部展示した

等をぼくポケ会議の際にやったりしているようです。

UXについてのまとめ

このように、本当の意味でのユーザー体験を高めるための工夫を必死でされている様子が伺えました。もしUXといえばUI、という固定概念を持ってしまっている方がいれば、一度このあたりの意味を見直してみると良いかもしれません。

僕自身も色々とサービスを作るため普段からUXについて考えることは多いですが、まずUIどうするか、みたいなところから考えている事がほとんどだったため、今回はかなり色々と考えさせられました。

質疑応答

あとは質疑応答があったためそのあたりをまとめておきます。

面白いことのビジネスのギャップの埋め方

面白いことをしたいという気持ちと、ビジネス上やらなければならないことというのは必ずしも一致することではないため、このギャップを埋めるためにどうしているのか、という質問でした。

そもそもカヤックに依頼が来る場合、その時点である程度面白いことを期待されているので、普通に作るよりは最初から面白いことを考えながら仕事ができる、とのことでした。そういうイメージを持たれる、ということ自体が役得ですね。

1日４回の試合は大変すぎるので開発時に否定する人はいなかったか？

正直この仕様は離脱も多いと思いますが、その分熱中してくれるユーザーが残って盛り上げてくれているのでは、ということでした。

このゲームは2014年頃にリリースされたもので、さらに前身のゲームがそもそもありました。そのあたりはまだ今のようにスマホゲーといったらこんな感じ、みたいな固定概念がなく、各社色々と試してやっているような時代だったため、割と開発時にもユーザー側にもこのルールが受け入れられやすかったとのことです。

そのため今この仕様のゲームを作ると厳しいのでは、とのことでした。

甲子園新聞のコストとリターンはつりあうか？

全く釣り合いません。ある意味度外視でやっているとのことでした。

デザイナーはその日それしかできませんし、社内のリソース管理も今はそれで調整するようになっているようです。

UXの熱量の共有のしかた

プロジェクトに入ったときに説明します。説明してあげないとあとでしんどくなるとのことですがたしかに絶対そうだと思います。知らないで任されたら辛そうですね…。

改修の要望等については、優先的になおすのはみんなが楽しめるものになってるのかな？　というところです。

例えばボスのとどめ報酬を作ったことがあったのですが、誰がトドメをさすかでもめるイベントつくってしまったこともあったそうですので、そういうのは止めたそうです。

新聞で仕事が増えるからやめようというメンバーはいなかった？

今も思ってると思うとのことです。でも甲子園新聞は最高報酬であり必要なものなので、なぜやることにしたのかをちゃんと共有しないといけません。結構議論もしましたし、岩瀬さん自身もも言ったことがあるそうです。これ以上は無理だ、という話を投げかけましたが、色々と話をして最終的にやろうということになった、ということです。

ゲーム、Web、アプリのUIで共通して意識してること

目的を考えることです。例えばこの画面ではこのボタンを押させる、など。その目的のためにどういったUIにするか。

どれが一番重要か、不明瞭だったらディレクターと話すします。

ゲームはセオリー通りじゃなかったりします。セオリーだけで楽しむのが全てじゃない部分があります。アプリもWebと同様セオリーがあったりします。

情報系学生がUI/UXデザイナーになるために必要なこと

UI/UXについては職業の垣根がなくなってるので興味のある職業を選択すると良い
最新のUIパターンを集めるとセオリーがみえてくる
ゲームだとその上に楽しさが加わって面白い
必ずしもUIデザインが必要というわけではない

カヤックのアンテナにひっかかる面白い人とは

何かを作る人。

「つくっていいとも」という社内イベントがあったりする。ほっといてもみんななにか作ってます。

ふざけすぎないラインとかある？

上場企業なのでソーシャルグッドは意識。
それなのにポケットフレンズコンチというのを作ってしまった。他にも色々。

多様性を大事にしてるのでルールがない。面白さをを定義しない（定義すると何かが失われてしまう）

まとめ

全体的に面白く、ためになる話でした。開始と終了時、急に近くの人と何か話してみてください、と言われて３分ほど話をする時間を与えられたり、ということもありました。焦りましたがそれはそれで面白かったです。カヤックはブレストを重視しているようなので色々とそのあたりも取り入れての内容でした。

ヤフーさんの開催しているOsaka Mix Leapは中々面白いものが多いので是非色々と見てみてください。

今回のイベントは下記でした。

Osaka Mix Leap Study #26 - カヤックに学ぶ面白UX論

Osaka Mix Leap Joint #16 - 制作物天下一武道会に参加してきた

2018-09-28T21:30:49+09:00

9/27に開催されたOsaka Mix Leap Joint #16 - 制作物天下一武道会に、発表者枠で参加してきました。下記のようなイベントです。

本業/本職とは別にチャレンジして作った制作物・デモ機などを、惜しげもなく「どやっ！！」と披露していただく会です！ハッカソンやアイディアソンでの成果物、テスト機や製品でもジャンルはなんでもOK、下記の＜参加条件＞に合う方であれば、どなたでも結構です。展示スペース＋90秒LTで、爆速披露していただけます。

Osaka Mix Leap Joint #16 - 制作物天下一武道会 - connpass

イベントの構成

まず最初に45分間の展示スペース見学タイムがあり、そこで発表者は展示を行い、見学にきた方々に軽く説明していきます。

それが終わると発表バトル（LT会）がはじまり、発表者は90秒LTで自分の制作物の発表を行っていきます。

展示スペース＆LTそれぞれにてオーディエンスはスマホで採点し、その合計で優勝が決定します。

展示スペース見学タイム

僕は当サービスであるCrieitを制作物として参加しました。PCを置いて実際に操作できるようにしブースを構えました。

エンジニア向けのWebサービスということで誰も来ないかな、と思いましたが、全てのブースの採点が必要ということもあり、わりと45分いっぱいいっぱい説明していました（なかなか疲れました）。Qiitaをご存知の方もわりと多く、説明がしやすくて良かったです。

というか、自分も他の制作物のブースを見て回りたかったです。

LT

くじ引きで順番を決め、各制作物の発表が行われました。あまり何も考えず参加したのですが、どれも凝っていたり笑いありで、非常に面白かったです。かなり全体的にもりあがりました。

実際の順番は覚えていないためイベントページに書かれている順で紹介していきます。Twitterで見つけたものは色々情報を貼っておきます。

Cassettify

@hikaeme

まさかの、カセットテープ内に回路を仕込むことで、ラジカセでネットストリーミング音楽を聞くことができるというとんでもない制作物でした。感動しました。

インターネットストリーミング音楽が聴けるカセットテープを作りました。microUSBで充電して30分くらい動きます。https://t.co/fgBJz9XHtY pic.twitter.com/yiIJ5eiV7e
— Yuji Nakada (@hikaeme) 2018年6月26日

うるさい秘書を作ってみた

カレンダーと連動したスマホアプリによる秘書です。空いている時間があると、設定したプリセットの中からこの予定を入れてはどうか？　と提案してくれます。いろいろな人に使ってもらって使い勝手を調整していくと面白いものになりそうですね。

ちなみに寝る予定を入れておかないと深夜にも提案してきてうるさいそうです。

かばんばか

@kabababaaan

いろいろカバンを作られているようです。今回は下記のようなかばんの発表でした。とにかくテンションが高くインパクト大でした。

【かばんばかプレゼント企画】手順はフォロー&リツイートのみです！最大で8名に当たります！！！かばんばかのカバンをたくさんの方に知っていただくために企画しました！！！詳細は最後の画像に！リツイートガチャガチャで牛革のカーディガンバッグが当たるかも！！！https://t.co/UWA8IIGAHJ pic.twitter.com/pcVwNfX0pe
— 鞄職人🎒かばんばか (@kabababaaan) 2018年9月26日

筋電ムカデロボット

電子工作により、ボタンをおすと歩くムカデロボットでした。

別で、歯を食いしばると動くうさみみも作っておられ、本当はそれらを組み合わせて歯を食いしばると動くムカデを作りたかったそうですが間に合わなかったとのことです。完成したものを見たかったです。

スマートスピーカーでコントロールできるラジコンカー

スマートスピーカー３種に対応し、声で操作できるラジコンカーです。

気づく方はすぐ気づくと思いますが、声をかけてから動くまでタイムラグがあります。そのため進む命令をだすと室内でどんどん進んでいってしまうので今回は回転だけとのことでした。

最終的には巨大化させて自分が乗って通勤したいとのことでした。夢がでかい…！

乗換駅で次の電車までの時間のお知らせシステム

なにかアプリで通知するのかな、と思いましたが、どうも通話を使ってお知らせしてくれるシステムのようでした。

しかも、この方は普段イヤホンを使って音楽を聞いているので、一切スマホに触れず、手元のイヤホンの操作だけで情報を聞いたりできるようにされているということでした。ちょっとした工夫でかなり便利になりますね。

乗換駅に着いたら次の電車までの時間を声で知らせてくれる - Qiita

NUKADOCK

アプリを使い、個人に適したぬか漬けを作る時間などを管理してくれるアプリのようです。

…食べたいです。

個人活動いろいろ

@dekantsu

自分が好きすぎて自分に関連した制作物をいろいろ作り、自分に関する数千円の本も数冊売りさばいたそうです。かなり大爆笑でした。

というか、この方は先日バズった光るメガネの方でした！　ゆるつくというグループで色々制作をされているようです。

第一回の内容まとめはこちら第一回　光るメガネ｜柴田和弥 @86siba｜note（ノート） https://t.co/FKRzmNPlKy
— ゆるつく (@yurutsuku) 2018年9月26日

会場ではみんな光るメガネをかけさせてもらってました。僕もお借りして写真とりました。

新しい方を持ち始めた紙袋

UXを重視した新たな紙袋とのことです。学生のグループの方で、着物に合う紙袋を考案して作成したり、カップルが手を入れて繋いで持てる紙袋などを考案されていました。

適当に作るだけではなく、ストーリーボードなどを取り入れて作られているんですね。最近の学生の活動は本格的ですごい…。

現実を撮らない写真

@YujiHazama

下記のような感じで、画像を色々と美しく加工されているようです。実際の写真ではなく加工することで安く誰でも写真活動を楽しめるようにしたい、とのことでした。

同じ手法📸 pic.twitter.com/ckrnM5CpNY
— 狭間祐至 (@YujiHazama) 2018年9月26日

OSAKA City TimeLpase

@yuu_u001

ずっと大阪周辺のタイムラプスを作り続けている方だそうです。現在はタイムワープというのもあるのですね。

タイムラプス | LifeStyle STANDARD

全天球カメラとVRゴーグルでテレイグジスタンス

育休中のプロダクトのため、嫁に怒られないギリギリの線で開発をこそこそとされているそうです。ソースコードや仕組みなど、なるべく誰でも作りやすいようにGitHubで公開されているようです。

sisinn/raspi_telexistence_vr: Display the remote image of Dual Fisheye camera on the VR goggles and experience the telexistence.

Chu's me

こちらも学生グループの発表で、購入前に口紅を選ぶ際、口紅を実際に試し塗りして試せるフィルムでした。こちらもストーリーボードなどをガッツリまとめられており、プロさながらでした。命名もうますぎてビックリです。

最近の学生の活動って本当に楽しそうですね。

自転車様方向指示器『行きますよランプ』

自転車につけるウィンカーのようなものです。手元のスイッチに連動し、後部のランプを光らせることができます。左右だけじゃなく、両方同時に押すと赤くなる等。

将来的には全ての自転車につくかもしれませんね。

Crieit

僕です。まさかのトリでした…。みなさん結構笑い要素を含めていたのですが、僕はそういったものは何も用意しておらず、しかもエンジニア向けサービスなのでニッチということもあり、なんとなく変な空気で終わりました。

初LTだったのでとりあえず無難に終わらず事しか考えていなかったので成功といえば成功なのですが、発表というのは奥が深いですね！

これで発表は終わりです。

優勝

優勝は…Cassettifyの方でした！　明らかにすごかったので個人的には想像通りでした。小さい電子工作は大好きです。

優勝者や３位までにはスピーカーやTシャツが贈られました。僕も参加賞としてバッグハンガーをいただきました。

まとめ

とにかく発表がどれも楽しく、終始盛り上がっていました。懇親会でも他の方の作品に触ってみたり、あとは光るメガネがいくつかあったので皆で使って盛り上がったりしていました。

大阪で盛り上がるイベントを開催していただけるので本当にヤフーさんには感謝です。気になるイベントがあれば是非参加してみてください。

Yahoo! JAPAN Osaka - connpass

参加メモ：「Integrate Full-text Search service with Django」 #PyConJP

2018-09-18T17:08:48+09:00

Integrate Full-text Search service with Django

PyCon JP 2018のセッション「Integrate Full-text Search service with Django」の参加メモです。

ElasticsearchをDjangoアプリケーションに導入したときのノウハウなどを中心に紹介されたセッションでした。
スライド

登壇者

池内孝啓さん(@iktakahiro)
株式会社 catabira - Founder & CEO
PyDataTokyo - Organizer

内容

Elasticsearchを活用したDjangoのWebサービスの活用方法や苦労など

実現したいこと

宿泊事業者向けの運用管理システムで、ゲスト-ホスト間のメッセージを全文検索できるようにしたい。

稼働中サービスに検索機能を導入する場合に考えること

既存のデータ（RDBに入ってる）
Elasticsearchのindex設計
過去のデータの同期
未来のデータの同期
既存アーキテクチャの非破壊

index設計

設計案1: ROA

Resourceを中心とした設計アプローチ。
今回のケースでは「スレッド」と「メッセージ」というResource起点に設計する。
RESTfulに設計しようとすると自ずとこうなる。

各DBのテーブルに対してIndexを設計する。
(thread/message/guest)

この方法の課題

ElasticsearchではRDBでいうところのJOINがやりにくい。（同一Index内のDocumentのみが対象になるなど）

設計案2: SOA

サービスを1つの単位とした設計アプローチ。
そもそもユーザーに必要なサービスは何か？という観点からスタートする。
（今回の場合、ホストが受信したメッセージを検索したい）

SOAでElasticsearchのIndexを設計する
- 機能として必要な情報をすべて Indexに登録する
- RDBのテーブルをJOINしてElasticsearchのIndexを作る
- (機能を満たすIndexを作成）

この方法の課題

基本的に非正規化することになるのでデータサイズが大きくなる。
またマスターが更新された場合、関連するDocumentを全部更新しないといけなくなる。

データの同期設計

RDBとElasticsearchをどのように同期するか。
- そもそも誰がやる？
- バッチ？
- Webアプリ？
- どのタイミングで同期する
- リアルタイム？
- 一定時間おき？

同期ツールの選択肢

go-mysql-elasticsearch

MySQLのbinlogを監視して、Insert/Update/Deleteが有ったらデータ転送イベントを発火する。
- pros
- 物理削除も対象にできる
- テーブル更新からラグが少ない
- const
- テーブル単位で転送対象が決まるのでROAの場合はいいが、SOAだとつらい

Logstash + JDBC Plugin

LogstashからSELECT文を定期的に発行して最終発行より新しいタイムスタンプのレコードがあればデータ転送を発火
- pros
- Selectを自分で組み立てられる→非正規化に対応できる
- cons
- 物理削除されたのはわからない

Elasticsearch + Django

Elasticsearch + Python

elasticsearch-dsl
- High-level APIを提供するPythonのパッケージ
- Indexをクラスとして定義
- IndexやMappingの生成も行う
（たぶん、そこまで頭のいいMigrationはできないが、Pythonコード上でMappingとかができるのはデカい）

Serializer

できるだけ柔軟な検索インターフェースを提供したい
q?keyword=ham|egg&name=masaとかのQueryは組み立てもParseも苦しい

-> ElasticsearchのSearch APIを透過的に提供しよう
とはいえIndexを勝手に見られるとまずい。。。
→ということでSerializer(Djangoの）を使う
　→　不要なキーを削除したり、権限のない情報が見られないようにする
　→　ElasticsearchのAPIを使うときのホワイトリストをDjangoのSerializerで作るイメージ

#### 同期時間の短縮化
Logstashの場合、走査はcronで行われるのでタイムラグが起こる。
Webアプリで同期的にElasticsearchを使う場合は、Signalを使えば良いのでは？

post_saveやpost_deleteを使っておくと、Modelが更新されたら「XXをやる」みたいなイベントハンドリングを簡単にできる。

##### この方法の課題
- エラー処理とか色々と考える必要がある。。。
- 非正規化されたdocumentに対して更新すると、定義箇所が多くなって複雑に。。。
- Elasticsearch側のパフォーマンス

結論というかお勧め

同期はLogstash（ダウンしたりIndexが変わったときの同期にドキドキしなくていいのでとりあえずこれで）
ラグの許容できない箇所はSignalsを検討。

この辺、ボーッとしてたので異同あるかも
Q. go-mysql-elasticsearchのように、イベントのトリガーとしてMySQLのbinlogを監視するのが良かったのでは？
A. 検討はした。処理が色々なところに散らばっちゃったり処理が複雑になるのが怖い
Q. Djangoでデータを保存したときにSelect文を非同期で発行する仕組みにすればエラー箇所とかも特定しやすくてよさそう
A. 将来リアルタイムにやるのであればそれがよさそう。Logstashに任せると安心な部分が多いので今はそうしている。

感想

将来こういう機能要件が出てきたときに、「こんなのElasticsearchで簡単にできるやろ」みたいな感じで甘く考えてると、ヤバいことになるな、と思った。

特にデータの同期をちゃんと考えて設計しないと炎上する。

要件決めの時に「どの程度のラグだったら許せるのか」とか「データによっては多少結果がズレてもいいか」みたいなことをちゃんと確認したい。

Osaka Mix Leap Study 特別編 - CTO Night KANSAIに行ってきた

2018-09-18T06:29:07+09:00

ヤフー株式会社さんの大阪オフィスで開催された、CTO Nightという、エンジニアがワクワクするようなイベントが開催されたため行ってきました。今回は、株式会社はてな、株式会社ハカルス、ヤフー株式会社のCTOが集まり、色々な話を聞くことができました。

下記はイベントのページと概要です。

Osaka Mix Leap Study 特別編 - CTO Night KANSAI

関西に拠点のあるテクノロジー企業のCTOを迎えて各企業のエンジニアのトップがどういった役割を担っているか、CTOのこれまで、今、そしてこれからについてトークやディスカッションを行います。
また、イベントの序盤には各社のエンジニアが登壇するプレゼンテーションブースを設け、「ブレイクアウトセッション」を同時開催します。

ブレイクアウトセッション

５人のエンジニアが各部屋で同時に登壇するため、どれか一つを選ぶセッションです。全部見たかったです。（懇親会で「あっちの部屋どうだった？」みたいな切り口で各々話がしやすくなるため、もしかするとそのあたりの狙いもあったのかもしれません。もしそうだとするとかなり良いアイデアでした）

僕は丁度大阪でひどい台風が来たばかりだったというところもあり、梶原章弘（ヤフー株式会社）さんの「1日1億PVを支えるYahoo!天気バックエンド」を選択しました。

Yahoo!天気について

Web、アプリ、あとはAlexa、ペッパーとかでも展開している
天気だけでなく、PM2.5、花粉、服装指数、紫外線等様々
雨雲レーダー　→　ユーザーに新しい体験を提供
地図上で雨雲の様子を見ることができる。現在地点の雨雲の様子や、数十分後の様子も確認ができるサービス。

歴史

1996年サービス開始
2004年災害モジュール掲載開始。新潟県中越地震を教訓として。
　　　全てのサービスの上部に災害情報を一斉表示する。
2005年災害情報ページ
2010年スマホ対応（iOSは2012年）

2014年大阪へ。現在は全て大阪に移行している。
2015年アプリ全面リニューアル
2017年 3000万ダウンロードを達成。現在も成長し続けている。

サービスを支える自社プラットフォーム

全国に配置されている自社データセンター

自社専用棟
東西に冗長化
低レイテンシ

プライベートクラウド

クラウド基盤はOpenStack
クラスタ数60以上
HV数 7,000以上
VM数 100,000以上

日本でこの規模のものはない

（たまたま関連する資料を見つけました）
Yahoo! JAPANにおけるOpenStack on Kubernetes導入までの道のり

100以上の社内プラットフォーム

AWSやGCPのようなクラウドプラットフォームを社内で運用しているとのことです。そのため各サービスのプロジェクトではサービス開発に集中できる環境が整っているとのこと。すごい…。

各プラットフォームを専門部隊が運用
Paas Caas等様々多数
S3互換のDragonなど（自社開発）
(MQ)Pulsar
何かあったら専門部隊にチャットで気軽に聞ける

Yahoo!天気のシステム

台風、豪雨の時には１日１億PVを超える
地震発生時のスパイクは１秒あたり１万リクエストを超える

アーキテクチャ

オーソドックスな３層構造
Web(数百台）、API（数十台）、Data層
ラウンドロビンで東西分散。GSLBで振り分ける（ヘルスチェック付きDNS)
シンプルで開発しやすい
災害時も安定して情報を提供する(BCP)

コンテンツ特性に応じた対策

キャッシュ

CDN。帯域コストが掛かるものはローカルキャッシュ。

ジェネレータ

生成にコストがかかるもの（数値データからグラフをびょうがするとか）は予めジェネレータで生成しておく。

並列APIリクエスト。１画面で複数API実行。
１画面100~200msec。災害関連ページは50msecとか。

Redisはシンプルに保ちたいため使わない。障害箇所を増やすかのトレードオフで検討する。API Aggregationもシンプルに保ちたいので使わない。

今後

新コンテンツ向けに新たなアーキテクチャ採用はありえる。
API Gateway、BFFとか。

エンジニアなので食わず嫌いじゃない。色々試してみたいけど、安定しての提供が第一なので色々慎重に要検討。

まとめ

サービスを落とさない

質問

ちょっと時間が余ったため質問タイムがありました。

先日の台風など、夜も総動員？

夜は別途他のチームがやっている。ただ、先日の台風等は気になったので夜に台風のアラートは気にしたりしていた。

チームの構成は？

メインエンジニア２人
サポートエンジニア２名
業務委託３名

の７人体制等

新たなアーキテクチャを作る際のチーム等は？

新しく何か作る時とかは一人がそれぞれ一つ担当する。

その他

以上になりますが、たまたま他のセッションをまとめられている記事を見つけたためリンクしておきます。「死の谷の先へ〜 Yahoo!路線混雑予測リリースまでの道程〜」についてのようです。

Osaka Mix Leap Study 特別編 - CTO Night KANSAI - エンジニアぽい人の備忘録

パネルディスカッション登壇者紹介

登壇者である株式会社はてな、株式会社ハカルス、ヤフー株式会社、モデレータである株式会社シナジーマーケティングの計４名のCTOでのパネルセッションでした。写真も撮っていなかったため会場の様子のツイートを貼っておきます。

そして後半はお待ちかね、CTOディスカッションです！モデレーターはシナジーマーケティングのCTO 伊藤さんが担当。エンジニアとしての魅力や覚悟、CTOになったきっかけ、今後のキャリア…など様々なテーマに答えて頂きました。CTOの皆さん、参加者の皆さん、本日はありがとうございました！ #mixleap pic.twitter.com/8sa8L4XGpn
— ヤフー大阪 (@yahoo_osaka_jp) 2018年9月14日

大坪弘尚さん（株式会社はてな CTO）

会社の紹介

2001年に京都で設立
従業員117名、半数がエンジニア
従業員の比率は東京：京都＝３：７

知る、繋がる、表現する、で新しい体験を提供し人の生活を豊にする

運営サービス

はてなブログ
はてなダイアリー（はてなブログの元祖）
はてなブックマーク
企業向けの直感的サーバー監視サービスMackerel（マカレル）

受託、共同開発

カクヨム（株式会社KADOKAWAと）
ジャンプルーキー！ Webやスマホアプリ（株式会社集英社）
イカリング２　スマホ連動アプリ（任天堂株式会社）

大坪さんについて

@motemen
2008年新卒
2016年 CTO（3代目）

高校の時インターネットマガジンのはてな人力検索の記事を読んだのが最初の出会い。大学の時にはてなダイアリーでブログを書いていた。

アプリケーションエンジニアとして下記に携わった。
* うごメモはてな
* はてなブログ
* Mackerel

その他色々

やっていること

技術部門の生産性向上
- 評価、育成
- 技術情報の横展開
古めのサービスの後方支援

染田貴志さん（株式会社ハカルス CTO）

@tksmd

経歴

サン・マイクロシステムズ（あまり開発できずグレた）
→未踏ソフトウェア（プロダクトを作るのが面白いという気持ちが膨らむ）
→シナジーマーケティング
→起業（CTO１回目）（色々と難しく２年くらいで退任）
→ヌーラボ（バっクログとかの会社。京都支店立ち上げから６，７年ほど働く）
→ハカルス（CTO２回目）

会社について

機械学習を活用した診断、治療支援
組み込み機器、FPGA上への機械学習の実装
開発チーム
日本、フィリピン、パートタイム含め１６人程（人が足りないので募集中！）
技術スタック
- Python, AWS
- アプリ - Python, Vue.js, React, Swift, Kotlin
- 組み込み - C、C++

Machine Learning Meetup KANSAI

関西の機械学習エンジニアのためのコミュニティではてな、LINE、ヤフー、ハカルス等で共済しているそうです。色々泥臭いところまで含め、幅広くやっているそうですのでご興味のある方は是非参加してみてください。

Machine Learning Meetup KANSAI

藤門千明さん（ヤフー株式会社 CTO）

@mikanmarusan
常務執行役員CTO
エンジニア歴14年程

会社について

Mission: 課題解決エンジン
Vision: Update Japan
サービス数100以上
大阪は200名以上
福岡、大阪、東京、名古屋、アメリカ西海岸、ホーチミンにオフィスがある
リモートワーク有り
フリーアドレス
子育て、介護支援。週休３日等も有り

サービス概要

マンスリーアクティブユーザー4,400万人
秒間250万リクエスト

CTOの仕事

どちらかというと経営者寄り
技術戦略の立案・実行
技術やアーキテクチャに関する意思決定
技術戦略をステークホルダーに伝える
経営陣に技術的な事などを説明する

決断すること、伝えることが難しく大変。

モデレーター：伊藤純一さん（株式会社シナジーマーケティング CTO）

シナジーマーケティングが2014年ヤフーグループに参加した。ヤフー株式会社システム統括本部大阪開発本部部長として働きつつ、シナジーマーケティングのCTOを兼任している。

パネルディスカッション

各社のCTO毎に特色があり、そのあたりで色々と違う話が聞けて面白かったです。

はてな：エンジニアの比率が高い中でのCTO
ハカルス：少ない人数の中、新しいことをどんどんやっていくCTO
ヤフー：大きな組織の中で多くの重要なことを抱えながら試行錯誤するCTO

（時間の関係で巻きも多く４社全ての話が揃っていない部分などもあります）

エンジニアというキャリアの魅力と必要な覚悟はなんですか？

たまたま４社ともほぼ同じという感じになったようです。

はてな

魅力：生み出すことと学ぶこと。何かを作りそれが小さなものでも多くの人に影響を与えることができること。
覚悟：周囲も変化し続ける状況に身を置くことが大切。

ハカルス

魅力：直接的に何かを生み出し、それによって困っていた事を解決したり、それまではなかった体験を生み出せること。
最初はコードが動くの面白いとかだった。でも仕事で作っていく場合、例えばプロジェクトマネージメントツールの機能で誰かの５分を節約できるようになったとすると、最終的に日本の何千人に使われることでとてつもない時間を短縮できる、ということを考えるとすごいインパクトがあると感じた。
覚悟：常に学び続けることが必要。環境や技術が変わるのが早い。

ヤフー

魅力：自分の手がけた製品やサービスをユーザーが使ってくれるのを実際に外で見かけることがある。フィードバックを生で見れて参考になる。
覚悟：ユーザーに残念な思いをさせてしまうことが悲しい。
昔のヤフーはC言語で開発をしていた。ちょっとの修正でWebの再起動が必要になるためなかなか直せない。
PHP→Node.js→Goと徐々に環境も変わっていく。そういった変化に追いつかないと良いサービスが作れない。学び続けることが極めて大事。

シナジーマーケティング

魅力：自分の力で大きな物を生み出す
覚悟：常に知識が必要

どんなエンジニアを雇いたい？

ハカルス

ものを作るのが好きな人→届ける、使ってもらうところまで情熱をもてる人
どういう価値をエンジニアリングで発揮できるか共感して自分を磨ける人
どんどん新しいもの（技術サービス等）を使える人　→　新しいものを取り入れていくことで更に学習の場ができ色々な輪が広がる

CTOの考える、CTOとはどういった役割ですか？

はてな

技術部門の長として全体の生産性と個々人の幸福に責任を持つこと
技術のプロフェッショナルとしてイノベーションを起こし続ける技術組織を作ること
技術でどういう新しい事をみんなでやっていけるかを考えること

ハカルス

重要視している事というのは３ヶ月毎くらいで違ってくる。現在は…

エンジニアリング組織を作り機能させること（社内向け）
AI技術のポートフォリオを考え言語化すること（社内、社外向け両方）
社外に対してどういう会社でどういう事をしようとしてるか知っていただかなきゃいけない。エバンジェリストの側面。
機械学習をどう使っていけるか模索しているので、現在どういった立ち位置にいるのか、というのを考え、テクノロジー業界のエコシステムにおける会社の立ち位置を築くこと（社外向け）

ヤフー

経営戦略を達成するための技術戦略を立案実行。お金も時間もかかるので株主、投資家に説明しないとお金を使うことができない。正しく伝えることが重要。
大きなプロジェクトを従業員に任せるのは色々と不安も出てくるため、正しく伝えること。
エンジニアを全員集めて話をする機会を継続的にとっている。
一番の苦労　→　技術者でない経営者に説明する（技術関係なく自由なことを言ってくるため）。一対一できっちり説明するしかない。
- ハカルス：お客さんと同じような事ある
- はてな：社長も事業責任者もエンジニア出身のためその点は結構楽かも。（ただし開発から離れていると認識のずれは生じてきたりする）
- シナジーマーケティング：経営会議で技術の話はちゃんとしないといけない（どうせ上に上げてもわからないからしなくていいだろうという雰囲気が出てしまう）

それぞれのCTOの次のキャリアは？

はてな

より大きな事をしたい。インターネットに対して。
経営に関わっていく。

ハカルス

今４０代くらいの世代だと多分８０くらいまで働かなきゃいけない。

５０くらいで学生に戻りたい。
機械学習はいろんな業界が興味を持つ。色々な現場に行くが、医療、工場等を見てみると、自分の知らない事がたくさん見つかる。そのため別の領域の知識を得てから色々作れたらもっと可能性やできることが広がるのでは。そのために一旦勉強してみたいという気持ちがある。新しい知識を得て再始動したい。技術を使える場所を増やしたい。

→　娘と一緒に大学！？ 50歳と20歳でワンチャンあるかも。

教育というか、育成について、若いエンジニアに対して何かやってることある？

はてな：成長したい気持ちにキャップをしないで場を設けてあげる。面白いことに対して手助け。会社の利益にも結びつけていく。
ヤフー：組織的にそれをやってる。
大きいと新しいサービスってできなくなってくる。ちょっとしたことでサービスがすぐ死ぬため。そのため大きいサービス、大規模アーキテクチャできる人を育成する必要がある。
　→　アーキテクト合宿。数十名で１泊２日山ごもりをして考える。元CTOとかがレビューしてボコボコにして帰る。価値観の共有、一緒にボコボコになる中で仲良くなり、次のヤフーを支える人になってくれる。（参加したい！　→　有料かなぁ…）
ハカルス：いい感じに失敗する（致命傷を追わない）こと大事なのでそういう環境を整えてあげたいと思いつつ。

失敗に対する考えは？

ヤフー：天気、防災等、人命に関わることもある。あとお金が関わる系のサービス等、重要なものも多いため、怒られる人が明確になっているようにする。若いエンジニア等があまり怒られないように。
とはいえ失敗は怖い。情報漏洩とかもあったため。命取りになることもあるので慎重に考えていく必要がある。
はてな：Mackerelで毎週リリースをしている。俺たちイケてる感をいかに出すか。他のチームと競争したり。技術もプロダクトも面白いよね、ということを意識的に共有していく。
- ヤフー：Mackerel使ってる。お試しで登録してみたらMackerelからメールで「どうすか？」って連絡来た。返答したらすぐ実装された。スピード感すごかった。組織的にちゃんとやってる。なんか違うんだろうなあ。
  →　はてな：開発者もフィードバック見てる。やる気が出る。
- ハカルス：僕もMackerel同じ経験あった。話を聞きに行きたいと来た。ベータからずっとやっててすごい。

ヤフー

たくさんのサービスがあり、子供からお年寄りまでに利用されている。CTOとして自分より若い世代にCTOとしての役割とヤフーの将来を繋いでいく。

自分がやりたいのは新しい２５年を作るため、違う技術や何かで新しい事をしたい。→　たしかに８０までやらなきゃ…

シナジーマーケティング

エンジニア面白いのでまだまだやっていきたい。最終的に色々終わったらまたエンジニアしたい。
子どもは母親好きすぎ　→　寝かしつけはおとうさんこわくて泣き叫ぶ（世界で一番かわいい）

質問

給料は？

CTOは公開されているのでそれ見て

CTOなんですが、部下の方が知識があって自信なくなった。どうしたらいい？

はてな：そういうもんかも。知識でマウンティングじゃなく、別の役割と価値を意識する。自信なくすな。
ハカルス：自信なくなる。でもこの業界は自分は常に上じゃないといけないってことはありえない。
ヤフー：おめでたいこと。部下が成長した。むしろ良い組織づくりできてる。僕は負けたくないからやるけど。
成長した人がまた活躍するために別のこと勉強したり、一般のエンジニアができないことを勉強する。

総括

はてな：CTOになって３年目、CTOって何？　と悩んでる途中。今日僕自身が一番勉強になったと思う。
ハカルス：CTOってみんな違うことやってる。会社の組織の文化や規模で役割違う。技術から関わる役割ということでは共通。
ヤフー：それぞれ人と役割が違うし、皆色々活躍して話してほしい。他のCTOにメンターになってもらったり等もあるし、常に１番ってことはない。吸収し続ける意識でやってる。

まとめ

時間が足りずいくつかの議題がスキップされたりしましたが、かなり色々と参考になる話を聞くことができました。

やはりCTOは単に高い技術力を持っていれば良いだけではなく、会社のこと、仲間のこと、世の中の新しいことに対して目を光らせ、より良い会社にしていく力が必要であると感じました。

しかし何より大阪でこのような豪華なイベントが開催されたのは非常に良かったです。（イベントや勉強会についてはいつも東京にマウンティングされ気味のため…）

Osaka Mix Leapでは月６回もイベントを行っているそうですので、関西圏の方はぜひチェックしてみてください！

Yahoo! JAPAN Osaka - connpass

京都Devかふぇ#3 〜フロントエンド〜に参加した

2018-09-15T15:55:12+09:00

【概要】

・勉強会参加で聞いたLTのまとめ。
・同様の内容はTwitterの方にも上げているが、文字数の関係でオミットした部分も含めて。

【LT】

◎Vue.jsを使うようになるまで／佐藤慧太@SatohJohnさん

・PiCTLINK開発にvue.jsを導入するまで
・2011リリース時はJavaでサーバーレンダリング(SSR)＋Jquery
・Mithril.jsから進化した→バインディングできるけど、HTMLとくっついてる
・jQueryでゴリゴリSPAしてたけど、ごちゃごちゃに
・Vue.jsは事前に準備いらない

◎Puppeteer/こばしんさん

・Headless Chromeが元
・A/B Testing
・SEO対策のため、SSR使わなあかんケースがある
・セレニウム的な何かかな
・スクショも5行くらいですぐできる(PDFも)
・PDFすごいのは、HTML直接書き込んでPDFに吐き出せる
・Keyboardも日本語入力できる。ただ、Enter飛ばす前にちょっと待とう
・jest-puppeteerが楽
・jest-image-snapshotで実行結果の比較もできる

＠超シンプルな静的プロフィールサイトを作る／kitamura Yumaさん(ポノス)

・https://webneko.info/ をvue.jsだけで。
・parcelというバンドラ利用
・ルーティング自作。
・良いのはvue本体に集中できたこと
・vue Fes Japanにも行くよ

◎jqueryからvue.jsに移行したら幸せ／泉亮輔さん(IoT.Kyoto)

・めんどくせえDOM操作を裏でやってくれる
・AWSがserverlessになった

◎ノリでフロント作った／柳田塁さん

・美容師学校卒業後、ゲームPGとか経由して、フリープラスという会社のSEに
・調査はWappalyzer(どんな機能使ってるかすぐわかる)
・サイト分析はhotjar(クリック率とかも見えるようになる)→客の動線も記録できる

◎コスト削減の話／北村涼さん(はてな)

・Reactでコスト削減
・Conponentを超細かく実装する
・storybookで確認(コンポーネントの一部だけでも表示確認できる)
・RN(ReactNative)画面で表示
・デザイナが調整しやすい
・レイアウトdiffが非常にわかりやすい
・簡単にできる分、遅くなりがちなので注意

◎北海道の地震の話／ふるしんさん

・電気が止まってる＝暖房が動かない→冬がやばい
・太陽光パネルを設置しても、そも外部電力が稼働に必要→勝ち組だと思ったのにｗｗｗ
・観光客が命だけど、来ないから負のループやばい
・北海道応援、小春の大LT大会(関西)というイベントがあるみたい。
→次回10/1予定たのしくLT聞きながらワイワイ北海道応援しよう

【初めて聞いたワード】

NUXT
Puppeteer
PWA
netlify
Storybook
css.scoped
hotjar

【感想】

自分のベースがJava,VB.netの業務システムの知識ばかりなので
web系の最新の話を聞けてとても勉強になった。
vue.jsはangularと比較して、より気軽に書けそうだなと感じた。

行ってみた：クラスメソッドのモバイル開発を知る!第5回〜プロジェクトマネジメント編

2018-09-09T21:26:21+09:00

【9/7（金）大阪】クラスメソッドのモバイル開発を知る!第5回〜プロジェクトマネジメント編のイベントに行ったためまとめてみました。

概要

イベントページより

第5回のテーマは「クラスメソッドのアジャイルな開発」

我々が日々開発しているソフトウェアに全く価値がなければ、虚しい日々を過ごすことになるでしょう。しかし素晴らしい価値があれば、利用者を含めた多くの人々に充実した日々が訪れます。そもそもソフトウェアの価値とは何なのか、またそれを届け続けるためにクラスメソッドで行っている事は何か、をお話しします。

とのことです。

「ユーザーの価値」ってなんだろう？

今年入社したばかりのモバイルアプリサービス部グループマネージャーさんのお話です。

クラスメソッドさんでは事業会社向けの受託開発が主な業務とのことでした。そのため、「ユーザー」というのはその事業会社と事業会社が開発するモバイルアプリを利用するエンドユーザー両方の事になります。

ちょっと便利な未来を作る

顧客の叶えたい未来を実現するため。ちょっと便利の積み重ねがすごく便利な未来を生み出す。

最高のユーザー体験を提供するというビジョン。常に顧客の意図をくみとり、解決策を考え共有する。

事業会社への価値

既存事業のチャネルを増やし売上増を目指す
ユーザーを囲い込む
ロイヤルカスタマー育成

アプリで実現できるのか？

アプリの利用者は？
集客方法は？
運用体制は？
KGI, KPIは明確か？
アプリでなければならないか？

事業会社は数百万～数千万の投資でアプリを作るため、価値があるアプリかをよくディスカッションすることが重要。

事業会社の課題を共に解決したい

マネジメント
UX/UI設計
デザイン
アプリ開発

エンドユーザーへの価値（難しい）

過去にこの方が事業会社で関わったプロジェクトは8/10CLOSEしたそうです。

CLOSEのパターン

すべてがトップダウン（社長の要望）。

エンジニアもデザイナーもマーケターも何のために業務を行っているか把握できないため、みんな仕事が苦しい。マーケティングも誰に売っていいか分からない（広告すら出せないで終わることも）。

継続できたパターン

社長不在でみんながサークルを作ってプロジェクトを進行する（３，４人）。企画の段階から。
社長が何か言ってきても話はつきかえす。ちゃんと納得できる理由をつける。
→メンバーのモチベーションがアップ

メンバーにデザイナー必要
メンバーに女性必要

価値を高めるための実際の企画方法

プロトペルソナ
6up sketches
リーンキャンバス

企画内容の検証方法

webアンケート
該当インタビュー
座談会
知人にききまくる

→反応の良くないものは不採用。不採用も多数でてくる。

アプリを作る前にテストマーケティングを行う。
開発せずに適当な既存サービスを利用して１ヶ月程検証を行う。
→売れるのが確認できたり、目標に達成したか等、有効かどうかを確認する。
インスタで検証したりも。

検証ができたら実際に進めていく

最低限のMVPの決定
Bullseyesの作成
事業計画の作成
価格の費用試算→収支シミュレーション

まとめ

エンドユーザーへの価値を追求し続ける。クラスメソッドに依頼すれば単に成果物を完成させるだけでなく、プラスアルファの価値をもたせ事業に貢献することができる。

感想

単なる受託開発でなく、顧客と一緒にエンドユーザーにとって最適となるサービスを企画検証して作り上げていくという付加価値はすごいと思いました。

スタートアップの開発方法などでよくこういう手法は目にしますが、実際に受託開発でも取り入れて役立てられるのは面白いですね。

受託でアジャイル開発

こちらの方も今年入社されたばかりの方で、元々はフリーエンジニアをされていたりしたようです。

現在はスクラムマスター、組織改善を行っているとのことです。

クラスメソッドの働き方

常駐しない
自社開発１：受託開発８
主なターゲットは小売、外食事業者
B2B2C
もっと来店してもらう、買ってもらう目的のモバイルアプリ開発

受託でアジャイル可能？
→顧客とそれをとりまく環境による

受託開発 x アジャイル特有の関心事

クラスメソッドはアジャイルの方が価値を出せる。
→マーケティング用のツールを作るから
→市場の変化、いろんな関係者からのフィードバックに適応していく必要があるため

アジャイル開発にはどんな顧客が合うか？

・顧客がアジャイルが向いていると確信or経験している
・開発経験少ない顧客（提案しやすい）
・既存の開発会社のリードタイムが遅いなどの不満を持っている

アジャイル開発が合わない顧客

・既存ののやり方での開発経験が長い
・連携するシステムが多い場合
・顧客の現場に決定権がない

契約は？

準委任契約＝アジャイルやりやすい

請負＝工夫次第で可能な場合もある

調整しにくい
最初の制度の低い計画を引きずりがち
３ヶ月毎契約で、各期間に自由に開発できる余裕を持った計画として進めたことはあった

契約＜信頼関係
契約交渉より顧客との協調が重要

なので最初の契約は課題

プロダクトオーナーはだれがやるのがよい？

顧客の場合

開発チームと一緒にやるのにハードルがある
業界に詳しい

開発チームの場合

顧客の場合と逆
権限を持ちにくい

チームの一員となり、詳しい人。条件を満たせれば誰でもいい。
今は社内の方がいいかもしれないが場合による。

実際に色々やってみたこと

チームで顧客の会社に行く（スクラムイベント時など）

重要な情報得る
内情を感じる
普段会えない関係者からフィードバック

現場視察（レストランなど）

利用者などを観察（お客さんや、店員さんの忙しさなど）

合宿する

プロジェクトスタート時等に気持ちが高まる
たくさん仕事の話ができる
楽しい

その他大切な事

*顧客と期待やフィードバックを伝え合う
→勝手な期待で裏切られる缶を防ぐ
→お互いの改善

プロセスやツールより個人と対話を。

大阪オフィスで働いてみて

クラスメソッドと大阪オフィスについて色々な情報を聞くことができました。

クラスメソッドやっていること

developers.io

やってみた系技術メディア
平日日中170万PV
社員はジョインしたその日に自己紹介ブログを書く
なんでも誰でも書きたい人が書く
AWS以外でもなんでも
ノルマ無し
インバウンド強い

AWS

ロックインしてる
次々便利になるので不便はなく楽しい

リモートワーク

会社の文化
自己判断
体調悪いという理由はだめ
災害時はリモートか休暇
ふるさと勤務（それでの入社もある）
家の環境を整えておくことが重要
オフィスよりも厳しい気持ちでやる
運動不足に気をつける
アウトプットし続ける（出社してないので成果がでないと何もできてない気分になってしまう）

海外カンファレンス

会社のお金で行ける
でもブログ書きまくってね

各地にオフィス

8拠点。バンクーバー、ベルリンに海外の拠点もある。

大阪

色々な福利厚生。運動器具、ゲームなども。
ルールはつくらない
自分からアクションしていく
→皆協力的なので言い出しっぺが損をしない。発言を恐れる必要がなく安心

リモートでうまくいく

対顧客…Backlog
社内…GitHubやSlack
朝雑談。日中Slackでも雑談
チームビルディング重要
怒らない

災害

災害耐性があがってきている
最近の地震や台風の際、仕事ができない人がいても大阪か北海道どっちかでカバーしたりしてた

まとめ

とにかく仕事が楽しそうでした。内容だけでなく環境も。もちろん大変な時とかも色々あるようでしたが、それでも一般的な開発会社に比べて楽しさ多めでエンジニアのストレス少なめな印象でした。

拠点も多くあるため、モバイルアプリ＆連携のためのサーバーサイド開発が得意な方は、気になったら調べてみると良さそうです。

Osaka Mix Leap OpenDay #3 に行ってきた

2018-09-05T23:00:24+09:00

「Osaka Mix Leap OpenDay」とは、ヤフー大阪オフィスでお仕事や勉強をしながら、そこに集まった参加者同士が交流するイベントです。

今日はこの Osaka Mix Leap OpenDay #3 - 富国KokageDAY! に行ってきました。東京ではYahoo! ロッジが常時無料開放を行っていますが、大阪にはありません。Osaka Mix LeapのOpenDayは数少ない大阪でのYahoo! オフィス開放の日ですので、行ってみました。

僕は恐らく第１回目の開催も行っているので、これで２回目の参加となります。せっかくなので１回目と今回の第３回を比較してみました。

概要

開催時間

13:30～18:30

お昼からです。

料金

無料です。

その他詳細

イベントページからの引用です。

電源＋Wi-Fiに加え、ソフトドリンク、お菓子などをご用意していますので、ぜひお気軽にご参加ください。

・弊社のコミュニケーターが話しかけたり、他の参加者とのマッチングなどを行うことがあります。
・学生の方も参加可能ですが、イヤホンを着用しての自習などはご遠慮ください。
・より多くの人に交流していただく為、グループ参加の方はなるべく分かれてご着席ください。

作業環境

回によって建物が違うようで、今回は前回とは違うところでした。

どちらも広々としており、座席も余裕があり自由に選べゆったりできるため、作業環境としては全く問題ないです。一応人数制限があるため混んでいて席がない、みたいな事はなさそうです。

飲食物

ありがたいことにお菓子と飲み物が用意されています。前回行った時はペットボトルのみでしたが、今回はMt.RAINIER等もたくさん用意されており興奮しました。（節度を持っていただきましょう）

説明

前回は受付した後さほど説明もなく部屋に放り込まれて「どうしたらいいんだ…？　お菓子も食べていいの…？」みたいになったのですが、今回は詳しく色々最初に説明をしていただけ、分かりやすくなっていました。

ある程度人が集まったら全員に向け色々と説明もしていただけたので、安心感も増していました。

（そういえば前回のイベントの後分かりにくかった旨を伝えていたので改善してくれていたのかもしれません）

交流

自由に作業をできる場所の提供ではあるのですが、説明にあるように参加者同士の交流もメインの目的となっています。

ただ、単に放置だとなかなかお互い話しかけにくいというのが現実です。実際、前回参加した時には誰とも交流することなく終わりました。しかし、今回は何人かの方とお話させていただくことができました。ある程度話しやすい環境ができつつあるため前回と比較しつつ説明します。

交流が可能かの目印

参加すると最初に青と赤の色のついた三角のオブジェを渡されます。青色で置いておくと話しかけても良い、赤色はちょっと忙しい、ということを簡単に見分けることができるためのものとのことです。（これも前回案を出したので検討していただけたのかもしれません…仕事が早くてすごいです）

運営の方が話をしに来てくれる

前回もでしたが、運営の方が各参加者に話をしに来てくれます。前回はそれだけで終わってしまったのですが、今回は色々交流のための施策も増えていたのでそのあたりにつなげる説明や誘導なども増えており、交流しやすい環境をある程度構築される意味もあったように思います。

プロフィールボード

恐らく今回の目玉だと思うのですが、入室する際に皆それぞれ自分の自己紹介的なものを書かされます。名前（もしくは名刺を貼る）、興味のあること、職業等。それを全員分ボードに張っておく、というものです。

各々それを見て、気になった人がいた場合には運営に伝えれば話をする場を作ってくれるのです。（もちろんそれ見て自分で話してもOKです）

これが画期的だな、と思うのは、普段イベントで色々な方に挨拶する際、正直全ての方が話があうわけではない、というところがあります。例えば僕であればWEBサービスを作っているエンジニアのため、デザインメインの方だとあまり話せることも無いですし、全く関係ない業種の方だとなおさらです。恐らく自分だけでなく、相手も同様に感じているはずです。しかも大体のイベントは懇親会的なものは非常に時間が短く、全員と話していると全く時間も足りず深い話などもできません。

ところが、このプロフィールボードがあると、本当に自分が話したい人と優先的に話すことができます。今回もエンジニアの方や色々コンサルしている方とお話させていただくことができました。

あと一箇所に貼る、というのがかなり良いです。参加者のそばをウロウロしてプロフィールを探らなくて良いのはとても合理的です。

非常にUXの高いサービスでした。これは東京のロッジでも導入すると良いかもしれませんし（導入してるのかも知れませんが）、他のイベントでも欲しいくらいです。

まとめ

とにかく今回は前回と比べてだいぶ改善されており、有益な時間を過ごすことができました。

とはいえやはり用意されているものを自分から利用していくことは必要となるので、完全に他人まかせだと何もやりとりできない場合もあるかもしれません。せっかくやりとりしやすい環境に徐々になっているようですので、どんどん活用していくことがおすすめです。

ただ、やりとりできなくてもその作業スペースを提供してもらえているだけで本当にありがたいことですので、プラスに考えれば感謝しかありません。

Osaka Mix LeapはOpenDayだけでなく、他にも色々LTや勉強会など、趣旨の違うたくさんのイベントが行われています。connpass等で色々見てみると楽しいと思います。

Freelance Meet Up in Osaka #01 に行ってみた

2018-09-04T07:34:29+09:00

Freelance Meet Up in Osaka #01 に行ってきました。

関西で活躍するフリーランスエンジニアの方をお招きし、案件事情や、単価、ワークスタイルまで多方面からパネルディスカッションを行います。
大阪のフリーランス業界を盛り上げるべく不定期で開催しているイベントです。

とのことで、#01のため恐らく初開催だと思われます。

主催はACTBE Inc.で、こちらのCEOの方がモデレータとしてパネルディスカッションの進行を行っていました。場所はこちらの会社が運営しているACTBE Horieというコワーキングスペースでした。

あとは大阪で活動されている３人のフリーランスの方が前に並び、随時出されていくお題に対して色々と話をしてくださいました。

大まかなテーマは下記になります。

働き方
技術
営業
お金

登壇者

詳しくはイベントページに掲載があります。以後の話を分かりやすくするため簡単に説明しておきます。

伊瀬知さん

ほぼリモートで活動中

石村さん

常駐業務で活動中

横山さん

チームを作って全国を飛び回って活動中

働き方

大阪でのフリーランスとしての働き方に満足していますか？

東京はかなりの人数のフリーランスがいるため、スキルの低いフリーランスも非常に多くやっていけている印象。もしかすると大阪の方がスキルが高いフリーランスエンジニアの割合が多い可能性も？　単価は安いのでそのあたりが課題。
地方のエンジニアの方が真剣度は高そう。ただ、実績をつかみにくいので、その部分はうまく大阪と融合してやっていけると良いかもしれない。
地方の方が業務環境などが健全で働きやすい。（夜になると誰もいなくなる等）

エンジニアになろうと思ったきっかけは？

タウンワークで見つけた開発会社に入った

ここで僕が腹痛でトイレに篭ってしまったので話を聞けませんでした…

なぜフリーランスになろうと思ったのか

フリーランスになること自体はメリットだけでなくデメリットもあり、色々悩んだが離婚したため
協調性がないから

現在の働き方は？

エージェント使って常駐しながらクライアントとの縁が増えてきたのでリモートに移行していっている
クラウドワークスから。月の半分くらい全国うろうろして仕事を見つけてきてる。つねに仲間を探してる。（自分でも案件を出している）
クラウドワークスは全然案件をとれない。30～40応募して5万円くらいの案件一つとか。全く取れなかった方も。

技術

技術レベルに自信はありましたか？

一部は自身があったが、ひとりでは網羅できないためチームを作成。たまたま環境が良かったのでうまくいく自信はあった。
自信はなかった。よく分からない自分の技術でお金が本当にもらえるのか不安だった。
自信がないから色々なところで学んで行きたかったので常駐業務で色々な会社を行き来した。

独立後に苦労した場面は？

技術と仕事取るのは全然別スキル
SESだと時間計算なので、得意じゃないところやるとアウトプット量が不足してるのが気になり申し訳なくなる
不具合が発生した時の修正は苦労が多い
最初に業界を知らなさすぎて苦労（fixやマージってなんですか？　って聞いて鼻で笑われた）。たまたまその現場がフランクでやりやすかったのでなんとかなった

技術習得方法は？

本
チームの場合は習得せず、その技術をもってる人に入ってもらったりする。その方が全体的に早い。
コードレビューの収穫は高い（お客さんやプロジェクトで一緒の人とか）
仕事時に会話で出てきた知らない言葉を調べて理解を深めていく
OSSに感謝し貢献したい

チームの場合のお金配分は？

仕事を取ってから分配を考える（２割は積立てておき何かあった時のために使う）
お金の配分をオープンにしないとチームでトラブルになったこともあった
各メンバーのスキルを星にしてお客さんと交渉（安くしたいなら星の低いメンバー、星の高いメンバーを入れたいなら費用をアップしてもらう。お客さんが自分で選択できる）星もメンバーにオープン。
↑業界知らないところからここまでうまくできててすごい

営業

しんどかった。ココナラでyoutube動画作って仕事につなげてみたりもした。最終的に常駐へ
会社員時代からつながりがあってあまり営業しなくてよかった（今はエージェント使ってる）
日本中色んな所に飛んでる。安くても繋がり作るためになんとかして引き受けてみる。

単価交渉される？　その時の対応は？

作業者の星制度を作った。星の低い人には仕事のやり方を教えたりもしなければならないが、逆にそれぞれ関係ないところで得意分野があったりするので、コンテンツ作成業務などでそういったメンバーの知識も使って仕事につなげたりすることでなんとかバランスを取ったりしている。
常駐ではあまりない
自分のやったことないところは費用落としてもいいから取りに行きたい
単価交渉してくるお客さんとしてこないお客さんは明確に分かれてる
交渉をよくしてくるのは関西だと多い感じ？
常駐で単価４０万→８０万に５年かけて上げた人もいた
エージェントにはなんでも言いやすい（単価交渉とか）。むしろ何でもちゃんと言おう

エージェント何社くらい使ってますか？

ギークス、レバテックとか、２，３社
日数減らしてくれという交渉もしてる
フリーランスだと、常駐業務でなくても大手とやるときは代理店に入ってもらったりする（直だとダメらしい）

お金

いくらくらい稼いでますか？

会社員より２倍くらい（ここから税金も引かれるが）（常駐は日数で上下調整できる）
まわりの人よりもちょっとかせげてるかなーと
定期的に案件があれば良い
仕事が好きだし時間も自由に決められるのでつい働いちゃう
ちゃんと定期的に休む時間作ってる（お客さんにも伝えてる）

節税してますか？

とくにはやってないけど、保険の積立とか
税理士さんにやってもらってる（税理士さんによって節税方法や基準も違ったりする）
適当にやってたらプライベートとごっちゃになって確定申告でむちゃくちゃ怒られた。税理士さんにやってもらうことにした

大阪フリーランスはどうですか？　課題点など

個人的には好き。人情とか。単価関係なく大阪でやりたい。責任ある仕事任されるまでに時間がかかる。とりあえずスキルアップのためいろいろやりたい。
フリーランスの信用とか費用とかは関西のほうが苦戦してる。発注側の意識もまちまち。関東は勉強会多い。
発展途上なので良くしていかなきゃいけないけど、なかなか進んでいかないので課題。もったいない。

質疑応答

どうやったら輪が広がっていくか？

アウトプットして自分自身の露出をふやす。ブランディング。
一人勝ちしないように他の人にやってもらうようにしている。

働く日数を減らす交渉はしづらくないか？

入る段階で交渉。入ってからだといろいろ気になってしまう（進行具合とか）
やめるときのキリのいいタイミングで引き継ぎだけにして減らすとか。

継続的に仕事をとることはできるのか（スケジュールが埋まらないかもという不安）

稼働日数を減らして複数の仕事を取ったり
呼び出されたらすぐ行くやつと思われるようにしたり
保守案件の数を増やす（受託を受けたらなるべる保守とる）

有望な業種とかある？

WEB制作ができないところからとってる（ちょっとしたところにプログラムが必要な時代になっているのでそのへんをすくいとる。大阪特化ではない）

まとめ

最初はどういったイベントなのかあまり想像できていませんでしたが、登壇者の方々がそれぞれ違った働き方をしており、バラエティに富んだ生の声が聞けたのでなかなか面白いパネルディスカッションになっていました。

そもそも僕も大阪でフリーランスとして働いている方々とほとんど会ったこともなかったので、参加者の方々とのお話も含め色々と新鮮でした。フリーランスになったばかりの方や、これから目指したいという方もいたので色々と参考になったのではないかと思います。

自然言語処理のMeetup「StockMark presents NLP Meetup! Vol.2」に参加したメモ

2018-08-24T23:58:23+09:00

この記事の内容

自然言語処理の勉強会「StockMark presents NLP Meetup! Vol.2」に参加したのでそれのメモ。

これな。

自然言語処理って地味に勉強会とか少ないので貴重だ。

今日はSIerの方々を集めた会らしい。
LTなのでさらっと表面をなぞる感じです。

NTT Data APCの取り組み

APCはAgileプロフェッショナルセンタの略らしい。

最初にニュースを検索して要約＆資料化（パワポ）にするアプリのデモ。
- ニュースを検索
- NTT Dataの名寄せ技術
- 様々な言語のニュースを翻訳
- Azure翻訳
- ニュースを要約＆資料化
- Google形態素解析
- NTT Dataの要約技術

NTT Dataの考え

昨今は「ニーズがもやもやしている」ところからサービスを作って早い段階で評価を得る必要がある。

なので、スタートアップや既存のクラウドサービスとコラボレーションして素早く価値創造をしていく。
→　仮説検証＆プロトタイプ作成をグルグル回していく。

新日鉄住金ソリューションズの取り組み

新日鉄住金グループのシステムソリューション部門
（ただし親会社関係の仕事は売上の20%程度）

（発表されている方の担当は「スマートマシン」。おうちハックにハマってるらしい。
LEGOで作るスマートロック　〜「Hey Siri 鍵開けて」を実現する方法）

スマートマシンのターゲット

ビジネス競争の加速とか複雑化や人口の減少があるので、クリエイティブな組織にするためのいろいろを解決していく。

鍵は「リーダー」。
リーダーは多忙で負荷集中してるからヤバイ。
→　これをAIでどうにかサポートしたい。

「リーダーがいなくてもメンバーが情報を探せるような仕組み」を作らないといけない。

例えば

リーダーがいなくてもメンバーが情報を調べる仕組み -> Cogmino
- あいまいなキーワードから検索したり業務の観点で情報が整理される
リーダーの代わりにドキュメントの一次レビューをしてくれる仕組み -> Lumisis
- タスク管理の代行。リーダーのレビュー観点を学習。

まだ社内で使っている状態らしい（表には出てない？）

よくある苦労

「実績がないからお客さんがデータをくれない」　→　身内を使って実績作りからスタート（ドッグフーディング）
「AIだけじゃ無理」　→　専門家やベンダーと幅広く連携する

苦い経験からの学び

こんなことがあった
- 技術ありきのアイディア出し　→　現場でやったら「全部没」
- 現場知識のみ　→　ありきたりだし実現不可能
- 技術ドリブン。使い勝手軽視　→　定着しない
どう解決したか
- 現場＋技術の両方を掛け合わせた発想を重視
- 高速でのトライアンドエラー＋観察
- 利用していることを意識されない仕組み
- インフルエンサーを仲間にする

IBMのサービスの紹介（Watson)

情報抽出機

非定型のテキストを整理・分析。

例えば、「川崎」が地名なのか人名なのか、ってどうやって判断するの？
- 固有表現がどういうカテゴリに分類されるのか、とエンティティ同士の関係性を見る。
簡単な文章なら今ならどんなツールでも分析できるけど、専門分野のものはなかなか難しい。
ではどうする？

→2つの手法
- 機械学習による情報抽出
- 多くの文章を学習させる
- ルール定義による情報抽出
- 単純にルールを設定して情報を抽出する
- ○○の後ろに「さん」がついてたら「人間」とみなす、とか

pros/cons
- 機械学習
- 人間がわかってないルールを認識できる
- ルールの説明が難しい
- データを集めるのが大変
- ルール定義
- 説明しやすい
- メンテナンスも楽
- ルール生成者によってブレがあるかも

あとはWatson Knowledge Studioのデモ。
今のところ、このレベルのは自分の用途（小説の分析）からはToo Muchかも知れないけど使ってみたい。
（速度とかはどんな感じなんだろう）

NRI：SIerがAIを祀ったら駄目だと思う件

メッチャ世界観がありそうなタイトル。

TRAINA

TRUE TELLERをリニューアルしたのがTRAINA。
主に導入先はコールセンターだけど、他にも幅広い業種に導入している。

通話内容を記録して応対履歴を作成
応対履歴を作成にかかっていた時間を削減

コールセンターだけじゃなくて営業部隊の電話営業などのチェックにも導入したりしてる。
→　なんかヤバそうな電話かけてる人がいないかチェック（「絶対儲かる！」とかコンプラ的にアウトな感じの）

課題

最近チャットボットが話題だけど、ユーザーは自分のやりたいことを言語化できないことも。
（「PDF」を覚えてないとか「アクロバットなんとか」みたいな曖昧な認識をしている人とか）

そういう人達のためにはチャットボットの「聞き返し」機能が重要
→　「ひょっとしてそれは『○○』のことですか？」みたいな。

あと、ちょっと前にニュースになってた「AIが国会答弁を作る」って実験があったけどニュースは「言い過ぎ」
質問に対して過去のデータを探って「こういうこと言ってたよ」って検索結果を返してくれる程度。
（「なかなかアレ」らしい）

個人の意見

いろいろAIに置き換えられていくけど、まだ「言語」はAIに置き換えにくいところ。
- 一般の人のAIの認識　→　ドラえもん（なんでもできるぞ）
- 実際のAI　→　できる範囲以外はできないぞ

こんな状況で「SIer」がどんなことをするべきかというと、「期待値コントロール」じゃないの？
- 情報発信とか
- 営業トークとか
- PoCとか

使いながらユーザーの期待値を調整していく。

なのでSIerは「AI」「AI」って祀り上げたらいけない。

ユーザーが必要なのは「AI」ではないですよね？
→　ビジネス課題が解決できればOK
（顧客が本当に必要だったものメソッド）

パネルディスカッション

LT発表者の方を中心としたパネルディスカッション。

前段の話として
- Web系とか華やかなところに比べて地味だけど「AIの現実」を知ってるのがSIer
- 一方、AI時代到来で再びSIer滅亡論が過熱している
- リスク取ってスピード感のあるAIスタートアップが台頭
- ビッグデータを持ってるGAFAが更に強大に

じゃあ、SIerってどうするんですかね？

テーマ1:AI時代にSIの役割ってどうなるんですか？

意見1: 「SIerはサッサと滅びればいい」
- 今時、何年もかけてシステム作るとかスピード感なさすぎじゃないですか？
- ユーザー企業は本当は自前で作った方がいい
- ただ、ユーザーに対して何を提供すればいいのかを一番知っているのがSI
- そういう人達のための相談役としてSIerが必要

意見2:「AIを使えばシステムが単純になるわけじゃない」
- より色々なデータを繋ぎはじめるから複雑な仕組みになってく可能性もある
- そういうときのために課題の解決を期待されるのがSIerなのでは？
- GoogleやAmazonを使って楽に作れたとしても、困ったときに彼ら助けてくれないですよね？

意見3:「色々な役割の人が潤沢にいるってのがSIerの強み」
- いろいろな専門分野の人を集められるので、それを上手くいかして戦う
- 「ふわ」っとした知見を持っているお客さんにしっかり説明して寄り添えるのはSIer

意見4:「AIコンサルになるべき」
- SIerはいろいろな業界のノウハウがある
- 知識の蓄積をベースにした提案ができるという強みがある

テーマ2:大企業にAIを導入したときの難しさってなんですか？

意見1:「データのばらつきがヤバい」
- テスト範囲だとちゃんと上手く動くモデルが作れたとしても、実業務になるとイレギュラーなデータが大量に出てくる
- 部署とかごとにチューニングしてあげる必要があったりする

意見2:「AIって何でもしてくれるんでしょ？っていう期待」と「ユーザーにどれくらい教育すればいいの？」っていうところ
- ユーザーが自分でデータを入れたり教え込ませたりしないといけないって認識がなかったりする
- 「何件入れれば上手くいくの？」みたいなふわっとした質問に回答していく必要がある

意見3:「辞書登録とかチューニングなどメンテナンスをしないといけない」
- 色んな人が運用に入っていくことを想定しないといけない
- 大企業だと分析とかシステムに詳しくない「初心者」も運用に入っていくので、そこの教育が大変

意見4: 「インフラ」
- ネットワークが隔離されていたりオンプレみたいな環境に構築することが出てくるのでつらい

テーマ3:SIとして「儲かるAI」みたいなプロジェクト本当にあんの？

意見1:「単純な分野では無い」
- 単独でお金を儲けるんじゃなくて、できることをウリにして他のお仕事をもらったり……

意見2:「汎用AIでは無理では？」
- 業務課題の解決という狭い分野でAIを活用することはよくある
- 「なんでもできる」系はちょっとまだお金にならないと思う

オフレコとかもあるので一部省略。

感想

「AIすげえ！」みたいな、よくあるイケイケな話よりも地に足のついた話が多かった。
勉強会全体も落ち着いた雰囲気で、過ごしやすい印象。

今の自然言語処理の「できること」「できないこと」については、参加前に自分が思っていた範囲と大きくは変わらない感触があったのでその辺は少し安心。
（イケてる話があまり見当たらないのは、自分の観測範囲が狭いからなんじゃないか、という懸念があった）

時間があれば、もう少し技術寄りの話も聞いてみたかったな。

『StudyCode：エンジニアと法律家のための勉強会』に参加してきたメモ

2018-07-18T23:45:50+09:00

StudyCode 〜エンジニアと法律家のための勉強会〜 #4 電子署名と契約

日時：2018/07/18 19:15〜
場所：株式会社LIFULL様　＠　麹町
https://studycode.connpass.com/event/89770/

一言で言うと

電子署名や契約書をITを使って解決するいろいろなノウハウの勉強会。

前段

昔　→　事後解決
今　→　予防法務
これから　→　共創

ドキュメントプロセスの劇的な変革を牽引する電子サインの可能性〜 Adobe Signのご紹介〜

一言で言うと

Adobeが提供している電子サインシステムの紹介
https://acrobat.adobe.com/jp/ja/sign.html

概要

ドキュメントプロセスを広範にサポートするサービス。
Adobeとしてはプロセス全体をサポートしたいという考えがあり、比較的わかりやすい「電子契約サービス」という風には紹介しないようにしている。

「電子にすると法的有効性が担保されないのではないか」という懸念に応えるものになっている。
（紙であっても改竄や修正ができてしまうのは政治問題になった件でもわかるはず）

ブラウザー＋メールがあれば使える、というハードルを下げたシステムになっている。

API連携もできるので社内の既存の承認フローとの連携も容易。

デモ

メールアドレスを承認フロー順に入れる
（感想：メールアドレスの入力を間違いそうで怖い）
1-2. 「承認」だけでなく、「確認する人」「フォームに入力する人」みたいな権限を設定することもできる
送信すると承認者にメールが届き、リンクを踏むと承認プロセスに入れる
メールアドレスだけではなくメールサーバーへのログインをもって認証を担保している。
不安だという人は二段階認証みたいのも可能。
承認プロセスではAdobe Sign上のフォームに署名などを入力する（手書きも可）
3-2. 印鑑やスマホを使った入力も可能
完了ボタンを押す
PDFの中に署名が入力される
目に見える「署名」だけでなくデジタル情報としても署名が記録されている。
6-2. 文章の編集履歴などもすべて記録されており、リンクを押すとその履歴を見ることができるので、これで法的有効性を保つことができる