勉強会メモ：デブサミ関西2019に行ってきました

はじめに

デブサミ関西2019の発表内容メモです。
今回は自分の現在の仕事とリンクするお話が多かったので、すごく勉強になりました。
どの講演も興味深いものばかりで無料で参加させてもらって本当にいいのかと感動で震えます。
翔泳社様、登壇者の皆様、運営の皆様、本当にありがとうございます。
本当にありがとうございます。

自分用メモをちょっと加工しただけなのでうまくまとめられていないかもしれませんがご容赦ください。
とりあえず現時点で登壇者様が資料を公開されているものについては、パスも貼っておきます。
変なところや資料の追加などがあれば、随時修正していきます。
なお、メモ中の（カッコ内）は私の感想・意見です。

イベント概要

日時：2019/09/27
イベント：https://event.shoeisha.jp/devsumi/20190927
場所：神戸国際会議場

心理的安全性の構造(中山 ところてん[NextInt]さん)

[メモ]

• 心理的安全性がないことの危険性

  • コロンビア号の事故
    • エンジニアからのアラートが聞き入れられなかった
  • 大韓航空の事故
    • 機長と副操縦士の関係性が対等ではないが故に起きたコミュニケーションロス

• プロジェクトアリストテレス（生産性に関する研究）

  • ここで示された要素の一つが「心理的安全性」
  • 最重要な要素ではあるが、あくまで一つの要素に過ぎない「心理的安全性」だけが独り歩きしている昨今

• 「心理的安全性がある状態」＝　「心理的安全性がある状態だとチームメンバー全員が信じている状態」

  • （チームメンバー全員、というところがミソだと思う）
  • 提案、質問、失敗などがポジティブな方向で受け入れられると全員が思っている状態

• 心理的安全性に関する勘違い

  • 本来、心理的安全性を確保して、チームや会社の課題に立ち向かおう、というもの。
  • ところが、ことなかれ主義、ぬるま湯環境的な文脈で使われてしまっていることがある。
  • 「心理的安全性」という字面から連想するイメージで誤って解釈されてしまっている
  • （無意識かもしれないが実際にそうなっているように見える状態を見たことがあるし、自分自身もちょっとハッとさせられた）

• 心理的安全性を加速させるには

  • 好奇心をもって前のめりで学んでいく姿勢が大事
  • （自分の能力を身の丈以上によく見せるのではなく、好奇心を持つことで、ポジティブに提案や質問といったアクションができるようになる、と理解した）

• 心理的安全性を脅かすのは「自尊心」

  • 無知だと思われたくない　⇒　質問しない
  • 無能だと思われたくない　⇒　失敗を認めない
  • 邪魔だと思われたくない　⇒　提案しない
  • 否定的だと思われたくない　⇒　現状を評論しない
  • （ブルース・リーの『考えるな、感じろ』が頭によぎった。変に考えすぎるからよくない。知らないものは知らないので迷う前に質問したらよい）

• ある優秀（だとみられている）なマネージャの話

  • チームメンバーが委縮してしまって動きが悪い
  • マネージャが自身の弱みをさらけ出して共有すたことでチームのコミュニケーションが活発になった
  • （「あの人はすごい」と思われている人は上位者になりやすい一方、プライドもあるので弱さを見せられなくなる、というシーンは容易に想像できた）

• にわとりたまご

  • 心理的安全性があるから雑談や自己開示ができるのか
  • その逆か

• OKR的なアプローチで、会社の目標（成長）と個人の仕事（成長）がリンクすると良い。

