読者です 読者をやめる 読者になる 読者になる

Developers Summit 2017に行ってきた(1日目) #devsumi

今年もデブサミに行ってきた。
一日目に参加したセッションのメモと感じたことなど。

codezine.jp

確実に良くするUX/UI設計

感じたこと・考えたこと

コアコンセプトを決めて一貫性のあるポリシーでプロダクトを磨き上げていくことは大切だなと思った。
検証と学習が軸になるのは、いつでもどこでも変わらない。

  • アプリ開発10箇条いいなぁ
  • 大体うまくいかないときというのは問題が複雑に絡み合ってるから、外部から大きな力を入れるというのは手だよなぁ
  • 実装を進めてからデザインに落とし込むアプローチはよい
  • フォードの話はいろんなところで聞くけど、好きだなぁ
  • コアコンセプトみたいなものを定義していくのは大切だし効果的だと思う
  • バッターボックスに数多く立つの大事
  • サービスとしてのコアが固まったら機能で小細工する必要はないんだよなぁ

リニューアルはどんなに丁寧にやっても何かしら失われる価値がある 構造を整理し矛盾を外し、リリース後に補完していく

「リニューアル」を「何かを変えること」に置き換えるといろんなことに当てはまる気がした。

Memo

  • なぜ大幅リニューアルは失敗しやすいのか?
    • 思いつきでリセットするから
  • ダメPDCA
  • 実生活だと意外とできてる
    • 結婚式のスピーチ
    • 実生活は皆試したがる
      • 車の試乗、ワインの試飲、物件の内覧。。
  • まず軽く試す、ダメなら辞めるか変える
    • 事前調査
    • 複数の実験
    • 利用者テスト
    • 改善
  • 日経電子版リニューアル事例
  • 100徳ナイフを作ろうとしていた
  • コアコンセプトを決める
  • アプリ開発10箇条
  • 事前調査
    • ユーザ調査のコツ:ユーザの発言を無条件に聞かないこと
    • ドクターになる
      • 患者がガンかもしれない、といった時に抗がん剤を投与するのはヤブ医者
    • 「競合が何をやってるか?」ではなく「競合がなぜやっているか?」を調べる
    • 徐々に制度を上げるプロトタイピング
    • 論理構造やレイアウト構造を決めてからデザインを作る
      • 実装→デザインの流れ
  • ユーザテスト
    • 場合によっては強豪のサービスもユーザテストする
    • ユーザーの言ったことより、ユーザーのやったことに注目する
  • リニューアルはどんなに丁寧にやっても何かしら失われる価値がある
    • 構造を整理し矛盾を外し、リリース後に補完していく
  • プロトタイピングの期間は約6ヶ月
  • 試せば必ずよくなる。その時間を惜しんではいけない
    • バッターボックスに数多く立つ
  • 良いコンテンツやビジネスモデルがあれば、機能で小細工する必要ない
    • 検証と吟味を行い、ど真ん中に豪速球を投げるのが重要

Google のインフラ技術から考える理想の DevOps

www.slideshare.net

感じたこと・考えたこと

スペシャリティは必要なんだけども、たしなみとして網羅的なスキルセットは必要なんだと思う。
バランス悪い自覚はある。がんばろう。
あとGoogleやっぱすげぇ。

  • 開発・運用・基盤とチームは分かれていても、スキルセットは同じ。共通言語があるということ。
  • Googleのデータ処理技術すごい。。全部自分たちでやってるんだもんなぁ
  • 難しかったけど、すごいってことは分かった
  • 知識としてのフルスタック。がんばろう。がんばる

Memo

http://www.slideshare.net/enakai/googledevops

  • DevOpsなんぞや
  • Googleにも運用チームはある
    • Site Reliability Engineering
    • 開発者と同じスキルセット+インフラの知識
    • 運用作業は、業務時間の50%以下
      • 他は効率化・改善のためコード開発にあてる
  • 運用は大変。バーンアウトを防ぐ
  • 徹底的に合理的
  • 完全なフルスタックチームは難しい
    • レイヤーごとの責任分界
    • 本質的でない依存関係をなくす
    • インフラ・開発・運用
  • 知識としてはフルスタックを目指そう
  • コンテナは昔から使ってた
    • データをコンテナに保存するのはアンチパターン
    • スケールしづらいし、ポータビリティも落ちる
    • OSレイヤは基盤チームがみる。責任分界
  • GFS
    • データフローとコントロールフローを分ける
  • BorgをOSSとして再実装したものがKubernetes
  • Bigtable
    • アプリケーションエンジニアが基盤を正しく理解して使っている
    • 知識としてのフルスタック

市場で勝ち続けるための品質とテストの技術

感じたこと・考えたこと

LEAN XPすごくよさそうと思った。
体系立ててまとめてる本とかないのかな?

  • 具体的なシナリオ考えるのイメージ湧くのでとてもよい
  • プロダクトマネージャは相当センスが求められる気がする
  • LEAN XPとてもよさそう
  • じゃんけん見積もりいいかも
  • コードの共同所有という考え方、チーム開発だと大事だよね
    • Javadocのauthor、個人的にはいらないと思っている
  • 組織とは何だろうか
    • 何に向き合うかの価値観は組織に対するスタンスが現れる
    • 人と組織もエンジニアリングの範囲だと僕は思う
    • 問題があるなら解決したい

