[ソフトウェア開発者の道具箱] イチゴジャムの法則

6月末に出版した 現場ですぐに使える! Visual Basic 2015 逆引き大全 520の極意 なのですが、この第19章には不思議な Tips が入っています。章自体は「トラブルシューティングの極意」ということで、運用保守や設計段階の落とし穴について書いた章なのですが、最後の10個の tips が「対人関係」になっています。端的に言えば、トラブルシューティングなんて、その場その場の経験の積み重ねと、根本的な対処の方法を知っていればよいだけなので、あまり表面的な対症療法なものは、これ以上追加したくなかったんですよね。というのと、試しに「技術書に技術的なじゃないものを紛れ込ませてみたかった」というのがあります。真面目に書くと、えらい時間が掛かるのだけど、Tips 風に1頁にまとまるぐらい(1000字ぐらい)を目標に書き下してみました、という具合です。

でもって、ものがVBだったからなのか、やっぱり読者対象がずれていたのか分かりませんが、まったく反響がないので、ここにブログの記事としていくつかついかしておきます。中身的には、見積もり本舗とか消えてしまった別のブログに書いてきたものでもあるのですが、なんらかの形で検索に引っ掛かるようにするもひとつかと。あと技術顧問的なことをやるので「ここ読んで」という具合にできるようにしておきます。

タイトルはワインバーグ著「コンサルタントの道具箱」から持ってきてるので、いわゆる「ソフトウェア開発者の道具箱」です。コンサルタントだと、どこかのシャチョーさんとかマネージャーを相手にするのですが、ソフトウェア開発者の場合は同僚やプロジェクトリーダー、新人、顧客の担当者が相手になります。書籍のほうは、改変が効かないのである程度オブラートに包んで話をしていますが、バックグラウンドには行動経済学とか心理学とか孫子とかそんなものも入っています。参考文献としては「コンサルタントの道具箱」しか出てきませんが、そのあたりは「読み取って」頂くというのが主旨でもあったり、そもそも「イチゴジャムの法則」ってのがそんなものなのです。

中心に何か伝達したいものがある、というのをイチゴジャムの法則では「粒」と表しています。その粒は、広げようと薄めようと逆に濃くしようとも同じなわけで、過不足なく書けば「粒」そのもになるけど、人によって受け取り方が違ったり詳しい説明が必要だったりするときには、粒の外側に解説を付け加えます。まあ、それが書籍の売りだったりするし、「コミュニケーション」とか「会話」とか呼ばれるものですよね。ツーカーの関係であれば、メール一本で済むようなところも、顧客との関係であれば電話をするなり相手先まで行くなりの「礼儀」的なコミュニケーションを必要とします。それをしないと「コミュ障」と呼ばれたり、相手からコミュニケーションの取れない人と排斥されてりします。書籍にちらっと書きましたが、このコミュニケーションを過剰に付ける技というものあります。いわゆる「広告」的なものだったり、上滑りな議論だったり、暇つぶしのお昼のワイドショーだったりします。「粒」がないのですから、どこまでも薄く薄く引き伸ばせるし、そもそも「粒」がないのだから、議論にも反論にもなりません。ただ、ぴーちくとさえずっているだけになります。そう、暇つぶしだったらそれでいいんですけどね。残念ながら、人によっては「粒」のありかが何処なのか見えなくなってしまって、疑似的な「粒」に引っ張られて議論がどこかに飛んで行ったりします。いや、もともと「粒」がないのだから、議論自体にもならないんですけどね。

そういうわけで、とあるコミュニケーション(顧客との間柄だったり、チーム内の間柄だったり)の中には「粒」があったりなかったりするわけで、若い頃には「粒」がない会話にイライラすることもあるでしょうが、いやいや歳をとると「粒」ない会話はそれはそれとして、頭の中で別な「設計」を考えたりできるようになるので大丈夫です。そのあたりの話は、けらえいこ著「たたかうお嫁さま」や「セキララ結婚生活」に詳しく書いてあります。

ちなみに、「粒」とはいっても、クオリアみたいにこれと示せるものではありません(つーか、クオリア自体がアレなので、そういう意味では「粒」ない会話を「クオリア的な」と言ってもよいかしれません)。そこは双方の合意のものとに通じるものでもあり、共通の個人的体験の重なりや、重ならないけどツーカーに考えられる、というようなひとつの単語や文では表せないものかもしれません。明示的なものであれば、UMLのようにあらわせるのですが、概念的なものは伝えにくいので暗喩(メタファ)を使います。メタファーを重ねることにより色濃くなる中央を明らかにするんですね。これは質問の応酬という形でも表せる(ディスカッションとは違います)ので、双方、それなりの技能が必要です。そういう意味では、文体が読者を選ぶというものもあり、かつこの文章自体もそういうメタファーに含まれているという意味で、やっぱり「粒」的なものを強化するために「イチゴジャムの法則」をもう一度持ち出してみるわけです。

河合隼雄著「中空構造日本の深層」のように、中空であるからこそ中央にあるものを双方が了解できるという場合も多いのです。私はこの方法を好みますが、最近の世の中はそうではなくなりつつありますよね。実際に中央にあるものを右に寄せたり左に寄せたりすれば、当然ならが双方の主張が異なるのだから議論が一致するはずはありません。一致することもなく、妥協もせずなのだから、そこは社会は広く階層化されている(ねじれの位置にあるという意味で)交差位置で満足すればよいのです。

さて、話を元に戻すと、ある程度価値観が一緒だったり、共通の体験があれば粒を使ったコミュニケーションが楽≒効率よくなります。まあ、そこがアジャイル開発的なチームビルディングなんですけどね。スクラムの本にもそう書いてあります。ある意味で、チームで残業をしたりチームで経営的な視点を持ったりチームで趣味を共有できたり、というのは、濃厚なコミュニケーションを欲しているのではなく(そういう場合もあるけど)、仕事上の煩雑なコミュニケーションを省略するために「あらかじめ」価値観を共有するという目的があります。なので、チームビルディングにおいて、スタート時点の「価値共有」と同時に「仕事上の価値の共有をお互いに認めることができるか?」というハードルも必要となり、組織だからこ組織に成り得るという分岐がそこにはあります。

そうそう、もうひとつのチームビルディングの仕方として「オーケストレーション」もあるので、こっちのは別の機会に。いわゆる LLC(合同会社) です。

カテゴリー: ソフトウェア開発者の道具箱 パーマリンク