Closed3
24/04/01 アプリケーション開発エンジニア勉強会参加レポート
お窓概要
2024/04/01 19:00~21:00 に オンラインで開催された アプリケーション開発エンジニア勉強会に
参加したので、そのレポート、というよりメモをせっかくなのでまとめます。
備考
- これは個人のメモです。"聞き取りミス等あるかと思うので参考程度に"
- おそらく後日こちらにレポート等記載されると思うので、こちらの確認がおすすめです。
- azukiazusaさんの "React フレームワークの 動向と選定基準" のLT資料はこちら (はてブで人気でした)
- 実はイベントの存在を忘れてました。
- 最後の登壇しか見れてないため、最後の登壇のみ記載します、すみません🙇
お窓バザー形式のスプリントレビューと それを支えるCI/CD
株式会社OPTiM 今枝さん
概要
現チームでは開発手法にスクラム開発を採用している。スクラム開発は計画(スプリントプランニング)、検査(デイリースクラム)、成果の確認(スプリントレビュー)、振り返り(スプリントレトロスペクティブ)の4つで回るのが基本。特にその中のスプリントレビューを改善したというお話。
課題1 形骸化したレビュー
"開発者が発表 プロダクトオーナーに受け入れ条件を確認してもらうだけの状態"
- 機能を知っている前提で内々で共有している
- 顧客・営業のフィードバックが得られないし 今後の機能について話し合えない
- クローズに開催していることで、他チームにプロダクト状態の周知ができない
解決策: バザー形式を採用してみた
- バザー形式とは?
- オープンな場のこと、実際に触ってもらいフィードバックを得る
- 営業/デザイナー等など参加可能
- 事前に(リアル)開催場所を周知
- 口頭質問・チャット質問を受け付けて フィードバックを受けられるように
- オープンな場のこと、実際に触ってもらいフィードバックを得る
- バザー形式のタイムスケジュール
- OP (5分)
- ローカルPCを用意して 15分x3セット分 発表
- プロダクトオーナーが質疑応答 (10分)
- 開発者がフィードバックで得られる効果
- より有意義なフィードバック
- 様々な操作によりバグが見つかりやすい
- (別チームから来た人が)POだけでなく開発者に直の質問ができる
- 参加者がフィードバックで得られる効果
- 営業: 定期的に新製品の動向を知ることができ、売りやすい
- デザイン: 他のユーザーの利用する場面を観察しデザインシステムの課題を発見できる
課題2: 十分結合されていないローカル環境での 成果確認
"スプリントレビューに間に合わない、駆け込みデプロイ状態"
- リリースが間に合わない
- デプロイ準備に毎回時間がかかる
- 実際触れないと仕様がわかりづらい
解決策: CI/CDを改善した
- デプロイフローの見直し
- 改善前:
- developにPRマージでイメージPush
- 新イメージをつかうように 手動でk8s設定の修正PR作成、マージでデプロイ
- 改善後:
- developにPRマージでイメージPush & k8s設定の修正PRを自動作成
- k8s設定の修正PRマージでデプロイ
- "手動で行う必要があるフローを削減"
- DEV/STGに1日 1~8回ほどデプロイできるようになった
- 改善前:
- ドキュメント生成フロー見直し
- RDBMS(DBドキュメント)
- SchemaSpyで検索可能なER図とテーブル情報をPRの都度生成
- OpenAPI(APIドキュメント):
- Redocをつかう ドキュメントをPRの都度生成
- Storybook(デザインドキュメント):
- (恐らくChromatic?)でコンポーネントカタログをPRの都度生成
- RDBMS(DBドキュメント)
まとめ
- バザー形式で 従来の受け入れ条件確認のみのレビューを脱却
- より有意義なフィードバックを収集可能に
- CI/CDで運用改善
- 仕様確認が必要になったとき アクセスしやすい導線を整備
QA
- 仕様変更がよく起こり 計画がずれてしまいそうに思う
- フィードバックは幅広く受け入れることで品質向上をする、ズレは起こるものと許容する
- OPTiMでの過去の開発手法について
- 開発手法はチームごとにチョイスしている
- 近年は基本的にスクラム
お窓今回参加した3社エンジニアさんに訊く
保守性・可読性を上げるために 設計で大切にしていることについて
Seiyaさん / パーソルキャリア株式会社
- レビュー体制が大事
- 開発しながらレビューもする、レビュー体制を属人化させない。
- (コミットに)コメントを付ける
- コミット1つ1つのprefixを付ける
- "なんのため" というコミットメッセージを残す
- PRメッセージのルールを決める
- 引き継ぎの時に見返しやすいPRにする
- 複数プロダクトの掛け持ちやメンバーの入れ替わりも多いため
azukiazusaさん / 株式会社はてな
- フロントを得意じゃない人がコードを触ることを想定する
- 難しいところは抽象化して 新しい機能を追加しやすく
- 難しい事を考えずに、少し足すだけで実装できるように心がける
- 可読性を上げるポイント
- ESLint等の静的チェックツールを活用する
- Lintルールを重要視する
今枝さん / 株式会社OPTiM
- できる人が共通化をする
- ディレクトリルールを決めてちゃんと整理して触ってもらえるようにする
- 静的解析ツールを導入してコード品質を担保する
- 複雑さを制限するCyclomatic(循環的複雑度)系のLintルール
- if文の数を制限するGo系のLintルール
- コミットメッセージのルールを設ける
- Commitlintを導入する
- gitemojiを必須にする
- issue番号を必須にする
今のアプリエンジニアの立場で嬉しい点 / どうスキルアップしてきたか
Seiyaさん / パーソルキャリア株式会社
- 裁量の大きさ、フロント・バック・アナリティクス なんでも触れる環境。裁量がでかいからこそ色々なことに挑戦できて嬉しい。
azukiazusaさん / 株式会社はてな
- 裁量の大きさが嬉しい。(株式会社はてなでは)エンジニアのアウトプットを重視しているので、ブログ書いたりとか 技術コミュニティへの貢献とかも評価されている。
今枝さん / 株式会社OPTiM
- 裁量の大きさ。技術選定を現場でできる環境が良い。(株式会社OPTiMでは)OSSのコントリビュートなどの報奨制度があります。
このスクラップは2024/04/03にクローズされました