2017年買って満足度が高かったもの

2017年も早いものでもう終わりですね。
皆さんがやっているのを見て自分もまとめておこうと思ったので今年買って満足度が高かったものをつらつらと残しておこうと思います。

iPhone X

www.apple.com

なんやかんやで満足度高いです。ホームボタンがなくなることでどれくらい影響があるのか心配でしたがすぐ慣れました。 今となってはホームボタンがなぜ存在していたのか分かりません。

一番懸念していたのはApple Payの支払時にTouch IDが使えなくなることだったのですが、Face IDでの認証が思った以上に速いので杞憂に終わりました。
Face IDはマスクをしていると認証しないからイケていないと思う方もいるかもしれませんが、マスクをちょっとずらせば認証できますし、そもそもマスクしているときにそんなに頻繁にロックを解除することがないので私は全く問題ありません。

カメラの性能も本当に素晴らしいです。何も考えずにシャッター切ればきれいな写真が撮れます。過去、カメラに定評のある端末をいろいろと試してきましたが間違いなく最高の出来だと思います。

唯一の不満は、ずっとPlus系の端末を使ってきたので画面サイズがとても小さく感じることです。これも慣れればどうということは無いのですが、たまに妻のiPhone 7 Plusを見ると画面の大きさが恋しくなります。

iPhone 8 Plus

www.apple.com

新しいiPhoneを9月に使えないというのが私には耐えがたかったのでiPhone X発売までの繋ぎに買いました。iPhone Xを入手したのですでに手元にはありませんが...
1か月ちょいの利用でしたが本当に満足度が高かったです。

今までのiPhoneの延長で最新型を使いたい方には間違いなくお勧めです。画面の見やすさ、動作のヌルヌルさどれをとってもiPhone 7系から進化していて素晴らしかったです。
カメラの性能も格段に進化していました。子供の幼稚園の運動会はこれだけで挑みましたが全然問題無かったです。

Apple Watch Series 3

www.apple.com

Apple Watchもなんやかんやで全シリーズ使っていますがこのSeries 3はやっとまともなApple Watchになったと感じさせてくれるものでした。

性能がアップしたことでアプリの起動、Apple Payの起動が格段に速くなっています。
Series 2も初代に比べれば格段に動画が速くなっていたのですがまだストレスが残るものでした。それがSeries 3では本当にスムーズに使えるのでストレスがなくなりました。

ただ、デジタルクラウンの赤ぽっちがちょっとダサく感じるのが残念です。今となってはもう慣れましたが。

ちなみに目玉機能であると思われるCellular通信については契約はしたものの一度も使ったことがありません。

Apple Watch Hermès - 38mmケース用ヴォー・スウィフト(エトゥープ)シンプルトゥールレザーストラップ

www.apple.com

Apple Watchのバンドはいろいろと買ってきたのですがちょっと冒険してみようと思い買ってみました。

つけた瞬間に、これがHermèsのレザーか!と感動しました。滑らかさが全然違います。今まで私がレザーだと思っていたものはいったい何だったのでしょうか。それくらいの衝撃。気持ちよすぎてついつい触ってしまいます。

Apple Watchの安いモデルと同じくらいのお値段ですが、今後も長く使えるものなので興味のある方は買ってみるとよいと思います。

Galaxy S8+

www.galaxymobile.jp

私は日本市場で人気のあるAndroid端末の現状を把握するという意味で、毎年GalaxyかXperiaどちらかの最新モデルを買うことにしています。
今回はこのGalaxy S8+を買いました。

画面が大きいのに手に収まるちょうどいいサイズ感、ベゼルレスのかっこよさ、スペックどれをとっても間違いなく今まで使ってきたAndroid端末の中で最高峰のものでした。

ただ、期待していたアシスタント機能である「Bixby」がゴミのような出来だったのが非常に残念です。

iPad Pro 10.5

www.apple.com

久々に大きな進歩を遂げたと感じさせてくれるiPadでした。
120Hzのリフレッシュレートは伊達じゃないです。

Apple Pencilでメモを取りながらの資料読みや技術書読みがとてもはかどります。

Kindle Oasis (Newモデル) 32GB

Kindle Oasis (Newモデル) 32GB、Wi-Fi、電子書籍リーダー

間違いなく過去最高のKindleです。毎日の通勤時の読書ライフの質が格段にあがりました。

防水、ページ送りができる物理ボタン、7インチになった画面サイズ、どれをとっても素晴らしいです。
私は気になった部分をハイライトしながら読むことが多いのですが、このハイライトするときの動作が速くなっていることも嬉しいところです。数秒の差かもしれませんが積み重ねると結構な時間の節約になっていると思います。

Nintendo Switch

www.nintendo.co.jp

言わずもがなSwitchです。
ただ、私はそこまでSwitchのゲームはしていません。

Switchの満足度が高い理由は、子供と一緒にTVゲームができるという機会を与えてくれたことです。

5才と3才の子供も細かいことが分からなくても一緒に遊べます。さすがNintendoさんです。
自分が子供のころにさんざんやったマリオシリーズを大人になってから自分の子供と一緒にできるということはとても感慨深いものです。

Logicool MX ERGO Wireless Trackball

www.logicool.co.jp

ロジクールから久々にでた新型のトラックボールです。M570tを愛用していたので迷わず飛びつきました。

最初はちょっと大きいなと思っていたのですが慣れてくるととても手にフィットします。電池ではなくて充電式になったこともありがたいです。
あと、傾斜を変えられるのがとてもよいです。基本は20度に傾けて楽な体勢で使うようにしていますが、ちょっと気合いを入れたいときは0度にして使っています。これが自分にとっての気合いスイッチとなっています。

Beoplay E8 - B&O PLAY

kanjitsu-boplay.jp

完全ワイヤレスイヤホンです。
昔、EARINが出たときに完全ワイヤレスイヤホンは体験していて残念な気持ちになったので敬遠していたのですが、まわりで買う人も多く、各種メーカーがこぞって出してきたので何か買っておこうということで買いました。結果、買って大正解でした。ケーブルがないってやはり素晴らしいです。

私が完全ワイヤレスイヤホンを使うのは主に通勤時とジムにいったときだけなので音質は捨てました。音質や防水を求めるなら間違いなくBoseSoundSport Free wireless headphonesを買った方がよいと思います。

私が大事にしたのは操作のしやすさと音漏れしないかの2点です。

この機種は横をタップするだけで操作できます。また、外の音が聞こえるようになるTransparencyモードも地味に便利です。話しかけられたときなどに左側をワンタップするだけでイヤホンを外すことなく外の音を聞くことができます。

音漏れについては入念に確認しましたがそこそこ大きな音にしても漏れません。個人的に電車の中での音漏れはけっこう許しがたいのでイヤホンを買うときはこのチェックがかかせません。

ちなみに、イヤーチップを変えるだけで音質やつけ心地、音漏れの印象はだいぶ変わってきます。私はComplyのものをいつも買っています。お持ちのイヤホン用のものを探して買ってみて下さい。

www.comply.jp

なお、長時間の移動時や普段はBose QC 30を使っています。これは去年の発売と同時に買いましたが本当に素晴らしいです。

bbs.kakaku.com

ThinkPad X1 Carbon 2017モデル

www3.lenovo.com

MacメインからWindowsメインに変えようとした年だったのでWindowsノートが必要になったので買いました。勉強会やセミナーなど外に行くときの相棒です。

安定のThinkPadでした。本当に何の不満もありません。この軽さでこの性能、そして何よりこのお値段で買えることがすごいです。特盛りにしてもMacBook Proよりも全然安かったので買うときに本当にこの値段でいいの?と不安になりました。

Apple Watch Series 3の赤ぽっちは許しがたいですがThinkPadの赤ぽっちはやはり最高です。

ヘアードライヤー ナノケア EH-NA99

kakaku.com

Panasonicのドライヤーです。ドライヤーが壊れたのを機に買いました。

髪の毛を乾かす速さが段違いに早くなりました。寝癖がすごいので毎朝頭を洗っているのでかなり時短できるようになりました。

また、我が家は私以外は女性(妻と子供2人)なので、彼女たちは髪の毛がさらさらになると喜んでいました。

常盤珈琲焙煎所のコーヒー豆

