はじめに
みなさんは「わたしの書いた日本語の設計書をコンパイルしたい？？」と聞かれてどんなことを連想されますか？
「わたしの書いた日本語の設計書」とはソフトウェアの設計書のことです。わたしは最近、切に、このドキュメントがコンパイルできて、実行可能コードに変換できなくとも定義漏れがないかとか、ロジック的な妥当性に矛盾がないかとかチェックできる環境があればいいなと思っています。
対象読者
とりあえずこの記事の想定読者はシステムエンジニアさんです。あなたが自分自身でプログラミングするのではなく、別の人にプログラミングしてほしい場合を想定しています。
わたしは日本語で設計書書いてます
みなさんは設計書何語で書いてますか？わたしは日本語です。外国の協力会社さんに実装を依頼する場合も日本語で書いています。
わたしの考案する日本語プログラミング仕様記述言語の弱点
わたしは現在、下記のような３階層の日本語プログラミング仕様記述言語ファミリーを考案しております。
| カテゴリ | 用途 | 現状 | 備考 |
|---|---|---|---|
| 日本語構造化仕様記述言語 | 要求仕様記述 | 企画中 | |
| 日本語ロジック仕様記述言語 | 内部設計記述 | 設計中 | オープン |
| 日本語トランスコンパイラ言語 | 実装・開発 | 試作中 | オープン |
日本語トランスコンパイラ言語は静的型付けシステムの実装言語にトランスコンパイルするため、また日本語で定義した変数名や関数名を設計者が意図した半角英字文字列（通常英語または日本語ローマ字表現）に変換できるよう、指定内容がけっこう細かいです。
日本語ロジック仕様記述言語が想定しているのは、疑似コーディング言語のためかなり記法はトランスコンパイラ言語に近いです。つまり基本的にはテキストだけで記述します。（表はないという意味）
実際の設計現場ではMarkdownで記述する場合、表が多く使われる
実際の設計現場ではMarkdown（以下mdと表記）で記述する場合、表が多く使われているような気がします。現に実際、わたしが書いている仕様書にはmd表が多く記述されています。（表がでかく、パターンも多くなってくるとスプレッドシートアプリに外だしします。）
つまり、実務的には仕様書設計書をプログラミング言語のソースコードのようには書かず、関数の定義情報やSQLデータベース照会言語の定義情報を、表形式で書いている場合が多くあります。
表がでかくなってくるとスプレッドシートアプリに外だしした場合はさすがにテキストソースファイルの範疇を超えるので、あくまでmd内で表として記述されている分には、パイプ文字などを認識して賞味の文字列を切り出せるので、関数の定義部、呼び出し部の記述を表形式にしてもコンパイルできる形式言語というものは存在しうるかもしれません。
日本語構造化仕様記述言語レイヤー
日本語構造化仕様記述言語レイヤーの内容はまだあまり具体的に定まっておらず、これまで数学的形式言語VDMの記述内容にある程度対応するような内容を考えておりましたが、実務的には表形式表現の定義情報を含むテキストソースコードを日本語ロジック仕様記述言語レベルのソースにコンパイルするといった構想にした方が有益かなと考え始めております。
各レイヤーの役割分担イメージ
日本語構造化仕様記述言語レイヤー
Markdown表形式の記述を含むMarkdownソースコード
（Markdownの表、インデント、強調装飾などを含むより形式的なソースコード）
↓（コンパイル）
日本語ロジック仕様記述言語レイヤー
独自の日本語プログラミング言語仕様によるソースコード
（変数定義・関数定義・仮定義多用 基本的にプログラミング言語のソースコード（表形式の記述はない）ただし、実装言語へのトランスコンパイルのための変数名・関数名の情報はなし
↓（コンパイル）次工程のトランスコンパイルに必要な情報はスケルトンとして出力
日本語トランスコンパイラ言語レイヤー
独自の日本語プログラミング言語仕様によるソースコード
（変数定義・関数定義・実装言語のインライン定義多用 基本的にプログラミング言語のソースコード）実装言語へのトランスコンパイルのための変数名・関数名の情報は要追記。
↓（コンパイル）
ターゲット実装言語ソースコード
ターゲットプログラミング言語仕様によるソースコード
↓（コンパイル）
ターゲット実装言語実行コード
ターゲットプログラミング言語仕様による実行コード・中間コード
おわりに
日本語構造化仕様記述言語レイヤーはあとでもう少し具体化します。本記事はあくまでアイデアレベルです。
日本語ロジック仕様記述言語レイヤーと日本語トランスコンパイラ言語レイヤーは、こちらの記事をご参照ください。