© LY Corporation © LY Corporation Public プラットフォームと チーミングと コミュニケーションと LINE ヤフー株式会社 Embedded SRE @maru in Platform Engineering の進め方とコミュニケーション ～組織の壁への向き合い方～ 1 / 32 

© LY Corporation © LY Corporation Public 先に結論 1. プラットフォームを作ると決めた瞬間、あなたが意図して組織の壁を作った 知る必要のない詳細を隠蔽し、認知負荷を下げるために 2. 壁を越える情報の伝達はすべてコミュニケーション 名前、問い合わせ対応、ドキュメント、社内マーケ、トレーニング、価格設定… これらすべてコミュニケーション 3. 意図を持って網羅的にコミュニケーションチャネルを設計しよう（1:1 / 1:Many ） 2 / 32 

© LY Corporation © LY Corporation Public 先に結論 1. プラットフォームを作ると決めた瞬間、あなたが意図して組織の壁を作った 知る必要のない詳細を隠蔽し、認知負荷を下げるために 2. 壁を越える情報の伝達はすべてコミュニケーション 名前、問い合わせ対応、ドキュメント、社内マーケ、トレーニング、価格設定… これらすべてコミュニケーション 3. 意図を持って網羅的にコミュニケーションチャネルを設計しよう（1:1 / 1:Many ） ここのHow の例をひたすら紹介します！ 3 / 32 

© LY Corporation © LY Corporation Public プラットフォームは、ただの共通モジュールではない プラットフォームの価値: I/F を学べば使える、内部は意図的に隠蔽されていてよい 隠蔽は情報格差を生み、組織の壁を生む。 壊すのが正義ではない 必要なのは、ちょうど良い隠蔽× 豊かなコミュニケーション 4 / 32 

© LY Corporation © LY Corporation Public 1:1 と1:Many の2 つのコミュニケーション 1:1 （個別・協働） 高解像度だがスケールしにくい インフォーマル( 非公式) なコミュニケーションがあっても良い 1:Many （スケール施策） スケールするが個別最適は薄くなる フォーマル( 公式) なコミュニケーションがすべて 5 / 32 

© LY Corporation © LY Corporation Public 1:1 コミュニケーションの例 問い合わせ窓口( ヘルプデスク) 利用者インタビュー 重要チームとの定例会議 センサー組織 裏口 6 / 32 

© LY Corporation © LY Corporation Public 問い合わせ窓口( ヘルプデスク) 多くの組織でチーム間のやり取りをするチャンネルを用意していることがあると思います。 組織によってはJira チケットだったり、Slack だったり、メールだったりなど。 しかし、この問い合わせをした時点で、すでに利用者は不満を持っていることをが多いです。 つまりその場で問題を解決するだけでは足らず、次のことに繋げる 問い合わせの原因がわかりにくいドキュメントなら改善する 社内AI チャットbot があれば、そのコンテキストに追加しておく 問い合わせが特に多いチームには、イノベーター/ アーリーアダプターとして個別に定例を持つ 「xxx のやり方がわからなかった」 「xxx をやったらエラーになった」 “ “ 7 / 32 

© LY Corporation © LY Corporation Public 利用者インタビュー 定期的に、利用者へインタビューを行っているプラットフォームもあると思います。 しかし、インタビューでは、利用者側の課題の感知機能・言語化能力に強く依存してしまいます。 もしインタビューで課題を発見できた場合、 そのインタビューに回答してくれているプロダクトチームは非常に優秀です！ 8 / 32 

© LY Corporation © LY Corporation Public 利用者インタビュー → 画面共有 多くの場合、インタビューで明確な課題を聞き出すことは難しいので インタビューでは質問をせずに、実際の利用者のオペレーションを画面共有してもらいましょう。 非効率な使い方を発見したり データ量によって、想定よりプラットフォームの動作が重かったり 利用者側でプラットフォームをさらに隠蔽して、 使いやすいインターフェイスにしていたり その場でやり取りで不満を解決するだけでなく、新たな課題も発見できるかもしれません。 9 / 32 