tokiwacoffee.com

最後にいきなりガジェットではなくてコーヒー豆です。

家では豆を自分でひいてドリップする派なのですが今年はここのコーヒー豆にはまりました。
浅煎り〜中煎りが好みなので大宮ブレンド常磐ブレンドをメインで、気分次第でその時々のシングル豆を買っていました。

店舗はさいたま市周辺に数店舗しかないのですが通販もやっているようなので興味がある方はぜひ。


最後に

他にもGoogle HomeAmazon Echo、Clova WAVE、HoloLensなどなどいろいろと買いましたが満足度が高いというよりは技術的な興味で買ったものなのでここには載せませんでした。

今年はあまりモノを買わないようにしたつもりなのですが無駄にApple製品を買ってることが分かりました。

来年も経済を回していきたいと思います。良いお年を。

リモートワークを神話にしない実践者勉強会に参加してリモートワークについて考えてみた

リモートワークを神話にしない実践者勉強会というものに参加してきました。
「リモートワークをどう実践しているか学べる場が欲しい」という目的で開催されたとのことです。

forkwell.connpass.com

現在私の所属する会社ではリモートワークは育児、介護などの一部の人だけに許可されています。私も育児の理由で1年半くらい週2でリモートしています。
また、全社員に向けてリモートワークを制度化しようという動きもあったりするので皆さんどんなことで悩んでいるのか知りたかったという気持ちもありました。

セミナー内容のざっくりメモと自分なりの考えをまとめてみます。

内容メモ

トーク - 株式会社grooves

イントロ
  • クラウドエージェント事業部
    • ほぼリモート
      • 月1出社も
    • 完全にリモートと割り切ってチームビルディング
  • Forkwell事業部
    • 週初と、月末以外の日は個人の判断でリモート可
リモートワークの導入まで
  • 一人のエンジニアから始まった
    • 会社に行かなくても仕事ができる状態だからリモートしていい?
  • 上司の不安
    • その人単体では機能するけど周りのメンバーとの関係は維持できるのか?
    • エンジニア以外もリモートしたいって言い出したらどうしよう...
  • まずは週2からはじめてみた
  • 質の高いコードを量産しだした
  • これをきっかけに社内にリモートワークの良さが広まってきた
どう解決したか
  • 大前提となる考え方
    • 付加価値を最大化すること
    • ひとりひとりの裁量、自由度が必要
  • Q: その人単体では機能するけど周りのメンバーとの関係は維持できるのか?
    • A: 向き不向きがある
    • リモートが向く人
      • 能動的である、自律的である
      • テキストでの高いコミュニケーション能力
        • 相手に配慮した会話
        • その上で言いたいことが言える
      • 情報アクセスの容易さ
        • 本人だけが持っている情報もチームの資産
        • 周りのメンバーはその資産にアクセスする権利がある
      • 利他的であること
        • 自分の利益だけでなくチームの付加価値向上にこだわった行動、振る舞いができること
    • リモートする上で払うべきコスト
      • ログを残す
        • 曖昧なものごとも言語化する努力が必要
      • チャットは返答する、スルーしない
        • リモートでも必ず返答があるという信頼感が必要
        • 即レスしろということではない
      • オフラインコミュニケーションの時間を有効につかう
        • オフラインでの関係構築が大事
  • Q: 他のエンジニアがおれもおれもと言い出したらどうする?
    • A: 小さく試して判断する
    • 本人とメンバーが発揮するバリューが落ちないならOK
    • 不公平感 < チームの成果
    • 職種ごとにバリューを発揮できる環境、時間帯が違うのは当たり前
      • バリューが発揮できるかどうかを小さく試していく
その他
  • ツールを使えるリテラシーが大事
    • エンジニアがエンジニア以外の人にもいろいろ教え回っていた
  • ジュニアな方だと育成は大変
    • 中途採用の応募者の数、質があがっているので結果的に教育コストは下がっている
  • 新メンバーが加わったとき、キックオフMTGは対面が有用
  • リモートワークに向いていない人はどうすればいい?
    • トレーニング推奨

LT

スマートキャンプ株式会社
  • リモートワークの立ち位置
    • 従業員の生産性、快適さを追求する取り組み
  • 月一で働き方を考えるMTGしている
  • 開発チームの取り組み
    • 毎日1時間の集中タイム
    • MTGを全て火曜日に
  • リモートワークは水曜日に、リモートワークデー
  • ルール
    • 勤怠はSlackで
    • 勤務時間内はSlackで連絡が取れるように
  • 集中してクリエイティブに開発したい作業を水曜日に持ってくる
  • 実体としては半数は午後から出社して静かなオフィスで開発していたり
  • ノートPCを全員に支給
リンカーズ株式会社
  • 週2でリモート勤務OK
    • 使っても使わなくてもOK
  • MattermostとSkype for Business
    • Slackは使わないでMattermost使っている
      • セキュリティ的な理由
  • コミュ力が高いことが大事
サイボウズ株式会社
  • 半分のチームがリモート
  • リモートワークに必要なこと
    • 制度、風土、ツール

座談会

  • メンバー同士でコラボレーションするときに気をつけていることは?
    • 新人にもやってもらっている。やった後に何が良くて悪かったのかちゃんと振り返ってもらう
    • 成果物だけで評価は難しい
    • サイボウズは市場価値で決めたりしている
    • マインドとかツールではない
      • 情報の整理ができるか。人によって情報の精度は違う
      • 勘で言っているのか何か事実に基づいて言っているのかの判断が必要
      • 嘘をつくことは前提で信頼する
        • 100%事実を伝える人間はそういない。それを念頭に。
  • 過去に起きた問題はある?
    • セキュリティ事故は怖い
    • 不公平感が出ちゃう
      • 不公平感は絶対出るよという前提
        • 育児する人しない人とか。そうい感情は割り切ってもらう
  • リモートに慣れるためにやっていることある?
    • リモートに向いていそうな人をそもそも採用している
    • 最初のチームビルディングは大切にしている
  • オンラインでチーム感を出すための工夫
    • オンラインでゆるいやりとりができるように
      • Slackなどの使っているツールでTwitterみたいな使い方をする
        • timesチャンネルみたいなもの
    • オンラインでも成果を求めればチーム感は自然と出てくるのでは?
  • Linkersではチャット上では議論しないルール
    • チャットはあくまでも報告の場、アツい議論はオフラインで
  • サイボウズはとことんオンラインで議論する派
    • そういうときは収拾させないで燃え尽きさせる
    • 議論をちゃんとするフレームワークは用意している
      • 真実なのか、そう思うというただの考えなのかはっきり分けるように

所感と考え

会社の規模によってリモートワークに対する考え方が全然違うということをあらためて認識できました。会社の規模や業務内容によって仕事の進め方もそうだし、セキュリティ的な話(何を守りたいのか)もだいぶ変わってくるので当たり前といえば当たり前なんですが。
自社でどうしようかと考えてばかりいると、どうしても固定された考えになってきてしまうのでやはりこういう場は必要ですね。

個人的に思っていることをいくつかのポイントでまとめてみます。

評価について

評価方法はどこも悩んでいるようでした。
成果で評価すればいいじゃんって話もありますが成果は職種によりそれぞれ。数字できちんと出せる仕事の人もいるしそうでない人もいる。
サイボウズさんの評価指標に市場価値があるというのはかなり理想的ですが、人事制度を同じように変えるのはなかなか難しいですからね。

ここは結局、評価指標をどうするかがポイントだと思っています。
OKRなどできっちりと自身の役割をマネージャーと認識合わせをして定期的に1 on 1などで振り返りを行うことで、たとえリモートであろうと適切な評価ができるのではないかと考えています。すでにこういう評価が行えている会社はスムーズにリモートワークが導入できるのでないでしょうか。しかしこのような評価ができていない企業も多いはずです。

つまり、リモートワークをやるならマネージャーの意識改革(場合によっては評価制度の変更)も重要になってくるということです。リモートワーク自体の制度を入れることばかりに夢中になってしまいこの大事な部分を忘れがちになってしまっては元も子もないです。

オンラインでのコミュニケーションスキルは大事

「オンラインで文章をきちんと書けない人ではリモートは厳しい」
これはどこも共通認識としてあるようです。

