しょこの雑記

IT時々女子力

ずっとLTしかやってこなかった私がJJUG CCCでカンファレンス登壇デビューした件 #jjug_ccc #ccc_m62

この記事では、以下の3点について書いています。CCC参加した感想は別記事に書く予定です。

  • JJUG CCC 2016 Springで発表した様子と感想
  • なぜCCCで登壇デビューしたか
  • 登壇デビューまでに何をしたか

カンファレンス登壇デビューした

JJUG CCC 2016 Springでカンファレンス登壇デビューしました!!
LTは何度もやったことあるけど、カンファレンスでの登壇は初めてでした!
とても楽しかったのと、もっといい発表したいので、また話したいです!!

JJUG CCCとは

当日の発表の様子と感想

発表資料

speakerdeck.com

発表内容

f:id:sd_ts1017:20160522225002j:plain

ライブレコーディングをTwitterにUPしてくださる「なかやまさん」に書いていただいてました。ファンなので感激!

会場の様子

f:id:sd_ts1017:20160522224838j:plain
togetter.com

直前のセッションから立ち見状態が続くほど多くの方に来ていただきました、ありがとうございます!全体の約8割がJavaエンジニア、1人がScalaエンジニア、約2割がその他言語(RoRなど)のエンジニアでした!

発表の感想&反省

初めての登壇はやりきった感ともっと話したい感が高まった!また登壇したい。
デモには悪魔がいるとは聞いていたが、本当にうまく動かなくて残念。でも、Twitterや懇親会で話した感じだと好評だったようで何より。

なぜJJUG CCCで登壇デビューしたのか

端的に言うと「今まで登壇したことない私にとって一番敷居が低かった」からです。

なぜ登壇デビューしたかったのか

もっとTechな内容を語れる人間になりたかったからです。
2015年の1月に初めてLTして以来、1年で10回以上社外の勉強会でLTしてきました。でも、そこで話している内容は初心者の域を脱していない(入門してみた、触ってみた)ものや、そもそも技術の話じゃないこと(女性エンジニアコミュニティの話とか、業務効率改善の話とか、キャリアとか)ばかりでした。
これではいつまで経っても「エンジニア」というよりは「人前で話すのが好きなIT系で働いている女子*1」を脱していないと思い、それは嫌なので、2016年に入ってからは技術的なLT登壇を意識しています。(今年の目標で「何かのカンファレンスで登壇する」というのも立ててました。)

JJUG CCCでデビューしようと思った2つの理由

一番は20分枠という、登壇初心者向けのセッションが用意されていたからです。そしてもう一つは、Javaコミュニティにはたくさんの友人・知人がいるため、心強かったからです。
まず20分枠について。「20分なら話せるかも」って思いました。LTで登壇したことは何度もあったのですが、長く話すことには抵抗・不安がありました。50分セッションしかなければおそらくCfPも出さなかったでしょう。でも、20分だったら「いつもLTで話しきれないことも話せそう」「デモもできそう」「20分なら一人で話せそう」。だからチャレンジしてみることにしました。
そしてコミュニティ。Java女子部へ参加したのをきっかけに、Java界隈の友人が増え、JJUGナイトセミナー、JJUG CCC 2015 fallと参加していきました。今回のCfPを出す時も、直接「やってみない?」と誘っていただいたり、色んな方に背中を押されたので出せました。そして多くの方に投票していただいたおかげでCfPが通り発表することができました。
私はJJUG以外の勉強会にもよく顔を出しますが、ちょっと怖い、登壇する人はいつも本を執筆している人ばかりでLTすらおこがましい、みたいなところもあります。そう思うと、JJUGは一番*2落ち着きます。

登壇デビューまでに何をしたのか

LTの時にはやったことない「似たような内容を一度発表してfeedbackを得る」を今回はやってみました。

Javaエンジニアが少ない「dots.女子部」でLTしてみた

JJUG CCC 2016 Springの前日、dots.女子部のイベントで似たような話をしました。

【満員御礼!増枠】 dots.女子部 - オールジャンル女子エンジニア集合!tips共有会vol. 2 〜私、この技術に恋してます♡〜 - dots. [ドッツ]

https://speakerdeck.com/sdts1017/scalanu-zi-hakatukoii-number-dotsgirlsspeakerdeck.com

女子部で得られたfeedbackの取り込み

