より良い「民主型」なリーダーを目指して

私は新卒後からずっとIT企業でエンジニアとしてのキャリアを重ねてきており、20代半ばのかなり早いタイミングから何かしらのリーダー的立ち位置で働いてきている人間です。
数名しかいないスタートアップから「テックジャイアント」と言われる巨大IT企業、そしてIT企業・非ITのユーザー企業含め、縦軸(大きさ)も横軸(業種)も異なる様々な企業の中で働いてきました。

技術的な記事の執筆や体外発表はこなしてきたのですが、自分はどんなリーダーで、何を目指して働いているのか、ということについて人生の中で一度も振り返る記事を書いたことがなかったので、ここではそういう記事を書きたいと思います。

10種類のリーダーシップ

まず、リーダーにも種類があります。同じ「WBCの代表だ」と言っても大谷翔平と周東では選手のタイプが異なりすぎて比較にならないのと同じように、一種類の「リーダー」という仕事が有るわけではなく、能力も様々ですし、目的も手段も千差万別です。

この辺は色々なリーダーシップ論が数多存在すると思いますが、ネットで見つけやすいものとして Indeed がまとめている「10種類のリーダーシップスタイルと自分なりのスタイルを確立する方法」という記事を参考にします。

https://jp.indeed.com/career-advice/career-development/10-common-leadership-styles

Indeed のサイトから引用

個々の特徴については元記事を見ていただくとして、私をこの10種類のうちどれに当てはまるかを選ぶとすると、「民主型」のリーダーとなります。

特徴についてサイトから引用すると以下。

参加型とも呼ばれる民主型リーダーシップは、専制型と放任型を組み合わせたスタイルです。民主型のリーダーは意見を求め、決定を下す前にチームからのフィードバックを考慮します。チームメンバーは自分たちの声が届き、重要な貢献をしていると感じられるので、民主型リーダーシップスタイルは従業員のエンゲージメントと満足度の高い職場を育むことができます。
この種類のリーダーシップは議論と参加を促すので、テクノロジー業界などの創造性とイノベーションに焦点を当てた組織に有効です。

つまり、一人で物事をなんでも決めるのではなく、皆の意見を聞きながら合議制で物事を進めていくタイプ、ということになります。

これは種類の話で、優劣の話ではなく、それぞれに良いところ悪いところ、もしくは人による適正もあると思います。私は「民主型」のリーダー、という位置づけが一番しっくりくるので、以降の文章ではその前提で話を進めます。

良い「民主型」なリーダーになるためには

あくまで分類の参考ということで、ここから先は Indeed の記事の内容と多少離れて行くと思いますが、自分がリーダーシップを取る際に重視していることをいくつか書いていきます。
テーマは「場作り」
リーダーの仕事は、この「場作り」こそが全て、といっても過言では無いと思っています。以下は一例を。

コミュニケーションの場作り

チーム内でどのようなコミュニケーションを行うか、制度づくりには気を使います。それは朝会や各種定例などのミーティングもそうですし、Slack 上でのコミュニケーション、PullRequest の扱い方、アラートの対応方針など様々です。
私は独断専行で決める事をリーダーとして行わないので、「意思決定」を皆で民主的に行う場を整理することが大事だと考えています。

皆で物事を決めようとする場合、何が課題になると思いますか?

色々ありますが、一つは「情報の非対称性の解消」
一般的に、リーダーやマネージャーなどレポートライン的に上の職種の方が様々な情報に触れる事が多くなります。その一方、一般の技術者は触れられる情報が限定的になりがちです。意思決定を自信を持って行うためには、判断材料として十分な情報、エビデンスが必要です。これは会議に限らず、作ろうとするシステム・既存のシステムについても同様の側面があります。

チーム内で情報の流通があまりに非対称性になっていると、技術者は判断ができず、結局多くの情報を知っている人(リーダー)が全部決めてしまう、という事になりがちです。
それを解消するためには、基本的な話ですが以下のような事が必要です。

