2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Developers Summit 2018の感想

Developers Summit 2018

感想

  • ベースとなる技術は原理原則から学ぶ
  • 別々のスピーカーから「現状」+「次の何か」について言及されていた
  • 技術で解決する
    • PDCA:調査→検証→実践→…
    • やらないこと:怠惰
  • 信頼関係
    • チームは人と人の繋がり
    • コンテキストの共有
  • 個人
    • 自分を見つめ直す
    • 好きなことを楽しく

参加セッション

【15-D-1】 技術選定の審美眼

  • t_wadaさんの新作トークセッション
  • 技術の変化の速さ = 陳腐化の速さ
    • => 本質的でない変更を強いられる
  • 技術の進化とは振り子ではなく螺旋
    • 螺旋なので同じところには戻らない
    • 時間とともに差分(可能にした技術)がある
    • その差分をスルーするのかキャッチアップするのか?
      • 自分の軸を持つのが大事:simpleとeasy
      • 採用する必要はないが、変わった後の世界は知る必要がある
  • ゲームチェンジャー
    • Rails:Easy
      • 開発速度アップ
    • クラウドコンピューティング
      • 集中と分散
      • コスト構造やボトルネックを変えた
    • Docker
      • 速さと再現性の高さ
    • React
      • 手数は増えたが、心配は減った
      • 考えることを大きく減らした

【15-D-2】 属人化したフロントエンドのJavaScriptを、‘新規機能開発を止めずに’改善するために行った取り組みについて。及びその経過報告。

https://togetter.com/li/1199576

  • 技術的負債の返済についての取り組みとその結果
    • 属人化についての話はなかった気がする
  • 手法
    • WebPack
    • eslint
      • no-undefは必須
    • React化
      • 新規、簡単な画面からの局所実施
    • リファクタ
      • テストがないと辛い
  • 運用
    • 勉強会
    • エディタ設定の共通化

【15-C-L】 婚活サービスにおけるシステム×サービスのイノベーション

https://togetter.com/li/1199576

  • サービス企業の内製化アンチパターン
    • PHP
      • Ruby
    • 要件定義
      • 企画から
    • 事業部席・案件
      • PRJでまとめる、横断的なPMOが必要
    • 技術力重視
      • 責任感と自立・人格重視
  • エンジニア×企業理念
    • サービス企業へエンジニアとしての取り組み
      • リリース日は大安
      • GitLab:ギットラブ
    • 婚活を科学する
      • マッチング数を増やすには→パーソナライズ
      • カウンセラーが担当
        • 学習、パターン化して特徴抽出
      • システムは双方向が得意
    • 企業
      • エンジニアを尊重して放置
    • エンジニア
      • サービス愛、企業理念の理解

【15-D-3】 人生20年説・好きな事と得意な事を仕事にしていけるかも知れないエンジニア人生のヒント

https://togetter.com/li/1199625

  • 中井さんのユーザケース
  • 人生20年説(京大教授 森毅)
    • 自分は5年周期くらい
  • 複数の得意分野を併せ持つ→自分だけの価値
    • そのために並列で面白そうと思うことを学ぶ
    • 学ぶ時は原理原則を!
    • 色々な経験は無駄ではない
  • クラウド x 機械学習 x ( ? )
    • 次は秘密

【15-C-4】 多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略

https://togetter.com/li/1199647

  • リクルートはボトムアップ文化
    • 失敗もあるが学びもある
    • 最終的な決定はトップダウンで進める必要がある
  • リボン型のビジネスモデル
    • SoR的な開発とSoE的な開発
    • PRJは導入-成長-成熟によって要素が変化していく
      • SoEからSoRへ
  • エンジニアチームは苦手なことに対応するために強みが失われていく
    • →組織的なフォローが必要
  • バックエンドとフロントエンド開発間での齟齬
    • BFF層の追加
    • ツール:Agreedの活用

【15-E-5】 最新技術に挑戦し続けるLIFULL HOME'Sアプリの開発について

https://togetter.com/li/1199683

  • 新技術の導入
    • AppStore/Google Storeでの評価、フューチャー枠
  • 課題
    • アイデアの提案
      • モックで提案する
      • 勉強会、ランチミーティング
        • 根気強く風土作り
    • 導入時の困難
      • 調査、学習が困難
      • 予期せぬことが発生する
      • 新技術にはリスクがあるので覚悟が必要
    • 負債の返済
      • 抽象化、統一化でコストを減らす
        • Clean Architecture
        • クラス名:役割+レイヤ
          • 役割の名称も共有、統一
        • UIの統一
          • ローディング、エラー
  • 挑戦→実践→モチベーション→挑戦…
  • Ask the speaker
    • 遷移は?
      • ストーリーボードベース

