Developers.IO 2019 登壇資料「カルチャービルディング〜世界最強のAWSエンジニア集団の作り方〜」 #cmdevio

Developers.IO 2019

#マネジメント

佐々木大輔

2019.11.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

「Developers.IO 2019」とは、クラスメソッドが運営するブログサイトであるDevelopers.IOの名を冠した、テクノロジーに興味のある方を対象としたイベントです。

私は10/11(金)に開催されたOsakaと10/19(土)に開催されたSapporoで2回登壇させて頂きました。また11/1(金)のTokyoではスケジュールが合わず、代わりににしざわが登壇してくれました(ありがとうございます)

また、本セッションについてはJBUG(Japan Backlog User Group)様からもお声がけ頂き、岡山、大阪、東京の3地域で登壇させて頂きました。以下にイベント開催時のTogetterまとめリンクを貼っておきます。

さて、本記事では私が登壇しお伝えした内容について、まとめます。

「カルチャービルディング〜世界最強のAWSエンジニア集団の作り方〜」

登壇資料

自己紹介

クラスメソッド株式会社取締役 / AWS事業本部本部長の佐々木大輔と申します。

クラスメソッドの現在

さて、まずは本日お伝えしたい内容に関連する、クラスメソッド株式会社の現在についてご説明します。

クラスメソッド株式会社は現在グループ子会社を含めて400人弱のメンバーがおります。また、東京本社を始めとして札幌、大阪、福岡、岡山、上越、沖縄の6地方拠点を設立しています。そして、ベルリン、バンクーバー、インドに海外子会社があります。更に、ふるさと勤務制度を使って在宅勤務しているメンバーもいますし、日常的にリモートワーク制度を活用し、自宅で働くメンバーもいます。

つまり、ロケーションがバラバラの状態で、400人が仕事をしており、日常的に会話をしたり顔を合わせたりすることがない、というのが、クラスメソッドの現在です。

企業におけるカルチャーとは？

さて、昨今企業カルチャーが強い注目を浴びています。企業カルチャーとは「企業で働く人たちが時間をかけて積み重ねてきた、意識的あるいは無意識的に共有されている価値観や行動規範」です。

よく企業理念こそがカルチャーだと誤解されがちですが、実際には企業理念はイコールカルチャーではありません。企業理念は通常、創業者のビジョンやパッションによって制定されますが、実際に打ち出された言葉はファジーで夢見がちなものになりがちです。

しかし、企業理念が不要だとは思いません。企業理念はその会社の方向性を示す重要な旗印であり、企業理念が無くて出来上がった共有意識はただの雰囲気であり、カルチャーとは言えません。企業理念を意識しながら過ごしてきた時間が、結果としてカルチャーになるのであり、言い換えれば企業理念が実体験からブレイクダウンされたものがカルチャーです。

なぜ今、企業カルチャーが重要視されているのか

企業カルチャーが注目され重要視されている背景に、変化のスピードが激しい時代であることが挙げられます。現在はビジネスや技術の革新が一夜にして生まれ、変わり、終わる時代です。例えば20年前はオンプレミスが主流でしたが、10年前にVMware vSphereがリリースされて一気に仮想化が主流になり、そして今ではクラウドファーストが主流となっています。このように様々な変化がどんどんと起きる現在では、古い技術やビジネスに固執してしまうと、それらの衰退に合わせて会社も衰退してしまいます。変化のスピードに追従出来ないと企業は生き残れません。

では、変化に追従するためには何が必要でしょうか？私はこう考えます。まず変化に合わせて自らを変革し続けることが重要です。そして失敗を恐れずに投資をし続ける、つまりリスクを恐れずチャレンジし続けることです。そのためにはビジネスの打席に立ち続ける必要があります。もちろん、それらを実現するためには学習し続けなければいけません。

そして何より重要なのは、そのような変化に合わせた行動を一緒に行える、信頼出来る仲間がいることです。ビジネス戦略に合わせて動く兵隊ではなく、その戦略の先にあるビジョンを実現するために一緒に考え、学習し、チャレンジするための仲間が最も重要です。

さて、著名な経営学者であるピーター・ドラッカーの言葉に「Culture eats strategy for breakfast」というものがあります。ビジネス戦略というのはその時その時で柔軟に変わるものです。しかし、戦略がどうあろうとも、社員が共通の価値観を持っていれば、どのような戦略にも対応出来ます。重要なのは個別のビジネス戦略ではなく、カルチャーこそが企業の成功のための最も重要なファクターであると、この言葉は示しています。

