マイクロマネジメント組織が「エンジニアリング組織」に生まれ変わるまで

ビジョンは「エンジニアとお客様を笑顔にする」

永江耕治氏：みなさん、こんにちは。エーピーコミュニケーションズの永江と申します。今日は「クライアントワーク企業でもできるエンジニアリング組織のつくり方」と題しましてお話をしたいと思います。

まず、当社の紹介を簡単にさせていただきます。エーピーコミュニケーションズと申しまして、創業は1995年にしています。約四半期世紀にわたって事業を運営しています。そして従業員数は現在376名です。関連会社としましては、一般派遣をしているAPアシストという会社を子会社に持っています。

主な事業領域はITインフラと呼ばれるところを主事業にしています。例えばクラウドに関連する技術、コンテナに関することや、ネットワークなどです。一例でいうと、ファイアウォール、次世代ファイアウォールのようなものです。そして共通的なものでいいますと、今はネットワークの自動化のようなソリューションにも力を入れています。

そして2016年には、アメリカにあるOpenStackを専業としているMirantisという会社が日本に進出するにあたり、当社と一緒にジョイントベンチャーとしてMirantis Japan株式会社をつくりました。今ここの代表取締役社長は当社の非常勤取締役を兼ねております。

当社のビジョン・ミッションですが、このようになっています。ビジョンとしては「エンジニアとお客様を笑顔にする」。そして、そのビジョンを達成するための使命として掲げているものが、「エンジニアを熱狂させる企業になる」です。当社はエンジニアが非常に多い会社ですので、このようなビジョン・ミッションを掲げて会社を運営しています。

そして、私の自己紹介も簡単にさせていただきたいと思います。大学を卒業してからエンジニアを8年間やっていました。最初はプログラマとしてWebサイトの制作をして、のちにWebディレクターという役割をしていました。そのあとネットワークエンジニアとして当社に入社をしてエンジニアとして働いていました。それが最初の8年。

そのあとマネジメント側にいきまして、マネージャーや部長をやり、それから新規部門の執行役員となって、約6年間マネジメントをしていました。

そののちに人材組織開発をメインに、人事担当の執行役員を7年間やっていました。この間に、国内のビジネススクールで人的資源管理を専門的に学べるところがあるのですが、そこで人的資源管理専攻で2年間ほど専門的な勉強をしておりました。

そしてのちにまた事業部門のマネジメントに移りまして、去年からより経営側にいって、取締副社長というポジションに今は就いています。

つまり、エンジニアをやり、マネジメントをやり、組織開発もやり、そして今は経営をしている。このようなキャリアを歩いてきています。このリアルな体験をみなさんに今日はお伝えをしていきたいと思っています。

5つのアジェンダ

アジェンダとしてはこの5つです。「クライアントワーク・エンジニアリング組織とは」「組織が耐えられるストレスを把握する」「フォロワーを増やす」「透明性を高める」「自ら動きはじめる」。この5つの章でみなさんにお伝えをしていきます。

今日お話しする範囲ですが、この赤枠の範囲の中でのお話になります。エンジニアのマネジメントというと非常に大きいテーマになると思うのですが、今日は数十名単位のチームの話ではなく、数百名単位の組織設計・開発、それから経営寄りの視点で見たお話とお考えいただきたいと思います。

では、最初の「クライアントワーク・エンジニアリング組織とは」です。

まずは組織を定義してみます。この図はこのイベントを主催されている広木さんの著書『エンジニアリング組織論への招待』の13ページに描かれている図です。「企業という組織の活動とは」ですが、「不確実性を減らして、具体的な行動に変化させること」ということです。

下に書いてあるのは社長・部長・課長・社員となっていますが、このようにピラミッド構造になっている会社で考えてみます。青いところは仕事の中での不確実な要素です。

社長がすべての具体的な企業活動をすることはできません。とくに規模が大きくなればなるほど、企業の全員の力を活用するためには、誰かに指示して、その誰かもまたほかの人に指示をしてというように、指示の連鎖が必要となってきます。

そのため、上位にいけばいくほど、抽象的で曖昧な状態で指示をすることになります。具体的で細かい指示をしないと動けない組織では、指示をする側にとんでもなく高い知的能力が必要となっていきます。それがないと具体的なところに落としていくことができません。

一方で、抽象的で自由度のある指示でも動ける組織であれば、大きい組織になっていっても、少ない指示で具体的に行動できるということになります。

組織は大きく分けると3つになる

組織を3つに分けると、このようになると考えています。

表の一番左側、マネジメントも自己組織化もされない組織。これは業務指示の話でいうと、ほぼない。そして不確実性の削減でいうと、ほとんどできない組織になります。

