目次
はじめに
こんにちは、Insight Edgeでエンジニアをしています伊藤です。 「これよくできているな」と言ってもらえるような設計・仕組みを目指して日々のエンジニアリングに取り組んでいます。
今回の記事では私の好物であるシステムアーキテクチャについてPoC(概念実証)の観点から考察してみたいと思います。
Insight Edgeは最先端技術をビジネスに活かすための技術者集団です。 そのため、プロジェクトではPoC(概念実証)としてプロトタイプを作成し、実際の現場・ユーザに試していただくことが多いです。
PoCをすることによって
- 想定しているテクノロジーの使い方で実際にビジネスを変えることができるか
- 役立てるために埋めなければいけないギャップは何か
- 適切にギャップをカバーすることで実際に使えるものができるか
といった観点を確認し、最終的にどんなシステムを作るべきかについての学びを得た上で次のステップへと進みます。
本記事では、本番システムの開発とは異なるPoCならでは特性を品質面を中心に整理しつつ、アーキテクチャに求められる要素について考えてみたいと思います。
PoCとアーキテクチャ
PoCと本番システム開発の違い
PoCの実装もシステム開発の一種であるとはいえ、本番稼働するシステムの開発とは異なる面があるので簡単に整理しておきます。 下記はInsight Edgeでのケースですので、組織やプロジェクトによって状況は異なるでしょう。
| PoC | 本番システム開発 | |
|---|---|---|
| 目的 | どうすれば効果的なシステムになるかの学びを得る | ビジネスに対して効果を出す |
| 優先事項 | 早く検証しフィードバックを得る | 費用対効果 |
| 利用期間 | 数週間〜数ヶ月 | 数年 |
| 運用する人 | Insight Edge内のPoC開発メンバ | 納入先の担当者 |
アーキテクチャとは
アーキテクチャとは、あるシステム(広義のシステム=系)をある観点から見た場合の構成要素・要素同士の関係をモデル化して表現したものです。
本記事では、アプリ内やインフラ構成だけでなく、開発標準やルールといった開発プロセスも含んだ範囲をアーキテクチャとして扱っています。
PoCにおけるアーキテクチャ設計
ソフトウェアシステムのアーキテクチャを設計する目的についてはさまざまな捉え方がありますが、 今回はプロジェクトのQCD(Quality=品質、Cost=コスト、Delivery=納期)の観点から以下の位置づけとしておきます。
システム開発・運用・保守において、 Qualityの最大化、Costの最小化、Deliveryの迅速化を目的にアーキテクチャを定義すること
PoC作成もシステム開発プロジェクトの一種ですので、QCDを考慮する必要があります。
PoCならではの考慮事項があるか、それはアーキテクチャを検討する際にどういった影響があるかをQuality面を中心に検討してみます。
品質(Quality)観点での検討
システムの製品品質についてはISO/IEC 25000シリーズ "SQuaRE" による定義がありますので、これをベースを検討します。
SQuaREの詳細についてはIPA(情報処理推進機構)の 「つながる世界のソフトウェア品質ガイド」 などを参照していただくとして、ここでは概要だけ紹介します。
※IPA:「つながる世界のソフトウェア品質ガイド」より抜粋
それぞれの特性の内容は以下のようになります。
| 品質特性 | 説明 |
|---|---|
| 機能適合性 | 必要な機能を十分に、正しく提供できるか |
| 性能効率性 | システム側のリソースを効率よく使えているか |
| 互換性 | 他システムと円滑に連携できるか |
| 使用性 | ユーザが容易に理解・操作できるか |
| 信頼性 | 安定して動作し、障害から迅速に回復できるか |
| セキュリティ | 不正利用・情報漏洩の防止・追跡ができるか |
| 保守性 | 変更や修正が容易に行えるか |
| 移植性 | 異なる環境へ容易に適用・移行できるか |
それでは、それぞれの品質特性についてPoCの場合を掘り下げてみます。
説明の都合上、取り上げる順序は上記から入れ替えています。
機能適合性
要求された機能を十分に・正しく提供できるか、という観点での品質特性です。
以下の3つの副特性に分けて考えることができます。
| 副特性 | 説明 |
|---|---|
| 機能完全性 | 必要な機能が備わっているか |
| 機能適切性 | 機能・プロセス・手順が無駄のないものになっているか |
| 機能正確性 | 正確に処理・出力しているか |
PoCでは
機能完全性と機能適切性は、機能に過不足がないかという観点の副特性なので、 PoCでは必ずと言っていいほど検証の対象になります。
また機能正確性はPoCの目的により優先度が変わる副特性ですが、 Insight EdgeではLLMや数理モデルを用いたPoCが多いため 「実用上十分な精度を出せるか」という検証は優先度を高くすることが多いです。
しかし今述べた2点については本番システムの一部を切り出して検証しているだけで PoCだから求められる特性というわけではありません。
機能の面で考に、本番システムにはなくPoC開発時だけ求められるものとしては、
- ユーザがどのような操作をしたかを後から確認できるようにする
- 操作後にテストユーザがフィードバックを入力できるようにする
といったものが考えられます。
これらの機能が過不足なく備わっているかどうかが、PoC環境ならではの機能適合性といえるでしょう。
アーキテクチャへの影響
上記のPoC環境としての機能適合性を満たすため、アーキテクチャとしては
- UIフレームワークに操作トラッキングの仕組みを組み込んでおく
- WebAPIアクセス時のURLやパラメータを自動的に記録する
- 操作記録用のログストレージを通常のログとは別に用意する
といった基盤機能の検討が必要になります。
使用性
ユーザが容易に理解・操作できるかという観点です。
PoCでは
使用性は機能適合性と並んで、PoCで頻繁に検証・フィードバックのポイントとなる観点です。
ただし使用性も「本番システムを設計する際の検討事項を一部抜き出し/先取りして検証する」という性質のものなので、PoC時のみに求められる要素は少ないと考えています。
PoC開発時には使用性分析のために、ユーザ操作やフィードバックを記録する機能が欲しくなると思いますが、それらの機能が備わっているかは、前項の機能適合性の観点に含まれます。
互換性
他システムと円滑に連携できるかという観点です。
PoCでは
PoC用のシステムでは、本番システムで予定してる外部連携のうち、検証に必要な部分だけを実装しますが、 テストユーザが多い場合や組織内の権限情報を検証に使いたい場合は、PoC時のみ特定の認証基盤とのユーザアカウントの連携が必要になることがあります。
外部の認証基盤を利用する前提でも、開発者としては外部の認証基盤を使わずに、スタンドアロンでユーザ作成・権限設定・ログインができる仕組みを設けて、素早い動作確認等ができるようにしたくなると思います。
PoCの場合はそのようなバックドア的な仕組みを設けることが許容（というよりも推奨）されるという点も本番システム開発と異なる点です。
その際には、外部認証基盤とスタンドアロンの認証機能がお互い干渉せずに使えるか、も互換性という観点で検討すべき品質となります。
アーキテクチャへの影響
外部のアカウントをテストユーザとして利用する場合は、Microsoft Entra ID(旧 Azure Active Directory)やその他のOAuth2/Open ID Connect対応サービスとの連携を組み込む必要があります。
認証基盤を自前で実装することはほぼなく、クラウドサービス/SaaSを使うことになると思いますが、
前述の通り外部認証基盤とは別にスタンドアロンでのユーザ登録・権限操作をできる必要があり、
PoCシステムの認証基盤選定時には外部認証基盤連携とシステム内ユーザ管理の両方に対応しているかを考慮して検討することになります。
信頼性
安定して動作し、障害から迅速に回復できるかという観点です。 副特性として以下が含まれます。
| 副特性 | 説明 |
|---|---|
| 成熟性 | テスト・もしくは使い込みにより、どの程度正常に動作すると言える状態になっているか |
| 可用性 | どの程度の時間、利用可能か |
| 障害許容性 | 障害発生時にどの程度正常に動くか |
| 回復性 | 中断もしくは故障時にユーザののぞむ状態に復元できる度合い |
PoCでは
PoCでは作成したプロトタイプ自体に高い安定性が求められることは稀ですが、
検証中に入力したデータが障害によって失われてしまうと、そこまでの検証が無駄になってしまう可能性があるので、
データの回復性についてはある程度確保する必要があります。
言い換えると、PoCではRTO(目標復旧時間)に比べRPO(目標復旧時点)の優先度が高いということになります。
またPoCでは通常のシステムと使って操作の期間を指定できる場合もあり、保全すべきデータ断面が本番システムより限定的と言えます。
アーキテクチャへの影響
データ回復性の要件をアーキテクチャに反映しようとすると、 ユーザがPoCを操作する日時を指定できるのであれば適切なタイミングでバックアップを取る仕組みを検討することになります。 また指定できない場合は十分な頻度の自動バックアップをアーキテクチャに組み込む必要があります。
いずれの場合もクラウド上のDB/ストレージサービスであればある程度カバーされていることが多いので、 入力データの重要性・コストのバランスを考えて取得タイミング・バージョン数を追加設定することになるでしょう。
セキュリティ
セキュリティ関連の品質の副特性としては以下が定義されています。
| 副特性 | 説明 |
|---|---|
| 機密性 | アクセス権限に沿ったデータ開示ができているか |
| インテグリティ | システムが不正アクセス・改ざんを防止できるか |
| 否認防止性 | 入力・操作が行われたことを後から証明できるか |
| 責任追跡性 | 誰が行った操作であるか追跡できるか |
| 真正性 | 人・メッセージ・サービス等が本物であることを証明できるか |
PoCでは
PoCでは信頼できるユーザに限られた環境・期間で操作をしてもらうことが多く、その場合はセキュリティについては本番システム開発よりも要求レベルが低くなりますが、 個人情報や部外秘の情報を検証に用いる際には、機密性だけ本番相当の高いレベルを求められる可能性があります。
アーキテクチャへの影響
機密性を確保するためには、大まかに2点、PoC環境自体へのアクセス制御と、ユーザごとのアクセス範囲の管理がアーキテクチャ上の関心事となります。
PoC環境へのアクセス制御については前述のユーザ認証のほか、アクセス元IPアドレスによる制限などが考えられます。これは本番システム構築時に検討する内容と同様です。
PoC時点でユーザ権限別にデータ/機能を制限する必要がある場合は、PoC環境を複数作り同じ権限のユーザ群ごとに別環境を提供することも選択肢となります。
複雑な権限管理を実装せずに済むため、その分の労力を本当に検証したいことに充てることができます。
保守性
保守性は以下の副特性に分解されますが、それぞれPoCでのポイントが考えられるので、個別に検討していきたいと思います。
| 副特性 | 説明 |
|---|---|
| 再利用性 | 作ったシステム・構成要素が他の目的にも利用できるか |
| 解析性 | 不具合の原因を特定しやすいか |
| 変更性 | コードを修正する際に不具合・機能低下のリスクを低く抑えられるか |
| 試験性 | システムのテストをしやすいか |
| モジュール性 | 適切にモジュール化されているか |
保守性:再利用性
作ったシステム・構成要素が他の目的にも利用できるか、という観点になります。
PoCでは
PoCで開発するシステムの再利用性には2つの観点があります。
1つは、PoCで作った機能を本番向けシステムに持っていけるかという点です。 特に数理モデルを構築してのPoCなどは検証したロジックに変更を加えることなく本番システムに反映する必要があり、重要な品質特性となります。
もう1つは、他のPoCを実施する際に流用できるかという点です。 こちらは前者ほどシビアになる必要ありませんが、将来のPoC実施時のコスト低減・実装期間短縮に寄与します。
アーキテクチャへの影響
本番システムへの再利用性を確保するためには、ソフトウェア内のレイヤ分け・コードのディレクトリ分けなどを開発標準として整備し、再利用したいロジックがモジュールとして独立した状態にする必要があります。
Insight Edgeではデータサイエンティストとエンジニアの混成チームで取り組むことがありますが、
このような場合は、事前にメソッドの切り方や引数・戻り値まで定めておくことで、
お互いの作成するロジックに影響を与えることなくスムーズに分担できるようになります。
また、他のPoCで再利用できるようにするという観点では、PoCでよく使う機能・構造を部品やテンプレートとして用意しておくことが考えられます。 その際は、本記事でそれぞれの品質特性に対して検討した内容がテンプレートに取り込む要素の候補になるでしょう。
保守性:解析性
不具合の原因を特定しやすいか、という観点です。
PoCでは
PoCでは予定していなかった操作・入力データに出会い、それを分析することが重要な要素です。
通常、使用状況の把握/不具合の調査に使える情報の量とログ保管容量/コストはトレードオフの関係になりますが、
PoCは本番システムに比べるとデータ量が少ないため、分析のトレーサビリティに振り切るという選択が可能です。
アーキテクチャへの影響
機能適合性についての検討でユーザ操作の記録をPoC環境の基盤機能として検討しましたが、不具合時の解析性ではリソース使用状況のメトリクスとログも重要な情報となります。
メトリクスについてはクラウドサービスを使っている場合はCPU/メモリ等のリソース使用状況を取得する設定ができると思いますので、PoCに合わせた設定値を検討して環境構築時に確実に適用できるよう管理しましょう。
ログについては効果的なログの取得タイミングが開発ガイドラインとして整備されていると良いでしょう。
またログのフォーマットとしては構造化ログを採用しましょう。主要なクラウドのログ管理サービスは構造化ログに対応していますので、適切にフィールドを使えば、多量のログの中からでも必要な情報を見つけやすくなります。
Insight Edgeではカスタムのログライブラリを作成し、ログの取り扱いの労力を減らしています。
保守性:修正性
コードを修正する際に不具合・機能低下のリスクを低く抑えられるかという観点です。
PoCでは
PoCでは「フィードバックをもとに改修を加えて再度検証する」というサイクルを何回か実行することがあり、素早く安全に修正できることが求められるますが、本番システムも同様に素早く安全に修正できるべきなのでPoC開発だけの品質要件というわけではありません。
保守性:試験性
試験性はシステムのテストをしやすいかという観点です。
PoCでは
PoCでは2つの面から試験性を捉えることができます。
1つは開発者が修正した内容を素早く確認でき、PoC環境へデプロイ可能な状態にもっていけるかという点です。 これはPoCに限らず本番システム開発でも求められる特性となります。
もう1つは、PoC自体が一種のテストなので 検証したい内容を正しく実施・検証できるようになっているかという点です。 検証に必要な機能が備わっているかという、機能適合性について検討することでカバーされます。
保守性:モジュール性
適切にモジュール化されているかという観点です。
PoCでは
適切なモジュール化はこれまで述べてきた保守性の全ての副特性に関わる要素です。
PoCごとにそれぞれの副特性の観点で検討することにより「適切なモジュール化」が決まります。
モジュール化を目的とするよりも、それによって達成したい特性からどのようなモジュール構造にするべきかを検討し、アーキテクチャへ反映する形となります。
性能効率性
システム側のリソースを効率的に使用できているかという観点です。
PoCでは
PoC段階で検証の主役になることはあまりないでしょう。
移植性
移植性には下記が含まれます
| 副特性 | 説明 |
|---|---|
| 適応性 | 多様な環境をターゲットにしている場合に適用できるか |
| 設置性 | インストール・アンインストールのしやすさ |
| 置換性 | 別の製品で置き換えられるか |
PoCでは
PoCはそもそも本番に向けて細部・周辺を更新することを前提としているので、 完成品を他の環境に持っていけるかというでPoC開発時に検討する意味は薄いと考えられます。
品質特性に対するまとめ
ここまでSQuaREで定義された製品品質ごとにPoC用システムで求められる要件・アーキテクチャについて考察してきました。
PoCという一時的な取り組みのためのシステム開発であっても、それぞれの製品品質の観点で検討することで、本番開発と異なる点を発見しアーキテクチャ設計時の考慮事項を言語化できたように思います。
コスト(Cost)・納期(Delivery)も考えると
ここまで品質:Qualityの面で検討しましたが、PoCはプロジェクトとして実行されるので、当然コスト・納期も重要な要素となります。 上記の品質面で検討した内容と、コスト・納期のバランスを取るにはどのようなアーキテクチャ設計上の判断が可能でしょうか。
既存システムからの流用
1つには、チームメンバがよく知っているアーキテクチャパターンを採用、もしくはチームが管理している他のシステムから流用することが考えられます。
ここまで品質面から検討してきたアーキテクチャの要素と一致しない部分も出るためPoCとしての要件に対して最適ではない可能性もありますが、 短期間・検証目的というPoCの位置付けを考えると、品質の妥協によるデメリットよりもコスト・時間を省力できるメリットの方がインパクトが大きいと考えられます。
また品質に関しても、すでに理解が進んでいるインフラ・アプリ構成となることで既存システムに関わるチームメンバにとっては保守性が高い状態となりますので、トレードオフ検討時にはその点も考慮に入れる必要があります。
共通機能の整備
もう1つ、組織としてPoCを頻繁に行うならば、PoCに特化したアーキテクチャ部品を再利用可能な形で持っておくことが考えられます。 システム全体のアーキテクチャのうち、Dev(Sec)Opsにあたる部分、
- CI/CDの仕組み
- 監視の仕組み
- モニタリングの仕組み
などはPoCの内容が変わっても共通であることが多いです。
これらを意識的に再利用し適宜アップデートをして整えていくことで、 PoC時には検証したい機能・UI等の実装にリソースを集中できるようにすると良いでしょう。
まとめ
今回は各品質特性についての考察を中心にPoCならではの特性・アーキテクチャ設計時の考慮事項を検討してみました。
元々なんとなくプロトタイプの設計時に対応していたものも多いですが、 言語化したことで抜け漏れなく検討できるようになったように思います。
それぞれの企業、チーム、プロジェクトによって状況などは異なると思いますので、 アーキテクトの皆様の検討の枠組み・叩き台として参考になれば幸いです。
