一見無害だが危険な言葉

Gerald M. Weinberg / 青木靖 訳
2007年3月12日 月曜

コンサルタントとして成功するためには、一見無害な言葉に注意を払う必要がある。コンピュータソフトウェアの分野では、そういうブビートラップみたいな言葉が満ちあふれている。このことについて、 おそらく多くの人にもっと馴染み深いだろう犬のトレーニングの話を交えて紹介しよう。

私の妻のダニはプロの文化人類学者であり、当然のこととして 優れた聞き手だ。文化人類学の仕事はもう引退したが、文化人類学者およびマネジメントコンサルタントとして培ったスキルと経験を元に、今は犬を飼っている人や犬のトレーナーのための行動コンサルティングをしている。この組み合わせからはたくさんの興味深いアイデアが生まれている。彼女が話してくれた攻撃犬の訓練の話もそうだ。いつものごとく、攻撃犬における大きな問題は、犬によってではなく、人によって起きる。

犬が攻撃訓練を受けていると聞くと、3人に1人は犬に向かって「殺せ!」と命令する。

ジョークとしてね。

あるいは単に犬がどう反応するか見てみるために。

こういう人間のばかな振る舞いと言葉に対する不注意さから守るため、攻撃犬のトレーナーは攻撃の合図として「殺せ」みたいな言葉は決して使わない。代りに、彼らは「健康」のような、命令形で使われることのない無害な言葉を選ぶ。

このような安全策が必要なのは、訓練された犬というのは一種の情報処理機械だからだ。大きな歯を持ったコンピュータみたいなものだ。何でもない命令が、どう訓練されているか(どうプログラムされているか)に応じて、犬には何かを意味するかもしれないのだ。

この恣意性は、攻撃犬でなければあまり問題にはならない。「ロールオーバー」(転がれ)という命令で犬がボールを拾ってくるなら、調教師は当惑するかもしれないが、そんなに害があるわけではない。しかし犬が「ロールオーバー」でのど元に飛びかかるように訓練されていたなら、話は全然違ったことになる。

 

保守、あるいは歯のあるコンピュータ

コンピュータも同じだ。コンピュータはプログラムされるものであり、プログラムで使われる多くの言葉の意味は恣意的なものだ。たった1つの間違いによって、役に立つコンピュータが会社を襲って殺してしまうかもしれない。ソフトウェアの保守をすごく軽く考えているクライアントのことを私が理解できないように思うのはそのためだ。保守はそんなに出来の良くない(そして安い)人でもやることができ、公式に管理する必要も規律ある開発をする必要もないとマネージャが口にするのを、何度も聞いたことがある。 保守なんてそんなに重要なものじゃないというのだ。そしてどんなに説明しようと、そうではないのだと彼らに納得させることができない。彼らが保守で高くつく失敗をするまでは。

幸いに(あるいは不幸にして)、高くつく保守の失敗というのはよく見られることなので、マネージャたちはたくさんの教訓を学んでいる。まあ授業料は安くないが。私はクライアントが犯した高くつくプログラミングのミスを記録した秘密のリストを持っているが、 最も高くついたものの多くは保守における誤りだ。そしてそれらのほとんどすべてが、それまで動いていたプログラムに対する数字1つの変更によって引き起こされている。

それらのケースではいずれの場合も、変更が無邪気に「簡単」だと言われ、マネージャがレベルの低い保守プログラマに「その数字を変更しろ」とカジュアルに命ずることで行われている。書かれた指示もなければ、テスト計画もなく、誰も変更をチェックせず、実際のところ、そのプログラマと日々の 運用との間でどのような調整も行われていない。これはまさに「殺せ」に対して攻撃するように訓練された犬を飼っているようなものだ(むしろ「こんにちは」かもしれない)。

 

たった1行の変更

保守での変更が誤ってなされる可能性は変更の大きさに対してどれくらいあるものか、私は調べてみたことがある。この結果は他の人にも確認してもらっている。 以下に挙げるのは、その結果をまとめた表の頭の部分だ。

変更行数 誤りのある可能性
1 0.50
2 0.60
3 0.65
4 0.70
5 0.75