LT後の懇親会中に、たまたま参加していた先月からプログラマな新卒Javaエンジニアの方にデモを行って見せたところ
「Activatorがあるのがいい!」
「何でググればいいかわからないことがTutorialにあるのがいい」
と好評でしたので、それをPlayの良さとしてJJUG CCCのスライドに追加しました。
また、「デモ見たら本当に簡単なんだ!ってことがわかってよかったです」と言っていただいたので、JJUG CCC当日は、画面のスクリーンショットを見せるだけの予定から変更し、実際に動かしてみることにしました。
毎回こうやってfeedbackを得られるとは限らないとは思いますが、今回試しにやってみて良かったです。難点は、忙しいタイミングで二つ発表資料作る必要があることですね・・・前日に変えてスマートに発表するのはさすがにできませんでした…反省。

まとめ

LTしかやったことない登壇初めてでしたが、得るものが多く、やって良かったです。
また、自分の運営する勉強会やイベントが、いつかカンファレンスとかで登壇するときに備えて練習できる場でありたいなと、改めて思いました。
最後に、20分枠という良い場を提供してくださったJJUGの皆様ありがとうございました。次は50分枠で話してみたいです。

*1:実際、いろんな勉強会で知り合った方と話すと「え、がっつりプログラミングするエンジニアだったんだ、知らなかった」と言われること結構多かったんですよね。ハンドリングだけするSEとかディレクターとか営業とかそっち系に見られることが多い。

*2:運営で入っているコミュニティdots.女子部の次に

千葉・金谷の「まるも」に開発合宿行ったら最高だった

金谷最高だった。開発合宿にも旅行にもいい。また来たい。

拠点:金谷

  • f:id:sd_ts1017:20160501153606j:plain
  • 千葉県富津市金谷(かなや)
  • 観光地。秘密要塞みたいな「鋸山」が有名
  • 海がとても綺麗で、地魚たくさん。美味しい。

アクセス

主な作業場

  • コミュニティスペースまるも f:id:sd_ts1017:20160501153711j:plain
  • 公式HP
  • 1Fが共用+貸切スペース、2Fがシェアハウス+テラス
  • 24時間開発可能。その他素敵な特色たくさん。HP要チェック。
  • 光回線Wi-Fiあり(↓32Mbps/↑43Mbps)
  • 2FのテラスでBBQもできる。食材も用意していただける。
  • 本当に至れり尽くせりでした。

宿泊所

  • ゲストハウスしへぇどん
  • まるもから徒歩数分のゲストハウス
  • 1泊2日食事付きで5000円/人
  • ベッド4つ+和室に布団敷いて雑魚寝スタイル
  • 地魚をふんだんに使った夕食。美味しい。
  • オリジナル地酒「しへぇどん」も飲める
  • 本当に至れり尽くせりでした。(2度目)

費用(8人で行った場合)

  • 「でもお高いんでしょう?」いやいや、お得だった。
  • まるも利用(貸切)料金:5000円/人(何人でも40000円/日)参照
  • まるもBBQ(道具レンタル+食材準備)料金:2500円/人
  • しへぇどん(1泊2日夕食付き)料金:4500円/人

その他施設

温泉:かぢや旅館

  • 公式HP
  • ゲストハウスにお風呂がないのでここで入りました(700円/人)
  • 一通りのアメニティあり。
  • 季節限定で高足ガニを食べれる(今回は食べていない)

食事処

浜焼き(行ってない)

回転寿司(行った)

コーヒー(行った)

  • cafe edomons
  • のぼりに掲げるのは「珈琲道」本格コーヒーがいただける喫茶。
  • 合掌造りの喫茶で、一階は喫茶スペース。二階には大量の絵画。気軽に美術を楽しんで欲しいとのこと。
  • バームクーヘンもとっても美味しい。

ピザ(食べた)

UI Crunch#8行ってきた #uicrunch

UI Crunch行ってきました。倍率8倍とか凄すぎ。 まとまったブログとかはメディアの方からありそうなので、口頭のみの内容込みで書き起こしたので見てみてください。 発表資料は公開され次第追加します!

ui-crunch.connpass.com

感想

  • 早く会社に持って帰りたい。語りたい。
  • デザイナーがエンジニアリングする、といえど関わり方は様々だった

テクニカルクリエイターが担う、サービス開発のUIモックの現場 〜サイバーエージェント流〜

スピーカー

