コンテナ共創センター勉強会#23 公開資料①

1. OpenShiftで実現する
プラットフォーム・エンジニアリング
におけるDevSecOpsの価値

2. 本セッションは個⼈の⾒解であり、 所属組織の⽴場、戦略、意⾒を代表するものではありません。
また、技術的な内容にも⾔及しますが、正確性を保証するものではありません。

3. ｜プラットフォーム・エンジニアリングって知ってますか？
2026年までに、ソフトウェア・エンジニアリング組織の80％がプラットフォーム・エンジニアリング・チームを
結成し、そのうち75％がセルフサービス開発者ポータルを取り⼊れるとGartnerは予測している。

4. https://platformengineering.connpass.com/event/275718/
｜とりあえず、これを観ておくと良いよ

5. 以上︕

6. とかやると、当然⽅々から怒られるので…

7. ｜今⽇お話ししようと思っていること
1. プラットフォーム・エンジニアリングって何︖
2. OpenShiftでプラットフォーム・エンジニアリングをするって︖
3. OpenShift Pipelines(Tekton)にフォーカスして何ができるか考えてみる
ようするに、
OpenShiftで使えるTekton（OpenShift Pipelines）をプラットフォーム・エンジアリングの観点で
『どう使えるか︖』、『どう使っていくのがいいのか︖』
を中⼼にお話ししていこうかなって思ってます。

8. n 2019年2⽉~ IBM中途⼊社
n 前職は⾦融系SIerで20年超のエンジニアとしてのキャリア
n 専⾨領域は「アプリ基盤」（アプリとインフラの間を取り持つ仕事）
アプリ基盤という仕事柄、アプリを⽀える仕事をずっとしてきていたので
アプリ⽣産性と管理統制を両⽴させる仕組みの構築を考え続けることが多かった。
2010年~くらい？
会社の方針でなんか使い始める。
フレームワークとか作るチームを指揮
2013年~くらい？
Immutable Infrastructure?
それ良さそう、と思って注目
2015年~ OpenShiftにフルコミット
Red Hat Summitでの出会い
ここまでくればビジネスで使えそう
Satoshi Doi
@satoshi55d
Senior Application Architect
Red Hat Certified Specialist
(ちなみに去年末失効して今はモグリです…)
IBM Japan,
Hybrid Cloud Services

9. ｜プラットフォーム・エンジニアリングの定義
厳密な定義は存在しないようだが、以下のガートナーの説明が個⼈的にはしっくりくる
• プラットフォーム・エンジニアリングは、再利⽤可能なツールとセルフサービス機能を実装し、インフラ
ストラクチャ・オペレーションを⾃動化することで、開発者のエクスペリエンスと⽣産性を向上させる
• 新たなテクノロジのアプローチであるプラットフォーム・エンジニアリングは、アプリケーションの再利
⽤可能で構成可能なコンポーネントとサービスを活⽤する
• ユーザーにとっては、標準化されたツールとコンポーネント、そして⾃動化されたプロセスを利⽤できる
というメリットがある

10. ｜共通基盤ってうまく⾏ったことありました？
過去には複数のシステムをまとめて管理する基盤を作り、その上で同じようにシステムを
作っていけば効率的なのでは︖として数々の共通基盤が作られ、そして死んでいった。
みんな私の⾔う通りにやってね。
（べき論の押し付け）
勝⼿にやっちゃダメよ。申請してね。
（数週間〜数ヶ⽉の待ち時間）
中央集権的に⾜並みを揃え
て上⼿くいくことといかな
いことがあるのでは︖
何やるのも遅すぎるよ…
べき論はわかるけど、うち
はそんな成熟度に達してな
いから開発者がついてこれ
ないよ…
とにかく中央集権、勝⼿は許さん 僕の考えた最強のシステム

11. ｜ならばセルフサービスだ！Kubernetesだ！
出典: https://twitter.com/memenetes/status/1637861860039876624?s=20

12. ｜ならばセルフサービスだ！Kubernetesだ！
出典: https://twitter.com/memenetes/status/1637861860039876624?s=20

13. ｜ならばセルフサービスだ！Kubernetesだ！
出典: https://twitter.com/memenetes/status/1637861860039876624?s=20
圧倒的学習コスト
開発者任せで上⼿くいく未来、想像できますか︖

