エンジニア文化祭2023参加メモ

少し遅刻したので途中から。

結果的に無駄なものを大量に作ることになる

• 64%の機能はほとんど or 全く使われない機能がある(2002年)
• 80%(2019年)
• ビルドトラップ

吉羽さんの記事発見
https://productzine.jp/article/detail/169

機能が増えるとユーザーの満足度が下がる
→たくさん作れば良いという話ではない

プロダクト開発はコストがかかる

• 必要とされていないプロダクトにお金と時間と労力をかけるのは無駄
• できるだけコストをかけずに素早くアイディアを実現する
• たくさん仮説検証、プロトタイプの作成

うまくたくさん作ることが最重要なわけではない

• アウトカム(成果)の方が重要
• 全員がアウトカムにフォーカスする必要性
• そのためのフィードバックが何より重要

問題設定力の領域での改善

• たくさん作ることを目的化するのはやめる
• 解決すべき課題にフォーカスする
• 作る前に仮説検証する
• 作ったら結果を測定する
• 失敗したら潔く捨てる

開発力の領域を改善する

• 良いアイディアがあっても実現できないと話にならない
• 開発に時間がかかると競争力に負けるかも知れない
• 開発力がないと実現に時間もお金もかかる
• 品質が低いと成長されられないかも
• 開発力は重要
• 開発力に課題があるチームは結構多い

短い間隔で安定して価値を届けるには

• 短い期間に区切って繰り返す(アジャイル)
• 短い期間の中で設計、開発、テストを終わらせる必要
  • 過去に作ったものを壊していないこと

テスト自動化の必要性

• 手作業だと時間がかかる
• 手動だと結果の判断を間違える
• 成長するについれて負荷がかかる
• チームにもっと価値の高いところに集中してもらう
• テスト自体がドキュメントになる(テストが仕様を表す)

品質や速度低下の兆候を見つけたら継続的に対処する

• テストの所要時間の増加
• バグの増加
• リリースの遅延
• コードの重複
• カバレッジの低下
• 可読性の低いコード
• 技術選択の誤り
• ハック

スキル領域でのボトルネック

• フロントだけ、バックエンドだけみたいに分業するとコストが増加
• フロントだけ忙しいみたいになる時期が発生する
• 開発チーム全体としてプロダクトを完成できる能力を持つ必要がある

開発改善

• 技術に向き合う、技術がなければ素早い変化には対応できない
• 作る量を減らしてでも安泰したパフォーマンスを出せるような投資をする
• 継続的にテストできるようにする

非難文化

• 非難の体操を自分や自分のグループから他人に反らそうとする

「あなたのチームは機能してますか？」
https://amzn.asia/d/eJR54Mq

意見を言えて、改善や実験(と失敗)を繰り返せる安全性がハイパフォーマンスにつながる

コミュニケーションの複雑性を抑える

• 1チームは10人程度までが適正
• チーム同士のコミュニケーションも対象チームが増えると複雑になり動きがどんどん遅くなる
• プルジェクトの規模を小さくする必要
• チーム間を疎結合にする必要

The API Mandate (ジェフ・ベゾス)

チームの認知負荷を考慮する

• 人間が脳に留められる情報量には限界がある
• チームにも言える
  • 優先順位が付けられなくなる
  • モチベが下がる

認知負荷に合うように責任範囲を制限する

• チームが扱うソフトウェアのサイズを制限する

複数プロジェクト兼任は悪影響しかない

これらを踏まえてチームを構成する

• これらを踏まえてチームを構成する
  • ただし組織構造をいじるのは他の改善の後が良いかも
  • そうしないと無駄なものを大量に作りやすくなってしまう
• どうやって？
  • 価値の流れを中心におく
  • コンウェイの法則を踏まえる

チームトポロジー
https://amzn.asia/d/b1uUVpt

機能しているチームを長く保つ

ハイパフォーマンスなチームを解散するのは単なる破壊行為では済まない

チーム力の改善

• 非難文化から脱却する
• コニュニケーションの複雑性を抑える
• チームの認知負荷を考慮してチームが担当する仕事を決める
  • 兼任はしない