© LY Corporation © LY Corporation Public 重要チームとの定例会議 プラットフォームを特に多く使っている利用者とは、定例会議を持つことは価値があります。 彼らにプラットフォーム側から相談することもできる 彼らの不満を解決すると他の利用者の将来の不満を潰せることにも繋がる 一方で、こういった定例は形骸化しがちです。 議題がなければ躊躇なく中止し、中止が複数回続いたら解散することを予め合意しましょう。 10 / 32 

© LY Corporation © LY Corporation Public センサー組織 ここまでのコミュニケーションは、 「あなたたちとわたしたち」に分かれて 向かい合ってやり取りするもので しかし、やはりそれでは見えるものに限界があります。 プラットフォーム組織の10% 程度は、センサー組織に投資することを検討しても良いでしょう。 11 / 32 

© LY Corporation © LY Corporation Public センサー組織 私たちはEmbedded SRE というチームで、センサー組織を実現しようとしています。 AI の文脈ではForward Deployed Engineer(FDE) と呼ぶこともあるらしい。 このチームは、各利用者のチームに兼務として所属し、そのプロダクトを一緒に成長させます。 その中で、プラットフォームにフィードバックするものを見つけるセンサーとなる役割です。 12 / 32 

© LY Corporation © LY Corporation Public 私たちのセンサー組織の生まれと特徴 私たちのセンサー組織は プラットフォーム自体の開発運用を行わない 開発組織に溶け込む必要がある 上記のことから、プラットフォームのメンバー求められるスキルも異なることがあります。 プラットフォームでは、特定技術に特化したスペシャリストが求められがち プロダクトでは、ビジネスの優先課題に対応するためにジェネラリストが求められがち そのため、プラットフォーム組織でセンサー組織のための採用を行ったり、 既存のプラットフォーム内の組織から配置転換で捻出するのは難しいことも多いです。 13 / 32 

© LY Corporation © LY Corporation Public 私たちのセンサー組織の生まれと特徴 私たちは以前は、プロダクト部門で生まれたSRE でした。 そして、LINE のプラットフォーム側に チームごと異動しました。 そのためチームのシードメンバーは、基本的にプロダクトチーム視点を持ち、 プロダクトを一緒に開発するメンバーとして受け入れられています。 チーム毎異動するのが難しい場合でも、 プロダクトチーム側から代表者を選出する形で始められるかもしれません。 14 / 32 

© LY Corporation © LY Corporation Public 裏口 「プラットフォームチームにいる同期に聞いてみたんだけど」 「プロダクトチームに仲のいい人がいるから、ちょっと聞いてみるよ」 「DM でちょっと聞いてみるよ」 こういったインフォーマルなやり取りは、属人性が強く再現性が乏しいため、頼るべきではない。 15 / 32 

© LY Corporation © LY Corporation Public 裏口 「プラットフォームチームにいる同期に聞いてみたんだけど」 「プロダクトチームに仲のいい人がいるから、ちょっと聞いてみるよ」 「DM でちょっと聞いてみるよ」 こういったインフォーマルなやり取りは、属人性が強く再現性が乏しいため、頼るべきではない。 しかし、短期的には非常に強力な手段です。 立ち上げ期やコミュニケーションのきっかけが必要な時などにうまく限定して、 ビジネスを前に進めるために使うことも必要です。 16 / 32 

© LY Corporation © LY Corporation Public 1:Many コミュニケーションの例 命名・ブランド設計 満足度サーベイ(NPS など) ドキュメント トレーニング 社内価格( 管理会計/ コスト配賦) リリースノート vs インターナルプレスリリース ロードマップの公開と更新 17 / 32 

