このサイトは、javascriptを使用しています。javascriptをONにしてください。

大人の人生はおもしろいか

この質問に答えようとすること。これこそが、僕らの創造と豊穣の源泉なのである。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
--/--/--(--)  スポンサー広告
▲このページのTOPへ

プロマネ④~コミュニケーションバグ~

システム開発をしていると、さまざまなバグが発生します。

バグというと、各関係者なりの視点で、さまざまなバグを想像すると思います。

例えば、プログラマなら
プログラムバグ、仕様書のバグなど
を思い浮かべると思います。

インフラ基盤を設計する人だったら
各種機器類のパラメータ設定ミスなど。

システムをいざリリースしてみたら、
ユーザから、こんなはずじゃない
なんていわれちゃうのも、一種のバグかもしれません。


で、今日お話したいのは、そのバグの解釈の話です。

つまり、バグというからには、バグを誘発した原因があるわけで、
その原因をどこに求めるか
といった話をしたいと思います。


バグが発生した場合、人はそのバグを解釈します。


プログラムバグの場合であれば、プログラムを書いた人の能力がなかったのだろう
と解釈するかもしれません。

機器類のパラメータ設定ミスであれば、単なるケアレスミスだという
解釈になるかもしれません。

ユーザからこんなはずじゃなかったなどと
いわれてしまう場合であれば、
ユーザ部門の担当者が変な人だったから
という解釈なのかもしれません。

その解釈のところで
誰かを悪者にしまうというのは、得策ではありません。

なぜなら、次の理由が挙げられます。

1.角がたつ
 誰々の技術が未熟だったからとか、
 誰々が設定を間違えたからとか、
 誰々がちょっとおかしいからとか、
 そういった解釈をプロマネがしているということになると、
 チームプレーをしている関係上、チーム内不和を誘発します。
 プロマネは、バランサーであるべきですので、個人の評価は腹に強く思っていることであっても
 軽率に公言すべきではありません。

2.説明が見苦しい
 問題を顧客・上席者に説明するときなどに、「誰々が悪いからです」などというと、
 幼稚な印象を与えてしまいます。
 

図式としては、問題VS我々という構図を作ったほうが、
チーム内団結力の点でも、得策なようです。

それでは責任の所在がわからなくなるという意見はあるかと思うのですが、
日本文化、特に、大企業でのプロジェクトの場合、
個人の責任はなるべくあいまいにするほうがよいようです。
理想的な解釈としては、大岡裁きの”三方一両損”のような
そういった穏やかな解釈が望まれます。


そんな解釈の仕方として、
”コミュニケーションバグ”という視点はいかがでしょうか
というのが、今日、私が言いたいことなのです。

先日とあるプロジェクトで、こんなバグがありました。

そのプロジェクトは、既存のシステムをリプレースするプロジェクトだったのですが、
システム基盤が変更されるのに伴い、既存のシェルを大量に変更する
という作業がありました。

・まず、変更するシェルが大量にあるため、その管理上の混乱をさけるため、
 修正・管理する要員を割り当てました。(修正担当者S)
・そして、修正指示者Xは、その修正担当者Sに修正を指示しました。(修正A)
・その後、別の修正も必要であったため、別の修正指示者Yがその修正担当者Sに
 修正を指示しました。(修正B)
・その後、修正対象のシェルが間違っていたことが判明したため、
 修正指示者Xは修正Aを再 度指示しました。(修正A´)
・その後、正しい修正対象に対して、修正Bがなされなかったためバグとなってしまった
 というものです。

なにやってんだい!というようなバグですが、
バグとは、えてしてこんなものです。

悪者を探そうとするのは、簡単です。

例えば、Xを悪者にするには、ちゃんと修正Bのことまで気にかけとけよ、ということになるし、
Yを悪者にするには、ちゃんと修正対象が正しいかどうかを確認しとけよ、ということになるし、
Sを悪者にするには、修正にはA、Bがあるのをわかっているのだから、A´の指示を受けたときに、
Yに対して、修正Bが再度必要かどうか確認をとるべきなんじゃないのか、と。

実際のところ、誰もが悪いといえば、悪いのだと思いますが、
みんな、”人のやっていることに興味をもとうよ”、という教訓と供に
”コミュニケーションバグ”と解釈したらどうだろう。

そしたら、あら、不思議。
X、Y、Sともに一両損して、”三方一両損”となったではないですか!
そして、
「僕らには、コミュニケーションの齟齬という大きく困難な問題があります。
そしてその問題に立ち向かう勇敢な私たち」
というチームの団結力を醸成する美しい構図に
なったではありませんか!

コミュニケーションバグという視点は、関係者が二人以上存在し、
その関係者全体に対して責任がいくということで、罪が分散し、
問題VS私たちという構図を作りやすいという特徴を持っています。

それに、こういった視点をプロジェクトメンバーに植え付けておくというのは、
プロジェクトを推進していく上で、大変重要です。

なぜなら、アラートをキャッチしやすくなるわけですから。
システム開発というのは、”問題の発見と解決、および関係者への情報の伝達”であるということを以前言いました。

コミュニケーションバグという視点は、問題の発見と、関係者への情報の伝達
という、この部分を強化する効果があります。
したがって、重要なのです。


【ブログランキングに参加しています。ポチッと一票入れてくださいね!】
ランキング
読んでいただいて、ありがとうございます。
スポンサーサイト
2008/01/05(Sat)  未分類コメント(0)トラックバック(0)
▲このページのTOPへ

コメント





















管理者にだけ表示を許可する

▲このページのTOPへ
▲このページのTOPへ
| HOME |
▲このページのTOPへ
プロフィール

やまいも

Author:やまいも
金融系システムの仕事をしています。
趣味は理屈をこねること。
そして、こねた理屈で人類の幸福を希求する。
これが私の願いなのです。

代表的な記事としては、次のものがあります。

「空気を読む」という言葉に内包されている危険な側面
人類の進化という観点から捉えた金融危機の意味について
自由論
HappynessとSuccessそして有能であるということ
やさしさについて
自我(エゴ)

twitter表示プラグイン
twitterユーザ名:yamaimo_
FC2カウンター
検索フォーム
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。