これから始める顿别惫翱辫蝉
?Download as PPTX, PDF?
1 like?740 views
2019年8月24日(土)に開催されたOpen Developers Conferenceで発表したこれから始める顿别惫翱辫蝉の資料です。
これから始める顿别惫翱辫蝉
- 1. これから始める顿别惫翱辫蝉 ?1年間DevOpsをやって分かったこと? 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹(@tmiyahar) http://VirtualTech.jp
- 2. 自己紹介 ? 本名：宮原 徹 ? 1972年1月 神奈川県生まれ ? 1994年3月 中央大学法学部法律学科卒業 ? 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 ? 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 （株）デジタルデザイン、ナスダック?ジャパン上場（4764） ? 2001年1月 株式会社びぎねっと 設立 ? 2006年12月 日本仮想化技術株式会社 設立 ? 2016年ごろからDevOpsと言い始める ? 2018年から自動化やDevOpsがお仕事的に少しずつ本格化 2
- 3. 日本仮想化技術株式会社 概要 ? 社名：日本仮想化技術株式会社 – 英語名：VirtualTech Japan Inc. – 略称：日本仮想化技術／VTJ ? 設立：2006年12月 ? 資本金：3,000万円 ? 売上高：11,293万円（2018年7月期） ? 本社：東京都渋谷区渋谷1-8-1 ? 取締役：宮原 徹（代表取締役社長兼CEO） ? 伊藤 宏通（取締役CTO） ? スタッフ：9名（うち、7名が仮想化技術専門エンジニアです） ? URL：http://VirtualTech.jp/ ? 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築?運用サポート – OpenStackの導入支援?新規機能開発?運用サポート – 自動化?DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 3
- 5. 日本仮想化技術株式会社は ? 仮想化技術のエキスパート集団 ? 進取の精神 ? 豊富な検証機材で新技術を追求 ? 自由な雰囲気の職場 5
- 6. 一緒に頑張ってくれる仲間を募集中 ? サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで – クラウド技術、自動化技術に興味がある人 ? コンサルタント – 通信系に強い人大歓迎 ? インターン – 学生はもちろん、社会人も可 6
- 10. 充実の福利厚生 ? マッサージチェア ? 充実のフリードリンクコーナー – お茶、ネスプレッソなど多種多様に取り揃え ? 誕生日はケーキでお祝い ? 雑誌年間購読制度 – 何でも好きな雑誌を年間購読 ? 書籍購入支援制度 – 技術書の購入は無制限（当然） – 好きな書籍（漫画も可）を1万円／年購入 10
- 12. 今日のお話の狙い ? 技術的なベストプラクティスやはまりどころは お話しません ? インフラ系営業?コンサルタントの立場からア ジャイル開発／DevOps案件に1年以上関 わった経験をふまえて、DevOpsを始める時の コツをお話します ? ケースバイケースのことが多いので、そのあ たりは割り引いて聞いてください ? 文字ばっかりで分かりにくいところはすみませ ん 12
- 13. 弊社がDevOpsに取り組む意義 ? インフラ構築業務からの脱却 – 開発?テスト段階からプロジェクトに関与 – インフラ構築の継続的改善 ? 新しい技術への挑戦 – 自動化の本番投入 – コンテナ、マイクロサービスの実装 ? アジャイル開発への関与 13
- 14. 2018年4月 プロジェクト開始 ? 業務システムのリプレース案件 – 現行システムの速度が遅い – 新しい機能が追加できない – クラウド化してインフラ設備を更新したくない ? アジャイル開発で順次リリースしたい – 従来はウォーターフォール型開発 – スクラムにチャレンジしたい 14
- 15. チームビルディングに苦戦 ? 内製化が行えない – ≒なかなか意思決定ができない ? 外部開発メンバーがウォーターフォール型 開発経験者のみ – アジャイル、スクラムに初挑戦 – 仕様や設計が決まらないと始められない ? 自己組織化されたチームではない – 自己組織化：課題解決の方法を自分たちで決 定する 15
- 16. スモールスタートすべきだった？ ? PJ初期は意思決定と実行の速度が命 – とにかく点を取ることを目指さないと始まらない – 曖昧なままスタートして、間違ってもいい – 早く失敗して、すぐ直す ? 自由度は高くない方がよい？ – 言語、フレームワーク、ミドルウェア、CI/CDツー ル、チャット、チケット、ブランチ、テスト etc.. – 決めることが多すぎる – とりあえず適当な組み合わせでスタートして、後 から直す 16
- 17. 「適当」のむずかしさ ? 「適当」＝「right way」 – ≠「about」 ? 不確定事項が多いのですべてを決められ ない – PDCAよりはOODAの方が合ってるような？ – OODA：「観察（Observe）」「仮説構築 （Orient）」「意思決定（Decide）」「実行（Act）」 ? 素早い意思決定と実行のループ 17
- 18. Ops側から見たDevOps 反省点 ? 「早く開発始めようぜ?」状態からの脱却 – とにかく何か動かせる環境を早く提供する – 自動化は意識しつつ、とりあえず手作業で – 急遽始まった「動作環境準備祭り」 – KubernetesやCI/CDツールの効果的な使い方 はプロジェクトを進めながら覚えればよい ? Ops側もバックログを抱えながら作業 – しかし、スクラム開発のスプリント期間に合わ せるのはなかなか難しい 18
- 19. 現在のプロジェクトの状況 ? システム更改で目に見える成果が出た！ ? スプリント期間2週間でのスクラム開発 – ふり返りやプランニングを隔週で交互に実施 ? 開発、テスト、本番環境の自動デプロイ – ただし、完全に自動サイクルで廻すのではなく、 必要に応じて手動トリガーでのデプロイ実施 ? テスト自動化への着手 – Ops側で作り込みする余地が生まれるかも 19
- 20. DevOpsをスムーズに進めるには ? Dev側にインフラスキルを – Ops側にやって欲しいことが正しく伝えられる – Ops側の提案の採用可否判断ができる – チーム全員が望ましいが、無理なら1名?2名 ? 運用監視は共同で進める – Ops 6割、Dev 4割ぐらいの関与度で？ – エラー判定はOpsでは分からないことが多い 20
- 21. 最後に：やってみて感じたこと ? アジャイルやスクラム、DevOpsでやること 自体を目的化してもいい – いいからやってみたらいいんじゃない？ – やってみて分かることが多い ? 最初は無駄が多いのを覚悟の上で – なかなか手が動かせない時間がもったいな かった – でも、必要な初期コストだった？ 21
- 22. DevOpSaaSに向けて 22
- 23. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3. 優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 23 自社だけではスピード感のある DevOps推進は困難
- 24. DevOpsを始める時に悩むこと ? どのインフラを使うの？ ? どのリポジトリを使うの？ ? 情報共有方法は？ 24
- 25. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 ? 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み ? 各種ツールのバージョンアップ追従 – 既存開発?運用環境からの移行支援 ? 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど ? 開発運用担当者の教育?サポート – 標準ドキュメント、教育コースの提供 ? サンプルの提供 – 自動化?テストスクリプトのサンプル
- 26. 提供される主な機能 ? チケット管理 ? ソースコード管理 ? テスト自動化 ? デプロイ自動化 ? プロジェクトマネジメント ? コミュニケーション 26
- 27. サポートされる環境 ? 開発：GitHub/GitLab/Jenkins/Redmine – CircleCI ? 構成自動化：Ansible – CloudFormation ? インフラ：Kubernetis – AWS EKS ? 運用監視：Prometheus – DataDog ? テスト自動化：Serverspec/Selenium 27※実案件で実績あり
- 28. 改めて大募集 ? 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか？ ? 一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか？ – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 28
- 29. ありがとうございました 29