社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

ITエンジニアの分類(仕事の役割:システム開発)

ITエンジニアを仕事の役割の観点で分類すると、システム企画、システム開発、運用保守に分類できます(私はシステム開発と保守を経験、ちょっとだけシステム企画にも携わる)。

システム開発は、ITエンジニアの仕事といった時に、一番イメージしやすい仕事です。システム企画が終わると、要求定義があり、要件定義、設計、製造、テスト、といった流れでシステム開発の工程が進みます。大部分のプロジェクトは、ウォーターフォール型と呼ばれる開発手法を採用しますが、最近ではアジャイル型の開発手法も徐々に採用されはじめてきました。

アジャイル型も誤解を恐れずに言えば、要件定義、設計、製造、テストという流れは同じです。どのような開発手法でも、ユーザーからやりたいことをヒアリングして、システムを作って、ユーザーに確認してもらう、という流れは変わりません。

①要求定義

要求定義では、何をやりたいかを整理します。ユーザー部門自身が要求定義書を作ることもありますが、通常は社内SEやIT子会社がユーザー部門の「やりたいこと」を要求定義書としてまとめます。この要求定義書に、請負の条件とかを肉付けしたものがRFPで、ベンダーはこれを元に提案書や見積りを作ります。

要求定義の記載が粗いと、ベンダーはリスクを多くとるので、見積りが膨らみます。

②要件定義

要求定義はシステムを意識せずに記載しているので、要件定義ではシステムで実現する範囲を決めます。手作業でやる部分とシステム化する部分を決めて、システム化する部分について、実現方法を検討します。

要件定義の記載が粗いと、あとでユーザー部門と揉めたり、バグがたくさん出たり、システム開発の失敗の大部分は要件定義の不備にあると言われています。

③基本設計

要件定義書は、ユーザー部門がわかる言葉で記載をしているので、それをシステムの言葉で置き換えたものが基本設計書です。システムをサブシステムや機能といった括りで分割して、その機能毎にシステムの実現方法を基本設計書に記載していきます。データーベースのデータの持たせ方とか、システムの処理の流れとか、インプットとアウトプットの全パターン等を記載していきます。規模の大きいシステムの場合、機能毎の基本設計の前に全体の設計をすることが重要になります。

基本設計の記載が粗いと、実装者が勘違いして作ったり、機能間で不整合が出たりして、テスト工程で炎上します。

④詳細設計

詳細設計では、基本設計書をもとにして、実装に必要な具体的な情報を詳細設計書としてまとめます。Javaの場合だと、どのようなクラスを作っていくかを決めたり、メソッド定義書等のプログラム仕様書を作ったりします。規模の小さいシステムやパッケージ中心のシステムだと、詳細設計自体をやらないこともあります。

⑤製造

いわゆるプログラミングです。パッケージの場合には、パラメータの設定等が製造にあたります。製造の過程である程度、動かしたりして初歩的なバグは潰しておきます。最近はプログラム言語もどんどん高度化して、かなり生産性が高くなってきました。またシステムに詳しくない人でも、マウス操作だけでシステムを作れるようにもなってきました。

単体テスト

通常は製造と一緒にやっていきます。Javaの場合だとJUnit等を使ったりします。作った画面等を動かすのではなく、プログラムそのものを単体で動かすので、プログラムテストと呼ぶこともあります。

教科書的には、このようなテストを単体テストと呼びますが、実際のプロジェクトでは単機能の結合テストのことを単体テストと呼ぶことが多いです。

結合テスト

画面内の入力チェックや出力内容の確認などの単体の機能のテスト(単体テストと呼ぶこともある)と、画面遷移の確認やある機能の画面で入力した情報を別の機能の画面で出力させたりするテストです。テストそのものよりもテストケースを作ることに多くの時間を要します。

テストケースを体系的に作れないと、テスト漏れが発生するので、設計と同じく論理的な思考能力が要求されます。

⑧総合テスト

システム全体のテストです。

バグの大半は結合テストで潰されている前提なので、この総合テストでバグがたくさん発生すると、リリース延期等のプロジェクトマネージャーとしては避けたい事態が現実味を帯びてきます。

⑨受入テスト

発注者のシステム部門やユーザー部門のテストです。

システム部門のテストは、結合テストや総合テストのレビューをすることで省略することもあります。ユーザー部門のテストは、主に操作感が想定通りかの確認をします。メッセージの出るタイミングなどは、なかなかドキュメントでは確認が難しいので、この受入テストで確認することになります。

ここでバグが見つかっても、リリースまで期間が短いこともあり、運用制限等が発生することもあります。業務に大きな影響のある制限があると、プロジェクトとしては失敗の烙印を押されます。さらにリリースした後で、早期のバグの修正を要求されるので、開発者の苦しみが続きます。

⑩リリース

受入テストが終わってリリース判定という儀式を経て、晴れて本番にプログラム資材をリリースすることができます。

大きなリリースだと次の日の本番サポート体制等を決めることもあります。

リリース作業は、ベンダーがやる場合もあれば、IT子会社がやる場合もあります。小さい会社だと社内SEがやることもあります。また内部統制が厳しい会社だとリリース作業は運用部門が実施することもあります。

【振り返り】

ざっと以下の分類の③−2についてご説明しましたが、イメージが湧いたでしょうか?

次回は③−3について詳しくご紹介していきたいと思います。

①スキル領域
 ①−1 アプリケーション系
 ①−2 インフラ系
 ①−3 運用系

②会社による違い
 ②−1 事業会社のIT部門(社内SE)
 ②−2 ユーザー系IT企業
 ②−3 Sier

③仕事の役割
 ③−1 システム企画
 ③−2 システム開発
 ③−3 運用保守