今日のポイント

  • Point1:ネイティブアプリ市場ではより高度な表現が最重要
  • Point2:心地よいユーザー体験が強豪優位性となる(日本のUIはまだまだ低い!)
  • Point3:デザインとエンジニアリングの中間を担うツールが整ってきた(Prottとか) デザインの敷居が下がってきたし、Swiftもデザイナに近寄ってきたと思っている。

テクニカルクリエイターとは?

  • 一人多彩(いっとたさい)なクリエイター
  • 表現の幅が広く、プログラム言語/アニメーションを自在に扱えるクリエイター

CAのモックアップ紹介

AbemaTV(インターネットテレビ局)

  • 藤田「そろそろテレビをスマホで見る時代が来てもいいよね?とにかくスマホで快適に。番組制作はテレビ朝日と組むからさ。」
  • 藤田「アプリの品質にこだわってくれ」
  • ラフモックアップ(開発当初のモックアップ)はFlashで作成。iPadアプリを想定していた
  • コンセプトモックアップ(性的デザインと同時に、Flashでアニメーション化してサービスの全体ループを作成し、**「心地よい視聴体験」=「ザッピング」にフォーカス。
  • DetailMockUpはPixateで詳細に作り込んだ。

AWA

  • 藤田「avexの松浦社長と釣りしてたら音楽アプリやることになったんだけど、とにかくオシャレで一見海外から来たような世界観でお願い」
  • Interaction専用アプリ「AWA-IxD」を開発(XCode)。Pixateとかではなく製品版として作ってた。
  • ローカルで動けば十分な程度で書いた。
  • 現実世界の動きとアニメーションの間にギャップを作らない。ユーザーの連続的な動作とアニメーションの間にギャップを作らない。
  • 横スクロール時にパララックスエフェクトを掛けることで「背景であること」を直感的に理解する手助けをしている。

ぺこり

  • モックアップはPixate
  • デザイナーがクオリティの高いモックを作る

3Q

Design/Interaction/Planningサービスの品質の構成要素

Design Quality

  • UI・デザイン
  • 約30サービスを佐藤さんが月1チェック
  • デザイナー・プロデューサーへのFB
  • 全体でのデザインFB

Iteraction

  • 遷移・トラジション
  • 今週作ったoutputをデザイナとエンジニアがペアで参加し、サービス毎のtipsや実装アイデアの共有
  • デザイナー向けSwift研修とかエンジニア向けデザイン研修
  • Lica

Planning

  • 代表の藤田さんはじめ現場のトップがレビュー

Conclusion

  • サービスづくりにおいてデザイナーとエンジニアが近づいている
  • テクニカルクリエイターには十分なベーススキルが必要。それがなければただの器用貧乏。
  • サッカーのDFでいうとリベロみたいなもの。エンジニア、デザイナーの「新しい役割」。
  • 自分の強みを理解し技術を巧みに応用する。すべてに長けている必要はなく、最適なアウトプットのための応用力が重要

エンジニアリングするデザイナーが領域を超えて見えたこと

スピーカー

なぜ領域を超えたのか

きっかけ

  • とあるプロジェクトの失敗がきっかけ
  • プロジェクトの状態(バグだらけ。作り直しが必要な状態。リリースまでに残された時間が2か月。厳しい)
  • リリース時点でのタスク消化率がSystemばかりだった。
  • リリース後「文章が途中で見切れてて最後まで読めない」「変なマージンが空いてる」「これではユーザー体験が損なわれてるじゃないか」
  • 反省点:(1)ユーザー体験が損なわれず実装コストも下げられるuI変更の判断が瞬時にできず、エンジニアの負担が減らせなかった。(2)リリースに最低限必要な期間を見積もれず、ビジネス側へ説明することができなかった
  • デザイナーが変わらなければ何も変わらない
  • 実装に関する知識と自分で実装できるスキルを身につける必要があった

領域に入り込む前の葛藤

  • 両立の手法が未知→やってみなきゃわからない

何をしてきたのか?

環境セットアップ

  • 作業したデータを実機で確認することや、共有する。
  • Xcode, Provisioning File作成, Git, GUI tool, Cocoa Podsで導入

UI実装

  • Xcodeでチャレンジ
  • 難易度1:storyboardで配色とFontsizeを変更した
  • 難易度5:マージンの調整しはじめる。auto-layout難しかった
  • 難易度3:画像の比率をしてい
  • 難易度2:角丸つけたい
  • コード書き始める(ここまで3か月くらい)
  • 難易度4:viewDidLoad()内にコードを書き始める
  • 難易度5強:TableViewのレイアウト実装。UGCの実装になると絶対必要になる。
  • 今はアニメーションの実装できるようになりたい(CoreAnimationでInteractionとTransition)
  • これができればXcodeでデザイナーがプロトタイプ作れるようになるのではと思っている

なぜ領域を超えられたのか

  • スキルセットの原点があった。
  • Flash制作していた時のAction ScriptとかWeb制作じのJava ScriptがSwift書く力の元になった
  • 組織のサポートがあった
  • チームに積まれているタスクのうちエンジニアリングの内容のものをできる範囲で消化する開発ルールで、現場で学ぶ環境となった(Google20%ルール)

何が変化したのか?

領域を超える以前と今

開発スタイルが変わった!

  • 以前はガイドを書いてエンジニアにレビューしてもらってた。開発の人がタスクいっぱいになる。
  • デザイナーが実装すると、エンジニアの全体タスク量が減る。開発終盤にプロデューサーからくるデザイン修正をデザイナーができる。

作業コストが変わった!

  • 両立の手法は見出せた!
  • 実装に参加し始めた頃は作業コストが増えたが、UIの実現方法で悩む時間が減ってエンジニアリングのタスクと両立できるようになった。

アウトプットが変わった

  • エンジニアがパッと見て実装イメージをつかめるようなアウトプットに変わった

スキルを活かす

  • 高速プロトタイピングの実現。デザインプロトタイプを廃止し、デザイナーとエンジニアが並行して作れば実装レベルのプロトタイプが作れるはず。
  • ゲームの現場はもうそうなりつつある。
  • 見込める効果:企画プレゼンやユーザーテストをより早く実現できる。本開発に向けての明確な課題の洗い出しが可能となる。プロデューサーや上のレイヤーにも理解を得やすくなる

領域を超えることのススメ

  • デザイナーが実装することは今となっては当たり前の概念となりつつある。
  • デザイナーの学習コストは避けられない。周囲の理解が必要。

コードをコミットできなくたって大丈夫

スピーカー

  • 株式会社Gunosy
  • デザイナー 森浩明さん
  • 他の企業と一緒に何かやりましょうっていう部署
  • 主にiOSのネイティブアプリ書いてきています

プロダクトやサービスの実装に関わらなくても大丈夫?

  • 実装するとなると不安なこと:時間/品質/プレッシャー/必要性/学習/他に重要なこと・・・
  • 他に重要なことって何?:デザインとか!
  • コードを書かないほうがいいのか?→プロダクトの周辺で積極的に書きましょう!
  • プロダクトの周辺:開発にコミットするようなコードではないところ。開発の助けになるコードを書く。

おすすめすること

  • (1) STUDY :自分の関わってるものを勉強してみる。
    イデアを形に/アプリや断片,気づきがある/問題の解決。
    エンジニアの人に笑われそうなコードでもまずは形にしてみる。
    Processing.jsのエディタを作ったことをきっかけに、どうやって作るかどうか

  • (2) TOOL :自分が使うものを自分で作ってみる
    日々使うツールを自分で作ってみる。気の済むまでアップデート
    Illustratorプラグインをjsで書いた。
    スクリプトを使って選択したパスを出力し、それを貼ればiOSのコードに使える、みたいなことをやっていた。
    「自分で作ったほうが早いな。」

  • (3) PROTO :コミットしない程度だけど製品に生きる
    ちょっとハードル高くなったよ!
    動くプロトタイプ/実際のデータ/テストしてみる/本番に近い/フィードバック
    実際のデータで実際のユーザーに使ってもらえる。
    リリースするものには書いていないので気楽にコード書いてテストできる。

なんでこの話した?

  • 外国人に道を尋ねられた時の「英語勉強しよう」というのと同じ。勉強しようと一時的に思う、でも長続きしない。
  • テンション上がるけど、実際のプロダクトにコミットするのはかなりハードルが高い。
  • だから、その前くらいのレベルでコードを書いて、良さを得ていくのから始めていってもいい。自分がそう。

全員がコードを書く会社では どんな感じでデザインしてるの?

スピーカー

  • ウォンテッドリー株式会社
  • デザイナー 青山直樹さん
  • 2015/6Join.今はSyncやってます
  • iOS/Android/Webアプリの実装どれもて入れちゃってる

「デザインもコードも書きたいデザイナーWanted!!」を見てWantedlyにJoinした

  • Wantedlyでは社員のほとんど、デザイナーの全員がコードを書きます
  • CEO/人事部長/デザイナー多かれ少なかれ書いています

なんで書いてるの?

デザイナーに聞いてみた

  • 学生時代建築・プロダクトを勉強していたが作るのにはお金がかかる。「ソフトウェアならタダじゃん!」
  • HTMLマークアップの延長で、ごく自然にやっている
  • 作りたいのは絵じゃなくてプロダクトから、自分で書いた方が効率的に目的に近づけるんじゃないですか?

つまるところ

  • 技術によってしか到達できない表現がある
  • チームでの開発プロセスの効率化
  • デザイナーもコードを書ければリリースまでの時間の仕事の幅が広がる

Wantedlyでやってること

  • よくあるデザインのプロセス:コードが書ければ実は全部不要かもしれない!?
  • ワイヤーフレーム・画面遷移:MTG中に済ませてしまう。デザインに時間があれば、画面デザインと一緒に
  • 画面デザイン:標準的なグラフィックであれば、描かない
  • プロトタイピング・指示書作成:作ってしまった方が、早いかも?
  • エンジニアとのコミュニケーション:GitHubのPull Requestベース。
  • エンジニアと共通の基盤・言語で会話できてスムーズ
  • 実装時に巻き取れる自信があれば、リリース時のクオリティは担保できる
  • 毎回のプロセスをシンプルにする一方で何度でも使える「環境」を整備
  • アイコンライブラリをWebフォント化していつでも使えるように
  • ガイドラインとしてパターンを出して、実装にコンポーネントとして組み込んでおく。
  • デザインの一貫性を確保し、後の追加・変更を簡単に。
  • 理想:作りたいことをつくる!!間にあるものは無駄!減らしたい!

まとめ

  • プロジェクトの進め方を大胆に最適化して、無心で完成度にフォーカスできる

デザインと技術をつなぐ

speakerdeck.com

スピーカー

  • 株式会社グッドパッチ
  • 執行役員CTO ひらいさだあきさん
  • SIer->カカクコム->GoodPatch

Goodpatchのデザインプロセス

  • チームビルディングをしてからものを作っていく

デザインと技術をつなぐ

Why:良いプロダクトを作りたい

  • エンジニアが要件定義や設計フェーズから関われないと、良いデザインが作れない
  • 例)サービスの基本設計とか、バックグラウンドでのタスク実行とか

