一応エンジニアの端くれなので、読んでおこうかという気持ちでこちらの本を読んでいました。
エンジニア向けの本というよりは、世のIT企画等に関わる方々全般向けの、考え方を指南する本だと感じました。
今回は読んで考えた事のメモです。
tl; dr;
- ITを取り巻く環境の考え方
- パッケージからサブスクリプションへ
- 所有から消費、そして体験が価値を持つ時代へ変化している
- IT活用を核にした事業・プロダクト開発によって、破壊的変化に対応すべき
- パッケージからサブスクリプションへ
- 姿勢
- なぜ日本のITはダメか？
- 効率化偏重思考
- サービスのライフサイクルに関する誤解
- 品質神格化
- ソフトウェアを作るとは?
- 自社のビジネスをサービス化するためのプラットフォーム
- ニッチ×プラットフォームは検討の価値あり
- 開発の内製化は急務
- 自社のビジネスをサービス化するためのプラットフォーム
- なぜ日本のITはダメか？
- 組織
- あるべき開発体制を作るための組織はどうあるべきか?
- 全員がプロダクト志向の組織になる事が必要
- 古臭い制度は捨てる覚悟が必要。でも合理性は必要。
- エンジニア採用はどんどん難しくなっている
- あるべき開発体制を作るための組織はどうあるべきか?
ITを取り巻く環境の考え方
サブスクリプション化時代
我々の社会は所有から消費、そして体験の時代へと移り変わっているそうです。 今や、体験が最も価値があるものとしてとらえられ、物を所有することは重要視されなくなりました。 例としては、音楽のサブスクリプションサービスやメルカリ等のCtoCビジネスでしょう。
こうしたビジネスが成功するためには、消費者の体験に対する反応を取得し、それを頻繁にソフトウェアに反映させていくことで、常に顧客満足を改善して体験価値を維持することが必要になってきます。
その文脈では、顧客を把握したり、頻繁にサービスを更新できるソフトウェア・開発体制はビジネスを行う上でのキーになってきます。
ソフトウェアファースト is なに？
本のタイトルにもなっていますが、「ソフトウェアファースト」という考え方が本書では軸になって語られています。
本書のタイトル「ソフトウェア・ファースト」とは、IT（とそれを構成するソフトウェア）活用を核として事業やプロダクト開発を進めていく考え方です。 ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
定義としてはこんなもんらしいです。
姿勢：ソフトウェアに対する向き合い方
今の日本、ヤバい？
最近の日本企業の衰退っぷりを見ると「大丈夫か？」と感じる方もいるかと思います。
読んでて面白かったのは、過去のおもちゃが今になって破壊を生み出している点です。 パーソナルコンピュータは発売当時はおもちゃでしたし、携帯電話なんて笑っちゃうくらい大きなおもちゃです。 でも、今や世の中を席巻している。これは非常に考えさせられます。 その文脈で言うと、ARとかVRとかのグラスウェアも、まだまだちゃんと使えるとは言えないですが、将来を考えるとベットしておくのも悪くないのかもしれませんね。
何はともあれ、”今”は基本的にどの産業も安心できない状況にあるんですが、今回はソフトウェアの観点で考えます。
ダメなポイントは
- 効率化偏重思考
- ソフトウェアライフサイクル
- 品質の神格化
かなと思います。 この３つのトリプルコンボによって、日本のITサービスはうまく回っていかないように思います。
効率化偏重思考
これについては、私自身ひしひしと感じるところではありますが、ITを効率化の道具と考える時代は終わったのかなと。 ペーパーレスでコスト削減なんて生易しいものではなく、そこから富を生み出していかないと競争に敗れていく、そんな時代になっているなと感じます。 この考えでITを導入するとろくなことになりません。
そして、効率化の道具と思っていると、ITの開発を外部委託しがちです。 自分たちでサービスを育ててITで富を形成してく必要があるのに、外部委託では肝心の”育てる”という部分ができません。
ソフトウェアライフサイクル
2000年代のソフトウェアといえばパッケージが主かと思います。 なので、作って終わりというスタンスで、よほどのことがない限り修正は行われず、使い続けるというのが一般的でした。
今やソフトウェアは、作って終わりの時代から、作って育てるものに変わっています。 そういった意味ではソフトウェア製品のライフサイクルはより短いサイクルで改修され、バージョンアップ等を含めた全体としては長く使われることが想定されているように思います。 とあるITサービス会社では、細かいサービスは毎日リリースする話を聞いたことがありますし、日々改善していかないとサービスとして生き残っていけません。
品質の神格化
日本はとにかく品質に関するこだわりが強いです。 歴史ある企業ほど、それは顕著のようで、怖いくらいに品質を重視しています。
ただ、「品質」と一言に言っても色々あります。
何故か当たり前品質だけに固執してしまっていたり、魅力品質をおろそかにしたり。
余談
余談ですがこんな記事も過去に書かれています。
もともとダメだった、よかった時期なんかそもそもなかったという論調ですね。 技術力が高いのかどうなのかは、見方によるとしか言えないと思いますが、今の世の中は間違いなく後進国に追いやられているとは思います。
過去の、あったんだかなかったんだかわからない、技術大国の時代の慣習に固執して、 日本のビジネス全体として、身動きが取れなくなっているというのが実態かなと思います。
ソフトウェアを作るとは？
何を作る? : ニッチ×プラットフォームは検討の価値あり
これは非常に共感できた部分で、ニッチな分野でのプラットフォームとしてのITサービスは検討に値するというものです。 汎用を目指すのではなく、とことんニッチな市場でプラットフォームを作って、そこで市場を拡大していくというやり方がこれからのIT サービスには有効かもしれないと。
誰が作る? : システムの内製化は前向きに検討する
ソフトウェアは買ってくるものから、ソフトウェアは買うものから自分で作るものになってきたのだと思ってます。 いろいろ理由はありますが、昔ながらのウォータフォール的な開発の方法では変化のスピードに耐えられなくなってきています。
日本の昔ながらの企業は、ITと聞くとなぜか難しいものという認識を持ってしまいがちですが、システムを外注して先進的なDXは困難を極めます。 ただでさえコミュニケーションという問題が待ち構えているのに、そのくせ綿密に企画検討してから開発なんてやってたら、その間に類似サービスが出てしまうかもしれません。
本気で DXに取り組んでいこうと考えているのであれば、システムは内製化してソフトウェアを中心においたビジネスを素早く展開していくことをう進めないといけません。
どう作る?：リーンスタートアップ・デザインスプリント
あまり詳しくない分野だったんですが、リーンスタートアップやデザインスプリントのような考え方が活用できるかもしれません。 これは、とにかく小さく作って頻繁に検証して、方向性やニーズを把握し続けるという手法のようです。
特にデザインスプリントでは、ユーザー理解からプロトタイプ検証まで5日でやるみたいです。 これはさすがに極端かもしれませんが、それでも短期間で検証を繰り返すアジャイル的な考え方が良さそうです。
どうまとめる?：PRDで開発の方向性を記録に残す
プロジェクト関係者での共通理解を図るために、PRDという文書を作成するそうです。
- プロダクトの概要
- 開発の背景
- プロダクト原則
- スコープ
- 対象ユーザー
- ユースケース
- 市場分析
- 競合分析
- 機能要求
- その他技術的要求
- システム要求
- セキュリティ要件
- プライバシー要件
- パフォーマンス要件
- リリーススケジュール及びマイルストーン
- マーケティング計画
インセプションデッキよりも、もっと細かい版って感じですね。 物をつくって、その後の展開まで見据えたドキュメントにすることが目的となります。
もっとかんたんに進める場合には、ワンページャーやインセプションデッキを活用しながら進めていくと、なるべく手間をかけずに認識のブレを減らすことができそうです。
どう使う?：運用から考える
使われないプロダクトはゴミである
これに付きます。DAU, WAU, MAUなどの指標を使用したりチャーンレートを見たり、NPSを活用したり、プロダクトの満足度を測定する手法は様々登場しているので、プロダクトをどう評価するのかはきっちり決めておく必要があります。
組織：開発に関する組織はどうあるべきか？
こうしたソフトウェアを開発するためには、組織体制としてどうあるべきなのでしょうかという話です・
マインドセット
組織を考える上でのゴールは、エンジニアであるなしにかかわらず、プロダクトにかかわるすべての人がプロダクト志向になることだと思います。これは、エンジニアが業務についての深い理解を必要ということにもなります。
もはや、プログラミングがエンジニアの仕事、ビジネスはビジネスサイドの仕事、といった区分けはできなくなっていますし、それをやっていてはソフトウェアファーストにはいつまでたってもなれません。
こういった、組織全員がソフトウェアについて考えていくようなマインドを持つことが、これからの組織作りには必要なのかもしれません。
組織
上でも書きましたが、社内で開発を内製化していくのが理想です。 エンジニア組織の教科書的な組織については、過去に書いたので割愛。
制度・文化
日本の昔ながらの企業文化は、最近のエンジニアに好まれないことが多いです。 いわゆるイケてるベンチャーがやっている、面白い福利厚生やリモートワーク等の制度や文化を取り入れることが、内製化を進めるための文化醸成には必要かもしれません。
一方で、なんでもかんでもやればよいということではなく、合理性を持った制度の導入が望ましいです。 特に、リモートワークなどはコミュニケーションロスにつながる恐れがあるので、十分な注意が必要のようです。 この辺はイケてるベンチャーといっても結構注意しているようで、フルリモート可の会社はあまり多くない印象ですしね。
目標はあくまで、組織としての生産性を最大化することです。 それを忘れずに取り組んでいく必要があるかと思います。
人材確保
多くの場合、エンジニア界隈の人材確保は難しくなってきています。 そして、IT以外の業界の従来型の人材確保の方法は、ITに対しては効果的でないことが多いです。
この辺については答えはないと思います。 本書を読んで改めて感じることは、優秀なエンジニアほど人材マーケットに流れていないということです。 そのため、本当に欲しい人材を確保するためには、エンジニアのためのPR活動や採用方針を決める必要があるように感じています。
キャリア：エンジニアのキャリアとは？
この辺はも過去に書いたので省略。
この辺は、こっちの本の方が詳しく書いてある気がします。
興味深いのは、著者のキャリアですね。 非常にチャレンジを好んだキャリアを選ばれていて、私から見るととんでもないキャリアを積まれていて、すごいなあと感じるばかりです。。。
感想
書かれていることについては、非常に納得しました。非常に勉強になりました。。。 もっと言えば、エンジニアのキャリアについての考え方については非常に参考になりました。
著者に媚を売るとかはおいておいて、この本にはいろんな観点からソフトウェアについて書かれていて非常にためになりました。 どうやって企画し、どうやってすテークホルダーを説得し、どういった組織を構築し、どういったキャリアが考えられるか。
私自身開発に関わる身として、DXというわけのわからないテーマが最近増えている中、エンジニアリングを取り巻く考え方にも諸説あるかと思ってます。 それでも、この本は
これからのソフトウェアはこういうもので、その周辺はこうあるべき、進めようとするとこういう問題にぶち当たって、こうやって解決する
という点について、一つの答えが書かれていると思います。 エンジニアだけでなく、ITに関わる全ての方々、DXを進めていく経営者の皆様はぜひご一読いただきたい、そんな本でした。
マジでうちのチームのやつは上から下まで全員読め。
