エンジニア組織の責任範囲の透明性をRACI図で高めてみた - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)

こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2018 の22日目の記事です。 前日は@kackytwさんのDQNの学習速度を改善するでした。 Engineering Managerのjob descriptionを共有する流れ 近年、Engineering Manager(EM)業界が賑わってきています。特に2018年は非常に活発化した年でした。書籍としては、エンジニアリング組織論への招待とエンジニアのためのマネジメントキャリアパスという名著が生まれました。また、Engineering Manager Meetupが3回開催され、Slack workspaceでは12/22時点で268人となっています。EMのためのPodcast EM.FMも誕生し、総再生回数が10,000回を突破するなど、多くの方から注目を集めていま

[yunon_phys]

書いた

[dskst9]

なるほど。デリゲーションまで確認したとは、すごいいい情報ができてる。そして形になることで組織によってすごい違うなと改めて感じる。

[tbpg]

"組織構造を考慮せずにjob descriptionを作ることは出来ない"

[tune]

責務の明確化は必要だけど、過度に意識させると領域を超えて動こうとする力を押さえつけてしまう気がする。個人的には役割をどんどん減らした方がいいと思ってるんだけどなぁ。

[hoppie]

フレームワークとして良さそう

[laptice]

CTOとEM, VPoE, LE(TechLead)の違いをRACIで図示したもの、この図で言うとうちはVPoEとEMとちょっとしたLEが全部集約されている。

[oros]

実行責任と説明責任を切り分けて考える方法

[efcl]

responsibilityとaccountabilityの違い、RACI図での役割説明

[braitom]

組織構造をRACI図で表すことにより役割ごとの責任範囲を明確にして透明性を高めるという話。確かにこれがはっきりしていないとjob description作れないよな

[mr_yamada]

早くRACIをうpしろや

[khtno73]

accountの訳は日本語「説明」の数ある意味の中で「根拠の提示」限定。全責任負う決定権者は決定に至った根拠を示せるよう状況把握し記録が残るようガバナンスする。丁寧に説明するってダラダラ時間かけるのは馬鹿。

[ohbarye]

なるほど / “RACIが自分の思っていた以上に組織構造に強く依存していた、ということです。 これはつまり、組織構造を考慮せずにjob descriptionを作ることは出来ない、ということを示唆しています”

[kyuns]

わかりやすい

[Sixeight]

RACIで書く移譲度合い分かりやすい

[tick2tack]

“RACIとはResponsible(実行責任者)、Accountable(説明責任者)、Consult(相談先)、Informed(報告先)”