「Developers Summit 2024 Summer（1日目）」に参加してきました

• 2024/7/23
• https://event.shoeisha.jp/devsumi/20240723

エンジニアとビジネスの距離感の難しさと夢

• 河合 俊典さん[エムスリー]

エンジニアとビシネスの距離

• ビジネスとエンジニアの距離感
  • 資本的距離
  • 性質的距離
  • 環境的距離
• エンジニアが目指すこととビジネスが目指すことを両立させる
  • エンジニアはエンジニアとしてのスペシャリティを高める
  • 技術を発揮する適切な場所タイミング
  • 技術が活用されるように動く

多くの開発者が知らないFigmaのポテンシャル〜Figma APIやDev Modeを活用したフロントエンド開発

• 谷 拓樹さん[Figma Japan]
• リー・コーリーさん[Figma Japan]
• https://www.figma.com/community/file/1397244591905482172/dev-modefigma-api-figma

Dev Mode

• Figmaはデザインツールだが開発者に連携するもの
  • 開発者のニーズにもあわせて専用モードを作った
• デザイナーと開発者のハンドオフ
  • 握手する一瞬で成功か失敗か決まってしまうのか？
    • 接点は一瞬ではないし複雑
    • 一方通行ではない

DevModeのワークフロー

• DevModeはデザインナーと開発者の架け橋
  • 共通言語を持てる
  • 変数やコンポーネントの命名
  • デザインで言うこれは実装で言うこれ、みたいな翻訳がいらなくなる

Align

• 共通の語彙
• 色とか文字とか余白とかの定義
  • デザイントークン
  • 最小単位
    • variablesで命名して意図を込められる
• コンポーネントのバリエーション
  • 命名してパターンを作れる
  • デザインデータをさわることなくパターンをUIで確認できる

Inform

• 言語化する
• コンポーネントの定義と共に説明文も書ける
• 注釈機能による補足

Connect

• デザインとコードをつなげる
• Figmaのコンポーネントがデザインシステムに存在するかわからない
  • FigmaからStorybookなどのリンクをつなげられる
  • コードをFigma上に表示することもできる
• FigmaのREST APIで変数の変更をコードに反映(PR作成したり)
  • コードの変更をFigmaに反映することも
• PluginAPIでコードへの書き出しを簡略化
• Figma for VSCode
  • VSCode上でFigma開ける
  • コメント書いたり見たりできるのがいい

開発と事業を繋ぐ！SREのオブザーバビリティ戦略 ～開発者体験UPで、全員幸福なサービス開発へ～

• 蒲生 廣人さん[レバレジーズ]
• 高木 憲弥さん[New Relic]

レバテックの戦略と課題

• 2軸で動いてる
  • リアーキテクト中
    • 業務影響のないリリース
    • なるべくはやく
  • 既存システムの運用
    • 安定的運用
• 既存システムの運用課題
  • 信頼性を計測できていない
  • マイクロサービス同士の通信が複雑

オブザーバビリティの採用

• SREからのアプローチ
  • システム内部構造の可視化
  • 信頼性の計測
• NewRelicの導入
  • 新たな実装無しで可視化
  • 属人性の軽減
• SLI/SLOの設定
• 予測モデルの作成
  • システムとビジネスの相関性
  • どこのSLOが下がったらどれくらい事業影響が出るかとか
• オブザーバビリティ成熟度
  • どの段階までできてるかの指標

講談社流!!基幹システム開発における、ハイブリッド開発の適用術～開発マネージャが語る成功の秘訣～

• 小山 佳祐さん[講談社]

基幹システムの開発

• アジャイル開発が難しい
  • 品質/予算納期/保守への引き辻
• ウォーターフォールだとユーザニーズ汲み取りきれない
• ハイブリット開発で

アジャイルとウォーターフォールのハイブリット

• 営業支援システムの開発
  • 7年稼働してる
  • ビジネス環境の変化
  • 古いOSやミドルウェアが足かせ
• どこまでウォーターフォール的にやってどこからアジャイル開発するか書いておく
  • 企画段階で
  • 要件定義まではウォーターフォール的に
    • 丸ごと移行ではなく不要なものを削っていく
    • ニーズの深堀りをして本当に必要なものを見極める
• プロダクトバックログ
  • 背景も含めてちゃんと書いておかないと後から分からなくなる
  • 要件定義との紐づけ
  • 優先順位をちゃんとつける
• スプリントレビュー
  • 受け入れ条件の達成を確認する
  • 観点を明確にして実施する
  • 修正なのか改善なのか
• テスト
  • 要件の確認観点と紐づける
• 移行
  • どこまでできたら業務運用開始するか定義しておく

新プロダクトの開発プロジェクト。最短最速に魂を売る！新しいアーキテクチャとプロセスの提案！

• 吉井 健文さん[リクルート]
• 竹下 由美さん[リクルート]

開発速度をあげるためのアーキテクチャー

• indeed plusが独立したサービスからプラットフォームへ
  • ボトルネックとなる部分のリリースを早めたかった
• 3倍の人数をあてて速度を3倍にする
  • 一般的にはアンチパターン
  • コミュニケーション観点でコストが増す
  • それはタスク間に依存がある場合
  • コミュニケーションパスが増えないようにした
• FE - BFF - BEのラインを複数作る
  • 相互に依存させない
  • BFFとBEのコミュニケーションが重い
  • なのでBFFの多くをBEに寄せた
• UIコンポーネント
  • コンポーネントとAPIが1対1になるようにする
  • 相互に依存させない
• 要件定義の段階でこの構成にできるようにしておく
• データベースだけは共有するしかない
  • DBの設計を最初にしてロックする
  • 主要な数画面のみ設計して早期に確定
• 開発が始まると想定外の事態がおきてコミュニケーションが発生してしまう
  • バッファのフェーズをとってそこでまとめて見直す
• 結合テストの段階では協調させる
  • FEどうしなど最小限で

ソフトウェアテスト領域のトップランナーが語る！事業に貢献する品質保証とは

• 末村 拓也さん[Autify]
• 河原田 政典さん[グロービス]
• 風間 裕也さん[10X/B-Testing]

ソフトウェア品質

• 何がどうなれば高い品質と言えるのか
• バグがなくても使われないと意味がない
• バグがあっても使われるものはある

パネルディスカッション

• 品質悪くて売れないと相談されたら
  • 品質といってるものがどんな部分か突き詰める
    • バグが多い？
    • 速度が遅い？
    • セキュリティが甘い？
  • カスタマーサポートの人が情報を持ってたりする
• QAって売り上げにつながらないからあコストでしかない？
  • テスト設計を前倒しすることで全体のコストが下がるはず
  • 後ろの段階で何か見つかると大幅にコストがかかる
  • テストの実行までをみるとコストでしかないかもしれないが結果も踏まえると削減につながる
• アジャイルにおける品質
  • 最初のリリースで最高品質を求めなくて良い
  • リリースし続けることに耐え得る品質が必要