＿・）つかまん （@tsukaman）
 https://bit.ly/pfem14_tsukaman 
 下手な強制、ダメ！絶対！ 
 「ガードレール」を「檻」にさせない 
 "ガバナンス"の取り方とは？ 
 

＿・）つかまん （@tsukaman）
 下手な強制、ダメ！絶対！ 
 「ガードレール」を「檻」にさせない 
 "ガバナンス"の取り方とは？ 
 非常に出オチ感の
 あるタイトルで
 申し訳ない…
 

＿・）つかまん （@tsukaman）
 下手な強制、ダメ！絶対！ 
 「ガードレール」を「檻」にさせない 
 "ガバナンス"の取り方とは？ 
 

バズったからって こういう安直な提案は するな！& 乗るな！ ＿・）つかまん（@tsukaman） https://bit.ly/CNDF23-PFEM4-TKMN インフラSIおじさんが贈る 前回PFEM登壇時の資料 
 （PFEM #4 福岡回）
 

バズったからって こういう安直な提案は するな！& 乗るな！ ＿・）つかまん（@tsukaman） https://bit.ly/CNDF23-PFEM4-TKMN インフラSIおじさんが贈る 前回PFEM登壇時の資料 
 （PFEM #4 福岡回）
 今回もだいたい
 ノリとしては同じです
 

PFEMの過去セッションが探しやすくなりました 
 6 ● 今まではConnpass開催ページから辿る必要がありました
 ● 現在は公式ページから各回セッションを簡単に視聴できます
 ● 公開されている資料も一緒にご覧頂けます
 https://www.cnia.io/pfem/events/ 
 

自己紹介
 7 ＿・）つかまん / 塚本 正隆 / @tsukaman ● 所属
 ○ レッドハット（株）- ソリューションアーキテクト（技術営業本部 公共・コーポレート事業部） 
 ● 経歴
 ○ 伊藤忠テクノソリューションズ（株）- 教育事業部（営業、講師、新人研修PM）− 13年 
 ○ 日本ヒューレット・パッカード（株）- WW Hybrid Cloud CoE（Solution Architect、Consultant）− 8年 
 ● 技術的経験
 ○ UNIX、Linux、OpenStack、Cloud Foundry、Ceph、Kubernetes、Ansible、vSphere 、AWS 等 
 ● 著書
 ○ Ansible実践ガイド（インプレス）、Raspberry Pi〔実用〕入門（技術評論社） 他 
 ● 好き
 ○ 音楽活動、合気道、眼鏡、漫画、ゲーム、ものづくり、ガジェット、コミュニティ活動 
 

CNDW2025のプロポーザル募集してるよ！ 
 8 https://cloudnativedays.jp/posts/cndw2025-cfp 
 

CNDW2025のプロポーザル募集してるよ！ 
 9 https://cloudnativedays.jp/posts/cndw2025-cfp 
 さてそろそろ
 本題へまいりましょう
 

10 10 なんでこんなテーマを話すのか 
 

なんかこんな話がありそうな気がしたからです 
 11 シャドウITを無くしてセキュアな開発体制を構築し、ガバナンスを効かせながら 開発効率を向上させるならプラットフォームエンジニアリングが最適です！！！ IDPを導入することにより、セキュアなゴールデンパスを開発者に提供できま す！！！！！このゴールデンパスにはあらかじめ統制をかけるべき事項が盛 り込まれていますので、開発者の認知不可を軽減させて高い生産性を安全に 創り出せます！！！！！！！！！！！
 

なんかこんな話がありそうな気がしたからです 
 12 シャドウITを無くしてセキュアな開発体制を構築し、ガバナンスを効かせながら 開発効率を向上させるならプラットフォームエンジニアリングが最適です！！！ IDPを導入することにより、セキュアなゴールデンパスを開発者に提供できま す！！！！！このゴールデンパスにはあらかじめ統制をかけるべき事項が盛 り込まれていますので、開発者の認知不可を軽減させて高い生産性を安全に 創り出せます！！！！！！！！！！！
 一見、とても
 それっぽい
 

基本に立ち返って考えよう 
 13 ➔ そもそもなんでPlatform Engineeringが必要なのか？ 
 ◆ あれでしょ？ 開発者の認知負荷が高すぎてモータイヘンなのをなんと かするためでしょ？
 ➔ それも大事な側面だけど、認知負荷を下げることだけが本質的な 目標なのかな？ 
 ◆ いや、開発者が本来のお仕事である「価値のある開発作業」に集中す るため・・・かな？
 ➔ じゃあゴールデンパスをもつIDPを導入すれば、開発者の認知負 荷はなくなって、質の良い開発ができるようになる？ 
 ◆ できる気もするし・・・でも、それだけで素直に新しいプラットフォームを 使ってくれるかな・・・使ったらホントに効率ってあがるのかな・・・あれ ・・・あれれ・・・
 

モノにだけとらわれ過ぎないようにしよう 
 14 ● Platform Engineeringにとって、プラットフォーム自体はとても重 要な要素なのは間違いない 
 ○ しかし、ツールや技術だけにとらわれ過ぎると、本質を見失います
 ● 良いモノを用意したからと言って、強制的に使わせようとしても人 はついてきません 
 ○ そうして死んでいったプラットフォーム（共通基盤）の話、散々聞きまし たよね？
 ● 認知負荷だ、開発効率だと、大義名分を掲げてみても、裏にある 「提供側の願望」が透けてると、信頼を得られません 
 ○ 気持ち良く使ってもらってこそのプラットフォームであり、それだからこ そ、質の良い開発が実現します
 

紹介したい資料があります 
 15 ● 「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由 
 ○ 2024年開催「OpenShift.Run」における @jacopen さんの資料 
 ■ https://speakerdeck.com/jacopen/gong-tong-ji-pan-wochao-eyo-jin-platform-enginee ringniqu-rizu-mubekili-you 
 

紹介したい資料があります 
 16 ● 「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由 
 ○ 2024年開催「OpenShift.Run」における @jacopen さんの資料 
 ■ https://speakerdeck.com/jacopen/gong-tong-ji-pan-wochao-eyo-jin-platform-enginee ringniqu-rizu-mubekili-you 
 今日話したいこと
 だいたい全部
 書かれてます
 

もうひとつ、ご紹介させてください 
 17 ● 技術がなければ作れない、必要がなければ存在している資格がない - Platform Engineering: A Guide for Technical, Product, and People Leaders の読書感想文 
 ○ nwiizoさんのBlog「じゃあ、おうちで学べる」における2024年10月25日の投稿 
 ■ https://syu-m-5151.hatenablog.com/entry/2024/10/25/060600 
 ● Platform Engineeringの本質を捉えた実践的ガイドとして、技術 リーダーから上級管理職、またPEのもたらす価値について学ん だり、導入/移行に関心を持つ全ての人に向けて書かれた本 
 ● Platform Engineeringの組織的/戦略的な側面により焦点をあて ている
 ● nwiizoさんのこれまでの経験に基づいた見解も述べられている良 記事です（日本語で読めるのありがたい・・・）
 

18 18 ここでちょっとクイズです 
 

どちらをつくるべきですか？ 
 19 VS
 Paved path 
 Railway 
 

そんなんケースバイケースじゃよ 
 20 ● 舗装路にも、鉄道にも、それぞれの良さがあります。 
 当然、それぞれに注意点もあります。 
 ○ Paved Path (舗装路) 
 ■ 自由で気持ち良く走れる（開発できる） 
 ■ 経路を変更もできる
 ■ 基本的にハンドルは自分で握って運転 
 ○ Railway (鉄道) 
 ■ 乗ってしまえば後はお任せ
 ■ 安定して大量の輸送ができるよ 
 ■ 決められた時間、決められた経路に従わなければいけない 
 ● どちらかに限定して考えるのではなく、ユーザーの状況に応じ て「本当に求められているもの」をつくるべき 
 

このふたつの違いってなんでしょう？ 
 21 VS
 

本質的には似たようなものなのかも 
 22 ● ガードレールと檻、役割が違うだけでどちらも開発者（と所属し てくれる組織）を守ってくれるモノです 
 ○ ガードレール 
 ■ 運転中に安全な範囲に留めてくれる 
 ■ ガードレールの内側なら事故は起こらない？ 
 ■ ガードレールは防御してくれるもの？ 
 ○ 檻
 ■ 一見、不自由と不幸の象徴の様にみえる 
 ■ 安全や安心が保証される環境であったら？ 
 ■ 求めるものが檻の中にあれば十分では？ 
 ● 制約が仮にあったとしても、価値を利用者に理解してもらえれ ば、利用に繋がるはずです 
 ○ ただし、独善的な価値に陥らないことが大前提
 

あなたの意見や考えや感覚で決めていませんか？ 
 23 ● 何にでも当てはまる「正解」なんてモノはありません 
 ○ どこかの事例、だれかの意見、またはあなたの思い込みだけで進めても、 使われないプラットフォームができあがるだけです
 ○ 銀の弾丸はないのです（言いたいだけ）
 ● これがあればいい、という危ない思考に陥っていませんか？ 
 ○ ツールや技術はとても大切ですが、それだけでは足りません
 ○ どんなものを作ったしても、押しつけてしまえば役に立たないで終わるかも 知れません
 ○ 利用者にとっての価値のあるモノを作れていますか？
 ● 向き合うべき人に正しく向き合えていますか？ 
 ○ プラットフォームの利用者=開発者の声を正しく聞いていますか？
 ○ 聞いた声をもとにプラットフォームを正しく作り続けていますか？
 

24 24 説得するな、納得させろ 
 

ガバナンスは悪ではない 
 25 ● 開発者自身と組織そのものを守るためのもの 
 ○ 多くの利用者が統制や安全性の意義は理解してくれるはず 
 ● 制約と利便性のバランス（妥協点）を見つけ出すことが重要 
 ○ プラットフォームの改善により、より高いレベルでの両立を目指す 
 ● 結局はコミュニケーションの問題かも？ 
 ○ 透明性にの高いコミュニケーションと相互理解の実現 
 ○ 意見が伝わっていると感じられるか 
 

良好なフィードバックを得るために 
 26 ● 利用者の声を正しく聴きとるための仕組みを用意しましょう
 デベロッパー 
 アドボケイト 
 プラットフォーム 
 サポート 
 アンケートや 
 インタビューなど 
 ● 開発者を支援する役割
 ● 連絡役としてプラットフォーム の周知や利用促進のための 活動を行う
 ● 開発者の意見やニーズを修 してフィードバックする
 ● プラットフォーム利用にあたっ ての課題や問題を解決する
 ● 問題の解決と合わせ、ユー ザーからのフィードバックを収 集する
 ● 定期的なアンケートやサーベ イの実施
 ● コミュニティの運営
 ● 1on1 インタビューの実施
 ● フィードバックセッションの開 催 など
 

ロードマップへの反映 
 27 ● フィードバックは「ループ」になっていなけれ ば意味が無い 
 ○ フィードバックの放置は、とても簡単に信頼を 失わせる
 ○ 集めた声を正しくプロダクトとしてのプラット フォームに反映していく
 ○ 透明性の高いロードマップの策定手法を確 立しましょう
 ● ステークホルダーのコントロールも重要 
 ○ 利用者の満足度だけが全てではない
 ○ エグゼクティブや各種プラットフォームの担 当者など、多彩なステークホルダーが持つ 目標にも配慮が必要
 ○ それぞれの目標のアライメントをとっていくこ とも「Platform Engineering」の重要な一面で す
 https://www.cnia.io/pfem/sessi ons/pfem-03-03/
 

28 28 まとめ
 

そこに愛はあるんか？ 
 29 ● 愛されるプラットフォームを目指す 
 ○ 使われてこそのプラットフォーム
 ○ 愛されるプラットフォームは生産性を向上させる
 ○ 生産性を推し量る1つの指標になりうる
 ● 愛の根底には信頼ありき 
 ○ 派手でなくても、安定して、仕事を確実に実行するツール
 ○ 時には信頼されていることが表からは見えないときもある
 ○ エグゼクティブ層からの信頼を得ることも重要
 ● プラットフォームチーム側からも愛を 
 ○ 利用者の真のニーズが何であるかを真摯に追求し続けているか？
 ○ 自らのKPIに注力しすぎて偏った施策になっていないか？
 ○ 正しいコミュニケーション をとるべく努力しているか？
 

そこに愛はあるんか？ 
 30 ● 愛されるプラットフォームを目指す 
 ○ 使われてこそのプラットフォーム
 ○ 愛されるプラットフォームは生産性を向上させる
 ○ 生産性を推し量る1つの指標になりうる
 ● 愛の根底には信頼ありき 
 ○ 派手でなくても、安定して、仕事を確実に実行するツール
 ○ 時には信頼されていることが表からは見えないときもある
 ○ エグゼクティブ層からの信頼を得ることも重要
 ● プラットフォームチーム側からも愛を 
 ○ 利用者の真のニーズが何であるかを真摯に追求し続けているか？
 ○ 自らのKPIに注力しすぎて偏った施策になっていないか？
 ○ 正しいコミュニケーション をとるべく努力しているか？
 恋愛をするように
 仕事をしよう
 （とある上司の教え より）
 

ご清聴ありがとうございました
 PEK2025現地でﾏｯﾃﾙﾖ!