非エンジニアのマネージャがエンジニアチームと上手くやる方法

近頃の世の中の流れは恐ろしい。全業種ソフトウェア企業にならないと競争力が維持できない。

“寝たときは製造業、朝起きたらソフトウェア企業”
by Werner Vogels（CTO, Amazon.com）at AWS re:Invent 2017 Key Note

という恐ろしい話は管理職に落ちてくるので、「寝たときは製造業のマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか？を考え始めるべきです。
元銀行員で非エンジニアで、いつのまにか開発ツールベンダーにどっぷりの私の経験からのTips を共有します。
エンジニアの方は、非エンジニアのマネージャにしれっとリンクを送ってあげてください（笑）

結論：
目標もバスの走らせ方もバスに乗せた優秀な人たちに任せて、バスの整備をする人になる。
マネージャが「何をつくるか？」の決定権を持てるのは彼/彼女が優秀なエンジニアの場合だけです。非エンジニアのマネージャは、ひたすらエンジニアが働きやすい環境を作ることが最大限できることです。

#ビジネスのやり方が違うことを理解する

• ソフトウェアの世界は規模の経済があまり効かない

  • 製造業のプロトタイプ→量産ではなく、プロトタイプ→サービスイン→継続した改善。
  • ハードの初期投資はほぼ不要。サーバーだってクラウドで安い。
  • 1000人の組織が作ったものが、5人の組織の作ったものに勝てるとは限らない。

• BtoB 製品では、マーケティング・プロダクト戦略もエンジニアにしかわからない

  • 企業が全部ソフトウェア企業になってくれば、BtoB で売れる製品は「エンジニアに使いやすい製品」になる。エンジニアの声はエンジニアにしかわからない。
  • 同じビジネスニーズに数百社がソリューションを出そうとしている。SIer の請負仕事のような「ちゃんと動く」では勝てない。「エッジが立った（特色のある）」製品が勝つ。
  • 特色を維持できる開発プロセスも必要。

• 職能別組織が成り立たない。Product Manager という謎の役職

  • Product Manager が製品のポジショニングを決めてエッジ（特色）のある製品を作る。
  • Product Manager がマーケティング、セールス、開発、予算を製品の「エッジ」に合わせて作り、世に出す。ここに不整合があると、エッジが無い製品が世に出る。
  • 既存の職能別組織で営業やサポートが強い組織はエッジの無い製品を良かれと思って作る。
  • 人事すらProduct Manager 目線での設計・運用が必要。
  • 製造業やサービス業（もしくは既存SIer）の組織・ルール・目線での運用は無理。

#ソフトウェア脳とそうじゃない人は別人種であることを理解する

• 「ソフトウェアが世界を回している」という世界観（吉岡さんクレジット）。
• ワクワクで動いている人が多い。嫌な仕事をポジションパワーでさせることができない。
• 無駄、繰り返し、データの無い決定、根拠のない根性主義などを極度に嫌う（ほんとはビジネスマンならだれでもだが）。
• コーディングは作業ではなく、「アート」らしい。「何行コードを書いて、どれくらいバグが少ないか」などという指標で評価しようとすると「お前は画家を書いた絵の数で評価するのか？」と怒られるし、良いエンジニアは辞めていく。
• 数名の優秀な人が製品・サービスを動かしているという事実を受け入れる。非属人化は高いレベルでは無理。
• 会社の仕事とその他の部分の境界があいまいな人ばかり。「昼は会社で仕事、夜はBlog 書いたり、OSS にコミットしたり、週末は1日は勉強会」のような人が多い。
• 「社内調整がうまい人」が「製品をリードするべき人」とは限らない。政治力で物事が決まっていくことが好きなエンジニアはいない。
• 逆に、CTO、Product Manager や製品の決定権を持つべき人が、予算管理、経営への報告、人の管理、ビジネスモデル作りが得意とは限らない。多くの場合、苦手。
• 一緒に働いているエンジニアはお互いの技量がわかっているらしい。人事の人が外から見てもわからないのに。

#非エンジニアのマネージャが意識してやるべきこと