How:早いフェーズでプロジェクトに関わる

  • よくある(1):要件定義の期間が長く、開発期間が短い。
  • よくある(2):開発に入らないと、エンジニアがアサインされない。

What:プロジェクトへの関わり方を見直す

  • AndroidデベロッパーがMaterial Designアドバイザーとしてプロジェクトに参加する
  • iOSデベロッパーがUXデザイナーとしてプロジェクトに参加する
  • Material DesignやHuman Interface Guidelinesは実装の経験がないと理解することが難しい
  • メタファーを理解した上でアプリケーションの設計をする必要がある

Android

  • Android DeveloperをMaterialDesignアドバイザーとしてプロジェクト(アプリのリニューアル)にアサイ
  • 最適なコンポーネントの提案
  • 実装の確認、修正方法の提案

iOS

  • iOS DeveloperをUXデザイナーというロールを持ってプロジェクト(サービスのアプリ対応)に関わる
  • どうサービスを切り出してアプリケーションにするか提案
  • サービスの強みを生かすためにどういったアプローチができるか提案

Webのこれから

  • Webアプリもネイティヴアプリのように設計する必要が出てくる
  • サービスデザインから考える必要がある
  • ネイティブアプリを作るのか?Webの方が良いか?
  • インストール試作、プッシュ通知の設計、オフライン対応、コンポーネント・・・

