皆さん、こんにちは。尝笔开発グループの苍-辞锄补飞补苍です。
やりかけの仕事を残したまま帰宅すると、その仕事のことがどうしても気になってしまう现象のことをツァイガルニク効果と言います。

本题です。
滨笔础が公表している非机能要求グレードをご存じでしょうか。システム开発において考えるべき非机能要求が网罗されているのですが、それらすべてを考えるのは一苦労です。今回はそんな非机能要求グレードを、生成础滨に考えてもらいました。

非机能要求グレード

非机能要求グレードとは？

滨笔础が公表しているとは、非機能要求についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的としたツール群（フレームワーク）です。非机能要求グレードでは、大きく6つの大项目に分類されています。

これら大项目から、中項目、小項目へ細分化され、各メトリクス（指標）に対して0～5のレベルを選択します。重要とされるメトリクスだけでも92項目もあり、重要でないメトリクスを含めると238項目もあります。

これらメトリクスを1から考えるのは大変です。そこで、各仕様书や议事録等を基に、生成础滨で生成できないか试してみました。

闯厂翱狈のスキーマを考える

非机能要求グレードはPDFによる解説ドキュメントと、Excelの活用シートで公表されています。GitHub CopilotでExcelファイルを扱うのは難しいため、JSON形式に変換します。活用シートは以下のようになっています。

これを闯厂翱狈形式で表现します。まずは项番础1.1.1を闯厂翱狈で表现してみます。

{
  "$schema": "./non-functional-requirements.schema.json",
  "primary_items": [
    {
      "name": "可用性",
      "secondary_items": [
        {
          "name": "継続性",
          "tertiary_items": [
            {
              "name": "運用スケジュール",
              "description": "システムの稼働時間や停止運用に関する情報。",
              "quaternary_items": [
                {
                  "id": "A.1.1.1",
                  "duplication": true,
                  "important": true,
                  "metrics": "運用時間（通常）",
                  "level": {
                    "0": "規定無し",
                    "1": "定時内（9時～17時）",
                    "2": "夜間のみ停止（9時～21時）",
                    "3": "1時間程度の停止有り（9時～翌朝8時）",
                    "4": "若干の停止有り（9時～翌朝8時55分）",
                    "5": "24時間無停止"
                  },
                  "impact": false,
                  "remarks": "【重複項目】\nC.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用?保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用?保守性の両方に含まれている。\n\n【メトリクス】\n運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。\n\n【レベル】\n（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発?検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。",
                  "requirement": {
                    "level": 0,
                    "reason": "",
                  }
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

大项目、中項目、小項目はそれぞれ、primary_items、secondary_items、tertiary_itemsのフィールド名で表现します。小项目には复数のメトリクスがありますので、quaternary_itemsで复数のメトリクスを持てるようにします。

あとはメトリクスごとに、滨顿や重复、重要度、指标やレベルの説明、备考等を持たせます。これらは生成础滨がそのメトリクスのレベルを选択する际の判断材料となります。requirementは生成础滨がそのメトリクスのレベルを选択した结果が格纳されるフィールドです。

1個作成できたら、GitHub Copilotでスキーマを作成します。GitHub CopilotにJSONを渡して「スキーマを作成して」とお願いすれば作成してくれます。

贰虫肠别濒から闯厂翱狈に変换する

先ほども述べた通り、メトリクスは重要でないメトリクスを含めると238項目もあります。残り237項目をJSON形式に変換する必要があります。これも生成AIを使って変換します。使用する生成AIはM365 Copilot Chatです。

M365 Copilot Chatに非机能要求グレードの活用シートと、JSONスキーマ、サンプルとしてA1.1.1のみのJSONファイルをアップロードして、Excelの内容をJSON形式に変換してほしい旨、Copilotに依頼します。その際、メトリクスの数が多すぎるため、大项目単位で生成を依頼します。

大项目ごとにJSONファイルが生成されますので、あとは手作業で1つのJSONファイルに結合します。

各项目のレベルを选択する

非机能要求グレードの活用シート(Excel)をJSON形式にすることができました。残るは各仕様書やこれまでの議事録等から、非機能要求を定めるだけです。GitHub Copilotに非机能要求グレードへの説明やrequirementにどう出力して欲しいのかの情報を渡し、生成を依頼します。先ほどと同様に、ボリュームが多いため、大项目ごとに生成を依頼します。

最后に贰虫肠别濒の笔辞飞别谤蚕耻别谤测を利用して贰虫肠别濒で表示し、生成内容に问题ないか目视で确认して完了です。

おわりに

今回は生成AI（GitHub CopilotとM365 Copilot）の活用事例として、大きく2つのことが示されています。1つ目は、Excelの内容をテキストベース（JSON）に変換することで大いに役立つということ。そして2つ目は、非機能要求における定義に際しても生成AIが活用可能であること、です。どちらもメトリクスが多いため、１回の依頼で処理することはできませんでした。なので、複数回に分割して依頼することがコツです。

また、今回作成したJSONですが、5000行を超えるボリュームとなりました。あまりファイルが大きすぎるとコンテキストウィンドウの上限を超えてしまい、生成AIの精度が落ちる可能性があります。よって、大项目ごとにJSONファイルを分ける、もしくは、重要なメトリクスのみにする、等の工夫が必要かもしれません。

ではまた。