色々な意味でカルチャーショックなプロジェクトの話です。

お客様との打合せ…議題は複雑で、図解をしたりして、何らかの「見える化」などの対策をしないとアッと言う間に「空中戦」になること必至のものでした。
＃少なくとも私にはそう思えました。

で、私達のポジション、役目はその打合せのファシリテートしていくものではなかったのです。
(今思えば)うまく立ち回ってファシリテートすれば良かったのですが、参加して日が浅く、また内容から考えて自分達が主でなかったため「様子見」をしてしまいました。

そして、打合せが始まりました。
予想通り5分もしないうちに議論している参加者の思い描いているイメージ、論理構成がおのおのずれていて、会話が噛み合わず、全く議論が進まないようになってきました。
しかも、「空中戦」なので、議論がずれていること、そして何がずれているのか、など当事者は意識していませんでした。

こんな「空中戦」を回避する方法の1つに「ホワイトボードを(有効に)使う」てのがほぼ定石だと思います。
＃会議術の基礎の基礎かなと。

ホワイトボードに、うまく整理し、満足感のある結論に導き出すのはそれなりに高度な技術だと思います…が、最低限、議論のポイントを書き出すだけでも、共通基盤ができる→それをベースに議論する…と安定した「地上戦」に持って行けると思います。

その打合せ…最後まで(約2時間！！)、ず～っと「言葉の空中戦」をやっており、最後まで「ホワイトボードを使った地上戦」になることはありませんでした。
＃私は手元のノートに会議が終わった後のタスクの段取りなんかを考えていました(苦笑)。

それ以降、自分が打合せに参加する際には積極的にホワイトボードの前に立つようになりました。
しかし、このお客様、余程「空中戦」が好きなのか、そこかしこの打合せでホワイトボードがすぐ近くにあるのに、空中戦をしています…。

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

Photo via VisualHunt.com

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

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

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

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

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

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

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

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

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

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

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

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

Photo via Visual hunt

もうずいぶん前の感じがしますが…2009年1月に納品したプロジェクトで、私が感じたことの1つに「自分には我慢が足りないなぁ」があります。

そのエントリにも書いていましたが、PJメンバーにいた新人と若手が「レベルアップする」というのが、(QCDという面での成功はもちろんのこと)プロジェクトのミッションの1つでもありました。
＃そして、毎度のことながら「レベルアップする」結果を出すのはとても難しいと思いました。

で、そのミッションを実現させるために、できるだけ毎日の朝会、仕様検討や(社内/社外を問わず)レビューなど様々なシーンで、2人に「～さんならどう思う？」とまずは聞いて、そこに答えがあれば、さらに「その根拠は？他のことはどんなのがある？」とロジカルに考え、そして判断できる力を少しでも付けてもらうようにしたり。
＃もちろん私なりの根拠ある答えを持っていますが。

また各人の進捗管理、タスク自体のやり方も、(基本的に)2人から発信がない限り、(ある程度意識して)放置したりしようともしました。
とはいうものの、自分の心配性やイラチな性格もあり、どうしても先に気付いた点や対応策、やり方などを言ってしまう場面も多々ありました。
2人にはその辺はあまり良い思いをさせなかったなぁと反省しています。

(ある程度プロジェクトの先が見通せた)終盤では「それは…」と言いそうになると「我慢、我慢…」と言い聞かせていましたが、まだまだマネジメントや色々な面で課題はまだまだあるなぁと。

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

Photo credit: mrbill78636 via VisualHunt.com / CC BY

どれくらい先かは分かりませんが、今後「したいこと」「できるようになりたいこと」の1つに「潔く本を諦める」ことがあります。

何度かエントリにも書いていますが、仕事関係の技術書やマネジメント系、その周辺領域のコーチングやファシリテーション、交渉力等の本を色々と買ったり、借りたりして読んでいます。

そんな本には題名やAmazonでの評価、ちょっと立ち読みした印象で「これは面白そうかも…」だったのが、いざ読み始めると「う～ん…」と思うものもあります。

「う～ん…」の中には「著者の考えが合わない」「文体が好きになれない」などの好き嫌いレベルから、「これは既に知識としてあるなぁ」「難しすぎて今の自分にはまだ早い」などの内容的なこともあります。

で「つまらんなぁ」など心理的にしんどい思いをしてまで読まずに、さっさと「潔く本を諦める」ことをしたいなぁと思っています。
ただこれが、「せっかく買ったんだし～」や「途中まで読んでいるんだし～」という意識がどうしても出るので、なかなか難しいんですね。
＃「難しすぎる」パターンは積読リストに放り込んで「いつの日にか…」というのがやりやすいのですが…。

最近、電車に乗っている時間も短くなったので、なかなかまとまった読書タイムがない中で読む本をうまく選別していきたいものです。

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

Photo via Visualhunt