14. ｜これに対処するのがプラットフォーム・エンジニアリング
顧客
インフラ
アプリ
インフラ
アプリ ・・・
・・・
サービス提供
インフラとアプリをシステム毎に
個別設計・構築。非効率では？
顧客
インフラ
アプリ アプリ ・・・
管理・統制
サービス提供
インフラだけ集約してアプリチームを
管理・統制してみました。
⇨一定の効果はなくはないが、「管理」
されただけの状態で真の価値を提供できるのか？
顧客
サービス提供
プラットフォーム
アプリ アプリ ・・・
サービス提供
プラットフォームチームからみてアプリチームは
サービス提供対象のお客様として捉える。
顧客に価値を提供するためにアプリチームに対して
どんな価値を提供できるか？を考えていくこと。
⇨これがプラットフォーム・エンジニアリング

15. https://speakerdeck.com/sachiwo/enhuramoopenshifttehuratutohuomuwozuo-ritai
｜⼿前味噌で恐縮ですが… (2020年発表だからガートナー発表より早いね︕)

16. ｜さて、話変わってTektonですが、⼈気ないんですかね…
出典: CI/CD Conference 2023

17. ｜Tekton, でも便利なんですよ…
ClusterTask A ClusterTask B ClusterTask C ClusterTask D
taskRef:
Task A
↓
TaskRef:
TaskB
↓
TaskRef:
kind: ClusterTask
Task A
pipeline A
taskRef:
kind: ClusterTask
Task C
↓
TaskRef:
kind: ClusterTask
Task D
pipeline B
Task A
Task B
namespace namespace
クラスタ提供者
クラスタ利⽤者A クラスタ利⽤者B
特殊なPipelineであれば各
Taskは利⽤者が作成。部分的
にClusterTaskを使⽤して省⼒
化。
⼀般的なPipelineであればTaskを作る
必要がなく、⽤意されたClusterTask
を並べるだけで作成できる。
ClusterTaskはクラスタ提供者
が作成して登録することも
できる。
TaskとしてPipelineの各処理をパーツとして使いまわせる、そして何よりClusterTaskを
作って利⽤者に公開すればパーツを組み合わせるだけでPipelineが作れる︕

18. ｜Tekton, でもでも⾯倒くさいんですよね
+ + + +
①CI/CDフローの箱一個ごとにyaml + コンテナ作る
②そしてそれぞれを呼び出す
フローをyamlでまた書く
Yaml Hell !!
üこれはCI/CDフローのタスクを使い回しできるように、タスクごとの独立
性を担保して依存を断ち切るために非常に有用な仕組みで、Jenkinsの課題
を解決できる。
üでも辛いものは辛い。
これらを準備してフローを回すまでのハードルが高い。学習コストが高い。

19. ｜OpenShift上⼿く使うと⾯倒臭さも極⼩化できます
GUIから簡単に
CI/CD Pipelineを払い出し
yamlテンプレートを選んで
Create押すだけ
開発者に対してのサービスとして提供したいパイプラインを登録、払い出しができる。

20. ｜Demo: 例えばこんなパイプラインを作るとして…
クラウド
環境
Openshift
（開発）
Dev Team
(Eclipse, VSCode)
Git(Local)
Openshift
（検証/本番/その他）
クラウド環境
Manifest
Repository
External
Registry
Webclient
Build
SonarQube
Analysis
Image Build
custom
Base Image
Base Image
TEST: any tool
Internal
Registry
PostgreSQL
Databases
custom
Base Image
Webhook
or
Import
Source
Build
Test Tool
Pod
Pod
App
Job
Ops Team
Pull
Job Trigger
deploy
Internet
Public Image Catalog
(DockerHub,
Operator.Hub)
RedHat Container
Catalog (RHCC)
Base Image
Internal
Registry
Pod
App
Deploy
(開発)
Push
image
Test
Import
image
deploy
Application
Repository
Source code
Detect
/Pull
DEPLOY
⼿動開始
Deployment
Manifest
Release
Entry
Push
image
Import
image
Library
Repository
Update
or
ITAC(IBM)
環境管理
Build
Pod
Build
SonarQube
Pod
Deploy
(本番)
Deployment
Manifest
① ②
配布資料ではデモは割愛させていただきます。

21. ｜DevSecOpsの複数の側⾯
セキュリティ
個々人との
対話
チーム間の
関係性
ツール スケール
DevOps
DevSecOps
DevOpsの四つの柱(※)とDevSecOps
※ 出典:「Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅」
仕組みとしてカバーできる範囲
DevOps/DevSecOpsは⼈や組織、⽂化的側⾯が強くハードルが⾼く感じるかもしれない
が、ツールなどを使ってまずは何ができるか、何が良くなるかを試してみるのが⼤事。

