この記事では、初心者向けにシステム(IT)エンジニアが行う仕事内容を紹介しています。
システム開発の流れは、会社やプロジェクトによって多少異なります。
こちらは営業が行うことが多いです。
まずは仕事を受注します。
コンサルティングを行いエンドユーザーの要望を調査してまとめ、顧客にプレゼンテーションを行います。
ここで受注して初めてプロジェクトが始まるわけです。
ここでいかに仕事をとれるかが、営業の使命となります。
人は何かを考えて言葉を発します。
これらは発する人により、様々な形に変化します。
そのため「考え」と「言葉」では多少のズレが生じてしまうのです。
言葉をそのまま受け止めるのではなく、その他のあらゆる情報から本当に言いたいこと、思っていることを分析しましょう。
エンドユーザーの業務内容や要望、また現状のシステム(あれば)を細かく調査します。
そして、それを実現できる要件を定義します。
エンドユーザーの仕事内容を理解する必要があるのでSEという仕事は、プロジェクトごとに毎回勉強が必要になります。
医療、金融、行政など、システムを開発するにはそれらの知識が必要不可欠なのです。
エンドユーザーの業務内容をしっかりと理解して要求を聞き出しましょう。
エンドユーザーはシステムに関する知識がほとんどないことが多いです。
そのため、説明がかなり曖昧だったり矛盾したことを言ってきます。
それを何を望んでいるかをSEが正しく取り纏め、要件を定義します。
プロ目線ではなく、エンドユーザーの目線で考えることが大事です。
ここで、要望とずれのある定義をしてしまうと、この後の工程に大きく影響がでる可能性があるので注意してください。
後工程になればなるほど、仕様の変更は大変になりコストも消費してしまいます。
基本設計・UI設計などを行います。
定義した要件から、画面や入出力に関する機能を設計します。
画面設計、データーベース設計や帳票設計がメインとなります。
要望を網羅した設計書ができれば問題ありません。
名前の通り、より詳細な設計書を作成します。
システム開発の実現方法が分かるように設計する必要があるので、プログラムレベルで分割して、プログラムでの実現方法が分かるようにします。
詳細設計書をみることで、どのような仕様でどのように実現するかが分かるようになります。
プログラムを言葉で書くようなイメージです。
クラスやメソッドなど、これらの処理を言葉で記述していきます。
ちなみに私はプログラミング設計はほとんどすることはありません。
設計書に基づき、プログラミングを行います。
ここで初めて実際にシステムが構築されるのです。
プログラミングを行う準備として、開発環境の構築、言語の選択、フレームワークの選択、DBの選択なども必要になってきます。
よくこの工程がメインだと考えている方も多いようですが、それは全くの間違いです。
むしろ、詳細・プログラミング設計書があれば比較的楽な工程なのです。
設計やテストの方が重要になってくると私は思います。
一般的によく使われる言語は以下となります。
Java,PHP,Ruby,Perl,C,C#,VB.net,VB,C++,Objective-C
なにを開発するかによってその特性にあった言語を使用します。
そして、フレームワーク選択して開発を行います。
細分化した単位でのテストを行います。
各メソッドが、正しい値を返すかなど、全てのプログラムに対して細かくみていきます。
基本的にはプログラミング設計書の項目ごとに確認を行います。
プログラムをまとめた各機能ごとに確認をおこないます。
こちらは詳細設計書を見ることで何を確認すればよいのか分かります。
設計した各機能が正しく動作しているかあらゆる方法でテストします。
システム全体で検証を行います。
ここまでくるとバグはかなり減ってきます。
この工程でバグをなくせると理想的です。
エンドユーザーの実務業務と同様に操作して検証を行います。
ここでのテストをクリアすると実際にシステムを導入する、いわゆるカットオーバーとなります。
ここでバグが出たり、仕様の変更を求められるとかなりキツイです。
要求定義・設計・テストをしっかりとして、そういったことが極力おきないようにしましょう。
バグの修正、インフラ系障害の対応、新要望の対応などがメインとなるのではないでしょうか。
トラブル系の場合は、一刻も早く解消させる必要があるため、場合によっては徹夜もあります。
直るまで対応する必要があるためです。
新しい要望が生まれて対応する場合は、また要求定義・設計・開発・テストを行い、その後に本番環境へ反映します。
上記では、一般的な工程について紹介しましたが、進め方にもいろいろな方法があります。
有名なものは、ウォーターフォール型、プロトタイプ型、スパイラル型などです。
それぞれ良いところや悪いところがあるため、開発前によく検討する必要があります。
こういった進め方や、各ドキュメントの書き方、ソースの記述方法は標準化することが望ましく思います。
こういったものが毎回変わると、慣れないため大変です。
慣れているのと慣れていないのでは全然違いますよね。
作業工数が増え、障害も増え、またストレスも増えてきます。
できるだけ標準化して品質の向上を図りましょう。
今回紹介したのは、一般的な顧客が使うシステムを構築する場合のプロジェクトの進め方です。
SEは、この他にも、Webサービスやスマホアプリの構築など、一般ユーザー向けに開発を行うこともあります。
また、システムの規模によっても異なっては来ます。
その時々によって、多少は変わってきますので、臨機応変に対応ください。
最近は、小規模開発を行う会社がかなり増えています。
そういった会社では、設計書もなく開発を行い、テストも簡単なテスト仕様書を作って行いすぐ納品しているところもあります。
私は何度かこういったプロジェクトにも携わったことがありますが、バグいっぱいでます。
工数がかなり減るため、短期間低コストで納品することができますが、クオリティはかなり低いです。
これが悪いこととは言いませんが(顧客によっては)、技術者として今回紹介した工程を行う能力は身につけている必要があります。
大規模になればなるほど、各工程が重要になってくるので品質の高い物作りが出来るよう頑張ってください。