-
株式会社ずんだもん技術室AI放送局 podcast 20241129
- 2024/11/28
- 再生時間： 1分未満
- ポッドキャスト
-
サマリー
あらすじ・解説
関連リンク 大人数チームで意思決定のスピードアップのためにやったこと 食べログの予約サービスチームは、利用者増加に伴う組織拡大により、コミュニケーションコスト増大、情報伝達の遅れ、開発スピードの遅延といった課題に直面していました。 これらの課題解決のため、チームは組織編成と情報共有方法に工夫を凝らしました。 まず、2名のエンジニアリングマネージャー(EM)と、複数の小チーム（ユニット）からなるユニット制を採用しました。 EMはそれぞれ異なる領域（運用・改善、プロダクト開発）を担当し、責任範囲を明確化することで、意思決定の迅速化を図りました。 さらに、チームリーダーを配置することで、チーム全体の方針やルールの決定を効率化しました。 ユニットの規模を小さくすることで、リーダーの管理コスト軽減と、リーダーが自ら開発に携われる環境を整備しました。意思決定はボトムアップ型を取り入れ、メンバー、リーダー、マネージャーの各レベルで適切な権限と責任を明確化することで、スピードアップを図りました。 情報共有は、日次と週次の2段階で行われます。 日次では、ボトムアップ型で情報を集約し、重要な課題や意思決定事項を迅速に共有します。 週次では、各ユニットからの情報をEMが集約し、チーム全体に展開することで、チーム全体の状況把握を容易にしました。 他チームとの情報共有は、ユニットリーダーとEMが窓口となり、効率的な情報伝達を実現しています。 今後の展望としては、他チームとのコミュニケーション改善、システムのリモデリングによるドメイン整理、エンジニアリングへの集中を促進するための更なるコミュニケーション改善に取り組むとしています。 これらの取り組みを通じて、開発スピードの向上とエンジニアの生産性向上を目指しています。 本記事は、大規模チームにおける組織設計と情報共有の改善に悩む日本のエンジニアにとって、貴重な参考事例となるでしょう。 引用元: https://tech-blog.tabelog.com/entry/2024/09/tabelog-engineer-information-communication 本番DBのマスターデータを全行ぶっとばすやらかしをしたときのお話、その反省 この記事は、本番DBのマスターデータを誤って全行削除してしまった事例とその反省について記述しています。深夜帯に稼働するSNSサービスにおいて、マスタデータのJSON型カラムを全てブランク値で上書きする作業中に事故が発生しました。原因は、開発環境での動作確認を省略した、UPDATE文によるデータ更新スクリプトの誤作動です。 復旧はRDSのスナップショットからの復元で行われましたが、データ容量が大きかったため1時間程度を要しました。この経験から、以下の反省点が挙げられています。 バックアップの不足: 作業前にSequel ACEによるレコードエクスポートや、CSV形式でのバックアップ（Copy Insert SQL機能活用）を行うべきでした。大量データの場合は、LIMITとOFFSETを使用して分割バックアップが推奨されます。 トランザクションの未活用: START TRANSACTIONとCOMMIT/ROLLBACKによるトランザクション処理を行うべきでした。これにより、更新クエリ実行後のデータ確認を行い、問題なければコミット、問題があればロールバックすることで、データの整合性を確保できます。 スクリプトからの直接クエリ実行: Pythonスクリプトで直接更新SQLを実行する実装は、事故発生時の影響が大きいため避けるべきです。スクリプトはクエリの生成のみとし、実行は手動で行うべきです。 開発環境での動作確認の省略: 過去に同様のスクリプトを使用していたため、開発環境での動作確認を省略しましたが、これは重大なミスでした。時間的制約があっても、開発環境での動作確認は必須です。 この事例は、本番環境での作業におけるリスクと、それを回避するための対策を学ぶ上で非常に貴重な教訓となります。新人エンジニアは、この経験から学び、本番作業前に必ずバックアップを取得し、トランザクション処理を行い、開発環境での動作確認を徹底するよう心がけましょう。 引用元: https://zenn.dev/kazutosakagami/articles/78d1649389c868 Raspberry Pi Compute Module 5 cranks up the power – and the...