システム開発では、APIの仕様変更ひとつでも、バックエンド、画面側の実装、テスト、リリース計画に影響します。技術的な理由を説明しても、QA担当はテスト範囲を、プロダクト担当は利用者への影響やリリース時期を気にしているかもしれません。相手が何を判断する必要があるのかを確かめないまま説明を重ねると、会議で理解を得たように見えても、担当者と期限が決まらず、次の作業に移れません。

私は、若手の開発リーダーに必要なのは、技術の説明力だけではないと考えています。相手の事情について仮説を持ち、質問で確かめ、複数の役割が動ける形にまとめる力も欠かせません。システム開発の調整で確認したい三つのことを整理します。

1．この場で決めることは何か

まず、打ち合わせで何を決めたいのかをそろえます。「API仕様の変更を説明する」だけでは、説明の後に誰が何を判断するのかが分かりません。

たとえば、レスポンス項目の変更が必要になった場合、決めることは一つとは限りません。互換性を保つ移行方法、画面側の修正範囲、追加テスト、リリース予定への影響など、論点を分けます。今日決める項目と、追加情報がないと決められない項目も区別しておきます。

会議の冒頭で「今日は変更の必要性を共有したうえで、画面とテストへの影響、リリース判断に必要な確認事項をそろえたい」と伝えれば、参加者は自分の役割から必要な情報を出しやすくなります。説明すること自体を目的にせず、判断につながる場にするのがリーダーの仕事です。

2．相手が判断に必要としている情報は何か

自分の担当範囲から見た問題だけでは、他の役割が動けない理由を捉えきれません。そこで、会議の前に相手側の事情について仮説を立てます。

たとえば、画面側の開発担当は、項目が変わったときの表示条件や既存処理への影響を気にしているかもしれません。QA担当は、どの利用条件を追加でテストすべきかを知りたいかもしれません。プロダクト担当には、利用者に見える変更点やリリース時期の判断材料が必要かもしれません。これは相手の考えを決めつけるためではなく、何を確かめる質問を用意するか考えるための仮説です。

「変更で問題はありますか」と広く聞くより、「この項目が未設定の場合、画面ではどの状態を想定していますか」「今回の変更で、追加確認が必要なテスト条件はどれですか」と尋ねると、判断に必要な情報が具体的になります。返答が仮説と違えば見立てを修正します。仮説に合う答えを引き出すのではなく、相手の説明から実際の条件を知ることが目的です。

3．誰が、いつまでに、何をするか

論点を共有しただけでは、調整が終わったとは言えません。決まったことと未決のことを分け、それぞれの担当者と期限を確認します。

たとえば「画面側で影響を確認する」では、誰がどの条件を見るのかが残ります。「画面側の担当が既存の表示処理への影響を確認し、QA担当が追加テスト条件を整理する。開発リーダーは結果をまとめ、次回のリリース判断に必要な情報を共有する」というように、次の作業まで言葉にします。期限や判断者が決まっていない場合は、その点を会議の結論として明確に残します。

最後に「この分担と期限で進められますか」と確認し、難しい事情が出たら計画を調整します。合意とは、全員が同じ意見になることではありません。何を決め、何が残り、各自が次に何をするかを理解している状態です。

調整の経験を、次の開発にも生かす

打ち合わせの後は、決定事項だけでなく、自分の仮説と相手の反応を振り返ります。どんな仮説を置き、どの質問で必要な条件が分かったのか。まだ確認できていないことは何か。次の調整では説明や質問の順番をどう変えるかまで考えます。

研修でこの力を扱うなら、技術的な論点と役割ごとの判断条件を整理し、相手の事情を仮説にして質問する練習ができます。今回のテーマに合わせた演習例として、API仕様の変更を題材に、バックエンド、画面側、QA、プロダクト担当の役割に分かれて、影響を確認し、担当と期限を合意する場面を考えられます。実際の開発現場で試した後、次の学習機会で会議の結果と自分の関わり方を振り返れば、学びを別の調整にも使えるようになります。

人間力教育センターのリーダー育成アカデミーでは、他部門を巻き込む対話や指示・報告・調整などのテーマを組み込み、学び、現場での実践、振り返り、次の行動をつなぐプログラムを設計しています。若手の開発リーダーが、仕様調整を説明だけで終わらせてしまう、決めた作業が進まないといった課題があれば、対象者の役割や開発現場の状況を踏まえた育成についてご相談ください。

リーダー育成アカデミーについて相談する　お問い合わせ