なぜSIerは自動化するのか/Why do SIers automate?

Transcript

1. なぜSIerは自動化するのか Automation Journey @2020/03/25
2. --- name: "Daiki Yamaguchi" company: entry_year: 2012 department: シス基 TB基盤 hobby: - ゲーム - 勉強 like: - あんでぃー @answer_d (裏の顔) インフラエンジニア9年生
3. 自動化 してますか？
4. 自動化 is 何
5. 本日の目的 • 「自動化」とは何か知る みんなで1歩踏み出せるようになりましょう！ • 自動化が作る未来を知る • これからどうやって歩めば良さそうか知る
6. アジェンダ • 日本のIT業界に起きている変化 • 人間 vs 機械 • 自動化のはじまりと発展 • 自動化が作る変化への強さ • DevOps/DXとの関連 • これからの歩き方
7. 経済産業省「IT人材の最新動向と将来推計に関する調査結果 ～報告書概要版～」 http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_report_summary.pdf
8. これから私たち、どうなっちゃうの～？ • 既存システムの運用対応はそのまま残る(むしろ増加？) • 技術の高度化でやることが増える • より素早い機能追加/改善が必要 • 残業規制はより厳しく 現状で手一杯 もはやなりかけ？
9. 「人は増えない、需要は増える」 どう対処する？ 単位時間あたりの生産性を上げる
10. 非機能要件 人間 機械 可用性 壊れたら動かない、冗長化不可 冗長 性能 ◦秒/step ◦ミリ秒/step 信頼性 指示通りに作業を実行しないリスク プログラムにより指示した通りに作業を遂行 拡張性 手順書または口頭による指示を超高度なAIが解釈 し、自動的に機能を拡張 処理追加分のプログラム実装が必要 運用・保守性 稼働時間 8～12h/日 24h/365d 計画停止 土日祝日 なし 稼働率 3日+α/年のペースで非稼働 監視不可能なパフォーマンス劣化あり 99% バックアップ なし あり 監視 目視、たまに自動報告機能あり エラー時自動通報(メール/チャット) 移行性 ドキュメント、口頭 ツールによる移行機能あり セキュリティ 指示と自己蓄積された情報に従って担保しようと する、たまにサボる 実装次第で自動担保可能 人間 vs 機械
11. 生産性向上のアイデア 機械への 作業のオフロード
12. 従来の作業プロセス 設計書 手順書 テスト 仕様書
13. 自動化のはじまり 設計書 手順書 テスト 仕様書
14. 自動化の発展 • IaC：Infrastructure as Code • コードでインフラを構成管理する発想 • インフラ構築そのものを機械にオフロードできるように 機械がインフラを管理する時代へ
15. 自動化の発展 │ playbook.yml │ ├─roles │ ├─XXX │ └─YYY └─tests verify.yml 設計書 手順書 テスト 仕様書 構築コード実行 テストコード実行 人間の作業 機械の作業 コード化 IaC Ansible ジッコウ
16. ところで… • 従来のインフラ構築プロセスは変化に弱い！ • 構成が変わらないことを前提にシステムを作り、大事にメンテナンスし て使い続けるアプローチ • 人間系、手作業主体の構築・運用 • ドキュメントベース 「変化への対応」を行う時の苦しみ
17. 変更にかかるオーバーヘッドでかすぎ問題 設計 実装 テスト 変化の要因 パッチ適用 障害対応 スケール アップ リリース 作業 • 実機と設計の乖離 • 関係者/他シス調整 • 影響調査 • 変更管理 • 設計反映漏れ • ヒューマンエラー • 設計や手順の不備 • 難しいリカバリ対応 • デグレード • 確認漏れ(サボり) 仕様変更 新脆弱性 加速する リリース 人の流動 リプレース EOL 新規技術 OSS 事業買収 「作業ルールの徹底！」 「2人作業、指差し確認！」 「チェックリスト遵守！！！」
18. そして訪れる限界 設計 実装 テスト 変化の要因 パッチ適用 障害対応 スケール アップ リリース 作業 仕様変更 新脆弱性 加速する リリース 人の流動 リプレース EOL 新規技術 OSS 事業買収
19. 自動化で変わるシステム構築のプロセス • そもそも仕様が変わらない前提がおかしいのでは？ • 「システムに求められる要件は日々変化する」という現実 • ビジネスのスピードはどんどん早くなっている • そうだ、自動化で解決しよう • IaCにアプリケーション開発で培われたプラクティスを適用 • バージョン管理 • CI/CD • TDD • ...etc • 自動化をベースとしたシステムアーキテクチャとプロセスを構築 「変化に強いシステム」
20. 変化に強いシステムの例 IaC │ playbook.yml │ ├─roles │ ├─XXX │ └─YYY └─tests verify.yml push 構築コード実行 テストコード実行 人間の作業 継続的改善 検知+自動起動
21. 変化に強いシステム + 組織文化の変革 DevOps 変化への強さが作る世界 プロセス マインド チーム観 尊敬/信頼 人
22. 目指すべき地点：DevOps • すっごいイケイケな状態 • 1日何十回！みたいな高頻度のリリース • 開発と運用(インフラ)の垣根が消失 • チームが真の顧客価値めがけて改善する文化が形成される • DevOpsなチームは • 「素早く」「間違いなく」リリースができる • システムの(無駄な)管理から解放される • 組織はより生産的な活動に人的リソースを割ける 「ビジネススピードの向上」 顧客が実現したい「DX」に必要不可欠な要素 かつSIer自身のDXでもある ＼はやくこれになりたい／
23. まとめ • 最強の労働力「機械」への作業のオフロード • 労働人口減少対策の鍵 • システムやプロセスの効率化までつながる概念 自動化 • 自動化で「変化に強いシステム」 • DevOpsで「ビジネススピードの向上」 • 人間が人間らしい活動に集中できる世界 自動化が作る未来
24. 高度な自動化やDevOpsを目指してどう進めば？ 変化を恐れず受け入れる みんなで進む • 「このツール使えば自動化する」なんてものは無い、無駄も 無理も必要 • できるだけ多くの人で負荷分散するべき • 知見を共有し合うことで組織としてのパワーが生まれる • 変革の時代は温故知新がだいじ • 新しいことを学び、良さを捉える • 積み重ねてきた歴史を無条件に信頼することをやめ、本質を考える
25. Happy Automation ! あんでぃー @answer_d DAIKI YAMAGUCHI yamaguti-dxa@nec.com 登壇者お待ちしてます(｀･ω･´)ゞ
26. Appendix
27. (出典) DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～
28. (出典) DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～
29. 2025年の崖 • 経産省さん「このままだと2025年以降の経済損失がヤバい」 経済産業省「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」 https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
30. 余談 • 「崖」という表現は国レベルで見たときの損失を指す言葉 • 企業レベルで見るとなんだろう…？ くらいで良いんじゃないですかね？(適当)
31. http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_report_summary.pdf SIerの働きは日本のIT業界にとって非常に重要
32. (出典) DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～
33. 閑 話 休 題 kan wa kyuu dai
34. インフラを管理する機械の例 コンテナオーケストレータ インフラを管理するインフラ
35. yaml yaml yaml apply いい感じの自動管理 死活監視 ルーティン グ オートヒー リング オートス ケール コンテナ数 管理 人間の作業
36. DevOpsでSIerの仕事はどうなるか • 従来の「装置仕様が変化しない前提のアプローチ」から脱却 • 構築/運用の効率は向上し、属人化は減少 • 顧客のニーズはシステムに素早く取り込まれ • 高度な自動化によって人間はシステムの管理から開放 • 組織はより生産的な活動に人的リソースを割けるようになる これ、SIer自身のDXじゃね？
37. あるかもしれない勘違い Ansibleで自動化し まっしょ あぁ、作業の 自動化ね いいよ、でもシス テムに影響与えな いでね
38. あるかもしれない勘違い いいよ、でもシス テムに影響与えな いでね あぁ、作業の 自動化ね IaC導入により得られるメリットは？ • 手作業の自動化 • システムの効率化 • プロセスの効率化
39. 自動化の闇 ついでに
40. 闇1：外注文化の闇 • (多重)下請け構造はビジネススピードの向上に反発する • 会社間やり取りによるオーバーヘッド • 外注先によるスケジュールバッファ • パーキンソンの法則 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」 • これに対してどうするのか、で更に闇 • 内製化の闇 • ITベンダーが抱える商売の闇
41. 闇2：内製化の闇 • ユーザ企業さん「自社内でシステム作ればええやん！」 • でも… • そもそもSIerへの依存度が高すぎ企業はスキルや要員の不足で無理 • 今から育てられる？ • ユーザ企業は自社内に優秀なIT人材を確保したがるが… • SIerからの人材流出が加速するとSIer側の人手が不足する可能性あり • 日本のベンダー依存度の高さから考えると、業界全体のシステムモダナイズの阻 害要因となる • 最悪のケース • ～5年後、DXしたのは金のあるユーザ企業だけだった～
42. 闇3：ITベンダーが抱える商売の闇 • 「人月商売」文化がアブナイ！ • 自動化を進めると工数が減ることがある • 知見共有が上手く行ったり • 上手く自動化できた実績を元に類似性の高いシステムを作る場合 • 工数が減ると売上が下がる • 同じ仕事でも、自動化していない人(=たくさん稼働を出す人)の方が高 く評価される • いつしか自動化するためのモチベーションが働かなくなるかも…
43. 闇4：自動化実装自体には時間がかかるぞ問題 • 自動化は継続的改善を行う時にこそ大きく効果を発揮する • ということは初期構築さえ乗り切れば良いPJ形態では…？ • 自動化実装そのものがスケジュールリスクとなる • 学習含めると基本的には手作業の構築よりもコスト増の傾向 • ぶっちゃけワンショットなら手作業+ツール化(従来の自動化)の方が早い • 仕様変更や運用を考えて初めて成果が現れる類のもの • でも自動化しないと行けない状況 → 「なんちゃって自動化」の横行 • システムの効率化という観点が度外視されたアドホックな実装 • 上辺はツール使ってても、結局やってることは手作業と変わらない • そのコードが共有され、隣のPJも同じことに… • ～そして非効率なシステムが量産されていった～
44. 闇5：ローテーション人事 • 能力開発、属人化解消などのために行っている人事異動 • 「どこに異動しても使える技術」とは？ • エンジニアリングスキルではなくヒューマンスキル • マネジメント、リードなど • エンジニアリングは外注し、どこにいっても人を操ってPJをこなせる人材を作る 方が効率的だから • スペシャルなスキルを持つ要員が少なくなる • そりゃあアプリケーション開発のプラクティスが必要な自動化は推進できないよ ね？
45. 担当～主任がやると良さそうなこと • 知識習得 • コードを読み書きできないとヤバい時代が来る • これからはインフラもコードにより表現される • そしてDevとOpsの境界はどんどん曖昧になる • 「プログラミングのできるDev」と「プログラミングのできないOps」 • Opsの価値って？ • 「Ansibleはプログラミングではない」は文字的には合ってるが、基本的に嘘 • プログラミング的な知識や概念は残念ながら必要 • 体感が無いのはB2Bのシステムが「まだ」モダナイズされてないだけ • これから急速にされていくし、もしされなかったらこの会社(あるいは日本？)は 崖に落ちてる • アプリケーション開発のプラクティスも学んでいこう • IaCのメリットを享受するため • 知見のアウトプット • 組織と自分の成長の両面で役立つ、オープンマインドを信じろ
46. Pくらいがやると良さそうなこと • 自動化を取り込む場合のPJ計画/マネジメント計画の変化に対 応 • 成果物、工程管理方法、開発モデル、その他色々変わるはず • 顧客の教育 • 老朽システムのモダナイズは顧客だけでなく自分たちにも影響する非 常に重要な社会的課題 • モダナイズの必要性について長期的な目線で顧客キーパーソンと議論 • 上流工程に関わる層にしかできないこと
47. SM↑がやると良さそうなこと • 自動化した未来と現状のルールのギャップをなんとかする • 「自動化の闇」への対応 • 評価軸やビジネスモデルの変革によって組織を変える、あえて業界標 準から外れる判断
48. 今日からはじめる自動化 • 自動化のベストプラクティス：できる範囲からやる • はじめから全部を改善はぶっちゃけ無理 • 自動化できないこともある • だからこそ「選択と集中」 • 小さく始めて成功体験を積み重ねる