はじめに

A-SPICEを知ろうとすると、最初にプロセスの多さに戸惑います。SYS、SWE、MAN、SUPといったプレフィックスのついたプロセスが30以上あり、ひとつひとつは理解できても、全体の関係がつかみにくいです。

本記事では、これらのプロセスを3つのグループに分けて整理した図をもとに、A-SPICEの構造を説明します。なお、A-SPICEにはACQやSPL
、PIMといったプロセスグループも存在しますが、本記事ではソフトウェア開発プロジェクトで中心的に扱われるSYS/SWE・MAN・SUPに絞って説明します。公式な解釈ではなく筆者の一つの見方として参考にしていただければ幸いです。

何が説明しにくかったか

A-SPICEについて人に説明しようとすると、プロセスの一覧を示すことはできます。しかし「それぞれのプロセスがどうつながっているのか」を図や言葉で表現しようとすると、途端に難しくなります。

SYSやSWEは一般的な開発工程と同様なので伝えやすいですが、MANやSUPは「管理」「サポート」と説明しても、開発プロセスの中でどう機能するのか、どう関係しているのかが相手に伝わりにくいです。

図で表現しようとしても、プロセスの箱が並ぶだけでビジーな図になりがちです。情報量が多すぎて、かえって全体像が見えにくくなることも少なくありませんでした。

そのつながりをシンプルに表現できる図が描けないか、と考えていました。

こう整理してみた

試行錯誤の末にたどり着いたのが、プロセスを3つのグループに分けて空間的に配置するという整理です。

「図1：筆者の整理に基づくA-SPICE 3層構造図（Geminiにより生成）」

図の見方は以下の通りです。

MAN（プロジェクト管理） はプロジェクト全体を貫く時間軸として上部に配置しました。計画を立て、リスクを監視し、進捗をトラッキングします。SYS/SWEの活動全体を包み込む存在です。

SYS/SWE(エンジニアリング) はいわゆるV字モデルとして中央に配置しました。要件定義から実装、テストまで、モノづくりの本体にあたる部分です。

SUP（サポート） は構成管理・問題解決・変更依頼管理として底面に配置しました。「品質崩壊を防ぐ、守りの要」として、SYS/SWEの活動を下から支えます。

この3つを空間的に重ねることで、「MANの枠組みの中でSYS/SWEが動き、SUPがそれを支える」という関係が一枚の図に収まりました。

各グループを自分の言葉で

MAN（管理プロセス）

MANはプロジェクトの計画と監視を担います。具体的にはMAN.3でプロジェクト計画を立て、MAN.5でリスク管理と進捗トラッキングを行います。

重要なのは、MANはSYS/SWEと並列ではなく、SYS/SWEの活動全体を包む存在だという点です。変更が発生すれば計画を更新し、リスクが顕在化すれば対策を打ちます。プロジェクトが終わるまで継続して機能します。

SYS/SWE（基幹プロセス）

SYS/SWEはモノづくりの本体です。システム要件定義（SYS.2）からシステムアーキテクチャ設計（SYS.3）、ソフトウェア要件定義（SWE.1）、設計・実装（SWE.2/3）、そして各レベルのテスト（SWE.4〜6、SYS.4/5）まで、V字モデルとして展開されます。

SUP（サポートプロセス）

SUPは開発活動を下から支える基盤です。構成管理（SUP.8）で成果物のバージョンを管理し、問題解決管理（SUP.9）で不具合や課題を追跡し、変更依頼管理（SUP.10）で割り込み要求をV字プロセスに適切に反映します。

地味に見えますが、SUPが機能していないと品質が崩壊します。

この整理で何が変わったか

3つのグループに分けて空間的に配置することで、説明の入り口が変わりました。

以前はプロセスを一覧として示すところから始めていましたが、この図を使うことで「MANという枠組みの中でSYS/SWEが動き、SUPがそれを支える」という全体像を最初に伝えられるようになりました。個々のプロセスの説明はその後でいいです。

また、プロセス改善を考える際にも、どのグループに課題があるのかという視点で整理しやすくなりました。「テストが弱い」ならSYS/SWE、「計画が機能していない」ならMAN、「変更が野放しになっている」ならSUPという具合です。

全体像が見えると、改善の優先順位もつけやすくなります。

おわりに

A-SPICEのプロセスを3つのグループに分けて空間的に整理するというのは、あくまで筆者の一つの見方です。公式のモデルにこういった整理が明示されているわけではありません。

ただ、全体像が見えることで説明しやすくなったと思います。同じようにA-SPICEの説明に悩んでいる人の参考になれば幸いです。