本記事は 2026 年 3 月 9 日 に公開された「 Kinesis On-demand Advantage saves 60%+ on streaming costs 」を翻訳したものです。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータをキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。2025 年 11 月 4 日、 Amazon Kinesis Data Streams に On-demand Advantage モードが導入されました。オンデマンドストリームで瞬時にスループットを増加させ、安定したストリーミングワークロードのコストを最適化できる機能です。従来はキャパシティを手動管理するプロビジョンドモードか、自動スケーリングするオンデマンドモードのどちらかを選ぶ必要がありましたが、On-demand Advantage の導入によりストリームタイプを意識する必要がなくなりました。 本記事では、使用パターンが異なる 3 つのシナリオを比較し、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながらストリーミングコストを最適化する方法を紹介します。正確に比較するため、2 つの AWS アカウントでシミュレーションを実施しました。1 つは On-demand Standard モード、もう 1 つはアカウントレベルで On-demand Advantage モードを有効にしたアカウントです。両方のデプロイで同一のストリーム構成、シャード割り当て、取り込みパターンを維持し、以下のシナリオで課金への影響を比較しました。 本記事に記載されている料金はすべて us-east-1 リージョンのものです。 On-demand Advantage の節約効果の内訳 前回の記事 では、ウォームスループット機能と、On-demand Advantage モードでストリームをウォームアップしてギガバイト単位や毎秒数百万レコードを処理する方法を紹介しました。次に、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながら、さまざまなストリーミングユースケースがどのようにコスト効率よく運用できるかを説明します。 アカウントレベルで On-demand Advantage モードを有効にすると、On-demand Standard と比較して多くの面でコスト削減が得られます。主なポイントは以下のとおりです。 AWS リージョンで最低 25 MiBps の使用量をコミットすることで、60% 以上の節約が得られます。最低コミットメントは、AWS バージニア北部リージョンの 公開料金 に基づき 1 日あたり約 100 ドルです。 Enhanced Fan Out コンシューマーの料金が 68% 低くなり、ストリームあたり最大 50 まで利用可能です (On-demand Advantage なしでは 20)。 24 時間を超えるデータ保持の料金が 77% 低くなります。 ストリームごとの最低固定料金がないため、コスト増加なしに必要な数のストリームを利用できます。 Kinesis On-demand Advantage を選ぶ理由: 60% 以上の節約 Amazon Kinesis Data Streams の On-demand Standard モードと Advantage モードの両方を評価するため、10 個のストリームをデプロイし、全ストリームで合計 100 MiBps の持続的な取り込みスループットを生成しました。EC サイトがユーザーのクリックストリームデータをストリーミングしてリアルタイムインサイトを生成するケースをモデル化しています。シミュレーションは異なるモードの 2 つの AWS アカウントで 2 日間実施しました。1 日目は 100 MiBps の安定した取り込みレートを維持しました。2 日目は、ホリデーセールイベントに備えて 10 個すべてのストリームのウォームスループットキャパシティを 10 倍に増加させ、実際の取り込みレートは 100 MiBps のまま維持しました。各ストリームは 10 MiBps を取り込み、全オンデマンドストリームで合計 100 MiBps です。 2 日目に、On-demand Advantage モードを設定したアカウントで 100 MiBps のウォームスループットを有効にしました。ウォームスループットを使えば、トラフィック急増に備えてストリームを事前にスケールアップできます。 On-demand Standard の Cost Explorer: On-demand Advantage モードの Cost Explorer: シナリオ 1 で On-demand Advantage のコスト効率が高い理由は、安定したデータスループットと複数ストリームの利用にあります。Advantage モードではストリーム時間料金がゼロですが、On-demand Standard モードではストリーム時間あたり $0.04 の料金が発生します。さらに、Advantage モードの受信バイト料金は GB あたり $0.032 で、On-demand Standard は GB あたり $0.08 です。On-demand Standard 構成では 48 時間で合計 $2,071.75 のコストが発生し、1 日あたり $1,037、年間 $378,505 になります。同じワークロードを On-demand Advantage モードで実行すると、同じ 48 時間で $823.44、1 日あたり約 $412、年間コスト $150,380 です。On-demand Advantage ではウォームスループットの追加料金もかかりません。60% のコスト削減に相当し、このワークロードだけで年間 $228,125 の節約になります。 シナリオ 2: 1 アカウントで 10 ストリーム、15 MiBps スループットと延長保持 ある医療企業では、データの再処理に備えて 2 日間のデータ保持期間が必要であり、規制要件により異なる種類のデータを別々のストリームに保存する必要があります。シナリオ 2 の再現として、On-demand Standard モードと Advantage モードの両方で、48 時間の延長保持期間を設定した 10 個の Amazon Kinesis Data Streams をデプロイしました。延長保持により、ダウンストリームシステムはデータを再処理し、一時的な障害から復旧できます。複数ストリームと保持期間を利用するため、On-demand Advantage モードでコスト効率が高いと予想されます。コスト内訳を見ていきましょう。 コストを評価するため、10 ストリームに分散した 15 MiBps の安定した取り込みトラフィックを 48 時間生成しました。On-demand Standard モード: On-demand Advantage モード有効時: Cost Explorer のスクリーンショットで、On-demand Standard モードと Advantage モードの料金を並べて比較できます。On-demand Standard の 1 日あたりのコストは $176 で、年間 $64,240 です。On-demand Advantage の 1 日あたりのコストは $104 で、年間コストは $37,960 です。15 MiBps のスループットと延長保持を利用しても、Advantage モードで 41% の節約を達成しました。Standard モードでは 24 時間を超え 7 日間までのデータ保存に GB あたり $0.10 の追加料金がかかります。Advantage モードでは 24 時間を超え 365 日間までのデータ保存に GB 月あたり $0.023 の追加料金となり、データストレージのコストが最適化されます。シナリオ 2 の結果は、Advantage モードがより幅広いワークロードでコストメリットをもたらすことを示しています。Advantage モードを有効にすると、最低 25 MiBps の使用量にコミットすることになります。しかし、15 MiBps スループットのシミュレーションでも大幅なコスト削減を達成しました。Advantage モードでは、10 MiBps 以上を取り込んでいれば、25 MiBps のしきい値にコミットしていても Standard モードより低コストになります。 シナリオ 3: 1 つの Kinesis Data Stream と 10 個の Enhanced Fan-Out コンシューマー マイクロサービスアーキテクチャでは、複数のサービスが同じデータストリームから同時に低レイテンシーで読み取る必要がある場合があります。システムの進化に伴い、新しい分析ユースケースをサポートし、ストリーミングデータパイプラインからより深いインサイトを得るために、Enhanced Fan-Out (EFO) コンシューマーが追加されることがあります。 次に、マイクロサービスアーキテクチャで On-demand Advantage モードを使用した EFO コンシューマーのコスト比較を評価します。24 時間にわたり、標準の 24 時間保持を設定した 1 つの Amazon Kinesis Data Stream に、EFO コンシューマーとして設定した 10 個の AWS Lambda 関数を接続してテストしました。 複数の EFO コンシューマーが同じストリームに同時にアクセスした場合のコスト影響を評価するため、評価期間を通じて 25 MiBps の安定した取り込みレートを生成しました。以下のチャートは、25 MiBps ペイロードの Enhanced Fan-Out コンシューマーを持つ Kinesis Data Stream を示しています。 以下のチャートは、On-demand Standard モードと On-demand Advantage モード有効時のコスト差を示しています。 Cost Explorer の分析から、複数の EFO コンシューマーを使用しても、On-demand Advantage モードの方が On-demand Standard モードより全体コストが低いことがわかります。On-demand Standard のコストは $1,266 で、Advantage モードのコストは $419 でした。同じワークロード特性で約 67% の節約を達成し、年間 $309,155 の節約になります。イベント駆動型アーキテクチャで複数のサービスがストリーミングデータへの独立したリアルタイムアクセスを必要とする組織にとって、EFO のコスト削減効果は特に大きいといえます。Enhanced Fan-Out のデータ取得料金は、Advantage モードではコンシューマーあたり GB あたり $0.016 で、Standard モードの $0.05 と比較して大幅に低くなっています。一方、持続スループットが低い (10 MiBps 未満) スパイクが大きく予測不可能なワークロードは、On-demand Standard の候補として推奨されます。スループット使用量をコミットせずに、ストリームのスループットキャパシティを自動スケーリングさせられます。 On-demand Advantage とプロビジョンドモードの比較: On-demand Standard モードと On-demand Advantage モードの両方が利用可能になったことで、プロビジョンドモードに頼る必要がなくなりました。キャパシティを手動管理する必要がなく、オンデマンドストリームならシンプルな料金モデルで運用できます。さらに、多数のストリームを運用したり、延長保持や Enhanced Fan-Out などの機能を使用しているプロビジョンドワークロードのお客様は、On-demand Advantage への移行を強く検討すべきです。データストリームはどのモードを選択しても同じ基盤インフラストラクチャを使用するため、On-demand Advantage とプロビジョンドの間で可用性や信頼性に違いはありません。 ウォームスループットに追加料金がかからないため、瞬時スケーリングが必要な場合は On-demand Advantage がプロビジョンドモードより適しています。 Gbps 規模でも、On-demand Advantage は実際のデータ使用量に基づく課金で競争力のある料金です。 On-demand Advantage は、EFO (マイクロサービスのような高ファンアウトニーズ向け) と延長保持の利用コストが大幅に低くなっています。 比較の参考として、Kinesis コンソールを使用して、アカウントの上位 200 のプロビジョンドストリームが On-demand Advantage に適しているかどうかを確認できます。 まとめ 本記事では、Amazon Kinesis Data Streams の On-demand Advantage モードがパフォーマンスと柔軟性を維持しながら大幅なコスト削減を実現する 3 つの実際のシナリオを紹介しました。On-demand Advantage は大規模ワークロードで優れたパフォーマンスを発揮し、On-demand Standard と合わせて、Kinesis Data Streams はさまざまなストリーミングユースケースにシンプルかつコスト効率の高いソリューションを提供します。ワークロードが安定して 10 MiBps 以上をストリーミングする場合、2 つ以上のコンシューマーにファンアウトする場合、24 時間を超えてデータを保持する場合、または数百のストリームを運用する場合は、On-demand Advantage が最もコスト効率の高いモードです。それ以外のワークロードには、On-demand Standard モードが適しています。多様なプロデューサーからコンシューマーへ毎秒数百万レコードやギガバイト単位のデータをストリーミングする場合でも、Kinesis Data Streams で対応できます。ぜひ Kinesis Data Streams On-demand Advantage を活用して、リアルタイムインサイトを組織やプロセスに取り入れてみてください。 著者について Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカウントマネージャー兼データ分析スペシャリストです。分析およびデータサービスの深い専門知識を持ち、パフォーマンス、スケーラビリティ、コスト効率に優れたクラウドアーキテクチャの最適化を支援しています。 Pratik Patel Pratik は、AWS のシニアテクニカルアカウントマネージャー兼ストリーミング分析スペシャリストです。AWS のお客様と連携し、ベストプラクティスに基づくソリューションの計画と構築を支援するとともに、お客様の AWS 環境の運用状態を健全に保つための継続的なサポートと技術ガイダンスを提供しています。 Varsha Palepu Varsha は、AWS のソリューションアーキテクトとして、中小企業のイノベーションと AWS 上での構築を支援しています。ストリーミングチームに所属し、技術コンテンツの作成やお客様のクラウド上での目標達成を支援しています。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデータ＆分析スペシャリストです。高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースソリューションの設計と構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

