F「みんなが嫌いな詳細設計をなくしたよー！」みんな「え、疑似コーディング？」

今朝の日経の記事「基幹システム プログラマー不要　富士通がソフト、開発費４割減 」を見て思わずどんな実現手法でプログラマーを不要とするのかと興味津々で図を見てみたら、

「システム開発者はひな型に沿って「『Ａ』を『Ｂ』に設定する」といった処理内容をまず選ぶ。次にあらかじめ規定しておいた「口座番号」や「取引金額」などの業務用語を順番にはめこむ。この繰り返しで設計書を完成させれば、プログラム言語に自動変換される。」

と解説がある。新聞には図も載っていて、

従来の手法　要件定義　→　基本設計　→　詳細設計　→　プログラム設計　→　プログラミング

新しい手法　要件定義　→　基本設計　→　詳細設計　→　コード生成

と、詳細設計で

「富士通は基幹システムのプログラムが演算やデータの移動、項目チェックなど特定の処理の組み合わせで構成できることに着目。処理の種類ごとに専用の設計書のひな型を用意した。」

用意されるひな型を使って詳細設計書を作成するらしい。

既視感のあるプロセス
10年以上前のとあるプロジェクトで、当時の現行システムの設計書を調査することがあって、その調査で出てきたものに「プログラム仕様書」なる「疑似コーディング」が書かれた設計書があったんです。

疑似コーディングとは、

「擬似コード （ぎじコード、英: pseudocode）とは、アルゴリズムなどを、架空の非常に高水準なプログラミング言語で記述したものである。Pascal、Fortran、C言語などの既存のプログラミング言語の構文と、自然言語に近い表現を組み合わせて記述することが多い。」　(wikipedia)

で、実質プログラミングをしているようなもので、それに携わったシステムエンジニアさん達からは非常に評判の悪かった印象があります。まぁ、その当時は次期システム開発では「止めましょう。」となりましたが。

多分、疑似コーディング自体は、当時のコンピュータ資源が高価で今の開発環境のように手元のPCでコーディングもコンパイルもテストもできなくて、全部ホストコンピュータでやっていて、待ち時間の多さとかの時間の効率が悪かったkら、その空き時間に疑似コードを書いてバグを減らそう、歳なのではないかなー、と想像します。

それを、詳細設計を書くときに「やってしまおう。」としたのではないかと。

詳細設計が実質のプログラム設計に置き換わるとすると起きそうなこと
要件定義、基本設計が夫々の工期の中で、計画した記載内容を充足したアウトプットで出来ているならこの手法でも行けるかもしれない、と思いました。

が、現実は厳しく、要件定義で次工程申し送り、基本設計で次工程の「詳細設計で検討することとする。」などとやっているプロジェクトでは、それまで詳細設計が前工程の付けを払うバッファになっていたのに、それが出来なくなるということを示唆していると邪推するのですがどうなんでしょう。

あと、詳細設計ではまだ曖昧さを残せた記述、特に異常処理などが実質、コーティングそのモノになるわけで、そうした気の利く処理を掛けるのかどうか。

開発費は4割減るのか
感覚的には、

「ちょっとちょっと！、詳細設計とプログラミングで4割削減ですってよ、奥さん！！」

です。感覚的に、詳細設計とプログラミングのプロジェクト全体の工程比率で「3割ぐらいなのでは。」と思います。で、他の工程にプラス、つまり、工数増加の影響が出るでしょう。それが詳細設計の工程の前ですね。

基本設計では、疑似コーディングができる程度までに情報を整理、設計するのが必須となるのではないか、と思われるので。基本設計で次工程まで考えておくの、って割とヘビーですもん。あぁ、ソリューション型のプロジェクトに慣れているとデータ設計などが上流に含めていることが多いのでそのあたりは抵抗感がないのかも。

さて、上手くいくか実績を知りたいなぁ、と。