1. jonathanh

    No comment

    jonathanh
Changes in title
-非エンジニアマネージャがエンジニアチームと上手くやる方法
+非エンジニアのマネージャがエンジニアチームと上手くやる方法
Changes in body
Source | HTML | Preview
@@ -1,70 +1,73 @@
近頃の世の中の流れは恐ろしい。
>寝るときは製造業、朝起きたらソフトウェア企業
by Werner Vogels(CTO, Amazon.com)at AWS re:Invent 2017 Key Note
-今後企業は競争力の源泉をテック分野に求めざるを得ず、AI/IoT といった部分に外注ではなく自社リソースをつぎ込み、ソフトウェアの会社へと変わっていくしかないという意味だと思います
-では、「寝るときは非IT 企業のマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか?非エンジニアで、外資系開発コンポーネント企業のマネージャをやっている私の経験からのTips を共有します。
+企業は競争力の源泉をテック分野に求めざるを得ず、製品のサービス化やAI/IoT といった部分にリソースをつぎ込み、ソフトウェアの会社へと変わっていくしかないという意味でした。GE はプログラミングができない人は今後採用しないと
+では、「寝るときは非エンジニアのマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか?非エンジニアで、いつのまにか開発ツールベンダーにどっぷりの私の経験からのTips を共有します。
結論:
**目標もバスの走らせ方もバスに乗せた優秀な人たちに任せて、バスの整備をする人になる。**
マネージャが「何をつくるか?」の決定権を持てるのは彼/彼女が優秀なエンジニアの場合だけです。非エンジニアのマネージャは、ひたすらエンジニアが働きやすい環境を作るのが仕事です。
-
#ビジネスのやり方が違うことを理解する
**勝てる企業:小規模の天才的なビジョナリーと優秀なエンジニアチームを持ち、CTOやProduct Manager の管理の元、一気にリソースを投入できる会社。**
-- **ソフトウェアの世界は規模があまり効かない**
- - 製造業のプロトタイプ→量産ではなく、プロトタイプ→サービスイン。
- - ハードの初期投資はほぼ不要。サーバーだってクラウドだし
+- **ソフトウェアの世界は規模の経済があまり効かない**
+ - 製造業のプロトタイプ→量産ではなく、プロトタイプ→サービスイン→継続した改善
+ - ハードの初期投資はほぼ不要。サーバーだってクラウドで安い
- エンジニアの生産性のばらつきは大きい。
- 1000人の組織の作ったものが、5人の組織の作ったものに勝てるとは限らない。
-- **勝つ製品が何なのかはエンジニアにしかわからなくなる**
- - 企業が全部ソフトウェア企業になってくれば、売れる製品は「エンジニアに使いやすい製品」
- - 同じビジネスニーズに数百社の企業がソリューションを出そうとしている。SIer の請負仕事のような「ちゃんと動く」では勝てない。
+- **勝つ製品が何なのかはエンジニアにしかわからな**
+ - 企業が全部ソフトウェア企業になってくれば、売れる製品は「エンジニアに使いやすい製品」になる
+ - 同じビジネスニーズに数百社がソリューションを出そうとしている。SIer の請負仕事のような「ちゃんと動く」では勝てない。
- 「エッジが立った(特色のある)」製品が勝つ。そして、特色を維持できる開発体制も必要。
- **職能別組織が成り立たない。Product Manager という謎の役職**
- Product Manager が製品のポジショニングを決めてエッジ(特色)のある製品を作る。
- Product Manager がマーケティング、セールス、開発、予算を製品の「エッジ」に合わせて作る。
- - 既存の職能別組織で営業が強い組織は「エッジの無い製品」を作りがち
+ - 既存の職能別組織で営業やサポートが強い組織は「エッジの無い製品」を自然と作る
- 人事すらProduct Manager 目線での設計・運用が必要。
+ - 製造業やサービス業(もしくは既存SIer)の組織・ルールでの運用は無理。
-#ソフトウェア脳と非ソフトウェア脳の人は別人種
-- ボトムラインとして、自分の考え方が優秀なエンジニアとは異なることを認める
-- ワクワクで動いている人が多い。
+#ソフトウェア脳とそうじゃない人は別人種であることを理解する
+- 「ソフトウェアが世界を回している」という世界観(吉岡さんクレジット)
+- ワクワクで動いている人が多い。嫌な仕事をポジションパワーでさせることができない。
+- 無駄、繰り返し、データの無い決定、根性、気合などを極度に嫌う(ほんとはビジネスマンならだれでもだが)。
- コーディングは作業ではなく、「アート」らしい。「何行コードを書いて、どれくらいバグが少ないか」などという指標で評価しようとすると「お前は画家を書いた絵の数で評価するのか?」と怒られるし、良いエンジニアは辞めていく。
- 数名の優秀な人が製品・サービスを動かしているという事実を受け入れる。非属人化は高いレベルでは無理。
- 会社の仕事とその他の部分の境界があいまいな人ばかり。「昼は会社で仕事、夜はBlog 書いたり、OSS にコミットしたり、週末は1日は勉強会」のような方こそ採用すべき人。
-- 「調整がうまい人」が「製品をリードするべき人」とは限らない。政治力で物事が決まっていくことが好きなProduct Manager はいません
-- 逆に、Product Manager や製品の決定権を持つべき人が、予算管理、経営への報告、人の管理、ビジネスモデル作りが得意とは限らない。
+- 「社内調整がうまい人」が「製品をリードするべき人」とは限らない。政治力で物事が決まっていくことが好きなエンジニアはいない
+- 逆に、CTO、Product Manager や製品の決定権を持つべき人が、予算管理、経営への報告、人の管理、ビジネスモデル作りが得意とは限らない。多くの場合、苦手。
+- 一緒に働いているエンジニアはお互いの技量がわかっているらしい。人事の人が外から見てもわからないのに。
#非エンジニアのマネージャが意識してやるべきこと
-- **ソフトウェア脳を少しずつ作る**
+- **自分でもソフトウェア脳を少しずつ作る**
- 到達できないことを知りつつも、技術を勉強する。関連する技術には”Hello World"レベルでもよいので自分で手を動かしてみる。自社製品はかならず手を動かして触る。
- 勉強会などエンジニアが集うところに出る。初めは怖いので誰かエンジニアの人にくっついていく。優秀なエンジニアの人と雑談するとまったく違う考え方に触れられます。
- - ここで大事なのは「飼いならされた凡庸なエンジニア」と「優秀なエンジニア」の2種類の人がいることです。企業規模やポジションで判断すると逆の人を目標とする可能性があります
+ - ここで大事なのは「飼いならされた凡庸なエンジニア」と「優秀なエンジニア」の2種類の人がいること。企業規模やポジションで判断すると逆の人を手本にする可能性あり
- **自分の権限とProduct Manager の権限の分離**
- - 「人を管理するマネージャ」であっても製品・サービスの方向性を決めるPM の役割はできないことを認めましょう。日本の組織ではPM が全権を握っていない場合が多く、オペレーションマネージャが自分が判断すべきではなくPM が判断すべき事柄を判断しているケースが多いです
+ - 「人を管理するマネージャ」であっても製品・サービスの方向性を決めるPM の役割はできないことを認めめる。日本の組織ではPM が全権を握っていない場合が多く、オペレーションマネージャが自分が判断すべきではなくPM が判断すべき事柄を判断しているケースが多い。
- 予算設定に必ずPM を入れる。PM 自身が自分が使えるリソースとコミットするアウトプットのバランスを取るのが一番。ただし、面倒な予算作業を丸投げしてはいけない。良いエンジニアは分かり切った予算を頭の悪いトップに説明したりすることは嫌い。
+ - 人事評価や採用もできるだけPM やエンジニアを入れる。採用では必ずコードを書かせてエンジニアにレビューさせる。
- トップへの説明責任には責任を持つ。悲しいですが、自分で判断しないことに対して説明責任を持つ必要があります。
- ただし、PM が「伸びている分野だから、市場の1% でも取れれば儲かるよね。」などといったエッジの無い製品リードを始めたら即刻クビにします。
- **エンジニアの働きやすい環境を作る**
- 良いエンジニアのアウトプットは凡庸なエンジニアの5~10倍。人件費と比べれば他のコストは小さい。
- 全員がHappy になる必要はない。優秀な数名のエンジニアがHappy でいられる環境・組織・ルールを作りましょう。セールス・経理・総務・人事といった人の「古い常識」に引きずられないようにしましょう。
- 良いマシンを使ってもらう。エンジニアにマシンは選ばせればベスト。
- 良い机、良い椅子、必要なら静かな環境、良いモニタ、**良い開発ツール**。
- 出張費とかでガタガタ面倒をかけるとか最悪。
- - 美味しいコーヒー。エスプレッソマシンは当然でしょう
+ - 美味しいコーヒー。エスプレッソマシンは当然。
- 勉強会、セミナー、本など自由にお金を使ってもらう。
- ただし、人付き合いが悪い人が多い(笑)ので、チームが交流する仕組みは必要。昼ご飯とか毎週Pizza の日とか。
- **非ソフトウェア脳の人とソフトウェア脳の人の間をとりもつ**
- 会社のトップのソフトウェア脳教育を根気よく続ける。会社のトップが非エンジニアの場合(ほとんどの場合はそうだが)、トップこそ最大の抵抗勢力です。外から高額で雇ったスーパーエンジニアで会社をソフトウェア企業化する使命を持った人の多くはトップと揉めて短期で辞めます。トップを洗脳するしかありません。
- 非ソフトウェアの現場やいわゆるドメインの理解はエンジニアチームに必須です。現場で仕事を動かしている人とのディスカッションの機会を作る必要があります。はじめは考え方が違うので対立しますが、現場と隔離しすぎると上手くいきません。
- - 愚かなルールに対して治外法権を敷く。企業には、優秀なエンジニアをげんなりさせる諸々の愚かなルールが存在します。外部メールチェック、業務中のSNS 禁止、ソフトウェアダウンロード禁止、提携の報告、上司の評価中心の人事評価体系、人の管理を中心とした昇給システム、etc.。会社としては必要ですが、少人数の優秀なエンジニア集団には不要です。
+ - 愚かなルールに対して治外法権を敷く。企業には、優秀なエンジニアをげんなりさせる諸々の愚かなルールが存在します。外部メールチェック、業務中のSNS 禁止、ソフトウェアダウンロード禁止、提携の報告、上司の評価中心の人事評価体系、人の管理を中心とした昇給システム、etc.。大企業では必要ですが、少人数の優秀なエンジニア集団には不要です。
#でもここで、ふと疑問「最初の数名の超優秀なエンジニア」はどこで見つけてくるの?
ええと。運とか熱意ですかね。