© LY Corporation © LY Corporation Public 命名・ブランド設計 ツールやシステムの名前、もしくはそれを提供しているチームの名前は、無視できません。 私たちの場合、プロダクト部門のSRE のときは、ただの"SRE" という名前のチームでした。 チームごとLINE プラットフォームに異動した際、 期待値のすり合わせのために Embedded SRE という名前にしました。 これはSRE のやり方が様々なため、人によって様々な期待を抱くことを警戒して チームごと異動する際の条件として上長と話したものでした。 18 / 32 

© LY Corporation © LY Corporation Public 満足度サーベイ(NPS など) NPS などのサーベイを配信して、集計している組織も多いかもしれません。 ここではPlatform Engineering Kaigi 2025 のキーノートで紹介されていた未来の1 つとして、 「サーベイもAI をインターフェイスとして、自然言語で行うようになる」という話を紹介したいと 思います。 今の固定の質問に回答するサーベイでは、どうしても拾いきれない声があるので より自然言語に近いやり取りのサーベイがAI チャットで出来るはずだ、という内容もありました。 気になる方は、ぜひセッションを見てみてください。 19 / 32 

© LY Corporation © LY Corporation Public ドキュメント ドキュメントをプラットフォームが公式に用意しないとどうなるか。 20 / 32 

© LY Corporation © LY Corporation Public ドキュメント ドキュメントをプラットフォームが公式に用意しないとどうなるか。 プロダクトの担当者が、 「xxx の使い方」というドキュメントを自分のチームのために書き始める。 プロダクト担当者がドキュメントを書き始めると、さらにどうなるか？ 21 / 32 

© LY Corporation © LY Corporation Public ドキュメント ドキュメントをプラットフォームが公式に用意しないとどうなるか。 プロダクトの担当者が、 「xxx の使い方」というドキュメントを自分のチームのために書き始める。 プロダクト担当者がドキュメントを書き始めると、さらにどうなるか？ 社内ドキュメントシステムの検索が汚染され、 他の利用者が公式のドキュメントに検索でたどり着けなくなります。 22 / 32 

© LY Corporation © LY Corporation Public ドキュメント ドキュメントをプラットフォームが公式に用意しないとどうなるか。 プロダクトの担当者が、 「xxx の使い方」というドキュメントを自分のチームのために書き始める。 プロダクト担当者がドキュメントを書き始めると、さらにどうなるか？ 社内ドキュメントシステムの検索が汚染され、 他の利用者が公式のドキュメントに検索でたどり着けなくなります。 一方でプロダクト側のドキュメントは、ケーススタディとしてわかりやすいことも多いです。 そういったドキュメントを見つけたら、公式ドキュメント側に引き取ることも検討しましょう。 私たちもプロダクト側として書いたドキュメントをプラットフォームに寄稿しています。 23 / 32 

© LY Corporation © LY Corporation Public トレーニング 利用者にプラットフォームの正しい使い方を伝えるため、トレーニングを企画することもあると思 います。 失敗パターンとしては、長尺の完璧なトレーニングを作ってから実施することです。 24 / 32 

© LY Corporation © LY Corporation Public weekly x short トレーニング 利用者にプラットフォームの正しい使い方を伝えるためにトレーニングを企画することもあると思 います。 失敗パターンとしては、長尺の完璧なトレーニングを作ってから実施することです。 その方法では、準備に時間を使いすぎてしまったり、トレーニング参加者にも負担があります。 もしセンサー組織があり、親密にしているプロダクトチームが既にある場合、2-30 分のweekly hands-on を行うことを推奨します。 2-30 分程度のhands-on は、1 回や2 回ではまともな成果は出ません。 しかし、半年続ければ10 時間程度のハンズオンになり、トレーニングについていけなかった参加者 のフォローも容易です。 準備も数時間で出来る規模ですので、翌週のトレーニングを準備しながら自転車操業も可能です。 25 / 32 