これも話が出ていましたが、リモートワークが当たり前の時代になることを考えると訓練してもらうしかないと思います。
冷静に考えると、相手の文章をよく読み、論理的に文章を組み立てるということはビジネスでは当たり前のスキルではないのでしょうか?
これらができるように努力しないということは業務に必要なスキルの取得を放棄していると見なすこともできると思います。(ちょっと言い過ぎな気もしますが)

もしかしたら一般的なビジネス研修(論理的思考とかそういうもの)の中で「オンラインコミュニケーションのための文書作成術」のような研修が必要となってくるかもしれません。それくらいできて当たり前の風潮にしないといつまで経ってもできる人、できない人の差を埋めることは難しいと思っています。

オンラインとオフラインの使い分け

対面で話した方が細かいニュアンスまで伝わるのは間違いないです。なのですべてをオンラインだけでやる必要はありません。
さらにいうと、オンラインでもテキストだと厳しいがビデオチャットなら意思疎通ができそうという場面もあると思います。

そこで、自分たちの組織でのルールを決めておくことが大事になってくると思います。
「基本はオンラインのテキストでやりとりするが、こういうときはビデオチャットで、さらにこういう場合は対面でやる」というルールを明確に決めておけるとよりスムーズにコミュニケーションできるのではないでしょうか。

オンラインでの議論

この話はとても興味深かったです。
オンラインで議論するのが普通だと思っていたので、議論はオフラインで行い、オンラインは事実だけを報告する場という考えは新鮮でした。確かにこれだと顔の見えない相手と変な読み合いをしながらの議論をしなくて済みますからね。やったことある人は分かると思いますがオンラインでの議論はけっこう頭も体力も使うので。

個人的にはチームビルディングがしっかりできている、かつオンラインでのコミュニケーション能力が高い人が集まっていればオンライン上でも議論は可能だと思います。むしろリモートやる以上そこを目指さなければいけないのではないでしょうか。
そのためにも、サイボウズさんのようにオンラインでの議論のためのフレームワークみたいなものを作って徐々に浸透させていく必要があると思います。

ただ、その状態になるまではオンラインでの議論が空中戦になってきたと感じたら、「ちょっと1回対面で話しましょうか」という方向に持っていくことも必要となるでしょう。

さいごに

自分の考えをまとめていても思ったのですが、やはりリモートワークに対する考え方や仕組みについては正解がないものであり自分たちの組織に合ったものを試行錯誤しながら決めていくしかないと思います。同じ組織でも今はフィットしているが時代と共にフィットしなくなることも十分に考えられます。
働き方やそれにともなう制度を柔軟に変えられないとこれから先はいろいろと難しくなってくるでしょうね。

いろいろな会社の考え方を知ることができ、またリモートワークに対する考えをいろいろ整理できて非常に有意義でした。
主催者の皆様ありがとうございました。

LINE DEVELOPER DAY 2017に参加してきた ~アウトラインメモ~

LINE DEVELOPER DAY 2017に参加してきました。去年は都合により参加できなくなったので初参加です。

linedevday.linecorp.com

参加したセッションのアウトラインメモと所感を残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。
また、都合により最後まで聞けなかったので最後の方のセッションは聞けていません。

なお、全セッションの資料は以下にまとめられています。

engineering.linecorp.com

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。

The Technologies in Clova

www.slideshare.net

LINEの新たなプラットフォーム戦略として、クラウド型AIプラットフォーム「Clova(クローバ) 」を開発しています。本発表では、AIプラットフォームであるClovaやスマートスピーカーWAVEについて、ビジョン、アーキテクチャについて紹介します。

内容

What is Clova

  • Cloud-based virtual assistant
    • この頭文字を取ってClova
  • 身の回りにある色々なものに搭載していきたい

History

  • プロジェクトスタートから実は1年しか経っていない
    • 2016年9月にプロジェクトスタート
    • MWC 2017で初プレゼン
    • 2017年8月にトライアルバージョン販売開始
    • 2017年秋に一般販売開始予定

Technology

  • アーキテクチャ
    • BRAIN
    • SKILL
      • 音楽再生、天気情報の読み上げなど
    • PLATFORM
      • 認証認可、ユーザープロファイルなど基盤部分
  • インターフェイス
    • CIC
      • Clova interface Connect
      • ClovaクライアントとClova接続のインターフェイス
      • SDKAPIのコレクション
      • 入力情報をClovaに送る、出力情報をClovaから受け取る
    • CEK
      • Clova Extenstion Kit
      • Clova上でアプリケーションを実行するためのAPI
      • CEKを通してSkillを呼ぶイメージ

今後の予定

  • 認識部分の強化
    • 話者認識ができるように
    • 発話以外の理解
      • 日時の理解、履歴の理解など
  • 開発環境の提供
    • 2018年を予定

所感

Clovaのこれまでの歩みと今後についてとアーキテクチャについての説明でした。

Clovaってプロジェクトスタートから1年しか経っていないということにかなり驚きました。
ハードの開発含めてこのスピード感で行うのかなりすごいですよね。開発チーム大変だったんだろうな...

WAVEの先行体験版を購入して使っていますがやはりAlexa等と比べるとまだ微妙な部分が多いのも事実です。細かいところの精度を上げるよりもまずは市場に投入して評価してもらったりテストデータを集める方が賢明と判断したのでしょう。

2018年には開発環境の提供を予定しているそうなのでそこからがClovaの本番でしょうね。開発環境の提供を楽しみに待ちたいと思います。

Gateboxのこれまでとこれから

www.slideshare.net

"次元を超えて、逢いに来る" 世界初のバーチャルホームロボット Gatebox は、その発表以来多くの反響を呼んでいます。現在初回の出荷に向けて準備が進んでいるこの製品の生い立ちと現在、そしてそれを支える技術と今後のテクニカルな展望、Clovaとの関わりについてお話をいたします。

内容

Gateboxのこれまで

  • 世界初のバーチャルホームロボット
  • 我々は機械的なロボットやスピーカーとコミュニケーションを本当にとりたいか?
    • かわいいキャラクターなら話しかけたくなるのでは?というのが開発のきっかけ
  • 2016年1月にコンセプトムービーを公開
    • 日本より海外からの反響が多かった
  • 2016年12月、1台30万円で限定300台販売
    • 売り切れた
    • 出荷はまだ
    • 今年5月に購入者にプロトタイプを体験してもらった。かなり好評だった

技術スタック

  • ソフトウエア
    • キャラはUnityで実装
    • 基盤はLinux
    • node.jsがメインでGateBoxの振る舞いを制御
    • C++音声認識や顔認識部分
  • Cloud側
    • Azure使っている。Functionsも利用
      • 元MS社員だから...

Gateboxのこれから

  • Clovaとの連携
    • スマートスピーカーはクラウド側から返ってくる音声を読み上げるだけ
    • Gateboxはそれに加えキャラクターがアクションを取らないといけない
    • 自然な振る舞いができるような音声合成をしないとキャラクターの動作が不自然になってしまうのでそのあたりの調整がキモ
  • 国際化対応
    • 海外からの反響も多いのでどう答えていくか
  • スマートフォンと本体をどう連携させるか
    • 外で起きたことをスマートフォンで検知してその出来事にもキャラが反応してくれるようにできれば

所感

Gateboxを立ち上げたきっかけとこれまでの活動、そして今後取り組もうとしていることが説明されたセッションでした。使われている技術スタックについての解説もありました。

Webの記事だけでしか情報を見たことがありませんでしたが、実際の開発者の方の話を聞くと目指している世界がはっきりと伝わってきて応援したくなりました。

音声に加えキャラクターの振る舞いの制御も考えないといけないのは非常に難しそうですがこの製品の肝となる部分だと思うのでいろいろとノウハウ知りたいですね。

また、初音ミクバージョンを初音ミクファンの方に使ってもらったときに「いつもありがとう」とGateboxに向かって話しかけていたという話はかなり興味深かったです。
相手が機械でも初音ミクという実像(たとえポリゴンであっても)があれば人間は感謝を伝えるというコミュニケーションを取ろうとするということ。考えさせられました。

Paying back technical debt - LINE Androidクライアントの事例から -

www.slideshare.net