Progressive Web Apps

  • ネイティブアプリに近づくWebアプリ。
  • オンラインでもオフラインでも動作する
  • Engagement(プッシュ通知とか。Service Workerとか)
  • インストールできる

Web Components

まとめ

  • レビュー/インサイト発見/コンセプト設計/デザイン実装
  • ここをスムーズにするためにデザインと技術をつなぎたい。
  • 1991:HTTP, 1993:HTML, 2007:iOS, 2008:Android
  • 技術によって領域が広がり、デザインによって洗練される
  • デザインを実現するために技術が必要で、自分の持ってる技術を魅せるためにデザインが必要。

質疑応答

佐藤さんへ:開発の時にどれくらいデザインにこだわって投資対効果を出すか

  • 自社サービスなので基本的にこだわる
  • ただ、リリース優先の場合はかなり機能を削る場合はある。
  • そこでも、エンジニアとデザイナーの目線を合わせる。妥協しないものづくりは大事。

青山さんへ:どうやって開発プロセス改善できた

  • スタートアップだから元々そういう文化だった
  • ただ、文化を作るのは人だから、今いる人から考えていけばいい

それぞれの会社の人へ:どういうエンジニアにJoinしてほしいか。特にネイティブアプリについて

  • ひらいさん:デザインに興味があるエンジニアと一緒に働きたい。ネイティブだと自分でアプリを公開まで持って行ったことある、ガイドラインを理解した上で開発している人。
  • 青山さん:一緒に作りたいものを作るエンジニア。自分が作りたいと思ってるものを作ろうとしているエンジニアはかっこいい。アプリの仕様変更をしなきゃいけないって時に、そんなこともあろうかと3ヶ月前から準備してました、って言われた時はかっこよかった。
  • 森さん:その道のスペシャリスト+自分の専門領域外に目を向けられる人。
  • 成澤さん:責任をもたせてくれるエンジニアと、アプリの配色を作り上げる途中に「これってどういう雰囲気のアプリなんですか?」って聞いて、「それに合わせたエフェクト作ってみたよ」って関わってくれるエンジニアさん。
  • 佐藤さん:柔軟なエンジニア。