【15-x-6】 休憩

【15-E-7】 スタートアップなエンジニアLT!〜スタートアップはどんな技術を駆使して開発を行っているのか?〜

https://togetter.com/li/1199726

快適なマニュアル作成・共有を支えるSite Reliability Engineering

https://speakerdeck.com/katsuhisa91/kuai-shi-namaniyuaruzuo-cheng-gong-you-wozhi-erusite-reliability-engineering?slide=1

  • 問題
    • 障害発生時のOpsの負荷が高い
    • モニタリングが貧弱
      • サービスの状況が把握しきれない
  • SREで解決しよう
    • 以前:筋肉で解決
  • Toil(手作業)を削減
    • 削減にどれぐらいインパクトがあるか
    • 今削減する必要があるか
    • それが最適な方法か
  • モニタリング
    • アラート、チケット、ロギングを見ればよい

サーバーレスを活用して少数精鋭で開発するニュースアプリ

https://speakerdeck.com/yamitzky/sabaresuwohuo-yong-siteshao-shu-jing-rui-dekai-fa-suruniyusuapuri-number-devsumi

  • ユーザに近い側をサーバレスに、それ以外はDocker化
  • サーバレスでGraph QL APIを提供
  • パフォーマンスは金でスケール
  • サーバレス化前は手動でスケール
  • サーバレスで乗り越えられなかった話もある

CrowdWorksのChatOpsの歴史

https://speakerdeck.com/hideki/chatops-history-of-crowdworks

  • Botが14体
    • 重要度の高い機能と低い機能が混在->分離
    • メインサービス用の機能を分離
    • 環境ごとに分離
  • BotからBotへ連携
    • Slackで@

CacooはHTML5でどう生まれ変わったのか

https://cacoo.com/diagrams/5SNHdnrh8hFGBLcv#0CBD0

  • ぶっちぎりの速さのために
  • 特定の技術だけでパフォーマンスを上げるのは難しい
    • ベンチマークをもとにした技術比較選定
    • データ構造の見直し
    • メモリの最適化
  • 技術+工夫が必要

Go言語と仮想通貨

https://speakerdeck.com/sonatard/goyan-yu-tojia-xiang-tong-huo

  • 仮想通貨技術の説明
  • プロダクト開発に集中したい
    • そのために環境づくり
    • GAE/Go

未来に「おいしい」をつなぐインフラの創造を支えるITの存在意義 〜農業の課題と可能性〜

  • 農業の課題と可能性
  • 食農業界でITを活用しても生産性が向上しない
    • データは集約されていない
      • データ量が膨大
    • 流通量が増えているにもかかわらず、値段が上がっている
  • SPAのフード版で、SPF
    • 生産から販売までも一気通貫でやる

【16-C-1】 実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -

https://togetter.com/li/1199970

  • モブプログラミングとは
    • やってみることで得られる学びが多い
  • 一緒に働くこと
    • 障害対応の時など
  • 分担するという先入観にとらわれていないか?
    • 一緒にやってうまくいかないチームが、分担してうまくいくのか
    • 分担の前後に同期が必要となる
    • モブは常に同期している
  • ペアプロとの違い
    • 個人ではなくチーム全体
  • 全てをモブプログラミングにする話ではなく使い分けが重要
  • 形式知を暗黙知へと言うが暗黙知は何が暗黙知なのか不明確
    • 過程を共有することで暗黙知をまるっと共有

【16-D-2】 NRIの働き方改革 - 開発スタイルから文化まで変えた軌跡 -

https://togetter.com/li/1200014

  • ツールを入れることで社内の文化を変える
  • 苦労した点
    • 反対勢力
      • 反対勢力はいったん放置
      • キャズム理論
      • 新しいもの好き、若者、小さなPRJから
      • トップダウンで大規模PRJへ導入
        • 環境を管理して提供
        • テンプレート作成
        • 説明会、ハンズオン
          • 使いやすいツールから
    • 現行保証
      • JIRAをExcelで操作したい:マクロ提供
      • ヒヤリング→新業務フロー
  • 結果
    • 情報の集約でメール、検索が減った
    • チャットで電話が減った
    • 見える化でチームを超えた協力
    • 議論の増加
  • 文化への影響
    • 縦割りの解消
    • チーム文化の統一
    • 気兼ねないコミュケーション
  • まとめ
    • トップダウンで推進
      • ボトムアップで普及させていく
    • 順序
      • ライトなツールから
      • HipChat→Confluence→JIRA
    • ネイティブを作る
      • 当たり前の状態にする
      • Excel使ってた人はExcelを前提に考えがち