• 必要ならチーム構造を作り替える
• ハイパフォーマンスチームは解体しない

まとめ

• アウトカムに注目して改善
• プロセス改善だけでは無意味
• 複数の領域で改善していく
  • 問題設定力
  • 開発力
  • チーム力

QA

非難文化を改善するには？

• 会社全体を変えるのは経営者が変わらないと難しい
• チームはマネージャーはこうすべき、みたいな本を読む
  • 振り返ってちょっとずつ改善

できる人を兼任させたがる場合の対処法

• NOとしっかりと言えるようにする
• 全部YESというといつか破産する
• 頼んでくる人は状況を考えずにどんどんドンドン言って来てしまう

メンバーが組織改善を提案する場合どう提案すべきか

• ファクトデータを提示することで説得力が出る
• メンバーの声を集めてテキストで投げる
• マネージャーに1on1などで伝える

ブログ
https://syu-m-5151.hatenablog.com/entry/2023/03/03/105049

アジェンダ

• About 3-shake(宣伝)
  • DevOps領域のプラットフォーマー
  • Sreake SRE(SER総合支援サービス)
    • AWS/GCP/Kubernetesなどに強い
• DevOpsとは
• SREとは
• 2023年SRE再考

class SRE implements DevOps
SERはDevOpsというinterfaceの実装である

DevOpsとは？

• 以前はDevと運用(Ops)で対立
• Devのゴール
  • 新しい機能を追加してビジネスの売上を上げる
• Opsのゴール
  • 安定かどうを実現して機会損失を防ぐ

システムが複雑化して開発と運用を切り離すことが難しくなってきた

• 運用と開発の仕事を同時に行うと生産性が20%減少する
• 1日10回以上のデプロイ: FlickrにおけるDevとOpsの協力
• DevOps Research and Accelerate(DORA)
• 2015 State of DevOps Report
  • DevOpsを導入している会社はパフォーマンス、満足度が高い
• 2018 State of DevOps Report
  • DevOpsの進化の段階を5段階で定義
• 2019
  • DevSecOpsについて
• 2020
  • PlatformエンジニアとDevOpsの話
  • クラウドの活用について
  • 承認プロセス
  • 自動化されたテストと自動化されたデプロイ
• 2021
  • SER実践への道
  • 安全なソフトウェアのためのサプライチェーンに関する言及
  • ドキュメントに対する言及
  • 燃え尽き症候群などに関する言及

DevOpsを実装していく

Effective DevOps(書籍)

• コラボレーション
• アフィニティ
• ツール
• スケーリング

２つの要素が重要

• 文化
• ツール

SREとは？

よくある誤解

• SRE = インフラの呼び方が変わっただけ

SERという単語からくる期待

• 可読性/信頼性などのSRE本に書いてある概念を運用に導入する

SERサイトリライアビリティエンジニアリング(書籍)
'信頼こそがあらゆるプロダクトの基本的な機能`

SERとは、組織が信頼性を制御するための技術

信頼性の階層を築く

• 今いる場所から始めることが大事
  • モニタリングから始めて信頼性を上げていく

広がり深まり求めるSER

SERの探求(書籍)

• SREはいまだに広がり続ける銀河
• あなたらしくSER(同僚の方の資料があるらしい)

2023年SRE再考

信頼性が確保できるとプラットフォームにしたくなる

• 信頼性は最も重要な機能
  • 使いたい時に使えないシステムは信用できない
  • 価値があれば信用を得られる

プラットフォームにしたくなる

• 重要なものはいつかプラットフォームに

最初からプラットフォームを見据えろ

変更速度を両立したくなる

振り返り

• Devのゴール: 新しい機能の追加
• Opsのゴール: 安定稼働

SERとは、システムの信頼性を制御するための技術
→変更速度のために信頼性を上げたり、維持したり、下げたりできる

未知のものを見つけたくなる

既知の未知(Know unknow)に対応する

モニタリングの場合

• Linux監視
• ミドルウェアの監視
• アプリの監視

マイクロサービス

• サービスを横断するリクエストの追跡