デザイナーはエンジニアによるべきか、経営によるべきか

  • 佐藤さん:CAの場合、技術を見てる場合じゃないということもある。デザインの指摘をしている途中に企画の指摘をしている時がある。デザイナー・プロデューサーと意思疎通できるように。エンジニア・デザイナー・プロデューサー三位一体で企画を練って、開発しています。
  • 成澤さん:DeNAもCAと似ていて、実装の段階と企画の段階が分かれている。三位一体で企画からエンジニア・デザイナーが入る、むしろエンジニア・デザイナーが覆す時も。判断のスピードをどんどん上げていくべき。自らがプロデューサーになったつもりでキャリアアップしてくべきという社風。
  • 森さん:エンジニア・経営どちらかではなく、全方向向かざるをえない。
  • 青山さん:Wantedlyにはディレクターがいない。一人の人間がデザイナー・エンジニアリング・経営など全てバランスを取ろうという必要はない。尖ったとこがある人間がチームを組むのが一番いいと思ってます。
  • ひらいさん:尖っているところを合わせていけばいいと思ってる。ビジネス的感度が高い人がエンジニアだろうがデザイナーだろうが誰でもチームに一人いるといい。スキルとしてビジネス・エンジニアリング・デザインを高いレベルで保つ必要がある。

Women Techmakers in Google Japanに行ってきました #wtm16

今日はWomen Techmakers in Google Japanに行ってきました!

Togetter

togetter.com

イベント概要

Women Techmakersとは?

Googleが主催するテクノロジー業界で活躍する女性向けのイベント。 毎年3/8の国際女性デーに合わせて世界各地で開催されています。 www.womentechmakers.com

日本版の概要はこちら。 googledevjp.blogspot.jp

感想とか

  • 終始inputもお腹もいっぱいのイベントだった!来年も行きたい!
  • 何かしらのイベントであったことある方とたくさん話せてよかった!
  • 日本で働く海外のエンジニア多くてよかった!
  • 男性も2人だけ来ていた。「どうすれば女性がもっと働きやすくなるか知りたい!」とのこと。すごい!!

Keynote - Xinmei Cai

  • All Englishセッションだった。半分くらいしか分からず・・・
  • キーワードは"Our Time To Lead"
  • 日本はまだまだ少ないけど、女性でも気にせずにリーダーすればいい。

  • 英語もっと勉強したくなった。聞き取れないってのもあるけど、伝えたい方が強い。

パネルセッション

  • ロールモデルは特にいない。自分でいいなと思った要素をもとに、自分の中に作り上げていく。
  • プログラマかっこいい!と思えることと、それが自分もやればできる!ってのが成り立ったらプログラマ増えそう

デザインスプリント

  • Google Ventureで公開されているデザインスプリントの方法でやりました。