・ミーティングなどの議事録、決定事項を必ず記録する
・作ろうとしているシステムについても設計書やDesignDocを必ず作成する
・上記の内容をチーム内の定例や、Slackなどで逐次共有する
・内容について議論・フィードバックをする事ができる場・時間を用意する
・既存の情報、ナレッジのシェアは積極的に奨励し、時間を割く

あとは「皆が公平に発言できる場の構築」
良く見かける話として、「Slack のパブリックチャネルでいつでも質問してください」と、誰でも発言・ディスカッションをできることをアピールする人や組織がいたりします。
しかし、実際問題、そういう Slack Room は参加者が数百人いたとしても実際発言しているのは数名、みたいなことが多く、民主的な環境でない事が多いです。見た目活発に見えても、オーディエンスの大半は静観、無関心という状態です。

少ない人数で決めた方が速い、というのも真だとは思いますが、多くの人が議論から疎外された環境だといわゆる「エンゲージメント」の構築が円滑に行えない事が多く、結果的に組織の課題解決にコミットしづらい環境が生まれます。なので、たとえば会議では以下のような工夫をします。

・必ず個々人の話すパートを作る
・司会進行を周り持ちにする
・一方的に話すだけでなく、質疑応答や議論をする場を必ず設ける

上記のような形で、皆が円滑にコミュニケーションでき、議論に参加できる場所を作る、ということが、私の考えるリーダーシップの中でも大事なポイントになります。

意思決定の場作り

リーダーというのは最終的に「意思決定」に責任を持つ必要があり、チームは最終的には組織の「課題解決」に責任を持つと考えています。
(課題:売上を増やす、戦略的機能を開発する、システムを安定させる、等)

リーダーは決めた事に対しては結果責任が常につきまといますが、だからといって自分でなんでも一人で決めることは私はしません。その理由は後述しますが、皆で議論をしながら決めていくために気をつけていることをいくつか書きます。

一つは、「課題を先送りにしないこと」
合議制で物事を決めていく、と聞くと、多くの人は「物事が決めきれなくて意思決定に時間がかかりそう」と思うと思います。たしかに工夫をしなければついダラダラと先延ばしになり、時間だけが過ぎていきます。

なので、課題に向き合った際は、その扱いについて必ずその場でスタンスを明確にし、どのような意思決定をするか、次にどのようなアクションを取るかを明確にすることを心がけています。
たとえばミーティングの場だと、以下については必ず明確にするようにしています。

・議題
 ・議論すべき話題/すべきでない話題のスコープ
 ・この場で決めたいこと
・決定事項
・Next Action

15分だろうが、30分〜1時間だろうが、必ずこのプロセスを経て、最終的に次に誰が何をいつまでにやるか、まで決めきります。時間を有効に使うためには事前準備も重要です。(事前にアジェンダを整理し、共有をしておく。ミーティング前に決められる事は先に決めておく)
こんな事当たり前だとお思いの方も多いと思いますが、個人的な印象では、できるリーダーは半分もいない印象です。

また、「皆の意見を否定しないが、質は下げない」のも大事だと思います。
皆の参加意識を高めるためにも、意見を出してくれた人には最大限の賛辞を送るべきですし、前向きな意見は積極的に登用すべきです。
しかし現実的に課題になるのは「質の低い意見」「有害な意見」の扱いです。
自分が楽したい、責任を回避したい・他人に押し付けたいというワガママや、意見の形を借りた他人への一方的な悪口、などを指しています。

まず、発言が他者をリスペクトしておらず、明確な悪意がある場合は、強い口調で否定・非難をします。ここはリーダーの強権を発動すべき場所と思います。
以前「ブリリアントジャーク」について記事を書いたことがありますが、こういう存在を許容せず、治安維持のために全力をかける事が大事だと思います。

悪意はないが、意見が稚拙で深掘りできてないケースもあります。こちらについては以下の観点で深く掘り下げ、論点が曖昧な場合は再考を促すか、意見を取り下げます。

