1. jonathanh

    No comment

    jonathanh
Changes in body
Source | HTML | Preview
@@ -13,12 +13,12 @@
#ビジネスのやり方が違うことを理解する
- **ソフトウェアの世界は規模の経済があまり効かない**
- 製造業のプロトタイプ→量産ではなく、プロトタイプ→サービスイン→継続した改善。
- ハードの初期投資はほぼ不要。サーバーだってクラウドで安い。
- - 1000人の組織作ったものが、5人の組織の作ったものに勝てるとは限らない。
- -
+ - 1000人の組織作ったものが、5人の組織の作ったものに勝てるとは限らない。
+
- **BtoB 製品では、マーケティング・プロダクト戦略もエンジニアにしかわからない**
- 企業が全部ソフトウェア企業になってくれば、BtoB で売れる製品は「エンジニアに使いやすい製品」になる。エンジニアの声はエンジニアにしかわからない。
- 同じビジネスニーズに数百社がソリューションを出そうとしている。SIer の請負仕事のような「ちゃんと動く」では勝てない。「エッジが立った(特色のある)」製品が勝つ。
- 特色を維持できる開発プロセスも必要。
@@ -42,14 +42,14 @@
- 逆に、CTO、Product Manager や製品の決定権を持つべき人が、予算管理、経営への報告、人の管理、ビジネスモデル作りが得意とは限らない。多くの場合、苦手。
- 一緒に働いているエンジニアはお互いの技量がわかっているらしい。人事の人が外から見てもわからないのに。
#非エンジニアのマネージャが意識してやるべきこと
- **自分でもソフトウェア脳を少しずつ作る**
- - 到達できないことを知りつつも、技術を勉強する。関連する技術には"Hello World"レベルでもよいので自分で手を動かしてみる。自社製品はかならず手を動かして触る。
+ - 到達できないことを知りつつも、技術を勉強する。関連する技術には"Hello World"レベルでもよいので自分で手を動かしてみる。気になるサービス・製品はかならず手を動かして触る。
- 勉強会などエンジニアが集うところに出る。初めは怖いので誰かエンジニアの人にくっついていく。優秀なエンジニアの人と雑談するとまったく違う考え方に触れられます。
- ここで大事なのは「飼いならされた凡庸なエンジニア」と「優秀なエンジニア」の2種類の人がいること。企業規模やポジションで判断すると逆の人を手本にする可能性あり。
- - 怖いけどアウトプットする。Take だけの人はコミュニティでは認められません
+ - 怖いけどアウトプットする。Take だけは良くないし、なによりアウトプットは自分のためでもあります
- **自分の権限とProduct Manager の権限の分離**
- 「人を管理するマネージャ」であっても製品・サービスの方向性を決めるPM の役割はできないことを認めめる。日本の組織ではPM が全権を握っていない場合が多く、オペレーションマネージャが自分が判断すべきではなくPM が判断すべき事柄を判断しているケースが多い。
- 予算設定に必ずPM を入れる。PM 自身が自分が使えるリソースとコミットするアウトプットのバランスを取るのが一番。ただし、面倒な予算作業を丸投げしてはいけない。良いエンジニアは分かり切った予算を頭の悪いトップに説明したりすることは嫌い。
- 人事評価や採用もできるだけPM やエンジニアを入れる。採用では必ずコードを書かせてエンジニアにレビューしてもらう。