• 自分でもソフトウェア脳を少しずつ作る

  • 到達できないことを知りつつも、技術を勉強する。関連する技術には"Hello World"レベルでもよいので自分で手を動かしてみる。気になるサービス・製品はかならず手を動かして触る。
  • 勉強会などエンジニアが集うところに出る。初めは怖いので誰かエンジニアの人にくっついていく。優秀なエンジニアの人と雑談するとまったく違う考え方に触れられます。
  • ここで大事なのは「飼いならされた凡庸なエンジニア」と「優秀なエンジニア」の2種類の人がいること。企業規模やポジションで判断すると逆の人を手本にする可能性あり。
  • 怖いけどアウトプットする。Take だけは良くないし、なによりアウトプットは自分のためでもあります。

• 自分の権限とProduct Manager の権限の分離

  • 「人を管理するマネージャ」であっても製品・サービスの方向性を決めるPM の役割はできないことを認める。日本の組織ではPM が全権を握っていない場合が多く、オペレーションマネージャが自分が判断すべきではなくPM が判断すべき事柄を判断しているケースが多い。
  • 予算設定に必ずPM を入れる。PM 自身が自分が使えるリソースとコミットするアウトプットのバランスを取るのが一番。ただし、面倒な予算作業を丸投げしてはいけない。良いエンジニアは分かり切った予算を非エンジニアのトップに説明したりすることは嫌い。
  • 人事評価や採用もできるだけPM やエンジニアを入れる。採用では必ずコードを書かせてエンジニアにレビューしてもらう。
  • トップへの説明責任には責任を持つ。悲しいですが、自分で判断しないことに対して説明責任を持つ必要があります。
  • ただし、PM が「伸びている分野だから、市場の1% でも取れれば儲かるよね。」などといったエッジの無い製品リードを始めたら即刻クビにします。

• エンジニアの働きやすい環境を作る

  • 良いエンジニアのアウトプットは凡庸なエンジニアの5~10倍。人件費と比べれば他のコストは小さい。
  • 全員がHappy になる必要はない。優秀なエンジニアがHappy でいられる環境・組織・ルールを作りましょう。セールス・経理・総務・人事といった人の「古い常識」に引きずられないようにしましょう。「公平性」は不要です。
  • 良いマシンを使ってもらう。エンジニアにマシンは選ばせればベスト。
  • 良い机、良い椅子、静かな環境、良いモニタ、良い開発ツール。繰り返す、CData Software をはじめとする良い開発ツール。
  • 出張費とかでガタガタ面倒をかけるとか最悪。
  • 美味しいコーヒー。エスプレッソマシンは当然。
  • 勉強会、セミナー、本など自由にお金を使ってもらう。
  • ただし、人付き合いが悪い人が多い（笑）ので、チームが交流する仕組みは必要。昼ご飯とか毎週Pizza の日とか。

• 非ソフトウェア脳の人とソフトウェア脳の人の間をとりもつ

  • 会社のトップのソフトウェア脳教育を根気よく続ける。会社のトップが非エンジニアの場合（ほとんどの場合はそうだが）、トップこそ最大の抵抗勢力です。外から高額で雇ったスーパーエンジニアで会社をソフトウェア企業化する使命を持った人の多くはトップと揉めて短期で辞めます。トップを洗脳するしかありません。
  • とはいえ、非ソフトウェアの現場やいわゆるドメインの理解はエンジニアチームに必須です。現場で仕事を動かしている人とのディスカッションの機会を作る必要があります。はじめは考え方が違うので対立しますが、現場と隔離しすぎると上手くいきません。
  • 愚かなルールに対して治外法権を敷く。企業には、優秀なエンジニアをげんなりさせる諸々の愚かなルールが存在します。外部メールチェック、業務中のSNS 禁止、ソフトウェアダウンロード禁止、定型の報告、上司の評価中心の人事評価体系、人の管理を中心とした昇給システム、etc.。大企業では必要ですが、少人数の優秀なエンジニア集団には不要です。

#ふと疑問「最初の数名の超優秀なエンジニア」はどこで見つけてくるの？
ええと。運とか熱意ですかね。