しかし、この企業カルチャーとは簡単に構築されるものなのでしょうか？ここで1つのホワイトペーパーをご紹介します。

2006年にアメリカ合衆国・ボストンのコンサルティング会社であるBain & Companyが公開した「Building a winning culture」です。一部を引用します。

“Bain & Company research found that nearly 70% of business leaders agree: Culture provides the greatest source of competitive advantage. --snip-- Yet, while business leaders recognize culture’s crucial role, our research also indicates that fewer than 10% of companies succeed in building a winning culture.”

“Bain＆Companyの調査では、文化は競争上の優位性の最大の源であると、ビジネスリーダーの約70％が同意しています。 --snip– しかし、ビジネスリーダーは文化の重要な役割を認識していますが、当社の調査では、文化の構築に成功した企業は10%未満であることも示しています。“

ここに記載された通り、多くのビジネスリーダーは、企業カルチャーは重要であると考えています。しかしその企業カルチャーの構築に成功した企業は10%未満です。企業カルチャーの構築は、重要ではあるが、困難な道のりであることが伺えます。

クラスメソッドのカルチャービルディング

さて、ここからは、私が実際にこれまで行ってきた、クラスメソッド株式会社社内でのカルチャービルディングについて、実体験をお伝えします。

まずは私自体のバックグラウンドです。クラスメソッドへの入社以前、私は札幌で知人と中小SIerを起業しました。当時は私を含めて5人しかいない会社だったのですが、その後順調に採用が進み、結果としてピープルマネジメントの必要性が出てきたため、統括マネージャーとして50人のメンバーをマネジメントすることになりました。しかし小さな会社であったため私自体も売上を上げる必要があり、インフラエンジニアとして大手SIerにSESで出向しておりました。そんなマネージャー兼エンジニアで14年勤務していましたが、30代半ばにしてエンジニアとして再チャレンジしたくなり転職を検討。友人の紹介でクラスメソッドに応募しました。

そして2014年1月に、クラスメソッド株式会社AWSコンサルティング部(当時)にソリューションアーキテクトとして入社しました。当時はまだ弊社のAWSビジネスが成功していない時期で、仕事はあれど全く利益が出ず、毎月赤字で、他部門の利益を食いつぶすような状況でした。まだまだ新規事業であったため専任のマネージャーを立てる必要がなく、社長が部長を兼任していました。更に一人親方の集団のように成り立っていましたので、部長(社長)以外全員がフラットの関係性でした。そして個々人が複数のお客様を同時に担当し、営業からコンサルティング、環境構築、運用保守を全部自分でやるような、分業体制の全く無い状況でした。もちろん利益が出ていないので人事考課も無ければ給与改定も無い状況でした。

そして2015年、やっとAWSビジネスが軌道に乗り始め、エンジニアも順調に増え始めた結果、社長も社長業に専念する必要があったため、部長を退任することとなり、代わりに私が部長を務めさせて頂くことになりました。これは前職でマネジメント経験があったこと、また当時クラスメソッド初の地方オフィスである札幌オフィスの立ち上げを成功させたことが大きな理由でした。なお、私自身はエンジニアになりたいと転職したのにまたマネジメントの立場となったため、最初は悶々としていたことを覚えています。

フェーズ1: 最初のステップ

この時点では、組織として全く何もない状態でした。まず企業理念はあれど浸透しておらず、誰も意識して仕事していませんでした。また人事考課の仕組みが無く、それ故に給与の基準もありませんでした。更に採用についても基準がなく、メンバーが良いと思ったか悪いと思ったかを判断するのみで、何を基準として判断しているのか定まっていませんでした。

ここからがカルチャービルディングのファーストステップです。

部の理念を作る

まず私が最初に行ったのは、部の理念を作ったことです。前述した通り、企業理念は会社としてのビジョンを指し示したものであり、現場のビジネスと必ずしもマッチするとは限りません。特に私の部門は企業の情報システムインフラの支援であるため、企業理念で掲げている「創造活動への貢献」がそのまましっくり来るものではありませんでした。

そこで、企業理念をブレイクダウンして、部のビジネスにマッチした理念に落とし込みました。企業理念を改めて認識した上で、リアリティのある理念に言い換えることで、浸透しやすくすることが狙いです。

クラスメソッドの企業理念は「オープンな発想と高い技術力によりすべての人々の創造活動に貢献し続ける」でしたので、これを私の部門のビジネスのレベルにブレイクダウンしました。そこで掲げたのが「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことをまるっとお任せしてもらうことで、顧客のビジネスに貢献する」です。

