GeekFactory

int128.hatenablog.com

日本語とギーク語を使い分ける境目は元請けにある

プログラミングができないのなら、プログラミング言語自然言語に翻訳したプログラム設計書を理解できるはずがない。できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。そんなレビューは意味がない。だって、全然プログラムの品質向上に役に立ってないじゃん。設計書の日本語は多少向上するかもしれないけど。

http://d.hatena.ne.jp/higayasuo/20080415/1208224902

重要なのはドキュメントをいじくり回すことではなくて実装工程にシームレスにつなげていくことなのだが、工程が分断されている日本のシステム開発スキームにおいては「この書類は自分たちが言いたい事を一語一句間違えなく伝えているのである」というのが大切らしい。

http://d.hatena.ne.jp/gothedistance/20080410/1207832176

ドキュメントを作るのは、顧客のために元請けが説明するためであり、元請けのために協力会社が説明するためです。顧客がUMLを理解できないので日本語で書き、元請けがプログラミング言語を理解できないので日本語で書く。結果として、ドキュメントのレビューは日本語のレビューに陥る場合が多くなります。本来の目的である「実装工程に至るまでの詳細化」とはかけ離れた議論になりがちです。

何も全部UMLにしろとかコード読めとは言っていません。顧客の経営層はギーク語を理解できなくて当然です。日本語とギーク語を使い分ける境界は元請けにあり、元請けは日本語もギーク語も理解すべきです。当然ながら協力会社はギーク語を使いこなせるべきですが。今はその境界が狂ってるから、自然言語のプログラム設計書を作っています。顧客とプログラマの間にいる人たちがギーク語を理解しないから困っています。

まあ現実にそんなスーパーマンはいないので、作業指示する人ぐらいはギーク語を理解してほしいです。要件を調整する能力はまた別ですので。