www.gv.com

  • HMW=How might will ?= 誰がどんなシチュエーションでなにがあったらいいか?
  • デザインスプリントは一定期間内に5つのフェーズで進める。
  • Understanding->Sketch->Decode->Prototype->Validate
  • 一定期間=4-5日の場合、最終目標は「新製品・アプリの最終画面」
  • 一定期間=2-3日の場合、最終目標は「会員登録のフローをなおす」等一部にフォーカス
  • 一定期間=1-2日の場合、最終目標は「LPだけでも直す」
  • このやり方、何にでも使えそう!!!!使っていきたい。

懇親会

美味しい!!! f:id:sd_ts1017:20160319200449j:plain

Developers Summit2日目参加したよ。 #devsumi

昨日に引き続きデブサミ参加しました!
今日はほとんどAWSとDevOps系。
昨日懇親会でてないから、なんだか消化不良・・・

参加したセッションまとめ

19-A-1 日本発IoTプラットフォームビジネスへの挑戦 〜 SORACOM 立ち上げ格闘記 〜

セッション概要

Togetter

2016/02/19 デブサミ2016【19-A-1】日本発IoTプラットフォームビジネスへの挑戦 〜 SORACOM 立ち上げ格闘記 〜 #devsumiA - Togetterまとめ

一言感想

19-E-2 実演&全員参加型 - 鳥肌必至のニューラルネットワークによる近未来の画像認識技術を体験し、IoTの知られざるパワーを知る

セッション概要

Togetter

デブサミ2016冬 19-E-2 - Togetterまとめ

一言感想

  • 実演&参加型のセッションで楽しかった!デモもスムーズだったしわかりやすかった。
  • Oracle Database Cloud Service熱い。ベンダの出しているDBはパッケージばかりじゃないことに驚き。
  • Oracle Database Cloud ServiceはJDBCいらずで、REST APIでデータ取得できるのは嬉しい。
  • 紹介されていたTEDみよう。

www.ted.com

19-A-L 非クラウドエンジニアのための「はじめてのAWS

セッション概要

Togetter

そのうち

一言感想

  • AWSができる幅って広いなと思いました。MLBでも活用されていたのは初耳!
  • AWS初心者がつまずくところは、AWSに関係ないところが多いけど自分でなかなか解決できないので無料ハンズオンでやるべきだとわかった

19-A-3 AWSで実現するクラウドネイティブなアプリ開発のポイント

セッション概要

Togetter

そのうち

一言感想

  • 知らないことだらけですごい焦った。
  • 駆け足でついていけなかったところもあったけどすごい濃かった
  • The 12 Factor Appしっかり理解せねば。

19-B-4 そろそろ俺たちの本気を見せてやるぜ!~ マイクロソフトOSSごった煮 DevOps 衝撃デモシリーズ!

セッション概要

Togetter

そのうち

一言感想

  • とにかくテンションが高かった!周りが静かで騒ぎづらかった・・・;
  • ツールを入れればDevOpsになるのは大きな間違いと言い切ってくれて嬉しい
  • DockerCraftが動いているの見れてテンション上がったw

19-A-5 エンタープライズでもクラウドファースト!Amazon Web Servicesをフル活用する

セッション概要

Togetter

そのうち

一言感想

  • 今の自分に生きそうなセッションだった。
  • AWS有識者がない中で2年かけてAWSへの移行、ちょっと安心した
  • 仮想データセンターからクラウドフルマネージドへ!

19-E-6 DevOps事情 AWSやAzureでの構築運用の失敗ナレッジからの学び

セッション概要

Togetter

そのうち

一言感想

  • 製品説明が多かった。
  • 会場近くの作業の音がしばらくうるさかった・・・残念。

Developers Summit1日目参加したよ。 #devsumi

今日はデブサミもといDevelopers Summitに行ってきました!
初参加です。明日も行くけどとりあえず1日目まとめ。

event.shoeisha.jp

各セッションについて

18-E-1 DevOps時代に明日から生かせるセキュリティ対策術 - 仲田翔一さん

今日聞いたセッションで一番今すぐ使えそうなセッションだった! event.shoeisha.jp

speakerdeck.com

1. セキュリティ対策に関する二つの勘違い

勘違い(1) セキュリティ対策は難しい

Why?
1. 考慮すべきセキュリティ事象が立場・工程によって違う。
2. システム固有のビジネスロジックに加えOSI参照モデルの第1層から第7層までの理解が必要となる(目に見えないサイバー空間のセキュリティが対象)

でも難しくないよ! - 攻撃者はセキュリティ対策が甘いシステム・意識が低い利用者を狙う。 - ちょっとしたセキュリティ意識向上やセキュリティ対策でも十分効果ある - 研究レベルの堅いセキュリティはむしろ突破したくなるので、ほどほどがちょうどよい