LINE Android Client の開発は7年目に入り、サービスの拡大に伴いクライアントの実装も肥大化および複雑化してきました。このような状況下で今後も持続可能な開発を行うためには、機能実装と技術的負債の返済を同時に進める必要があります。本発表では、技術的負債を返済しやすいような環境作りとして、我々がどのような改善をしてきたかについて、コード、CI (Continuous Integration)、チームの3つに焦点を当てて紹介します。

内容

  • リファクタリングは難しい
  • 技術的負債を返済しやすい環境づくり
    • Code
      • Kotlin採用など
      • ただ入れるだけではダメ。制限するところは制限する
        • コーディング規約の整備
        • ライブラリの悪用を制限
          • 例) ReactiveXはいろいろな用途で使えてしまうのでラッパーを作って対応
    • CI
      • PRに補足情報を入れるボットを作っている
        • 自動でIssueトラッカーのリンク挿入、APK installコマンドの提示、推奨レビュアの表示など
      • Releaseブランチからtrunkブランチへのオートマージ
        • コンフリクトが起きたらLine Notifyで通知
      • Issue Tracker Police
        • PRには必ず対応するチケットがあるはず。対応するチケットがない場合はマージできないようにした
      • gradle-versions-pluginを利用してライブラリの最新バーションをチェックする
    • Team
      • 文化を変える
      • 知識や技術の共有
        • 勉強会、資料の共有

所感

LINEのAndroidアプリ開発において技術的負債を返済しやすいようにどのような環境を作ってきたのかを説明したセッションでした。

PRを扱いやすくするためのGitHub用のボットを各種自作して利用しているのが印象的でした。
特にIssue Tracker Policeが私は気に入りました。チケットとPRが必ず結びつくようになっていることを自動で徹底できるので楽。こういう仕事は人間がやるものではない。

LINEにおけるBluetoothを活用した取り組みの紹介

www.slideshare.net

スマートフォンの枠を超えたユーザ体験の実現のため、LINEではBluetoothを使ったデバイス連携サービスを提供しています。このセッションでは、LINE Beaconおよびtappiness自販機の事例をベースに、LINEがどのようにBluetoothを活用しているか、注意した点、苦労した点などをお話します。

内容

What is a LINE Beacon

  • BLE使ったBeacon
  • 事例
    • 書店においてLINEマンガと連携
      • そのまま試し読みできる
    • Tappiness
      • 自販機に搭載
      • 双方向通信を使った決済システム
        • LINE PAYで支払える
        • ポイントが貯められる
  • 開発者も利用可能
    • Beaconを検知したらWebhookを送る仕組み

アーキテクチャ

  • 最初はiBeaconやEddyStoneを利用しようとしていたが独自方式でいくことにした
    • その場所だけのサービスを実現したかったため
      • なりすましされにくい物が必要
      • iBeaconなどはUUIDの領域が決められていて独自のセキュア領域を含めることできない
  • 16bit UUIDを利用
    • Bluetooth SIGにお金を払うことで発行できる

Tappiness(自販機)について

  • Line Appがインターネット接続を仲介する
  • Web Bluetoothの仕様を参考にしている

LINE Simple Beacon

  • ラズパイやMacbookをBeaconとして利用できるものを公開した
  • 13biteのFreeのUUIDのスペースを用意
    • ここに好きなデータを載せられる

所感

LINE Beaconの概要と事例を知ることができたセッションでした。

iBeaconやEddyStoneを利用せず独自方式を採用した背景などを知ることができて面白かったです。
自販機のTappinessの仕組みも面白かったです。自販機自体には通信機能を持たせずスマートフォン経由で接続するというのはなるほどなーと思いました。

Line Simple Beaconも面白そうなので何か作ってみようかと思えました。


全体所感

運営方針が本当に素晴らしいと感じました。
参加者の快適性と自社製品のアピールがうまく混ざっていて好感を持てました。

LINEの専用アカウントを活用

  • 受付用のURL含め基本的にLINEで連絡が来る
  • 次のセッション情報や会場の案内などもいいタイミングで通知がくる
    • これがすごい便利だった
  • タイムテーブルや、会場案内図、アンケートなどが全てLINE Bot上で実装されている
    • 自社プラットフォームでできることをきちんとアピールしていて使ってみようという気にさせてくれる

情報提供の速さ

  • 資料が即時アップロードされ、セッション終了後にURLが届く
  • 公式のまとめブログをその日のうちに発信

その他運営全般

  • 会場キャパシティと参加者の数がちょうど良い
    • 混み過ぎでもなく、空き過ぎでもなくちょうどよい快適さ
    • 他のイベントだと混みすぎて部屋の移動もできないことが多いのでかなり快適に感じた
    • どう見積もっているのだろうか?
  • カフェを貸し切って休憩場所にするという方針は素晴らしい
    • 参加者、発表者の交流の場にもなっていて良かった

残念だった点

  • セッション時間がちょっと短いように感じた
    • そのせいか概要レベルのセッションが多かったように感じた
    • もう少し技術的に込み入った話があってもよかったかもしれない
  • 発表がちょっと堅苦しい感じがした
    • おそらく話すスピードとかスライドのめくり方とか細かい指示があったのではと予想
    • そのせいで本来の力が出せていない発表者もいたように感じた
    • 一定のクオリティを保つことも必要だとは思うので難しいことではあると思うが…

builderscon tokyo 2017 2日目 ~アウトラインメモ~

builderscon tokyo 2017の2日目のレポートです。

builderscon.io

1日目のレポートはこちら。

braitom.hatenablog.com


builderscon 2017 tokyo day2

3Dプリンタで作る1次元セル・オートマトン 階差機関 、アナログコンピュータ

speakerdeck.com

  • 階差機関と3Dプリンタ
  • デルタ型の3Dプリンタ使っている
    • 中国語の説明書見ながらつくった(中国語分からないから写真見ながら…)
  • 階差機関
  • 桁上がりの仕組み
    • 出っ張り見たいのがあってそれで分かるようになっている(0-9管理している)
    • 原理的には10進数以外でも実装できるはず?
  • 設計方針
  • 産業革命時代になぜ達成できなかったのか?
    • 精度が足りない
    • 人の問題、金の問題
  • 今の時代ならできるのでは?→そう3Dプリンタならね
  • CADソフト
    • OpenCADだといろいろツラくなってきたのでFusion 360
  • 3Dプリンタの苦手なこと
    • Z軸方向に長いとブレる
    • 摩擦がかかるパーツは苦手
  • 積層型3Dプリンタのつらいところ
    • 浮いているとことは苦手
      • サポート材で対応→しかしサポート材取り除くのつらい
      • 分割しちゃうという手も

所感

階差機関って何ぞや?状態でしたが、図を用いた説明がかなり分かりやすかったです。ぜひスライドで確認してみましょう。
3DプリンタのTipsもためになりました。昔、3Dプリンターでちょっと遊んでいたこともあるのでサポート材を取るのが面倒くさい問題は良く分りますw

階差機関の歯車の仕組みなんて絶対自分では調べない領域なのでとても楽しめました。歯車の仕組みすごい。産業革命すごい。 しかし、昔最先端だったものを現代の技術の力で個人が開発するって面白いですね。

今日から使えるCSS Grid

geckotang.github.io

  • CSS Grid
    • より複雑なレイアウトに対応するために登場
    • Flexboxもあるけどちょっと足りていない
  • グリッドレイアウトを作りやすい
    • CSS側にレイアウト情報を持つのでHTMLがシンプルに
    • Flexboxは縦、横どちらかの整列
    • CSS Gridは縦、横両方の整列ができる
  • ブラウザ対応状況
    • IE10+とEdge以外は対応している
      • IE10とIE11は古い仕様を参照している
        • 使えるけどできないことがある
        • polifillあるけどお勧めしない
      • Edgeは次のバージョンから新しい仕様に対応する
  • CSS GridとFlexboxの使い分け
    • CSS Gridが向いているもの
      • 大きい部分だとウエブサイトの大枠
      • 小さい部分だと縦横に揃える必要のあるリスト
    • Flexboxが向いているもの
  • 参考リンク

所感

