このブログを読んでいるあなたは、おそらくITへの転職や異動希望などのジョブチェンジを考えていらっしゃることと思います。しかし具体的にシステムエンジニアがどのような仕事をしているか分からないため、仕事内容を調べていたのではないでしょうか。そんなあなたに、「開発途中の仕様変更のリスク」を例に取り、システムエンジニアの仕事について説明したいと思います。
また、システム開発を依頼するお客さまの中には、「せっかく作るんだから、やっぱりあの機能を入れること はできないだろうか」というような考えが頭をよぎる方がいるかもしれません。そして、いざシステムエンジニアに話してみると煮えきらない態度で不満だったというようなことがあったかもしれません・・・この記事は、そんな経験をされたお客さまにも、お役に立てる情報となっているのではないでしょうか。
実を言うと開発途中での仕様変更は、どのような手法でシステム開発を行っているのかによりますが、非常に大きな”リスク”を抱えることになります。確かにお客さまのご要望に応えることがシステムエンジニアの仕事ですが、本当にそのリスクに見合った効果が得られるのか、考えていかなければなりません。以下で詳しく解説します。
開発途中の仕様変更は、”品質の低下”につながる
システムを作る上で大切なことを尋ねられたら、どのように回答するでしょうか。「エラーが発生しないこと」だったり、「画面が見やすく、操作しやすいこと」などが挙げられると思います。つまり、”品質”が大切ということになります。
システム開発を行うとき、システムの規模が大きければ大きいほど”ウォーターフォール”という手法に従います。この開発手法の最大のメリットは、前工程を徹底的にレビューして仕上げて次工程に進み、対応する試験工程を経てから受渡しを行うため、ある程度の品質が保証されることです。逆にデメリットは、前工程を徹底的に仕上げることからどうしても時間がかかってしまうことです。
上の図の向かって左上、実現性検討の工程がおおまかにシステムとして実現できるかどうか判断するという開発工程のスタートラインになります。そこから、要件定義の工程でシステムにどのような機能を盛り込むのかお客さまの要望を伺い、その要望をもとに各設計書の作成段階を経て、プログラミングを行うことになります。その後、各設計書やお客さまの要望が実装されているかどうか、各試験を経て確かめられます。
システム開発は人間が作るものですから、どうしてもエラーは発生してしまいます。逆にエラーが無いシステムというのは不可能なので、各試験工程でエラーの摘出ができなかったとなると、違った意味での不安を抱えたシステムということになります。だからといって試験工程でエラーが出たからそれを適宜修正していけばいい、というわけではありません。やはりエラーの発生は少なくしなければならないのです。そうなるとどこでエラーを少なくする工夫をするのか、それは各設計書作成段階での作込みです。
そのため、ある程度開発工程が進んだ段階で、仕様を変えようとすると今まで作り込んだ設計書が水泡に帰すので、品質を大きく下げてしまうというリスクにつながるわけです。また、どうしてもお客さまと企業という関係がありますから、プログラミング段階で修正を加えるよう依頼されてしまうということもあるかもしれません。こうなってしまうともう最悪です。今まで作り込んだ設計書がなかったことになりますので、出来上がるシステムは要件定義の内容とは全く異なるものになってしまい、誰も使わないようなシステムの出来上がり、などということになりかねません。
以上より、お客さまの方としては品質を下げるリスクを犯してまで仕様を変更したいのかということをご考慮をいただく、システムエンジニアとしては品質が下がってしまうというリスクがあることをお伝えして、次の開発で仕様を変更するようお客さまにご納得いただくということになります。
今回の内容はシステムエンジニアの開発工程に一歩踏み込んだ内容なので、なかなか理解しにくい内容だったと思います。適宜リライトし、理解しやすい文章を目指していきます。
コメント