[宣伝] VISITS Advent Calendar 2019
VISITS Advent Calendar 2019 の7日目です。
1日目 VISITS に取り入れたエンジニア文化
2日目 堅苦しい用語は抜きにしてリレーショナルデータベースの正規形を学ぶ
3日目 本番環境で使えるgRPC-Gateway【前編】
4日目 iOSのUIを構築する仕組みと学ぶステップを考える
5日目 create-react-app Advanced Configuration まとめ 2019年末版
6日目 AWSしか触ったことのないサーバーエンジニアがGCPで本番運用してみた(前編)
この記事について
幻影旅団のチームマネジメントのすばらしさとそれでも鎖野郎に半壊させられた理由を考察する - Note
↑の記事に触発されて、「ちょっとした日常で感じた、よくできた組織やグループについての記事を書いてみたい」と思うようになりました。
良いネタないかなーとボンヤリYoutubeを見ていたら（←オイ）、 人気６人組Youtuberグループである東海オンエアの彼らのある動画を見つけました。
東海オンエアの編集担当、同じシーンに｢同じテロップ｣入れられるはず！
この動画の中で、彼らは、Youtuberの命とも言える編集を全員行えるようにし、リーダーのてつやの編集を真似るようにしているということを発言していました。
毎日投稿しないと視聴者が離れていってしまうYoutuberの世界ですが、トップ層のYoutuberがグループで力を合わせながら個人にかかる編集の負担を減らすことで週５〜６本という高頻度での動画投稿を実現しています。
この記事では、その動画内での会話を引用し、東海オンエアが動画編集をどのように行っているかをみてみます。
続いて、**「なぜ東海オンエアの動画編集が属人化していないのか」を考察しつつ、「開発組織の属人化が止まらない理由」**を考えます。
その後、**「属人化をなくすススメ」**を紹介します。
東海オンエアにおける動画編集
東海オンエアとは？
めちゃくちゃ有名なYoutuberを自分が紹介するというのも変な話ではあるのですが、記事の流れの都合上、簡単に紹介したいと思います。
東海オンエア(チャンネルのリンク。音出るかも)とは、日本トップクラスの登録者数480万人(2019/12現在)を誇る愛知県岡崎市に拠点を置く６人組Youtuberグループです。
では、以下のような説明がされています。
東海オンエア（とうかいオンエア）は、日本の愛知県岡崎市に拠点を置く、6人組YouTuberグループ。メンバーはてつや、しばゆー、りょう、としみつ、ゆめまる、虫眼鏡。2013年にYouTubeより動画投稿を中心とする活動を開始。2017年からUUUMに所属している。YouTubeチャンネルとしてメインの「東海オンエア」、サブの「東海オンエアの控え室」、ならびに各個人メンバーのチャンネルが存在。
メンバー全員が動画編集できる！
2019年5月に投稿された動画である 東海オンエアの編集担当、同じシーンに｢同じテロップ｣入れられるはず！ でのトークを引用してみましょう。
知性担当の虫眼鏡さんがオープニングトークをしている一節です。
「東海オンエアには強みがありまして、なんと６人全員編集ができるんです」
「なので編集に追われることなく撮影もできますし、それぞれプライベートの時間を作ることができるという非常に恵まれた環境で撮影をさせてもらっています」
私はこれまで限られた編集担当が編集をしているのかと思っていましたが、６人全員が編集をすることで、周りの負担を減らしつつ、継続的な動画投稿を実現しているようです。
「元はやっぱ、てつや（リーダー）の編集なんですよ」
「てつやの編集を真似して、僕たちが動画を上げてるんですけども」
この発言からだけでも、リーダーのてつやの編集（特にテロップや効果音）の個性を東海オンエアの個性として、他のメンバーが認めていることがわかります。
リーダーのやり方を真似することで、視聴者には動画編集を誰がしたかをあまり意識する必要がなくなっており、純粋に動画内の企画に集中することができます。
このオープニングトークの後、「だけど、本当に真似できてんの？」→「検証してみよう」 という流れで、「他のメンバーのテロップが、リーダーのてつやのテロップと一致するか？」という動画の企画が始まります。
全員が動画編集することのメリット
動画編集という負担のかかる業務をローテーションで回すことで、週５〜6本という高頻度で長い間動画投稿し続けることができていると考えられます。
もちろん、リーダーのてつやがいなくなってしまうと、東海オンエアの企画が成り立たなくなったり、良さがグッと減ってしまうと思いますので、他のメンバーがてつやの代替をできるというわけではありません。
ただ、編集に関しては、やり方さえ分かっていれば別の人でも代替可能な作業です。
このように、重要だが、別の人でもできる負担が多い作業をローテーションにすることで、特定個人に負担がかかりすぎない仕組みが出来上がっています。
まさに 属人化をしない仕組み ができています。
属人化とは？
急に 属人化 という言葉を持ち出しました。
属人化 - Weblio を引用すると、
属人化・・・企業などにおいて、ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。
エンジニア組織の中にいる人であれば、 属人化 をしている（=属人性がある）状況を見聞きしたことがある人は多いでしょう。
例えば、開発における属人化の例としては次のようなものがあります。
- 製品に不具合があった時に、直せる人が昔から製品を知っている○○さんしかいない
- このオペレーションする必要があるんだけど、手順書がないのでいつもやってる○○さんしかできない
- コードの書き方の癖が強く、意図や意味を聞かないと、他の人がコードの編集できない
このような状況になると、例えばその人しかできない作業を その人がいないとき にやりたい場合、困ってしまいます。
もちろん、作業によっては、「やり方を知っている必要がある人が一人いれば十分」な場合があるかもしれません。
しかし、組織が個人に依存するようになると、個人への負担が大きくなり、ボトルネックになってしまうこともあり得ます。
先ほどの、東海オンエアの動画編集 で例えると、動画編集をてつやしかできず、てつやに負担がかかりっきりな状態 と言えるかと思います。
実際の東海オンエアは、動画編集を誰でもできるようにする 状態を作り、属人化を防いでいます。
属人化を防ぐためにはどうしたらよいだろう？
じゃあ、「開発組織が（望ましくない）属人化を防ぐためにどうしたら良いの？」という話になると思います。
なぜ東海オンエアは属人化していないのだろうか？
タイトルにもある通り、 東海オンエアから学ぶ ために、**「なぜ東海オンエアは属人化していないのか」**を考察してみます。
そもそも東海オンエアは、元々同じ地域出身の仲の良い友達関係から始まっているグループです。
そのような関係だと、動画編集の重要性（＝これがないと動画が出せない）を伝えることも容易にできますし、教える側も教えられる側もお互いのことを熟知しており、教えやすく、教わりやすいやり方で情報伝達ができるはずです。
教えられる側として、友達にわからないことを質問する 心理的安全性の低さ も重要なポイントだと考えられます。
東海オンエアが属人化しない理由を次のようにまとめてみました（私感です）。
- 教えられる側が作業の重要性を理解している
- 教える側が教えることのメリット（＝属人化を防ぐことのメリット）を理解している
- 互いのことをよく知っており、コミュニケーションする上での心理的安全性が非常に高い
- メンバーの数が６人とそれほど多くはない
一方、うまくいかないエンジニア組織や開発チームでは？
東海オンエアのものと逆にしてみましょう。
属人化をうまく解消できない組織は、以下のような問題を抱えていると考えられます。
- 教えられる側が作業の重要性を理解していない
- 教える側が教えることのメリット（＝属人化を防ぐことのメリット）を理解していない
- 他のメンバーのことをよく知らず、コミュニケーションする上での心理的安全性が低い
- メンバーの数が多すぎる
一般的なエンジニア組織や開発チームでは、教育コストがかさみ、特定個人に負担がさらに集中する負のスパイラルが起きる可能性すらあります。
仮に属人性排除のためにドキュメントを作ったとしても、
- なぜその手順をするのかわからない
- 前提知識の書き漏れがあり、結局書いた人に聞きに行く必要がある
など、以前よりも コミュニケーションコストが高くつく場合もあるかもしれません。
属人化を解消するためには
ここまで考察した内容から、属人化を解消するためにすべきことを挙げてみることにします。
あくまで私感ではあるので、組織ごとにやり方は異なる可能性があります。
まずは、作業できる人を少しずつ増やしていく
今まで一人しかできなかった作業を、突然明日から１０人が作業できるできるようにすることはできません。
多くの人に伝えようとすればするほど、色々な人に対応する必要があり、うまくいきません。
汎用的なドキュメントほど人には興味を持たれないものです。
東海オンエアのように、今回の担当はこの人、次回の担当は違う人と作業担当者を回していくと、長続きする可能性は高まります。
作業担当者として実際にやってみないと責任感も湧きません。担当者を決めてあえて役割を回すことで、個人の責任感も増していくはずです。
まずは、作業できるようになる人を二人・三人、・・・のように段階的に増やすようにしましょう。
持ち回りが一周した後、全員が作業の責任感を持っている状態が理想ですね。
属人化を防ぐメリットについて組織でよく話し合う
本当の最初は、属人化を自覚するところから始まると思います。
「この人にしかできない仕事は○○だ」のように、属人化してる作業を洗い出します。
続いて、属人化に課題感を持つメンバーが、「なぜ属人化に問題があるのか」を周りのメンバーに伝えましょう。
全員が最初から同じ課題感を持つことは、とても難しいことです。まずは、問題提起から始め、課題感の共有から始めます。
属人化を防ぐことがゴールではありません。
「属人化を解消すると、チームにとってこんなメリットがある」ということをチームとして理解することが重要です。
本当のゴールを理解していないと、「とりあえず、ドキュメント作ったらいいんでしょ」などと、検討外れなドキュメントが量産され、必要な情報が埋もれてしまう可能性すらあります。
他のメンバーに興味を持ち、コミュニケーションを増やす
一朝一夕の話ではないですが、組織内の心理的安全性を高めることが、属人化解消にも関わってくると考えられます。
属人化を引き起こす要因には、作業をうまく伝えられないことだったり、相手の言ってることが理解できず、お互いコミュニケーションをしなくなるなどがあります。
これにより、知識が特定個人に偏ってしまうという状況になってしまいます。
教える側・教えられる側どちらにも当てはまることです。
個人ができる行動としては、次のようなものがあります。
- 他のメンバーがやっている作業について興味を持ち、聞きに行く(作業そのものを知る)
- その作業は他に誰ができるのかを聞く（属人化してるかを知る）
- 作業者は普段何を思っているのかを他の人に伝える（負担を他の人に知らせる）
ドキュメントや手順書には、「なぜ」を書く
「属人化を防ぐためにドキュメントを書こう」と意気揚々と書き始めたとしても、単なる手順書だと伝わるものも伝わらないです。
手順よりも先に、**「なんでこの手順書が必要なのか」**を文章化して共有しましょう。
この必要性さえ他のメンバーに伝えることができれば、属人化について課題感（その人が作業できなくなったら誰ができる？？）を持ってくれる人が増えるかもしれません。
弊社での施策
せっかく Advent Calendarなので、弊社の属人化解消のために行っている施策について紹介します。
リリース番長制度（リリース担当持ち回り）
VISITS に取り入れたエンジニア文化 でも取り上げられていますが、各リリースについて担当者を決めて、あらかじめ書かれた手順書についてリリース準備・リリース作業を行う リリース番長 制度が導入されています。
詳細な手順書をGitHubのプライベートリポジトリで管理し、それを見ながらであれば、誰でもリリース準備・リリース作業ができるようにしています。
まだまだ不完全なところはありますが、JIRAのダッシュボードなどを作り、一目でリリース準備ができたかどうかがわかるような仕組みにしています。
この施策の目的は、他の開発者がリリース作業に時間を取られず、気持ちよく開発を行える ようにするためのものです。
リリース番長になると、仕事が増え、負担はかかってしまいますが、持ち回りだと思うと気が楽になりますね。
まとめ
長くなってしまいましたが、「東海オンエアから学ぶ開発組織の属人化解消のススメ」、いかがだったでしょうか。
後半は、ほとんど東海オンエアが関係なくなってしまった ことは若干アレではありましたが、書きたいことが書けて楽しかったです。
属人化という問題は多かれ少なかれどの組織にもある話だと思います。
この記事が属人化に悩むどなたかの力になれれば幸いです。
ありがとうございました！