CSS GridとFlexboxってどちらかだけを選んで使うものと思っていたのですがそんなことないのですね。同じ画面でも場所によってそれぞれのメリットを理解して適用させていくのが大事ということが理解できました。
使い分けでも紹介されていたように、パターンとしては大枠のレイアウトをCSS Gridで整えて、細かいところはパターンによってCSS GridかFlexboxを選んでいくって感じになるみたいです。
この辺は実際に自分のページレイアウトに当てはめていって試行錯誤しながら学んでいかないと感覚つかめないかなあと思いました。

polyglot になろう !!

speakerdeck.com

  • polyglotって?
  • polyglotだと何がうれしい?
    • ある言語の概念を他の言語に持ち込める
    • 他の言語の経験によってより理解が深まる
    • 2つ目以降の言語はより簡単に習得できる
      • 新しい言語は何かしらの言語の影響を受けている
    • 作れるものの幅が広がる
      • 言語ごとに得意分野がどうしてもある
  • polyglotになるには?
    • やる気と時間
    • 全く別の領域に手を出してみる

所感

感覚的に、確かに初めてのプログラミング言語を学ぶときは「あっ、これはあの言語でいうあの機能に該当するものだ」っていうことがありますよね。そういう感覚をうまく言語化してまとめてくれているなあと思いました。
複数言語を完璧に使いこなすのは難しいかもしれませんが、2つくらい覚えておけばその知識を活かして何とかできる気がします。

しかし、他の言語をやってみようって思うきっかけって何なのでしょうね?
全く別の領域に手を出してみる方法を推奨されていましたが、今の時代どの言語でも結構色んな領域に対応できちゃうのですよね。プロダクトレベルだと無謀だと思いますが個人開発レベルだとそれでもなんとかなってしまうので悩ましいところです。

WEB+DB PRESS 100号記念 特別企画

  • Vol.1~
    • vol.1はJSP徹底入門!
    • vol.2で宮川さん登場
    • vol.3から稲生さん参加
    • 4月の新人歓迎号と総集編が売り上げよくなる
    • この辺りはJavaの時代、特集1は全部Javaだった。使っている言語、これから使いたい言語ともにNo1だった
  • vol.25~
    • vol.27でAjax登場
    • vol.28でRails登場
    • vol.32で大幅リニューアル、連載増やした
    • vol.36、Seasar2によるスーパーアジャイルなWeb開発。この頃Seasar2全盛期
    • vol.43でAWS初登場
    • vol.46、最初で最後のPython特集
    • 時代がWindows中心からLinux
    • XMLが減ってきた(紙面数的にも嬉しい感じに)
  • vol.49~
    • vol.49、仮想化が一般的になってきた。VMware ESXi特集
    • vol.50、Git登場
    • vol.51でRails特集
    • vol.57、Android特集
    • vol.69、GitHub特集
  • vol.73~
    • vol.75、Infrastructure as a code流行ってきた
    • vol.79、Docker登場
    • この辺りは結構最近なので記憶が新しい
  • Q&A
    • 編集部ではどのように技術キャッチアップしてるの?
      • イベントやSNS
      • 著者に直接教えてもらう
      • 自分が知りたいことは記事や本を書いてもらうw
    • ライターの探し方は?
      • 毎号5人から10人くらい新しい人が書いている
      • 記事書いたことある人に頼めばOk
      • 著者経由で
      • 1懇親会1企画を目指していく
    • 「WEB + DB」とは
      • あまり意識していない
      • Webアプリケーション開発のためのプログラミング技術情報誌という中心だけを意識
      • 役に立つなら何でも載せる

所感

技術の歴史を振り返ることができた。 私がこの業界に入ったのは2007年なので自分が触れてきた技術の振り返りって意味もありとても楽しめました。
こう振り返ると、その時代の旬の技術についてはちゃんと情報追えてキャッチアップできてきているのかなーと思いました。
こういう感じで定期的にトレンドの流れを振り返るのは大事ですね。今後何をやればいいのかも見えてくる気がします。

The Evolution of PHP at Slack HQ

  • Slackの開発している
  • DAU
    • 北米、UK、日本の順。日本は結構多い
  • 有償利用者も増えている
  • 急成長しているが、この中生き延びないといけない
  • Enterprise Gridは84社が使っている
  • SlackのコアはPHP使っている
  • PHPはぶっちゃけお粗末な言語、しかし成功しているサービスはPHP使っている
  • PHPの良いところ
    • State
    • Concurrency
    • Programmer Workflow
      • アプリの変更時のフローのこと。PHPはサーバーリスタートいらない、reloadだけ
  • 2015年
    • PHP5 + functional-ish programming
    • OOPは使わない
    • SlackのファウンダーはFrickr作った人。Flickrがこの方法で成功したから同じ方法で
  • HHVM + Hack
    • Speedとパフォーマンス
  • Hack
    • 型チェック
    • Data Structure
  • HackはPHPの欠点をfixしてくれる
  • HHVMへの切り替え
    • Route5とCloudFront
    • Route53のWRRを設定。振り分ける重みを変える。少しずつ実施
    • パフォーマンス大幅に向上
      • レスポンスタイム、PHP : 116ms、HHVM : 62ms
    • 今は100%Hackに変換している

所感

あまり聞くことのできないSlackのサーバーサイド側の話を聞くことができて有意義でした。機能のElectronアプリの話といい本当に貴重な経験でした。

正直、PHP関連の動向はほとんど知りませんでしたが質疑応答等の内容も含めてPHPの現状が把握できた気がします。まさに「知らなかった、を聞く」状態でした。
今までPHP系の情報は全スルー状態でしたがHackは悪く無さそうに感じたのでちょっと意識して軽く情報には目を通していこうと思いました。

全体を通して

冗談抜きで今まで日本国内で参加したカンファレンスの中で一番良かったです。
いつもとは違うことを色々知ることができた、セッションが魅力的だったというのももちろんあるのですがなぜそう思ったのかを簡単にまとめると以下のような感じなのかなと。

  • コンセプトがはっきりと体現されている
    • 「知らなかった、を聞く」がまさに実現されている
    • 本当にいろいろな内容のセッション、つまり様々な分野が得意な人が集まる→つまりは文化が違う人が集まるということ
  • 運営が素晴らしい
    • 参加者への配慮(朝食の用意、アイコン付き参加賞の配布など)
    • 運営メンバーの担当範囲がしっかりしていて色々と運営がスムーズ
    • 変な内輪乗りもなく、かといってかしこまった感じでもなくちょうど良い和やかな感じ
    • 牧さんのアツい想いが伝わってくる

私自身、社内の技術イベントを主催しているのですが実はbuildersconの思想にかなり影響を受けています。前回は都合がつかず参加できなかったのですが今回参加してあらためて「こういうことを目指しているんだ!」というのを再認識できました。
次回は運営のお手伝い等もできればと心から思いました。

本当に最高のカンファレンスをありがとうございました!

builderscon tokyo 2017 1日目 ~アウトラインメモ~

builderscon tokyo 2017に参加してきました。

builderscon.io

参加したセッションのアウトラインメモを残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。資料が公開されているものはリンクを張っておきました。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。


オープニング

  • buildersconはYAPCの直系のイベント
  • Discover somthing new
  • 発見と知識を共有

Desktop Apps with JavaScript

  • SlackでDesktopアプリを作っている
    • チームは4人
  • Windows7だと絵文字とかのサポートがつらいから早くアップデートしてw
  • クロスプラットフォームアプリを作る理由
  • JavaScriptで書かれたアプリはもう世の中にあふれている
  • Electronについて
    • Node.js + Chromium(レンダリングエンジンの部分だけ) + C++(OSネイティブ機能)
    • Main ProcessとRenderer Process間での通信が可能
  • Slackアプリの話
    • Electron、TypeScript、C++
    • 複雑な部分(全体の5%くらい?)はC++使っている。Video Call部分とか。
  • ライブコーディングしながらElectronアプリを作るデモ
  • テストはこの辺り使って行っている

所感

Slackの中の人の話を聞けるなんて本当に良い経験でした。
ライブコーディングが最高でした。Electronアプリの作り方の基本がばっちり理解でき、Electronで何か作ってみようと思わせる非常に良いセッションでした。

SlackではVideo Call部分はC++で書いているといっていましたし、パフォーマンス求められるようなアプリを作るにはやはりElectronだけではダメなんだろうなと思った次第。

