開発チーム間の情報を遠回りさせてる - Mitsuyuki.Shiiba

いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。 のだけど僕からは 「この部分はディレクター（社内でスクラムマスター的なロール）さんから、あのチームのディレクターさんに共有してもらってもいいですか？」 って自分のチームのディレクターにお願いしたり 「この部分はプロダクトマネージャ（社内のプロダクトオーナー的なロール）さんから、他のチームに確認してもらってもいいですか？」 ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。 そんなお願いをすると、一瞬（え？エンジニアどうしで話して認識合ってるのに？）って反応をされるし、僕自身も（大企業っぽいかなぁ？）って思ったりするのだけど、自分の気持ちを説明すると「たしかにそうね。おっけー！やっ

[manimoto]

関係者間で合意が取れてるならいいと思うが、ブログ主が独自でやってるだけなら開発体制として合意取って明文化したほうがいいと思う。各々が「俺の考える最強のコミュニケーションパス」をやるとカオスになる。

[versatile]

エンジニア同士で話してもらった方が、みたいな会話があるが、その逆か。書いてることは解る、速度が遅くなることを享受して得られるメリット。反論できるだけのロジックが自分にないので現状これが良いってことかな

[Eiichiro]

シンプルなのは、チケット上げて明文化したうえで、上司には口頭共有かなぁ。 確かに口頭じゃないと記憶しづらいし、事後共有だと、報告することを忘れがちになるので、事前に正式ルートで承認はありかも。

[fog-og-frog2]

リバースプロキシを経由してAuditログを残すのを人力でやってるようなもんやな。

[uzuki05]

“チームを外から見たときに、プロダクトのことはプロダクトマネージャに聞けば何でも答えてくれて、組織やスケジュールのことはディレクターが、システムの詳細はエンジニアが答えられる”

[ghostbass]

BTSやらなにやら使っても実務担当以外は見ない、読まない。なのでそいつらが「そんなの聞いてない」を言い出さないために遠回りというか「君らこれ見たよね？」って出来るようにするのは良い。

[eichisanden]

情報伝達のルートって常に最短なのが良い訳じゃなくて意図的に通したいルートを通すのが良いよな。メールでCCに沢山入れるのは違う。

[onesplat]

いい話じゃん

[clockwork9]

情報をオープンで一元化されたソースにまとめる運用は、プロダクトマネージャーやディレクターがPRやissueを読んで実装担当のエンジニアと同じ見解になるチームでないと辛いと思う。前提知識云々よりも政治の問題。

[mrnns]

情報共有とコミュニケーションの改善に興味がないマネージャーもいるんだよな。とにかく丸投げみたいな。その人は実務担当者が抜けるたびに途方に暮れているのだが、指摘するとムキになるので放置している。

[door-s-dev]

仕組みとしては良さそうに見えるけど、プロダクトマネージャーにお伺い立ててる間動けなくて手が止まるとかなりそうだな〜

[xxxxxxxxlarge]

普通にPMを絡ませるのは大事やろ。

[dev0000_1]

依頼は上長に話してもらっていいですか、ってやつに近い。

[diveintounlimit]

明文化して情報をオープンにしなさいよ

[uxoru]

異なる組織と開発する際にどこの会社でも通じるコミュニケーション方法を取るのは良いことだと思う。チーム間のエンジニアどうしの距離が近くても、チーム間の上司や営業どうしの距離が遠かったら、困る。費用関連が

[nakag0711]

本来はドキュメントがあるべきなんだろうけど…これだとマネージャが転職したら…

[cpw]

結局最終的にコード外で仕様を残す文化なら積極的にエンジニア外を巻き込んだ方が良さそう。コードが仕様の文化ならエンジニア間で決められるものなら早い方で良いと思う。結局コード見ないと分からないんだよねー。

[for-my-internet-demo]

似たような理由でDMしない

[sgo2]

チャットなどを使うのも手だけど、傍から見てるだけだと内容の理解度が下がるのが難点。

[toaruR]

そのためのドキュメント

[sonots]

うむ