はじめに

日本語プログラミング言語をモデリング言語としてシステム開発上中流工程に導入した場合、そのメリット・デメリットについて考察する記事の8回目です。

本記事の内容はいくつかに分割されて記載されます。本記事中の「本記事」とは分割された内容の総体を指す場合があります。

この記事は日本語構造化仕様記述言語 Re:Mind（リマインド）アドベントカレンダー2023の18日向けの記事です。

対象読者

とりあえずこの記事の想定読者はシステムエンジニアさんです。とくに日本語で要求仕様や内部設計資料を書いている方向けのお話です。

また、参考にプログラマさん。ぐだぐだの内部設計書から実装してひどいめにあったことのあるひと（力量のあるデベロッパはそれを乗り越えて設計者になる？）

システム開発工程をトータルに見ている責任者さん、システム開発工程の改善ソリューションを検討している企画責任者さんとか。

オーソドックスなリレーショナルデータベースを使用している業務システムであることを1回目 2回目の記事で説明しております。

一般的なWebアプリケーションシステムであり、簡単な受発注業務をインターネットで支援するシステムであることを3回目 4回目の記事で説明しております。

5回目の記事ではドメイン駆動設計（DDD）の文脈で用いられる意味でのユビキタス言語を例示しました。

6回目 7回目の記事ではドメインエキスパートからプログラマレベルまで共有可能な言語のことをユビキタス言語化された日本語プログラミング言語とし、その各工程のソースコードの差異を例示・解説しました。

これまでの記事でようやくひととおりの検討材料を例示できましたので、まだまだざっくりしたシンプルな例すぎて説得力にはかけると思いますが、さらに詳細に立ち入る前に、本記事のテーマのメリット・デメリットについて考えてみます。

自然言語の母語が構造化された制約があるだけで、言語としての可読性が高い
この点でシステムエンジニアリングに疎いドメインエキスパートでも十分に意図を共有可能（特に上流のモデリング記述）

ロジックの意図の表現・精度が自然言語記述より格段に増す
数学的形式言語ほどではないにしろ、最上流から静的に型付けされた構造化言語による記述とすることでシステムに出現するデータの型の引き、戻りの一貫性は検証可能

各工程層の設計者の意図を確実に次の工程に引き渡せる
前の工程の成果物・ソースコードを継承する
次工程担当者は前工程のソースコードを直接編集して書き足すイメージ

各工程層の中間成果物に「完成」の客観的な目安を導入できる
つまり各工程層のユビキタス言語のコンパイラが通過するか

数学的形式言語よりは各段にハードルは低いものの自然言語記述より制約があるため最上流では能力的に対応できない実務担当者も出現
ただし自然言語との併記は可とすることで逃げれる。（次も似た感じ）

各工程層の中間成果物にコンパイラ検証による「完成」の客観的な状態が導入されるため自然言語記述のあいまいな逃げができないことによる工程遅延
これの回避策としては、コンパイラ検証はオミットして、構造化疑似言語として運用する（多少のあいまいな表現が許容、未定義のデータ名、処理名などが混在）

後工程の変更の前工程へのフィードバック工数
後工程の変更内容をどこまで前工程のソースに反映するか。手作業ではやってられない。ただし、帰納的なトランスコンパイルは抽象的な状態を詳細化するよりは一意性がありコンピュータが得意なので、逆トランスコンパイラなどで自動化はできるかもしれない。

本記事の中間的な締めとして、ざっくりメリット・デメリットについて検討してみました。。

各工程の詳細について引き続き検討していきます。数学的形式言語との関係について少し触れます。