注意
本記事では学生からPlatform Engineeringがどのように見えているのかを書きます．
そのため誤ったPlatform Engineeringに対する理解が含まれる可能性があります．
企業に所属していない者からはどのように見えているか伝われば幸いです．
1. 環境
私の状況と周囲の学生の雰囲気を紹介します．
Platform Engineering関連の話だけ読みたい方は飛ばしてください
私は現在クラウド・分散システム研究室というクラウドとIoTを対象とした研究室に所属しています．
研究室にはESXiやKuberntesが導入されており，vmやコンテナを利用した研究が行えます．詳細はこちら
私は特にKubernetesの方に関連した研究を行っているのですが，PrometehusやIstio，Chaos-meshなどの知識資源がesaに残っており，実験環境の構築にはあまり苦労しない状況です．
講義でもKubernetesを扱うものがあり，同学年のうち6分の1程度がKubernetes操作を経験しています．
2. 学生のPlatformEngenieeringへの理解
Platform Engenieeringについて私の考えをまとめます．研究が落ち着いたらアンケートもとりたいなと考えています．
2.1. 個人にとってのPlatform Engineering
私にとってPlatformEngenieeringは自分の開発を快適にするための方法です．
当然，企業ではないのでお客さんがいるわけでも，組織としてともに開発するソフトウェアエンジニアがいるわけでもありません．そうなると，必然的にインフラからアプリケーションまで自力で構築する必要があります．
例えばDiscord Botを作成しようと思ったときにはプログラム自体が必要なのは当然として
- プログラムを動作させ続けるサーバ
- プログラムが停止しても再度起動する仕組み
が必要です．
1度動けば良いのならばデスクトップ環境でテストすればいいですが，私の場合は同時に3つのBotを動作させたいと考えていました．
そうなると,
- Bot Tokenの管理
- ノートPCとデスクトップPCで共通化された開発環境の整備
- コードのテンプレート化
- エラーに対するドキュメントの整備
など行いたいことが増えてきます．
これらの要求に対して実装するまでの時間や労力と，実装した結果得られるメリットを比較してどれだけ良く開発できるかを考えます．(これは正にPlatformEngenieerが行っていることなのかなと想像しています)
2.2. 研究室所属学生にとってのPlatform Engineering
さて、ここまでは個人の学生による開発という視点で考えてきました．しかし私には研究室の学生という視点も考えられます．
個人での開発と研究室での開発で違いはあるのでしょうか？
当然研究でもソフトウェアを開発，デプロイする必要があります．例えば課題を検討する時に実際に環境を作成して試したり，提案を評価するための環境を作成したりします．
しかしその時の意識は異なっています．
個人では、現状に不満がありそれを改善するために開発を行うでしょう．そのため，ある程度はバグを排除する必要があります．
対して研究室では作成したソフトウェアを研究用として捉えています．そのため作成したソフトウェアは提案の評価ができていれば十分で，使いやすさにはあまり関心を持ちません(使いやすさを評価にする場合を除く)．
研究室での開発で重要なことは環境構築とデプロイ速度です．
学生での研究は1,2年程度で評価まで行う必要があることが多いです．そのため，実験の前提である環境構築は素早く繰り返し行える必要があります．また，ソフトウェアについても細かく調整と実験を繰り返すため，こちらについても素早く行える必要があります．少しアジャイルっぽいですね．
2.3. 実際に行ったこと
とても小さなことになりますが，私が実践したPlatformEngenieeringの例として研究室で作成した書籍レビューサイトを挙げます．
詳細はこちらに丸投げするとして，ここでは特にPlatformEngenieeringに関連していると感じた部分について取り上げます．
このプロジェクトは16日という短時間でMVPが完成させつつ，これからも使えるよう引継ぎを意識した開発を求められました．私はそれを達成するために各ビルド方法を使用して開発が進められるようにしました．
ブログにある図の再掲になるのですが，
この図でのlocal, container local, Pod k3sの部分です．
それぞれの環境でプログラムが実行できるということは，開発時に使用する方法を制限しないことにつながると考えています．例えばPCの環境のライブラリやビルドツールを導入したくない場合にはコンテナ環境で実行することができます．
ここまでだとまだプロジェクトに依存したインフラ環境であり，PlatformEngenieeringには不十分かなと感じました．
そこでこのQiitaを書くにあたってGithub Actionsでのビルド部分を内部向けのドキュメントに残しました．これによってほぼコピー＆ペーストだけであらゆるDockerfileの自動ビルドが行えるようになりました．Actionsに対する認知負荷下げ，コンテナレベルの知識だけで開発できるようになったと思います．
プロジェクト特有の技術資源を他のプロジェクトにも活用できるようにしたため，この例がPlatformEngenieeringに当たるのかなと考えています．
3. 周囲の学生の理解
ざっくり聞いた限りでは，私が話した相手はPlatformEngenieeringという名前だけは聞いたことがある状態になったようです．しかし大多数の学生は名前すら知らない状況です．
対してSREという単語は，就活などで聞いたことがある学生が増えてきた印象があります．
PlatformEngenieeringも少しづつ広がっていきそうな兆候は見えますね．
研究が落ち着き次第ちゃんとアンケートを行う予定です．結果はここに追記いたします．
4. PlatformEngenieeringを学生に広めるために
PlatformEngenieeringを学生に広める上で最大の障壁は，学生生活で関わることが少ないことだと思います．当然の話ですが，大抵の学生はPlatformという概念に関わることは多くありません．特にPlatformを整備するという経験をしている学生は楽に数えられる程度しかいないと思います．
しかし広めるのが不可能なわけではありません．
大切なのはその職業が何を行うのかが正確に想像できることだと思います．
学生から見ると企業の中身はよく見えないものです．
そのため，PlatformEngenieerの方々が普段どのような業務を行っているのか正直あまり想像できていません．
ここで強く言いたいのは，学生向けの簡単な解説を求めているわけではないということです．
多くの方が勘違いされるのですが，意欲ある学生にとって簡単にした解説は刺さりません．
むしろ，よくわからない単語で圧倒した方が効果的かもしれません．
私自身も，CI/CDカンファレンスに参加した頃は，セッション内で使われている単語がほとんど分からないかったです．当時の私にとってはITの分野なのにここまで分からないものがあるのかとかなり強い衝撃を受けた記憶があります．
その後，自宅でCI/CDを実践したことで単語が理解できました．
自分の見ていた世界が狭かったんだなとも思いました．
そしてそれを認知するということはとても大きな成長を生みました．
まとめると，私が考える学生にPlatformEngenieeringを広める方法は，内容のレベルを下げずに，学生が参加しやすいような環境を作ることです．
そして，その環境というのは初学者が飛び込んでも怖くないようなコミュニティの暖かさみたいな部分に現れると思います．
ということで，学生でこの記事を読んでいる方へ，
Platform Engineering Meetupは学生にも優しく，それでいて実際のエンジニアとしての取り組みなど高度な内容を聞くことができる．とても良いコミュニティです！
初めからオフライン参加に飛び込むのは不安という人は，まずはオンラインで参加してみてはいかがでしょうか！
おわりに
PlatformEngenieeringを楽しんでくれる学生が増えることを願っています．