ITエンジニアは読んでおこう「ソフトウェアファースト」感想

ずっと読みたかった及川卓也さんのソフトウェアファーストを読了したのでメモ。

「DXとはIT活用を手の内化すること」など、バズワードに惑わされず、筆者実体験から来る、具体的な言葉でわかりやすくIT業界や経営の課題が書かれた良書、いや名著だと思います。

肝に銘じておきたいと感じた内容を書きます。

・従来とクラウド普及後の開発スタイルの違い
従来）
・更新コストが高く、リリース前にあらかじめ決められた品質基準をすべて満たしていることを確認する必要がある
・リリースするまでが仕事。
・開発と運用が独立
・最重要項目は、リコール／回収事態にならないこと

クラウド普及後）
・更新コストが比較的低く、リリース後に修正する選択肢も考えられる
・リリースしてからが本番。
・開発と運用が一体化
・最重要項目は、サービスが停止しない、アクセス不可にならないこと

・ユーザドリブンな開発
職能組織ではエンジニアとレビューア、QA（品質管理）間でブラックボックスになりがち。事業主体組織にしてプロダクト中心で物事を考える。また、ユーザログを取得して解析するなどの施策が有効。

・狩野モデル
日本企業の陥りがちな間違った品質追求の誤解を説明できるモデル。品質を５要素に分解。イノベーティブなプロダクト開発で重視すべきは「魅力品質」と「一元品質」。「当たり前品質」を高めても顧客満足度には繋がらない。

当たり前品質
充足していると当たり前で、不充足であれば不満を引き起こす。
例）車がアクセルを踏むと進む

一元的品質
充足されていれば満足を引き起こし、不充足であれば不満を引き起こす。例）車の燃費

魅力品質
充足されていれば満足だが、不充足であっても満足度に影響しない。
例）車のインターネット接続機能

無関心品質
充足されていても不充足であっても満足度には影響を与えない。
例）見えない部分の塗装

逆品質
充足されていれば不満を引き起こし、不充足であれば満足を引き起こす。例）車のエンジン音

・使われるプラットフォームの構築の仕方
最初の一歩は特定の領域、あるいはごく少数の企業が確実に使えるものを提供する垂直型サービスづくりから始めるべき。（はじめからあらゆるユーザニーズに応えようとしても期待を裏切るだけ）

最初は汎用化を考えず、特定用途の機能を少数のパートナー企業と共同で作っていくほうが現実的。それが優れた機能になったら次のステップとして汎用APIを提供していく。

・新規事業の立ち上げ時の注意
最初はプロダクトマネージャーだけをアサインし、企画中のソリューションが正しいのかひたすら検証。ソリューションも複数案考えて比較。

はじめからエンジニアを入れると作る方を優先してしまいがち。作っては壊しの繰り返しはエンジニアを疲弊させる。

・エンゲージ施策
ネットフリックスの勝因の１つ。ユーザの利用データを徹底分析。コンテンツ作成に寄与。
ネットフリックスとブロックバスターの歴史から企業の存亡に必要なこと。

１．手段が変わっても変わらない、高く掲げた企業理念を大切にする
２．エンゲージメント強化への取り組みを妥協しない
３．意思決定者が技術に対する理解を深める

・ローンチ＆イテレート
自分の周りの人間をアーリーアダプターと仮定してプロトタイプを作り、仲間内で実証してから外部公開する。外部公開後は評価を検証して実際のユーザを想定してプロダクトを育てていく。
素早くリリースして仮説検証サイクルを回していくプロダクトアウトとマーケットインのハイブリッド開発。

・創造性は制約を好む
10%増ではなく10倍増を考えると根本的に発想を変える必要がある。例えばChromebookは構想発表時「起動から利用開始まで10秒を実現する」（当時Windowsで同じことをやると5分）

ただし、無理な目標を上司から押し付けられたという形になってはいけない。制約条件をあえて強くして新たな発想を生むやり方は有用。

・ネーミングは重要
先入観を捨てるためには名前や呼び方が大事。

・企業がDXやIT活用の方法論を考える際に意識したい事柄
１．ハードウェアはソフトウェアのためにある
２．ソフトウェアはユーザエクスペリエンスのためにある
３．ユーザエクスペリエンスは人々の感情を満足させるためにある

