概要
ソフトウェア工学では、ソフトウェアは商品として扱われるため、ソフトウェアの制作は正しいプロセスを経て行うことが重要視されている。それは勿論特定のソフトウェアを闇雲に作ろうつするのではなく、計画に沿って制作を進めることを意味しているが、その前に実現可能性（Feasibility、現実的かどうか）、つまりそもそも開発を始めるべきかどうかを解析する必要がある。また、開発すべきと判断した場合は、プロジェクトや計画の詳細（たとえば、開発に用いるプログラミング言語など）も実現可能性の面で評価したうえで最適なものを選ぶことが重要である。
本稿の目的は、（関数電卓へ拡張可能な）「電卓プログラム」を例にFeasibility Studyを行い、その開発に最適であるプログラミング言語をソフトウェア工学的な考え方で求めることである。なお、今回の解析では、プログラミング言語の候補としてJava9、Scala、Haskell、Rustの四つを考える。
各プログラミング言語の特徴および評価
Java9
Java9はJava言語の最新版である。Javaは二十年を超える歴史を持つ、マルチパラダイムな言語言語である（主としてオブジェクト指向・手続き型）。GUIなどを持ち、拡張可能である電卓プログラムではオブジェクト指向と手続き型という特徴が作りやすさにつながると考えられる。このようなアプリにとっては、Java9が適切であろう。前のJavaのバージョンよりは様々な面で性能が上がるため、良い成果物が期待できると考えられるため、この言語で開発を行うと良いのではないか。
Scala
Scalaは、マルチパラダイム言語（オブジェクト指向、関数型プログラミング可能性、など）である。Javaと同様に、プログラムはJavaバイトコードにコンパイルされ、JVMで実行されるため、結果となるプログラムは様々なプラットフォームで実行できると考えられる。なお、Javaと違って関数型プログラミングもサポートされているが、電卓プログラムではその出番は見えず、純粋な手続き型プログラミングで実現しやすい部分が多い。
Scalaは2004年に初めて現れた、比較的に新しい言語である。そのため、ソフトウェア工学的な考え方では、Scalaの適性は疑わしい。しかし、Java全体より新しいとはいえ、Java9よりはふるいため、安定性などを考えるとScalaも立派な選択肢であるといえよう。
Haskell
Haskellは、Javaをも上回る歴史を持つ、1990年に初めて現れた、純粋な関数型プログラミング言語である。この中の最古の言語であるため、ソフトウェア工学的に適切であると思うかもしれないが、無論ながら単に言語が古ければよいという問題ではないことも明らかであろう。最大の問題点は、純粋な関数型プログラミング言語であるゆえ、珍しい考え方を開発者に押し付けることになるため、意味も無く負担がかかることになる。手続き型言語で簡単に表現できるものが関数型言語や論理型言語で煩雑になる場合も多く、その上に上記の通り関数型プログラミングの要素を活用できる場面は極めて少ない。ソフトウェア開発者を名乗るものなら知るべき言語であるかもしれないが、今回のプロジェクトの候補からははずすべきと考える根拠もある。
Rust
Rustは、マルチパラダイム言語（関数型・手続き型など）である。純粋なオブジェクト指向はサポートしていない（ほかの手段によってオブジェクト指向と似たような機能や抽象化が実現可能）。（Java9を除いて）最も新しい言語であるため、ソフトウェア工学の考え方では論外といっても過言ではない。
考察と結論
上記によると、このプロジェクトに最適なのは、Java9かScalaのどちらかとなる。Scalaはやや珍しい言語であり、Javaに無い機能は求められていないため、Javaの考え方・書き方を何年間も熟知している人たちが昔のように書けるJava9のほうが良いかもしれない。しかし、Javaのバージョン9は実質的に存在しないといって良いほど新しいため、安定性なども心配になり、本当に同じ作風でよいかどうか疑問に思うことがあるため、この二つの中から選ぶならScalaを選ぶべきである、という考え方も妥当であろう。これ以上議論すると机上の空論になりかねないため、プロジェクトの詳細や開発チームの詳細などを考慮しないと結論を導くための情報が足りないと考えるのが正解であろう。
あとがき
実現可能性を永遠に議論するより、さっさと何かを作ってしまえば時間も削減できる、という考え方もある。実際、そういう決断をしなければいけない場合も多い。状況を冷静に判断しようとする賢者よりも難しいことを考えない愚者どもが先に進み、成功することは市場でもよくある話である。
ちなみに、私は数時間もかけずに関数電卓プログラムを一人でC言語で作ったことがある。また、同じ時間で同様なプログラムをx86アセンブリ言語で作成できると断言できる。なお、Haskellが好きな人はHaskellで開発してしまっても大きな問題は起きないであろう。
ソフトウェア工学的に何が正しいのか、なんて考える余裕も必要も無かった。どうやら、すべてのプログラミングが必ずしもソフトウェア工学ではなく、どのようなプログラム開発に対してもソフトウェア工学のルールや原理を適用できるというわけでもない。個人で作るかチームで作るか、商品にするかしないかなどでTPOや状況が変わり、それにあったソフトウェアの作り方を考える必要があるといえる。個人では様々な自由があるが、大きい会社には大勢の人で莫大な金額や責任を掛けてソフトウェア工学を行うため、慣性が強く、個人のように自由に動けず、「さっさと何かを作っちゃえばいい」という考え方で開発を行うわけにはいかなくなる。ただし、そういう状況下での実現可能性やプログラミング言語を議論するには、「電卓プログラム」というプロジェクトは単純すぎるといえよう。「この言語で無ければ・この言語であれば非現実的だ」といえる場面がまったく創造できないからである。もっと大きなプロジェクトや厳しい条件があるときは、この言語での開発の難易度の差が出るかもしれない。
なお、このプロジェクトの開発しやすい言語についてしいて言うならば、一番単純なC言語などで開発したほうがソフトウェア工学の考え方でも適切なのではないだろうか。