部のビジネスとしてやっていることを分かりやすく文字化した上で、あくまで顧客に貢献するためのものであるとして、企業理念に相似させました。

行動指針を作る

次に部としての行動指針を定めました。これは企業理念と部の理念を実現するためにメンバーに求められる行動を明文化したものです。

行動指針は多すぎても細かすぎても実現されません。仮に行動指針が100項目あったとすれば、それは即日形骸化するでしょう。行動指針は覚えやすいように、シンプルに、本当に必要な要素だけに削ぎ落とすことが重要です。行動指針は最もシンプルなカルチャーだと僕は考えます。

そこで提示した行動指針はたった2つ、「セルフマネジメント」と「アウトプットファースト」です。

まずセルフマネジメントについて、自由に提案し、オーナーシップとリーダーシップを持って自分で遂行することを求めました。また仕事も生活も勉強も受け身ではなくプロアクティブに行うこと、周りは相談には乗るけど指示はしないので自分で考え自分で実行することを求めました。そして弊社のセルフマネジメントを象徴する言葉に「許可を得るな、謝罪せよ」があります。

上述の通り、元ネタは元ミラクル・リナックスCTOで元楽天株式会社で技術理事だった吉岡弘隆さんのTweetです。背景は上記のブログに書いていますが、元ネタは3Mの創業ストーリーに書いてあったものだそうです。弊社では「アクションするのにいちいち許可を得る必要はない。許可を取る時間が無駄。やっていいですかじゃなくてやりましたと言えばいい。その結果間違っていれば謝れば良いだけ」の意味で使われており、実際弊社内でなにか改善したいことがあれば、気づいた人が自分でタスクフォースと呼ばれるチームを作成し、改善を実施します。改善の実施に許可は一切必要ありません。

もう一つの行動指針がアウトプットファーストです。弊社では「学習エンジンを持つ」ことが全員に求められています。学習エンジンとはつまり自学自習して自分で前に進めることです。また、どんなインプットも必ずアウトプットすることを求めています。他人が見れないインプットは成果とみなすことが出来ません。例えばある技術を勉強したり、セミナーに参加したり、読書したことは、アウトプットが無いと、本当にその知識を身に着けたのかどうか他人から評価出来ません。全てのアクションはアウトプットによって評価されるので、必ずアウトプットするように伝えています。身につけた知見は、業務はもちろん、ブログや、登壇や、記事執筆などでアウトプットしてもらっています。外部に公開出来ないものは社内WikiでもSlackでも構いません。とにかくアウトプットを最優先で考えます。

人事考課の仕組みを作る

次に人事考課です。弊社では元々Job Description(JD) Meetingという仕組みがあったが、当時は全く機能しておらず、たまにあったとしても雑談して終わりという実態でした。そこでJD Meeting Guideという、JD Meetingでやる内容を明記した文章を作成し、メンバーに共有して、そのGuideに従って実施するようにしました。

給与の基準を作る

次に給与の基準を作成しました。弊社では元々給与テーブルとして、スタッフ、エンジニア、スペシャリスト、マネージャー、ディレクターのような職種と、職種ごとのランクが決まっていましたが、職種について明確な基準がありました。そこで職種ごとに求められる能力を明文化し、合わせて職種ごとの給与レンジを決定しました。更に職種ごとの定量的目標を明文化した上で、給与改定方針を作成しメンバーに周知しました。この給与改定基準には昇給するポイントや減給するポイントも記載しました。以下のようなものです。

給与を適正化する

さて、私が部長になった2015年当初、公平な給与の支給がされていませんでした。原因は(中小企業あるあるなのですが)、そもそも採用時点での給与が、ほぼ前職の条件に引きずられて決定していたからです。例えば、地方の人は低かったり、若くても前職が大手SIerだったら高かったり、ということが発生していました。

そこで実際の各メンバーのパフォーマンスと給与レベルをあわせるために、2年かけて適正なバランスまで調整しました。私にとって幸いだったのは、当時から現在に至るまで業績が上がり続けていたため、給与を下げることなく、昇給のみで適正化が可能だったことです。給与とパフォーマンスが一致していない場合でも、その給与のために出すべきパフォーマンスを伝え続けることで、本人のパフォーマンスを上げることになり、結果として給与との乖離を無くすことが出来ました。

採用の基準を作る