・PRD（Product Requirements Document）
プロダクトの骨太の方針。また変更可能な動的ドキュメント。一般的には以下。

・プロダクトの概要
・開発の背景
・プロダクト原則
・スコープ
・対象ユーザ
・ユースケース
・市場分析
・競合分析
・機能要求
・その他の技術的要求
　・システム要求
　・セキュリティ要件
　・ プライバシー要件
　・パフォーマンス要件
・リリーススケジュール・マイルストーン
・マーケティング計画

・ダイバーシティの誤解
組織に求められる多様性は、バラバラの人が集まることではない。ミッション対する共感度が高いという同質性がある中で、多様性を重んじるのが正しいやり方。（同質性が高いと意思決定スピードが早い）

議論を尽くすのは大事。だが、行き先も価値観も全く異なる人との議論は時間の無駄。

・デジタイゼーション、デジタライゼーション、DX

・OSSに学ぶ組織文化
ITテクノロジーが持つ可能性を信じ、情報共有を勧め、メンバが自発的に協力し合う文化の醸成が望まれる。その参考がOSS。その文化は以下。

・開発方針や機能追加について、誰がどんな発言をしても平等に扱われる。
・情報を 1 人で囲い込まず、横展開する人が尊ばれる。
・他人が進めている開発を進んでサポトする協業も尊ばれる。
・社会的な地位や経験値より、積極的に開発に参加する人が尊ばれる。
・結果、開発したソフトウアの成果は「参加者全員の成果」と見なされる。

・全員が「プロダクト志向」で考える
WhyとWhatは事業側。howはエンジニア。役割分担を明確にするとスピーディだが、行き過ぎると、社内でありながら別会社のように受発注する関係になる。

事業サイドも開発サイドも、プロダクト志向でユーザへの価値提供を意識することで連携が深まる。プロダクト志向とは、ユーザに提供する価値を最大化するために何が必要かを考えること。

・出島戦略の成功要素
出島とは、新しいプロダクトチームを立ち上げる際の戦略。既存組織とは異なるルールで動く治外法権な組織。軋轢のもととなるため物理的な隔離が必要。また、成功には「明確な成功定義、定量的なKPIの設定、四半期ごとの成果と周知徹底」を押さえる。

・π型人材を目指す
π型人材とは、2つの専門分野を持ち、全体の調整をしたり複雑な課題を解決したりすることができる人のこと。 キャリア形成の考え方のひとつ。

・人は生涯成長を続ける生き物
キャリアを積んだシニア世代でも諦めることはない。常に学び続ける姿勢を忘れないようにしなくてはいけない。学習しなくなったらその人の成長は止まる。

・Connecting the dotsと計画的偶発性理論
スティーブ・ジョブズのスピーチで語られた「点と点をつなぐ」考え方。これは、「個人のキャリアの8割は予想しない偶発的なことによって決定される」という計画的偶発性理論と同じ。

予期しない出来事を計画するには、以下の行動指針が大事。

・「好奇心」 ―― たえず新しい学習の機会を模索し続ける
・「持続性」 ―― 失敗に屈せず、努力し続ける
・「楽観性」 ―― 新しい機会は必ず実現する、可能になるとポジティブに考える
・「柔軟性」 ―― こだわりを捨て、信念、概念、態度、行動を変える
・「冒険心」 ―― 結果が不確実でも、リスクを取って行動を起こす

・学習効果を飛躍的に高める方法
業務に関連付けて勉強する。仕事に関係あることで自分に興味のあることを提案する。内発的動機付けと外発的動機付けが一致することで学習効果は飛躍的に高まる。

本業と異なるなら業務外で実施するしかないが、これが実施できるよう、経営側は組織運営に常に「余白」をもたせるようにする。

・変化を求める
変化とは進化。変化のスピードは社会の変化に追いついているか？

人に喜んでもらうものを提供する喜びを持てれば、社会課題を解決して救われる人を見られれば、多くのことが変わっていく。小さな変化が大きな変化を生んでいく。

ソフトウェア・ファースト