mono(0w0)ログ

読んで、体験して、自分でやってみた記録

Developers Summit 2018 KANSAI に参加しました

今回は会社お休みして参加してきました。
同僚二人に遭遇するハプニングありましたが(ΦωΦ)
とても充実した1日になりました。

TD;DR

  • 今年のデブサミ2018関西では「未来をはじめる」というテーマ
  • 自分が取り組む/プロセス改善/アジャイルクラウド機械学習/に関連するセッションを聴講
  • 届けたい価値、解決したい問題に向かい合うことの重要さを再確認
  • それを実現するための方法や手段をエンジニア個人としても習得したいし、組織にも浸透させたい
  • (ブログにまとめるのにいつも1週間以上かかってるのなんとかせな。。。)

Mackerelの200週連続リリースの舞台裏とこれから

  • ユーザーにとって価値のある"機能"を毎週リリース
  • ミニマムな状態からスタートし、機能開発スピード自体が価値となる
  • OSS部分もあって、ユーザー(外部エンジニア)によるコントリビュートリリースもあった
    • 【感想】オープンでありとても素晴らしいと感じました。
  • 少人数なアジャイルチームでCI/CDをさらっと実現している(風に聞こえた)
  • 長期タスク/短期タスク/作りおきをうまくコントロールして連続リリースを実現
  • No マイクロマネジメント。自律したチームには余力が必要
    • 【感想】そんなチームを作り・維持できるマネジメントに興味があります。
  • チーム全員が同じミッション・価値を共有してコミットメントする
  • 結果として機能開発スピードの価値が相対的に低下したので連続リリース止めた

改善を重ねるリモートスクラム開発 〜kintone開発の現場から〜

  • スプリント期間を2Wから1Wに変更
    • 【感想】僕も全く同じ理由で1Wスプリントに変更したのでめっちゃ頷いてました。
  • スプリントプランニングで大枠の設計を実施
  • タスクの実施は全員でモブプログラミング
  • バックログリファインメント毎日30分全員で
    • 【感想】僕は週の半ばくらいにまとめて時間をとっていましたが、毎日少しずつというのも試してみたいです。
  • リモート改善について
    • 【感想】「リモート」でのスクラムをどう実現しているのだろうと期待していたため、1スライドに詰め込まれていて少し残念
    • 【感想】もう少し「リモート」観点で深掘りしたお話を聞いてみたかったです(ツールの選定とかなぜリモートやるのかとか)

今日から始める機械学習はてなの事例〜

  • 吉田 康久さん [はてな]
  • 3つのタイプ
  • 世間のイメージ VS お手軽機械学習
    • 【感想】勇気をもらえます。何事もミニマムスタートですね。
  • アプリケーションエンジニアのメリット
    • データをきちんと見る
    • いい特徴量のありかを知っている
    • 問題解決の手段として使える
  • 汎用ではなく固有・制約を活かす。全部機械学習で解決しようとしない
  • 大事なのはデータ量・特徴量。解決したい問題やドメインをしっかり捉えること
  • 困ったときは
    • Kaggle
    • Machine Learning Meetup KANSAI

意外と知らない?!GitHubの新機能を紹介します

  • 鈴木 順子さん [GitHub]
  • ビジネス向けGitHub
  • 【感想】Git/GitHubの基礎知識からちゃんと学ぼう(´・ω・`)
    • 【感想】Git/GitHubの何がどのようにメリット/デメリットになってどんなチーム・組織・プロセスにフィットするのか説明できたらなぁ

クラウドネイティブなアーキテクチャを設計する次世代の現場力

  • 北山 晋吾さん [レッドハット]
  • クラウドネイティブ=クラウドリソースを意識することなく活用できること
  • KubernetesクラウドのKernel
  • クラウドを活用するために意識を変える
  • クラウドネイティブな設計
    • 柔軟かつ効率的なシステム運用
      • マネージドサービス活用によりカスタム運用を減らす
    • 迅速かつリスクの少ないアプリデプロイ
      • 必ずしもマイクロサービス化が正義ではないがモノリシックは分割する
      • 【感想】マイグレーションについての基礎知識を見ることができて嬉しい
      • サービスメッシュ活用によりアクセスに応じたデプロイ実現
    • 信頼性を維持する運用体制
      • 組織とプロセスの意識改革

Javaを活用したマイクロサービスのためのKubernetes活用

  • 寺田 佳央さん [日本マイクロソフト]

  • 会社・開発者は二極化する

  • すべての企業はソフトウェアカンパニーにならなければならない
  • 「変化することのリスク」「変化しないことのリスク」
  • 技術の見極め・最適化が大切
    • とりあえずマイクロサービスだ!コンテナだ! はダメ絶対
  • サービスごとにリポジトリは作るべき
  • 並列処理をしっかり理解する
  • 障害は起きる
    • 1個のサービスを切り離して残りの99個を活かす
  • Release It! 本番用ソフトウェア製品の設計とデプロイのために オーム社
  • HelloWorldレベルは簡単

勝てる「開発プロセス」の作り方 ―そのプロジェクト計画、本当に成功を確信して書いていますか?

  • 岡 大勝さん [ゼンアーキテクツ ]

www.slideshare.net

  • 開発プロセス=プロジェクトの見通しを立てる
  • プロジェクトの三態
    1. 価値探索
    2. 試行錯誤
    3. 製品化
  • 実現性トライアングル
    1. チーム・環境
    2. テクノロジーアーキテクチャ
    3. スコープ
    4. 中心にコスト・スケジュール
  • トライアングルを使ってリスクを見る
    • 【感想】「物差しを当てる」という表現と感覚がすごく腹落ちしました
  • ウォーターフォールのメリット
    • 未経験者が習熟しやすい
    • 【感想】ちょっと疑問が残る。プロジェクト期間とかにもよるけど、習熟度合いが早いのはアジャイルかなと思う
    • 【感想】ウォーターフォールをすべての工程通して経験できれば深く習熟できると思う
  • アジャイルとは
    • 暗黙知の再評価
    • 暗黙知を活かすために必要なたったひとつのこと=「信頼」
  • Work Together