線の内側の色付け: ソフトウェア開発の制約

さまざまな種類の制約により、デザイナー、開発者、プロジェクト マネージャーが利用できる選択肢が制限されますが、それには正当な理由があることが望まれます。

ソフトウェア コンサルタントのティム リスターは、プロジェクトの成功を「主要な利害関係者が期待するすべての要件と制約を満たすこと」と定義しました。ソフトウェア要件に関する膨大な量の文献があります。対照的に、利害関係者がソフトウェア イニシアチブに課す可能性のあるさまざまな種類の制約についてはほとんど書かれていません。制約を特定し、伝達し、制約内で作業することは、ソフトウェア開発を成功させるために不可欠な要素です。定義から始めましょう。

「制約とは、製品の仕様、設計、構造、構成、またはプロジェクト管理で利用できる選択肢を制限する制限です。」

ソフトウェア イニシアチブは、製品、プロジェクト、プロセスという 3 つの主要なクラスの制約の影響を受けます。

製品の制約

製品制約は、開発中のソリューションが持つ必要がある、または持つことができない機能または特性を指定します。このことから、制約は要件とかなり似たものに聞こえますね。

製品制約は確かに要件情報の一種です。ビジネス アナリスト (BA) は、要件を引き出す際に制約を調査し、設計者や開発者が適切に対処できるように文書化する必要があります。すべての要件を制約と考える人もいますが、私はそうではありません。それらを何と呼ぶかよりも重要なのは、それらの重要な情報を発見し、理解し、検証し、文書化し、伝達し、尊重することです。

引き出し中に、設計または実装の制約が近づいていることを示すキーワードを聞きます。 しなければならない、 してはなりません、 できないかもしれない、 そして 次のことはできません:

「…を超えることはできない」 「

「…使わなければなりません」 」

「…使わなければなりません」 」

「…に書かなければなりません 「

関係者の制約に関するステートメントを単に転写しないでください。制約が存在する理由を尋ね、その妥当性を確認し、時代遅れまたは無効である可能性のある仮定が行われているかどうかを判断し、制約を要件の一部として含める根拠を記録します。その理論的根拠を記録しておくと、開発者が「このようにしなければならないのか、それとも私が考えた別のアプローチで大丈夫でしょうか?」と尋ねた場合に生じる可能性のある議論をすぐに解決できます。

要件に含まれる設計制約は、製品設計のある側面を特定の方法で行う必要があることを指定します。特定のユーザー インタラクション言語を組み込んだ要件に注意してください。「ユーザーが[送信]をタップしたとき…」BA は、そのような記述が本当の制限であるのか、それとも誰かが考えた単なる解決策のアイデアなのかを判断する必要があります。それが実際の制約ではない場合は、他の創造的なデザインのアプローチを妨げないように要件の文言を一般化します。「ユーザーが[送信]を選択したとき…」

ソリューションのアイデアを要件に含めても問題ありません。それが制限（「このようにしなければなりません！」）なのか、示唆に富む提案（「私たちが考えていることを見てもらうために、私たちが考えたアイデアがあります。」）なのかを読者が理解できるようにしてください。 BA は、時期尚早、不必要、不用意に課せられた、または過度に厳しい制約を要件として記録することを避けるべきです。

制約はさまざまなソースから発生する可能性があります。組み込みソフトウェアを含むデバイスは、多くの場合、サイズ、重量、使用される材料、形状、物理インターフェイスとソフトウェア インターフェイスの両方、持続可能性の問題などの物理的な制約を尊重する必要があります。コンピューティング環境、プラットフォーム、オペレーティング システム、物理インフラストラクチャ、およびその他の技術的考慮事項により、メモリ、プロセッサーの能力、ディスク容量、ネットワークの速度と容量、セキュリティ、または互換性により、制限 (同時ユーザー数やトランザクション数など) が課される場合があります。 。

ビジネスルール 多くの制約を課します。実際、 ビジネスルールグループ「ビジネス ルールは、ビジネスの一部の側面を定義または制約するステートメントです。ビジネス構造を主張したり、ビジネスの行動を制御したり影響を与えたりすることを目的としています。」ビジネス ルールでは、特定のアクションを実行する必要がある、または実行してはいけない、または実行できないこと、または特定のユーザー ロールのみが特定のアクティビティを実行できることを示すことができます。

ソフトウェア ソリューションで制約のあるビジネス ルールに準拠すると、ユーザー アクセス、特権レベル、または同様の使用制限を強制する機能が生じる可能性があります。制約では、システムが特定の計算を実行する必要がある方法を指定できます。輸送機器や医療機器など、規制認証の対象となる製品は、ビジネス ルールや標準として文書化された多数の確立された制約に準拠する必要があります。

非機能要件によって制約が課されることもよくあります。セキュリティ要件が良い例です。多くの場合、企業標準や業界のベスト プラクティスによって、ユーザーとデバイスの認証用の特定のプロトコルが規定されます。アプリでのユーザー認証に生体認証は許可されていますか? それともユーザーは認証アプリ、物理的なセキュリティ キー、テキストまたは電子メールで送信された秘密番号、またはその他の多要素認証技術を使用する必要がありますか? MFA を実装するにはさまざまな方法があります。要件によって、どのメソッドが必須か、許可されるか、または許可されないかが指定される場合があります。

製品制約のその他の原因には、外部の業界、製品、または政府の標準 (データ保護やアクセス セキュリティなど) や、従来のシステムまたは関連する製品ファミリー メンバーとの互換性が含まれます。要件と同様に、BA は、チームがプロセスの早い段階で関連する製品の制約を確実に特定できるように、大きな網を張る必要があります。制約を見落とすと、計画外の大規模な設計やコードのやり直しが行われる可能性があります。誰もそれを望んでいません。

