なぜ、その設計になっているか説明できなければエンジニアとは名乗れない
OSやミドルウェアなどの設計をするならば、「なぜ、その設計になっているか説明できなければならない。」のですよ。実装する設定は顧客の要件を起因に、システム仕様、実現仕様と細分化、具体化し、ソフトウェアのパラメータ値に変換していきます。
なぜ、そのパラメータ値でよいのか
ソフトウェアのパラメータ値は、顧客の要件からデフォルト値のままの場合もあるし、デフォルト値を変更して設定することもあるし、要件を実現するパラメータではないからデフォルト値のままのこともあります。何れにしても、要件の有無から値の変更に関わらず、何某かのパラメータ値を設定をするのです。整理すれば、下表のようになりますね。
項番 | 顧客要件の影響 | パラメータ | パラメータ値の変更理由 |
1 | 対象 | 変更しない | デフォルト値で顧客要件を実装できるため |
2 | 対象 | 変更する | 変更する値により顧客要件を実装できるため |
3 | 対象外 | 変更しない | 顧客要件の対象パラメータでないため |
上表で良しとするなら、顧客の要件に影響されるパラメータを知らなければどのパラメータを変更又はデフォルト値のままとするかを決めることが出来ません。だから、設計を出来るということは、パラメータを知っていなければできないのです。
仕様だけでは設計できない
パラメータの仕様はパッケージの管理者ガイドや構築マニュアルにその説明があったりするのでそれをみればだいたい出来そうです。ん?何で出来そう?なんだって?だって、100%仕様どおりに動くパッケージなんて存在しないでしょう。顧客の要件を実現するために複数のパラメータを設定する必要があるケースもあります。複数のパラメータ値の設定が必要な場合、複数設定するパラメータに優劣があったらどのような動作をするのでしょう。それを仕様だけで読みとるのはかなり至難の業ですね。
いやいや、「製品ベンダに問い合わせればいいから。」と答える人もいるでしょう。でも、その問い合わせで動くと裏付けされるのは、製品ベンダの環境下だけの話であって、顧客のシステム環境下で必ず動くとはだれも保証してくれないこともエンジニアであれば経験値的に知っているはずです。
結局、仕様を押さえていたとしてもそのとおりに動くかどうかは、物理的には相違があっても論理的には顧客環境と同じシステム環境下で動かした上でパラメータ値を確定しなければならないのです。
と、書けば「それをどこでやるんだ、そんな時間はないし、コストもない。」と言いたくなるかもしれません。でも、それをやらないと試験工程で初めて想定外の動きをすることを知ることになるかもしれません。そうしたことをそのときになって受けれいるかどうか、という判断をしなければなりません。その上で、疑似的な論理環境を使ってまでパラメータの振る舞いをどこまで押さえるかは、そのパラメータで押さえようとしている顧客要件の優先度で判断するほかありません。
でも、結論からえ言えばやるんですよ。疑似的な検証環境で顧客の重要な要件を実現できるか否かを。だから、パラメータを知らなければならないんです。そう、立花先輩も言っていたじゃないですか。
「私言ったわよね、一からコンフィグを作れって。」 室見立花 なれる!SE