仕様を担当するエンジニアが知っておくべきQ&A活動のお作法

背景
Q&A活動とは「前工程と後工程との板挟み」
良い質問とは
質問する・しないの界面はどうやって決めるのか
参考サイト
まとめ
関連記事

背景

Q&A活動が上手く進まないという悩みを抱えている仕様担当エンジニアに向けて、自身の経験が役に立つのではと思い筆を執りました。本記事ではシステム開発の上流工程に焦点をあてて解説致しますが、下流工程でも役に立つ場面はあるかと存じますので、最後までお読みいただけますと幸いです。

Q&A活動とは「前工程と後工程との板挟み」

Q&Aとは、「Question and Answer」の略語です。質問と回答をやり取りする活動なわけですが、どんな活動かを一言で言うと「前工程と後工程との板挟み」です。システム開発でよく発生する構図を用いて説明致します。下の図をご覧ください。

前提として、ここでの仕様担当とは、発注者と会話をし、仕様書発行までを支援し、後工程へ橋渡しをする立場のエンジニアとご理解ください。以下に、上記図の流れを示します。

ソフト開発担当が質問を起案する（右上の「質問」）
仕様担当が質問を受け取り、発注者が分かる言葉に変換して起案する（中央上の質問（修正版））
発注者が仕様担当から質問を受け取り、回答を作成する（左下の回答）
仕様担当が発注者から回答を受け取り、ソフト開発担当が分かる言葉に変換して回答する（中央下の回答（修正版））
ソフト開発担当が回答を受け取る

2番と4番で登場する「変換」というのがキーワードです。つまり、仕様担当の価値は前工程と後工程との翻訳機能です。図の中で仕様担当が質問や回答を修正しているのが読み取れると思います。これは何をしているのかと言いますと、発注者とソフト開発担当間のギャップを埋める作業です。仕様担当は発注者とソフト開発両方と会話しているため、双方の前提にギャップがあることを理解しています。例えば、発注者が仕様の内容を深く理解していない場合があります。ちょっと以外かもしれませんが、仕様書は常に継ぎ足し継ぎ足しで作成されていく秘伝のたれのようなものです。そのため、過去から引き継いでいる仕様に関し、たまたま担当者にアサインされた発注者が経緯を把握するのは困難です。一方、ソフト開発側には過去プロジェクトの設計書やソースコードが残っているため、それをベースに仕様に対する質問を投げてきます。よくある質問が「この仕様の必要性は？どうしてこのような実現手段を取ったのか？もっとリソース効率よい仕様にしてくれないか？」という具合です。そのような質問をダイレクトに発注者にしてしまうと怒り心頭になってしまうのは想像にたやすいですね。この事例は発注者よりもソフト開発側が情報量が多いパターンですが、逆のギャップもあり得ます。新規のソフト開発ベンダーへ委託された場合が該当します。その場合の質問内容としては「仕様の意味がわかりません」的な内容が多くなってきます。この質問は中々厄介で、質問者は何がわからないのか、発注者に何を聞きたいのかを詳しくヒアリングを重ねる必要があります。つまり、長年プロジェクトに関わってきた人間と、初めてその仕様を目にする人間では仕様に対する解釈にギャップが生じるのです。なお、2番の際に仕様担当が回答できることもあります。

良い質問とは

前工程と後工程で仕様に対する理解度にギャップが生じることを説明してきました。ギャップが生じないように良い仕様を書くべきではありますが、仕様の品質は読み手が決めることもあり、中々難しいです。ですが、質問と回答に対する負荷を下げることは容易だったりします。間に挟まれる立場である仕様担当としては、質問者に対し、質問起案時に以下を記載してもらうようにすると負荷が減ります。

項目	説明	例
質問要約	質問内容の要約です。	エアコン機能の不揮発設定内容について
質問の内容	質問内容を可能な限り詳しく記述します。文章のみで説明が難しい場合、図や表等で補足します。なるべくクローズドクエスチョンとします。	エアコン機能を動作させる際、事前にセンタから設定情報をダウンロードします。その際、設定情報のインターフェース仕様上、A以外にもB、Cが設定可能ですが、B、Cが設定された際は以下の内、案①でよいでしょうか。案①：設定情報を破棄する案②：設定情報を受け入れる案③：既存の設定情報で動作する
該当仕様	質問したい仕様書名、章、表番号などを記述します。複数ある場合は複数記述します。	仕様書名：エアコン機能仕様書　x.x章
質問の背景と提案	質問するに至った経緯を記述します。【観点】・実装困難なため、仕様変更をしてほしい・仕様に定義がないため、仕様定義してほしい・設計内容の宣言・仕様解釈の確認	仕様に定義がないため、仕様定義いただきたいです。設計上は破棄する方が不具合発生リスクを抑えることが可能なため、設定を受け入れるのではなく、破棄する方針とさせていただきたいです。
現行との差異	現行とは既に稼働しているシステムのことです。過去のプロジェクトと差異があるか否かを記述します。	現行システムにはなく、新規仕様です。しかし、類似のXX機能において破棄する方針のため、横並びとさせていただきたいです。
回答期日	回答してほしい期日を記述します。	2024/5/1

表1　質問項目の記入ガイドと例

上記のように、質問をテンプレート化してしまえば、ラリー回数を少なくすることが可能です。全てのパターンがテンプレート化できるとは限りませんが、仕様担当の負荷を減らすことが可能です。「質問の内容」にある「クローズドクエスチョン」とは、予め選択肢を用意した上で、相手に選ばせるというスタイルの質問方法です。例では、①破棄する、②受け入れる、③既存設定で動作するという3つの選択肢を用意した上で、①を希望するという質問をしています。この聞き方であれば、相手からすると選ぶだけですので、回答作成に必要な時間が節約できます。

質問する・しないの界面はどうやって決めるのか

仕様担当の最大の悩みが「発注者へ質問すべきか否か」だと考えます。後工程が進めば進むほどに質問が増えていきますが、その時期になると発注者は既に別のプロジェクト立ち上げで忙しくなってきます。そのため、「今更なんで聞いてくるんだ」という心理状態になります。この状況がまさに仕様担当として最も胃が痛い時期です。では、質問する・しないの界面をどう考えればよいのでしょうか。仕様発行前に前工程と後工程含め合意形成できれば問題ないのですが、一つの考え方を示します。

考え方①：他システム・要素へ影響する話か否か

インターフェース仕様に関する質問は基本、質問すべき事案であると考えます。例えばスマートフォンアプリからエアコンを起動/停止できるシステムがあったとして、「エアコンからこんなデータを送信してよいか」的な質問をするとします。そういった、他のシステムや要素へ影響する話である場合は、仕様担当で判断せずに発注者へ確認すべきであると考えます。前提として、スマートフォンアプリ仕様は発注者しか把握しておらず、仕様担当のスコープはエアコン開発という事例です。要は、自分の開発スコープ内で閉じる話か、そうでない話かで考えるということです。

考え方②：不具合に繋がる話か否か

このまま設計を進めていくと、不具合に繋がるリスクがある場合、質問すべき事案であると考えます。例えば、「ログをメモリへ保存すること」「プログラム更新時、プログラム更新ファイルをメモリへ保存すること」という仕様があるものの、優先度や保存方針が未定義だとします。このまま設計を進めると、2つリスクがあります。