なぜ技術要件文書を作成するのですか?
Rachel S. Smith, author of Writing a Requirements Document, explains that a technical requirement document, “Presents why a product is needed, puts the product in context, and describes what the finished product will be like.” For software projects, a technical requirements document generally refers to how the software will be built including the operating system it is being programmed for and other standards.
技術的要件文書を作成しないと、実際の問題が発生する可能性があるというスミス氏は言います。これらの問題には、以下が含まれます。
- 本当のニーズを満たさない製品を構築してしまう。
- 「機能クリープ」の発生。
- チームの一人のグループがアリを作っていると思い、別のグループはゾウを作っていると考えます。
Renee Fellman, a Portland, Oregon-based business expert who specializes in turning around businesses on the brink of failure, has found that failure to adequately document technical requirements can cause serious problems for a company that impact their bottom line.
Problems that arise from not having technical requirements documentation can range from simple to complex. “In one company I consulted for,” Fellman said, “Vital FDA compliance issues weren’t being addressed because human resources had failed to do something as simple as assign the duty of taking care of regulatory affairs.”
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
技術要件文書の価値
技術的要件文書を使用すると、プロジェクトや製品を成功させるために必要なもの、技術的には何が必要かをチームが相互に理解できます。プロジェクト管理の 5 つのフェーズのうち、プロジェクトのライフサイクルのフェーズ 2 で技術的要件文書を作成する必要があります。このフェーズでは、プロジェクトのスコープが定義され、目標が設定されます。技術的要件文書には、次の情報も提供されます。
- 予算を決定します。
- 作業分解スケジュールを作成します。
- プロジェクト ガント チャートを作成します。
- コミュニケーション計画を開始します。
- リスク管理の側面を定義します。
技術要件書作成者の期待
技術的要件文書を作成する人は誰でも、「優れた」システム要件を構成し、この情報を明確な方法で伝える方法を理解する必要があります。
- 次のことに留意してください。
- 技術的な要件を分析し、常にビジネス ニーズを基本的な基準点として使用する際に、探索するソースについてクリエイティブにしましょう。
- わかりやすい言葉を使って、他の人があなたの結果を理解できるように支援する
- プロトタイプを使って何が足りないのかを把握する
- 含める内容を決定する際には、相互関係、優先順位、コスト、実施、環境への影響を理解していることを確認してください。
- システム境界の定義
ビジネスでよく見られるその他の種類の要件文書
技術的要件の最初のリストを決定する際には、社内の他のチームも準備している他のドキュメントがあることを認識してください。これらのドキュメントは同じプロジェクトに関するものですが、オーディエンスは異なります。これらのドキュメントの一部に冗長な情報が含まれている可能性が高いです。一部の項目は、ビジネスや市場要件文書ではなく、技術要件文書に含まれていると感じるかもしれませんが、心配しないでください。目的に最適な技術要件書を作成するのはあなた次第です。最も役に立つ情報を確実に収集してください。
Accompa の製品管理担当バイス プレジデントである Michael Shrivathsan は、要件文書とその機能の種類に関する専門家です。
“There can be some overlap between business, market, and technical requirement documents,” said Shrivathsan. “Depending on the organization, they may or may not use all these document types. At large companies (1,000 employees plus), they typically do use all three of these docs. Most mid-sized companies (200 employees or more) use at least two of them.”
これらの他のレポートには、技術的要件文書を使用して通知、影響を与える、または不測の事態を引き起こす可能性のある重要な情報が含まれる場合があります。ここでは、プロジェクトをサポートするために他の部門によって作成されるその他のドキュメントをいくつか紹介します。
書かれたビジネス要件文書 (BRD)
: 製品マネージャー、製品マーケティング マネージャー
オーディエンス: ビジネス マネージャー
レビューと承認: C レベルのエグゼクティブ
ビジネス要件文書は、プロジェクトの大まかなビジネス ケースを定義し、通常は最初に準備されます。
ビジネス要件文書は、ビジネスの観点からプロジェクトの目標を定義します。このフェーズのドキュメントでは、ビジネス目標を大まかなレベルで説明します。このチームのメンバーは、あなたのビジネスと顧客のニーズの両方に焦点を当てた必要なビジネス情報を収集するために、あなたの会社やクライアントの会社で適切なビジネス マネージャーと会う必要があります。
ビジネス要件文書から、技術的要件文書に役立つ以下の情報を学ぶことができます。
- 顧客のニーズの性質
- これらのニーズを満たすことが、会社のミッションとどのように一致しているか
- 製品、システム、ソフトウェアが顧客のニーズを高いレベルでどのように解決するか
- 明確にするために、適切なフロー、組織図、または図を通じて、プロジェクトのすべての関係者間の関係を肖像化することが推奨される
市場要件文書 (MRD)
によって作成: 製品マネージャー、製品マーケティング マネージャー
オーディエンス: ビジネス マネージャー
レビューと承認: ディレクターレベル
A 市場要件文書は、市場が何を必要としているかという点で、BRD に情報を追加し、開発中の製品やプログラムなどの現在の市場状況を特定します。すでに何が出ているのか、どのように市場に出ているのか、誰に何かを知ることで、他の製品機能のギャップを判断するのに役立ちます。
市場要件文書から、技術的要件文書に役立つ以下の情報を学ぶことができます。
- 計画されている製品の種類
- ターゲットにされている顧客
- 定義するペルソナ:
- 顧客特性
- 彼らが直面する課題
- 提案された製品がこれらの課題の解決にどのように役立つのか
- 競合製品とそのメリットとデメリット
- あなたの製品がより良くなる方法
あなたの会社の誰も上記のレポートを準備していない場合は、製品が存在する宇宙を把握するために、足の追加作業を行う必要があるかもしれません。
技術的要件は、望ましい結果に焦点を当てる必要がある
ソフトウェア開発の技術的要件には、開発計画、技術アーキテクチャ、ソフトウェア テスト、展開などのコンポーネントが含まれます。フェルマンは、優れた技術的要件の文書化は、あなたが望む結果に焦点を当てることから始まり、プロセスに過度に焦点を当てることではないと助言しています。なぜでしょうか。なぜなら、どこに行きたいかによって、そこに行く方法に関するすべてを決めるからです。たとえば、エベレストの頂上に到着するためにラクダを連れて行くことはないでしょうが、最終的な目標がエジプトの砂漠の古代の墓に到達することならば、あなたは乗るかもしれません。
フェルマンは、「技術的要件文書の準備を始める前に適切な質問をしないと、解決しようとしている問題を実際に解決できない文書につながる可能性があります」と警告しています。
もちろん、質問は顧客、会社、意図するサービスや製品によって異なりますが、技術的要件文書では、特にユーザーの観点から、新しいシステムやソフトウェアに何を達成してほしいかを探ります。開発者と相談し、開発者の視点から、何が実行可能で、何がそうでないのかを尋ねるとよいでしょう。
テンプレート化された技術的要件チェックリストは、貴重な組織ツールです。
Smartsheet の要件収集チェックリストなどのテンプレート化されたチェックリストを使用すると、技術要件分析の一環として収集すべき情報の種類に集中できます。
必ず以下を含めます。
- 機能要件と実行するタスク
- マイルストーンに関する日付の推進
- サイズ、重量、色、形状、質感、耐久性など、有形製品の物理的要件
- 技術的環境の詳細
- データ要件
- 外部インターフェイス
- 互換性/移植性
- メンテナンス
多様なグループから情報を収集する
スミスは、このようなドキュメントの情報は、エンド ユーザー、顧客、開発者、その他の関係者など、さまざまな情報源から得られる可能性を示唆しています。情報は、インタビュー、アンケート、アンケート、調査、チーム間の円卓会議を通じて収集できます。
使用状況分析の採用
製品を使用するユーザーの種類を特定し、その使用パターンを把握します。これは、達成したいパフォーマンスのレベルに必要な要件を決定する際に役立ちます。
ユース ケースの作成
一般的なユーザーによる対話のモデルは、ケース図とケース レポートを使用して、技術要件ドキュメントまたはビジネス要件ドキュメントに含める必要があります。
ニーズと望ましい成果を探る
技術的要件文書に関する以下の種類の情報を収集することを検討してください。
1. エンド ユーザーの期待とニーズ、および製品が実際にどのように使用されるかを定義する質問します (ここにいくつかのサンプルがあります):
- あなたの製品やソフトウェアはどのようなコア問題をオーディエンスのために解決しますか?
- 製品やソフトウェアの使用時に、人々に何を達成してほしいですか?
- 人生はどのように簡単に、より生産的になるのでしょうか?
2. チーム構造と不測の事態を定義する
- どのチーム メンバーが仕事の側面を担当していますか? (上記のフェルマンの例を忘れずに、すべての重要な仕事の責任が割り当てられていることを確認してください。)
3. 製品の定義
- モックアップ、ナラティブ、リストを使用します。
- インターフェイスの要件を明確に記述します。
- 特に、製品やソフトウェアがクライアントの仕様に合わせて構築されている場合は、顧客またはクライアントの要件を明確にします。
- 開発段階を定義します。
- 完了までの具体的なステップを含め、より多くの詳細が発見され、決定されるにつれて洗練できる初期スケジュールを作成します。
- プロセスのどの部分が互いに依存しているのか、その理由を探り、不測の事態を特定します。
4. プロトタイプを作成して、ユーザーが新製品やシステムから予測した結果を明確にする
5. 人、プロセス、ソフトウェア、テクノロジー開発、チェンジ マネジメントなど、製品開発のライフサイクル全体を定義する
6. 各システム要件に次の内容が記載されていることを確認します。
- それが実行する関連する機能。
- 設計、法的、規制上の制約やリスクの面で、あらゆる種類の制限。
- 運用場所、使用、またはストレージに関する環境設計要件。
システム品質を考慮する
ビジネス要件とユーザー要件を満たすために必要なサービス品質を説明する際には、次のシステム品質を考慮してください。
- 可用性 - システムのリソース、サービス、エンド ユーザーへのアクセシビリティに基づいて、システムに期待できる「アップタイム」の量。
- 潜在能力 - システムが、より多くのリソースに依存しない使用状況の予期せぬピークにどのように対処するか。
- パフォーマンス - さまざまな用途の特定の負荷条件を考えると、応答時間と潜在的なキャパシティはどのようになるか。
- 拡張性 - 元のアーキテクチャを変更することなく、キャパシティとユーザー数をどれだけ速く増加または減少できるか。
- 保守性 - ハードウェアとソフトウェアの両方のシステム コンポーネントの監視、修復、アップグレードがどれほど簡単か。考慮すべき要因には、ダウンタイムの計画、使用状況のパターンに基づくメンテナンスの機会、サービスの可用性に関する重要な時間、診断と監視のスケジュールなどがあります。
- セキュリティ - ユーザーの承認や認証、転送中の情報など、システムの安全性はどのくらいか。
技術的要件を検証し、改善する
技術的要件を定義したら、時間をかけて検証し、改善します。スミス氏は、「特定の要件を要求した関係者の数、それに依存するその他の要件の数、システムの使用を容易にするか、ユーザーが他の方法で行えない機能を実行するのか、その他の定性的対策などの要因を見ました」と述べています。
スミスにとって、要件を検証することは、できるだけ多くの目玉を得て、フィードバックを聞き、特定の要件を維持または却下することの影響について話し合うプロセスでした。「ショートカットは本当にありません。主要な関係者を巻き込み、意見の違いを理解し、解決するために協力することがすべてです」。
スミスは、あなたが必要なすべての要件を把握したかどうかは決して分からないと予測しています。「おそらく、必要以上に集まるでしょう。しかし、それらを持ったら、優先順位を付け、時間と予算に合った最優先事項の要件に取り組みます。最も重要なのは、最大の要件ではない場合もあります」。
関係者を常に把握する
現在、関係者が開発プロセスを直接把握し、進捗状況を視覚的に確認し、実施中の要件をレビュー (ただし編集しない) し、早期のプロトタイプをテストできるツールがあります。「ソフトウェア開発はとても難しいことです」とスミスは言います。「人は開発前に機能に興奮し、期待に応えなければ本当にがっかりする可能性があります」。したがって、製品がリリースされた後も、ユーザーに情報を提供し、どのような方法で早期にアクセスしたり、定期的な更新を提供したりすることが、エンドユーザーの満足度を高める鍵となります。
あなたのためのアジャイル モデリング?
アジャイル モデリング (AM) は、ソフトウェア ベースのシステムや製品の開発に展開できるモデルを作成して文書化するもう 1 つの方法です。その範囲は、プロセス全体を含めるために技術的な要件のドキュメントを超え、時間と予算を与えられ、可能な限り最高のソフトウェアを作成するための最も効果的な価値と原則に基づいてベスト プラクティスを組み合わせたものです。
アジャイル モデリングの詳細については、以下の推奨書籍をご覧ください。
- 規律正しいアジャイル デリバリー (DAD): Scott W. Ambler とマーク・ラインズによるエンタープライズにおけるアジャイル ソフトウェア デリバリーの実践者ガイド、IBM Press、ISBN: 013281013
- オブジェクト プライマー第 3 版: UML 2 を使用したアジャイル モデル駆動型開発。 ケンブリッジ大学出版局、2004 ISBN#: 0-521-54018-6
- 規律正しいアジャイル デリバリーの紹介: マーク・ラインズと Sccott W. Ambler によるスクラムから継続的デリバリーへの小さなチームの旅、規律正しいアジャイル・コンソーシアム、ISBN: 978 149 754 4383
技術要件テンプレートとソフトウェア
テンプレートは使いやすく、コストは適切ですが、代替案もあります。Shrivathsan の会社である Accompa は、冗長な情報や誤解された情報に基づいて発生する可能性のある問題を管理する要件文書ソフトウェアを作成しています。
このソフトウェア:
- これら 3 種類のドキュメント間の依存関係を追跡します。ビジネス要件文書に何かが変更された場合、市場や技術要件文書にカスケード効果を与える可能性があります。
- すべての情報を簡単に使用できるように 1 つのリポジトリを提供します (Shrivathsan は、ほとんどの大企業ではこの情報が複数のサイロに分割され、検索と使用が非常に困難であると述べました)。
「最小のプロジェクト以外のプロジェクトでは、これらの依存関係を手動で追跡することはほとんど不可能です」と、Shrivathsan 氏は言います。そのため、手頃な価格のソフトウェア ツールが必要です」と述べています。
技術要件書の作成に関するアドバイス
技術的な要件を書くことは、他の標準的なビジネス文書とは少し異なります。プロジェクトの完了や新しいタイプのソフトウェアの構築に使用する人々が理解できるように、それらを書く芸術があります。便利な技術的要件を書く際に役立つヒントを以下に示します。
- シンプルでわかりやすい言葉を使えば、全員が自分の意味を共通認識できます。
- 簡潔にしましょう。はじめに最初の段落から始め、続いて箇条書きで読みやすさを高めます。
- 文構造をシンプルに保ち、主要なアイデアを一度に 1 つだけ伝えましょう。
- 特にコンセプトを簡素化したり、あるコンセプトと別のコンセプトの関係を示したりする場合は、1,000 語の価値がある写真です。
教育機関や企業向けの技術要件書
教育機関や企業の中には、コンピューターのハードウェア、ソフトウェア、ブラウザに関する基本的な技術的要件に専念するウェブ ページがサイト上にあります。これらの基本的な技術的要件を満たしていない場合、学生、教員、または従業員はイントラネットにアクセスできません。学生の場合、これはオンライン クラスを受けることができないことを意味します。企業の場合は、従業員が自分の仕事をできない可能性があることを意味します。
通常、情報には以下が含まれます。
- プロセッサまたは CPU の最小速度、最小メモリ、オペレーティング システムの種類など、Windows および Mac プラットフォームの最小構成。
- インターネット アクセスのためのネットワーク接続の速度
- サポートされているブラウザの現在のリストに加え、ダウンロードするためのリンク
- ブラウザ プラグインの現在のリストと、それらをダウンロードするためのリンク
- インターネット アクセス情報
- 学校または会社の電子メール アカウントに登録する方法
- 必要なソフトウェア
Smartsheet テンプレートを使用すると、技術的要件が作業チェックリストに変換され、プロジェクトを管理できます。
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。