はじめに
こんにちは。進捗ゼミです。今回は、エンジニア組織での権限移譲について考察しようと思います。具体的には、次のようなものです。
- 任意参加の技術系コミュニティを運営している人・グループがいて、そのコミュニティを後世に残したい。そのため、より若い世代に権限を委譲して、若い世代を中心とした活動をしてほしいと思っている
大学のサークル活動のようなものを想定していますが、社会人サークルやその場のノリで集まったゲーム制作サークルなどでも似たようなものだと思います。ちなみに、タイトルで斬る！ と書きましたが、とくに何も攻撃せず、原因と対策を淡々と考察する記事となります。
用語
- 責任者：現時点の技術系コミュニティで主導権を握っている人・グループ
- 次世代：翌年の技術系コミュニティで主導権を握ってほしい人・グループ
- 権限移譲：コミュニティの実質的な運営者を責任者から次世代に移行すること
どうして技術系コミュニティはワンマン化して次世代への継承が難しくなりがちなのか
まず、問題意識として、技術系のコミュニティは、スポーツや音楽などのその他のコミュニティに比べて、責任者に権限や活動のコアが集中（ワンマン化）しやすいと考えています。このワンマン化がコミュニティの継承を難しくしていると思います。ここでは、その原因をより深く考えてみましょう。
本質的に個人技
技術を極めるのであれば、最終的に個人で本を読むなりコードを読むなりしないといけません。したがって、コミュニティとしての活動よりも個人の活動の比重が高くなります。これが仮にサッカーであれば、強い人は必ず何らかのコミュニティに所属することになるので、毎年強い人が継続的に入ってきてくれるのですが、技術系のコミュニティは、技術が好きな人がわざわざ集団に所属するインセンティブが相対的に弱いです。
参入障壁が高い
基本的に専門知識であり、その他の趣味に比べて実際の難易度、精神的な難易度ともに高いです。そのため、すでに出来上がっているコミュニティに飛び込むハードルと技術を学ぶハードルの両方を乗り越えた人しか新規に参加してくれません。
技術力と発言力がリンクしやすい
特定のソフトをみんなで作るようなサークルであれば、発言力はかなり技術力によって左右されます。これにより、話を回すのが得意な人間に発言力が与えられにくいです。
したがって、技術力があってかつ話を回すのが得意な人間じゃないと受け継ぎにくいが、そんなスーパーマンはそこまでいません。
これが集団で行う合奏とかだと、中心に立つ人は必然的にコミュニケーションもうまくならざるをえませんが、技術系のコミュニティでは他人としゃべらずに黙々とのめりこんでる人間が暗黙に発言力を持ってしまうこともあり得ます。これはコミュニティにとっても本人にとっても不幸なことです。
結果、スーパーマンがいる世代だけのコミュニティとなって、スーパーマンが抜けるとコミュニティごと消滅する可能性が高いです。
年齢制限が本質的にない
スポーツにおける大会、音楽系における本番、文化系における発表会といったイベントは、特定の年齢の世代に対して特定のイベントに参加することを強制します。このようなイベントがあれば、次世代は強制的に当事者になって、責任者も強制的に権限移譲が発生するためそのために死に物狂いで努力します。
しかし、技術系であれば参加の年齢制限がかなり緩いです。したがって、責任者側が自力でイベントを起こしていかないとなかなか権限を委譲しきるところまでいきません。
そして、だらだらと権限の委譲をサボっている間に若い世代との年齢差が広がっていきスムーズなコミュニケーションが難しくなります。
どのタイミングで権限移譲が失敗するのか？
ひとくちに権限以上の失敗といっても、失敗するパターンはたくさんあります。ここでは、失敗の原因を三段階に分けて考えてみます。この記事では、主に2番と3番の問題にアプローチします。
1. そもそも運営したい人、組織が好きな人がいない
一番根本的な失敗です。組織運営はエンジニア組織に限らず、組織が好きである人が割に合わない仕事をしないと回らないようになっています。特に技術系コミュニティなら、好きな人と技術を触ることはコミュニティ運営と本質的に無関係です。
コミュニティ参加者が居心地よく参加できているか、楽しく開発できているかを注視してください。
2. 前任者が権限を手放せない
そもそも責任者が生涯現役を目指しているような場合、コミュニティの権限移譲は発生しません。
しかし、責任者が後継者を真剣に求めていて、後継者になりたい次世代がいても、実質的に権限を手放してないようになる場合があります。
それは、責任者が次世代の見える場所でずっと監視していたり、善意で次世代の政策に色々口出しするような場合です。現場で口を出さずに見守られているだけでもまあまあ息苦しいです。勉強中の高校3年生の後ろに母親がずっと立っているぐらいには。この問題は、本質的にはコミュニケーション不足に起因しています。そのため、責任者と次世代の仲が良くないほどに深刻になります。次世代の人間とはあらかじめ仲良くなってください。
3. 権限だけ渡されてもやり方が分からない
前任者がスーパーマンだった場合、属人性が死ぬほど高い運営をしている場合があります。
事前にドキュメントにしたうえで運営を手助けしないとなかなかうまくいきません。ただし、運営を手助けするつもりで前項のパターンに陥り、実質的に運営をしてしまう場合があります。
そのため、少しずつやり方を学んでいけるようにする工夫する必要があります。
運営における基本的な役割
権限移譲の話をする前に、フラットかつ指揮系統が曖昧な技術系コミュニティに発生しがちな役割とその特性について説明します。
エンジニア組織は本質的に個人で頑張ることになるので、比較的役割分担があいまいになりがちです。そのため、組織論の本に書かれているような形式的かつ重厚なものよりも、ある程度のゆるさでざっくりとした役割を捉えておいた方がうまくいきます。
「組織がうまく回ってない」よりも「○○の役割をこなす人間が不足している」、「権限を手放せない」よりも「○○の役割のやり方を学んでいる次世代がいない」という理解をしておけば、問題の本質をより詳しくとらえられます。
政治家
政治家の役目は次の通りです。
- 具体的な運営方針を決める
- やりたい運営方針に対して、責任を持ち、正当性を説明する
コミュニティ運営のもっとも基礎となる役割であり、運営の原動力です。この役割をこなすには、そもそもコミュニティが好きであることと、自分から動く主体性が必要です。政治家の説明が、コミュニティの運営上のさまざまな指示の正当性の源です。そのため、政治家はコミュニティの中心となることが必要です。
官僚
官僚の役目は次の通りです。
- 政治家の決めた方針に基づいて、具体的な実現方法を企画する
- 適切な人間を割り当てて、適切な仕事量にまとめて、実現する
- 政治家に話を聞きながら、政治家がやりたいことを実現する
官僚は、基本的にあまり意思を持たず、裏方で動き、独自の決定をするときは政治家の意向に沿うかを確認します。なぜやりたいかは政治家に任せて、政治家が決めきれてない部分を詰めて、実現可能性があるようなタスクにまで分割する、何をやるかを担当します。官僚は、常にいろいろな人間と仲良くして気軽に仕事を振れるようになっておく人間関係と、具体的な日程や作業量、コストを管理する実務能力が必要です。
現場責任者
現場責任者の役目は次の通りです。
- 個別の案件について、やってみないと分からないことに対処する
- 必要に応じた買い出しや人員の追加調達を行い、官僚から与えられた目標に対して最終的な帳尻を合わせる
- 個別の案件について、労働者をとりまとめる
官僚がいくら机上で頑張って調整をしたところで、実際のイベント（なにか物を作ったり、どこかへ行ったり、なにかを発表したり…）には、やってみて初めてわかるような注意点がたくさんあります。これらの疑問点、注意点、問題に対して、それをいちいち現場にいない政治家・官僚に聞くのはあまりに非効率です。そのため、官僚から任せられた範囲で単独のイベントや単独の仕事に対して責任をもって、目標までの帳尻を合わせる役割が必要です。現場責任者は、実際にやってみて確めるフットワークの軽さと、最後まで成し遂げる責任感が必要です。
労働者
労働者の役目は次の通りです。
- 作業を行う
- イベントに参加する
労働者という言葉は若干誤解を招いてしまいますが、技術系コミュニティは仕事ではないため、基本的には開催しているイベントに参加してコミュニティに参加してくれる人、という位置づけの役割です。
どんなコミュニティでもそうですが、人手はすこし多すぎるほうがわいわい盛り上がれて活気があります。「ちょっと手伝うぐらいならいいよ」程度の参加者でもこの役割は熟すことが出来るので、労働者は質より量が重要です。
失敗パターン
政治家が現場に出る
政治家は、過剰に現場に出ないでください。技術コミュニティに限らず、ワンマン化が進んでしまうと、政治家が労働者になってしまいます。しかしこうなると、組織がまったくスケールしません。なぜなら、上から下まで全部政治家がやると官僚も現場責任者も不要なので、密室での政治になりやすいからです。密室での政治だと政治家の頭の中だけで暗黙的にしか政治が行われないので、次世代が政治に参加しようがありません。そのため、意図的に他の人に仕事を説明する機会を作ることで、意図的に正当性を説明して、意図的に誰かからの承認を得る場所を作って、一定程度納得してもらって仕事を投げてください。仕事を投げるときには「私がやりたいから」だと他の人にはやってもらえません。そのため、政治家の側もそれなりに説得力のある理屈を考えるので、結果として運営自体もよりよいものになります。
政治家が不在
コミュニティのみんなが「何かしないとまずいよね」とだけ思っていても、「動いていい？」「やっていい？」「責任まではとれない…」「何したらいいんだろう」と考えて何も進んでいない状態です。
- 根本的に政治家志望者がいない場合：かなりどうしようもない
- 政治家志望は存在して、自分が政治家になっていいのか悩んでいる場合：責任者が次世代に「あなたが政治をやるんだよ」というのを任命する。
- 政治をやろうとしているが、言語化や政策決定で困っている場合：マニュアルやチェックリスト、引継ぎ文書の形式で、現役の政治家が決めるべきフレームワークを提供する。このパターンはいずれ慣れるようなものなので、かなり簡単に問題を解消できる
コミュニティにおける役職というのは、はじめの一歩を踏み出せない政治家のためのものです。技術コミュニティに限らず、趣味の集まりでは、役職をつけたところで、やりたくない仕事をやってくれるわけではありません。なぜならお金が絡まないからです。しかし、自分が主体となって動くことで反感を買わないか不安である人間は、錦の御旗があると心理的な負担が軽減され、積極的に働いてくれるようになります。
責任者が官僚をやらずに引退する
責任者は、次世代のコアメンバーに権限を委譲するにあたって、政治家・官僚のやり方を学んでもらう必要があります。しかし、この二つの役割は非常に難易度が高く、高度な経験が必要です。したがって、「次世代の自由にさせたい」という理想論だけを言って、自由という名の放置すると、次世代はうまく運営できなくなります。
人間関係と発言力を一番持ってるのは責任者です。年齢的にも技術的にもおそらくそうです。したがって、前任者は次世代が政治を進めていくサポートを行う立ち位置で働くべきです。
したがって、運営の権限は政治家→官僚の順序でひとつずつ委譲する必要があります。まず政治家をやってもらって運営のイメージを持ってもらい、それを官僚としてサポートし、次に政治に慣れたら官僚の仕事も投げればよいのです。大学のような1年単位で入れ替わるようなコミュニティでは、3年官僚・2年政治家とか4年官僚・3年生政治家といった分担でもいいと思います。
ここで難しいのが、責任者が次世代の自由に政治をやってもらうことです。官僚として働いていく上では、どうしても昔の癖で自分の意志を通したくなります。また、より良くできる点を見つけることもあります。しかし、そのあたりのことをいちいちレビューしていると、事実上の政治家の権限がなかなか委譲できません。出来るだけ次世代の人の意見を聞いて、次世代の人にお伺いを立てて、実現できるような手段を具体的に提示する、という役割を明確化して「主役は次世代である」というメッセージを伝えることが必要です。
次世代が現場責任者を経験せずにいきなりコアメンバーになる
この問題も、今まですべてをやっていた責任者が急に次世代に権限を委譲しようとしたときに発生しがちです。次世代にも、準備期間や慣れの期間が必要です。さらに、一般メンバーも、次世代の運営側が信頼できる存在であり、安心できる人であるという認識を持ってもらったほうがスムーズに運営できます。
そのためには、いくつかのイベントを現場責任者として引っ張ってもらうのがもっとも簡単です。
次世代の経験的にも、コミュニティ全体への告知の意味でも重要なステップなので、省略しないようにしましょう。
技術に偏りすぎる
ワンマンになりやすい理由の部分でも解説しましたが、技術系コミュニティに特有の問題として、「そこまで人付き合いが得意でない・やりたくないのに、技術だけが得意なせいで、周りがその人に発言するのに気が引けてしまい、不幸にも得意ではない仕事をやらざるをえなくなり、運営に失敗する」というパターンが発生しやすいです。
入った人間が少しずつ技術が好きになってもらって、週に1回AtCoderに参加するだけとか、困ったときに小さなPythonスクリプトを書くだけとか、Unityで5分で終わるミニゲームを作れるとかそういう人間がたくさんいると、コミュニティとしての成熟度合いや多様性が高まります。この成熟を生み出すのは、コミュニティの価値や目的に技術以外のものを明確に含めることが必要です。
技術にのめりこんでいるタイプのメンバーだけだと、まず人間関係を調整して全部を潤滑に動かす官僚がいなくなります。また、参加のハードルが上がって徐々に労働者がいなくなります。結果、官僚がいないので現場責任者の任命もうまくいかなくなり、政治家が労働するパターンになります。
責任者が現場監督の指揮下で労働をやる
前提として、次世代から見ると責任者は権威があるように見えます。
そのため、偉い人の視界の範囲で仕事をしていると、どうしてもお伺いを立ててしまいます。また、責任者の側も善意でそれにこたえてしまいます。これを繰り返してしまうと、自分でうまくいかない部分の帳尻を合わせて指揮を執って運営する経験が積めません。
責任者がなんらかの労働をする場合、お金だけ出すとか荷物の運搬に車だけ出すとか少なくとも次世代が見えないところで働いてください。
労働者の不在（ライト層の不在）
「本質的に個人技」「参入障壁が高い」でも説明しましたが、軽い気持ちで入ってきて軽く活動する人というのが技術組織ではかなり生まれにくいです。
しかし、労働者が不足している組織では、裾野が広がらず、新規の参加者が減少します。
技術系コミュニティでは、意識が高い人間が、あんまり技術をせずにダラダラしてるメンバーに敵対的な気持ちになってしまうようなことがあります。特にコミュニティが一丸となって何かを作っているようなものであれば、非常におこりやすいことです。しかし、ダラダラして楽しくしゃべっているメンバーは非常に重要な資源であることを認識してほしいです。
このようなライト層が十分居心地の良さを感じられる環境であれば、興味を持ったライト層がよりコアな層になるのはそれなりに自然です。
少数精鋭で一部の志がある強い人間を育てようという発想はよくありません。
おわりに
今回は、エンジニア組織でトライしていること、というお題で記事を書きました。
私自身、大学生のB4ということで、そろそろ大学でのコミュニティ内の立ち位置は考えていかないといけないな、と考えていました。
この記事では、汎用的に役立つ運営体制の円滑な引継ぎのコツを書きました。
記事に書いたアンチパターンを避けるように振舞えるようにしたいと思っています。