検証された製品の制約を文書化する ソフトウェア要件仕様の中で。明確な要件を記述し、完全であること、 明確な、など。

プロジェクトの制約

ソフトウェアの制約について話すとき、それは最も一般的にはプロジェクトの制約を意味します。これらは多くの場合、次の形式で表されます。 時間、コスト、範囲の古典的な鉄の三角形:

三重制約とも呼ばれるこの基本的な点は、3 つの側面の 1 つが変化した場合、その変化に対応するために他の側面も調整する必要があるということです。プロジェクト マネージャーは、3 つの側面のそれぞれに関してどの程度の柔軟性があるかに応じて、トレードオフの決定を下す必要があります。この三角形モデルは単純すぎるため、さまざまな方法で表現されます。品質は一部の図に現れますが、頻繁に現れるわけではなく、一貫した方法でもありません。

次の観点から考えるとよりわかりやすいと思います プロジェクトの 5 つの次元: 機能 (または範囲)、スケジュール (または時間)、コスト (または予算)、スタッフ、および品質。人々は、正しくても間違っていても、品質と速度や範囲を日常的にトレードオフしているため、品質を個別の次元として扱います。私は、時々行われるように、スタッフと予算を一緒くたにして、その組み合わせを「リソース」とは呼びません。プロジェクト チームに十分な資金があるにもかかわらず、それ以上の人員を雇用できない場合があります。リスク分析によってチームがテクノロジーの選択を制限したり、ビジネス戦略を導いたりする可能性があるため、リスクが制約であると考える人もいます。

これら 5 つの側面はそれぞれ、特定のプロジェクトで 3 つの役割のいずれかを引き受けることができます。 制約、 ドライバ、または 自由度。柔軟性を提供しない寸法は制約です。例としては、不変に固定された納期、限られたチームの規模、固定の予算、または交渉の余地のない機能セットなどが挙げられます。拘束ではない寸法は、ある程度の調整可能性を提供します。したがって、プロジェクト マネージャーの課題は、制約が課す制限内でプロジェクトが成功要因を達成できるように、より柔軟なディメンションを調整することです。

安全に関する重要なヒント: 5 つの次元 (鉄の三角形が好みの場合は 3 つ) すべてが柔軟性のない制約になるわけではありません。プロジェクトの現実が変化するたびに、何かを提供できる必要があります。チームとそのリーダーは、最初にどの次元が制約であり、どの次元が柔軟であるかについて共通の理解を必要とします。

プロセスの制約

プロセスの制約は、多くの場合、組織または外部の標準が原因で、開発チームが採用できるアプローチや開発成果物を制限または決定します。私は、それが特定の取り組みにとって最適なアプローチであるかどうかにかかわらず、すべてのプロジェクトにエンタープライズ アジャイル フレームワークを義務付けた大規模な組織を知っています。たとえそれが活動に適さない場合でも、管理命令に従ってチームはそのように運営しなければならなかった。たとえばスクラムの使用を義務付けている組織では、チームはスクラムによって定義されたチームの役割を果たす必要があります。スクラム活動、イベント、式典を実行する。製品バックログ、スプリント バックログ、完了の定義などのスクラム アーティファクトを作成します。

規制上の審査と認証の対象となる一部の製品は、特定のプロトコルと規格を使用して開発する必要があります。特定の形式で提示される指定されたコンテンツを含む特定の成果物を作成する必要がある場合があります。特定のチェックポイントのレビューと承認が必要になる場合があります。組織が ISO 9000 認証を維持したい場合は、その品質管理システムが確立された基準に準拠している必要があります。特定の CMMI 成熟度レベルを達成するには、組織は適切なプロセスを確立し、それに従う必要があります。

その他の可能性あり プロセス制約の原因 これらを含めます:

• ソフトウェア分析と設計モデリングに使用されるツールと図の規則

• 成果物書類に必要なテンプレート

• 開発環境、構成管理ツールおよびリポジトリなど

• 移植性や互換性の理由で使用または回避されるプログラミング言語または言語機能

• 要件を表現する方法

• 大規模言語モデル (LLM) やその他の AI 製品、クラウドベースのサービスなど、サードパーティ ベンダーのツールやサービスの使用に関するセキュリティと信頼性の問題

• プロジェクトの計画、追跡、および報告の規則

制約の重要性

関連する制約を特定することは、プロジェクトの計画と要件の開発において重要な側面です。プランナーは、変化する現実に対応できるように、自分の柔軟性がどこにあるのかを知っておく必要があります。設計者は、自社の製品が関連する規則、規制、ポリシー、基準に準拠していることを確認する必要があります。

設計上の制約は必ずしも悪いものではありません。製品内および製品間で論理的に類似した操作に一貫性を提供することで、学習性と使いやすさを向上させることができます。例としては、携帯電話からオブジェクトを削除する方法があります。アプリごとに、さまざまなインタラクション手法、ビジュアル デザイン要素、言語が使用されます。方法は、単一のアイテムを削除するか、複数のアイテムを一度に削除するかによって異なります。削除を確認する必要がある場合と必要ない場合があります。混乱してしまいます。ユーザー インターフェイス標準を定義すると、確かに UX デザイナーに制約が課せられますが、それはユーザーの利益になります。

クリエイティブな人は自分の仕事のやり方に制限が設けられることを好まないかもしれませんが、それが現実です。制約を事前に理解しておけば、より適切な製品を無秩序に生産することができます。

---

著者: カール・ヴィーガース

カール・ヴィーガースは数多くの本の著者です。 ソフトウェア要件 (ジョイ・ビーティと)、 ソフトウェア要件の要点 （キャンダセ・ホカンソン氏と、 ソフトウェア開発パール、 日常のものの無思慮なデザイン、 そして 成功するビジネス分析コンサルティング。