既存メンバーのための制度作りを整理した上で、次に必要になったのは採用基準です。弊社の採用プロセスは書類審査、一次面接、二次面接で、弊部の二次面接は志望部署のメンバー全員で行っていましたが、採用基準が無いがゆえに、判断が各々に依存していました。そこで企業理念と行動指針に従った採用基準を制定し、メンバーに周知しました。

採用は企業カルチャーを醸成し維持するための最も重要なフィルターと僕は考えます。採用基準通りに採用すれば、理念や行動指針に従わない人は入ってきません。もしカルチャーが違う人が組織に混ざると癌になり、そこからカルチャーの崩壊が始まります。

また、採用基準の中に認知バイアスを記載し、メンバーみんなに意識してもらうことにしました。認知バイアスはその知識を持っているかどうかで全く判断が代わります。例えば類似性効果は、出身地や出身校が同じだとどうしても親しみをもってしまいがちです。そういったときに「これってバイアスかも？」と思えるような状態にしておくのは、採用においてとても重要です。

私が考える採用の最悪手は、仕事に合わせて人を取ることです。スキルだけ見て、仕事のスキルセットに合わせて採用してしまうのが最も危険だと考えます。例えばJavaの開発案件があるときに、その仕事に合わせてカルチャーに合わないんだけどスキルセットが合うからと採用してしまった場合、その仕事がなくなったとき、その人のカルチャーがズレていると、他の場所で活躍してもらうことが出来ません。採用で最も重要なのはカルチャーフィットであり、スキルセットはその次です。

フェーズ1の完了

さて、ここまでで最低限組織に必要なものが完成が完成しました。企業理念の浸透、人事考課の基準、給与基準、採用基準です。

フェーズ2: 組織拡大

さて、以下は弊社の入社人数のグラフです。2015年くらいまでは月に1〜2名程度の入社だったのですが、2017年からは毎月複数人入社し、2018年には毎月10人入社してくるようになりました。

私が入社した当時40人だった会社が一気に100人を超え、200人を超え、どんどん成長していきました。私自身のピープルマネジメントラインも50人以上になり、一人で全てを見通すのは困難になりました。しかし、それでもカルチャーの維持は重要です。カルチャーが維持されるように、様々な施策にトライしました。

組織構造のリデザイン

まず、コミュニケーションパスを最小限に抑えられるように、組織構造をリデザインし、業務内容によって部を分割しました。更に部門内のチーム作成ルールを定義しました。具体的には頻繁にコミュニケーションを取るチームの人数は5名以下に抑える、5名を超える場合は2チームに分けた上で1つのグループとして扱う、1人のマネージャーの管理範囲は8人以下に抑える、などです。

情報共有のデザイン

組織を分割すると必ず発生するのが、情報の縦割りです。例えば環境構築のチームと運用保守のチームで情報が縦割りになっており、運用保守チームの求める内容で環境構築されていない、などの問題が発生しました。このような問題を防ぐべく、業務を明文化したり、必要な情報をまとめたりしました。情報やノウハウの共有は、業務面だけでなく、組織構造を柔軟に変更したり、人の異動をフレキシブルに行うためにも必要です。それぞれの部門の業務が誰でも参照可能な状態で明文化されていれば、部門間を異動しても業務にすぐ追従することが出来ます。

また、業務や技術だけでなくリーダーやマネジメントのノウハウも可能な限りアウトプットし公開し共有しています。これは個人の知見で留まりがちなそれらのノウハウを共有することで、組織カルチャーがリーダーやマネージャーに依存して縦割りになることを防ぐ意味で重要です。

コミュニケーション設計

次にコミュニケーション設計として、情報共有を行うためのコミュニケーション手段を設計しました。例えば朝会、チーム週報会、全体週報会、全体月報会などです。ここで重要なのはコミュニケーション手段を固定化しないことです。必要な手段は維持するものの、形骸化し不要になったコミュニケーション手段は廃止することで、常に効率的にコミュニケーションが取れるようにします。

ミドルマネジメントの育成

