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

ソフトウェアファーストな時代における開発の変化

 ソフトウェアファーストな時代における開発の変化

More Decks by Masahiko Funaki(舟木 将彦)

Other Decks in Technology

Transcript

  1. 2 舟木 将彦(@mfunaki) CircleCI合同会社 Developer Advocate ビジネスを支えるソフトウェアの マーケット変化適応力を高める のに不可欠な CI(継続的インテグレーション)

    CD(継続的デプロイメント) の意義や価値、進め方を 技術、ビジネス、経営の言葉で お届けする 2013~18 Customer Innovation Principal (Black Belt) • 150社以上とデザイン思考を ベースにしたワークショップ~ ソリューション実装 (デザイン思考の総本山 Stanford Univ. d.school開校時に 39億円の資金を提供したのが SAP創業者の Hasso Platner) 2018~20 Chief Digital Advisor • 自動車や金融、小売業、テレコムを 主にクラウド+AI+VR/MRでの 協業(新規共同開発等)を支援 自己紹介 時間をかけた計画先行でもなく、重複等の無駄の多い開発先行でもなく、 計画と実装の間の時間差少なく、らせん状に前進
  2. 3 本日のアジェンダ お話の流れ 1. CircleCI会社ご紹介 2. DXアプローチのストッパー 3. 新たな取り組みを継続させる鍵 結論

    ベストな開発チームメンバーは、 選抜メンバーの中だけにいるのではない。 手を上げたい様々な人が、 自由に・安全に (壊さない、壊れない、責められない) 継続的に手を挙げられる仕組み(文化)を 支える「ツール」が必要
  3. 10 先進的な事例を集める、適用可能性をPoCする なぜストッパーなのか • PoC(概念実証)で検証すべきポイントは出てきても、 1) 実運用相当の(デジタル)データが なかったり、2) 何を達成したら事業に向けて継続するというKPIが定義できない。 その結果

    • サンプルデータでの(良好な)検証結果が受け入れられなかったり、 実データでの検証で出てきた課題が乗り越えられるのか検証されなかったり、 一定の成果を達成しても、そこがゴールになってしまい、先に進まない 事例 • 多数
  4. 11 多様な人たちの多様な観点でワークショップ実施 なぜストッパーなのか • 多様な人たち(いろんな視点で観察、アイデア出し、プロト作成、事業化 )を集められない、 ファシリテーターを用意できない、事業化 KPIが事前に設定できない その結果 •

    ワークショップを開催しなくても机上で出るようなアイデア出し大会に留まる、多様性から 来る発散力も、一般化・抽象化することによる収束力も、目線を変えるリフレーム力もな い、祭りの後、継続的にバージョンアップする仕組みがない 事例 • 小さな赤ちゃんの世話をしていても、ママはスマホスーパーで簡単お買い物 →ママが欲しかったのは「自宅で子供と2人きり、煮詰まってしまう状態からの  脱出、つまり子供が泣き出しても白い目で見られずに買い物でき、気分も  リフレッシュできる実店舗」
  5. 12 実は 1, 2ができているような会社であれば • PoCの結果をもとに、課題を洗い出し、さらに先に進めることのできる人材も、 • アイデアをもとにプロトタイプやMVP(Minimum Viable Product:

    顧客に価値 を提供できる最小限の製品)を作り出せる人材も、 • プロトタイプやMVPをユーザにぶつけて、ユーザを観察して、「真の欲求」を見 つけ、反映させられる人材も、 いるが、 「手を挙げる仕組み」「引き継ぐ仕組み」= (ほかの人が)継続性を支える仕組み がない
  6. 15

  7. 16 全部を内製しない: バイモーダルIT ハードウェアであっても Powered by Software な時代、 ただし、すべてを内製しない。 モード1

    変化が少なく、 確実性・安定性を 重視 モード2 開発や改善スピー ド、利便性を重視 ゴール 差別化→ 利益拡大 効率化→ コスト削減 手段 DevOpsによる 内製 (現場ニーズ 迅速に反映) 既製品を そのまま使う (自動更新) 適用業務 顧客との 関係性が 必要な領域 会計 人事 生産管理... (ERP領域)
  8. 17

  9. 18 継続するビジネスを支えるソフトウェア開発を標準化 プラン コード ビルド テスト リリース デプ ロイ 運用

    監視 継続的インテグレーション (CI) 継続的 デプロイ (CD) 自動化できない 非正常系は 自動化できない 自動化できる→継続的であるために自動化すべき ビジネスが継続する限り、プロジェクトは続く コード追加・修正時は 常にビルド・テスト (最後にまとめてやらな い→早く失敗すれば 早く品質が安定する) サービス停止せず常に リリース/デプロイ (失敗時にはクイックに 修正 / 前バージョンに 戻せる)しくみ 人にしかできない ことは、 細分化した上で できる人が 手を挙げてやる →属人化させない 共有 リポジトリ上 で 常に作業 自動化できる ことは 作業手順の 定義を行い 自動実行させる →依頼しない、 抜け漏れしない 運用・監視しやすい 品質をコードに反映 (必要なデータの取得、 スケーラビリティの 確保)