なお、ライブコーディングしたサンプルは以下で公開しているそうです。

ブラウザ拡張のクロスブラウザ対応についてどう向き合っているか

speakerdeck.com

所感

私自身ブラウザ拡張機能はいくつか作っていたりするのですがクロスブラウザ対応するという考えは今まで考えたことありませんでした。そういう意味でなるほどなーと考えさせられました。
ちゃんとしたサービスのブラウザ拡張を仕事で作っていないと出てこない考えだよなーと。個人で作ると、正直自分のメインブラウザだけ対応すればいいやってなっちゃいますからね。
自分のブラウザ拡張をクロスブラウザ対応してみようという気持ちがかなり高まりました。

自分でクロスブラウザ対応するためのツールを色々作っているのもすごいですね。便利そうなので使ってみたい。

Haskellを使おう

speakerdeck.com

  • Stack
    • cabel-installに変わるビルドツール
    • プロジェクト間の依存パッケージのバージョン違いを適切に扱ってくれる
  • Stackage
  • Hoogle
    • 関数名、型名とか検索できる
  • 日本HaskellユーザーグループのSlackの#questionで質問受け付けている
  • 本出す
  • I/O処理
    • あんまり得意ではない。が、苦手というほどでもない
  • I/Oモナド
    • PythonとかPHPなどと同等の機能を提供する
    • 入出力、ミュータブル変数、例外
  • do記法のコツ
    • let x = ...x <- ...を使い分ける
    • 冗長でも<-で別の変数に束縛してから使う
  • HaskellではI/Oはモナド
    • モナドを使ったプログラミングが必須
  • モナディックなAPIの読み方
    • 何を提供するモナドか、メンタルモデルを把握する
    • モナドの剥がし方を探す
  • なぜHaskell使う?Goじゃだめなの?
    • GHC使うとパフォーマンスを担保できる
    • Goと比べると型システムが優れていて抽象度の高いコードが書ける

所感

すごいH本を過去に1度読んだだけの私にはなかなか理解がキツかったです…
Haskellではモナドを理解しないとダメなことが良く分りました。モナドが曖昧になっているのでこれを機にすごいH本を読み直そうと思いました。

RDBアンチパターン リファクタリング

speakerdeck.com

  • データベースの寿命はアプリケーションより長い
  • 最近はDBのチューニングはマネージドサービスがやってくれる
    • でも、設計は自分たちでやる必要がある
  • データは生き物、基本的にdeleteよりinsertが多い
  • RDBアンチパターンを見極めるのが大事
    • 不吉な臭いを見極められるように
    • Softwear Designで連載してるから見てね
  • 何をリファクタリングするかはアプリの特徴によって変わってくる
  • データベースリファクタリングはすごく長くなる→戦うための準備が必要
  • 「モニタリングのないオペレーションはテストのないコードと一緒である」→モニタリングは超大事
  • DBを止めるのは難しい
    • 停止時間を限りなく短くすることはできる
    • サービス停止の壁は政治と技術の両方で解決する
  • データベースリファクタリングするだけの価値があるか見極める
    • 意味はあるのか
    • 作業に応じた効果があるのか
    • 今やるべきか
  • 小さい変更を長いスパンで繰り返す
    • 欲張らない、一気にやりたい気持ちを抑える
    • DBは影響範囲が広いので切り分けできるように
  • 金で殴る
    • 金の弾丸
    • DBはお金の力でなんとかなることも多い
  • 1度作ったDBは消せない
  • RDBの知識は寿命が長い
    • 1度覚えれば長く役立つので勉強の費用対効果が高い

所感

過去のスライド等に目を通していたので、内容はだいたい知っていたのですがやっぱせっかくなので生で講演を聞こうと思って参加。プレゼンもうまく非常に楽しませてもらいました。
RDBリファクタリングは技術や政治の力が必要だけど「覚悟」も大事。

しかし、やっぱアプリの要はDBですね。DB知らないでアプリは作れん!と改めて思いました。DBエンジニアの方は偉大だ。

RDBは学習の費用対効果が高いというのはごもっともだと思いました。今をときめく機械学習系のライブラリやVR技術なんかは10年後どうなっているか予測できませんが、RDBが10年後に無くなっているとは到底思えませんからね。


1日目はこんな感じでした。「知らなかった、を聞く」ことができて非常に満足度高いです。 明日も楽しみです。

Developers Summit 2017 Summerに参加してきた ~アウトラインメモ~

Developers Summit 2017 Summerに参加してしきました。

event.shoeisha.jp

参加したセッションのアウトラインメモを残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。資料が公開されているものはリンクを張っておきました。

なお、資料は公開され次第、以下でまとめられていくようです。

codezine.jp

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい


エンジニアコミュニティを推進する企業文化 ~楽天での5年間のコミュニティ活動・社内勉強会からみえてきたこと~

1000人以上が来場するようになった楽天テクノロジーカンファレンス、事業部門から発案された社内ハッカソン、着実に収益基盤を確立してきたScrum Gathering Tokyoなどを手がけてきた立場から、どうやって社内外のコミュニティを居心地がよく、イノベーティブな場にするのか、私なりの体験と考え方を話したいと思います。

  • 楽天株式会社 川口 恭伸

内容

speakerdeck.com

  • コミュニティ運営やカンファレンス開催はなんか成功している感じはするし、はたから見ると楽しそう
    • 実際はそんな簡単ではない
  • 結局はプロジェクトとか商売のコツと大差ない
  • Tipsなど
    • 月単位のマイルストーンを決める
      • いつ開催案内する、登壇者募集するなどはきっちり決めておくと楽
    • 集まる日を決める(専任でできる人はいないので皆でやる日を決める)
    • 同じ会場で何度もやる
      • 場になれるのでトラブルがなくなる
    • 色んなカンファレンスに参加していろいろパクる
    • 人手は常に足りない問題
      • いきなり増やすとイベントの目的などのコンテキストを揃えるのが大変
      • 常連さんをどんどん運営側に引き込んでいく
    • 引き継ぎはなくしたい
      • どんな作業も一人でやらないでチームでやっていれば引き継ぎはなくなる
  • 楽天カンファレンスをやっている理由 → 楽天をふつうにしたい
    • ふつうというのはどこでもやっている状態

所感

時間配分が間違っていて途中で時間切れになってしまって残念でした。スライド後半まで話が聞きたかったですね。

コミュニティやカンファレンスに関する細かいTipSや考え方が確認できて良かったです。社内で技術イベントを主催しているので学べる部分がかなりありました。
会場を固定してそこで何度もやるのはやはり重要ですよね。ちょっと違うだけで変なトラブル出てきますし。現にデブサミ雅叙園に固定したらいろいろとうまくいくようになったそうです。
最近、仕事もプライベートもバタバタしていてなかなか勉強会やカンファレンスに参加できていないのですが何とか時間を作って参加していく気持ちが高まりました。やっぱ色々なイベントを見てパクらないとですよねー。

SoRとSoEをつなぐ「エンジニアの役割」と「企業の課題」

非IT企業のパーソルキャリアが、SoR型開発とSoE型開発を混在させ、その中でエンジニアがどのように価値発揮したか、また価値発揮させるための企業側の課題についてお話します。

  • パーソルキャリア株式会社 清田 馨一郎

