役割名ではなく行動を定義する ― 責任割当てを機能させる方法

Automotive SPICEのアセスメントを行っていると、GP2.1.4（Assign Responsibility）は比較的達成しやすいプラクティスに見えます。

組織図があり、役割一覧があり、RACI表も整備されている。Project Manager、Quality Assurance Manager、Configuration Managerといった役割も定義されている。そのため、多くの組織は「責任の割当てはできている」と考えます。

しかし、インタビューを進めると次のような声を耳にすることがあります。

「Project Managerを任されていますが、実際には何をすればよいのでしょうか。」

「Configuration Managerになったのですが、どこまでやれば責任を果たしたことになるのでしょうか。」

役割は存在しているのに、その役割を担う本人が何を行うべきか分からないのです。これは決して珍しい話ではありません。むしろ多くの組織が直面する共通の課題ではないでしょうか。

責任割当ての落とし穴

責任割当てに関する要求の目的は、プロセスを確実に実施するための体制を構築することです。

ところが実際には、

• 役割名だけ定義して満足してしまう
• RACI表を作って終わってしまう
• 責任者を任命すればプロセスが回ると思ってしまう

という状態に陥ることがあります。確かに役割定義書やRACI表は有効な手段です。しかし、それらはあくまで責任を可視化するための仕組みに過ぎません。本当に重要なのは、割り当てられた責任が実際の行動として機能していることです。役割名が存在することと、その役割が期待どおりの活動を実施できることは同じではありません。

「誰が責任者か」より「何を行うか」

Automotive SPICEでは、多くのプロセスで役割が定義されています。

しかし、

• 毎週何を確認するのか
• どの指標を見るのか
• どのタイミングで介入するのか
• 何を判断するのか
• 問題が発生した場合に何を行うのか

までは明確に規定されていません。そのため、役割名と責任範囲だけを定義すると、担当者それぞれの経験や力量に依存した運用になりがちです。結果として、同じProject Managerでも人によって活動内容が大きく異なり、プロセスの再現性が失われます。責任者を置くことが目的ではありません。プロセスが継続的かつ安定的に運用されることが目的なのです。

Managerだけの話ではない

この課題はManager役割だけに当てはまるものではありません。

例えば、

• Reviewer
• Author
• Verifier
• System Architect
• Change Control Board
• Configuration Librarian

といった役割についても同じです。

レビュー担当者であれば何を確認するのか。Verifierであればどの証拠を確認し、どの基準で合否を判断するのか。役割名だけでは十分ではなく、期待される行動を明確にすることが重要です。今回は分かりやすい例としてManager役割を取り上げますが、本質的な考え方はすべての役割に共通しています。

同じ役割でもプロセスによって期待行動は変わる

さらに見落とされやすいのが、同じ役割であっても担当するプロセスによって期待される活動が異なることです。

例えばProject Managerの場合、MAN.3では、

• 計画策定
• 進捗監視
• リスク管理
• 是正処置

が中心となります。

一方でSUP.9では、

• 問題解決状況の監視
• 問題分析結果のレビュー
• エスカレーション判断

などが主な活動になります。

つまり、「Project Manager」という役割だけでは必要な行動を定義できません。どのプロセスにおいて、どの責任を担うのかを明確にしなければ、期待されるマネジメント行動は見えてこないのです。

TSPに学ぶ役割の考え方

こうした状況を考える際に参考になるのがTSP（Team Software Process）です。

TSPではPlanning Manager、Quality Manager、Process Manager、Support Managerなどの役割が定義されており、それぞれに具体的な責務や確認事項が設定されています。つまりTSPは肩書を与えるだけではなく、「何を行うべきか」まで明確にしているのです。この考え方で見ると、Manager役割とは成果物を作る人ではありません。成果物が作られる仕組みを維持し、監視し、改善する人です。

そのためManager役割の本質は、

• 実施状況を監視する
• 状況を評価する
• 問題を判断する
• 是正を促す

ことにあります。

行動を具体化する

例えばProject Managerであれば、

• 計画と実績の差異確認
• スケジュール遅延の兆候把握
• リスクレビュー
• 未解決課題の監視
• 是正処置の指示

といった活動が考えられます。

Configuration Managerであれば、

• 構成品目登録状況の確認
• ベースライン設定状況の確認
• 変更要求処理状況の監視
• 構成監査結果の確認

などが該当します。

重要なのは、「構成管理に責任を持つ」と書くことではありません。何を確認し、何を判断し、どのような条件で行動するのかまで明確にすることです。

行動を明確化する仕組みを作る

こうした具体化を実現する方法として、役割説明書は非常に有効です。

例えば、

• 役割の目的
• 確認する内容
• 使用する指標
• 参加する会議
• レビュー対象
• 判断事項
• 実施頻度
• エスカレーション条件

などを整理します。

ただし、必ずしも役割説明書という成果物である必要はありません。組織によっては、Role Description、RACI、Procedure、Work Instruction、チェックリストなどに分散して定義してもよいでしょう。重要なのは文書の名前ではなく、期待される行動が誰にでも分かることです。

役割間連携も重要

実際のプロセスは、個々の役割だけで成立するものではありません。

Project Manager、Quality Assurance Manager、Configuration Manager、System Architect、開発担当者など、多くの役割が連携しながら運営されています。

そのため、

• 誰が入力するのか
• 誰がレビューするのか
• 誰が承認するのか
• 誰が監視するのか

を明確にすることも重要です。RACI表やスイムレーン図は、その関係を可視化する有効な方法です。

責任割当てを機能させるために

責任を割り当てることは重要です。しかし、それだけではプロセスは機能しません。本当に必要なのは、割り当てられた役割が何を行うのかを具体化することです。そして、その内容が引継ぎ可能なレベルまで整理されていることです。役割名を定義するだけではプロセスは改善しません。

「誰が責任者か」だけでなく、

「その役割は何を確認し、何を判断し、誰と連携し、どのように改善を促すのか」

まで明確にする。それこそが責任割当てを形骸化させず、ASPICEのプロセスを実際に機能する運営モデルへ発展させる第一歩ではないでしょうか。

 

（佐野　忠）