Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Management And Software Engineering

y_matsuwitter
September 13, 2019

Management And Software Engineering

@bit valley 2019

y_matsuwitter

September 13, 2019
Tweet

More Decks by y_matsuwitter

Other Decks in Technology

Transcript

  1. • 松本 勇気 • • 経歴 • 東京大学在学中に 社のスタートアップの立ち上げ・支 援

    • 年 入社 • にて執行役員、 、新規事業担当を経て へ • 高負荷環境のシステム設計や機械学習、 、 など新技術領域担当を歴任 • 未来を感じる技術が好きです。 自己紹介
  2. 何度でも同じ動作を繰り返す。
 • 技術力次第で、複雑度の高い振る舞いであって も繰り返し等しく動作する。
 
 スケーラビリティの獲得
 • 計算リソースとそれを活用する技術力があれば どこまでもスケールが可能。
 •

    クラウドの登場が後押し。
 ソフトウェアの挙動は全て記録できる。
 • ユーザーのアクセスや管理画面の挙動など一つ ひとつに対してログを残し分析。
 • 結果として数値に落とし込む事が可能。
 
 分散並列データ処理基盤
 • 大量のサーバを活用し分析可能に。
 • 数十億のログを全て分析にかけることができる 時代の到来。
 ソフトウェアのインパクトとは何なのか? 社会を大きく変えたソフトウェア、その強味とはなんだろうか。 反復可能性 計測可能性 同じ動作を繰り返しつつ、過程を全て記録可能することが事業に変化を与えた。
  3. とシステム システムの と の間を知るために必要なことは観測。 • ただ単にソフトウェアを作るだけでは数値化できず、 意図して記録する事が必要。 • • 可観測性とも言う。

    • システムの挙動を適切に記録し、中の構造を観 測可能にする。 • 観測が事業理解への第一歩 • 入力がどういう過程を経て出力されるか。 • 例:サービスのユーザー満足の理解、売上効率 の理解など。 観測することにより、そのシステムをより細部まで理解し、精度高く改善することができる。 事業 入力 資本、人、モノ 出力 売上・利益・顧客 数 なぜこの結果にな るのか? 観測
  4. 会社・事業と 事業は複数の要素の集合からなるシステムである。観測による科学的改善が可能になる。 事業のObservabilityを向上させることで科学的改善のフローに持ち込める。 • 事業というシステムを着実に改善する意識を持つ。 • 事業をモデル化し観測可能にするには • ソフトウェアでワークフローを構築する。 •

    全ての段階でログを残す、計測する。 • 数値として可視化する。 • 人でなくていい部分は自動化する。 • オフラインの事象も計測し自動化 • センサー導入やロボティクス 事業 ソフトウェア 分析基盤 事業モデル ログ 数値
  5. ツリーと事業のモデル化 事業をシステムとして捉え、観測可能な数値モデルに落とし込む。 • そもそもシステムとは? • 互いに作用しながら動作する複数の要素の集 合。 • 事業は、ユーザーや組織、それぞれのプロダク トやその中の画面一つひとつを要素としたシス

    テムと見ることができる。 • モデル化 • 事業の性質を理解するにはそのシステムを観 測し、数値的なモデルにする。 • これを担うのが ツリーと言える。 事業というシステムは、観測しKPIの形でモデル化されることで初めて改善が可能になる。 事業 利益 売上 コスト 人件費 広告費 どこまでも分解し計 測可能
  6. 機械学習と反復可能性の拡張 、機械学習がなぜ今必要とされているのか。 • 機械学習の価値 • 大量のデータから傾向を見出し、傾向に応じて 未知の入力に対しても推論する力。 • 大量のデータが収集・処理できるクラウド基盤の伸 展などが、機械学習によるさらなるソフトウェア化を

    もたらした。 • 人を介すること無く、特定の業務の自動化が可能に なる。 • ニュースキュレーション、広告配信、伝票の仕分 け、不良品の判別などなど 膨大なデータの中から未知のケースに対しても何度でも応答することが新しい価値を生み出している。 大量のデータ 大規模分散処理基盤 データ傾向を学習した機械学習モデル より「曖昧」な反復可能性 機械学習基盤
  7. + 0.5% - 1.5% +1.0% 数値・自動化・ソフトウェアの威力 ソフトウェア、事業のモデル化、機械学習の組み合わせが大きな進化をもたらしている。 • 科学的事業改善 •

    施策の良し悪し、効率などが事業モデルから計 算可能。 • テスト環境の構築により科学的に比較・評価 することで着実な改善を目指す。 • テストと検証の自動化 • 比較・検証すらもソフトウェア上でワークフロー 化される。 • や など。 • 事業において分析と仮説発見へのフォーカスがもた らされる。 事業を科学的に改善できる環境では、可能な限り多くの実験を行える組織が優位である。 現状 Plan A Plan B Plan C 改善幅 常に ツリーに基づき比較、効 率のよい施策に寄せていく。
  8. ソフトウェアと人の逆転 今の時代の事業づくりにおいて、ソフトウェアは切っても切り離せない。 • 人もシステムを構成する要素の一つ • 最も柔軟な動作が可能な構成要素 • 一方で最も希少性が高い要素でもある。 • まずソフトウェア的に事業設計する

    • 基軸にソフトウェアがあり、そこに人を組み合わ せていく。 • ・スケーラビリティを獲得。 • 既存事業であっても、人の活動やワークフローを分 析しソフトウェアベースに設計を理解、再構築する事 が重要。 ソフトウェアをベースに事業を設計し、そこに人が配置される。 ソフトウェア ソフトウェア ソフトウェア
  9. 人に人らしい仕事を ソフトウェアは人の仕事を奪うものではなく、変えるもの。 • 単純な作業、単一のスキルへの依存は年々自動化 される一方。 • 人にしかできない仕事とは? • 究極的には現状から課題を発見し、仮説を立案 し、未来を作り上げること。

    • 事業をソフトウェア的に捉え、設計することで、人が より人にしかできない仕事に注力する事が可能にな る。 • クリエイティビティ ソフトウェアを活用し、より人にしかできない課題発見やアート的領域へシフトしていこう。 Creative work 事務的作業 ルーティン ガバナンス Creative work ...etc Software
  10. 生産技術の普及
 • 工作機械などが発達し、誰 が作っても同様の性能が発 揮できる状況に到達
 
 規格化やモジュール化 
 • 規格を外れる製品が作れな

    くなり、どれを買って同じ性能 となっている。
 利用者から見て、十分な性能の 競合製品が多くどれを買っても効 用の変わらない状況。
 
 • 例:ガソリン
 — 現状では精製技術に大 きく差がなくなり、どこか ら買っても同様に十分 な品質で利用可能
 付加価値の付与
 • 高性能化、デザインなどによ る改善、しかし高価格化など で顧客離れなどへ。
 
 競争領域の変更
 • コモディティとならない領域に 力点を変える。
 コモディティ化という概念 ソフトウェア時代のキャリアについて、考えておくべき重要な考え方。 定義 要因 対策 コモディティ化した物は最終的に評価を落とし機会を失う。
  11. 技術のコモディティ化サイクル 技術そのものは常に進化し、 になる時代。 • や の時代 • 難しい技術やその開発力もいつか製品化されコ モディティになる。 •

    そもそもソフトウェア・エンジニアリングは高速な 規格化によるスケーリングの世界 • スタートアップの力学は技術そのもののコモディティ 化を促している。 • 技術そのものより、事業課題に解を与える事自体に 力点を置く。 コモディティにならないために、技術だけでなく事業や顧客の課題を解決する力を重視する。 新技術の登場 課題の体系化 Best Practice OSS登場 SaaS登場 スキルとしてのコモディティ化
  12. ソフトウェアで事業を設計する 職種に関わらず、事業に関わる上で必要な視点がソフトウェアエンジニアリング的思考。 自身の世界を如何に自動化・計測し改善につなげるか、その課題発見と解決能力が必要。 • 事業をソフトウェア的な発想で改善するには • 関わる仲間それぞれの仕事を理解する。 • 例:経理、契約、納品などなど •

    サービスを利用する人のことを理解する。 • 例:いつ、どの職種の人が使うのか • 人々の作業のうち、ソフトウェアで価値に集中するた めに何が必要か考える。 • その良し悪しのためにどんなイベントを計測すれば いいか考える。 事業 営業 Marketing 法務 会計 総務 労務 顧客 人事 ...etc 社会 政治
  13. ものの良し悪しを科学する
 • 定量的に表現でき、対照実 験することで初めて比較でき る。
 — この実験の手数こそが 事業やチームの強さ
 
 数値は共通言語


    • 領域横断で素早く意思決定 するためには数値でコミュニ ケーション
 高いレベルでQCDSのトレードオ フを取れる力 = 技術力
 • 技術知識だけでなく、課題を 実際に解決する力が必要。
 
 ユーザーに届け、沢山失敗する
 • ユーザーに価値を届ける コードが重要
 • そのために、沢山の失敗を 受け入れる、そのための胆 力、レジリエンス。
 領域横断的知識が求められる
 • ソフトウェア×〇〇ができる ことが重要
 — 例:会計や税務、自分 の事業ドメインなど
 
 相手の言葉で話をする
 • より良いソフトウェア化を達 成するには関わる全ての人 と連携する事が必要。
 — 相手と会話できるだけ の専門知識を。
 ソフトウェア指向な経営に貢献するために ソフトウェア的思考でプロダクト作りに関わる際に必要な、 つの視点。 広く学ぶ ユーザーに向き合う 計測し、数字で考える