スタートアップのエンジニアマネージメントについて考えてみた

AWS Startup Community Advent Calendar 2021の記事です

スタートアップでCTOになってエンジニアの育成やマネージメントを5名ほどやってみて感じたことを書きます。

この記事の対象は、独自のシステムをつかってビジネスを行いたい経営者やマネージャーをメインの対象としています。

エンジニアのマネージメント≠タスク管理

現在のチームを長期的にもつまで、エンジニアのマネージメント＝タスク管理だと思っていました。

例えば、短期開発、単発開発でプログラムさえ納品すればよい、という状態であれば、この考え方は成立します。

年単位でかつその後も保守し続けていくという場合はこの考え方では問題がでてくるのではないかと思います。

エンジニアの仕事へのモチベーションをできるだけよい状態にする、といういことが長期戦には必須だと感じるようになりました。

私は社会人になった直後は、ディレクター、PMをやることが多かったのですが、その頃はまだエンジニアとしての経験が浅く、エンジニアにどうも思われているかまでは考えがいたっていませんでした。

学生エンジニア⇨ディレクター・PM⇨エンジニアとキャリアを重ねて、またマネージメントをやるようになってやっと見えてきた一面もあると思います。

スタートアップのエンジニアになる人の特性

一般的なエンジニアのイメージってロジカルで、クールに淡々と仕事をこなす、というようなイメージをもたれているのではないでしょうか。

個人的な意見ですが、エンジニアはその逆でとてもエモい側面をもっていると思います。

他の業種（営業、コーポレイト）の方のほうが仕事は仕事としてわりきってクールに対応されるかたが多い印象です。

エンジニアは、とっても人間的で個人主義、自分がやりたいこと、仕事が楽しいと感じれる、といったことを重視する人が多いと感じています。

その背景としては、もともとプログラムが好きで趣味の延長で仕事をしている人が多いのがまずあげられると思います。

また技術力があれば環境を自由に選択できる、自身の裁量で仕事ができる、といった自由な選択できるのも大きいと思います。

仕事で淡々としてるようにみえて、プライベートのSNSアカウトでは趣味に熱狂的になっている一面がある人が多いのではないでしょうか。

経営者やマネージャーは人間としてより向き合う必要あり、そこを考えないとうまくいかないのではないかと思います。

特にスタートアップにジョインするエンジニアはその傾向が強いと思います。

エンジニアが変わった時、モチベーションが低い状態での開発が生み出す負債は小さくない

エンジニアはリアルタイムに作業するわけではなく、人がいなくても動く仕組みをつくる仕事です。

理想的としては、開発をして無事動く物を作れば、エンジニアはいなくても資産としては残ることになります。長期的に雇用する意味はないことになります。

とはいえ、一度決めた仕組みでビジネスが回り続けることは珍しく、システムにはビジネスとともにアップデートしていく必要があります。

変わらないことが前提であればわざわざシステムを自前で作る必要はなく、既存のシステムを使えばいいわけです。

それを使わない、という選択という時点でアップデートは当然はいることになります。

開発していたエンジニアがいない状態でアップデートを行うとよく問題がおきます。

当事者ではないのでわからないことが多い、離職した人が問題の種をうめているなど理由はさまざまです。

安定したシステムは安定したチームによってつくられます。

頻繁にエンジニアが変わるシステムはその数だけ技術負債をつくっていくことになります。

ただ上述の通り、エンジニアはエモい人が多く、気持ちのずれでやめてしまうケースも少なくないです。

やめるまでいかないでも、このチームにずっといようと思っている状態で開発されたプログラムと、いつまでいるかわからない、という状態でつくられたプログラムではクオリティに大きく差ができます。

なぜなら自分が継続的に保守し成長させていこうと設計したものと、とりあえず動けばよいと考えたものでは、根本的に異質なものになるからです。

プログラムは使う人に対する未来予測のつみあげです。とりあえずのチームではこの未来予測は限定的なものになりがちです。

安定したビジネス基盤をつくるには安定したエンジニアチームの構築をするべきだと私は思います。

保守ドキュメントについて

余談ですが、ドキュメントをかかせないから引き継いで保守できないのだ、などよく昔は言われました。ではどんなドキュメントを書けば保守できますか？それを考えるのはだれでしょう？

保守できるドキュメントの書き方に正解は少なくともグーグルに公開されている情報にはありません。そういった書籍も自分の知る範囲だとありません。参考になるものはあるかもしれません。

なのに、なぜドキュメントがあれば保守できる、といった話をする人がいるのでしょうか？

これは神話だと思ったほうがよいと個人的には思います。本当の正解はうごいてるプログラムのコードです。それを読み解くしなく、読み解けないプログラムは継続的な資産価値がありません。

結局は担当するエンジニアが設計するコード次第ということになるのではないかと思います。

スタートアップにジョインするエンジニアのモチベーションとは？

スタートアップにジョインするエンジニアの同期はさまざまあると思います。

ざっくりこんな感じではないでしょうか。

• 成長意欲

• チャレンジ精神

• 頼りにされたい

• 自分でサービスを作りたい

中堅であれば、自分単独がある程度できるようになったので自分自身を新しい事業で試してみたい若手であれば新しい技術を学びたい、

そんな思いからスタートアップにジョインする人が多いのではないかと思っています。

このジョインする時に思ったことが実際にジョインして業務したあともかわらず持ち続けることができれば、そのエンジニアは残っていくと思います。

エンジニアが求める適度な信頼と明確なゴール

エンジニアは技術屋であり、単独ではビジネスを生み出すことができないフォロワーやヘルパー的存在です。誰かのアイディアを実現することを使命としています。

誰かから頼りにされてはじめてアウトプットが生み出すことになります。そのため、表面的か潜在的かはさておき誰かに頼りにされたいと思っています。

この頼りにされる度が繊細です。

頼りにされるすぎると「丸投げ」「無茶振り」など認識されます。細かく指示すると「過度な干渉」として認識されます。

最終的に何をどのような期間、人員でつくるか、というのを開始前に決めることが重要になります。

ここでその人にあった目標設定とその人が求める信頼度を設定できると意思疎通が成立し、その後も円滑にコミュニケーションがおこなわれます。

曖昧なままスタートすると「丸投げ」「無茶振り」「過度な干渉」のような負の感情を誘発し、コミュニケーションを阻害するような事象がおきます。

このことはモチベーションに大きく影響します。

目標がころころかわる状況を「動くゴールポスト」など言われます。

そのため、エンジニアは物事の進め方にとても敏感で、本来プログラムとは異質の計画手法などにも強く関心もっています。

アジャイル開発、スクラム開発などの学習に時間を割いているエンジニアが多いのはその現れでもあります。

チームには目標設定ができるマネージャーの存在が不可欠で、エンジニアとうまくすすめれない経営者はそういった手法を学習するか、そういったことに理解があるマネージャーやエンジニアが必要になります。

エンジニアのモチベーションは時間と共に変化する

最初はうまくいっていたし、プロジェクト計画もすすめかたも合意をとった、これまでとやりかたを変えていないのにモチベーションがさがってくる、ということがあります。

• 技術負債（プログラム的な問題）

• 長期開発による興味の変化
  
  

技術負債

一つ目の技術負債ですが、プログラムを開発していくと多くのバグや問題が発生します。また開発をうまくすすまないような問題なども多く発生します。

それが発生する理由はさまざまですが、短期的にみて問題ならないことが長期的に開発をつづけると進行の妨げになるような問題が多く生まれていきます。

こういった問題は開発ともに変化していき、放置しておくとエンジニアのモチベーションを下げていくことになります。

本来はこういった問題はエンジニア自身が解消していく問題ですが、これらを解消するにも期間が必要になります。そのため、アラートがあげずらく、解決しないまま離脱する、ということも少なくありません。

興味の変化

また長期的に開発をしていること興味が変換していくこともあります。これはエンジニアが日々学習していくことによって起きることだと思いますが、やりたいことが変わっていきます。

よりよりパフォーマンスを引き出すには、仕事の技術と自身が学びたい技術をできるかぎり、マッチングして双方が良い方向にすすむようにしていく必要があります。

継続的なエンジニアとのコミュニケーションが重要

エンジニアは外的、内的要因によってモチベーション、アウトプットの振れ幅が大きくなる場合があるので、定期的にコミュニケーションをして、今の状態をよく確認しておく必要があります。

特に計画の遅れが発生している、体調がすぐれない、といったことが起きる場合は、対処が必要になります。

目標の変化の確認、問題のヒアリングなどをおこない、コンディションをよく確認しておく必要があります。

具体的には スクラム開発などで実施される振り返りなどを定期におこなう。定期的に 1on1 を行い、パーソナルな部分をふくめた話し合う機会をつくるとよいのではないかと思います。

長期戦においては、コミュケーションをどうとっていくかが、システム開発のクオリティに大きく反映されていくことなると思います。

一時的なパフォーマンス、モチベーションの変化、継続的に下がる要因を解消する

最初にかいた通り、エンジニアは実はけっこうエモい人が多いので一時的な上がり下がりはよくあります。

良い時はどんどんできあがるが、悪い時はなかなかできあがない、ということが少なくありません。

継続的に下がり続ける場合は、信頼度、目標設定、潜在的な問題などに原因があるので、一緒に対象する方法を検討するとうまくいくと思います。

経営者とマネージャーのコミュニケーション、信頼関係、権限委譲も重要

いくらマネージャーが事前に問題を検知し、対応しようとしたとしても、その対処ができるリソースや権限がなければ、改善に限界がある場合があります。

具体的には、エンジニアの新規採用、評価、昇給などです。これらが全く別のところで行われている場合、せっかくのマネージメントをおこなっても改善を行うまでに時間がかかったり、意思の伝達が適切でなかったり、といった問題がおきます。

経営者はできるかぎりマネージャーを支援し、またマネージメントをまかされた人はそのチームやエンジニアの状態を経営者と共有し、双方で信頼関係を気づくことが重要なります。

私がマネージメントについて本格的に考えれるようになったのは、経営者に採用などの権限を委譲されるようになってからだと思います。

経緯者とマネージメントを行う人の信頼関係がない場合は、いくらマネージャーが問題を検知したとしても、その対応を行うのは難しいかもしれません。

理想的には経営者がそのマネージメントを行えることだと思いますが、上述の通り、エンジニアのマネージメントはエンジニア経験者、あるいはそれに類する経験がないと難しい側面があると思います。

経営者は他にもやることがたくさんあるので、委譲できるマネージャー的存在を採用、もしくは育成することが重要だと思います。

最後に

メンバーとの信頼関係が大事

いろいろ書いてきましたが、エンジニアはエモいので長期的な関係構築を考えると、雇用関係以上の信頼関係が非常に重要になってきます。

つまり日々コミュニケーションができる信頼関係を構築することが重要だと思います。

スタートアップにとってエンジニアに限らず、メンバーの離脱は大きな損失だと思います。

そういったことをできるだけ減らすように信頼関係を構築する方法を考えるとビジネスもうまくいくのではないかと思います。

私のチームが開発しているパフォーマンスマネージメントサービです
https://coteam.jp/

私のチームで一緒に働いてくれるメンバーを募集しています。お気軽にどうぞ。
https://www.wantedly.com/projects/499992