目指すのは反脆弱なシステム・組織

モダンフロントエンド

• ES2015
• React
• TypeScript

など

これらはどのよう需要があるのか？

jQueryなどの時代から見ると

• Node.jsなどのツール類が充実
  • Webpack
  • ES2015へのトランスパイラ
  • 圧縮
• デプロイされるJSと開発者が書くJSは異なるものになる
• 作るもの自体がフロントエンド中心になって来ている
  • 今はPCよりもスマホが主流になっている
    • UI側でやることが多い
    • キーボード入力よりもジェスチャーなどが増える
• 作るものの複雑化、やることが増えた
  • フロントで複雑なことをすることが当たり前になって来ている
  • そのためのツール類の進化

フロントエンドの変化が早すぎる

• 2015,2016年くらいでたくさん言われた(ちょうど過渡期)
• 半年前はCoffeeScriptだったのに急に変わった
• Backbone.js使っていたら気がついたら別のフレームワーク(Angular, React, Vue)に置き換わった
  • jQueryとのインテグレーションが多かった
  • 作ることが多い、複雑化
  • 双方向でバインディングできるような仕組みがトレンド化してきた
• Reactが流行った理由
  • Reactドキュメンタリーという動画があるらしい
  • フロントが大変なところは表示と内容の更新
  • 表示と更新を同じような書き方で書きたい
    • 今までは処理が分かれていた
    • Reactは一緒にできるようにした

Vueの文化ではミニマムな思想だが、ReactはReduxなどの大規模な思想がある
どこから来たのか？

• データのstateをどこで持つか？
  • ここのコンポーネントで持つとアプリ全体から見た時に状態が分からなくなる
  • 中央集権することで分かるようにした→Redux
• グローバルに持たせる文化は結構前からあった(グローバル変数ではない)
• 使うところと変更するところを一緒にすれば安全だよね
• ステートレスなコンポーネントが理想という発想(関数)
• Hooksの登場で流れが変わってきた
  • 途中の状態をどう扱うか？

全部を集約するという考えは間違いだった(Redux)

• APIのキャッシュも持っていた
• フォーム情報を全て持っていた
• それぞれの役割として持つようにすべき

SSR/SSGについて

• パフォーマンスの改善
• レンダリングの多様性
  • 前はバックエンドからのレンダリングだけだった

いつまで「今」は続くのか

• 少なくとも今はアプリ開発において数年間は使われるのでは？
• 10年/20年になるとAIが入って来たりで変わるのでは？
• 近年でも変わって来ているところがある
  • RESTからGraphQL
  • tRPC
  • TypeScriptとどうインテグレーションを取っていくか？
• 大体Next.js/TypeScriptがデファクトみたいになっている
• Whatは同じだけどHowが変わって来ている
  • より高速なビルドシステム(Webpack/vite)

フロントエンドエンジニアは最もユーザーインターフェースに触れている

• そちら側にフォーカスしていくべきでは？
• コモディティ化して来ている
  • 専門家の知識が不要になってくる
  • まだコモディティ化しきってはいないから一定の需要はある(長期では分からない)
• 大多数の人はコモディティ化した技術をキャッチアップすればよかった
• 今後の差別化という意味ではビジネス価値に重きを置くことかも

「フロントエンド」の概念が劇的に変わる時

Javaのようなかっちりした文化から動的型付け言語でサクッと作れるように変わった歴史

• Ruby on Railsを中心にフロントの流れも変わって来た
• APIとの通信はまた型文化に戻りつつある

変わるタイミング

• ニーズが変わる時
  • ChatGPTやGitHub Copilotの登場でも変わってくる可能性
  • それらを上手く使いこなせる人の需要が増えるのでは？

お昼出ていて見れませんでした

開発体制

3拠点
120名程度

backlogの開発チーム

• 32名体制
• PdM
• TechLead
• EM
• SWE: それぞれのチームに3名程度の体制

開発に対する取り組み -SME-

• Subject Matter Expert(SME)
  • テーマ別に担当者を指名し業務の20%の範囲内で改善活動を進めている

体制面における課題