• HRT+OKR

  • (HRTに則り）謙虚・尊敬・信頼がベースにあるという前提で
  • ⇒　個人の興味関心やめざしたい方向が自己開示されている環境で
  • ⇒　（OKR的に分解された）目標設定で会社の成長と個人の成長・興味がすり合わせられる

• 全体のサイクルが重要

  • 心理的安全性、OKR、スクラム…といった一つ一つの取り組みだけやっていてもダメ。全体のサイクルを作ることが重要
  • （手段が目的化してはいけない、ということだと思う。結局目的は、チームの課題解決であったり、より成果を出すための手段なので、うまく組み合わせて相乗効果が起きるようにせよ、ということかと）

新規事業を支える文化と加速させる技術～DevOps/GCP/DDD～ (大西 真央[Sansan]さん）

[資料]
https://www.slideshare.net/maoohnishi3/devops-gcp-ddd

[メモ]

• VUCAの時代

  • 予測不能で具体的な解決策が存在しない世界
  • 市場調査「しながら」サービス開発を行っていく必要がある

• リーダーはメンバーを変えることはできない。できても、きっかけを与えることくらい。

  • 文化はメンバーを変化させられる

• 学習・適応・変化を楽しむことができ成果を加速させる文化の醸成

  • 信頼マネージメント
    • バディプログラミング
    • マイクロマネジメントしない
  • チーム学習
    • 積極的に相互に学びを共有する
    • 知らないは恥ではない
    • インシデントは学習のチャンス
    • （発生したインシデントに対して個人を責めるのではなく、仕組みの問題を気づかせてくれてありがとうと言えるのはすごい…！）
  • 早期フィードバック
  • エッセンシャル志向
    • 時間をかけて100点を狙わず、短時間で80点を狙う

• 新規事業

  • 自分たちがエンドユーザーではない
  • 開発者がよりビジネスに向き合う手段としてのDDD、GCP採用
    • （DDDはその手法そのものがビジネスに向き合うものなので理にかなってる）
    • （GCPは車輪の再開発や無駄な工数をなくすという文脈かな）

どのような考えの元でコンテナをフル活用していったのか(村主 壮悟[ABEJA]さん)

[メモ]

• 徹底的に何もしたくない、楽をしたいという情熱

• SSHしたくてSSHしてるわけじゃない

  • だから自動化したり外だししたりする

• サーバーレス

  • ローカルデバッグしづらい
  • 開発効率が悪い

• フルマネージドは楽な反面、制限が強い

• ステートレスな構成といつ落とされるかわからないスポットインスタンスの親和性

  • ステートレスなので落ちても無問題
  • 安い（登壇者様の意向に沿って詳細は省くけれど、納得のいく結果でした）

• APIGateWayを自作した理由

  • マネージドサービスのんだと一番のフロント部分（重要）なのに止まってもコントロールできないから

• ディープラーニング関連のコンテナイメージサイズは10ギガバイトスタートというコンテナの一般的なセオリーに全力で立ち向かっていくスタイル

  • なるほど（なるほど）

• 個々のサービスのコストだけではみえてこない、hidden costが結構ある

  • Clowd watchのログ費用など

• Datadog便利そう

• コンテナのイメージタグにlatestを使ってはいけない

  • 気づかないうちに中身代わってしまう

名古屋でエンジニアが中心となり、ゼロからコミュニティを立ち上げた話(葛城 友香[ヤフー]さん)

[メモ]

• Hack U

  • 学生向けのハッカソンイベント
  • 一か月のハッカソンイベントで学生さんと一緒に社員さんがサポートについて質問に答えたり（すごい）

• 名古屋（大阪も）圧倒的に首都圏に比べるとイベントの回数が少ない

• 場所がない、経験がない、参加者がいない問題

• イベント開催する前提で新オフィスレイアウトを考えた

• HackUは半分トップダウン

  • トップダウンだと
    • 評価される、理解もされる、人も適切にアサインされる

• Meetupはボトムアップ

  • 名古屋でクリエイターが活躍する場を作りたい
  • 上司から評価・理解されにくい
  • 本業とのバランスを…という圧

• ボトムアップな思いとトップダウンの方針がうまくマッチして開催に至った

  • （常に思いを持ち続けていたから叶えられたことなんだろうなあ）

• 来場者を楽しませる

  • ケータリングに旗を刺す
  • 登壇者に所縁のある食べ物・飲み物
  • 限定バッジ

• ノウハウ

  • 当日。責任者はタスクを持たない
  • 椅子は少なめに置いておいて席が埋まってから追加するとまばらに座らない
    • （これ神アイデアでは）
  • 懇親会の話題集を作っておく
    • （これ神アイデアでは）

• 発表テーマ選定が難しい

  • テーマ選定の基準は、「この人に発表してほしい」「この内容で発表してほしい」が軸。
  • 他拠点に援軍に来てもらっている状態なので、名古屋ワンメイクで実施できるようにしたい

• 会場貸しすることで地域のコミュニティでプレゼンスを発揮できる

  • （後述のサイボウズさんの発表にも通ずるところがある）

• （全体通して、すごくイベント運営に対して真摯に向き合ってこられたんだなと感じる発表でした）

エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ（岡田 勇樹[サイボウズ]さん）

[資料]
https://www.slideshare.net/ssuserd4b8ca/5web-developers-summit-2019-kansai

[メモ]（個人的に印象的だった部分のみ記載）

• 大阪開発部の立ち上げとともにエンジニアの採用を始めるが、最初は手探りの状態だった

  • 1年目
    • イベントスポンサー、コミュニティスポンサー
    • イベントに参加
    • 外に出ていくことの重要性の気づき
    • お金も要る
  • 2年目
    • 大学主催のイベント、逆求人イベントなどにも出資
    • 費用対効果がわかってきた
  • 3年目
    • 勉強会にオフィスを貸し出し
    • イベント情報を部内で共有して誰かが参加
    • 大規模イベントスポンサー
    • 学生アルバイト
    • お金を使わなくてもできることがあることが分かった
  • 4年目
    • 対外施策を東京・愛媛に
    • コネクト支援部の発足
      • 全国の採用を担う部門
      • 社外のエンジニアとつながることが部門ミッション
      • 開発本部だけど開発しない非エンジニア組織
      • 登壇などはプロダクトの開発エンジニアが出る
      • 対外能力の高いエンジニアの活躍の場の創出
      • イベントやるよ、となると気軽に出張できる・したがる
        • （文化が社内にきっちり根付いているということですね）
      • 個人の成長につながる

• 自社イベント、全国で15以上のスポンサー（スポンサートークもあり）、ブログ発信強化

  • 昔はそんなにエンジニアは目立っていなかった
  • 活動することで、技術力が高いというイメージがついた
  • 採用も増えた

• 新人研修資料がバズる

  • （バズった時に読みました）

• 対外活動を通して

  • 企業やコミュニティとつながれるようになった
    • イベントスポンサー、合同イベント
    • 技術ブログ等に端を発するコラボレーション

• （サイボウズのエンジニアさんはレベルが高いイメージですが、こうした戦略的な背景と、そしてそれがきちんと企業の文化として根付いているという部分に感銘を受けました。やはりコミュニティ活動・アウトプットは重要）

CI/CDを使い倒して数段上のソフトウェア開発をしよう！(金 洋国[CircleCI]さん）

[資料]
https://speakerdeck.com/kimh/cdwoshi-idao-siteshu-duan-shang-falsesohutoueakai-fa-wosiyou-debusamiguan-xi

[メモ]

• CI/CDがなぜこんなに盛り上がっているのか

  • https://codezine.jp/article/detail/11083

• CIのメリット

  • テストがないと、何度も同じ手順を繰り返さないといけない

  • CIが自動でやってくれる

  • テスト実行忘れ、動かない古いテスト、環境依存

    • テストが信頼できない
    • 常にテストは回し続けて通る状態を維持してこそ、テストの信頼性がある

  • テストが古い問題

    • CIを回し続けることで回避できる

  • テストが壊れる問題

    • 壊れた時に検知してくれる。マージブロックを使うことでテストが通らないとマージできない状態を作ることができる
      • 「使われていない自動化は壊れていく」

  • 環境依存（僕の手元では動きます）問題

    • たまたま古いレコードがあって動いただけ、とかが検出できる

    • 常にクリーンな環境でテストを回すことで「僕の手元では動くんですけど」というようなローカルの環境やデータに依存しないテストができる

• 「テストがなくても始められるCI」

  • テストだけがCIの活用範囲ではない
  • Linting, Coverage, 複雑度, ドキュメント自動生成
  • CI結果を可視化する
    • ステータスバッジ
    • ダッシュボード、メール、チャットBOT
  • 少しずつテストを追加する
    • テストがないレガシーシステムに対しては、ユニットテストを書いていくよりはビジネスロジックのテストからやる方がよい
      • （まずはコア機能のロジックテストから書くっていうのでもいいかも）
    • 既にレガシーなものに頑張ってユニットテストを拡充してもあまりうまみはない
    • 無理は禁物

• CD

  • 継続的デリバリー
    • リリースに人間の意志が介在。何を、いつデプロイするかを「人間が判断・決定している」
  • リリース後の仕様バグ⇒本当に必要な機能はユーザーに使ってもらって初めてわかる
    • フィードバックループ
      • CDを導入してリリースを速く・細かくすることでユーザーの反応を速く得て改善する

• CDが向いてない範囲

  • エンタープライズ
    • OSSの活用が進んでいない
  • レガシー
    • 技術的負債
  • CD導入のための銀の弾丸はない
    • サービスを疎結合にしたりOSSなんかを使っていったり…

• CircleCIはモノリシックなサービスだった

  • Docker,k8sの導入をしてマイクロサービス化した
    • 1年半でやった
    • （モノリシックなサービスを1年半でマイクロサービス化できたってめちゃくちゃすごいのでは…）
  • レガシーなものはあきらめる
    • 既にレガシーなものは無理にCI/CD導入しない。新しいものにはきっちり入れる
    • （新しいものには徹底してレガシーを作りこまないっていう精神大事ですね。バランスも大事だけど。）

• CDが実現する本番環境テスト

  • ロールバックが簡単にできる
  • 本番環境でテストできる
    • リリースしてみないとわからない・見つからない不具合が存在する
    • CI/CDによってカナリアリリースやブルーグリーンデプロイなどが実現できる

• CI/CD ⇒ プログラムに対する「心理的安全性」

ぶっちゃけ儲かるの？ アウトプットするエンジニア大集合LT！

【技術同人誌の利点について】（底辺亭 底辺氏[銭けっと]さん）

[メモ]

• 技術同人誌を書き、世に認知され、市場価値をあげるべき
• （ちょっと刺激的な発表でしたが、ハッとさせられる発表でした）

【たった1冊の本を3回も書き直した話】（藤原 惟氏[ソラソルファ]さん）

[資料]
https://speakerdeck.com/skyy0079/c-7-output-lt-developers-summit-2019-kansai-number-devsumi

[メモ]

• Markdownの書籍を出版
  • note -> 技術同人誌 -> 商業誌
• 15日分の記事で1冊の本になる
• 金銭は思ったよりは儲からないが、知識・人脈・機会などの無形資産は増える

【個人開発でアプリを作ってお仕事を頂けた話】（shoheiさん）

[メモ]

• FiFiCを作ったノウハウで仕事が増えた（ブロックチェーン）
• ブロックチェーンならNemがおすすめ
• アウトプットが大事
• 自作サービスを作れ

【Udemyでプログラミングの動画講座を販売してみた】（Abe Asami[nocono]さん）

[資料]
https://speakerdeck.com/sammy7th/udemytehurokuraminku-falsedong-hua-jiang-zuo-wofan-mai-sitemita

[メモ]

• JavaのWebアプリを作りながら覚えられる動画。網羅的ではなくとっかかりとなるもの
• コース考えたり、課題アプリ考えたり、撮影したり、やることがいっぱい
• 動画はDiffが取れないので変更管理が難しい
  • （そのうち取れるようになる未来が来るのでしょうか）
• 動画収入よりもフリーランスとしてアピールできるツールとしての側面
  • （藤原さんの書籍執筆とも通じるところがある）

LT全体通しての感想

• アウトプットが重要で、直接的・間接的によらず得るものは多い