[Day 3: A-2] Octocatは技術的負債の夢を見るか?


yhirano55

登壇者: Repro株式会社 treby 氏

Repro株式会社ではアプリ向けのアナリティクス/マーケティングのためのRepro SDKを提供しています。

直近では4400万全体MAU、月間40億Push通知配信を行うくらいの規模感になってきました。

我々エンジニアが取り扱うのはそんな大規模データをさばくシステムですので、会社のカルチャーとしてエンジニアリングに関して軽視されることはありません。

ただ、そんな環境でもいわゆる技術的負債と呼ばれるものは存在し、しばしばバグの原因となったり、エンジニアの機能開発の妨げとなったりします。

このセッションでは、いかにして技術的負債は生まれるか、また生まれた技術的負債をどうするのか、技術的負債との向き合い方をご紹介します。

https://techplay.jp/event/679666


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(0)

Questions and feedbacks (6)

treby
treby commented about 1 year

@shinkufencer ありがとうございます。Reproでは概ね以下のように機能開発を行っています。

  1. タスクの発生
  2. PM、営業とコミュニケーションをとり、機能仕様を確定
    • 完全に確定しない場合もあり、その場合はとりあえずたたき台を作ってみることも
  3. データの構造に手を入れる場合は設計レビューを行う(CTOか、CTOレベルの設計力を持つメンバー、もしくは両方をレビュワーに入れる)
    • 自分で考えて終わり、ではないので1, 2日考えたらesaにアウトプットしてレビュワーレビュイーで叩く
      • 大体往復分含めて1週間から10日かかることもあります。、
    • 詳細仕様が決まっていない場合は決まったあとに行います (仕様が変わると手戻りになるため)
  4. 手を動かして実装する
    • この段階で機能仕様を満たすのがどう考えても大変な場合はPM相談することも
  5. UX確認
  6. コードレビュー

設計レビューでは、テーブルのschemaやER図、カラム名・テーブル名・変数名の合意を取ります。

Like(1)

treby
treby commented about 1 year

@asflash8 ありがとうございます。 今ちょうどチーム内で議論が行われている部分なのですが、現段階の運用としてはメンターメンティー制をとっています。 つまり、新しいメンバー(メンティー)に対しては実際の業務を通じてメンターが地図を共有していくイメージです。

ドキュメントも書きますが、どうしても古くなってしまう問題もあり……開発全体で20〜30人規模のチームの例ですが参考にしていただけると幸いです。

Like(1)

treby
treby commented about 1 year

@kyanny ありがとうございます! 取り急ぎご用意しましたのでご確認ください。 https://www.slideshare.net/treby/octocat

Like(0)

kyanny
kyanny commented about 1 year

感想です。「事業として価値がある部分に技術的負債はうまれる」、含蓄があって大変よいお話だと思いました。同僚に紹介したいので資料を公開してほしいです!

Like(1)

asflash8

地図を共有するのが大事という話したありましたが、どうやってメンバーに地図を共有していますか? クラス図などのドキュメント?コードレビュー?

Like(0)

shinkufencer

設計レビューとかどういうふうに進めているのか、どういうフォーマットを扱っている感じのか例として何かあれば

Like(0)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano