なんかもう全部入りでした。
ソフトウェアは業務を効率化するだけではなく、ビジネスのルールを変えるものであるという考え方をソフトウェアファーストと呼び、
ソフトウェア開発を「手の内化(内製してコントロールできてる状態)」するために組織に必要な観点をプロダクトマネジメント、エンジニアリングマネジメント、採用、評価、給与体系、DevOps、経営、組織文化、キャリア開発などなど、様々な観点を交えて著者の方の経験に基づいて語られています。
ほんと全部入りでした。
ポイントサマリー
定義
ソフトウェアは業務を効率化するだけではなく、ビジネスのルールを変えるものであると言う考え方。課題ドリブンで出発し、ソフトウェアファーストで解決する。
誤った品質追求
- 当たり前品質(基本品質):充足されて当たり前、不足すると不満
- 一元品質(性能品質):充足されると満足、不足であれば不満
- 魅力品質:充足されていれば満足だが、なくても仕方ないと受け取られる
- 無関心品質:満足度に影響を与えない
- 逆品質:充足されていれば不満、不足であれば満足、人によって異なる
-
サービス開発において重視すべきは魅力品質
-
他者が真似すればすぐに基本品質になる
プラットフォーム構築
-
小さいうちに汎用性を高めると期待を裏切る
-
最初は特定の領域、企業が確実に使えるものを
-
APIエコノミーも一種のプラットフォーム戦略
あらゆるサービスは課題解決のためにある
-
恩恵を受ける人が多ければ多いほど支持される
-
課題ありきで考えないとオーバーエンジニアリングになる問題
-
最初はプロダクトマネージャーがひたすらその企画が正しいのかを検証する
プロダクト企画のやり方を変える
-
プロダクトアウト:作ったものや作りたいものを売る
-
マーケットイン:市場やユーザに必要とされるものを作る
10Xを目指す
-
10%成長なら既存の改善で達成できるかもしれないが10倍となると根本から変える必要がある
-
制約を強くすることで創造性を生む
名は体を表すとは
-
新規プロダクトに既存のカテゴリから命名すると先入観を生む
競合に対する見方を変える
-
航空業界の競合はリモート会議システムとなった
-
終電を逃した客を狙うビジネスホテルの競合はタクシーだった
-
競合が新機能をリリースしたら、それは誰のどんな課題を解決しようとしているのかを考える
-
競合は自社に気づきを与えてくれる
ユーザーを理解する
-
インタビューでお困りのことは?と聞いて得られる回答に価値はあまりない
-
観察を通じて本人が気づいていないユーザー自身の理解を進める必要がある
-
遠慮の文化が邪魔をするときは、周りでお困りの方は?と聞くと有効なことがある
インナーソース
-
OSSプロジェクトのやり方を本来クローズな会社組織にも当てはめてみようという考え方
-
誰もが参加、利用可能な状態で開発を進める
-
大事なのは社内のエンジニアが担当外にも貢献したいと思える状況を作ること
事業会社のIT人材育成、コニカミノルタ
-
1年半かけて実施、月一回木金土曜
-
宿題も
-
講師は社内中心で時に外部講師
-
前期の受講生から次期運営を選出
開発組織のマネージャーの役割
-
メンバーのパフォーマンスを最大化し、成長を助け、成長し続ける組織を通じて事業に貢献すること
-
現場発信の議論を受け、引き出し、解決に向けたタスクを提案し、リードしていく
-
それに加えて技術面の判断も求められる
CTOとVPoE
-
CTOの役割を一部切り出したのがVPoE
-
CTOが主に自社の技術ディレクション、経営に対しての技術面からの関与、開発への投資判断やパートナー選定、事業に対して技術面からの判断を担う
-
VPoEはエンジニアリング組織のトップとしての組織マネジメントを担う
-
テック企業の場合、経営陣に技術出身が多くあえて置かないこともある
出島戦略
- CTO直下で素早い事業判断
-
何をもって成功とするのかを明確に定める
-
目的達成の度合いを正確に測定できるKPIを設定する
-
四半期ごとに何らかの成果を出し、周知を徹底する
-
PoCをやるだけの組織にならないように注意
変化に強い開発組織は「信頼」から生まれる
-
やれること、よりやりたいことを尊重する
-
やりたい人に任せてできるようになれば会社の資産となりその人のキャリアアップにもつながる
-
さくらのインターネットではコンテナ、k8sもやりたいひとから発信された
マネージャになることを望まないエンジニア
-
エンジニアとしての力量が乏しい人がマネージャとして権勢を振っているのを見ている
-
あまり意味があると思えない事務作業などに追い立てられているのを見ている