システム方式設計で実装の実現性を見極められないエンジニアには設計させられないよね

システム方式設計なので、まぁ、基本設計だと思ってもらえればどの工程かはイメージが合わせられるでしょうか。この工程までは、所謂、上流工程ですからここでシステムデザインを間違えると後続の工程への波及効果はとてもインパクトがあるのです。

ですから、システム方式を設計する際には、要件に沿った実現仕様、つまり、これから実現しようとしているシステムへの要件を満たすための実装を考慮した方式を選択しなければ、システム方式設計である基本設計工程から“やり直し”をせざる得なくなるのですね。

このことを意識してどれだけのエンジニアが設計しているかはちょっと疑問かも、です。製造構築工程や試験工程でのどんちゃん騒ぎを横で見ていると。1-2回でいいから、有識者を入れてウォークスルーのレビューかませておけばいいだけなのに。

システム方式設計での実現性の必要性
でも、「ホントに必要なの？」なんて疑り深い人がいるかどうかはわかりませんし、

「顧客は実装なんて気にしないから。」

なんて言う人もいたりして、「そんないい方しなくてもいいじゃん？」なんて思うけれど、マジで顧客は実装なんて気にしていないんでしょうかね。

ワタシ的には、「気にしていないよ。」と言い切るエンジニアがいるとするなら、それは「思考範囲が狭いなぁ。」とか「『顧客は実装なんてきにしていない』という言葉の本質が見えていない。」としか思えないです。

あの「顧客は実装なんて気にしないから。」という意味合いは、どんな言語でコードを書こうが、どんなアルゴリズムを採用しようが、どんなパッケージを選択しようが、結構だけけれど、

「(非機能要件に埋もれている保守性やランニングコストなどを考慮しつつ、)システム要件を満たすプログラムを届けてくれればいいから。」

という意味なんですね。だから、ね。好き勝手にしてしいわけではないし、関心がないわけではないんですよ。

システム方式での実現仕様を見極めるためにエンジニアがしなければならないこと
要件定義でシステムで実現することを整理して、そのスペックを決めて、機能仕様に展開するわけですが、その展開や機能仕様の詰めに当たっては、それを現実に実装するパッケージなり言語などの組み合わせで実現するのですから、そうした製造工程でそれが「できるの？」を見極めなけないといけない。

だって、できないことを仕様にするわけにもいかないでしょ？

じゃあ、エンジニアの良心としてどうするか。いや、「良心ないし。」なんていうのはワタシだけにしてほしいものです。はい。

そこはアレです。アレ。プロトタイプを作るしかないです。特に、実績がない方式を選んだときや複雑なしくみのときとか。いや、上流工程の仕様決めで複雑なデザインをしている時点で「フラグ立ってるよ！」かもしれないですけど。シンプルな論理構成であっても、実装するツールやポイントを押さえてそのシステム方式のフィージビリティは確かめておかなければならんです。

設計はしてみたけれど、その実装した機能がどうふるまうかは、

「実装してからね。」

では、遅いです。ふるまいをきちんと押さえて設計しておかないと。それを見極められないと、方式設計での機能の正常ケースと異常ケースが曖昧になって、後続工程の設計や試験工程での試験設計から揺り戻しを起こします。それ、ダメだからね。

そうすると、採用するパッケージやアルゴリズムなどを担当するエンジニアは設計するエンジニアが詳細設計や製造工程を担当しないとしても、それらのパッケージや言語の特性や顧客の要件を踏まえてフィージビリティを直接確かめるか、若しくは、フィージビリティ自体は指示を出して確認できるレベルの技術は持っていないといかんです。

それができないエンジニアにはシステム方式設計をさせてはいけないんですよ。顧客に動くシステムを届けられないから。