はじめに 対象読者 主なキーワード 共通ID基盤プロジェクトについて なぜプロジェクトを開始したのか？ 共通ID基盤構築の要件 共通ID基盤の技術選定 認証基盤に関連する技術群 どの技術を使うべきか？ アーキテクチャの検討 隠れたサービス要件の発覚 サービスに求められる要件について OIDCで必須のOPへのリダイレクト OIDCとサービス要件の不一致 別の方法を探る 1. 主力プロダクトをOPとする案 2. サービスのドメインを統合する 3. サービスをコードレベルで統合する 終わりに はじめに スマートキャンプ株式会社京都開発拠点では、自社開発プロダクトであるSaaSマッチングプラットフォーム「 BOXIL SaaS 」とオンラインイベントサービス「 BOXIL EVENT CLOUD 」の間でアカウントを共有する共通ID基盤の開発を進めています。 この記事では、その開発過程でOpenID Connect（OIDC）の採用を検討した結果と得られた知見について解説します。 具体的には、共通ID基盤の開発過程を時系列で紹介し、OIDC採用の検討過程、ビジネス要件との折り合いをつけることが難しかったこと、およびOIDCを使わないケースも含めたシングルサインオンの代替案についても触れます。 対象読者 ID基盤を作る際に、OIDCを導入しようか迷っている人 かつOIDCの基本的なことは理解している人 主なキーワード BOXIL SaaS : SaaSマッチングサービス。主力プロダクト。 BOXIL EVENT CLOUD : ビジネスのための情報共有の場としてのオンラインイベントプラットフォーム。 OpenID Connect（OIDC） : 認証基盤としての最有力候補技術。 シングルサインオン（SSO）: 一つのID（アカウント情報）を入力するだけで、連携する他のサービスにもログインできる仕組み。 OpenID Provider（OP）：OIDCにおけるユーザー認証のサービスを提供するサーバーまたはプラットフォーム Relying Party（RP）：OIDCにおけるユーザーの認証情報を利用するサービスやアプリケーション 共通ID基盤プロジェクトについて なぜプロジェクトを開始したのか？ プロジェクトの対象サービスがBOXIL SaaSというサービスと、BOXIL EVENT CLOUDというサービスであることは冒頭にお伝えしました。 BOXIL SaaSとBOXIL EVENT CLOUDとは、別々のサービスではありますが、片方はSaaSを導入したい／提供したい企業向けのマッチング、もう片方はイベント開催を通してビジネス上の知見・つながりを提供しています。 ですのでターゲットとする顧客としてはある程度重なる部分もあります。 現状ではそれぞれ独自の認証システムを持っているので、ユーザーは各サービスで別々に登録する必要があり、サービス間のデータ連携もありません。一方のサービスに登録しているユーザーに対して、そのデータを活用したもう一方のサービスで便利な機能を提供するなどの施策を簡単に提案できない状況でした。 このような課題を解消するため、共通ID基盤の導入により、一度登録すれば複数のサービスでアカウントを共有できるようにするプロジェクトがスタートしました。 ここで現状におけるサービスの簡単な構成図をお見せしておきます。 それぞれのサービスがユーザー情報を独立して持ち、認証も別々に行なっていることがわかります。 認証の仕組み(Before) では現状を踏まえたうえで、要件をまとめていく次のステップに移ります。 共通ID基盤構築の要件 チームでは、ビジネスサイドのメンバーとも話を進め、共通基盤に求められる具体的な要件をまとめていきました。 要件をかいつまんで説明すると下記のような内容になります。 ドメインの異なる2サービス（BOXIL SaaS、BOXIL EVENT CLOUD）でIDを統合して利用できるようにする もともとユーザー属性の近いサービスであるため、IDの一元化によりサービス間での相互送客を狙いたい 会員情報の二重入力や更新の手間を省き、サービスのUXを向上したい 各サービスのデータを紐づけたうえで、データ分析やマーケティング活動に活用したい 属性の近い別のサービスを将来的に連携する際のID連携の基盤を作る 新規サービスにおいても、既存サービスのユーザーを低コストで連携できるようにしたい 本プロジェクトでは上記の要件を満たすべく、まずは関連する技術選定から始めていきました。 共通ID基盤の技術選定 認証基盤に関連する技術群 今回のように異なるドメインのサービス間でのSSOを実現する際に、関連技術をいくつかピックアップし検討していきました。 以下に主要な検討技術をピックアップして簡単に特徴を説明します。 OIDC OAuth2.0を拡張し、認証にも利用できるようにしたプロトコル IDトークンを用いて認証をして、UserInfoエンドポイントからユーザーのプロフィール情報を取得する 異なるドメインのサービス間でのSSOが実現できる データのやり取りはJSON形式で行なう OAuth2.0 認可のためのプロトコル（認証ではない） この仕様で認証を賄うには独自に拡張を行なう必要があるが、リソースサーバーから提供されるプロフィールAPIを用いての認証の方法には脆弱性があり、拡張の際にはセキュリティなどのリスクに特に気をつける必要がある データのやり取りはJSON形式で行なう SAML 異なるドメインのサービス間でSSOを実現できるプロトコル SAMLは独自に定義された認証規格であり、OIDCがOAuth 2.0に基づいているのとは対照的 SAMLはXML形式でデータをやり取りする 独自構築 規格には属さないものの、完全に独自で認証システムを設計する選択肢も存在します。この方法は、特定の要件に対してもっとも柔軟に対応できる点が強みです。しかし、OIDCなどセキュリティも考慮された規格とは異なり、セキュリティリスクも自分たちで考慮の上仕様を決める必要があるため、その点で難易度が高いと言えます。 さらに、この手法は既存のライブラリや参考資料が少ないため、構築と運用のコストが他の方法よりも高くなる可能性があります。 どの技術を使うべきか？ チームでは、先にまとめた既存規格の技術、独自認証などの特徴と、求められる要件を考慮したうえで検討した結果、今回の共通ID基盤プロジェクトにおいては第一候補としてOIDCを採用することになりました。 選定の際に考慮した点については下記の通りです。 社内のスキルセットとのマッチング OIDCはOAuth2.0の拡張であり、基本的なフローはOAuth2.0とほぼ同じであること 既存プロダクトではOAuth2.0の導入実績があり、社内で知見がある程度蓄積されていること 低い複雑性 SAMLよりもプロトコルがシンプルで、仕様自体の見通しが良いこと 走り出しから継続して検討をしながら進めていくような今回のプロジェクトには、シンプルであることがプラスで働くこと 将来的に新しいサービス連携することを考慮したときに、スピーディに連携できそうなこと セキュリティの考慮 IDトークンの署名・暗号化や、 PKCE （Proof Key for Code Exchange）など、多くのセキュリティ機能とベストプラクティスが組み込まれており、必要十分であること ライブラリの充実 標準化され多く利用されている規格であるため、既存のライブラリやツールのサポートが豊富で、設定例やドキュメントも充実していること 基盤のベースの技術としてOIDCを採用したので、それを前提としてシステム構成を考えていきます。 アーキテクチャの検討 次にOIDCを前提として、共通ID基盤を入れたときのサービス全体のアーキテクチャを検討しました。下記に簡略化した構成図を掲載します。 現状のシステム構成図は「 なぜプロジェクトを開始したのか？ 」の章を参照してください。大きく変わったところは下記です。 認証を担う機能を共通ID基盤として新たに構築する BOXIL SaaS、BOXIL EVENT CLOUDでそれぞれ持っていた認証の実装を、共通ID基盤のOIDC経由で行なう実装に置き換える。 各サービス上にあるユーザー情報のうち、認証に使う情報を中心に共通ID基盤に移す。（それ以外の多くのサービス固有のユーザー情報は据え置き） 認証の仕組み(After) OIDCの観点だと、BOXIL SaaS、BOXIL EVENT CLOUDの各サービスはそれぞれRPとなり、新しく作る共通ID基盤はOPとして振る舞う形になります。 隠れたサービス要件の発覚 チームでは、作ったアーキテクチャの想定を元に、実際にOIDCを使ったときに具体的にどのような画面遷移になるだろう？実際のUXはどうなるだろう？といったユーザー観点での調査を重ねて、ビジネスサイドとも話を進めていきました。 サービスに求められる要件について ところで、BOXIL SaaSでは、さまざまな施策を通じて会員の獲得効率（CVR）を最大限に高める戦略を採っています。たとえば、資料請求フォームの入力後に会員登録処理と並行してログインができるよう実装したり、EFO（Entry Form Optimization）によるUXの最適化に重点を置いています。 今回のプロジェクトでも、会員登録の手間を減らしてUXを向上したり、サービス間での相互送客を実現するなどの目的がありますが、実際問題としてはCVRを損なわないという前提条件下で考慮される必要があります。 ただ、この要件は事前に明文化できていたわけではなく、チーム間で明確に認識の形成ができずにプロジェクトが進行して、徐々に懸念が強く浮き彫りになってきたという感じでした。 OIDCで必須のOPへのリダイレクト OIDCの仕様の中にはいくつかの認証フローが定義されていますが、特に今回採用を予定していた認可コードフローにおいては、"OPへのリダイレクト"という仕様があります。 下記のシーケンス図をご覧ください。 シーケンス図 認証の開始時にRPであるBOXIL SaaSから、OPである共通ID基盤にリダイレクトされ、認証が完了した後にOPからRPに認可コード付きでリダイレクトされて戻ってくる流れがあることがわかります。 このリダイレクトはOIDCの仕様上重要で、RPとOP間の疎結合性を保つことで、安全に認可コードをRPに渡すことを実現しています。 OIDCとサービス要件の不一致 さて、前述したように、BOXIL SaaSとしては会員獲得におけるCVRに影響を与える変更は極力避けたい事情がありました。プロジェクトチームでは、OIDCのリダイレクト仕様がBOXIL SaaSのCVRにどのような影響を与えるかを慎重に考察しました。 結果、リダイレクトを入れることで会員登録やリード獲得のプロセスに影響が生じ、ユーザーが外部の認可エンドポイントへ移動することで、会員獲得の動線が分断されて、CVRやEFOによるユーザー動線の最適化にも悪影響を及ぼす懸念が出てきました。 それを避けるために、なんとかリダイレクトしつつも極力CVRに影響を与えない次善策を含め、調査と検討を重ねたのですが、決定的な策が提案できず、最終的には独立した共通ID基盤経由でOIDC認証をする構成を採用しない決断をしました。 高い自由度のUXを確保するために、OIDCのリダイレクト要件は今回のプロジェクトには合わないと判断したのです。 別の方法を探る では、前述した「リダイレクトしたくない」というビジネス要件と、「リダイレクトが必要」というOIDCの仕様を受けて、どういった意思決定をすべきでしょうか。 私たちが現状調査・検討してきた案をいくつかご紹介します。 BOXIL SaaSをOPとする案 サービスのドメインを統合する サービスをコードレベルで統合する なお、この記事を執筆時点では、目下、案の検討を進めている途中のため、どれを採用したのかは言及しません。どの案もUI/UXへの影響や、開発・保守運用工数への影響などなどトレードオフがあり影響度も大きいため、慎重に検討を進めていく必要があります。 また考えるうえでは、短期的なメリット、中長期的なメリットなど時系列も含めて議論が必要と考えています。 以下にそれぞれを簡単に紹介します。 1. 主力プロダクトをOPとする案 認証の仕組み(BOXIL SaaSをOPとする案) この案はOIDCの認証を管理するサーバー（マイクロサービス）を新規で開発・運用するのではなく、考慮すべきビジネス要件が多いBOXIL SaaSをOPとして振る舞わせ、BOXIL EVENT CLOUDはRPとしてそのエンドポイントを利用する形です。 そうすることでBOXIL SaaSでは従来の会員登録のフローを変更する必要がなくなるため、ネックだったリダイレクトの影響に対する懸念は考えなくて良くなります。 デメリットとしては、認証機能自体のBOXIL SaaSへの依存が強くなってしまうため、連携するサービスの負荷でBOXIL SaaSも影響を受けてしまったり、例えばBOXIL SaaSがクローズする際に連携サービスが影響を受ける可能性などがでてきてしまいます。 また、この案は一度しか使えず、今後連携するサービスでは通常のOIDCによるリダイレクトが強制される形になります。 以降の案はOIDCを使わない案です。 2. サービスのドメインを統合する 一方のサービスのコードベースを、もう片方のドメインに丸ごと移すやり方です。 認証の仕組み(サービスのドメインを統合する案) 例えば、BOXIL SaaSは現在 boxil.jp 、BOXIL EVENT CLOUDは boxil-event-cloud.jp でホスティングしていますが、これを boxil.jp 、 event.boxil.jp に変更すれば、サードパーティクッキーの制限がなくなります。 片方でログインして、もう片方のサービスとログインセッションを共有することも技術的に可能になります。 3. サービスをコードレベルで統合する これはできるケースが限られると思いますが、もし連携するサービスのビジネスドメインや会員属性が近く、数が多くない場合は、サービス自体を一つのコードベースに統合する案も考えられそうです。 認証の仕組み(アプリケーションをコードレベルで統合する) 当然ながら自由度は非常に高いですが、引越しする側のサービスについてゼロベースに近い開発が必要になるため、完了までにかかるコストや、統合にあたっての双方のデータスキーマの見直しなど、多岐にわたる検討が必要になります。 終わりに 本プロジェクトの開発過程では、技術選定だけでなく、ビジネス要件との整合性も重要であることが明らかになりました。OIDCは多くの場合に有効な技術ですが、それありきで進めるのではなくUXとビジネス要件をしっかりと両立させ、最適な技術選定と実装を広い視野で追求していく必要があることを今回学ぶことができました。 この記事が皆さまの参考になれば幸いです。

