日本人は、阿吽の呼吸で伝わる文化を信じているのか、ストレートに依頼することが苦手なのか、曖昧な内容で合意して仕事が行われていることに驚くことがあります。
役割分担は、事前に決めたお互いがやることの約束です。システム開発プロジェクトを進めるにあたりクライアントとの役割分担を決めておくことは、当たり前ですが、役割を決めていても、解釈の違いから「聞いていない」となったり、曖昧な定義のため「想定と違う」となったりして、もめごとに発展することがあります。プロジェクトマネージャーは、QCDの達成に注力したいので、役割分担といった下らないことでエネルギーを削がれることは出来れば避けたいです。今回は、クライアントとの役割分担、事前に約束したお願いごとで揉めないためのポイントをご紹介します。
曖昧な合意は日常生活でも見られるので、ビジネスで起こったとしても不思議ではありません。
かんたんイラスト（記事を読む時間のない人へ）
クライアントの役割
システム開発プロジェクトでは、提案書あるいは計画書の中で、必ずクライアントとの役割分担を定義します。事前に合意しておくことで責任の所在を明確にするだけでなく、ベンダー任せになってしまう事態を避けクライアントに当事者意識を持ってもらう意味もあります。クライアントの役割として代表的な作業を下記に挙げますが、ざっくり言うと、仕様提示と情報提供、レビューと承認、調整の3つです。
・現行業務および業務要件の情報提示
・現行システムや周辺システムの仕様提示
・設計レビューと承認
・テスト計画のレビューと承認
・ユーザー部門との調整
・関連システムとの調整
役割で揉めた体験談
上記の例は、一般的に役割分担として定義する内容と思いますが、実は、ここに危うさが潜んでいます。この記載で問題ないと思った人は、少し危ないかもしれません。
このような内容で合意した結果、クライアントと揉めてしまった実体験を３つ紹介します。
① 現行システムの仕様提示
長く使ってきたシステムを刷新するプロジェクトで、開始前に、現行システムの仕様をクライアントから提供してもらう約束をしました。ですが、開始後に提示されたのは、業務引継ぎで使ったであろう断片的なユーザーマニュアルとシステムの概念図です。「ちゃんとした仕様書をください」と言うも、「これ以上の詳しい資料はない、約束通り仕様は提示した」の一辺倒で埒が明きません。
クライアントの言い分はざっくりであっても仕様を提示したということであり、ベンダーとしては提示された内容では仕様と言えないという押し問答が繰り広げられてしまったのです。
システム開発経験者であれば、仕様＝設計書の認識はありますが、マニュアルや概念図を仕様と捉えるクライアントもいます。現行システムの設計書がないことを知りつつ確信犯として仕様提示を約束したのかもしれません。結局、最新化された完全な設計書は存在していないため提供できないことがわかり、クライアント責任者と協議し追加の費用を頂いて現行システム調査をすることになりました。計画の見直しが必要となったため、クライアント責任者からはきっちり合意しなかったことの叱責を受け、気分は良くありませんでした。
“仕様”という言葉が曖昧かはさておき、クライアントと共通認識を持てていなかったことが問題です。
日常生活でも、買いものをお願いする時“何か飲み物”のような曖昧な言葉は揉める原因です。
Ａ：「何か飲み物買ってきて」
Ｂ：「わかりました」
Ｂ：「どうぞ、コーヒーです」
Ａ：「コーヒー飲めないんだけど」
Ｂ：「頼む時に、言ってくださいよ」
② 設計レビューと承認
設計レビューと承認はクライアントの役割と事前に合意しました。いざ、設計レビューをお願いすると、「設計書の見方がわからない」「レビューをして欲しいならポイントを整理してくれ」と言われたことがあります。
当時チームリーダーでしたが、まだ経験不足なこともあり、確かにそうかもしれないしクライアントのためにもポイントは整理しようと思い、設計書の構成を分かりやすく示した資料を作り、それぞれの設計書に吹き出しでポイントを記載したことがあります。これには、かなりの工数がかかることになりました。本来的には、掻い摘んでポイントだけレビューすることは、部分承認となってしまう可能性があるため、それ自体が良くありません。もしもポイントとして挙げなかった箇所で開発以降に仕様齟齬が見つかった場合、「聞いてない」と言われて、それこそ揉める原因となります。クライアントには設計レビューの目的を正しく理解してもらわないといけませんでした。
日常生活でも、妻が夫にイベント日を連絡したものの、求めていることが伝わっていないことはあります。
妻：「25日は子供の運動会だからね」
夫：「ふーん，そうなのね」
子：（前日）「パパ、明日の運動会だけど、行けるよね？」
夫：「えっ、仕事だよ」
妻：「前に伝えたよね、なんで休みとってないのよ」
夫：（頭の中で）聞いたけど、休んでってことだったのー
③ ユーザー部門との調整
クライアントのシステム部門がバイヤーで業務部門が利用ユーザーという関係性のプロジェクトで、業務部門との調整はシステム部門の役割として事前に合意しました。すると、システム部門担当者から「業務部門との仕様確認会議を設定しました」と連絡があり、「開発チームから誰か参加した方が良いですか？」と聞くと、「参加ではなくて、説明をしてください」と。いざ業務部門へ仕様の説明をしていくと、もっとこうして欲しいというリクエストを受けることに。すると会議後、システム部門担当者から「あんなに要望受け付けてどうするつもりですか？」と。「調整はシステム部門の役割ですよね、要望をどう扱うかは、システム部門で決めてください」と言っても、「調整は会議だけです。仕様を取り込むかはベンダーの仕事です」「取り込めないなら業務部門に断り入れてください」と揉めることに。
調整と一言で言っても、会議設定だけと考えているクライアントもいますし、説明まで含めていることもあれば、説得までの場合もあります。ここで特に重要なのは、説明と説得は大きく違うことです。利用ユーザーと仕様を詰めていくとやりたいことが膨らむ場合があります。それを全て取り入れると予算を超過するため、調整が必要となりますが、この膨れた仕様の調整、いわゆるスコーピングの作業を行うのが、ベンダーかクライアントかで揉めることがあります。一度膨らんだ仕様を削っていき、予算と納期に収まる内容でユーザー部門と合意することは結構大変な作業です。
日常生活でも、妻が夫へ料理をお願いすると、やりたいことだけやられてしまうかもしれません。
妻：「今日、疲れたから、料理よろしくね」
夫：「ＯＫ，任せて！」
夫：「できたよー」
妻：「確かに料理はできてるけど、キッチンがすごいことに・・・」
夫：「えっ、片付けもやらないといけないの？」
妻：（頭の中で）片付けも含めて料理でしょー
役割分担で揉めないための対策
役割分担を明文化するためによく使われるのがタスク一覧ですが、これで整理することが揉める原因を作ってしまう場合があります。揉めないためには、どのように記載すればよいのでしょうか。
１．主担当だけ記載する
揉めないようにタスク一覧に役割を定義するには、一つのタスクに対して、主担当だけ記載することです。よくある駄目な記載は、一つのタスクに対して、「主担当：ベンダー、副担当：ユーザー部門、支援：システム部門」のように複数のプレイヤーを書いているケース。これだと、そのタスクの何が主で何が副か、それこそ不明確です。前述の【体験談③ユーザー部門との調整】は、”調整”の作業範囲が不明確だったことが揉めた原因です。この例で言えば、ユーザー調整という一つのタスクではなく、会議の調整と設定、仕様の説明、要望が膨れた場合のユーザー説得、と３つのタスクにして、それぞれに主担当だけ記載すべきです。一つのタスクに対しては、必ずプレイヤーは一人だけ記載するルールを徹底すべきです。
２．インプットを明確にする
各タスクが何のための作業か、目的を伝え切れていない場合があります。これは各タスクのインプットを記載することである程度予防できます。【体験談②設計レビューと承認】は、”レビューと承認”の目的が正しく伝わっていなかったことが原因でした。クライアントのタスクである設計レビューのインプットに、「全ての基本設計書 ※レビューのための改編・加筆なし」と記載するだけで、この事態を避けられたかもしれません。
３．アウトプットを定義する
タスク一覧に作業内容を記載しても、その捉え方は人それぞれです。解釈の違いを無くすためには、タスクのアウトプットを具体的に記載するべきです。【体験談①現行システムの仕様提示】は、”仕様”という曖昧な言葉が揉めた原因でした。現行システムの仕様提示のアウトプットに、システム全体図、画面設計書など提供して欲しい明確なドキュメント名を記載すべきです。具体的に書くことで、これはどういう内容が記載されたドキュメントですか？というやり取りが発生し、事前に認識を合わせることができます。
まとめ
役割分担は、いわば契約書のようなものです。
キックオフミーティングでクライアントの役割について説明をして、責任者も含めて合意することが大切です。
システム開発プロジェクトはクライアントが実現したいことを達成するものなので、クライアントと共に推進することは当然で、役割分担は、その共同作業において、誰が何をやるのかの約束事です。日本人だから、曖昧でも理解してくれるとか、ストレートにお願いしたら嫌な顔をされてしまうかもとか思って、なあなあに済ませてしまうと、後から揉めることになってしまいます。事前にきっちりと合意することは、プロジェクトマネージャーの大切な仕事のひとつです。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
