はじめに
こんにちは、ACS事業部の東出です。
私はACS事業部でDX Enabling部という、内製化コンサルティング・プロダクト開発支援を提供する部署の責任者をしております。
ACS事業部では、Platform Engineeringに関する取り組みや情報発信を積極的におこなっています。
ユーザー企業の方々にPlatform Engineeringのご紹介をさせて頂く際に、「標準化とどう違うの？」といったご質問を頂くことがございます。
今回は、所謂「標準化」とPlatform Engineeringが意味するところの違いについて書きたいと思います。
余談ですが、この記事を書こうと思ったきっかけですが、ちょうどシステムアーキテクト試験の勉強として共通フレーム2013の解説書を読んでいて、試験勉強からの逃避のためですネタとして思いついたためです。
標準化とは（本記事における定義として）
システム開発の世界に身を置く方にとっては、「標準化」というキーワードは耳にタコができるぐらい聞くワードだと思いますが、その言葉が意味する範囲は様々だと思います。
なので、誤解がないように、この記事における標準化の意味を先に示しておきます。
システム開発における「標準化」とは、開発プロセス、技術、ツール、プラットフォームなど、システム開発に関連するさまざまな要素に対して、共通の基準や規則を設定し、適用することを指します。 標準化の目的は、効率的な開発プロセスの確保、品質の向上、相互運用性の保証、技術的な互換性の確保などです。
標準化によって、開発者間でのコミュニケーションが容易になり、プロジェクトの管理と運営がスムーズに行われやすくなります。・コーディング規約：ソフトウェア開発におけるコーディングのスタイルや規約を統一します。これにより、コードの可読性が向上し、メンテナンスが容易になります。
・開発プロセス：プロジェクト管理やソフトウェア開発のライフサイクルに関する方法論を標準化します。アジャイル開発、ウォーターフォールモデルなど、プロジェクトに最適な開発手法の選定と適用が含まれます。
・技術スタック：プロジェクトで使用するプログラミング言語、フレームワーク、ライブラリ、データベースシステムなどの技術要素を統一します。これにより、技術的な互換性と効率的なリソース利用が促進されます。
・インターフェースとデータ交換：システム間やシステムの異なる部分間でのデータ交換の形式やプロトコルを標準化します。API（Application Programming Interface）やファイルフォーマットの標準化がこれに該当します。
・セキュリティ基準：システムの安全性を確保するためのセキュリティ関連のポリシー、規範、技術的対策を統一します。
（Powered by ChatGPT4）
まさにこういった規約・技術スタックの統一などの活動に、何らかの形で従事されたことがある方は多いのではないでしょうか。
私も過去の所属企業で推進したり、内製化コンサルティングでも標準化のお手伝いをしている関係上、意識することが多いテーマです。
なぜ「標準化」が必要なのか？
なぜ、標準化をする必要があるのか。
以下は私の業務経験に基づく範囲から導き出したものなので、あくまで私見になりますが、以下のように考えます。
学習・教育コストの最適化
個々のエンジニアにとっては嬉しくない場合もありますが、学習・教育コストの最適化を図るには技術スタックの固定化が有力な打ち手になります。
プロジェクト品質の担保
システム開発・運用の現場では、現在でも多重下請け構造による開発が主流です。
こういったケースでは、参画するエンジニアのスキルがばらつくことがあります。
そういうプロジェクトで品質を担保するために、細部までルール化することで一定の品質に保つことを図ります。
こういったケースの標準化においては、スキルが高くない人でもそれなりのアウトプットが出せるようにと、過度な制約が設けられるケースがあります。
例えば、確かJava8からだったと思うのですが、ラムダ式やStream APIが使えるようになった際に、「使い慣れない記法は品質低下の要因になるのでNG」やら、「プロジェクトリーダーが理解できないものなのでNG」といった話を見聞きしました。
自分の観測範囲のプロジェクトでも起こっていました。
セキュリティ・ガバナンスのため
「プロジェクト品質の担保」とも通じる部分がありますが、「知らないことを知らない」領域のことは、ルール化して示さないとわからないものです。
例えばセキュリティに関して、知識がないと対策の必要性すら認識できません。
そのため、セキュリティチェックシートのようなもので確認したり、CI/CDの中にセキュリティチェックを入れたり、脆弱性診断をおこなったりしています。
「標準化」の根底にあるもの
こうした観点で推し進められる「標準化」には、工場的なイメージがあるように私は思います。
誰がやっても、一定の品質でシステムが作り上げられる。。。
標準化、という言葉、営みの中身について、テイラーが提唱した科学的管理法の考え方に近いものがある気がしています。
Platform Engineeringと「標準化」は、目指すべき方向性・マインドセットが違う
Platform Engineeringは、開発チームがより効率的・クリエイティブに活動できるように支援をおこなうためのプラットフォームの提供・管理に関するプラクティスと言えるものです。
開発チームにおけるクリエイティビティを阻害するもの（認知負荷などと表現される）をセルフサービス型のプロダクトで解消し、開発チームがビジネスゴールの達成のために全力を出せることを、Platform Engineeringは支援します。
Platform Engineeringでもセキュリティ・ガバナンスなど、全社で統一すべきものについてはガードレール型のセルフサービスとして提供しますし、IaCやアプリのテンプレート、内部開発プラットフォームとして様々な機能を提供しますが、これらはセルフサービス型で提供されます。
「開発チームが自らの意思で」「自分たちが作るアプリケーションに適したものを選択する」という形でPlatformが提供する各サービスは利用されます。
そういう意味で、Platform Engineeringと、この記事で述べた「標準化」とは、目指すべき方向性やマインドセットが異なります。
おわりに
本日の記事は、あくまで私個人の「標準化」に対する捉え方と、Platform Engineeringの違いについてのご紹介でした。
標準化、という言葉に対する捉え方の違いや、本記事にてご紹介した内容に関するご意見ご感想など、ぜひお伺いできると嬉しいです。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化やPlatform Engineering関連のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
今日触れたようなことを、内製化コンサルティングとしてお客様と対話したりしています。 メンバー絶賛募集中でございます。