開発者はこの高い割合を見て驚くようだ。それには2つの理由がある。第1に、開発における変更というのは、保守における変更よりも簡単だということがある。それは開発での変更が、よりきれいで、小さく、良く構造化されたコードに対してなされるためだ。通常はコードがはるか昔に知らない人間によって何度も変更されているようなことはなく、 そのため、予期しない依存関係をたくさん含んでいたりはしない。そういう依存関係こそ、私の知るもっとも高くついた惨事に関わっていたものだ。

第2に、開発時における間違った変更がもたらす結果というのは通常小さく、実際の運用に影響を与えずに修正することができる。そのため、開発者は間違いをそれほど気にかけず、誤りを犯す確率を実際より小さく見る傾向がある。

開発においては、単に間違いを修正して、陽気に進み続けることができる。しかし保守ではそうはならない。その誤りのもたらしたダメージの後始末を しなければならず、ミーティングで膨大な時間を費やして、そのような誤りが今後二度と起きることがない(次に起きるときまでは)ことを説明するのだ。

これら2つの理由により、開発者は保守における誤りの確率の高さを、保守プログラマの無知や経験のなさのためだと考えがちだ。しかしこの表をさらに下の方へと見ていくと、原因が無知のためでも無経験のためでもないことがわかる。

変更行数 誤りのある可能性
10 0.50
20 0.35

変更のサイズが増えると誤りの起きる可能性が減るということは、実際には保守プログラマが小さな変更での成績が示すよりも能力があることを表している。それは「簡単」な変更は真剣に受け取られず、そのため不注意に、管理を受けずに実施されるためなのだ。プログラマがこんな風に言うのを、何度聞いたことがあるだろう? 「簡単さ! 1行修正するだけだ!」

 

誰がこの無害に聞こえる言葉を作ったのか?

そうしてそんなプログラマの言葉に、マネージャが同意するのを何度耳にしたことだろう? あるいは「小さな変更」だから「汚く手っ取り早く」やることを認めてしまうのを?

そういう無邪気な態度は、「小さな」変更が本当に小さい場合には理にかなっているのかもしれない。プログラムの保守が、たとえばアパートの建物の保守のようなものであるなら問題はない。用務員のやる保守が危険でありえないとは言わないが、台所の流しのワッシャーを1つ変えたところで、建物が崩れて住人を生き埋めにする危険はないと仮定できる。しかし同じ仮定を、ビジネスを日々動か しているプログラムに対してするのは安全ではない。私たちは言葉をとても自由気ままに使っており、「保守」は一方の状況から他方の状況へと不適切に流用されてしまったのだ。

コンピュータプログラムにおける「保守」という言葉を作った人が誰なのであれ、その人は「殺せ」とか「こんにちは」という言葉で攻撃するように犬を訓練する人と同じくらいに考えがなく、不注意なのだ。 すでに後の祭りではあるが、「保守」プログラマというのは、用務員よりも脳外科医に近い。生きているシステムを 開けるというのは、流しを開けてワッシャーを替えるというよりは、頭を開けて神経を替えるようなものだからだ。もし保守が「ソフトウェア脳外科手術」と呼ばれていたなら、簡単にやれることだと考えられただろうか?

こう考えてごらん。あなたは攻撃犬に「殺せ」と言う悪い癖がある。それであなたは脳外科医の所に行って、こう言うのだ。 「先生、ちょっと私の頭蓋を開けて、この小さな癖を取り除いてもらえませんか? 手早くやってもらって構いませんよ。小さな変更なんだから! ごくつまらない保守作業でしょう?」

 

教訓

もちろんコンサルタントたるあなたは、言葉に対してこんな風に不注意ではないはずだ。そうだよね?  しかしそういう問題——破滅的な小さな保守のような——を抱えているクライアントに呼ばれたときには、彼らの「無害な」言葉を注意して聞くことだ。そこには小さな変更をして問題を解決する必要がある ことの手がかりがあるかもしれない。

「おっと、ちょっと待ってください!」

 

home  rss  

オリジナル: Innocent but Dangerous Language