最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取り組みをひとつ紹介します。 私のチームでは10個近いコンポーネントのオーナーシップを持っています。それらの品質の期待度は大きく異なり、変更頻度、採用技術、システムに占める重要度といったパラメータから決定されます。この期待を見誤ると、変更頻度が極めて低いコンポーネントを頑張ってリファクタリングしたり、モダンな技術が採用され寿命の長いシステムを雑に拡張したりと、成果の小さいアクションを取ってしまいます。逆にこの期待を適切に捉えられると、チームのリソースがコスパが高いアクションに向かっていくことが期待できます。変更頻度の高いコンポーネントのCI/CDを改善し、重

Felipe Castro is an OKR expert helping organizations implement and successfully work with agile goal management systems. Through his mentoring of countless companies, Castro recognized early on the habits that repeatedly led to failed OKRs. While these anti-patterns may seem beneficial at first, they can quickly lead to negative consequences. They can be broken down into three core areas: Setting

ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の