ソフトウェアなどの仕様の議論をする時に、問題の切り分けや明確化にズレがあると、話しが複雑になり、議論が集約しない。だから、可能な限り課題を細分化して、解釈の範囲を絞り込んでいく必要がある。ところが、日本語はあまりにもハイコンキストなものだから、どうしても齟齬が入り込みやすい。
もっとも、英語だって曖昧な表現をして、曖昧な合意をすれば、こう思ったのに、こう期待していたのにという齟齬はある。だから、標準化ではNormative Textを使って、可能な限り曖昧さの排除をするわけだ。
日本語の場合には、漢字一つでも意味が異なってくるから、これがもっと面倒なことになる。だから、日本の規範的な文章をとなると、法律的な書き方になって、可読性が一気に下がる。法律や契約書などでは、逆に意図的に曖昧さを残したり、入れたりすることも多い。
今日はチャットで、あるソフトの振る舞いについて打ち合わせしていたのだが、「Aの判定にBの要件を追加する」というのが、「Aの判定をしない」に化けたりして、本当にややこしい。
こういうときは、もう直接プログラミング言語的な記述で表現できるような、Normative Japanseが欲しくなる。英語のNormative Textでは、shall, may, shouldを徹底して気にするけど、日本語の会話や文章で、徹底的に気にしたら、曖昧さが減る用語ってなんだろう？
曖昧さついでにもう一つ。昨日、スタッフが書いたちょっとした電子回路をチラ見した。充電制御の回路なので、まったくシンプルで、２つのICが使われている。僕は、そのICのスペックもデータシートもみていないし、中身もしらない。
本当にちらっとパワポに貼られた回路図の一部をみただけだったけど、ある信号の処理について、直感的におかしくない?と思った。そこで、スタッフに、これで大丈夫なの？このICは、そういう仕様なのか確認しくてれと指示した。
果たして、データシートを確認したスタッフは、指摘のとおりなので、抵抗を追加するように変更したと報告があった。
こういうのって、まだ僕が現役で回路を書いていた十数年前でも、既にECAD をきちとん使って、DRCをかければ回避できる事だったし、スタッフが使っているCADでもその機能はあるはずだ。
ソフト開発でも、沢山でるエラーがうざいからと、コンパイラーのWarning Levelを落としてしまう人がいる。明示的な無視と気がつかなかったは大きな違いで、ぼくはそいう事をしないように、よく若いエンジニアに言っていた。これは、CADのDRCとかでも一緒だ。
人間が出来る事は、限界があるんだから、コンピュータの力をうまく使えば良いのにって、いつも思うんだよね。