Memo

第一部
  • ヤフオクアプリ
    • ビルド時間の増加
    • 不十分な単体テスト>リードタイム増加
    • 市場で勝ち続けるための品質とテストの技術
  • Pivotal LabでLEAN XPを学んだ
  • ペアプロ
    • 機能とペアを紐付け
    • ペアは片方をDailyで入れ替える
    • 仕様に詳しくなる
    • 技術力の底上げ
  • バックログマネジメント
    • ペルソナからシナリオを抽出、シナリオをストーリー(タスク)に
    • Gherkin format
  • じゃんけん見積もり
  • より小さくより価値の高いもの順に
  • コードカバレッジの罠
第二部
  • テスト自動化
  • まずはユニットテストから
    • 導入がしやすく、効果が高い
  • テスト自動化のピラミッド
  • Cyber Dojo
  • 即実戦で鍛える(プロダクションコードでやる)
  • 体感してから理論を覚える
  • ステークホルダー大杉問題
  • 当たり前のことが当たり前にできないとき、組織に何かしらの問題がある

IoTへのWeb側からの関わりかた

感じたこと・考えたこと

自分の今の関心はあんまりIoTにはないんだなぁ、と思った。

  • 楽しいよ、面白いよ、というのが伝わってるセッション。
  • 興味があったら自分でやってみたらいいよ、ということなのかなと。
  • 具体的な知見もたくさんあってよい

Memo

  • Web系とハード系は大きな違い
    • 開発環境
    • 時間
    • コスト
    • 総じて物理なのでハード系のほうが大変
  • 技術はお金になる
    • 海外からお菓子送られてきた
  • ダイエットの知見
    • 豆腐キムチと豆腐ふりかけチーズ
    • ココナッツオイルダイエット(危険)
    • チアシード
    • もやし炒め
    • 3食ドリンクだけ
  • なぜつくるのか
    • 面白そう、楽しそうだから
  • どう勉強するか
    • Web系とハード系は別々の世界
    • 越えられない山
    • 独力でがんばる
      • 感電するTry&Error
    • コミュニティに参加して知見を得る
  • まず何から始めるか
    • 光るものは正義
    • LEDをチカチカさせる
  • Web/ネット系のノウハウは全く使えない
  • パーツがやたらと多い・やたらと小さい
  • デバッグがひたすら大変: print最強
  • Amazon Dashの衝撃

「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2017」プレゼン大会

感じたこと・考えたこと

全部読みたくなった。。

  • “凡事徹底と主体性、他人の尊重” その通りかも

Memo

技術書部門
  • ゼロから作るDeep Learning
    • 作る発見
      • 作れないものは理解できない
    • 動かす発見
      • Githubでコード公開しているので手元で試せる
    • 分かる喜び
      • 本質はシンプル
    • 作る経験はコピーできない
  • 暗号技術入門 第3版
    • 中学生でも読める
    • 難しい数式ではなく図表
    • 内容は妥協せず、最新の情報まで扱う
    • 3版でアップデートしている
  • 新装版 達人プログラマー 職人から名匠への道
    • プログラマ有志と編集者によって新装版が発行された
    • 訳文や造本が全体に細かく見直された
    • 時代背景には注意する
    • 他の本と併せて読むと良い
ビジネス書部門
  • なぜ、あなたの仕事は終わらないのか
    • 著者がすごい
      • 学生時代に3億円稼いだ
      • MS辞める時はCEOが直接引き止めに来た
      • ホリエモンが絶賛
    • 著者の時間術
    • 編集者が1ヶ月実践した
      • 10年で初めて仕事を残さずに帰郷した
      • 7年位ほぼ土日も休んでいなかったのに、売上は1.5倍になった
      • 半年の世界一周の度に行く休みを取れるようになる!
    • 要点は選択と集中
      • いかに仕事を減らすか
  • ITエンジニアが覚えておきたい英語動詞30
    • 名詞は実は普段から使っている
    • 米国では海外からのエンジニアが増えている
      • 必ずしも英語が得意なわけではない
      • そういう人たちが使っている英語をまとめた本
    • 英語は動詞が中心、動詞力を高めると表現力が高まる
    • 必要なのはTOEICの高得点ではなく、ミニマムな動詞力
  • 最強の働き方
    • ビジネス書は焼き直しや中身の無いものが多い
    • 最高水準のものを作りたいとの気持ちを込めている
    • 著者は一流のプレーヤーではなかった
    • どんな業界・職種にも当てはまる優先順位の高いものをまとめた
    • 読みやすく思い出しやすい構成にしている
    • 1ページに必ず1ユーモアを入れている
  • まとめ
    • 凡事徹底と主体性、他人の尊重
    • 得意なこと、好きなこと、必要とされることが噛み合えば一生続けられる

まとめ

f:id:su-kun1899:20170216215814p:plain

やりたいこといっぱいあるなぁ、と思ったので、ちゃんとやりたいことに時間を使えるようにしないとなぁ、と思った。
やりたいことはやらなきゃいけないことでもあるのかもしれないけど、やらなきゃいけない、っていう気持ちより、やりたいっていう前向きな感情の方が大きいので、健全になったなぁと思う。
やりたいこととやらなきゃいけないことが一致しているというのは素敵なことだな。

明日も参加予定。楽しみです。