【開発経験3年】SEのリアルキャリアパス:設計からテストまで一貫対応の現場から

アイキャッチ画像

2025年1月に入社したT.Nと申します。

私は新卒でSES会社に入社し、3年ほど開発の現場にて設計からテストまで一通り経験しました。

それぞれのフェーズ毎に躓いたところ、知っておきたかったことを実体験に基づいて記事にしました。

未経験からの目線で書きますので、反面教師として参考となれば幸いです。

 

■基本設計

 基本設計とは、システムの要件定義でまとめられた要望を元に、

 システムの具体的な機能や構成などを決定する工程です。

 

 開発を進めるなかで最も重要な工程だと思います。

 基本設計時点で顧客との認識があっていないと

 それ以降の製造が全て無駄になりますΣ(゚∀゚ノ)ノ

 

 基本設計段階で開発納期を決め、それぞれの見積工数を出していきます。

 その為、開発中どこかで遅延が発生すると、後の作業がキツくなってしまいます。

 

 1.躓きポイント①

  基本設計で記載した内容が製造不可だった:

  基本設計段階では技術的には可能だと思われた機能でしたが、製造が進んでいくと、予期せぬエラーが発生しました。

  調査したところデータベース上の制約に引っ掛かっていた為、そもそもの機能を見直さないと出来ないという結論になりました。。

  結果:

  代替案でOKを頂きましたが、開発納期ギリギリになってしまいましたm(_ _;)m

  教訓:

  予め制約等に引っ掛からないかサンプルデータを用意して確認する。

  

 2.躓きポイント②

  見積工数の見込みが甘かった:

  基本設計段階で、作業者から別企業で似た対応をしたことがあると聞いていたため、

  見積工数をある程度抑えて考えていました。

  製造が始まり作業者に問い合わせたところ、全く違う対応だったことが判明。

  一から作成が必要になり、その時点で見積工数が破綻しました。

  結果:

  開発納期には間に合ったものの、工数が余計にかかってしまいました。。

  教訓:

  類似の対応があった場合、その対応内容で製造可能か確認する。

 

■詳細設計

 詳細設計とは、システムの内部構造や動作の詳細を具体的に決める工程です。

 基本設計で決まった機能を、実際にプログラミングや開発ができるレベルまで落とし込みます。

 

 実際に詳細設計を見ながら開発を進めるため、粒度の粗い詳細設計では意味がありません。

 また、詳細設計からテスト仕様書にテスト内容を記載するため、詳細設計漏れはバグを発生させる原因とも言えます。

 

 1.躓きポイント

  文言、説明文の統一化が出来ていなかった:

  説明文の末尾が「です」「ます」に統一されていなかったり、同じ変数なのに違う説明文になっていました。

  結果:

  製造する際に混乱してしまいました。。

  ※私が詳細設計→製造を担当したため、混乱したのが自分だったのが不幸中の幸いです。

  教訓:

  詳細設計の作成前に文言等のルールを決めるべきでした。

  

  

■製造(プログラミング)

 製造とは、エンジニアが詳細設計を基にプログラムを作成し、実際に設計書通りの実装になるか確認します。

 製造では、詳細設計(日本語)をソースコード(プログラミング言語)に変換するため、

 一通りのプログラミング能力が必要になります。

 

 1.躓きポイント①

  質問が遅かった:

  初めて使用するプログラミング言語だったため、調べながら製造していました。

  ただ、調べても出てこない内容が出てきた際、暫くの間立ち往生していました。。

  結果:

  他の作業者からプロジェクト専用の関数のため、調べても出てこないと伝えられ、

  使用方法まで教えて頂きました。

  教訓:

  一度調べても出てこない場合、すぐに有識者に質問をする。

 

 2.躓きポイント②

  質問の仕方:

  質問する際に、全部投げかけるような質問になってしまい、

  「自分で調べた?」と逆に質問されてしまいました。。

  結果:

  自分が調べた箇所、その結果、今何で躓いているかを改めて質問しました。

  教訓:

  質問するときは、下記の手順で質問する。

  ①質問の概要を伝える。 「〇〇処理の実行時、エラーが発生してしまいました」

  ②どこまで調べたか伝える。 「調査して、〇〇処理の△△までは正常に進んでいるのですが、□□でエラーに飛んでそうです」

  ③どうしたいか伝える。 「□□では☆☆操作を行いたいです」

  ④最後に 「ご教授いただけますでしょうか。」

 

■テスト

 テスト作業とはシステムやソフトウェアが設計通りに動作するか、不具合がないかをチェックする作業のことです。

 具体的には、テストケースの作成、テストの実行、結果の評価、改善提案など、開発工程において品質を担保するための重要な作業です。

 

 テストする際には、エビデンス(操作毎にスクショ)を取得しながら行うことが一般的です。

 また、使用したテストデータも残しておくと何かあった際に便利です。

 

 1.躓きポイント

  テストケースの不備:

  基本的にテスト時は全てのソースコードが通るようにテストケースを作成します。

  ループの処理がある場合、複数回実行させるテストケースを作成しましたが、

  ループ時下記のケースでのテストが行われていなかったため、再チェック時にバグが発生しました。

  (実際にテストしたケース)

  処理開始→ループA開始→分岐処理→B処理→ループA開始に戻る→

             →分岐処理→C処理→ループA終了→処理終了

  ※分岐ではBとCに分かれています。

  (バグが発生したケース)

  処理開始→ループA開始→分岐処理→B処理→ループA開始に戻る→

             →分岐処理→B処理→ループA終了→処理終了

  結果:

  1度目のループでB処理のメモリを破壊してしまい、

  2度目のループでB処理を参照しようとしたところ、

  既に破壊されているものを参照しようとしたためエラーが発生した。。

  製造者に修正を依頼し、テストケースに不備が無いか再度調査した後、

  テストケースを増やして再テストになりました。

  教訓:

  ループと分岐処理がある場合は同じ処理が複数実行できるかの確認を怠らない。

  

今回はフェーズ毎に未経験の自分が躓いたところを書かせていただきました。

この記事を書いている時、当時のことを思い出して胸が痛くなりました。。

同じ失敗しないように私も時々この記事を読もうと思います笑

この記事がどこかで皆さんの役に立てたら幸いです!