ソフトウェア要件仕様とモックアップが企業の時間とコストを節約する方法
ITプロジェクトの70%が、計画段階のミスが原因で予算超過または完全に失敗していることをご存知ですか？Standish Group (2023)によると、主な原因は明確なビジネス要件と製品の視覚的な表現の欠如です。そこで、ソフトウェア要件仕様書（SRS）とモックアップが役立ちます。この2つのツールは、 ソフトウェアコンサルティング 同社は、製品開発とテストの混乱を管理可能なプロセスに変えるためにこのツールを使用しています。
優れたソフトウェア要件仕様書（SRS）は、単なる形式的なものではなく、あらゆる開発プロジェクトの成功の基盤となります。適切に作成されたソフトウェア要件仕様書（SRS）は、ソフトウェアシステムが何を実行すべきか、ユーザーやシステムとどのように相互作用するか、そしてどのような品質基準を満たすべきかを詳細に規定します。
例えば、カリフォルニアのあるスタートアップ企業は、些細なミスが原因で$10万ドルの損失を被りました。チームは承認済みのSRS（設計・開発・品質保証）なしにコードを書き始めたのです。その結果、顧客は期待に応えられない製品を受け取り、再開発に3ヶ月もかかりました。
一方、モックアップは、プログラミングを始める前にアイデアを視覚化します。これにより、設計、論理インターフェース、ユーザーシナリオを調整することができ、これはIT開発において特に重要です。モックアップがなければ、ビジネスプロセスにおけるソフトウェアの役割が歪められ、後工程でのエラー修正にかかるコストが10倍から100倍にもなる可能性があります（IBM、2021年）。ソフトウェア要件定義は不可欠です。
SRSとモックアップがどのように時間と予算を節約し、開発プロセスに関わるすべての関係者の負担を軽減するのかを見てみましょう。以下の点を学びます。
- 請負業者との衝突を避けるための SRS アウトラインの書き方。
- 機能要件と非機能要件がなぜ重要であり、同等に重要なのか。
- 効果的な SRS ドキュメントを作成するためにトップ企業が使用するツール。
次の IT プロジェクトを成功させる準備はできていますか? まずは基本から始めましょう。
ソフトウェアコンサルティング
ソフトウェアコンサルティングは、企業が開発プロセスを効率化し、効果的に目標を達成する上で重要な役割を果たします。 ソフトウェアコンサルティング会社 堅牢なソフトウェアアーキテクチャの構築、ベストプラクティスの実装、そしてコストのかかるミスの回避方法について、専門家のアドバイスを提供します。ソフトウェアコンサルティングにおける主要な注力分野の一つは、ソフトウェア要件仕様（SRS）とモックアップの開発です。これらのツールは、ソフトウェア開発プロセスを構造化かつ効率的に維持し、企業の時間を節約し、開発中の高額なエラーの発生リスクを低減します。
例えば、Standish Group (2023) によると、ITプロジェクトの70%は要件が明確でないために失敗したり、予算超過に陥ったりしています。SRSは単なる官僚的な文書ではなく、機能要件と非機能要件の両方を網羅したソフトウェア開発の詳細な青写真として機能します。ソフトウェアコンサルティング会社やSRSコンサルティングと連携することで、企業は不十分な計画や明確に定義されていない目標といったよくある落とし穴を回避し、最終的にはプロジェクトの予算とスケジュールを守ることにつながります。
プログラミング段階の前にアイデアを視覚的に表現するモックアップは、もう一つの貴重なツールです。デザイン、ユーザーエクスペリエンス、機能要件の整合性を確保するのに役立ちます。これらのビジュアルにより、関係者は製品が期待どおりであることを検証でき、後々コストのかかる再設計のリスクを軽減できます。
ソフトウェアコンサルティングは、企業が自社のソフトウェアニーズをより明確に理解し、複雑なITプロジェクトを円滑に進め、成功へと導くための支援を提供します。SRSコンサルティングは、ソフトウェア要件を正確かつ適切に文書化し、リスクを最小限に抑え、開発作業をビジネス目標と整合させることで、このプロセスをさらに強化します。
SaaS開発
SaaS（Software as a Service）開発とは、ローカルマシンにインストールするのではなく、オンラインでアクセスできるクラウドベースのソフトウェアアプリケーションを開発するプロセスです。SaaSプラットフォームは、インターネット接続があればあらゆるデバイスからアクセスできる、スケーラブルなサブスクリプションベースのソリューションを企業に提供します。SaaS開発の主なメリットは、初期費用の削減、自動更新、他のシステムとの容易な統合などです。 SaaS開発 ユーザーフレンドリーなインターフェース、セキュリティ、そして増大するユーザーベースに対応するための高可用性とスケーラビリティの確保に重点を置いています。
SRS ドキュメント: ソフトウェア製品エンジニアリングにおける役割
ソフトウェア要件仕様書：成功するプロジェクトの基礎
SRS（ソフトウェア要件仕様）ドキュメントは、顧客と開発チームの間で締結される正式な合意文書であり、ソフトウェアプロジェクトの目的、動作方法、そしてどのような条件下で実現されるかを詳細に記述します。これは単なる要望リストではなく、誤解を解消しリスクを軽減するプロジェクトの「バイブル」と言えるでしょう。IEEE 830規格によれば、優れたソフトウェア要件仕様（SRS）には、明確な目標、機能要件、パフォーマンス基準、そしてシステム制約が含まれており、ソフトウェア要件開発を成功させるための基盤となります。
- 目標と範囲 - 製品が作成される理由。
- 機能要件 — システムが実行すべきこと (例: 「ユーザーはファイルをアップロードできる」)。
- 非機能要件 - システムがどのように機能するか (パフォーマンス、セキュリティ、互換性)。
- インターフェース - 外部システムおよびユーザーとの対話。
- 制約 - 技術的またはビジネス上のルール。
例: モバイル バンクのプロトタイプ ソフトウェア要件仕様には、2 要素認証とデータ暗号化を指定する「セキュリティ要件」セクションが含まれています。
機能要件と非機能要件：比較分析
ソフトウェア エンジニアリングでは、要件は次の 2 つのタイプに分けられます。
| 基準 | 機能要件 | 非機能要件 |
| エッセンス | システムが実行する処理（例：「注文の作成」）。 | システムの動作方法（例：「応答時間≤ 2秒」）。 |
| 例 | 承認、商品検索、支払い。 | 信頼性、拡張性、使いやすさ。 |
| 予算への影響 | 作業範囲を定義します。 | アーキテクチャとインフラストラクチャに影響を与えます。 |
機能要件は、製品のコアロジックを定義します。例えば、eコマースアプリケーションでは、「ショッピングカートは商品を24時間保持する必要がある」といった機能が考えられます。
ただし、非機能要件は多くの場合「命の恩人」として機能します。
ケーススタディ：フィンテックスタートアップが SRS文書 「システムは1秒あたり5,000件のトランザクションを処理する必要がある」という要件。負荷が増加しても、この要件によりシステム障害や顧客損失を防ぐことができました。
非機能要件を無視することのコスト
これらを軽視するのはよくある間違いです。HealthCareSoftは2022年、バックアップを必要としないクリニック向けのソフトウェアアプリケーションをリリースしました。
結果：サーバークラッシュにより10,000件の患者記録が削除されました。復旧には$2百万と6か月かかりました。
結論：SRSドキュメントは官僚主義ではなく、予測可能性への投資です。抽象的なアイデアを開発チームへの明確な指示に変換し、予期せぬ事態から予算を守ることができます。
SRS ドキュメントの作成: 手順とツール
SRS を作成するためのステップバイステップガイド
SRSの作成は一見複雑に思えるかもしれません。では、SRSドキュメントに何を含めるべきか、そして混沌としたアイデアを構造化されたドキュメントへと変えるための4つのステップを詳しく見ていきましょう。
- 要件収集
- クライアントインタビュー、市場調査、ユーザーシナリオ分析を実施します。
- 機能要件（「システムが何をするか」）と非機能要件（「どのように行うか」）の両方を取得します。
- 例: オンライン バンキング製品の場合、要件にはセキュリティ、リクエスト処理速度、支払いシステムの統合が含まれます。
- 分析と優先順位付け
- 要件が互いに矛盾したり、ビジネス目標と矛盾したりしないことを確認します。
- MoSCoW メソッド (Must have、Should have、Could have、Won't have) を使用します。
- ドキュメント
- SRS テンプレート (IEEE 830 標準など) を使用して要件をフォーマットします。
- 含めるセクション: 概要、機能要件と非機能要件、インターフェース、制約。
- 承認
- ドキュメントをクライアントと開発チームに合わせて調整します。
- 例: SRS ドキュメントは、コーディングを開始する前に関係者の承認を得る必要があります。
SRS開発のための自動化ツール
SRS プロセスを簡素化するには、以下を使用します。
- Jira – 要件とタスクを追跡します。
- Confluence – SRS ドキュメントを保存し、共同編集します。
- Helix ALM – バージョン管理とテスト用。
これらのツールは、データ損失のリスクを軽減し、要件管理を高速化します。
失敗したSRS実装の例
ベルリンを拠点とするスタートアップ企業が倉庫管理ソフトウェアを開発しました。時間的な制約から、チームは外部インターフェースの詳細な要件を省略しました。その結果、次のような問題が発生しました。
- 開発者は仮定に基づいてシステムを構築しました。
- UI が従業員のニーズを満たしていないため、クライアントは製品を拒否しました。
- 再設計には$30,000と2か月が費やされました。
結論: SRS の手抜きがプロジェクトの失敗につながりました。
SRSエラーがなぜ高額になるのか
IBM の調査によると、バグの修正にかかるコストは時間の経過とともに大幅に増加します。
- 設計段階で発生したバグを修正: $1。
- テストフェーズ中：$15。
- 発売後：$100+。
出典: IBM Systems Sciences Institute、2023 年。
結論：SRSとシステム要件ドキュメントは、単なる官僚主義ではなく、経済的損失に対する保険です。SRSドキュメントの作成に時間を投資することで、プロジェクトを予期せぬ高額なコストから守り、ソフトウェア開発プロセスを加速させることができます。
IT 開発: SRS ドキュメント機能
IT開発は単なるコードの作成にとどまりません。常に進化するデジタル環境で動作する製品を開発することです。デスクトップアプリケーションとは異なり、Webプロジェクト（SaaS、eコマース、企業ポータルなど）には、次のような特有の課題が伴います。
- スケーラビリティ – システムはトラフィックの増加に対応する必要があります。
- クロスブラウザ互換性 - Chrome、Safari、Firefox で一貫した表示。
- 統合 – 支払いシステム、CRM、分析ツール。
たとえば、SaaS プロジェクト管理プラットフォームの SRS ドキュメントには、「システムは遅延なく 1,000 人の同時ユーザーをサポートする必要があります」という要件セクションが含まれている場合があります。
SaaS および E コマース向け SRS 機能
- SaaS ソリューション:
- 非機能要件の種類に焦点を当てます: データ セキュリティ (暗号化、ロールベースのアクセス)、99.9% の稼働時間。
- 例: クラウドベースのテキスト エディターの SRS では次のように指定できます。
「2分ごとに自動保存します。」
- 電子商取引ウェブサイト:
- ヘッダー: ロゴ、検索バー、カートアイコン。
- 製品セクション: 価格、カテゴリ、評価でフィルタリングします。
- フッター: 連絡先の詳細、ソーシャル メディア リンク。
- UI/UX 要件の重視: ユーザーフレンドリーなショッピング カート、PayPal/Stripe の統合。
- ケーススタディ: 電子商取引サイトのメインページレイアウトには次のものが含まれます。
この構造は、開発が始まる前に開発者とクライアントの間の期待を一致させるのに役立ちます。
ソフトウェア開発アウトソーシング：成功事例
オランダのスタートアップ企業がオンライン教育用のSaaSプラットフォームを構築していました。社内リソースが不足していたため、アウトソーシング開発を選択しましたが、まず以下の点に留意しました。
- 機能 (ビデオ ウェビナー、クイズ) とセキュリティ コンプライアンス (GDPR) を指定した詳細な SRS を作成しました。
- 類似プロジェクトからのベンチマーク要件が含まれています。
- 定義されたパフォーマンス期待値: 5,000 人の同時ユーザーをサポートします。
結果：
- 請負業者は、タイムラインと予算を正確に見積もりました (当初の $200K ではなく $150K)。
- 最終製品は、最初の試みでセキュリティ監査に合格しました。
- このスタートアップは、明確に定義された MVP と SRS の調整により、$2M の投資を確保しました。
SRS が IT 開発における秘密兵器である理由
- クライアント向け: 抽象的なアイデアを明確な技術仕様に変換し、信頼できない請負業者から保護します。
- 開発者向け: 修正や誤解を減らします。
重要なポイント：アウトソーシング開発は、詳細なSRS（仕様書）がある場合に限り有効です。SRSがなければ、ビジネスニーズを満たさない製品が提供されるリスクがあります。
非機能要件: SRS の主要要素
ローカルサーバーでは完璧に動作するアプリが、100人のユーザーがオンラインの状態でクラッシュする、あるいはリリースから1週間後にハッキングされる、そんな状況を想像してみてください。これらは架空の恐怖物語ではなく、非機能要件（NFR）を無視した現実世界の結末です。たとえ機能に問題がなかったとしても、「隠れたフレームワーク」がなければ、製品は失敗に終わります。
非機能要件 (NFR) とは何ですか?
NFRは、システムが何をするかではなく、どのように動作すべきかを定義します。主なカテゴリには以下が含まれます。
- パフォーマンス - 応答時間、サーバー負荷容量。
- セキュリティ - データ保護、認証。
- スケーラビリティ - コードを書き直すことなく拡張できる能力。
- 使いやすさ - ユーザーフレンドリーなインターフェース設計。
例: オンライン バンキング システムでは、機能要件は送金と支払いをカバーし、非機能要件はデータの暗号化と DDoS 攻撃への耐性を保証します。
ケーススタディ：NFRを無視することで$2Mが無駄になった
2021年、あるEdTechスタートアップ企業がオンラインコースプラットフォームを立ち上げました。彼らのSRS（サービス提供基準）は詳細な機能要件（ビデオ講義、クイズなど）をカバーしていましたが、パフォーマンス要件は考慮されていませんでした。
結果：
- 同時ユーザー数が 500 人に達したため、サーバーが過負荷状態になりました。
- 動画が 10 ～ 15 秒間バッファリングされ、大量のユーザー離脱を引き起こしました。
- 緊急インフラ最適化には $2M の費用がかかり、4 か月かかりました。
結論：NFRはオプションではなく、安定性の基盤である
SRS で非機能要件を定義するにはどうすればよいでしょうか?
- 抽象的ではなく、具体的に
- ❌ 悪い例:「システムは高速でなければなりません。」
- ✅ 良い例: 「同時ユーザー数が 1,000 人の場合、ページの読み込み時間は 2 秒以下である必要があります。」
- 標準を使用する
- セキュリティ：GDPR、ISO 27001。
- パフォーマンスの場合: SLA (例: 稼働時間 99.9%)。
なぜこれがアウトソーシングにとって重要なのでしょうか?
ソフトウェア開発をアウトソーシングする場合、SRS で NFR を定義します。
- ベンダーが適切なテクノロジー (スケーラビリティのためのクラウド ソリューションなど) を選択できるように支援します。
- 受け入れテスト中の紛争（「負荷要件を指定していない！」）を防止します。
- 予算を節約 – 後でアーキテクチャ上の間違いを修正すると、10 ～ 20 倍のコストがかかります。
結論：機能要件は「何を？」という問いに答え、非機能要件は「どのように？」という問いに答え、そして「どの程度うまく？」という問いに答えます。非機能要件を無視することは、基礎なしで家を建てるようなものです。最も重要な時に製品の不具合を回避するために、SRSは必ず両方を網羅するようにしてください。
ソフトウェア開発のアウトソーシング：SRSの役割
プロジェクトを外部チームにアウトソーシングしたところ、1ヶ月後には全く期待と異なるものができあがっていたとしたらどうでしょう。身に覚えがあるのではないでしょうか？これは、詳細なSRS（設計・開発・仕様書）を作成せずにアウトソーシングした場合によく起こることです。
SRS がアウトソーシング契約における「盾」となるのはなぜでしょうか?
SRS は単なる希望リストではなく、次のような法的に重要な文書です。
- 要件を固定し、両者が同じ目標を持つことを保証します。
- 操作のリスクが軽減されます。請負業者は不要な機能を「デフォルトで」強制できなくなります。
- テストの基礎として機能し、明確な基準に従って承認が行われます。
たとえば、SRS に「ソフトウェアは 1 分間に 100 件の注文を処理する必要がある」と記載されているにもかかわらず、請負業者が 50 件の注文しか処理できないシステムを納品した場合、これは契約の直接的な違反となります。
ケーススタディ: SRS が $50k と会社の評判を救った方法
バルセロナのスタートアップ企業が、フィットネストラッカーのモバイルアプリのソフトウェア開発をアウトソーシングしました。抽象的な技術仕様書の代わりに、次のような内容を提供しました。
- インターフェース例を含む詳細なソフトウェア要件仕様 (SRS)。
- パフォーマンス要件: Apple Health とのデータ同期は 3 秒以内。
- 非機能要件: 24 時間の自律動作。
結果：
- 請負業者は隠れた修正で予算を膨らませることはできませんでした。
- 最終的なプロジェクトコストは市場平均より $50K 低くなりました。
- このアプリは、よく考えられた UX のおかげで、App Store で 4.8 つ星を獲得しました。
SRSなしでアウトソーシングする場合の5つのリスク
時間を節約するために SRS の作成を省略することにした場合、次のようなことが起こります。
- 期限の変更 – 明確な要件がなければ、時間と予算の見積りは推測になってしまいます。
- 承認時の衝突 – 「依頼通りにやった！」 vs. 「これは私たちが望んでいたものではない！」
- 技術的負債 – 請負業者は、コストのかかるやり直しが必要となる安価なソリューションを使用する場合があります。
- 知識の損失 – チームが離脱すると、新しいチームは製品の開発方法を理解できなくなります。
- 法的リスク – SRS を参照せずに紛争を解決することはできません。
自分を守るには？
ソフトウェア開発をアウトソーシングする場合は、次の 3 つの手順を実行します。
- SRS の作成に投資しましょう – 2 ～ 3 週間かかりますが、数か月分の作業を節約できます。
- 請負業者がすべての要件を理解し、同意していることを確認してください。
- すべてのプロジェクトマイルストーンで SRS をチェックリストとして使用します。
覚えておいてください：SRSは官僚主義ではありません。重要な管理ツールです。プロジェクトを予算のブラックホールに陥らせないでください！
SRSとワイヤーフレーム – ITプロジェクトの保険
すべてのプロジェクトが予定通り、予算内で、期待通りに開始されることを想像してみてください。これはユートピアではなく、ソフトウェア要件仕様（SRS）とワイヤーフレームに投資する人にとっては現実です。これらのツールは保険のような役割を果たします。すべてのリスクを排除できるわけではありませんが、財務への影響を最小限に抑えることができます。
IBMによると、計画に投資された$1ごとに、リリース後のバグ修正にかかる$15のコストが削減されます。SRSは抽象的なアイデアを明確な指示に変換し、ワイヤーフレームはコードを1行も書く前にコンセプトを視覚化します。これらを組み合わせることで、以下のメリットが得られます。
- 修正の必要性を 60～70% 削減します。
- 請負業者の承認を迅速化します。
- より正確な ROI 予測を可能にします。
SRS を省略するとどうなるでしょうか? 曖昧な要件、終わりのない修正、期限の遅延、そして最終的には 40–200% の予算超過に陥ります。
結論
よく構成された ソフトウェア要件仕様 SRS（Software Defined Revision：ソフトウェア仕様書）ドキュメントは、ソフトウェアが何を実行すべきかを説明し、開発に必要な要件を詳細に記述することで、ソフトウェアがビジネスニーズを満たしていることを保証します。SRSは、ソフトウェアが動作する際に適用される制約を含む、機能要件と技術要件を正確に概説した包括的なソフトウェアユースケースを提供します。SRSドキュメントを作成することで、ソフトウェア開発プロセスにおけるプロジェクトマネージャーは要件を効果的に管理し、ドキュメントとソフトウェアの最終的な実装との間の差異を減らすことができます。
既存のSRSは新規プロジェクトの参考資料として活用でき、SRSのアウトライン例は要件管理プロセスの標準化に役立ちます。ソフトウェア開発をアウトソーシングしようとしている企業は、外部チームとの契約前にSRSを完成させることで、透明性を確保し、コストのかかる修正を削減できます。クラウドベースのドキュメント管理システムを開発する場合でも、その他の複雑なソリューションを開発する場合でも、強力なSRSドキュメントを作成することで、システムとソフトウェア開発のプロセスが効率化され、最終的には時間とコストを節約できます。
開発を宝くじのように無駄にするのはやめましょう。Camel ExpertのプロフェッショナルにSRSの作成をお任せください。アイデアの具体化、ワイヤーフレームの作成、そして適切な業者の選定まで、お手伝いいたします。その結果、最大40%の予算を節約し、競合他社よりも早く製品をリリースできるようになります。
失敗を未然に防ぐことができるのに、なぜ費用をかけてミスをするのでしょうか？まずは計画から始めましょう。計画こそが、投資が確実に報われる唯一の段階です。
付録：SRS自己検証チェックリスト
チェックリスト 1: 要件の完全性
✅ すべての機能要件が明確に説明されている（例：「ユーザーは Google 経由で登録できる」）。
✅ セキュリティ、パフォーマンス、スケーラビリティなどの非機能要件が指定されています。
✅「外部インターフェース要件」セクションが含まれています（UI/UX、クロスブラウザ互換性）。
✅ 制約が文書化されています (例: Windows 10 以降との互換性)。
✅ 主要機能のユーザーシナリオ（ユースケース）が提供されます。
✅ クライアントのすべてのビジネス目標が考慮されます。
チェックリスト 2: 適切な SRS ドキュメント構造
✅ SRS テンプレートが使用されます (例: IEEE 830 または ISO/IEC/IEEE 29148)。
✅ ドキュメントには以下が含まれます:
- 概要 (目的、ソフトウェアの使用例と役割のセット)。
- 機能要件と非機能要件。
- インターフェース (API、ハードウェア/ソフトウェア統合)。
- 制約と依存関係。
同様のプロジェクトの SRS 仕様の例が含まれています。
要件には一意の ID (例: FTR-001、NFR-005) が番号付けされます。
チェックリスト3: 一貫性チェック
✅ 矛盾する要件はありません (例: 「システムはオフラインで動作する必要がある」と「常時インターネット接続が必要」)。
✅ パフォーマンス要件は技術的な制限と一致しています (例: 共有ホスティングで「10,000 リクエスト/秒」は非現実的です)。
✅ システム要件仕様は SRS と同期されます (例: サーバー容量はワークロードと一致します)。
チェックリスト4：アウトソーシングの準備
✅ SRS には受け入れ基準が含まれています (例: 「5,000 人の同時ユーザーをサポートする」)。
✅ セキュリティ標準が指定されています (GDPR、ソフトウェアの ISO 27001)。
✅ ドキュメントの要件が概説されています (例: 英語のユーザー マニュアル)。
✅ 用語集のすべての用語が明確に定義されています (例: 「自律動作」 = 充電なしで 24 時間)。
チェックリスト5: 要件の検証
✅ プロジェクトマネージャーおよび関係者へのインタビューが実施されました。
✅ 要件はユースケースシナリオを通じてテストされます（例：「登録 → 支払い → 配送」）。
✅ Web 開発仕様が考慮されます: SEO、モバイル適応、キャッシュ。
✅ 要件管理ツールが使用されます (Jira、Helix ALM)。
チェックリスト6: SRS品質評価
✅ 強力な SRS は次の基準を満たしています:
- 完全性: 欠落した機能はありません。
- 明確さ: 曖昧な解釈はありません。
- テスト可能性: 各要件を検証できます。
サポートドキュメント (技術仕様、API ドキュメント) への参照が含まれています。
ドキュメントはすべての関係者 (開発者、クライアント、テスター) によって承認されます。
チェックリスト7: 開発の準備
✅ 明確なソフトウェア要件が開発プロセスと一致しています。
✅ ソフトウェア エンジニアリングに適した方法論 (アジャイル、ウォーターフォール) が選択されます。
✅ 変更を加えることができるライブ ドキュメントが維持されます (例: Confluence + Jira)。
チェックリストの使い方:
- SRS ドキュメントの作成と照らし合わせて各ポイントを確認します。
- 答えが「いいえ」の場合は、続行する前に SRS を修正してください。
- ソフトウェア開発の場合、契約の一部としてチェックリストを請負業者に提供します。
例：
電子商取引 Web 開発プロジェクトの場合は、以下を確認してください。
- SRS (機能要件) に PayPal 統合について記載されていますか?
- ページの読み込み時間は 2 秒以下と指定されていますか (非機能要件)?
