技術覚書

自分のために技術的なことを色々と書こうと思います。

トップ > 行ってきた > 【行ってきた】(20190927)DevelopersSummitKANSAI 2019

【行ってきた】(20190927)DevelopersSummitKANSAI 2019

行ってきた レポート DeveloperSummitKANSAI

f:id:manabu-hashimoto:20190928133947j:plain

こんにちは。

９月最後の金曜日、プレミアム休暇とって
勉強会行ってきました！

目次

これに参加しました

event.shoeisha.jp

いつも勉強会は基本単身で行くんだけど
今日はこのイベントに職場の方も参加するって聞いて
「おお、同志よ…！」とうれしかったり心強かったり。

どうしてこれに参加しようと思ったの？

例によって技術動向・情報の収集がしたかったからなんですけども
単純に「めっちゃ楽しそうなイベント！」と思ったから。
実際行ってよかったです。お祭り気分も味わえたし、
フォロワーの方と名刺交換できたし、職場の人とLINE交換もできたし。

当日のタイムテーブル

https://event.shoeisha.jp/devsumi/20190927/timetable

自分が聴いたセッション

自分の中で「チームの生産性を最大化するにはどうするか？」に関心が
大きく占めるようになったなぁと改めて思った。

プロジェクトマネージャーになりたいわけじゃないけど、
自分と一緒に仕事する人が楽しく楽に成果を上げられるか
そのために少しでも知識やベストプラクティス的なものを欲しているなと。

セッションごとのメモ

心理的安全性の構造 / 中山ところてんさん

スライド

心理的安全性の構造 デブサミ2019夏 structure of psychological safety

メモ

心理的安全性が欠如したことによる事故

共通して言えるのは、人同士が対等な関係でないことと、
人は威圧されると萎縮してパフォーマンスを出せなくなるということかな。

心理的安全性とは何か？

  • プロジェクトアリストテレス
    • チームの生産性に何が寄与するか？
    • 「生産性」を高めるための５つの要素
      1. 心理的安全性
      2. 相互信頼
      3. 構造と明確さ
      4. 仕事の意味
      5. 影響
  • 真に重要なのは「チームがどのように協力しているか」
  • 心理的安全性とは、提案したり、質問したり、懸念していたり、失敗したことで罰せられたり恥をかかされたりすることがないことだと信じている状態
  • 個人で「心理的安全性が確保されている」思っているよりも、チーム全体でそれが共有されていることが重要。
  • 「心理的安全性」の「状態」と「目的」が混同されている。本来は「目的」のためにある。
    • 心理的安全性の目的：良い議論、良い行動のためにある。
    • コンフォートゾーンでぬるま湯につかるためではないよ！
  • 心理的安全性は「無知・無能・邪魔・否定的なやつだと思われたくない」で脅かされる⇒だから何も行動しなくなる。
  • 人は弱みを見せたくない。健康問題は弱みの最たるもの。
  • リーダーは自己開示をして弱みをみせても「攻撃されないよ、大丈夫だよ」をアピールする
  • メンバー間で雑談・自己開示できるようにするには？
    • HRT（謙虚・尊敬・信頼）・・・学び続け、成長し続けるための姿勢を持つこと
  • OKR
    • 我々は何者で、どこに行くのかがわかって、自分の成長・仕事が会社の成長とリンクしているのがよいところ。
  • SECIモデル
    • 知識を「個人・集団」「暗黙知・形式知」の二軸で考える、知識創造モデル。

心理的安全性の構造

  • 良い行動のためには、他社の体験の血肉化が必要
    • 新聞・読書・ウェブ記事・TVのINPUTをもとに雑談ができるようになって、そこから自己開示ができる
  • 単に「雑談、OKR、ナレッジマネジメント、心理的安全性の確保だけできてるー」だけじゃダメ。
    • 大事なのはこれらを組み合わせてプロセスを回していくこと

参考URL

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

スライド

新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~

メモ