真ん中はマイクロマネジメント組織です。これは業務指示が具体的で細かいものになります。不確実性の削減は少ししかできないことになります。

一番右が自己組織化された組織となりまして、業務指示は抽象的で自由度があるものになります。不確実性は大きく削減できる。これが特徴になると思います。

表の一番左と真ん中の組織は不確実性が減らない組織に当たります。これ、先ほどの図で表してみると、社長・部長・課長・社員の青いところ、不確実性ですね、これが減らせないので、組織としての不確実性の削減は少しだけになってしまいます。

こういった形だけではなく、例えば部長の不確実性はけっこう減らせるけど、課長がボトルネックになることもあると思います。

その場合、この途中の不確実性の削減が少しだけになってしまい、組織全体のパフォーマンスは上がらなくなってしまいます。

スライド一番右の自己組織化された組織は、不確実性の削減が多くできるものです。

図にするとこのようなイメージになります。一番右にいったとき、不確実性はかなり減らせるようになります。

つまり、組織の発達段階で考えてみると、一番下がマネジメントも自己組織化もされない組織。そして真ん中がマイクロマネジメント組織。その上位になるのが自己組織化された組織と考えられます。

クライアントワークのよくある実態

タイトルにもつけましたが、クライアントワークはいったい何でしょうか、という定義です。クライアントワークとは、自社でできない仕事を抱えるクライアントから、その分野のプロとして業務を請け負うことです。クライアント、またはその先のエンドユーザーの課題を一緒に解決することです。そして、パートナーとして一緒にチームになっていくことです。そして、クライアントのビジネスを成功に導く仕事です。

形態としてこういうことがあり得ます。お客様先に常駐をして一緒に働く。契約形態は業務委託契約であったり、準委任契約（SES）と呼ばれている契約形態などがあります。

となると、実態としてこういう体制になることが多くあります。図でいうと、この上にある現場A・B・Cはお客様先に常駐をするチームです。そして下側が本社機能となります。

この体制の問題は現場と本社の間で議論・対話がないこと。できるときもありますが、議論・対話しづらいと言えます。こうなると、指示待ちになりやすい傾向にあります。つまり、常駐している社員と本社の間に認知のゆがみが起こりやすくなるわけです。

ですので、このような制約がある場合は、「マイクロマネジメント組織」より上の「自己組織化された組織」に向かっていくのが非常に難しくなると考えられます。

クライアントワーク企業でよくある組織というのは、左側か真ん中が非常に多いのではないでしょうか。

では、エンジニアリング組織とは何でしょうか？　これも定義してみます。エンジニアリングの定義。同じく書籍の『エンジニアリング組織論への招待』の11ページにこのように言語化されています。

これを私なりにもっとシンプルに言うと、エンジニアリングとは、「曖昧さ」を減らし「具体性・明確さ」を増やすこと。

そして、マイクロマネジメント組織と自己組織化された組織も『エンジニアリング組織論への招待』の中で言語化がされています。これもシンプルに言うと先ほどの表になると思います。

スライド一番右、例えば自己組織化された組織の定義で言えば、業務指示は抽象的で自由度があるもの。そして不確実性の削減は大きくできるもの。それがこの組織と言えると思います。

先ほど出てきた「曖昧さ」という言葉と「不確実性」という言葉はほぼ同義と考えています。目指すべきエンジニアリング組織とは、「曖昧さ」を大きく減らし、「具体性・明確さ」を増やせる組織であると。ですので、当社が目指すのはこのエンジニアリング組織、自己組織化された組織です。

APCが目指す「エンジニアリング組織」

マイクロマネジメント組織、自己組織化された組織を当社なりにもう少しブレークダウンしたものがこの表になります。

例えば「概念」でいうと、統制型から自律型へ。自律は非常に重要な概念だと思います。そして、「文化・構造」でいうと、ピラミッド構造から逆ピラミッド構造へ。現場が判断して自ら動く組織です。

「情報蓄積」は、中央に貯めていたところから、必要な人同士がつながっていくかたちに変わっていきます。そして「統制」は、指示命令から、議論・対話型に。

「権限」は、上層部が多く持っているところから、現場に権限移譲されていき、「リーダーシップ」は、権力・公式の権威と呼ばれているものから、サーバント型、非公式の権威へと変わっていきます。

そして「チーム」は、同調性、同質性が求められていたところから、多様性が求められるようになってきます。「責任」は、失敗を罰するところから、失敗を糧に次に活かすところへ変化していきます。

お客様先に常駐する体制の何が問題なのかというと、「統制」の議論・対話型のところが非常に妨げられやすい形態になることです。議論・対話に時間をかけづらい形態が組織の成熟度を上げづらくさせているという側面があるのです。