• チームによって認知負荷のばらつきがある
• マネージャーの人手が足りていない
  • 専任のマネージャーは一人

技術面

• Haxe, TypeScript(React)
• Scala(Play), Go, Perl
• AWS
• Elasticsearch, Solr
• ドックフーディングしながらの開発

直近の改善

• React化
• Auroraのバージョンアップ
• コンテナ化
• Git Protect Branch
• 外部サービスとの連携強化
• かゆいところに手が届くアップデート月間

技術的負債解消への取り組み

• 歴史が長く負債が多い
  • パフォーマンス
  • メンテコスト
• 技術的負債対応検討委員会
• 新機能開発とのバランス計画
• ゼロベースの再設計もする

開発者の邪魔をしない/させない

• 開発者に集中してほしい
• 例えば負債返済の提案を受けた場合
  • リソース調整
  • 状況によっては他の開発をストップ
• 他部門や経営層から横槍が飛んできたら
  • 彼らの理解できる言葉で説明責任を果たす

その他

ブログ発信
https://nulab.com/ja/blog/

カルチャー作り

• 日常のコミュニケーション
  • 朝会
  • 勉強会
  • 輪読会
  • Typetali上でのコミュニケーション
• 機能開発以外の改善
  • 毎週金曜日は改善活動の日
  • SME活動
  • 技術的負債の管理

SERと開発組織

４つのチームタイプ

• ストリームアラインドチーム
• イネイプリングチーム
• メモ取れなかった・・・

Four Keys メトリクス

Four Keysが分からないから調べる
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

インフラの仕組みだけで解決できる限界

SERはどうしてもインフラから入ってしまう

SERと開発者が協働して進めるには？

1. 開発生産性・メトリクスの基準を統一する
2. 改善活動をみんなが目標とする
3. 数値を追うのではなくて目的・目指すものを明確にする

開発生産性・メトリクスの基準を統一する

生産性の指標が必要→Four Keys

元は手動で集計(スプシ)して可視化していた

変更に強いメトリクス集計

• ツール、組織、事業フェーズによって変わる
• 最近はメトリクス集計の外部サービスがある
  • はじめはコスト面的に無料で試したい
  • スプシ、GitHub, Google Looker Studioで自作したらしい

Google Looker Studio

• ノーコードで集計ができるらしい

アプリケーション領域の改善

• アプリエンジニア、SERが協働
• 改善のためには体制を作る必要性がる
  • 改善に興味がある人を集めてチームを作った

SRE個人をストリームアラウンドチームの一員として埋め込み、中から改善する

実際にあった怖い話

• とあるPRを1ヶ月放置していた
• 再開する際にPRブランチを作り直した
• リードタイムを3日にすることが目的になってしまっている

リードタイムが表す意味

• First Commit→リリースまでの日数
• 最近はスモールリリース・Feature Toggleという手法がある
• リードタイムはPRの単位(機能の単位ではない)

リードタイム短縮の目的

• 障害を減らしたい
• リリース複雑性を減らしたい

開発者体験が高い組織 = 幸せが高い組織

• スピード・気軽さ
• リリースの複雑さ
• 品質の高さ

速度と安定性は表裏一体

まつもとりーのこれまでとCOGNANOのこれから

• 京大博士(情報学)研究者
  • クラウドコンピューティング、ホスティング
• さくらインターネット研究所 研究者/マネジメント
  • インターネット基盤に関する研究
• COGNANO
  • ITとバイオのコラボ事業を見据えた経営戦略・研究開発戦略の立案

赤川さんQuestion

取締役CTOとしての立ち位置について

• 社長がボストンなどに行って共同研究の話を進めている
• それに対してITの技術が必要になってくる
• 人材集め、組織作り

バイオの話は軽々しくオープンにできない内容があるらしい(確かに)

ITだと資金調達の際にとりあえずプロトタイプをサクッと作ることができるが
バイオは研究開発で何億円ものお金が必要になる。
数打てば当たるような業界でもないし、10年後に成果が出るかもしれない
投資家目線からしても難しい領域

諸事情により不参加だったのでアーカイブ見ます