文化的なとりくみ

  • VUCA（不安定・不確実性・様々な要素が複雑に絡む・物事の因果関係曖昧）の時代
    • VUCAマインド：変化・学習・適応のサイクル
  • エンジニア組織として文化・技術・ツールは全部大事。
  • 個人がVUCAマインドを持つことで組織が変わる。
  • リーダーは人を変化させることができない。リーダーができるのは変化の「きっかけ」を与えること

成長思考

  • 生まれつきのスキルより、努力して学習することよりスキルをあげる
  • xxxは自分だとできないと考えるより、できるために小さな行動を起こし、学習していく
  • 文化を中心にとらえ、個人が変わっていく

個人的に大西さんのこのセッションが一番心にグサグサささってめっちゃ共感でした。
実際に自分も社内で「文化を作りたい」とすごーく思ってたところだったんですよ。

  • リーダーは人を変えることはできない
  • 文化は人を変えることができる

というのであれば、リーダーにできることは
「個人が変わるための文化を作ること」じゃないかなと思いました。

失敗を許容する

  • インシデントは罰ではなく、学習のチャンス。
  • 犯人捜し・叱責だけだと人は委縮し、ポテンシャルをつぶしてしまうことになる。

開発コンセプト

  • 安定したインフラで素早く動け（by Facebook)
  • DDD
  • GCPサーバレスサービス

第一線で活躍している人・企業に共通して言えるのは
しっかりとした「ビジョン」や「コンセプト」を持っていて
それをちゃんと一緒に仕事する人たちに伝えていますよねー。

参考URL

生産性を上げる新しい役割「業務ハック」とは？ / 髙木 咲希さん[SonicGarden]

スライド

公開されたら追記する。

メモ

納品のない受託開発

  • 月額定額・顧問型・成果契約
  • 業務ハッカー＝業務改善×システム化（仕組化）する人。大事なのは「業務改善」
  • 社内SE・・・システム目線が強い。業務ハッカーはあくまでも業務に重きを置く。 先日の「ザッソウ」のエントリにも書いてますのでご参照ください。

業務ハックとは

  • ぎょ：業務を
  • う　：うまく
  • む　：無理せず、させず
  • はっ：反復しながら
  • く　：組み立てる
  • 生産性をあげること・・・コストを下げることよりもアウトプットの量をあげること
  • 根性に頼らない、人に完璧さを求めない（ミスを責めない）
  • 業務の見える化⇒ボトルネックを見つけて改善案⇒現場で改善案試行、ふりかえりのサイクル
  • 既存のサービスを活用する。
    • trello、IFTTT、チャットワーク、とかとか
  • 業務ハック勉強会を開催している。
    • 情報流通する基盤形成、認め合いから自身創出、気の合う仲間
  • 自分たちの業務を相談しあう交流タイム
  • 勉強会応援サイトgyomy

参考URL

GYOMUハックのお仕事、紹介します / 廣野 美里さん[ freee ]

スライド

公開されたら追記する

メモ

GYOMUハックとは

  • ビジネス要件に対して社内のシステム構築・業務改善・課題解決を行う人たちの総称。
  • 社内SE,BPR、情シス⇒GYOMUハック
  • 新しいエンジニアの役割としてのGYOMUハック
  • ビジネスチームとの二人三脚がかかせない。
  • 今にとらわれがちな現場に対して、未来を見据えながら現状の課題を改善する仕組みを作る。
  • コミュニケーションの繰り返し
    • 現状把握
    • 優先度付け
    • 理想設計
    • 実装
    • 定着化
  • 理想ドリブン：制約とかそういうのはひとまずおいといて理想を、あるべき姿を明示する。
  • 課題解決をしながら「信頼貯金」を積み上げて関係を構築する。
  • 正しいものを正しい場所に置く。
  • 改善と最適化でシンプルに

なぜ必要か？

  • ビジネスは生き物だ。時間が経つにつれ、どんどんと複雑で大きくなる。
  • 人間は慣れる生き物だが、変わることは辛い。
  • それでも改革は必要だから、現場の人たちの気持ちに寄り添いながらハッピーになる夢を見せる。 GYOMUハックが責任をもつ。