さて、組織構造をリデザインした後、全てを私一人でマネジメントする必要のないよう、ミドルマネジメントの育成を行いました。マネジメント業務に興味がなかったり、そもそも合わないと思われるメンバーをアサインしても意味がないため、マネジメントに興味を持っていたり、素養があると思われるメンバーをピックアップし、声がけして、やってもらうことにしました。ミドルマネジメントのメンバーにはいきなり全部丸投げするのではなく、当面は私がサブとして入って支え、マネージャーとなれるように育成し、1年を目処に完全移譲しました。移譲する際には積極的に権限を移譲し、ミッションを提示、移譲し任せた範囲には口出しをせず、主体的に行動してもらうようにしてもらっています。なお、権限を移譲したとしても、私とミドルマネジメントのメンバーで認識のズレが発生しないよう、カルチャーの意識合わせは常に行い続ける必要があります。そこで4週間単位で私とミドルマネジメントのメンバーで1on1を実施し、意識のすり合わせを行っています。

ミドルマネジメントの育成で重要なことは、マネージャーはただの役割であるという意識付けです。マネージャーはマネジメントという仕事をする人であり、権利ではないし上下関係もありません。僕は普段から弊部のメンバーに対し部下という言い方をしません。下だとは考えていないからです。同じように上司と呼ばれるのも好きではありません。僕は僕の役割を実行しているだけで、上ではないからです。ただの役割なのでやれる人がやれば良いと僕は考えます。だから、マネジメントにチャレンジしてうまくいかなければメンバーに戻れば良いのです。一度マネージャーになった人がうまくいかなくてもマネージャーであり続けたり、マネージャーからメンバーになることを否定的に捉える必要はありません。このためには、普段からマネージャーからメンバーに戻りやすくする雰囲気を作ることが必要です。

キャリアパスの設計

さて、ミドルマネジメントという役割が弊部で生まれたことで、エンジニアにとってのキャリアパスが細分化されることになりました。そこで、3年後や5年後の自分の姿を想像しながら効率的に成長出来るように、エンジニアのキャリアパスを明文化しました。人事考課ではキャリアパスを意識しながら会話を行い、本人の方向性を考えてもらっています。

以下のキャリアパスはとある部署のサンプルです。エンジニアとしてスキルを磨いたのち、マネジメント職に行くのか、スペシャリストとして更にスキルを磨くのか、あるいは新しいチャレンジのために他部署に異動するのか、本人の志向性に合わせて会話します。もちろんマネジメントかつスペシャリストもありえます。

フェーズ3: さらなる組織拡大

組織拡大は終わりません。社員数が300人を突破し、毎月10名がコンスタントに入社、私の部のミドルマネジメントメンバーも10人以上になりました。それでも尚、カルチャーの維持が最重要です。そのために現在様々なアクションを行っています。

360度評価の導入

一つは360度評価の導入です。導入した背景の大きな要素として、マネージャーガチャがあります。どんなに優れた人同士であっても、必ず相性というものが存在します。何となく合わない人、というのはどんな聖人君子でもあるものです。しかしこの際に「何となく合わない」で評価が上がらなかったり下がったりするのは、誰にとっても幸せなことではありません。このように、人事考課がマネージャーガチャにならないように、評価の目を増やすことが、360度評価の導入の目的です。

360度評価のやり方についてはまだ試行錯誤中であるため確定していないのですが、現時点ではランダムに複数の同僚をピックアップして評価してもらっています。また評価項目の大半はカルチャーとしています。これは評価する側もされる側も、改めてカルチャーを意識しながら、カルチャーフィットを同僚の目から評価してもらうためです。

また重要なポイントとして、結果は人事考課に使わず、あくまでマネージャーが参考情報として使っています。これは360度評価の不正を防ぐためです。360度評価はその性質上メンバー同士が故意に点数を上げることが可能であるため、あくまで直接評価に使わないことを明示しています。

人事部の立ち上げ

これまでは各部にて1次面接を実施していたのですが、採用数増加に伴い採用負荷が膨大し、業務に支障が出るようになりました。そこで1次面接を巻き取る部署として、人事部を立ち上げました。人事部メンバーは人事のプロではあるもののエンジニアではないため、人事部が行う1次面接ではカルチャーのみを評価してもらい、2次面接で各部メンバーによって技術を評価するようにしました。

カルチャーの明文化

さて、この施策のために必要になったのがカルチャーの明文化です。これまでは何となく「クラスメソッドらしさ」というものが共有されていて、メンバーみんながそのらしさを意識していました。しかし新しく入社した人事部メンバーがカルチャーによって採用を行うためには、そのカルチャーが明文化されている必要があります。つまり、クラスメソッドらしさという暗黙知を形式知にする必要がありました。

