システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。
＃ここでは仕様書に「○○機能の動きはAである」と記述されている前提です。
こんな時に、やってはいけない行動の1つが(理由も聞かず、検討もせず)「仕様書には【○○機能の動きはAである】と書いてあり、お客様にも承認をもらっています。それをBにするには別途費用と期間がかかります」なんていうことです。
この時点で「戦いのゴング」…それもあまり勝ち目のない戦い…が鳴ることになります。
こういう仕様追加/変更はもちろんのこと技術的な課題や問題など、システム開発では様々なものが発生します。
そして、それはどれほど予想して対策を考えても完全には防ぐことはできません。
＃もちろん予想と対策が不要と言いたいわけではありません。
この原因には、様々な要因…ユーザのレビュー、想定不足もありますし、自分達SIerのドキュメントや会話の伝達能力の低さ、読みの甘さ等…があります。
原因(とその真因)を突き止めることは意味がありますが、ややすると、【お客様(ユーザ) VS 私達(SIer)】の対決構図になり、問題そのものの解決より「要はお前らが悪かったんやろ！」的に責任(非)は相手にあると認めさせることにパワーを使うパターンに陥ります。
これに対して【問題 VS 私達(SIer+ユーザ連合軍)】のように、一種の同盟関係を作ると状況は良い方向に進むものです。
この同盟関係がプロジェクト序盤～終盤まで機能していると、問題に対しても「じゃあ、これどうする？(SIerやお客様それぞれの立場で)自分達のできることって何だろう？」という感じで、プロジェクトをドライブできます。
そのために、(しょうもない心がけですが)常に「【問題 VS 私達(SIer+ユーザ連合軍)】なんですよ」と言い続け、意識してもらいます。
具体的な例では、お客様と話す言葉遣い1つにしても普段から「【私達】のプロジェクトでは…」とMeではなく、Weを使います。
打合せ等では(議題にもよりますが)、対面に座る(対決的なポジションです)のではなく、(問題や課題が見える)ホワイトボードやプロジェクターに並んで座るようにします。
SEはロジカルに仕事を進めることが多い(仕様検討などはロジカルでないと破綻しますので)です。
が、こういう「泥臭い」部分も同じかそれ以上に大事だったりします。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Visual hunt
コメント