CTO不在の企業で開発組織を作っていくために大事なこと
おはこんばんちは!!尾藤 a.k.a. BTO です。
これは CTOA Advent Calendar 2020 の5日目の記事です。
今までウノウとUUUMの2社のスタートアップでCTOを足掛け10年近くやってきました。経歴柄、CTOのいない企業から開発組織の作り方の相談を受けることが多いですが、やはりCTOが不在で開発組織を作っていくのは非常に困難です。とはいえ、転職市場に都合よく即戦力になりうるCTO人材が簡単に見つかるのも稀です。そこでCTOが不在の中で開発組織を作っていくために大事なことをまとめてみました。
開発組織作りで大事なのは採用ではなく環境作り
開発組織作りで大事なことはいろいろありますが、最も大事なのは採用と環境の2つではないかと思います。環境が良くなければ優秀なエンジニアは採用できないし、優秀なエンジニアに来てもらえなければ良い開発環境を作ることができません。いわゆるにわとりたまご問題で、解決するための銀の弾丸はありません。最も有効な解決手段は即戦力CTOの採用ですが、これも非常に難易度が高い。じゃあどうすれば良いんだと思いますが、あきらめたらそこで試合終了なので、なんとかする方法を考えていきたいと思います。
エンジニアの組織作りのためには優秀なエンジニアの存在が必要不可欠です。そして優秀なエンジニアを採用するのに最も大事なのは環境作りです。なぜなら企業が採用するエンジニアを選んでいるように、エンジニアも転職する企業を選んでいるからです。エンジニアが優秀であるほど好きな会社を選ぶことができるので、優秀なエンジニアを採用したければ、自社が選ばれる必要があります。そのために環境作りは非常に大事です。
ここでいう環境作りは、スペックの高いPCを用意するとか、デュアルモニタにするとか、長時間座っても疲れない椅子を用意するとかそういったことではありません。お金だけで環境作りが解決するならどこの企業でもできます。根本的な課題解決には経営陣自らが取り組んでいく必要があります。
エンジニアは数年で転職する
エンジニアの環境作りを考える上で大事なのが、エンジニアは数年で転職するというキャリア特性です。エンジニアは数年で転職することを知っている方は多いと思いますが、それをただの事実として捉えるだけでなく、その意味をちゃんと理解する必要があります。数年で転職するというキャリア特性をしっかりと理解すると、なぜエンジニアがそのような行動や決断をするのかが理解できるようになります。もちろん、できるだけ会社に長く在籍してもらう努力は大事です。それでも数年で転職するのです。エンジニア組織を作っていこうと思ったら、このキャリア特性をしっかりと理解していく必要があります。
会社に求めるのはスキルアップとやりがいと評価
エンジニアにとって数年で転職することは当たり前なので、そもそも会社に長く所属することは最初から考えていません。なので転職する時は、この会社で数年間働いて何を得られるのかを重要視します。それで数年後に転職するタイミングでキャリアアップしたいので、スキルアップできる環境かどうかを重要視します。よくあるのが、大変な仕事を任せれば成長(スキルアップ)できると考えている方がいますが、これは大きな勘違いです。後述しますが、スキルアップできる環境作りは会社として整備していく必要があります。
またやりがいも非常に大事です。エンジニアの面接をしていると、転職理由として仕事にやりがいがないがよく出てきます。大変な仕事を任せればやりがいがあると考えている方がいますが、これもまた大きな勘違いです。なぜならエンジニアは難しい課題を解決するのは好きですが無理難題を解決するのは好きではないからです。特にB向けのサービスや社内システムでは、この傾向が顕著に出てきます。
最後に大事なのが評価です。例えばエンジニアの転職サイトでは転職先企業で、社長がエンジニアやCTOがいるという項目があったります。エンジニアは評価者にエンジニア出身者がいなくて技術力を評価されなくて嫌な思いを経験した人が多くいます。経営陣にエンジニアを求めるのは、自分の技術をちゃんと評価してもらいたいからです。技術的な観点なしでエンジニアを評価する時は、往々にして開発した機能とスケジュールだけが評価されることになりますが、システム開発は複雑なのでそれだけで評価することはできません。例えば私のように営業の経験が一度もない人間が営業のトップに立って、営業の成果を売上とスケジュールだけで評価したらどうなるでしょうか。現場の営業の方は満足するでしょうか。技術を理解するのは難しいですが、機能とスケジュール以外のことにも目を向ける努力は必要になります。
優秀なエンジニアが採用できなかったり定着しない会社は、上記三項目(スキルアップ、やりがい、評価)が大きく欠けていることがほとんどです。CTOがいない状態でこれらを整備するのは難しいですが、改善していく努力は必要です。これを改善していくための具体的な施策を書いていきます。
開発環境(DevOps)を整備する
今までCTO不在でエンジニア組織作りに困っている会社でDevOpsができている会社は見たことがありません。DevOpsの詳細については割愛しますが、簡単に説明すると開発を効率化するために開発以外の作業を自動化したり、テストコードをちゃんと書くことになります。DevOpsが整備されると開発により多くの時間を割くことができ、エンジニアのやりたいことに集中できるので、スキルアップにもやりがいにもつながります。
DevOpsの整備には工数がかかります。そしてDevOpsの整備は何の機能追加にもなりませんし、短期的なメリットはありません。なので現場のエンジニアから声が上がっても、事業成長優先を理由に実現できないことがほとんどです。もちろん会社が倒産すれば元も子もないので事業成長は大事ですが、それで優秀なエンジニアがいないことを嘆くのは筋が違うと思います。要はトレードオフなのです。
DevOpsの整備は現場からの声はいくらでもあがりますが、整備するためには工数がかかるので、会社の意思決定として取り組む必要があります。DevOpsが整備されていない状態は、例えるならオフィスの環境が整備されずに汚い状態で仕事をしているような状態です。DevOpsをやりたいと提案すると、よくROIを示して欲しいみたいなことを言われますが、オフィスの環境改善でいちいちROIを示すことはないでしょう。大抵の場合は改善を諦めて不満を溜め込み、静かに会社を去っていきます。なぜならエンジニアは転職するというキャリア特性を持っているので、改善が難しい環境で改善のコストをかけるよりかは、転職するコストの方が低いからです。
技術に理解を示す努力をする
先述した通り、エンジニアは技術が評価されず嫌な経験をしている人が多くいます。プログラムが書けるようになる必要はないと思いますが、技術に対しては一定の理解を示すことが大事です。もちろんエンジニアが技術がわからない方に対して、わかりやすく説明する努力は大事です。要は相互理解なのです。
技術がわからないでエンジニアに丸投げしている状態が続くと、エンジニアの評価が機能追加とスケジュールだけになってしまいます。上述したDevOpsの整備は機能追加とスケジュールには直接的には無関係なので、評価対象とならずエンジニアが不満を抱える状態を作ってしまいます。短期的な成果が評価される状態になってしまい、長期的に効果があることが評価されず状況がどんどん悪化してしまいます。
あとは技術に理解を示してくれると、コミュニケーションコストが大幅に削減されます。技術がわからないから丸投げしたいし、わかるように説明をして欲しいという姿勢の方とのやりとりは、コミュニケーションが非常に困難になります。知識がないので説明コストが高く、理解も浅いので本質的な議論ができないからです。例えばプロのカーレーサーは車の整備はしませんが、高度な専門知識を身につけています。そうしないとメカニックと専門的な会話ができないからです。本当にちゃんとした開発組織を作りたいのであれば、プログラムを書ける必要はありませんがある程度の技術知識を持っていないとエンジニアとスムーズなやりとりもできないし、正しい意思決定をするのも難しくなります。
ユーザからのフィードバックを得られる仕組みを作る
エンジニアがプログラムを書いたりシステムを組んだりするのは、いったい何のためにやるのでしょうか。仕事でシステム開発する時は、自分のためではなく誰かに使ってもらうためにやります。なので自分が時間をかけて作ったシステムが本当に役に立っているのかを知りたいのです。
エンジニアの転職先はB2Cのサービスを開発している会社に人気があります。実際優秀なエンジニアはB2Cサービスを開発している会社に集中する傾向があります。これはB2Cサービスだとユーザの役に立っていることが視覚化されやすいからです。
よくB向けのサービスを開発している会社から、うちはC向けのサービスを開発してないからエンジニアの採用がうまくいかないといった声を聞きますが、半分は合ってて半分は間違っていると思います。ユーザからのフィードバックがしっかりとエンジニアにも届く仕組みづくりを心がければ、もっと仕事にやりがいを持ってもらえる状況は作り出せるはずです。
エンジニアの評価・給与制度を別にする
エンジニアはキャリア特性が他の職種と違うので、評価・給与制度を同じにすると歪が大きくなってしまいます。なのでエンジニアに対しては評価・給与制度を別することをおすすめします。
エンジニアの転職市場での評価は個人のスキルへの依存度が大きく、プロジェクトの成否の影響は軽微です。経営者としては会社の業績に貢献してもらいたいので、業績連動の割合を増やしたいところですが、エンジニアの場合はプロジェクトの成否と技術力の関連性が低く、もしプロジェクトがうまく行かなかった時に評価を下げてしまうと不満が大きくなってしまう可能性があります。なので、考え方としては業績連動の割合を他の職種よりも減らし、業績が良くても悪くてもあまり評価に影響しないような仕組みにしていくのが良いかと思います。
日本では労働者の解雇規制が厳しく、給与を気軽に上下できない事情があったりするので、転職市場に合わせるという理想的な状態にするのはかなり難しいです。エンジニアの中には成長速度があまりにも早くて、会社の給与制度が追いつかないケースもよく出てきます。こういったケースにもできるだけ柔軟に対応するためにも、給与制度は分けておいた方が無難です。
エンジニアの言うことを鵜呑みにしない
ここまでかなりエンジニアに優遇する施策を書いてきましたが、エンジニアの言うことを鵜呑みにしすぎるのも良くありません。優秀なエンジニアを採用したくてエンジニアを特別扱いしすぎた結果、エンジニアが楽になりすぎてだらけてしまったり、他の職種からの不満が大きくなったケースもあります。
人間誰でもそうですが、発言した内容や考えている事は理想だったり、なりたい自分を語っていることがよくあります。例えばマクドナルドでアンケートを取ると必ずヘルシーなメニューが欲しいという意見が出てきますが、実際にヘルシーなメニューを導入しても客はマクドナルドでヘルシーものは買いません。会社の経営者としては彼らの言っていることが本当に正しいのかどうかを総合的に判断して意思決定していく必要があります。そのためにもエンジニアの生態系やキャリア特性を理解することは必要不可欠なのです。
しかしながらエンジニアのことを理解した上での意思決定を進めるのは、エンジニアリングの知識がない状態では難しいと思います。自らが進んで学んでいくことも大事ですし、ピンポイントで実績のあるCTOにアドバイスをもらうのも大事だと思います。
まとめ: 大事なのは相互理解
私自身がエンジニアですし、テーマからもかなりエンジニアによった内容になりましたが、もちろんエンジニアにも改善していかないこと、やっていかないといけないことが多々あります。大事なのは相互理解を深めることです。エンジニアがもっと成果を出しやすい世の中を作るために、企業がもっとテクノロジーを武器に事業発展ができるようになるために、少しでもこの記事がお役に立てれば幸いです。
この記事が気に入ったらサポートをしてみませんか？