ITコーディネータの吉田聖書です。
先日、逆境におけるマイナス面を
プラスに転化した例が報道されました。
面白いと思ったのでご紹介します。
山形県の酒蔵で、
瓶詰めした後に地震が発生し、
銘柄が分からなくなってしまった瓶が
大量に生まれてしまいました。
さすがに栓を空けて確かめる
というわけにもいかず、
思案の末、銘柄の分からない
（どれが当たるか分からない）
「ラッキーボトル」として
販売することを決めたということです。
それ以外にも、
瓶詰めしてラベルも貼り終わった瓶が
地震によっていくつかの瓶の
王冠が凹んだそうですが、
それを地震を克服した
縁起の良いアイテムとして
販売することにしたそうです。
河北新報オンラインニュース
「ラッキーボトル」中身は何？ 銘柄不明の酒販売 新潟・山形地震支援に「もっけだの」
https://www.kahoku.co.jp/tohokunews/201908/20190822_52016.html
「銘柄が分からない」
「王冠が凹んでいる」
というマイナス面を
うまくメリットに転化した例
ということができると思います。
アメリカの元技術者で
コンサルタントのG.M.ワインバーグは、
マイナス面をメリットに転化することを
著書「コンサルタントの秘密」の中で
「ゴーマン法則」として紹介しています。
プログラマというものは自分たちのこの、欠陥を変じて機能とする能力を誇りとしているものだが、ゴーマン法則は決して彼らの専売特許ではない。
「コンサルタントの秘密」・47ページ
そしてその証拠として
ガソリンやバナナ、薬の副作用など
マイナス面をメリットに転化した例が
多数紹介されています。
さて、情報システムの構築も
依頼側の言うとおりに作ることが
全てではありません。
情報システムを構築、運用していると
どうしても不具合というものが起こります。
不具合というのは、
利用者が期待する動作と異なる動作の
全般を指しますが、
その中でもプログラミングに
起因するものをバグ（虫）と呼んでいます。
不具合のすべてがバグなのかというと
必ずしもそんなことはなく、
「そもそもそんな要件がない」
「明確に議論できていない」
といったことが原因で
不具合として認識されることもあります。
指摘された動作が
設計書（設計ドキュメント）に明記され
議論の余地がなければ
「これは仕様通りの動作です」
と一蹴することができますが、
設計書に明記されておらず、
どちらにも解釈の余地がある場合
「バグ」か「仕様」かで
押し問答になることがあります。
言われたとおりに作ることが
負担だったり無駄だと思える場合、
きちんと料金を払ってもらえるならともかく、
タダ働きは何としても避けたいため
実施側は作らずに済ませる方法を考えます。
こんな時、仮に今の動作のままでも
依頼側にメリットが感じられるような
説明や提案をすることができれば、
受け入れられるどころか喜ばれ、
スッと解決することがあるのです。
関連記事
- 見つかりませんでした。
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。