そこで、クラスメソッドのカルチャーをClassmethod Leadership Principleとして明文化し、コーポレートサイトにて公開しました。このカルチャーは社長自身が文章を作り、マネジメントメンバーでレビューし、最後に社員がレビューして、決定しました。元々存在していた行動指針や360度評価の項目として定めていたカルチャーに沿った内容ですし、社員自身でレビューしたものですので、弊社メンバーにとっては違和感のないものになっています。

もう一つ、弊部がなるべき姿、なりたい姿を一つのフレーズとしました。それが以下です。これは私の部門のキーフレーズとし、ステッカーにして、みんなでPCに貼り付けています。ステッカーにすることで全員が意識しやすくすることが狙いです。

カルチャーフィットの確認と是正

カルチャーを明文化したものの、メンバーがカルチャーを体現した行動をしているのか、カルチャーの体現に対してモチベーションがあるのかどうかを確認する必要があります。そこでモチベーションクラウドを導入しました。モチベーションクラウドは社員満足度調査に似ているのですが、重要なのはこのサービスによってメンバーの期待値と満足度を測定して数値化し、それらがカルチャーにフィットしているかを確認できることです。そして、カルチャーにフィットしていない期待値を改善していく必要があります。

一例として弊部の結果を示します。右上が期待値と満足度が高いもの、左下が期待値も満足度も低いもの、左上が期待値が高いのに満足度が低いもの、そして右下が期待値が低いけど満足度が高いものです。マネジメントとして特に気をつけなければいけないものは左上、期待値が高いのに満足度が低いものです。

モチベーションクラウドは、データを取るだけでは意味がありません。データに対して、マネジメントメンバーが課題を取り捨て選択し、アクションプランに起こし、メンバーに共有して、初めて効果が出るものです。必ずアクションに繋げなければいけません。

そして、カルチャーにフィットしていない期待値はコントロールが必要です。例えば弊社の場合、セルフマネジメントをカルチャーとしていますが、マネジメントされないことに不満がある場合、その期待値自体を下げる必要があります。また、自学自習をカルチャーとしているのに教育に期待値が高い場合、その期待値も同様に下げる必要があります。このように、適切な分析とアクションがあって初めて、この施策は成功に繋がります。

カルチャーの浸透で大事なこと

カルチャーの浸透で大事なことは、カルチャーは行動規範であり、人事考課には使わないと名言することです。カルチャーの体現自体を高く評価してはいけません。また、カルチャーを体現していないことをマイナス評価してもいけません。例えば弊社のカルチャーにはリーダーシップというものがありますが、リーダーシップを発揮すること自体は評価の対象ではありません。あくまで、リーダーシップを発揮した結果として発揮されたアウトプットが人事考課の対象です。同様に、カルチャーを体現していなかったとしても、アウトプットが出ているのであれば、それは人事考課の対象です。

あくまで「カルチャーの体現の結果として発揮されたパフォーマンスやアウトプット」に対して人事考課することを、メンバー全員に伝えていく必要があります。

カルチャービルディングの現時点

さて、クラスメソッドのカルチャービルディングの現時点は以下の通りです。

企業理念に基づいたカルチャーを明文化して共有
全てのメンバーがカルチャーを意識
カルチャーに従った人事考課と給与査定
採用ではカルチャーフィットを最重要視
カルチャーフィットを定期的に確認

今後発生するであろう課題

ある程度カルチャーが出来上がったとしても、今後も課題は発生し続けると予測します。

今後も弊社は拡大し続けることが予想されます。現在の400人が1000人になってもカルチャーが薄まらない組織づくりを続けなくてはいけません。カルチャーは経営層が言い続けるだけでも、メンバーが意識するだけでもダメです。経営層もメンバーも、全員が言い続け、意識続け、実行し続けることが、カルチャーの維持に重要です。

次に、組織拡大に伴って組織が増えたとしても、組織ごとにカルチャーが縦割りにならないよう、気をつける必要があります。部門ごとに違うカルチャーになると、部門異動時にカルチャーが合わなくなり、フレキシブルな異動が実現されません。部門ごとにカルチャーがある事自体は問題ではないのですが、最重要なのは部門ではなく会社としてのカルチャーであることを周知し続けます。

そして、組織拡大に伴い、ミドルマネジメントが不足する可能性が高いです。このためにはミドルマネジメント人材の育成を積極的に行うこと、そしてマネジメント業務をポジティブに捉える風土作りが必要です。特にエンジニアはマネジメント業務を忌避する傾向にありますが、マネジメント業務のポジティブな側面やモチベーションとなる要素などを、私たちマネジメントメンバーが伝えていく必要があると考えます。