内容

  • SoEとSoR
    • ジェフリー・ムーアが2011年に出版したホワイト・ペーパーにより広まったビジョン
    • Systems of Engagement and the Future of Enterprise IT
    • SoEとSoRは対立するものではない
    • BiModal戦略の登場(ガートナーが提案)
    • 枯れたことだけではダメ。新しいことだけでもダメ。ビジネスによいものを選択するのが大事
  • 社内事例
    • 新規システムにSoE
    • SoRのサブシステムをSoEで開発
    • これらにチャレンジして行く中で内製化の大切さを実感
      • 社内に知見が貯まる
        • 外部ベンダーに頼んでいると知見が貯まらない
      • プロダクトオーナーの育成、開発メンバーの育成、IT部門の本気度などが必要
  • なぜ非IT企業で内製化ができたか
    • 最初は優秀なエンジニアが必要
      • トップがテクノロジーで会社を変えるという強い意志を示す
      • 共感したエンジニアが入ってくる
    • エンジニアの採用
      • メディア露出、勉強会への登壇や主催
    • 社内風土
      • エンジニアの価値をしてもらう
      • 小さい成果をコツコツ出す
      • 所属部署以外へ積極的に絡んでいく
    • プロジェクトを回せることをアピール
      • IT部門、企画部門の人などを巻き込んでいき一緒に開発できることを認知してもらう
  • 内製化により見えてきたこと
    • 非エンジニアとのエンゲージメント
      • エンジニアが能動的に動くことが大事
        • 社内調整などの地道な活動も必要
        • エンジニアの方から非エンジニアの方に歩み寄り関係性を築いていく
    • 非エンジニアの上司との関係性
      • 非エンジニアの上司はTech Leadなどに権限を委譲する
        • エンジニアのことが分かる人がエンジニアに関する権限を持つことが大事
    • 変化が激しく、現場は混乱しがち
      • 次々に登場する新テクノロジーの目利きができる力が必要
      • アーキテクトが必要
    • 企業風土
      • 現場に権限が与えられているか
      • チャレンジが推奨されているか
        • 失敗が許されていないと新しいことはできない
        • 従来プロセスを見直して無駄を改善していく勇気
        • チャレンジするためにはしっりとした基盤(土台)が必要
      • トップの強い意志があるか

所感

SoEとSoRの詳しい話ではなく、この考えを元に企業のエンジニアリング文化をどう変えていったのか?という話でした。
外部に委託することがメインだった企業がどのようにエンジニアリングができる会社に変わっていったのかの知見を知ることができました。 さらっと発表していたがこの裏にはかなりの苦労があったんだろうなーと思いました。
エンジニアの価値向上のための方法、社内風土の形成は参考にしたい。 特に非エンジニアの方との関係性の構築は気をつけないとですよね。お互いの立場が違うことを認識しないで話しちゃうとどうしても対立してしまうので注意しないとですね。

Yahoo! JAPANのコミュニティが生み出す価値

企業主体のコミュニティを立ち上げたYahoo! JAPAN。そこに至った背景や、コミュニティを通じてYahoo! JAPANのエンジニアやデザイナーに起きた変化、そして、これから世の中に与えていく影響についてお話しします。

  • ヤフー株式会社

内容

www.slideshare.net

  • 社員の勉強会参加、登壇は積極的に支援
  • LODGEというコワーキングスペースをオフィス内に設ける
    • 技術勉強会などにも利用してもらっている
  • 企業がコミュニティを形成する目的は?
    • 採用 → 一般的
    • 成長 → こっちの話をする
  • なぜコミュニティから成長を生み出したいのか
  • 社外コミュニティの参加支援
    • 支援はありがたいが、自分たちの課題を解決できるとは限らない
    • 規模の大きなイベントに偏りがち
    • 行く人と行かない人のギャップが生まれる
    • → それなら企業がコミュニティを形成してしまおう
  • ヤフーが形成するコミュニティ
    • 課題を解決することを目的にする
      • 同じような課題に取り組む企業とも共有しやすい
    • 課題を解決する場として定着させる
      • 勉強しに行くのではなく課題を解決する場に
    • 複数領域をまたげるように(iOSAndroid、デザインなど)
      • 各領域を1つの目的で繋げることがキモ
      • 全体をまたいでフォローする組織がある
        • 色々な領域を見ることで共通課題を見つける
    • 実現する上で乗り越えたこと
      • とにかくオープンに開催
      • 小さな成果をとにかく拡散する
        • コミュニティ全体の成果となるように意識
      • ときには自らハードルを下げていく
    • 現れてきた成果
      • 導入するツールの意思決定が行いやすくなった
      • 小さいチームの施策を大きなチームが導入

所感

ヤフー自らが主体となってコミュニティーを運営している目的やその効果が説明されたセッションでした。 勉強しに行くのではなく課題を解決する場であるという考えが素敵でした。
小さな成果でもどんどん発信していくスタイルはやっぱ大事ですよね。こういう文化があるというのもいいですね。
しかし、あまりに内容がひどいと逆に信頼を損ねることにも繋がるのでは?とも思いました。この辺りの線引きをどうしているのか気になりました。ヤフーさんだけではなく各社何かしらのレビューフローとかあるのか気になるところ。

コミュニティ活動と企業の相互作用 ~コミュニティへの貢献と組織活動への還元~

本セッションではコミュニティへの貢献が企業の組織にどのように影響するのか、実際の事例と開発での体験を通して、コミュニティと企業の相互作用について紹介します。

  • 株式会社メルカリ/株式会社ソウゾウ 上田 拓也、日高 正博

内容

  • エキスパートエンジニア職がある
    • 社外の活動5割、社内の活動5割で行える
  • 技術をアウトプットするところに技術が集まる
    • 社内で得た知見をコミュニティに伝えるのが基本
      • 実際にプロダクトを開発しないと得られない知見がある
    • 外のカンファレンスで得た知識を社内勉強会でチームに共有
    • チームメンバーに、勉強会への登壇や、Techブログの記事依頼も仕事のひとつ
    • 社外と社内で情報を回して知見を集めていくというサイクル
  • 技術コミュニティを通じて知見を得る
    • 1社が取り組めるプロダクトの数には限界がある
    • 色々な会社が参加しているので自分たちがまだ知らない知見を得ることができる
  • 海外カンファレンスへの参加
    • 日本で得られない知見を得る
    • 日本で得た知見を共有する
      • 日本のコミュニティのレベルは決して低くない
  • コミュニティで得た知見を社内に還元する
    • いくつか社内勉強会があるがだいたいが週1でやってる
    • 情報共有だけでなく社外へのアウトプットの練習の場にもなっている
    • Go Fridayのポリシー
      • 短期的なインパクトよりも継続することが最も大事
      • 資料の準備を頑張らない
      • スキップしない
        • 1度スキップするとクセになる
        • 雑談ベースでもよい
  • 技術教育と技術コミュニティ
    • ビギナーを支援していく
      • 敷居を下げていく活動が大事
      • ビギナー向けの情報や書籍は重要
      • 体系的に書かれた資料が必要
      • ハンズオン、学んだことをLTでアウトプットしてもらう
  • 貢献と還元を考える
    • 同期的な活動
      • 勉強会、カンファレンス
    • 非同期的な活動
      • 書籍の執筆、ブログ、情報共有
    • この2つを通じて貢献していく
    • 敷居が高いと感じるなら、自社プロダクトで使っているOSS部分の不具合報告、動作報などをフィードバックしてみるところから初めてみる
  • コミュニティへの貢献が組織を変える
    • エンジニア自身の知見がたまる
    • 社外から技術的なフィードバッグを獲得
    • 新しい技術を取り入れ、作っていく土壌の育成

所感

メルカリのブログに書かれていて既に知っている内容もありましたがこうやってまとめて聞けると良いですね。
社内の活動の成果と、社外の活動の成果の流れのサイクルを本当にうまく回していて素晴らしいです。 社外の活動に工数の半分を使ってもよくそれもきちんと評価に結びつけているということもすごい。

外部への関わりを評価する仕組みを自分が今いる組織にも入れられないか考えてみたいです。

組織と文化のリファクタリング

一度は良かれと思って始めたチーム体制や評価制度、あるいは社内の勉強会など…いつの間にかうまくワークしなくなった社内の「組織」や「文化」はありませんか。クリエイターたちが前向きに業務に打ち込んだり、モチベーション高く開発を維持するために、リブセンスで行った取り組みをご紹介します。

  • 株式会社リブセンス 海野 拓、内山 高広

内容

speakerdeck.com

