長沼明子IT系ベンチャー企業の人事が考えるべき戦略人事のポイントご自身の経験から思うエンジニアの特性、IT系サービスを展開するベンチャー企業で起こり得る事など経験知に基づいて、人事部に考えてほしい「戦略人事」のポイントをボードメンバーの湊さんにお伺いしました。エンジニアには2つのタイプがありますQ:エンジニアはどんなキャリアを描いているのでしょうか。エンジニアに求められているスキルや行動はどんなものがあるのでしょうか。エンジニアにはサービスをつくっていきたい志向の人と、技術を極めたい職人肌の人と、大きく2パターンがあると思っています。そのあいだのタイプもいるでしょうが、キャリアパスはやはりこのいずれかですね。サービス志向の人は、どちらかというと企画に口を出したくなりますし、いろいろな経験を積みたいと思っているでしょう。技術を極めたい人は技術的に面白い事ができるところに興味を持ちます。組織運営側から見ると、タイプに応じた適材適所をしないと不満分子が出てしまう。企画やりたい人に技術の安定運用だけを任せるといやになってしまう時期が来るでしょうし、企画をやりたくない人に企画を任せると、自分がやりたいことではないという声が出がちになります。そのためにも個々人の見極めと適材適所の配置が重要になってきます。個々人の志向も年齢や経験に応じて変わるところもあります。ぼくも昔は技術を突き詰めたい派でしたが、30歳を超えたくらいから、それを使って何かやりたいという志向になっていきました。経験則ですが、年齢を重ねるとサービス志向が増えてくる傾向がある気がしています。30歳前半くらいになると技術に自信がつき始めるので、その技術をサービスへどう活かすかに興味が移る人が多いような気がします。実際、知人のエンジニアと話してみるとそれが第一の転職理由というのをよく聞きます。タイプに関わらず必要なのは、会社が何をやっているか、どんなサービスを描こうとしているかをある程度把握することですね。プロトタイプのないサービスをつくっていかないといけないシーンが多いはずです。つくったものがステークホルダーのイメージと乖離していてぶつかっってしまうこともあり得る話ですよね。全体感を把握しながら開発することが必要ですし、トライ&エラーが多いことも含みながら開発プロセスを描く必要があるでしょう。メドピアの時もPVを稼ぐための方法の正解がわからないので、当時はとにかく週次でPDCAを回し続けた記憶があります。「トライ」が多い時に一つ大事なのは、KPIをどのように設定するかで悩みました。何が大事な数値かをちゃんと見て、そこからPDCAを回す。難しいし、落ち着くまでに時間もかかる部分ですけどね。近頃はVSAやOODAなどの方法も聞かれるようになりましたが、いずれにしても、サービス開発者や運用者が「何を誰に対して作っているのか」を全員で意識し、誰に対しても「今これをやろうとしている」と常に言語化されている環境づくりが大事なのだと考えています。メンバー同士で解決しあえるコミュニケーションもう一つ、エンジニアの資質としてコミュニケーション能力があるかどうかが実は大事だと思っています。技術力があまりなくても、自分の想いとかやりたいことをちゃんと話せる人であれば、意見や不満は言ってくれるんですね。「こういうのを考えているんです」とか「こうではないでしょうか」といった具合に。表現できる人同士がメンバーになると、自分たちの間でそんな会話をしながら業務を進めてくれるようになります。これは特にベンチャー組織のマネジメントにとっても大きな機能ですね。優秀な集団でも「俺が俺が」という人ばかりでは仕事が進まなくなってしまいます。エンジニアに向けたメッセージの翻訳が人事には必要Q:エンジニアを抱える成長企業にとって、マネジメント面で留意することは何があるでしょうか。エンジニアに対し会社の理念やビジネスモデルを語ることはとても重要なのですが、それと共に具体的な業務内容を説明することが重要です。会社として何をやってほしいかを明確に伝えないとピンとこないんです。理念やビジネスモデルを実現するために、こういうサービスをつくり、そこにはこういう技術が必要で、こんな体制での開発したいのだけど、この技術や人材がたりないのであなたにお任せしたい、という話をすると一気に理解が進みます。その点では、CTOやCHROのような立場の人が、会社が今後何をやろうとしているかをエンジニアにわかる言葉で伝えるかどうかはとても大事です。採用時もそうですし、社内で働くエンジニアに向けたメッセージとしても、トップメッセージの「翻訳」という工夫をする必要があります。個々人の適性が発揮できるような環境をつくるエンジニアの適材適所の見極めには時間がかかるときもあります。個々人が力を発揮するにはそこは必要部分です。したら、技術者出身ではなくても見極めるマネジメントをするという役割の人を別途たててもいいかもしれません。一方で、ベンチャーだと途中でビジネスモデルが変わることもあって。そこで、当初思っていたような適材適所ができないこともあり得ます。本人のやりたいことと会社の仕事があわなくなってくるということです。不幸にもエンジニアが退職を申し出た場合は、必ず会社の方向性を改めて説明して、お互いの合わなくなった理由を言語化した方がよいと思います。言語化することで感情以外の具体的な理由が見え今後に繋がるからです。「将来会社が新しいビジネスを始めて、面白そうだと思ったら戻ってきてください」と伝えることが、結構大事なんじゃないかなと思っています。それをうまくやっている会社もあって、そうすると仮に会社を辞めてもあまり悪くは言わないし、本当に戻ってきてくれればお互いにとって幸せです。相互にメンバーで話をしながら問題解決をしたり、何がわからないかを先に行ってくれたり。それだけでマネジメントにかかる時間や労力が相当変わってきます。取材中にうかがった「エンジニアのコミュニケーション力」の話は、ベンチャー企業経営と技術者と両方を経験したことで出されるまさに実践的なアドバイスの一例でした。CANTERAで、マネジメント向けコーチング研修をスタートします。