・何が課題だと思うか
・それを解決するためには何が必要か
・それが実現できるメリット/実現できなかった時のデメリットは何か
・実現するためにどのような準備、工数が必要か
・上記が曖昧な場合、クリアにするためにどのようなアクションが必要か
等々

結局、みんなで意思決定をしていくためには、皆の意見を尊重することも当然大事だが、甘やかしすぎてはいけないし、質を保つための努力をリーダーが勇気を持ってしないといけない、ということだと思います。

なぜ「民主型」のリーダーを目指しているのか

文章の順序として逆だと思いますが、なぜ私が「民主型」のリーダーを志向しているかをここから書いていきます。

私は若い頃は、どちらかというと「専制型」のリーダーだったと思います。自分や少数のメンバーで大事な事を1から10まで決定し、厳格なルールを設けてチームの規律を保つ、というスタイル。仕事も他人に任せるというよりは自分が強いこだわりを以て色々なところで手を動かし、口を出していく感じでした。
このやり方でうまくいくケースもあるのですが、うまくいかないケースも出てきます。

スケーラビリティが低い

一番最初にぶつかるのは、仕事のスケーラビリティです。自分でなんでもかんでもやっていくと、自分のこなせる仕事量の限界がチームの仕事量の限界になってしまい、一定のレベルまでは良いですが組織が大きくなると成長へのボトルネックとなってしまいます。

単純に仕事がスタックするだけでなく、メンバーへ適切にタスクを割り振る事が難しくなり、メンバーのアイドル時間が増えがちです。メンバーと自分の労働時間やタスク量の格差にイライラしたり、もしくは謎の優越感を感じ、強権的な発言も増えがちになります。メンバーの適切な教育な機会を奪う事にもなってしまいます。
そして、忙しすぎると、適切な意思決定がどうしても行えなくなるので、総合的な意味で仕事のパフォーマンスも低下していきます。

ちなみに、そういうような経験もあって、個人的な座右の銘としては「リーダーは忙しくなってはいけない」という言葉を胸に刻んでいます。

仕事の手離れが悪くなる

自分でないと意思決定できない事、自分でないと解決できない事が多いと、いざ新しいことをやりたいと思った時に自由に行動が取りづらくなります。
ノウハウが一人に集約しすぎていると他人に引き継ぐコストが非常に高くなり、引き継ぎに時間がかかったり、そもそも引き継ぎができなかったり、という状態に追い込まれます。

これは組織に加入した直後なら比較的問題にならないのですが、同じ組織に長くいると地層のように積み重なっていく類のものです。そして気づいた時には身動きが取れない状況になりがちです。

自分が成長できない

諸々なんでも自分でやることで、自分が経験できる事を最大化することができる、という可能性もありますが、現実としては難しいと感じています。
技術の進化は速く、ITの領域や適用分野も無限に広がっており、全領域を一人の力でキャッチアップすることは現実的ではありません。

なんでも自分一人で行おうとすると、限界点を自分に設定してしまう事に等しく、結果として仕事の質や成果にも限界があり、学べる情報も限定的になります。学びが少ないと、中長期的に成長する機会も少ないということで、結果的に自分が成長できないスパイラルに陥ります。

メンバーも成長できない

そもそも、リーダーというのはあくまで組織の中で便宜上設定している役割で、技術者の能力の優劣を表現するものではありません。そして技術の得意分野もメンバーによってまだら模様なことが多く、◯◯という分野ではAさんが得意、XXではBさんの方が詳しい、この件については彼らにリーダーシップを任せた方がずっと良い成果が生まれる、ということも現場の中では珍しくないです。そういう Partial な権限移譲をチーム内で怠ると結果的に組織のパフォーマンスが落ちます。

たとえ万が一、自分がチームの中で絶対的に能力が高い、という状況だとしても、「メンバーに任せてみる」というプロセスを継続的に積んでいく工夫をしないと、エンジニアやリーダーとして成長する機会の芽を奪う事にもなります。
メンバーが成長しないと、中長期的にリーダーのなり手が増えず、結果的に組織や自分の首を締めることにもなります。