speakerdeck.com

  • クリエイターの組織作りの事例紹介
    • 組織の特色
      • 事業部長が強い
        • ビジネス出身なのに自ら開発始める
      • 色濃い越境型組織
        • 職種の違いはあまりない
        • 営業もSQL平気でたたく
    • 課題
      • 事業部長に頼りきってしまう
      • 教育にコストがかかる
      • 評価に不公平感がでる
    • 評価の仕方の明文化
      • キーワードとして分かるように
      • 課題解決力だけでなく技術力でも評価
    • いろいろあって組織が再編成される
      • でも、今までやってきたことが次の組織へ
      • 良いところはそのまま取り入れられていった
  • 文化の形成、社内勉強会をリファクタリングした話
    • テーマ縛りのLT大会やってる
      • 昔は読書会だった
      • アウトプットの場にしようということからスタート
    • 最初始めたときは10回で終わった
      • 毎週一人一人と消えていった
      • 理由は飽きてきたから
      • いつも同じ人が発表しがち
      • ガチ勢じゃないと参加しづらいと思われがち
      • 内輪ノリになりがち
    • どう復活したのか
      • 取締役の退任がきっかけ
      • その時に、あれは良い文化だったと言ってもらった
    • 勉強会の良かったところを言語化する
      • これにより趣旨は悪くなかったことが分かった
    • 趣旨は変えずに内部を変えることに→リファクタリング
    • 新規参入者の促進
      • これまで参加してくれて人の楽しみは奪わないように
      • いつも発表してくれるコアメンバー以外にもアプローチできるように
    • また飽きていくことは大いにあり得る

所感

組織の再編成を乗り越えて、今までの取り組みが全社の評価制度の見直しになったのはすごいですね。良いところを次にも繋げていける体制は素晴らしいと思いました。組織が強くなるとプロダクトも強くなるという言葉が印象的でした。
自己組織化といっていましたが自立的な組織ですね。やっぱ大事だよなあ 社内勉強会をリファクタリングした話も印象的でした。1度はマンネリ化してしまったものを趣旨は変えずに中身を変えていくという取り組み素晴らしいですね。
こういう勉強会ってどうしても内輪になりがちなので新規参入者のことを考えていくことは本当に大事だと思います。敷居を下げているつもりでも対象者はそうは思っていないってことになりがちなんですよね。

eurekaの普遍的に優秀な人材として成長し続けるための組織づくり

エウレカでは、100名を超える多様なバックグラウンドを持ったメンバーひとり一人が気持ちよく働ける環境づくりと、いかなる環境においても活躍できる普遍的に優秀な人材として成長し続ける組織作り、文化作りについて紹介させて頂きます。

内容

www.slideshare.net

  • 自律と自立
  • 自己組織化されたチームが必要
  • タックマンモデルをベースにした
  • ドラッカー風ワークショップ
    • 嫌なことも好きなことも分かる
    • その人の地雷を避けることもできるようになる
  • インセプションデッキ
    • 判断基準に迷ったときの判断基準に
    • プロジェクトに対する認識のズレを減らせる
  • チーム内の対話を増やすことが大事
    • チームで対話して合意することが大事
  • チームの問題を自分事に
    • 偉い人の問題と考えないで自分の問題として扱えるように

所感

時間オーバーで最後まで話が聞けないのが残念でした。
自己組織化されたチームを作るためにどのような活動をしてどのような効果があったのか理解できました。
チームメンバーのことを知るためにドラッカー風エクササイズを実施するのは是非やってみようと思いました。 あとは、問題を自分の問題にするのは意識したい。ついつい、上の人が悪い、会社が悪いとか考えてしまいがちです。最近こういう傾向になりがちだったので改めて今抱えている問題を考え直したいと思いました。

コミュニティを長く続ける秘訣

本セッションでは、10年継続している企業主催コミュニティ、1年間でのべ6000人以上が参加した個人主催コミュニティ、そして年間600回もの勉強会が開催されるコワーキングスペースを運営するそれぞれの立場から、コミュニティのグロースや、持続的に運営する方法について語ります。

内容

企業主催の勉強会を10年続けたノウハウダイ公開

  • 株式会社ビープラウド 佐藤 治夫

www.slideshare.net

  • BPStudyは2007年9月から始めた(丸10年)
  • 今までに320人の方が発表してくれた
  • フリージャンルで多くの人に話せる勉強会
  • 心が折れそうになることも
    • 開催テーマの企画
      • 倒産する人が見つからない、見つかっても日程が合わないなど
      • 解決策 : 新刊技術書をチェック、カンファレンスページのチェックなどを行う
    • 集客
      • 50人会場で20~30人来れば人が集まっている感がでる
      • 解決策 : 告知時の導線の改善、Webページの紹介文の改善
      • ドタキャン対策
        • リマインドのタイミング、参加枠の調整など
  • なぜ発表するのか
    • 発表テーマを探す→自分の経験が整理される→勉強会で話す→自分の専門分野が見えてくる自信がつく→キャリアが変わる
  • 発表したら良い内容
    • 本に書いていない内容
      • やってみて得た知見、最新情報、コツ・独自の理論、デモ・ライブコーディング

個人主催でも4000人が集まった、IoTLTグロースの秘訣を探る

  • dotstudio株式会社 菅原 のびすけ

speakerdeck.com

  • なぜ参加人数が増えているのか?
    • 「IoT 勉強会」で調べると検索の上位になるから?
    • 毎回会場を変えている
    • 告知する媒体を分けている
    • 半数が新規、半数がリピーター。このバランスが良い
  • Tips
    • 頑張りすぎないのが大事
    • お客さん意識は特にしない
    • 片付けとかもみんなで
    • IoTLTは運営は2人しかいない

コワーキングスペースでたくさんの勉強会を支えてみて

  • コワーキングスペース茅場町 Co-Edo 田中 弘治

  • 会場費は参加者ひとり1,000円

  • 懇親会開催にも対応
  • 最初1フロアで運営していたが今では3フロアに
  • 会場を貸す側からみた良い勉強会とは
    • イベント内容を端的に説明できている
    • タイトルだけで申し込みしたくなるのが理想
    • 日程調整などの段取りが上手だと同日の進行もスムーズな傾向
    • 来て欲しい人が明確になっている
    • 開始時刻だけでなく開場時刻もきちんと書く

所感

長いことコミュニティを運営している方、継続的に集客しているコミュニティを運営している方、勉強会の会場を提供している方のノウハウや取り組み方を学ぶことができました。

BPStudyは継続的に月1回開催を10年間も続けているとか本当にすごいです。告知文を改善するためにWebライティングを学ぶというのは良さそうなので早速勉強しようと思いました。

IoTLTの緩い感じすごく良かったです。特に頑張りすぎないという話は印象的でした。参加者をお客様意識しないという考えは大事だなあと思いました。 どうしても「参加するんだからちゃんと対応しろよ!」という人が出てきてしまうと思いますが、そうは思わずに「緩い感じでもいいじゃん!」って人達が集まるようになってくるから良い雰囲気が継続できるのかなと思いました。

普段なかなかコワーキングスペースを運営している人の話なんて聞く機会が無いのでCo-Edoの話は新鮮でした。
勉強会を主催する人を大切にしている気持ちがビシバシと伝わってきました。こういう方のおかげで皆が学べる機会が提供されているのですね。

全体所感

コミュニティについて1日を通して考えることができて非常に有意義でした。

オープンな技術コミュニティも社内の技術コミュニティもコミュニティであることには変わりありません。さらには忘れがちですが、企業内の組織もまたコミュニティなのです。

内部、外部のコミュニティをどう繋げていくのか、どう相乗効果を出していくのか、そんなノウハウを学べた気がします。
コミュニティを盛り上げる方法、継続する方法に決まった定石があるわけではないです。自分のコミュニティにあった方法を他のコミュニティからパクりつつ最善な方法を探し続けていくことが大事なのだと改めて思いました。

私自身、社内のTechイベントみたいなものを主催しているので今回得たことを取り入れていって、ゆくゆくは社外も巻き込んでの情報共有ができていけるように精進していこうと思います。

Amazon Echo Showが発表されました

噂されていたAmazon Echo Showが発表されました。

噂通りのスクリーンのついたもので、6/28発売のようです。

www.amazon.com

開発系情報を発信しているAlexa BlogにもEcho Showについての記事があがっています。

Introducing the All-New Echo Show : Alexa Blogs

商品説明と開発者Blogを見たファーストインプレッションをTwitterでつぶやいていたので忘れないようにまとめておきます。

音声アシスタント分野ますます面白くなってきました。 これによりAmazonの独走状態がさらに続くのか、それとも他社も負けじと何か出してくるのか楽しみなところです。

しかし、MicrosoftのBuildの前日に発表してくるとかさすがですね…これでCortana Skills Kitの存在がちょっと薄くなってしまう。