ユーザーに質問を送っても返ってこないのは

ソフトウェア開発に限った話ではありませんが、オーダーメイド系のモノ作りをしている企業であれば建築であれなんであれ、お客さまに細かい点について質問しなければならないような部分があると思います。

そうした場合に「なんとなく」の信頼関係の中で進めていると、上手くいかないシーンも出てきます。特に開発現場のスケジュールは逼迫しているにもかかわらず、お客さまのスケジュールも逼迫していて、なかなか回答が得られないまま時間だけが過ぎていってしまうようなシーンは経験したことがある人も多いのではないでしょうか。

少なくともＢ２Ｂで開発するソフトウェア開発業の中では、次のような流れで互いに信頼し合って、自らの責任を果たし、スムーズに作業が進むような現場…と言うのは稀です。

これが確認メールの代わりに、口頭でのやり取りでもそうですし、定例会などの会議の場であっても基本は同じです（中には記録に一切残さず、口頭でのやり取りだけしか行わない現場もあるでしょうが、そちらは「いった／いわない」の水掛け論に発展するだけで、そもそも推奨しないため割愛します）。

こうしたやり取りの中で最も怖いのは、

　「お客さまが解答をなかなか返してくれなくて進捗が遅れる」

ケースです。

この時、お客さまの多くは「多忙」を言い訳にします。
実際「多忙」は嘘ではないのでしょう。システムやソフトウェア仕様を知るような重要なポジションを担っている担当者は大抵、他にも多くの仕事を持っていて、忙しそうに走り回っていることが多いものです。

ですが、だからと言って相手のことを慮ってそのまま放置していると、大抵プロジェクトは大変な状況に陥ります。結果、製造工程以降のメンバーに高稼働を強要しなければならなくなりますし、そうしたスケジュール逼迫の中で作業させるとソフトウェア品質にも必ず問題が出てきたりします。

これはどこの企業でも、どこの現場でもよく起きることです。

詳しく聞こうとしても、なかなかお客さま担当者の日程都合が取れず、いつまで経っても仕様が確定しません。既に、そのような空気が出来上がってしまった現場で、急に「問題が起きないように」することは至難です。こうしたリスクは活動開始前のうちから手を打っておかなくてはなりません。

本来、こうした問題を完全に回避するのであれば、プロジェクトチームの上長（決裁権を持つ者）が、契約段階（プロジェクト着手前の時点）でお客さま担当者の上司も巻き込んで、

　"ルール"を作っておいてもらう

と言うのが最も効果的です。
一番いいのは、

　「質問者が指定する日付までに回答していただく」

なのですが、これは質問者にとって都合がよすぎるため、時として回答者に大きな負担をかけることにもなりかねません。まれに現場のエンジニアによっては無茶ぶりをして"当日中"や"明日中"と言った要求をする人もいたりします。

そうなるとお客さま担当者が本当に多忙の場合、そちらに負担がかかってしまうことにもなりかねません。そこで、対案としてよく用いられるのが

　「質問日から原則〇営業日以内。
　　ただし、困難な場合は指定期日を決めて、遵守する」

です（通常は５営業日…つまり１週間以内にします）。

質問表や課題管理表などを用いる場合、多くは「回答期日」の欄があるかと思います。そこに、質問起票日＋５営業日を基本的に記入するとして、どうしても時間がかかるなどの都合があって、５営業日以上かかると分かっている場合は、回答責任者の実現できる期日を明記してもらうようにします。

この「回答期日」がない質問は『優先度がない』ということです。

回答してもしなくても、どちらでもいいと言っているようなものなので、
いつまで経っても回答してくれないと思っておいた方がいいでしょう。

こういうルールを、プロジェクト発足時の時点でお客さまと、自分たちのチームメンバー全員で共有する機会を持ちましょう。必須なのは

　・お客さま担当者
　・プロジェクトマネージャー／リーダー

です。
また必須ではないけれども、効果を確実に保証したいのであれば、

　・お客さま担当者の上司
　・自プロジェクトの上長（管理職）
　・自プロジェクトのメンバー

も巻き込んでおくと良いでしょう。もしも、プロジェクト発足時にキックオフのようなものを実施するのであれば、極力関係者は全員参加の上で、こうしたルールや徹底事項を周知し、みんなの前で「遵守する」と意識付けた方が徹底力が向上すると思います。

もしも、この上司や上長が面倒くさがったり、あるいは担当者やマネージャーが上司を呼ぼうとしたりしなければ、おそらくこのルール自体が形骸化します。最初からルールなんて守る気はないと言うことだからです。

上司の知らない中で、現場同士、担当者同士でコソコソと勝手に進めていると、進め方に問題があった時に誰もフォローができません。

プロジェクトの全体に関わるようなことは、どんな些細なことであっても上司、上長を巻き込んでおくことが肝要です。

もしルールも作らず、かつ期限を切っても守らず…と言う中でプロジェクト進めると言うのであれば、それはもうマネジメントすることが不可能ということです。何を軸にして進めていいかもわからず、無法地帯の中で好き勝手に進めると言うことになります。

　計画も立てず、
　進め方も定まっておらず、
　ルール１つも作らず、守らず、
　とにかく勝手に進め、勝手なモノ作りだけしていたい

と言う人を守る組織も人も存在しません。チーム活動になる以上は、必ず「チーム活動であるからこそ」の個人活動との違いが必要です。

チームと個人の違い、難しさは何でしょう？

それは

　・足並みをそろえること
　・コミュニケーションを成立させること

ではないでしょうか。１人だと意識しなくてもよかったことが、チームだと色々足枷に感じるかもしれません。ですが、足並みがそろってくると１人でできることよりももっと大きなことができるようになっているはずです。

では、どうやったら足並みがそろうのでしょう？

１人だと自分の中で考えるだけでよかったことが、他の人とコミュニケーション（情報伝達や情報共有）しなければならなくなってきます。煩わしいと感じるかもしれませんが、それがスムーズに行えるようになってくると、役割分担や分業ができて、自分自身の負担も最小化されていくはずです。

どうやったら、スムーズなコミュニケーションが成立するのでしょう？

そうしたことを予め決めるのが『ルール』です。

ルールはシンプルであればあるほど、『客観的再現性』が保証されます。客観的再現性…すなわち「誰でも、同じ品質、同じ結果になる」ということです。ルールを決めておけば、ルールに従って行動する人たちの足並みがそろい、互いに負担をかけあわずに済むようになるのです。

チーム内だけに閉じたルールはよく考えられたプロジェクトを見かけますが、意外にもチーム外（ステークホルダー）との間でのルールは杜撰なまま…と言うのは珍しくありません。

大きな問題を起こす前に、こうした些細なルールも含めて見直してみると良いのではないでしょうか。