 |
さて、次にソース・コード（C#）を例に挙げてみよう。以下に挙げるのは、「モンテカルロ法によって円周率を求める」というサンプル・プログラムだ。
ちなみに、「モンテカルロ法」というのは、乱数を用いて近似解を求めるアルゴリズムだ。ここでは円周率を求めている。
namespace PiByTheMonteCarloMethod
{
static class Calculation
{
public static double Square(double x)
{ return x * x; }
public static double SquareDistance(double x, double y)
{ return Square(x) + Square(y); }
}
class Position
{
double x, y;
public Position(double x, double y)
{
this.x = x;
this.y = y;
}
public double SquareDistance
{ get { return Calculation.SquareDistance(x, y); } }
}
static class Target
{
public const double radius = 1.0;
public const double diameter = radius * 2.0;
}
static class Dart
{
public enum Result { Hit, Miss };
static Random randomNumber = new Random();
public static Result Throw()
{ return Judge(HitPosition()); }
static Position HitPosition()
{ return new Position(PositionByRandomNumber(), PositionByRandomNumber()); }
static double PositionByRandomNumber()
{ return Target.diameter * randomNumber.NextDouble() - Target.radius; }
static Result Judge(Position HitPosition)
{ return HitPosition.SquareDistance <= Calculation.Square(Target.radius) ? Result.Hit : Result.Miss; }
}
static class DartsHall
{
public static double Game(int throwNumber)
{
int hitNumber = 0;
for (int count = 0; count < throwNumber; count++)
{
if (Dart.Throw() == Dart.Result.Hit)
hitNumber++;
}
return (2.0 * 2.0) * hitNumber / throwNumber;
}
}
}
|
|
| 「モンテカルロ法によって円周率を求める」プログラム（C#） |
|
| |
|
|
これは、英語を主としたソース・コードだ。そのためクラス名やメソッド名、変数名などは英語で付けられている。
英語圏の人が英語のソース・コードを見る場合は、多分、とても早く内容をつかむことができるだろう。
彼らにとっては、むしろ英語に不慣れな日本人プログラマーが以下のソースを見るがごとくに英語のソースが見えているのではないか。
namespace モンテカルロ法による円周率
{
static class 計算
{
public static double 二乗(double x)
{ return x * x; }
public static double 距離の二乗(double x, double y)
{ return 二乗(x) + 二乗(y); }
}
class 位置
{
double x座標, y座標;
public 位置(double x座標, double y座標)
{
this.x座標 = x座標;
this.y座標 = y座標;
}
public double 距離の二乗
{ get { return 計算.距離の二乗(x座標, y座標); } }
}
static class 的
{
public const double 半径 = 1.0;
public const double 直径 = 半径 * 2.0;
}
static class 矢
{
public enum 判定結果 { 命中, 外れ };
static Random 乱数 = new Random();
public static 判定結果 射る()
{ return 命中かどうかの判定(刺さった場所()); }
static 位置 刺さった場所()
{ return new 位置(乱数による座標値(), 乱数による座標値()); }
static double 乱数による座標値()
{ return 的.直径 * 乱数.NextDouble() - 的.半径; }
static 判定結果 命中かどうかの判定(位置 刺さった場所)
{ return 刺さった場所.距離の二乗 <= 計算.二乗(的.半径) ? 判定結果.命中 : 判定結果.外れ; }
}
static class 弓道場
{
public static double 試合(int 矢を射る回数)
{
int 命中した回数= 0;
for (int 矢を射た回数 = 0; 矢を射た回数< 矢を射る回数; 矢を射た回数++)
{
if (矢.射る() == 矢.判定結果.命中)
命中した回数++;
}
return (2.0 * 2.0) * 命中した回数 / 矢を射る回数;
}
}
}
|
|
| 「モンテカルロ法によって円周率を求める」プログラムの日本語多用版（C#） |
|
| |
|
|
ところで、日本においても慣例的にソース・コードは英語で書かれることが多い。
たとえ日本人プログラマーであっても、日本語で名前を付けることに違和感がある人も多いだろう。
私も日本語で名前を付けることに違和感はある。それは、下のようなものだ。
|
日本語で名前を付けた場合の違和感：
- C#も含めプログラミング言語の多くは英語ベース。構文やキーワードは英語がベースとなっている。地の文が英語なのに、そこに日本語が混ざる違和感。「重箱読み」や「湯桶（ゆとう）読み」のような違和感。
|
|
|
| |
|
|
ただし、英語で名前を付けた場合にも違和感はあるのだ。
|
英語で名前を付けた場合の違和感：
- 自分のモデルに登場する名前と異なった名前を使う違和感。同じ概念なのになぜ同じ名前で呼ばない？ なぜニュアンスの違う別の名前に替える？
|
|
|
| |
|
-
聞いた話だが、「日本語が母国語である人が漢字やかなによる日本語の表記を認識する時間」と、「英語が母国語である人がアルファベットによる英語の表記を認識する時間」を比べると、前者の方が大分早く認識することができるそうだ。
もし日本語が母国語である人について、日本語の表記と英語の表記の認識時間を比べればその差はもっとずっと大きいはずだ。日本語の場合の方が何倍も早く認識できるだろう。
| つまり日本語表記を使ったときの方が、よりブロードバンドなのだ。 |
ソース・コードは設計に関する重要なドキュメント（＝設計をコミュニケーションするための文書）でもある。読めればよい、コンパイルが通ればよい、というものではない。それは、「コミュニケーションという価値にコミット」しているという態度とはいえない。
相手に伝える、ということが、そのプロジェクトにとって大切だと思っているのであれば、伝えようとしている相手にソース・コードというドキュメントが最も広帯域で伝わる方法をとるべきだ。
英語が適していることもあれば、日本語が適していることもあるだろう。これはほかの仕様書や設計書などのドキュメントと同様だ。例えば、ソース・コードを読む人の中に、日本語が苦手な人がいる可能性がある場合には、英語を用いるべきだろう。だが、この場合、仕様書や設計書などのソース・コード以外のドキュメントにも同様に英語を用いるべきだろう。
-
例えば、問題領域で「図形」と呼び、分析モデルや設計モデルでも「図形」と呼ばれていた概念があったとする。そしてそれを、ソース・コードで「Figure」のような微妙にニュアンスの異なる別の言葉に言い換えるとする。これは、コミュニケーションにとって一種の障害となるだろう。
-
-
前回聞いたと思うが、
| 同じ概念には同じ名前を付けて、異なった概念には違う名前を付ける |
というのは、良いコミュニケーションのための重要な原則だ。同じ概念のものを異なった名前で呼ぶべきではないのだ。
-
もちろん、ソース・コードを読むのが全員ネイティブな日本人であるとしても、英語でソース・コードを書きたがる人もいるだろう。この場合、もし日本語と英語が同じ速度で認識できる人たちで構成されたチームであれば、それは当然の選択だと思う。つまり、英語がコミュニケーションの障害とならない場合や、英語の方がコミュニケーションがスムーズな場合に英語を用いるのは当然だ。
 ちなみに、日本語を使ったソース・コードのことを、私は、