参考URL

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

スライド

公開されたら追記する。

メモ

今ヤフー名古屋で開催している主なイベント

  • ヤフー名古屋TechMeetup
    • クリエイターマインドやサービスを支える技術
    • コンテナ技術
    • Webフロントエンドを支える取り組み
  • Hack U
    • 学生向けハッカソンイベント。全国最大５都市で開催。個別の大学でも累計６０回以上の開催実績
    • 学生さんに対し、ヤフーさんのサポートをする。

０からの立上げ

  • 課題：名古屋ではエンジニアやデザイナー向けの勉強会少ない。(compassでも101件しかない)
    • 今までもコツコツやっている。出席人数２０人前後
    • 名古屋オフィスにイベントできるスペースがない。
    • 名古屋メンバーが一から企画したイベントがない
    • 弊社主催のイベントも本社で行った学制向けイベントをHACK Uの運用メンバで行ったもの
  • モチベーション
    • 課題を把握：地域性の課題と自社オフィスの課題
    • 熱い思いがあった！
  • オフィスの移転が決まってから、社外向けイベントやりたい人達であつまってキックオフ
  • Vision：名古屋でクリエイターの未来を創る
  • 社内で何かを立ち上げる時、部署やプロジェクトだとトップダウンの場合多い
    • 上司から評価されやすい
    • 周りの理解も得やすい
    • HackUも半分トップダウン
  • 一人一人の負荷は大きいけど、逆に全員で広い視野で見れるようになった。
  • TechMeetUpはボトムアップ
    • 本業とかかわりのないところに時間を割いて主務をやりつつボランティア状態
    • まわりを巻き込んでいくようにした
    • 会社の方針も名古屋でのイベントをやるとなっていたので、マッチングした。
  • 風通しのよい運営
    • PMは当日タスクをもたない
      • 当日の仕事は判断、登壇者や関係者への挨拶だけ
      • それ以外のタスク（トラブル）が発生するから、そのときのために体をあけておく
      • 懇親会話題集を作っておく

周りを巻き込む

継続

  • 会場の貸し出しにとどまらないこと
    • 社外の様々なイベントに利用してもらっている。
  • コミュニティリーダーになる！
    • 勉強会をやりたい人たちにきっかけを提供する

課題

  • テーマの選定に悩む
  • ほかのイベントとの兼ね合い
  • 名古屋単独での開催
  • 毎回、地域や自社の課題を解決するつもりで！

「勉強会言うは易し、行うは難し」だなーと思いました。
本業とは別途で運営やるってとてつもなく大変だと思います。
しかもそれを継続してやってくってすごいです。

話を聴いたとき、企画から実施までとてつもなく腐心されているんだなーと。 会場の用意だけでも一苦労なのに、お土産（ノベルティ）を用意したりとか 勉強会に来る人たちのためのサービス精神が半端ないですね。
これらをなすのは「熱い思い」があるからなんでしょうね。

参考URL

ホテル・旅館運営企業が毎週リリースするDevOpsサイクルを作るまでの道のり / 藤井 崇介さん[星野リゾート]

スライド

ホテル・旅館運営企業が 毎週リリースするDevOpsサイクルを作るまでの道のり

メモ

  • 星野リゾートは1914年創業。105年目になる。1990を天気に運営のみを担うビジネスモデルへ転換
  • 星野リゾートの情シス・・・現場で働いている人たちがエンジニアになって働いている。
  • 組織文化
    • Ganho（がんばれ星野）
    • フラットな組織。みんあんで意見を出し合い、だれでも対等に意見交換。
    • 一人ひとりが判断する。⇒透明性・情報開示
    • 失敗を許容する文化

星野リゾートのシステム開発

  • 独自システムが多い。

    • よそとは違うこと、自分たちの特徴をだすためには独自システムが必要。

  • 外部に依存した開発体制

    • 人手不足と外部依存の体制で、事件が起きる

