SE(システムエンジニア)の主な仕事内容
スポンサーリンク
要件定義
シムテムを作るのに重要な要件定義のフェーズ。顧客からの要求であるRFPを現実可能な物にする為に顧客と打ち合わせを重ねながら進めていきます。
RFP(案依頼書)とは発注企業がシステム開発を行う際に必要な要求をまとめ、発注先の開発会社に具体的な提案を依頼するための資料のことを言います。
このRFPをから顧客の要求を実現するためにはどうすればよいかシステム屋の目線で検討し資料にまとめ顧客と意識を共有していきます。
顧客にも色々な顧客がいます。シムテムに詳しい顧客もいれば、まったくシステムの知識のない顧客もいます。中にはやりたい事が今の技術では現実的ではない要求をしてくる顧客もいます。そのため顧客の知識レベルを把握しながら顧客が理解しやすい説明、資料作りを心がけるのも大切です。
炎上する案件は要件定義のフェーズに失敗していることが多く、非常に重要なフェーズです。
(主な理由は顧客と要件が詰めきれていない、スケジュールが現実的でない、見積もりが甘いなど)
基本設計
顧客向けの仕様書が基本設計書。顧客向けの資料の為、分かりやすさと機能を網羅できているかが大切です。
システムの全体図や機能相関図、処理シーケンス、処理フローのようなシステムをイメージしやすい図と機能の概要説明があるのが一般的です。
ただ基本設計書は現場や案件によって書き方や書く内容も違います。案件によっては基本設計書がない案件もあります。基本設計書は顧客向けの資料の為、顧客に納品物として求められていない場合、基本設計書がない事は良くあります。
基本設計書は書くのに時間がかかりますし、基本設計書がなくても詳細設計書があればプログラマはコーディングすることが出来ます。しかし基本設計書がないと、後からプロジェクトに参加した人やシステムを知らない人は、どんなシステムなのかイメージするのが難しくなります。
詳細設計
プログラマ向けの仕様書が詳細設計書。プログラマ向けの資料の為、プログラマがコーディングしやすいように書きます。プログラマはこの詳細設計書を見ながらコーディングするのが一般的です。
詳細設計書の精度は現場によりだいぶ変わります。基本設計書に近い形で分かりやすさを重視しあまり細かいソースレベルのことまでは書かない現場もあれば、if文などのソースレベルまで細かく書く現場もあります。
また詳細設計書がない現場もあったりします。その場合、基本設計書から仕様を読み取る必要がありプログラマの負担は多く、仕様を間違って解釈してしまいバグに繋がる危険性もあります。スケジュールが過酷な場合は、基本設計書や詳細設計書がなく、口頭で仕様を説明してもらいながらプログラマがコーディングするケースもあります。そして後から設計書を作ることもあります。
コーディング
プログラマが詳細設計書を見ながらコーディングするフェーズです。そして一番忙しいのがこのフェーズです。だいたい夜遅くまで働いているのはコーディングしている時です。
コーティングは開発メンバの経験値により想定外の時間が発生することが多いです。例えばGoogle Mapを使用する案件で、Google Mapの経験者であれば1日で対応できる内容が、未経験者がやると1週間かかるというのも珍しくありません。他にもCSS経験者であれば10分で終わる内容でも、CSSの知識がない人がやると1日ハマっていたりします。それくらい経験者と未経験者では作業時間に差が出るのです。
そしてIT業界は変化の速い業界なので次々と新しい技術が出てきます。
プログラマはコーディングだけをしているイメージがあるかもしれませんが、実際はわからないことをWEBで調べている時間が結構あります。
要件定義や設計と違いコーディングは想定外に時間のかかることが多く高残業に繋がっていると思われます。
(ただ高残業になる一番の原因は開発期間が短かったり、開発人数が少ないのが主な原因だと思っています）
スポンサーリンク
試験
開発で作成したシステムを試験するフェーズ。
試験には主に単体試験、結合試験、総合試験があり、リリース後に炎上しないためにも非常に重要なフェーズです。
たまに現場で試験を軽視している人がいますが、そういう人が多い現場ほどリリース後にバグがよく出ます。
品質の良いシステムを作り上げるには試験は必要不可欠であり、非常に大事なフェーズである事は間違いありません。
単体試験
機能単体の動作を確認する試験が単体試験。
単体試験ではよくバグの原因となる境界値チェックやNULLチェック、入力チェック、例外確認、データベースの内容確認、入出力の内容確認などを行います。
単体試験のやり方は色々ありますが、ユニットテストや単体試験書での試験が一般的だといえます。
ユニットテストは単体試験用のソースコードを書く必要があり、開発者の負担が大きくコストがかかります。しかし単体試験段階でのバグの洗い出しには最適な手法だといえます。
単体試験書での試験の場合は、試験書の精度次第です。精度が高ければバグも洗い出されますが、精度が低いと単体レベルで発見するべきバグを見逃してしまう危険性があります。
結合試験
機能間を繋げた試験であり、設計書通りにシステムが動作するのかを確認するのが結合試験。
単体試験は機能単体の試験なので、結合試験で初めて機能間を繋げる試験を行います。型の違い(Stringとintや日付のフォーマット違いなど)やNULLの意識違い(NULLが来ないと思っていたらNULLが入ってきたなど)でエラーになることが多いです。
また負荷試験も結合試験の中でやっておきたい試験です。
システムが想定している限界値まで負荷を掛けた状態で、想定通りに動作するのかを確認することは重要です。負荷を掛けるとシステムの動きが遅くなることがよくあります。遅くなる理由でよくあるのがSQL。SQL文の書き方よくなかったり、インデックスが適切に付与されていなかったりします。(SQLのチューニングは大切です)
スポンサーリンク
総合試験
総合試験は顧客の要求通りの動作するかを確認する試験。
ここまでくるとあまり細かい試験パターンは行わずに、運用で想定されるシナリオを満たしているかを試験していきます。
ここのフェーズで単体レベルのバグが発見されると問題になることがあるので気を付けたい所です。(厳しい現場だと「なぜ単体レベルのバグを発見できなかったのか」の説明資料をを提出しなければならない現場もあります)
保守
シムテムを無事リリースしたら終了ではありません。保守を行う必要があります。具体的に何をするかというと普段は何もしません。問題があった時に対応します。
そのため保守を担当しながら別の作業を行うのが一般的だと思われます。
システムエンジニア(SE)の残業時間はどのくらい！？
2018年「Vorkers残業時間レポート」によると平均残業時間は28時間という結果になりました。
業界別ではIT業界の「Sler、ソフト開発、システム運用」は28.5時間。2013年が45.9時間だったので、働き方改革の影響などで、本当に残業が減ってきたのを感じます。
実際、私もシステムエンジニアとして働いていますが平均20時間〜30時間の残業時間です。忙しい時は40時間くらい働きますが、忙しくない時は定時で上がっています。
IT業界は「新3K」といわれ若い年代がIT離れをしています。そして2020年に東京オリンピックがあり、AIの発達もあり、2018年時点ではIT業界は人材不足の時代になっています。IT業界が本当に「新3K」なのか。もしかしたらそれも古い情報になってきているのもしれません。
「新3K」とは土木作業における「3K」(きつい、汚い、危険)からきている言葉。その内容は
(きつい、帰れない、給料が安い)
まだまだ残業時間が長い現場もあるのが現実かもしれませんが、一昔前の帰れない日々が続くような働き方をしている現場は少なくなっているように感じています。平均残業時間「28.5」と具体的な数値になって現れているものが現実だといえるのかもしれません。