分散モノリスを脱するために管理するGithub repository数を17個削った話 - SO Technologies 開発者ブログ
こんにちは、ライクル事業部 エンジニアの菊池@kichionです 現在、ライクルでは大きく2チームで分かれて開発を進めており、私は技術負債解消を行うチームでシステム改善を行っています ライクルでは早すぎたマイクロサービス化によりコードベースが30近いGithub repositoryに分散しており、システムツールのrepositoryを含めると50のrepositoryが存在していました。 アジリティ向上のため、コンテキストをまとめrepositoryを17個削ったのでその方法論を紹介したいと思います 背景 分散モノリスとの闘い 1. 重複コード・知識の分散を"なるべく"解消する 2. 使っていない・今後の仕様に耐えられない機能を消す 3. メンテナンスが辛くなったrepositoryの整理 4. 問題の複雑化を招いていたデータソースの整理 5. コンテキスト毎にrepositoryをまと
メンバーからのフィードバックに向き合う - Konifar's ZATSU
7月にEMをやめたのだけれど、実は最近マネジメントロールに戻った。 1on1などで自分や組織の至らないところについてメンバーから率直なフィードバックをもらうことが多く、そのたびに本当にありがたいと思っている。ちなみに最近もらってよかったフィードバックは、「ハレーションを恐れすぎ」です。 メンバーからのフィードバックは受け手のスタンスや振る舞い次第で何も言ってもらえなくなったり信用をなくしたりすることもあるので、「メンバーからのフィードバックに向き合うとはどういうことか」を雑にまとめておきたい。 フィードバックをもらうまで フィードバックを受け付けていることを伝える 言いにくい話も多いので、スタンスを明確に伝えておかないとフィードバックはもらえない 予定が詰まっていると遠慮されてしまうので「予定は調整するのでいつでも声をかけてほしい」と伝えるとか 意見を持ってそうな人には直接声をかけるのもよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