勘違い(2) セキュリティ対策は後回しにしてよい

Why?

  • セキュリティ要件は非機能要件&&セキュリティ要件&&実装は任意&&ユーザ満足に非直結&&コスト・時間もかかる

でも必要だよ! - セキュリティ対策は当然と解釈された判例がある!! - セキュリティ対策を必須のものとして考慮することが重要なので、後回しにしてはならない!

2. 効果的なセキュリティ対策を実現するには

設計・開発工程が肝。
1. 設計・開発工程でセキュリティ対策するのが最も効果が高い
2. 設計・開発工程でセキュリティ対策するのが最もコストが安い

3. OWASPの成果物をどう使うか

1. Top10 - OWASPが誇る最高の成果物

  • ウェブアプリの10大脆弱性とそれを作り込まないための対処法を理解するための資料。
  • 公的な機関の品質要件に書かれているほど良いもの!

2. Cheat Sheet Series

  • 設計・開発時のリファレンスとして活用したいチーとシートが多数存在

3. Proactive Controls

  • ウェブ開発における事前対策用
  • 脆弱性を事前に除去または提言可能なセキュリティ技術を紹介
  • OWASP Top10のどの脆弱性に対応できるかを把握できる

4. ASVS

  • セキュリティの取り組みの設定・確認に!
  • 自身が所属する組織ができているセキュリティ対策とできていないセキュリティ対策がわかる

5. ZAP

  • 一歩進んでウェブ脆弱性テストに!
  • 初学者にも玄人にもウケがいい診断ツール
  • 実行ボタン1つで出来るので使い易い

6. IoT Top10

  • IoT向けOWASP Top10
  • IoTでもウェブセキュリティの知識が不可欠

18-B-2 データ分析で始めるサービス改善最初の一歩 - 石原翔真さん

event.shoeisha.jp

すごいつぶやいたからtogetterを貼ります

togetter.com

18-E-3 クラウド・ネイティブ時代の2016年だから始めるDocker基礎講座 - @zembutsu

今日聞いたセッションで一番ためになったしわかりやすかった! event.shoeisha.jp

  • 扱うこと「Dockerをどう使っていくのか?」
  • 扱わないこと「コンテナ技術について」

Agenda

  • 1.改めて「Docker」とは何か?
  • 2.技術選択の要素
  • 3.最新動向(Docker 1.9, 1.10)

Togetter

togetter.com

18-E-4 FinTech 金融とテクノロジーの◯◯な関係

使っている技術等詳しい話まで聞けなかったのが残念だったが、FinTechスタートアップの立ち位置が聞けた。
国に規制されている事業(資産運用等)のスタートアップは少ないとのこと。

18−D−5 アジャイル開発でハードウェアをつくる~イノベーションはラーメン食えればいい!~

event.shoeisha.jp

タイトルと登壇者写真を見て、完全にネタ系かな?と思ってたのだけどしっかりした内容だった!そしてやっぱり面白かった!

  • 最初から完成形ではなく、スモールスタートで行こう。利益は一ヶ月でいっぱいラーメンが食える程度を目安にする。
  • 材料費を抑え、ワークショップ等で使ってもらってフィードバックを得て、たくさんピボットしよう。

18-D-6 開発者が押さえておきたいクラウドネイティブ時代のITインフラのトレンド

オンプレミスのここ5年くらいのトレンド説明だったので、知ってたor理解が容易かった。特段新しかったのは、vSphere Integrated Containersってくらいかな。
EMC傘下に入ったからかストレージの話が中心だった。

18-A-7 大企業からのエンジニア主導の企業と経営

event.shoeisha.jp

togetter.com

Yahoo! Tech Conferenceで唯一Yahoo!じゃないなと思ったら、社内ベンチャーからの子会社化したところだった。
Hack Day!という24時間の成果を3分半で発表するのがいい取り組みだと思った。
あとは、精神的・肉体的なモチベーションを考慮して経営しているってのは面白い観点だった!

その他

  • MozillaFirefox OSのTVアプリデバッグ楽しかったw
  • cybozuさんのバナナと電源/Wi-Fiとドリンクが無料なカフェの居心地が良かった。
  • 製品説明セッションに当たった時50分いるのは苦痛だった(途中退出した)
  • 個人スポンサー優遇されてるな・・・両日行けるなら個人スポンサーはかなりアリ。