おたふくソース
と呼んでいる。
 -
師匠……まさかそれは、和風ソースということですか？
-
知らん。
実は、私はこのような和風のコミュニケーション方法も重要かもしれないと考えている。
|
|
それってどういう意味なんでしょうか？ |
| |
|
|
例えば上で、英語がべースのソース・コードに日本語が混ざることに違和感がある、といった。しかし、別の見方をすれば、これは、クラス名だのメソッド名だのが素早く判別できるということでもある。もちろん、英語を母国語とする人たちが、英語だらけのソース・コードでそれをするよりも素早くだ。英語の中にかなや漢字で書かれた日本語の識別子があれば、とても目立つからな。先ほどの2つ目のソース・コードを見れば分かると思う。
それから、日本人同士のコミュニケーションでは、日本語により細やかなニュアンスが伝えられることがある。
例えば、「俳句」などは、とてもブロードバンドだ。
「石山の石より白し秋の風」
わずかこれだけの文字数で、短時間にとても多くの情報を伝えることができる。
通常「暗黙知」を伝えることは難しい。だが、うまくメタファーを使うことで、多くの暗黙知を形式知化して伝えることも可能だ。ちなみに、今回の私の話にもとてもたくさんの例え話が出てくる。新しい概念を伝えるときにとても有効な手段だからだ。
ほかにも単なるドキュメントでは伝わらないものを伝えようとする試みはある。例えば、「ニコニコカレンダー」を見てほしい。なんと、「チームのムード」を伝えるのに成功しているのだ。
それから例えば、私がよく使う、
「毛筆で書いて壁に貼る」
というプラクティス（実践）もその代表的な例だ。
|
| |
|
|
例の、毛筆で書いて壁ですね……。 |
| |
|
|
考えてみてほしい。メールで、
つぶさにいうのと、的確にいうのは違う
と書いて送るのと、
と毛筆で書いて壁に貼るのとでは、伝わり方は同じだろうか？ 言葉としては同じものでも、伝わる情報量は違うのではないか。
テキスト・データとして見ると、この文自体のデータ量は30バイト余りしかないかもしれない。だが、表現方法に関わらず、いつもコミュニケーションの量は30バイト程度だろうか？ そうではないだろう。どう伝えるかによって、伝わる情報量は違うのではないだろうか。
【まとめ】
|
|
|
| |
|
|
さて最後に、「創造的なコミュニケーション」というテーマでまとめを行ってみたい。
|