当社もこのような課題に長年直面してきました。10数年前はこのような状況でした。マイクロマネジメントも自己組織化もされない組織です。会社の方向性って何なんですか？　目標ってあるんですか？　そのような状況だったんです。

ですので、とくにここ5〜6年で、こんなふうに変えてきました。左側の事業戦略をしっかり作れるようになってきました。今持ってきているんですが、こんな冊子ですね。200ページほどになります。3ヶ年の事業戦略を作って、年度の戦略も各部署ごとで作っています。かなり精緻に作れるようになってきました。

この冊子には部の目標まで書いてあるんですが、そこからその部に属する50ほどのチームがそれぞれで年の頭にマネジメント計画書を作り、そこからさらに個人の目標へブレークダウンされていくマネジメントができるようになってきました。

ですので、数年前からこの真ん中ぐらいのところまではいけたような気がしています。ただ、目指すべきところは……もう少し進んだところ、自己組織化された組織を目指しています。

じゃあ、これをどうやって変化させていくのか。この左側のマイクロマネジメント組織からさらに上に上がっていくためには、変化に必要なことがあると思っています。それは組織が耐えられるストレスを把握をすること。そしてフォロワーを増やすこと。それから透明性を高めること。これが必要だと当社では考えています。

組織が耐えられるストレスを把握する

では、その2番目の章「組織が耐えられるストレスを把握する」です。

「不均衡」という言葉があります。辞書で引くと、「つりあいが保たれていないこと。また、そのさま」のことをいいます。

組織にとっての不均衡は何かというと、組織にストレスがかかって不安定になっていること。つまり、これは「組織が揺れている」と表現する人もいますが、このような状況です。

図に表してみるとこのようになります。縦の軸がその不均衡です。ストレスと言い換えたほうがわかりやすいかもしれません。そして、右側に矢印がある横の軸、これが時間になります。そして、点線で囲まれているエリアがありますが、これは組織が耐えられる範囲です。不均衡に耐えられる、ストレスに耐えられる範囲がこのあたりと考えてください。

この青い線が何を示しているかというと、耐えられるストレスが超えてしまったので急激に下げたというような図になります。これは何かを生み出すことを避けたということです。

そうではなくて、こういうことをしたほうがいいと考えています。この赤い線が波打っているところは、組織が耐えられる範囲でストレスをコントロールして、その状態を維持させるのです。そうすると、組織が成長することに挑戦している状態になります。ストレスがかかることにはなりますが、それが成長であり、変化を生み出すことにつながっていきます。

組織の中で不均衡がどういうときに起こるのかというと、「社員にとってハードルが高いことが課されたとき」「社員間の競争を促すような施策が始まったとき」「異動があり他部署の社員が入ってきた」「新しく優秀な社員が採用されて入ってきた」「ライバルが昇格をした」「重要な仕事に誰かが抜擢された」というようなことが起こったりすると、組織の中で不均衡が生じ始めます。

これを不適切に避けると、組織の中で「優秀な人と自分を切り離す」であったり、「会社や権威を批判する」ということがはじまります。

この批判のようなものが始まると、会社の上層部の人たちはその施策をやめたり、優秀な人を入れるのをやめたりし始めます。また異動しようと思っていた社員がそれをやめる、みたいなことが始まるわけです。そうすると一気にストレスが下がりますが、それが先ほどの青い線の状態になるわけです。

組織の中で不均衡が生じる時

これは圧力鍋です。これは組織の今の例えを表すメタファーにもなると思っています。圧力を適切にかけるとおいしい料理ができるものです。圧力がもしかからなかったら、目的としていた料理はできなくなるわけです。一方で、かけ過ぎると壊れてしまいます。

これは組織も同じことだと思います。どれぐらいの圧力に耐えられるかは、組織によって異なってきます。それをきちんと見定めることは非常に難しいことですが、これをやらなくてはなりません。それによってどれぐらいのストレスをかけていいのかを感知して、それに応じた不均衡を起こさなくてはなりません。

実際の当社の事例でいうと、2015年に「プロフェッショナル職」という人事制度を新たに新設しました。役割としては、担当する業務分野において専門能力を発揮し、技術で当社の未来をつくっていく、そんな役割です。自分の技術で、技術にこだわっている人を感動させる、というミッションを持っています。

人事制度全体の職種のマップでいうと、今はこんなふうになっています。一番左、総合職といわれるところが一番人が多いです。これに加えてオレンジ色のところ、プロジェクトマネジメント職、それからプロフェッショナル職。プロフェッショナル職群の中にまたいくつか種類がありますが、このような多様な職位ができるようになってきました。