22. ｜ Reference Architectureに加えてValidated Patternを提供できる
まずは試そう、となった時に学習コストが⾼ければそこで頓挫してしまうことだってある。
だから、使いやすく、低学習コストなサービスを「開発者」に提供することでハードルを下げる。
クラウド
環境
Openshift
（開発）
Dev Team
(Eclipse, VSCode)
Git(Local)
Openshift
（検証/本番/その他）
クラウド環境
Manifest
Repository
External
Registry
Webclient
Build
SonarQube
Analysis
Image Build
custom
Base Image
Base Image
TEST: any tool
Internal
Registry
PostgreSQL
Databases
custom
Base Image
Webhook
or
Import
Source
Build
Test Tool
Pod
Pod
App
Job
Ops Team
Pull
Job Trigger
deploy
Internet
Public Image Catalog
(DockerHub,
Operator.Hub)
RedHat Container
Catalog (RHCC)
Base Image
Internal
Registry
Pod
App
Deploy
(開発)
Push
image
Test
Import
image
deploy
Application
Repository
Source code
Detect
/Pull
DEPLOY
⼿動開始
Deployment
Manifest
Release
Entry
Push
image
Import
image
Library
Repository
Update
or
ITAC(IBM)
環境管理
Build
Pod
Build
SonarQube
Pod
Deploy
(本番)
Deployment
Manifest
他社事例、他チーム事例でこんな感じでやってましたよ、これがBest Practice
ですよといったReferenceとなるArchitectureは有用ではあるけれども…
Reference Architectureが実際に動くものとして払い出せると
もっと素敵だと思いませんか？
当然、使い慣れてきたら自分なりのカスタマイズも可能。
＋
Reference Architecture Validated Pattern

23. 顧客
サービス提供
プラットフォーム
アプリ アプリ ・・・
サービス提供
｜ プラットフォーム・エンジニアリングの観点で考えてみる
• プラットフォーム・エンジニアリングは、再利⽤可能なツールとセルフサービス機能を実装し、
インフラストラクチャ・オペレーションを⾃動化することで、開発者のエクスペリエンスと⽣産
性を向上させる
• 新たなテクノロジのアプローチであるプラットフォーム・エンジニアリングは、アプリケーショ
ンの再利⽤可能で構成可能なコンポーネントとサービスを活⽤する
• ユーザーにとっては、標準化されたツールとコンポーネント、そして⾃動化されたプロセスを利
⽤できるというメリットがある
再掲: ガートナーのプラットフォーム・エンジニアリングについての説明
簡単にセルフサービスで使える良いもので開発がしたい。
⾯倒な⼿続きで時間を取られたくない。
⾃社として標準化して統制が取れた状態でアプリチームの
創意⼯夫を阻害しない状態で提供したい。

24. ｜ ほら、プラットフォーム・エンジニアリングしてませんか？
簡単にセルフサービスで使える良いもので開発がしたい。
⾯倒な⼿続きで時間を取られたくない。
⇨GUIでポチポチして開発者が好きなように払い出し
⾃社として標準化して統制が取れた状態でアプリチームの
創意⼯夫を阻害しない状態で提供したい。
⇨Validated Patternとして標準化したものをセルフサービス
で提供

25. ｜ まとめ
• プラットフォーム・エンジニアリングは開発者に対して（その先の顧客に対して価値を届け
るために）どのようなサービスを提供していくかをエンジニアリングすること。
• ⼀部の強者が作る、「俺が考えた最強のプラットフォーム」ではなくそれを利⽤する開発者
の成熟度に合わせて、共に進化していくことも視野に取り組む社会的活動でもある。
• Tekton便利だけど⾯倒くさい（学習コストが⾼い）を解消し、開発者に対して有⽤なサー
ビスとして提供できる仕組みがOpenShiftにあるので使ってみると良い。
• Tektonの例のように開発者に対するサービス、という観点で他にも様々な⼯夫がOpenShift
ではされているので⾒てみてください︕（私の過去スライド参照）
プラットフォーム・エンジニアリングに寄与できる便利機能がたくさんある。

26. ｜ 最後に宣伝
本⽇お話しさせていただいたような内容をサービスとして提供したい、という想いで
現在も進化しながら提供させていただいているのが弊社デジタルサービス・プラットフォーム。
https://www.ibm.com/resources/consulting/jp-ja/digital-service-platform/
プラットフォーム・エンジニアリング興味出てきた︕やりたいけど何からやれば︖
みたいな時にお声がけください🙇