© LY Corporation © LY Corporation Public 社内価格( 管理会計/ コスト配賦) Public Cloud を使われている方は、その価格設定からそのサービスをどう利用するべきかを理解で きることはありませんか？ 利用者に提示する料金体系もコミュニケーションの1 つです。しかも強力なものです。 管理会計の仕組みが社内にない場合、ゼロから立ち上げるのは非常に困難がつきまといますが、 受益者負担や独立採算制といった原則を適用できるようになります。 1. プラットフォームのユースケースを料金体系で暗に示せること 2. 受益者負担の原則により、特定のプロダクトが無闇に使いすぎないようにすること 特定プロダクトに特化しすぎて、実質的な外注開発になることを防ぎます 3. コスト配賦に数% の利益を上乗せすることで、その利益の範囲で自由な挑戦を行えること プラットフォームはしばしばコストセンターとなり、厳しいコスト削減圧に晒されます この時、新たな挑戦や人員の確保のために使える利益があると説明がしやすい 26 / 32 

© LY Corporation © LY Corporation Public リリースノート vs プレスリリース しばしば社内向けツールでは、何を変更したかというリリースノートは列挙するものの、 それが利用者のどういった問題を解決するかを説明したプレスリリースを出すことは少ないです。 リリースノートとプレスリリースがどのように違うのか、一度具体的に比較してみましょう。 27 / 32 

© LY Corporation © LY Corporation Public Grafana Image Renderer のリリースノート このツールは、Grafana のダッシュボードを画像やPDF にレンダリングしてくれるものです。 Apache 2.0 LICENCE としてGitHub 上でメンテナンスされています。 こちらのv5 のリリースノートはこちらです。 ソフトウェアのリリースノートとしては、何が変わったかを書くべきなので、これが正しいです。 では、これをサービスとして提供している場合のプレスリリースを見てみましょう。 v5.0.0 はありませんでした 28 / 32 

© LY Corporation © LY Corporation Public Grafana Image Renderer のプレスリリース こちらはブログとしてポストされたプレスリリースです。 https://grafana.com/blog/2025/12/03/whats-new-in-the-grafana-image-renderer-higher-quality-results-security-enhancements-and-more/ 内容は非常に明確で、下記が図と文章で説明されています。 このツールが何をするためのツールなのか 最近の更新はどのような課題を解決するものなのか このツールをGrafana Cloud やその他の環境で使い始める方法 29 / 32 

© LY Corporation © LY Corporation Public リリースノート vs プレスリリース ソフトウェアのリリースノートと、プラットフォームサービスのプレスリリースは目的が異なりま す。 もし、プラットフォームを作っていて、ソフトウェアのリリースノートしか出していない場合は プレスリリースにも一手間かけると、利用者側の戸惑いや誤解も減ることが期待できます。 30 / 32 

© LY Corporation © LY Corporation Public ロードマップの公開と更新 プラットフォームのリリーススケジュールを参考に、開発チームは計画を立てる場合があります。 特に問い合わせが多いものや強制力があるプラットフォーム移行開始時期などは明記しましょう。 またロードマップの認知度をあげるための工夫も必要になることが多いです。 ロードマップが文化として根付くまでは時間がかかると思いますが、 気長にコツコツやりましょう。 31 / 32 

© LY Corporation © LY Corporation Public 目指すべきコミュニケーションのサイクル 1:1 はプロダクトの課題を収集、1:Many は仕組みでスケール。両者を循環させることが重要です。 [1:1 観察/ 対話/Embedded] ↓ 事実・摩擦を収集 [ パターン化/ 仮説化] ↓ 再現できる単位へ整形 [1:Many 化 (FAQ→Doc→Bot→e ラーニング/PR/ 価格/ ロードマップ)] ↓ 自助化/ スケール [ 計測 (NPS/CSAT/ 利用データ)] ↓ 効果検証・優先度調整 [1:1 へ還流 ( 再観察/ 実験)] ↺ 次の仮説へ 32 / 32