Help us understand the problem. What is going on with this article?

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

バズワードが先行して、実態が伴わない時代には、本質的なことを熱く語ってくれる書籍はそれほど多くではない、これはそのうちの一冊と思います。まさに内製化の必要性を強く感じて、それを模索中の自分には、トンネルから明かりが見えたかのように、行くべき方向を見つかりました。
下記は本から抜粋した、あとで何度も読み返したい内容です。

  • 日本は変化が止まっています。その理由は、社会が変化を望んでいないではないかと感じることがあります。変化には苦痛を伴います。一次的に不幸になる人も出てくるかもしれません。しかし、今の日本は全員が平等に少しずつ不要になる道を歩んでいるのではないでしょうか?不幸になる人を生んでいいと決して言いませんが、少しでも不幸になる要素がある変化を拒み続けた結果、全員が不幸になっているということはないでしょうか?
     ⇒ 先のリスクを過小評価する傾向があるので、苦痛を負っても現状を打ち破る突破力が必要

  • サービス化する社会に合わせたプロダクトを開発するには、開発手法も変えていく必要があります。変革が必要なのはプロダクトの企画、開発・運用手法、技術だけではありません。それらすべて変革を推進する人と組織も含まれます。
     ⇒ Product、Process、Peopleという三点セットで常に考えなければいけません

  • ユーザーのニーズを追えばあらたなプロダクトの企画が生まれるわけではない
     ⇒ イノベーションのジレンマーの示された通り

  • DevOpsは開発と運用が一体となり、プロダクトを育てていくという組織連携、それを支える文化、そして開発と運用のツール等を含むものとされています

  • 企業がソフトウェアファーストを実践するには、ソフトウェア技術を理解し、事業に活用できる人材が必要です。このような人材を育て、生かせる組織が必要です。さらには、失敗することを前提に、つくっては壊すことをよしとする文化も大切です。
     ⇒ 失敗する前提は一番難易度が高い、利益至上主義との熾烈な闘いが必要かも、内外からのプレッシャーを受け入れ、解消してくれるマネジメントの強力なサポートが必要

  • ソフトウェアファーストで最も大事なこてゃ、変化しないものを理解することです。つまりビジョンやミッションであり、それに関連する社会課題や価値観です。

  • アジャイルやDevOpsはあくまでも手段、ユーザードリブンなマインドが不可欠、この目的意識をチーム全体に浸透させることが、ソフトウェアファーストを実践する最初の一歩です。

  • エンジニア、レビュアー、QAのみんなが同じプロダクトチームになると、必然的にブラックボックスだった箇所が減っていきます。

  • 日本企業が変化に乗り遅れ、世界市場で存在感を失う状況に陥る理由は大きく三つ
    要因1:ITを「効率化の道具」と過小評価
    ・効率化や省力化だけがITの可能性ではありません。
    ・ITには既存産業のルールを壊し、新たなビジネスに作り替えるだけのパワーがあります。これにいち早く気付いたのが米国の企業群でした。
     
    ・日本企業の多くは、正常性バイアスによって過去の成功体験にとらわれ、モノづくりこそが日本の「正業」であり、ITは「虚業」という誤った認識をもってしまったのではないでしょうか?

  ・事業会社がじそうできるようになったら、デジタルトランスフォーメーションに対する外部からの支援は終了となります。デジタル・トランスフォーメーションの本質を突き詰めていくと、SIerは関連する案件をやり続けることで自らの存在価値を最小化していくことになるのです。

問題提起:ITの価値を誤認した結果、自社にIT活用のノウハウが蓄積されない「SIer丸投げ文化」が形成されてしまったのではないか。しかし、この構図もいずれ成立しなくなるはず

 要因2:間違った製造業信奉から抜け出せない
 ・製造業の物づくりとソフトウェア開発の違い
  製造業: 企画⇒先行開発(試作)⇒製品開発(量産設計)⇒製造⇒販売 ※手戻りが許されない
  ソフトウェア開発(特にSaasの場合): 企画⇔PoC(試作)⇔設計⇔開発⇔運用 ※手戻り発生が前提

 ・製造における生産性と品質支えているのが生産技術、これはソフトウェア開発では「開発基盤」と考えることができます

 ・日本企業はソフト愛和を「設計パターンに従って複製可能な工業製品」とみなし、米国企業は「ビジネスであり商売の重要な武器」、欧州企業は「ソフトウェアの標準化に代表される美」 を体現するものとして捉えている。 *
 
 ・問題提起:日本企業はソフトウェア開発をレバレッジの効くビジネスとしてではなく、工業製品のようにとらえたため、イノベーティブなソフトウェアを生みだせなかったのではないか?
 
要因3:サービス設計運用面で誤解
・狩野モデルで考える間違った品質追求の愚
 イノベーティブなプロダクト開発を考えるときに重視すべきは魅力的品質であり、一元的品質です。魅力的品質は当たり前品質に変質可能です

・日本企業のプロダクト開発は、当り前品質を高めることが唯一の道だと信じ込み、魅力的品質を磨くことを怠っている

・現実に即していない情報セキュリティポリシー

・データ活用に感じる二つの違和感
  データへの期待が先行しすぎ、収集するデータの種類と用途を考えずに集める
  ユーザーのプライバシーを踏まえ、データ収集、ユーザー体験設計、データ活用を考える人材不足

問題提起:多くの日本企業がITを使ったイノベーションを起こせていないのは、品質管理やセキュリティ施策のやりかたが画一的だったり過剰になっているため、ユーザーが本当に欲しいものを追求できていないからではないか

  • ITサービスで存在感を示すためのアイディア

 ・フィジカル*サーバー領域の新規事業

 ・現在の製造業の典型的な姿は、製品の販売後はユーザーとの関係は薄れ、製品の利用状況の把握もせず、再びユーザーとの関係が生じるのは製品の買い替えか、新たな製品の購入を検討した時だけとなります

 ・プラットフォームを構築せよ
最初の一歩は特定の領域、またはごく少数の企業が確実に使えるものを提供するバーティカルなサービスづくりから始めるべきだと考えています。領域によっては、素早く汎用化を進めない限り、より大きな汎用プラっとフォーマーににも困れてしまう危険性がある

 ・課題ありきで物事を考える習慣がないと、開発中にエンジニアがコードを各ことを目的化してしまい、オーバーエンジニアリングになってしまうという問題も出てきます。課題の解決法は常に戦略、技術、オペレーションという3つの観点で考えなければなりません

nuanfenglsr
開発推進と企画にフォーカスしながら、事業を支えることをミッションとするチームを率いるマネージャー、 常にプロダクトマネージャーのマインドセットで物事を考えていることを心かけています
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした