下手な強制、ダメ！絶対！ 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは？

2025/09/08(月) 開催のPlatform Engineering Meetup #14における登壇資料です。
---
【トーク概要】
プラットフォームの力により開発者の認知負荷を軽減し、開発生産性を向上させることがPlatform Engineeringの大きな目的です。このプラットフォームでは開発者が意識をしなくとも、セキュリティやガバナンスが考慮されたガードレールに守られたゴールデンパスが提供されます。つまり、開発者は認知負荷を高める事なく、安心で安全な環境で思いっきり開発ができるわけです。

しかし、ここのガードレールを履き違えてしまうケースが散見されます。

ガバナンスを効かせることを優先してしまい、開発者を守るためのガードレールが、逆に開発者を縛り付ける制約の檻となるのです。これでは開発生産性は高まるどころか、逆に大きく下がってしまうでしょう。

本セッションでは、このような制約を強制するアンチパターンに陥らないために、どのような考えや手法を用いて統制をとっていくべきかをご紹介します。

Transcript

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

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

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

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

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

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

7. 自己紹介
 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〔実用〕入門（技術評論社） 他 
 • 好き
 ◦ 音楽活動、合気道、眼鏡、漫画、ゲーム、ものづくり、ガジェット、コミュニティ活動 

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

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

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

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

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

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

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

15. 紹介したい資料があります 
 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. 紹介したい資料があります 
 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. もうひとつ、ご紹介させてください 
 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 18 ここでちょっとクイズです 

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

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

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

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

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

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

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

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

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

28. 28 28 まとめ

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

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

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