設計言語

設計書がシステム完成後に出来上がる、奇妙に聞こえる話ですが、建築のように釘一本でさえ、事前に決定できる世界と異なり、ソフトウェアの場合は、トップダウン(基本設計ー横展開)とボトムアップ(部品作成ー縦展開)が交互に行き来することで、全体が完成することが多く、設計書が後付で出来上がるという事態が頻発するのも自然です。ただし、これでは、工期も予算も計算できないので、通常は、試作(プロトタイプ)とプロダクト作成の2段階工程を組みます。試作の重要性は、ソフトウェア固有の性格も反映しています。ソフトウェア自身は名前の通り柔軟なプロダクトであり、それ故、部品の組み換えや機能の追加・削除が、限定的かつ部分的ではあっても、可能であり、そのため、クライアント側からの要求が、当初の要求仕様を超えることはよく起きます。その意味で、発注者側、受注者側、納期、コスト、それぞれの折り合いをつける着地点として、試作品が使われます。

プロトタイピング言語

現代は、優れたプロトタイピング言語が多く、どれを使っても大きな差はありません。特に、ラピッドプロトタイピングと呼ばれる、高速開発/高速デバッグ能力は絶対欠かせません。その一方、特定のプラットフォームの使用は諸刃の剣となります。プラットフォーム故の便利さを享受できる一方、プロダクトに引き継がれることで生じるプラットフォームのレガシー化問題がソフトウェアの進化速度を遅らせることも起きます。趣旨は異なりますが、マイクロソフト社が提唱するマイクロサービスが一つの答えになるとみています。プラットフォームという大きなブラックボックスではなく、より単機能のビルディングブロックを使い、代替可能な部品の集まりとして、レガシー化問題を回避します。なお、個人的には、マイクロサービスを、メッセージ型APIを解するクロージャ(内部状態付き関数)で実装するのがベターだと考えています。

部品化

あるいは、構成と機能問題です。構成が部品群の形を決め、機能が各部品の中身と部品同士のインタフェースを決めますが、予め、構成を部品群にどのように分割すればよいか、また、各部品にどのような機能を割り当てればよいかは、試行錯誤的な部分があります。特に問題となるのが、各部品(ライブラリ、関数あるいは手続き)同士を繋ぐ入出力パラメータの問題は難しく、部品としての独立性を優先すべきか、部品同士の接続性を優先すべきか、一般的な解は存在しません。

また、オブジェクト指向言語を採用した場合、状態およびメソッドに関し、何をクラス共有とし、何をサブクラス固有とするか、その判断は特定のプログラム構成においては一意に決まっても、複数のプログラム間で部品化までを考慮すると、その分割標準は急激に難しくなってきます。

プログラム合成

いわゆるオブジェクト指向言語パラダイムには部品化という発想がある一方、部品を集めて一つにする、つまり合成するcompose という発想が明示的に仕組みとして用意されていません。これに対し関数型言語の場合は、型および引数の形を含め、明示的に対処せざるを得ず、その分、関数型の扱いは面倒となる一方、プログラムとしはロバスト robust なものを作れます。

プロダクト開発言語

理想は、プロトタイピング言語がそのままプロダクト開発言語となることです。昔と異なり、今は、プロトタイピング言語(ほとんどインタプリター言語)でもJIT Just In Time によってリアルタイムでコンパイルする機能によって、開発性と高速性を併せ持つことができ、プロトタイプ言語をそのままプロダクト開発言語として引き継ぐことが可能となっています。

設計言語としての形式仕様

プロダクトが完成し、仕様がすべて明確になった後には、プロダクトの保守性を高めるものとして形式仕様による再設計は重要です。形式仕様を書くことによって、仕様が見直され、整理され、再利用性もそこから見えてきます。ただし、形式仕様化のタイミングは難しく、あまり早すぎても無駄に終わることも多い。一般的には、出来上がったプロダクトの品質と製品計画のバランスが仕様の形式化を行うか、止めるかを決定します。

形式仕様の重要性はソフトウェアエンジニアの間で常識として広く行き渡っていますが、いざ使うとなると、さっと腰が上がる程の気楽さは残念ながらありません。そこで登場するのが、型推論Type Inference です。静的な型推論だけでなく、動的な型推論、あるいは通信プロトコルを型として、その設計に型推論を持ち込むことができます。ただし型推論も、形式仕様同様、プログラムロジックを組み立てられないエンジニア向けではありません。どちらかというとプログラムロジックのケアレスミスを発見するために有効です。

設計言語としてのビジュアル言語

ここでは一時流行った、あるいは今でも特定の分野では有効なGUI操作だけでプログラミングが完成するアプローチについては、触れません。代わりに、ペーパープロトタイピングを紹介します。文字通り、紙の上にアイデアを描いていきます。様々なビジュアル言語が設計開発されてきましたが、紙と鉛筆によるビジュアル言語にまさるものはありません。思考に制約がなく、表現に制約がないというのが最大の売りです。ただし、大事なことが1つあります。ペーパープロトタイピングしたら、なるべく、早く本物のプロトタイピング(動くもの)を作ることです。プロトタイピングが得意なスタッフがいる事務所ならば、ペーパープロトタイピングが有効です。

設計言語としての自然言語

究極の設計言語は自然言語です。自然言語は曖昧だと言われます。しかし、逆にその曖昧さが仕様を決定する上で役に立つこともあります。米国での例ですが、戦闘機シミュレータを設計する際、身体的であるパイロット自身による機の操作を、数値的である機体の動きへ、どう写像すればよいか、自然言語とFuzzy論理が使われました。機の操作は自然言語で表現され、それがFuzzy論理に写像され、そこから直接、機体の動き(数値)に変換され、数十ミリ秒の操作応答速度を実現しました。世の中の要求仕様requirementは曖昧さに満ちています。一方、コンピュータは数値計算が得意であり、曖昧さの処理は不得意です。しかし、自然言語と数値計算を結ぶパスPathが見つかれば、自然言語は究極の設計言語となります。




Symbolic Systems, Inc. 2020.06