UNIXという考え方 スマートキャンプでエンジニアマネージャーをしています林です。 私はエンジニアマネージャーをやっているのですが、エンジニアではありません。 マーケターとしてスマートキャンプに入社し、マーケティングの成果を最大化するためにディレクターの立場でプロダクト改善を行ううちに開発チームのマネージャーになったという経歴です。 tech.smartcamp.co.jp 非エンジニアがエンジニアのマネジメントをするにはエンジニアについて学ばなくてはいけないことが多々ありますが、私が色々と学んできた本の中で、 特に役に立った書籍 を紹介していこうと思います。 「UNIXという考え方」 この本をオススメする対象者と読むメリット この本を読んだ背景 本の内容・構成・読みやすさ 私視点で学びになったポイント3点 ①「スモール・イズ・ビューティフル」 ②大きな一まとまりをつくるよりも、分解した小さなシステムを連携させるほうが応用がきく ③できるだけ早く試作を作成する この本を読んで役立った事 まとめ 「UNIXという考え方」 この本をオススメする対象者と読むメリット 今回ご紹介する本は、私のようなマネージャーだけではなく、 エンジニアと一緒に仕事をする人 なら読んでみるととても参考になる本だと思います。 サブタイトルにある通り、UNIXの設計思想と哲学について解説した本なので特定のOSについて語ったものではあるのですが、そこには良いプログラムとはどういうものなのかという事など、プログラミングについての本質が書かれているように思います。 これらの内容はエンジニアの考え方を理解するのに一役買うと思いますし、想像力を膨らませて応用すれば、エンジニアでなくても自分自身の業務の改善に役に立つ要素が多く見つかると思います。 厚さは1cmないくらいで140ページ程の読みやすいボリュームの本なので、ぜひ読んでみてください。 この本を読んだ背景 この本は、弊社のエンジニアチームのメンバーに勧められて読みました。 私が大好きな経営者に、ミスミグループの社長をされていた三枝匡という方がいます。その方の書籍のなかで、事業組織はなるべく小さくあるべきという意味合いで「スモール・イズ・ビューティフル」という言葉が語られていますが、その話をしている時にこの本を紹介されました。 「エンジニアも同じ考えを重要視している」という文脈で、その詳細が書かれた本として教えてもらいました。 本の内容・構成・読みやすさ この本では、上で紹介した「スモール・イズ・ビューティフル」だけではなく、プログラミングの根幹になるような考え方が様々紹介されています。 本の構成は、まず冒頭で主要な項目の概要の説明があり、次の章から項目のそれぞれについて詳しく紹介していく形になっています。 内容としては、UNIXの考え方として「教義にも匹敵する」と表現される程重要視される9つの項目と、「UNIX文化の一翼を担っている」と表現され、人によっては重要度に差がでるものの重要と考えられている10項目があります。それらの項目１つ１つについて、章やセクションを分けながら詳細に説明がされていきます。 最後にはその他のOSの思想についての説明があります。 このセッションがあることによって、相対的にUNIXについて考える事ができる構成になっていて、非常にわかりやすいですし、興味深く感じました。 構成は非常にわかりやすいですし、文章も著者の経験に基づく事例を交えながらフランクに語られている印象で、肩肘張らず読む事ができると思います。 私視点で学びになったポイント3点 ①「スモール・イズ・ビューティフル」 冒頭で三枝さんが事業組織について同じことを言っているという話をしましたが、この本を読んで、「スモール・イズ・ビューティフル」は真理だなと再認識しました。 小さく分解して考え動かす事はマーケのタスクでも応用可能です。 例えばEFO(入力フォーム最適化)のためのABテストをするとき、フォームの配置の問題、フォームの入力補助の問題、誘導文言の問題、背景色の問題など切り分けてテストすると、どの項目がどれだけ影響を与えるかが明確にわかり改善PDCAを回しやすくなります。 何か施策を考える時に、最小単位に分解できているか？と考える事 は施策の精度をあげるのに貢献してくれます。 ②大きな一まとまりをつくるよりも、分解した小さなシステムを連携させるほうが応用がきく スモール・イズ・ビューティフルに関連する内容ではありますが、 小さな単位で作ると組み合わせでいろんな事ができる というのも真理だなと思います。この内容は、なんとなくそうだと思っていたものが言語化された感覚でした。 私でいうとこれはKPIをメンバー毎に振り分けていく時の考え方に近いと思います。大きくざっくり「みんなでこのKPIをおう」みたいな設定をしてしまうと、役割分担が不明確でメンバーが力をだしきれなかったり、終わった時に評価ができないという問題がおきます。 KPIも適切に分解し、そのKPIを追う人が結果をコントロールできる単位にすることが重要です。そのためKPI設計時に上記の考え方をもっていると、よりシャープに設計ができると思います。 ③できるだけ早く試作を作成する リーンスタートアップなどの書籍によって、今やアーリーリリースの重要性は多くの人が認識している状態だと思いますが、数十年前に既にそれが設計思想として定着していた事は驚くべき事だと感じました。 長く生き残っているものの根本思想はやはり優れている（先をいっている）と感じさせてくれ、そういうものから学ぶ事の重要性を再認識させてくれました。 できるだけ早く試作を作成する事自体は私は常に取り組んでいかないといけない事ですが、タイミングによっては徹底できてない事もあります。この件についてはしっかりと意識し、引き続きやっていきたいと思います。 この本を読んで役立った事 エンジニアを理解するという方向で役立った事としては、『 エンジニアの頭の中がどうなっているか 』を想像しやすくなった事があります。 日々の会話のなかで、「要素を小さく分解してるんだな」とか、「過去のプログラムを組み合わせて活用する事を考えているんだな」とかいう想像がついたり、よく言われる「闇」という状態が何となく想像できたりして、この本を読んだことでよりコミニュケーションがとりやすくなったと思います。 またリファクタリングの重要性や価値についてより理解できるようになるので、その工数を取りたいというエンジニアの要求についても合理的に理解できるなどしています。 根本思想を理解することができると、大枠何が正しくて何が間違っているかが判断できるようになり、そのレイヤーでは 共通認識を持つことができます 。それによるメリットはかなり大きいと感じています。 まとめ この本は、エンジニアの考え方について理解する上で非常に役に立つ本です。 また概念を応用することで、私でいえばマーケティングなど、エンジニアリング以外の業務に役立てる事もできると感じます。 エンジニアを理解する上でも、ご自身の仕事の上でも実用的な本だと思うので、ぜひ一読される事をおすすめします。