ですが、この制度が始まる前の2014年はこんな感じでした。一番左の総合職群と呼ばれているところだけだったんです。グレード、等級が上がるということは、出世をするというか、役職に就く、マネージャー・部長になる、そのような1本の道しかなかったのです。

現在では、このようにさまざまな役割があって、エンジニアのキャリアパスとして管理職以外の生きる道ができました。今では20名ほどの社員がこういう職種に就いていて、活躍してくれるようになり、こういった職種になりたいという人や、採用の際にもこの制度があるからと入ってきた人も増えてきました。

しかし、この制度を企画し始めた2014年の頃は、反対意見や反発の声がけっこう多かったんです。なぜかというと、こんなものがあったからです。

プロフェッショナル職の技術評価には、成果発表会（プレゼンテーション）で評価をする項目もありますよ、となっていたんです。

これは先ほどの不均衡の例でいうと、こういうふうになるんです。一番上が該当しました。「社員にとってハードルが高いことが課された」というふうに捉えられたわけです。

となると、こんなことが始まるわけです。当時プレゼンをするようなエンジニアは当社にいなかったので、「あれはほかの優秀な会社の特別なエンジニアだけがやっていることなので」「エンジニアはしゃべるのが好きじゃないんです」と数多く言われました。「やめてください」みたいな話はかなりありました。

だからといってやめるかというとそうではないのですが、組織と個人の状況により不均衡の高まりやすさが異なることがあります。

状況に変化が生まれる

当時はこんな状況でした。「この制度は今までなかった」「そもそも社外の勉強会に参加したことがない人がほとんどだった」「社内でエンジニアによる発表会はなかった」「社外でプレゼンをするエンジニアは社内にはいなかった」。

これらが新しい制度を入れるときに、不均衡が高まりやすくなる要因になるかどうかでいうと、全部高まりやすくなる要因になるんです。不安だし、経験したことないし、見たことないし……となると、高まるんです。

当時、私は人事の責任者だったので、組織がどれだけのストレスに耐えられるのかを確認するために、何人かの社員にヒアリングをしてみました。「こんなこと考えてるんだけど、どういうふうに感じる？」と、30名ほどに1対1で話を聞くと、「それはやだな」という反応が多くありました。ただ、いやだといっても程度があるので、「絶対いやです」なのか「ちょっといやだな」など、いろいろあるわけなんですよね。

そこである程度全体感を把握して、「今の組織が耐えられるストレスってこんな感じかな。ここだとちょっとやや越えるかな」ということを考慮して制度を実行していきます。それは難易度やサポートの手厚さを調整することです。サポートを手厚くすると、実は一部の不均衡を低くすることもできたりします。

当社はこの「8a1」という勉強会を2014年ぐらいから始め、今でも年に2回ほどはやっています。講師は当社のエンジニアがするのですが、社外の人も参加できる勉強会として、これまで30回以上開催してきました。

この勉強会を始めたことでなにが起きたかというと、先ほどの状況に変化が起こりました。「社内でエンジニアによる発表会がある」という状況に変わります。「社外でプレゼンをする、社外の人も来るエンジニアが社内にいる」と変わります。この経験により、組織の不均衡が高まりにくくなるのです。

最初が肝心ですので、初回はこんなふうに盛り上げました。盛り上げて成功体験をしてもらうことはかなり重要な要素です。会場はおしゃれでかっこよくて人が集まりそうなところを借りました。写真の奥のほうにキッチンがあるんです。

こんなことも仕掛けました。料理好きの社員に協力をしてもらったんです。料理が得意な社員が何人かいるので、勉強会が終わったあとに彼らが食事を振る舞いますよと告知したところ、「技術に正直興味なかったけど、これは行ってみようかな」みたいな人がけっこういたんですね。

当時は勉強会をする習慣がなかったので、そこでいきなり勉強会を開催しても集まらない。でもこの仕掛けによってけっこうな人が集まったんです。その結果、この大勢の中でかっこよく発表をするエンジニアが生まれ、それが彼らの成功体験になり、見ている人の中にもその姿をかっこいいなと思ってくれた人が出てきて、エンジニアが技術を発表する会が定着し今でも続いています。

この章をまとめますと、こういうふうになると思っています。まさにこれを狙ったわけです。ストレスを避けるわけではなく、ストレスをかける。ただ、爆発しないようにやってきました。

つまり、組織のレベルを上げるためには不均衡は必要なんです。ただ、組織によって耐えられる範囲は異なってきます。目に見えない組織ストレス耐性を観察をすることが大事なことになってきます。そして、組織の状態に合わせて、心理安全性を確保するための施策を打つことも同時に必要になってきます。