1. jonathanh

    No comment

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