« 身体を揺らす | メイン | 昼間寝てて・・ »

システムエンジニアの実情・理想と現実

〇 理想的な開発
ウォーターフォールモデルでは要件定義から始まり、外部設計/基本設計、内部設計/詳細設計、開発、各種テストと各フェーズに分かれて作業を行います。この時に、フェーズ毎に作業者以外の人によるレビューを実施することが理想となるのですが、実際には時間がないという理由でレビューが疎かに扱われるケースもあります。レビューを正しく行っていれば、例えば設計段階で誤りに気付き設計を見直すことができます。しかし、レビューを疎かにしたがために開発が始まって初めて問題に気づくといったことが発生します。そうなると、進めていた開発を止めて設計を見直さなければなりません。もちろん、それまでの開発作業は無かったことにして、新しい設計に基づいて開発をやり直すことにもなります。このように手戻りが発生してしまうと、2度手間3度手間となり無駄に工数を消費してしまいます。その結果、レビューに正しく時間を割いていた方が最終的にかかる工数は少なかった、ということに繋がりかねません。

〇 理想的なテスト
システム開発には仕様変更が付き物です。仕様変更とは、顧客との打ち合わせで決まっていた仕様が顧客側の都合で「やっぱりこうしてほしい」と変わることを指します。顧客が業務を遂行する上で必要な変更であれば、もちろん受け入れる必要があります。開発初期の外部設計/基本設計段階であれば手戻りは少なくなりますが、これが内部設計/詳細設計、開発、テストとフェーズが進んでいくにつれて手戻りが大きくなります。また、一度完成したシステムに対しても、実際に運用していく中で「やっぱりこうしてほしい」という話が出てくるものです。この中で、一番工数が必要となるのはテストです。顧客側からしてみれば些細な変更だとしても、システムとしてはその変更により影響を受ける全てを再テストして動作チェックしなければなりません。そのため、テストは自動化しておくことが理想です。具体的には、バージョン管理ツールと継続的インテグレーションツールを導入し、あらかじめテストケースを作成しておくことで、プログラム変更が発生した時に自動的にテストが実行される環境を作ることが可能です。これにより、テストを効率化することができます。しかし、普通にテストを行うことと比較すると、テストケースを作成することは倍近い工数が必要となることもあるもので、やはり時間の都合によりなかなか実現が難しいというのが実情です。

〇 顧客と上司の理解
ここまでは実際の開発作業について記載しましたが、それ以前に顧客と上司の理解があることが最大の理想となります。顧客の理解があれば無理な仕様変更は発生しませんし、上司の理解があれば無理なものは無理と顧客に断ることや、変更に応じて必要となる工数を顧客に伝えてスケジュール調整することができます。現場によっては、顧客の言うことには全てYesと答えることしか許されないということもあります。そうなると連日残業が求められることになります。

http://www.se-agent.biz/ ←システムエンジニアに強い転職エージェントをチェック

トラックバック

このエントリーのトラックバックURL:
http://www.darkdogtour.com/mt3/mt-tb.cgi/55

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2017年09月29日 16:39に投稿されたエントリーのページです。

ひとつ前の投稿は「身体を揺らす」です。

次の投稿は「昼間寝てて・・」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.38