強い開発組織

開発の外部委託する問題点＝内製化の理由

　・スピード
　　・ユーザーのフィードバックをスピーディに対応し続けるのは宿命
　・ノウハウの蓄積
　　・企画、仕様、設計、実装、品質確認、リリース　はすべて自社が担当
　⇒外部委託の問題点はスピード感と内部ノウハウの蓄積に加え、痛みの共感できないことも重要。そもそもSIと事業会社とビジネスモデルがあまりにも異なり、利益相反になってしまっていると最近の失敗で痛感

エンジニアの採用について

　・報酬は大事だが、「挑戦しんがいのある開発テーマ」を提示しよう
　・エンジニアの働きやすい環境づくり
　・マネージャは開発経験者がベスト
　・ソフトウェア開発に必要な環境や組織文化整っていないにも関わらず、マネジメント人材だけを確保し、あとはすべて任せて結果を待つのは得策ではない

外部リソース使って問題ない場合

　　・誰が作っても差異のないソフトウェア
　　・開発上必要だが、一度しか使わない
　　・オープンソースソフトウェアを活用する場合
　　　⇒個人的には比較的に重要ではない、人材の外部調達やりやすい部分は外部委託も可と思います

　　・外部委託するリスクを慎重に検討しよう。自社で巻き取れないということは、すなわちつくったその日から負債をかかえているようなものなのです。
　　　⇒正直、この一言は耳が痛く、衝撃的

全員がプロダクト志向

　・事業サイドの人間がテクノロジーを学ぶのと同様に、エンジニアリング組織もプロダクト志向で物事を考える組織にかわっていかなければならない
　・WHATとHOWは分業ではなく、一緒に考える
　・究極のプロダクト志向
　　　・事業発展させるには時期プロダクトで何を実現しなければならないのか？　を考え、技術的な実現性をいったん忘れてユーザーが求めるるだろう仕様を形にしようとする

開発組織を整備するステップ

職種を定め

　　・プロダクトマネジャー
　　・ソフトウェアエンジニア
　　・エンジニアリングマネジャー
　　・デザインナー
　　・QAエンジニア
　　　※　マネジメント職の役割を明確にするのが重要

開発組織におけるマネジャーの役割

