この記事では、SIerに就職した新人システムエンジニア（SE）が、初めて業務に取り組む時に心がけたいことを5つご紹介します。
筆者は新卒以来、SIerでSEとして従事してきています。
SIerとは、世の中で動く様々なITシステムを作る会社です。
システムインテグレーター（英: Systems Integrator）は、個別のサブシステムを集めて1つにまとめ上げ、それぞれの機能が正しく働くように完成させるシステムインテグレーション事業を行う個人や企業を指す
wikipedia(システムインテグレーター)
SEとして、筆者は普段、例えばこんなことをしています。
- お客様とシステム仕様の擦り合わせ
- プログラムの製造や、テストの実施
- システム変更に伴い、影響を受ける他システムへの説明
- システム障害の連絡を受け、本番サーバへ駆けつけ復旧の対応
実はSEの業務は、意外と幅広いのです。
ただ、この中でも、新人SEが担当するのは、基本的に「プログラムの製造・テスト」になることが多いです。
この記事では、SIerに就職した新人システムエンジニアが、初めてプログラムの製造やテストをする時に気をつけたいことを、筆者の実体験を交えて５つ、ご紹介しています。
是非参考にしてみてください。
新人システムエンジニアが気をつけたいこと5選
SIerの新人システムエンジニアが、初めてプログラミングやテストの業務をする時に、気をつけたいこと５つを、まとめていきます。
これらの項目は、要件定義や設計、リリースといった他の工程でも必ず役にたつものです。できるだけ意識し、身につけられるようにしていきましょう。
- 必ずINPUT文書に従って作業をしよう
- 作業前に成果物の確認をしよう
- 事前にチェックリストを確認しよう
- こまめにレビューをしてもらおう
- とにかく他を真似よう
必ずINPUT文書に従って作業をしよう
開発作業をするときは、必ずその作業をするためのINPUTのドキュメントがあります。
例えば、プログラミングであれば設計書、テストであればテストケース表といったものです。
ただ、INPUT文書に従うのは当然だと思いますよね。
ところが、実際に作業をしてみると、良かれと思って、ちょっとINPUTを無視してしまうことがあるのです。
設計書では出力メッセージが「hallo」でした。ただタイプミスだと思ったので、プログラムでは「hello」へ修正しておきました。
INPUT文書に従わない修正はNGです！
実はそのシステムでは、構築当初から、「hallo」のタイプミスが埋め込まれてしまっており、「hello」で定義すると動かなくなってしまうかもしれません。
修正をしたい場合は、必ず設計した人などへ確認をしましょう。
また、問題がなければ、まずINPUT文書の設計書を修正した上で、プログラムを修正しましょう。
ツールXを使ってテストをすること、とありましたが、テストに失敗しました。ただ、ツールXの設定を少し変えたらテストに成功したので、テスト合格としました。
テストケースに記載の条件を無視したテスト実施はNGです。
実はテストケースに記載の条件が間違っていたのではなく、そもそもプログラムに不備があり、想定の条件ではテストがうまくいかなかったのかもしれません。
テストケース記載の条件で不合格になった場合は、まずは、正直に不合格と評価するようにしましょう。
実は、INPUT文書に従うことは当然だと思っていても、このように、改善や作業効率化を考えて、INPUT文書からずれてしまうことがありますので、気を付けるようにしましょう。
作業前に成果物の確認をしよう
プログラミングやテストをするときは、まず作業前に、最終的に何を作成すれば良いのかを必ず上位者へ確認しましょう。
自分の成果物をレビューしてくれる人や、OJTの先輩などへ確認するのが良いですね。
成果物なんて決まりきっているだろう、と思う方もいるかもしれません。
確かに、例えばソースコードや、テスト時のログなど、一見悩むことは無いようにも思えます。ところが、例えば以下のように、意外と抜け漏れしてしまうようなことがあるのです。
こたにんデータベースの中身をロールバックする異常系のケースを実施しました！
結果をまとめたので確認してください！
先輩エンジニア確かにデータベースの中身は空になっているね。
ただ、本当にテスト前にはデータベースの中にデータはあったのかい？
この例は、テスト実施前にもデータベースのログをチェックしておく必要がありましたが、それができていなかったようです。
こたにん設計書通りにプログラム作成しました！
確認してください！
先輩エンジニアこのプログラム、あちこち文法がおかしくないかい？
ちゃんとコンパイルは通るのかい？
こちらは、成果物として、コンパイルまで完了したソースコードを準備する必要がありましたが、それができていなかったようです。
このあたりはプロジェクトの環境にもよります。
レビューを出す際は、自動的にコンパイルや各種チェックまで完了してしまうような便利な環境 (CI環境などと呼ばれます) もあったりします。
成果物は、プロジェクトや環境などによって毎回変わる可能性があるものです。何度もやり直しにならないためにも、手を動かす前に、何をOUTPUTするのか、確認をする習慣をつけましょう。
事前にチェックリストを確認しよう
チェックリストという言葉を初めて聞く人もいるかもしれません。
チェックリストとは、開発作業時に注意すべき事柄がまとめられたドキュメントで、以下のような特徴があります。
- 過去の開発プロジェクトなどで発生したトラブルや不具合などのノウハウが積み上げられています。
- 細かな作業工程ごとに用意されていることがあります。（製造用、設計用、など。）
- 各作業工程ごとに、担当者は必ずチェックすることを義務付けられることがあります。
具体的には、チェックリストには以下のような観点があります。
・コーディング規約に従ってプログラミングしているか？
・最新のバージョンのプログラムを修正したか？
・起こりうる全ての入力値に対してテストをしたか？
・テスト結果としてプログラムのログだけでなく、システムのログもチェックしたか？
このように、チェックリストには、過去の失敗を繰り返さないための重要な観点がまとめられていることが多いです。
そして何よりも、事前にチェックリストを確認しておかないと、全作業がやり直しになるかもしれません。
例えば、プログラム修正が終わった後に、そのプログラムが最新バージョンだったか確認したのでは遅いですよね。
ですので、チェックリストや、該当するドキュメントがある場合は、必ず事前に確認するようにしましょう。
こまめにレビューをしてもらおう
初めて業務をするときは、これが特に重要です。
レビューをしてもらう人、あるいはOJTの先輩などに、こまめに作業の成果や状況を共有するように心掛けましょう。
目的の一つは、言わずもがな、成果物の方向性が間違っていないかを確認してもらうためですね。進め方が間違っている場合、早めに検知して方針修正できた方が、やり直しの量も少なくてすみます。
さらにもう一つ目的があります。
開発プロジェクトには、上に書いた通り、INPUTドキュメントや、ルールが十分にありますが、さらに突発的に発生するルール・変更といったものもあったりします。
こういった突発的なイベントに対し、自分の作業への影響を知るためにも、こまめに今の状況を共有するようにしましょう。
せっかくなので、私が過去経験した一例をご紹介します。
あるプロジェクトがランニングテスト (本番を想定し、長期間アプリケーションを継続稼働させるテスト) を実施するため、開発環境のアプリケーションの設定を変更。
テスト消化完了まで、設定の変更が継続された状態となった。
この環境は他のプロジェクトとも共有の環境でした。
そのため、変更を知らずにテストをしてしまった他プロジェクトは、全テストを元の設定でやり直し、となってしまったなどの影響がありました。
このような変更は、新人までは通達されないことや、あるいは通達されても影響が判断できないこともあります。だからこそ、今実施している作業を定期的に共有することが大切になります。
新人が自分から作業状況を共有していくことは、先輩やレビュアーにとってもありがたいはずです。
定期的に状況共有し、安定した開発ができるように心がけていきましょう。
とにかく他を真似よう
色々と気を付けるポイントをご紹介しましたが、結局のところ、真似に尽きます。
最初はひたすら他の真似をしていれば、意外とうまくいくものです。
こたにん他のプログラムに「hallo」って書いてあったから、今回のプログラムも「hallo」にしておきました！
こたにん他のテスト成果物を見たら、システムログも含まれていたので、私も一応システムログをとっておきました！
こたにんみんないつも午前中にテストしていたので、私も午前中にテストするようにしています！
この記事で紹介した各種トラブルも、こんな感じで、他の真似をしていれば、意外とうまく回避できたりします。
システム開発をする上で一番良い教科書は、今安定稼働しているシステム自体です。初めて開発作業に入ったときは、とにかく色々なプログラムや設計書、テスト結果などの資料を読みまくり、そのシステムでのルール、作法を吸収していきましょう！
この記事はこれで以上です。新人エンジニアの方々の参考になれば幸いです。