事件勃発

  • 事件１：やるやる詐欺事件
    • 予約サイトに銀行振り込み決済機能を入れられる？
      • はい。３か月くらいです（いつから着手できるか知らんけど）
      • あるある「工数を答えたのにスケジュールと思われる」
  • 事件２：完成したはずが動かない
    • DM配信システムを外部委託した
      • 外部委託「完成したで（本番で動かせるとは言ってない）」
        • 塩漬けにしておいていて確認せず。本番でいざ動かしたら動かない。
        • あるある「システム完成の定義が違う」

問題点

  • スケジュールの合意形成フローがない
  • 優先度が決まらない

Ganhoな組織を活かして問題解決

  • 部署を超えて話し合う。
  • 合計性フローの整理
    • 要望を取りまとめる場を設けた
    • 開発までわかるエンジニアが入って合意形成の体制を強化した。
  • 工数をポイント制にかえた
    • 人日／人月の見積もりをやめた
      • 人日／人月で見積もりは、人に依存するので当てにならない。
      • Fポイント：開発依頼フォーム⇒kintoneに連携、エンジニアがポイントを設定⇒会議で優先度決める
      • Fポイント（藤井ポイント）

開発体制の構築

  • 2018年入社当初：バラバラの拠点で開発を開始。
  • リモート前提
  • QCDコントロール
    • Q：CI/CD環境構築。コードレビュー、CLレビュー
    • C：仕様のコントロール（受託をやめる）、ボトルネックの改善。
    • D：朝会の実施で状況把握、アサインの調整

改善当初の状況

  • 改善が進みだし、社内から好評。2wに1回はリリース
  • 違和感。Ganhoな組織文化になってない⇒スクラム導入。

スクラム導入の理由

  • コミュニケーション機会を増やす
  • フォロー体制強化
    • あふれそうな場合に、チーム内の判断でヘルプに入ってもらう
  • 開発効率の改善
  • スクラムのセミナー（有償）いいよ
  • チームを分断するとどちらかでボトルネックになる
    • 機能横断でチームを作る⇒情報共有が密になる。
  • スウォーミング：１つのタスクをみんなで集中して終わらせる。
    • 協力することで、小さな成果物を早く作ることができる
    • お互い協力することで、自分ができなかった作業のやり方がわかる。
    • 複数人でチェックしながら進められるので、成果物が個人に依存しない
  • 改善にも時間使う
    • JSP⇒vue.js
    • Dockerで開発環境作れば構築楽になるのでは？
    • プルリクの承認でビルド・デプロイできるようにしたい
  • お客様への理解が必要。（導入当初は生産性が落ちる。でも最終的には生産性は前以上になった）

スクラム導入したことで

  • 毎週リリース。継続可能な環境になった
  • 問い合わせ件数半減
  • 会社、働き場所を超えて改善できる体制を構築できた

内製化が進んでいるなぁと強く実感。受託開発がなくなるわけやな。
大規模で開発している我々、本当に取り残されている感が…。

まとめ

  • 外部に依存した体制から内製に方向転換することで、改善できる
  • 改善するためには組織文化の支えが重要
  • 内製化する立場だからこそ、スクラム開発を取り入れられる。
  • エンジニアが成果をだすと、経営の方向も変わる。

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

スライド

CI/CDを使い倒して数段上のソフトウェア開発をしよう (デブサミ関西) - Speaker Deck

メモ

  • CI/CDは戦国時代。GitHubもGitHubActionでCI/CDできるようになった
  • なんでこんなに関心が高まっているのか？
  • codezineで連載している。ググると出てくる

