サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

チームビルディング 旧館より 考え方

問題対私達の構図

投稿日:2009年4月12日 更新日:


システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。
#ここでは仕様書に「○○機能の動きはAである」と記述されている前提です。

こんな時に、やってはいけない行動の1つが(理由も聞かず、検討もせず)「仕様書には【○○機能の動きはAである】と書いてあり、お客様にも承認をもらっています。それをBにするには別途費用と期間がかかります」なんていうことです。

この時点で「戦いのゴング」…それもあまり勝ち目のない戦い…が鳴ることになります。

こういう仕様追加/変更はもちろんのこと技術的な課題や問題など、システム開発では様々なものが発生します。
そして、それはどれほど予想して対策を考えても完全には防ぐことはできません。
#もちろん予想と対策が不要と言いたいわけではありません。

この原因には、様々な要因…ユーザのレビュー、想定不足もありますし、自分達SIerのドキュメントや会話の伝達能力の低さ、読みの甘さ等…があります。

原因(とその真因)を突き止めることは意味がありますが、ややすると、【お客様(ユーザ) VS 私達(SIer)】の対決構図になり、問題そのものの解決より「要はお前らが悪かったんやろ!」的に責任(非)は相手にあると認めさせることにパワーを使うパターンに陥ります。

これに対して【問題 VS 私達(SIer+ユーザ連合軍)】のように、一種の同盟関係を作ると状況は良い方向に進むものです。

この同盟関係がプロジェクト序盤~終盤まで機能していると、問題に対しても「じゃあ、これどうする?(SIerやお客様それぞれの立場で)自分達のできることって何だろう?」という感じで、プロジェクトをドライブできます。

そのために、(しょうもない心がけですが)常に「【問題 VS 私達(SIer+ユーザ連合軍)】なんですよ」と言い続け、意識してもらいます。
具体的な例では、お客様と話す言葉遣い1つにしても普段から「【私達】のプロジェクトでは…」とMeではなく、Weを使います。

打合せ等では(議題にもよりますが)、対面に座る(対決的なポジションです)のではなく、(問題や課題が見える)ホワイトボードやプロジェクターに並んで座るようにします。

SEはロジカルに仕事を進めることが多い(仕様検討などはロジカルでないと破綻しますので)です。
が、こういう「泥臭い」部分も同じかそれ以上に大事だったりします。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual hunt

-チームビルディング, 旧館より, 考え方

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

自分のTwitterアイコンの変遷

Twitterアカウントのアイコンは干支をモチーフにしたものですが、元ネタはヨメさんが年賀状用に描いていたものです。 #コミュニティなどで使う個人名刺にも使っていて、名刺の作成は前川企画印刷さんのブロ …

プロジェクトにおける「割れ窓理論」

環境犯罪学上の理論に「割れ窓理論」というのがあります。 「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(Wikipediaより) 有 …

会議での「KY読めよ」な空気がキライ

議論が活発な会議で、費用対効果が出ているような会議ならそんなことはないのですが…。 生産的で無い、一方通行的報告的会議で質問すると… 「時間無いねんから」 「そんなんどうでもええやん」 …的な空気にな …

マルチスレッド

仕事の振り方が下手な人がいます。 「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。 …

文書化の指針

以前の「未来の自分を信頼し過ぎない」ことを書きました。 とはいうものの、何でもかんでもドキュメント化するのではなく、いくつかの要因(例として必要度合い)から判断して作るか決めれば…とも書きました。 私 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。