　　・メンバーのパフォーマンスを最大化にし、成長を助け、成長し続ける組織を通じて事業に貢献すること
　　・エンジニアリング組織のマネジャーは組織を束ねてメンバーの成長を支援するだけではなく、技術面の判断も求められる
　　・プロダクトマネジャーとエンジニアリングマネジャー
　　　・PM：ミニCEO、製品責任者、プロダクトの成功に責任を持つ
　　　　・人事権を持たないケースが多い
　　　　・典型的なタスク：企画、設計（ユーザー体験、インタフェース、技術妥当性検討）
　　　　・実装時におけるプロダクト判断（品質基準設定、トリアージ）
　　　　・リリース及びそのあとのプロダクト判断（Go-to-Market、グロース）
　　　・EM：
　　　　・開発組織の責任者
　　　　・エンジニア一人ひとりの成長を支える
　　　　・担当する組織を限定して人事権を持つ
　　　　・成長し続ける強いエンジニアリング組織を構築することに責任を持つ
　　　　⇒PMは「WHY」、[WHAT」にフォーカス、EMは「WHO」、「HOW MANY/HOW MUCH」にフォーカス
　　　・組織が大きくなると、テックリードを作る

経営陣

　　　・CTO
　　　　・技術ディレクション
　　　　・経営に対して技術面から関与（技術をどのように経営に活用するかを考える、技術戦略）
　　　　・エンジニアリング組織のトップとして組織マネジメント（VPoEの役割）
　　　　・昨今はエンジニアが転職先を選ぶ時の一つの要件として、その会社に優れたCTOがいるかとのこと
　　　・VPoE

自社にあったジョブディスクリプションを作ってみる

　　・自分の所属する組織がやるべきことを言語化する
　　・現場の状況を把握しながら、タスクを列挙し誰がそのタスクをたんとうするかを考えるボトムアップのアプローチをお勧め
　　・タスク、役割、何に対して責任を負う、必要なスキル、経験、マインド
　　・構成：募集の背景（オプション）、職務内容、責任、要件（Must Have、Nice Have）

職能組織と事業主体組織

　　・自社組織図の中でエンジニア組織をどう位置付けるかを考えよう
　　・職能型：　開発部として独立
　　・事業主体型：各事業に開発チームを持つ
　　・複数プロダクトを開発・運営する企業では、プロダクト毎に開発方針や開発サイクルがちがうため、職能組織で決めたルールが足かせになることもあり得る
　　・マトリックス組織
　　　・職能と事業の両軸
　　　・2人以上の上司、メインとサブ
　　・事業価値の最大化と組織成長のバランスが重要
　　　・組織は一度作ったら終わりではない
　　　・随時形を変える必要
　　　⇒組織ベース以外、PJベースで人員を編成するアイディアもありかも

出島戦略

　　・押さえるべきポイント
　　　　・何をもって成功とするのか、目標を明確に
　　　　・目的達成の度合いを正確に測定できるKPI
　　　　・四半期ごとに何等かの成果を出し、周知を徹底
　　　　・PoCだけではいけない

エンジニア採用難の解決策

　　・給与テーブルにひもづく人事制度を見直せ
　　・できる限り同一会社で採用、一体感の醸成
　　・社内職種の平等を考慮してばかりいると、外部から優秀な人材を獲得することが不可能ですし、社内優秀な人材が外部流出するリスクも高くなります
　　・正しく評価するには、組織が期待するプロフェッショナルとしての理想形を考える必要がある
　　・現代のソフトウェア開発はコミュニケーションが重要、スムーズに意思疎通だけではなく、良いプロダクト開発に向けての建設的な議論が含まれます。
　　・ボトムアップでエンジニア組織内の評価基準をまとめる（特徴量抽出）
　　・リファラル採用は採用目的ではなく、自組織の課題を炙りしにも有効
　　・人材エージェント頼みの採用は間違い、そもそもレベル高い人がエージェント不要
　　・最初の１名が重要、必ず組織のトップを担う必要がないが、少なくとも組織づくりを一緒に進めていけるような人を選ぶ
　　・給与や評価を見直すような制度面の変革はどうしても堅苦しいものになりがちで、同時に多様な個性がぶつかりあうことを許容し、そこから生まれる創造性を重視する組織文化を醸成していくのが良い
　　・組織文化を変える、就業規則など、フックがたくさんある、
　　・変化に強い開発組織は「信頼」から生まれる
⇒成功の循環というフレームワークがある、循環のスタートは「関係の質」、つまり組織中のメンバー間は良い関係を築かない限り、思考、行動、結果の質が上がらないとのこと
　　・期待を語り続けるのは自主性を引き出すきっかけになる
　　・あらゆる制度は運営側の魂がはいらないと形骸化してしまい、場合によってはマイナス効果
⇒まさにご指摘はごもっとも、今推進中のPOトレーニングを形骸化になっていないのか、振り返りをして方向性を考え直す

　　・「やれること」より「やりたいこと」を尊重して組織作り

ソフトウェアファーストのキャリアを築くには

　　・キャリア形成の「型」
　　　・T型⇒専門を深める、専門を広げる、厚みを作る、専門を増やす⇒π型
　　　・藤原和博氏提唱する「ホップ・ステップ・ジャンプ」
　　　・複数の縦軸を作る時の選び方、コネクティング・ザ・ドッツ
　　　・スタンフォード大学のジョン・D・クランボルツ教授の計画的偶発性理論
　　　　　・慎重に立てた計画以上に、予想外のでき事や偶然のできことがキャリアに影響を与える
　　　　　・好奇心、持続性、柔軟性、楽観性、冒険心
　　・学習効果を高める秘訣は自分のやりたりことを仕事にすること。業務に関連付けて学習することにより、内発的動機つけと外発的動機付けが一致することになるので、学習効果は飛躍的に上がります。
　　・スキルの棚卸
　　　・聞いたことがある、内容を理解している、まあまあ使える、使える、十分に使いこなせる
　　・身に付けたスキルは遅かれ早かれ陳腐化する　例：グーグル発祥のSRE（Site Reliability Engineering）という方法論がインフラエンジニアのスキルと異なるものが求められている
　・キャリアパス
　　・キャリアの軸足：　技術力・人と組織・プロダクトとビジネス
　　・三つのパターン
　　　・エンジニアを極める
　　　・エンジニアリングマネジャーを志向
　　　・プロダクトマネジャーを志向
　　　・ソフトウェアファースト人材になる第一歩
　　　　・感度の高いユーザーになる
　　　　・作りての気持ちを理解する
　　　　・修羅場の経験は人を成長させる

『ソフトウェア・ファースト』読書メモ その3