CI / 継続的インテグレーション

  • なぜテストを書くべきか

    • 何度も同じ手順を繰り返さないといけない
    • 人の目や手に頼るとしくじる。

  • CIはテストを自動で実行する仕組み

    • あくまで開発者がテストを書いてそれを実行するもの

  • テストを書くだけでは不十分。

    • テスト実行し忘れ。テストが壊れている。テスト結果が環境依存。⇒テストの信頼性がない
  • テスト実行し忘れ
    • リリース前にテストし忘れ⇒
  • テストがないとCIはできない。。。
  • テスト文化の布教にはコストと時間がかかる
  • テストがなくても始められる方法
    • Step1：お好みのCI/CDツールを使う
    • Step2：様々なタスクを自動化
    • Step3：結果を可視化する(yarn)
    • Step4：マージブロックの有効化・・・CI通らないと開発者はマージできない
    • Step5：テストを少しずつ追加する
  • メンテナンス問題
    • CI/CDツールのメンテはたいへん。先任者必要（Jenkinsおじさん問題）
    • クラウド型はメンテコストが少なくなる？？

CD / 継続的デリバリー

  • Continuous Delivery
    • リリース作業に人間の意志が介在する
    • デプロイまではツール、リリースは人間が判断。
  • Continuous Development
    • リリース作業に人間の意志が介在しない
    • 自動でステージング・本番環境へデプロイ
  • フィードバックループを使う
    • 細かい単位でリリースする
    • フィードバックを早めにえる
    • カイゼンする
  • CDなくしてフィードバックループなし
  • そもそもCDに向いてないやつ
  • 迅速なロールバックが可能になる。
    • git revert でソースを戻すと自動的にシステムも切り戻しができる
  • カナリーリリース
    • 本番環境のほんの一部にリリースして動かし、問題があれば一部を切り戻せる
  • ブルーグリーンデプロイ
    • 新(blue)、旧(green)２つ環境を用意して、何かあったら古いほう（green）に切り戻す

参考URL

エンジニアが市場価値を上げるために缶詰事業にチャレンジした理由 / 井上 和馬さん[カンブライト]

スライド

公開されたら追記する

メモ

日本の食を世界に持っていくには？？

  • 缶詰を小ロットで商品化。
    • 企画・開発・製造・販売
    • 100コから商品化
  • アジャイルの開発手法を食品開発に導入した
  • 物がうれず、ヒット商品の寿命が短い時代
    • すぐ作ってみて、販売⇒フィードバックを繰り返す（アジャイル）

ステージ別市場価値を上げる取り組み

  • プログラマ時代
  • チームリーダ時代
  • プロダクト責任者時代
  • 社会貢献事業時代

ぐいぐいひっぱる人ってやっぱり駆け出しのころから
仕事への取り組み方が全然違うなーと思いました。
やらされている感がなく（見せず）、自分で課題・目標を見つけて進めていく。
こういう「背中」をメンバーに見せることがリーダーには必要だと思いました。

振り返って思うこと

  • 会社からの目標≒自分の目標
    • やらされていると感じた仕事はほとんどなく自分がやると決めて仕事をやってきた。
  • できることではなく、やりたいことをやる（今の自分にできなくても）
    • 自分ができることの延長戦で目標設定しても成長角度は低い。
  • 目標の理由とどのみちでそこに行くのかを共有（ゴールの共有）
    • 自分だけでなく、関わる人にとっても納得できる目標と道なのか？
    • 考えたことを１０回説明して納得できれば一気にすすむ
  • 誰よりも目標に向かうチャレンジを楽しんでいることが伝わるようにする
  • 何をしようともテクノロジーの力は必要。エンジニアが持つ可能性はすごい

特に「誰よりも目標に向かうチャレンジを楽しんでいることが伝わるようにする」
姿勢って大事だなーと思いました。リーダーが楽しんでる姿だったり
夢・理想を語らないと、メンバーも楽しんでくれないし、ついてきてくれないんじゃないかと。

おまけ

ランチセッションで出た軽食（サンドウィッチ）

f:id:manabu-hashimoto:20190928134009j:plain

タダで超有益な話きけて、お昼ご飯まで出るなんて
デブサミ、コスパ最高では？

セッションでもらったノベルティ

SanSanさんとヤフーさんのセッションでもらったやつ。 ありがとうございまーす！ f:id:manabu-hashimoto:20190928134016j:plain