【16-D-L】 ゼロからのエンジニアが開発マネージャーになるまで 〜 スピードと変化に強い文化と環境 〜

https://togetter.com/li/1200021

  • 変わらなかったもの
    • 信頼関係
      • 仲間
      • エンジニア
    • 開発
      • 設計・仕様
        • 変数関数クラスの名前が決まれば7割おわり
    • レビュー
  • 変わらないために変わり続ける(一風堂)

【16-B-3】 サーバーレスのメリットを最大限引き出すためのシステム設計手法と考え方

https://togetter.com/li/1200043

  • サーバレスの一般的なメリット
    • 運用上の管理なし
  • 見えにくいメリット
    • 機能がコンポーネントで分割される
      • マイクロサービス的
      • ステートレス、冪等性→イベントドリブンになる
    • Twelve-Factor App
  • イベントドリブン
    • イベントストリームが辛い
      • クラウドベンダーで用意されている
  • ベンダーロックインでは?
    • パーツの揃ったロックインは悪いものではない

【16-D-4】 ソフトウェア開発30年史を振り返りつつ考えるプログラマにとって変わらないもの

https://togetter.com/li/1200066

  • インターネット老人会向け
  • 好奇心から探求が始まり発展して新しい何が生まれるサイクルを繰り返している

【16-A-5】 「自分」をまるごと活かす!私が“CRE”というキャリアを選んだ理由

https://togetter.com/li/1200079

  • 自分とは何か?
    • 憧れていたもの、習ったこと、原体験。
      • そこから、好きなもの、なりたいものを考える
  • 色々なことを経験
    • 無駄ではなく投資
  • 憧れドリブン
    • 目標は修正してもいい
  • できることを増やしておく
    • 好奇心を持つことは大切

【16-C-6】 The Amazon Way~Amazonのソフトウェア開発~

https://togetter.com/li/1200104

  • お客様の生活を楽にする。お客様を起点とする
  • 組織づくり
    • メカニズム
      • プレスリリースから書く
      • 6pager
    • アーキテクチャ
      • モノリシックなシステムからマイクロサービス
      • two pizza teams
        • 作るものに対する全てを負う
        • "You build it, you run it"
      • テストは、すべてを自動化
      • 運用:5-whys
    • カルチャー
      • Our Leader Principle
      • お客様の為にならないことはお金を使わない
      • スキルは優れていても、カルチャーが大切
      • everyday is still day one

【16-C-7】 子育て・介護に向き合うエンジニアが技術に取り組み続けるために

https://togetter.com/li/1200123

リターンシップ

  • キャリアを途中で止めたがインターンシップのように働く
  • 働き方改革
    • 残業は減らない
  • 子育てしながら
    • 自分の時間を自分でコントロールできない
      • 仕事の難易度↓専門性↓
      • バックオフィスなど
    • 楽しくない
      • お互いに遠慮している状態で負のスパイラル
      • 詐欺師症候群
  • 解決できることはテクノロジーで
    • 在宅/裁量労働
      • 短時間で専門性の高い仕事
  • やるべき事
    • 雑談
      • 心理的安全性
    • ピープルマネジメント
  • 大企業にできること→中小企業でできるはず
    • サボりを見つける従業員監視型からの脱却

CTOが育休とった話

  • よかった事
    • 育児に自信
    • 妻からの信頼
  • 諦めた事
    • 完全母乳→ミルク
    • 自炊→外注の利用
    • 丁寧な家事→機械化
  • スマートスピーカーは手を使わないので便利
  • 働き方
    • これからは労働人口が減る
      • 増員で対応はできない
      • 生産性向上、効率化が必要
  • まとめ
    • 育休はいいぞ
      • 復帰後のイメージもしやすい
    • 時間はないぞ
      • リソースは有限、諦めるものもある
    • 雰囲気大事

介護の話

  • 介護 x IT
    • 現場にはテクノロジーは何もない
  • 高齢化の現場
    • 介護リテラシー
      • 介護になったらどうすれば良いか知ってるか?
      • 介護サービスの種類を知っているか?
    • 国の現状
      • 胴上げ型->騎馬戦型->肩車型へ
      • 2050年には4割が老人(メガネ率位)
  • 介護離職は突然やってくるし長い
  • 介護マーケットは巨大
    • ITは縁遠い
    • まったくIT化されていないのでチャンスでは?
      • 国策で後押し
      • エンジニアが少しずつ興味を持ち始めている
2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?