∑考=人 〜プロメテウス〜

そして今日も考える。

SIerが考えるべきはプログラミング自動化ではなく設計簡略化

ハードウェアとソフトウェアの共通点と相違点

モノ(ハードウェア)を作ることとシステム(ソフトウェア)を作ることは結構似ている印象を受けると思う。私も正直同じような印象を持っていた。システム開発では、要件定義、設計、製造、試験という工程に沿って進んでいくし、おそらくモノの生産でも同じような流れになっているはずだ。

 

しかしながら、過去の製造業が手作業から機械作業化、そして生産自動化、という歴史を辿っていった一方で、製造に該当するプログラミングは未だに手作業である。

 

とは言え、プログラミングも製造業同様の進化自体はたどっているのではないかと思う。例えば、自動車開発で、自動車の金型、あるいはタイヤなどの既に完成されたパーツを利用するように、システム開発でもそれらに相当するフレームワークやライブラリを利用することも一般的になってきた。(ちなみに私の担当システムは全てフルスクラッチ。)システム開発を進めるためのツール類も整備されてきている(機械化)。

 

プログラミング自動化の取り組みの効果は?

なので、システム開発の将来的な進化として考えられる、考えていかなければならないのはプログラミングの自動化、ということになる。既にソフトウェア開発の自動化に取り組んでいる企業や研究機関は存在する。

 

ただ、まぁなんというかプログラミングを自動化するにはまだまだ高いハードルがあると私は思っている。いや、たぶんITに関わっている人なら皆思ってるんじゃないだろうか。

 

例えば、今プログラミング自動化の例として、設計書を書くとコードが自動で生成されるツールなどが存在する。クラス図やシーケンス図を書いたり、E-R図を書くと、自動でプログラムが書かれるという仕組みになっているはずである。

 

確かに、通常であれば、設計書を作成した後に、設計書をもとにプログラミングを行うので、プログラミングが自動化されたと言えるかもしれない。もちろんこれも確実に労力削減には寄与している。しかし、これはプログラミングを自動化したと言えるのだろうか。

 

プログラミングは単純に進化しているだけ

プログラミングとは、期待する動作を実現するために、何らかの規定に沿った入力情報をコンピュータに与えることである。では、自動でコードを生成するために設計書を特定のフォーマットに沿って詳細に記載して、動作を実現させることもまた、プログラミングと呼べないだろうか。

 

結局ここで言われているプログラミングの自動化とは、プログラム言語の進化でしかないのである。あくまで機械化の域を超えていない。それは元々機械語でコンピュータへの命令を記述していたのをC言語Javaで記述できるようになった、ぐらいの進化と何ら変わらない。

 

目指すべきはプログラミングの完全自動化(設計簡略化)

本質的に、製造業の場合は、設計と製造の意味も、それらに必要な労力や能力も全く異なっていた。そのため、製造の自動化は後に革命と呼ばれるほどの大きなインパクトがあったのである。しかし、誤解を恐れずに言うと、ソフトウェアの設計と製造は全く同じことをしている。少し、やり方が違うだけなのだ。

 

とは言え、SIerでは、設計をする人と製造をする人が違うのはもはや当たり前になっているのも事実だ。私の経験では、設計をする人はシステム全体を考慮した概要レベルの設計を行い、コーディングをする人は詳細な部分の設計を行う、といった暗黙の役割の差異が存在する。

 

ただ、昨今の考え方で、単純に製造工程を自動化する取り組みをしても、結局プログラミング言語がその他の命令方法(クラス図、シーケンス図)に変わるだけである。その結果製造工程を排除できるといっても、詳細レベルの設計を設計工程で全て実施しなければならないだけので、開発全体ではそこまでの時間短縮の効果は得られない。もともとプログラマーがやっていたことをSEが実施するようになるだけだ。

 

プログラミング自動化によるシステム開発の期間短縮を図るのであれば、必要なのは、自動でコードを生成することではなく、プログラミングの完全自動化(というより設計簡略化)という考え方が必要になってくる。

 

プログラミングが自動化できない理由

ハードの製造自動化は実現できるのに、ソフトの製造自動化が実現できない理由は大きく二つである。

 

1.「自動化」の意味合いの違い

先にも触れたが、前提として、ハードの製造自動化が提供した価値とソフトの製造自動化が提供するであろう価値は全く別種のものであることだ。

 

ハードの製造が自動化されたことによってどんな便益がもたらされたかを考えると、それは短時間で同じ個体を何度も大量に生産できるようになったことである。それまでは設計図をもとに職人が一つ一つ製造しなければならなかったのだ。

 

その点ソフトウェアはどうだろう。そもそもスタートラインから同じ個体(プログラム)は無尽蔵に生産することが可能である。一つ作れば、それをコピペで大量に生産・配布することができるのだ。ハードの製造では同じ部品を幾つも生産する必要があるが、ソフトは基本的に同じ部品は作らない(無論、良いシステムに限り、であるが)。だからハードの自動化とソフトの自動化ではまるで闘いの土俵が違うのだ。

 

2.規模の違い

次に圧倒的な規模の差である。ハードウェアとソフトウェアの比較を考えた時に、ついつい、PC端末本体とPCのOSとかを比較してしまいそうであるが、スケールが違いすぎる。

 

ソフトウェアは目に見えないため、現実世界での規模はわからないが、仮にそれを構築する金額予想ベースで考えれば、ソフトウェアであるWindows 10 OSに相当するハードウェアの規模は新国立競技場ぐらいのインパクトがあると思う。一般的な規模のシステムでも家相当の規模はあるんじゃなかろうか。もはやハードウェアの比ではない。

 

で、家の生産が自動化されているかというと、やはりされていない。普通に無理。でも物理的な制約がなければ、可能ではあると思う。超巨大な工場を用意して、超巨大なクレーンで運んで建てる、みたいな。だとしても、システム開発の完全自動化はできない。

 

設計簡略化の課題

ちなみに製造業は既に設計簡略化も実現している。3Dスキャナ(3Dプリンタ)なんかが該当するだろう。既に完成されたモノから内部的に設計図を書き上げて製造することができる。設計のインプットとして必要な情報が少ないし、インプット用に人間が加工する必要もない。でもこれもやっぱり複製の域を超えないので、ソフトには応用が難しい。

 

ソフトウェア開発の設計を簡略化するためには、曖昧な指示をいかに具体化するか、という課題を解決しなければならない。極端な話、下記のシチュエーションが実現できれば良いのである。

 

私:

「ログイン画面を作って」

コンピュータ:

「ユーザ、パスワードの入力欄、実行ボタンを実装して、DBデータに存在しないデータから入力された場合にはエラーメッセージを出力するようにしました」

 

これは結局のところ、言われたことしかできない従来コンピュータの限界を超える技術である。あるいはAIならそれを可能にしてくれるのだろうか。