上記のような事態に何度も遭遇した結果、自分としては今の「民主型」のスタイルにシフトチェンジをしてきました。

一番主眼に置いているのは「スケーラビリティ」です。
専制型なリーダーは「モノリスなシステム」だと例える事もできます。それで良い時期もありますが、組織拡大につれて分散型のスケール可能なシステムにマイグレーションしていかないといけない、というのは自明のことです。

先にあげたような「場作り」は、とても手間と時間のかかる作業ですし、皆で決めるという作業についても一人で決めるよりコストの高い作業に見えます。しかし、成長機会をメンバーに多く与えるスタイルですし、マネジメントを「型化」をすることでより多くの人が再現可能なメソッド・プラクティスを組織に提供することができます。

マイクロサービスはコンポーネント間のネットワークレイテンシの遅延を生み出したり、デプロイメントやバージョニング、スロットリング、監視・オブザーバビリティなどシステムで考慮しないといけない事項が爆発的に増えるが、それでも採用する企業が多い、採用しなければいけない現場が多い。
アーキテクチャをメタファーにすると、リーダーシップについても似たような状況がある、と個人的には思っています。

「民主型」リーダーの弱点

以上のような話を、先日、他社の CTO の人に話した事がありました。
理解はしていただきつつも「こういう問題があるよね?」と即座に指摘をいただきました。非常に的確な指摘だと思うので、以下に記載します。

どうしても意思決定にコストがかかる

これは上段の文章でも書いていますが、どうしても場作りや情報共有のコスト、そして皆で意思決定するための合意プロセスのコスト、がかかってきてしまい、時間がかかるスタイルです。

プロセスを洗練させ、できる限り短時間で決めきり行動にまでつなげる。そのための努力は惜しまない、というモチベーションと勇気をリーダーが持っていないと、結果的にパフォーマンスが低い状態に陥りがちなことは、常に留意していないといけないと思います。

悪意のある人への耐性が弱い

皆で決めていく、というプロセスは、メンバーの良心、善良さに依拠したプロセスとも言えます。
メンバー皆が「善良な市民」であれば非常にワークする仕組みですが、明確に悪意をもったメンバーが中に含まれてしまうと、システムが瓦解します。

・チームの決定事項に従わない
・自分の提案が却下されると不平不満を言い、取り入れられるまで抵抗する
・アサインしたタスクを放置して、自分の好きなことを行う
・議論の場を乱すような不規則発言や、他人の悪口を繰り返す
・皆で議論・意思決定をする場に、個人的な理由で参加しない
・そもそも仕事をしない

これは頭の痛い問題で、正直有効な解決手段を見いだせていません。
シビアな職場であれば自然淘汰されていくのですが、CTO の縁故で入社したとかそういう特別な待遇の人の場合、甘やかされて保護されてしまうケースもあります。

現状、私が取りうる手段は、そういう行動を取った人間に対しては「人事評価」を低評価にし、自省を促す、という方法です。ただこの方法は当然のことながら会社組織とのすり合わせ、合意の基に行わないと色々支障が出ることもあります。

上記のようなリスクを理解はしながらも、私は基本的にメンバーを性善説で信頼をすることをベースとして今後も働いていきたいと思います。
その上で、もし行動・コンピテンシーが適切でなかったり、仕事の目標設定を大幅に満たせない場合は、組織の最後の手段として「評価」というプロセスがあります。それを心に留めておき、それ以上はあまり深く考えないようにします。
この辺は、似たような話が以下の書籍にも書かれていました。

おわりにかえて

以上、自分の考えるリーダー像について書いてきました。
思った以上に抽象的な内容になり、細かいテクニックやノウハウ等についてあまり文章が割けなかったので、その辺は別の記事で書く機会があれば書きたいと思います。

この記事が気に入ったらサポートをしてみませんか?