[Day 2: B-4] バス因子が自分でバス因子を脱するための方法


yhirano55
yhirano55 commented 2 months

登壇者: 株式会社Fablic 片山 潮美 氏 @sinamon129

あなたのプロジェクトには、バスに轢かれたらプロジェクトが破綻する人が何人いますか?

自社サービスを運営している組織において、サービスのスケールのためには開発組織のスケールが必要不可欠です。

急成長中である日本初の Ruby on Rails で作られているフリマアプリ フリルを開発するFablicのエンジニア組織において、バス因子である私が、組織のスケールのために脱バス因子するために同僚と行ってきたことを成功失敗両事例お話します。

https://techplay.jp/event/655769


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

Like(0)

Questions and feedbacks (4)

sinamon129
sinamon129 commented 25 days

懇親会等で、各質問者の方に直接回答させていただいたのですが、 回答を見たいという要望がありましたので再度ここに回答していきます!

もし、エンジニアに依存する他チームがなかなか自立してくれない、しかしそのチームがワークしないことには事業として危ぶまれるといった場合にはどのようなアプローチを取ることが望ましいと思いますか?

割とここは他チームがエンジニアの担当範囲だろうと思われていたり、逆にエンジニアが他チームの担当範囲だと思っていて…みたいなことが相互に起きてしまっている場合があるかなとおもっていて、 それぞれに期待することをすり合わせるのがいいのかなぁ、と思っていたりします。

エンジニアじゃない方からすると、システムに近い部分は自分の判断でやって大丈夫なのか?と不安になっているから、お願いしてきているのかも知れないです。 自分のチームで解決できる方が話も早いとおもうので、解決の仕方を伝授してやってもらうなどもありかも知れないです。

暗黙知が特定個人に蓄積し続ける状況を組織的個人的に対処していく取り組みのなかで、「いまいちだったなあ」とか「うまくいかなかったなあ」といったようなことがあれば教えてほしいです。

カスタマーサポートの人からの調査・修正依頼のチャンネルに対する対応を、よく気づく2人ぐらいがやっていた時に、 これは負荷を分散しないと行けないということで、 一次対応者を全エンジニアから毎日ランダムに2人選ぶ、という試みをやっていたことがありました。

当時よく起きていた問題や頻度を全員が把握できて、ドキュメンテーションや根本解決がすすんだという面はあったのですが、 どうしても差し込み作業になってしまうため、2人でも早く反応する人がでてきて偏りが生じたり、 しびれを切らしたよく反応する人が出てきてしまったりという現象がおきました。 また、カスタマーサポートからの依頼のドメイン範囲が広く、10人以上の中で2人選ぶため、調査・修正に対する知見が個人に厚い状態で貯まりづらい、という問題がありました。 (そのため、難易度の高い問題はどうしても一部のメンバーへエスカレーションされてしまう)

現在はドメインごとに担当者を置いているので、知見が貯まりやすい状態になってきました。

自身がバス因子であることを自覚したのはどういうことがきっかけですか?

スライド中にもあったように、いないとやばいといわれることが増えたこと (なにか問題に対する一次対応速度が早いのと、みんなが把握していないことを知っている事に気づいた時)

自分の仕事が本当に回らなくなって、間に合わないですごめんなさいというコミュニケーションを取りまくっていて辛くなってきた時に、ほぼ自分だけが対応している緊急対応が連発した時とかですかね…。叫んでました。

Like(4)

kuntao
kuntao commented 27 days

自身がバス因子であることを自覚したのはどういうことがきっかけですか?

Like(0)

kakutani
kakutani commented 27 days

暗黙知が特定個人に蓄積し続ける状況を組織的個人的に対処していく取り組みのなかで、「いまいちだったなあ」とか「うまくいかなかったなあ」といったようなことがあれば教えてほしいです。

Like(1)

purintai
purintai commented 27 days

自社サービスのベンチャーにおいて特定のエンジニアがバス因子になってしまうのはよく起こりがちだと思います。

もし、エンジニアに依存する他チームがなかなか自立してくれない、しかしそのチームがワークしないことには事業として危ぶまれるといった場合にはどのようなアプローチを取ることが望ましいと思いますか?

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