はじめに
初めまして！ 今年4月に新卒としてウェルスナビに入社しました、佐藤です。
本記事では、私が企業でのシステム開発を経験して感じた個人開発との違いについて、実際のシステム開発の流れを交えながら説明します。
これからエンジニアを志す方々に、企業でのシステム開発の雰囲気や、今からでもできることについて、少しでも学びになれば幸いです。
対象読者
- 企業でのシステム開発がどんな感じなのか気になる、という方
- 自分が作るプログラムがいつもバグだらけ、もっとちゃんとしたプログラムを作りたい！ という方
企業でのシステム開発の中で感じた、重要なこと
個人開発との違いの中で、特に重要だと感じたのは、下記の2つです。
- 「なぜそうしたのか？」を、強く・繰り返し意識する
- コーディング以上にコストを掛けて、「本当にそれでいいのか？」をしっかりと検証する
なぜこの2つが重要だと感じたのか、私たちのチームでの実際のシステム開発の流れを交えながら説明します。
私たちのチームでのシステム開発・テストのフロー
チーム毎のやり方や案件にもよりますが、私たちのチームでシステム開発をする際の大まかなフローは下記の通りです。
その中で特に大事だと思った部分をピックアップして説明します。
設計レビュー
自分が考えたシステム設計で問題ないか確認するためのレビューです。
ここでは、なぜこのような設計にしたのか、本当にこの設計でいいのかという部分が重要視されます。
自分しか使わないシステムであれば、とりあえずやってみて問題が起きた時に修正する…という形でも問題ないかと思います。
しかし、企業が開発するシステムの背景には多くのお客様がいらっしゃいます。そのため、個人開発に比べて影響範囲が圧倒的に大きいです。
設計を深掘り、理由をきっちりと説明できるようにしておくことで、「それならこの設計はどうだろう？」「このパターンを見落としていないか？」といった議論に繋げることができます。
それによってシステムの品質を上げ、不具合の発生を抑えることができます。
また、個人開発では自分1人が設計を把握していればOKですが、企業でのシステム開発が自分1人で完結することはありません。
後からプロジェクトに参入する（アサインされる）人が困らないようにするため、ドキュメントとしてしっかり残しておく必要があります。
テスト設計・テストケースレビュー
個人開発だと「このパターンで確認しておけばいいか…」と頭の中で考える人もいるかと思いますが、企業でのシステム開発の場合は大抵、考慮漏れを防ぐため、そして他の人にもレビューしてもらうため、スプレッドシートなどにきっちりと書き出します。
私たちのチームでは多くの場合、下記の2種類のテストを実施します。
| テストの種類 | 詳細 |
|---|---|
| 機能テスト |
開発した機能が正常に動作するか？ という観点。 今回開発した機能が正常に動作することを確認するために、どのようなパターンのテストが必要か、洗い出す。 |
| 無影響確認 |
意図しない悪影響が発生していないか？ という観点。 過去のとある日時でのデータベースの内容を再現して改修後のシステムを動かし、改修前のシステムでの実行結果と比較して意図しない差分が出ていないかどうか確認するテスト。 いつのデータベースを再現するのかを決めておく（大抵の場合、テスト対象のシステムが稼働する日時であればOK）。 |
前者は比較的容易に想像がつきますが、後者の無影響確認については、個人開発の範囲ではなかなかやらない部分だと思いました。
そしてレビューの際は、「なぜそうしたのか？」「本当にそれでいいのか？」という部分が重要視されます（「このパターンのテストが必要（或いは、省略しても良い）と判断したのはなぜか？」「本当にこのテストケースでカバーしきれるのか？」など）。
テスト実施・テスト検証レビュー
テストを実施したら、結果をスプレッドシートにまとめます。
個人開発ではわざわざテストの証跡を記録しない人もいるかと思いますが、企業でのシステム開発では、他の人が確認できるようにテストの証跡をしっかりと残します。
レビューの際はやはり、「なぜそうしたのか？」「本当にそれでいいのか？」が重要視されます（「検証結果をOKとした根拠は何か？」「データ抽出の条件がおかしいなど、論理が破綻していないか？」など）。
この時、結果をまとめるスプレッドシート内で関数を複雑に使用してしまっていると、他の人が解読するのに時間が掛かってしまいます。
パッと見のシンプルさだけでなく、判断の根拠が伝わりやすいようにすることが大切です。
企業でのシステム開発プロセスを経験しての感想
企業でのシステム開発プロセスを経験して、コーディング以外の部分にコストを掛け、着実に進めることの大切さを実感しました。
私が学生時代にやっていた個人開発は、自分用のWebアプリを開発するというものでした。不具合があった時の影響範囲も限定的だったので、設計やテストはなんとなく実施するといった形で進めていました。
一方で、現在私が所属しているチームでは、お客様からお預かりした大切な資産を使った取引を扱っています。不具合があると多くのお客様が不利益を被る可能性があるため、私がやっていた個人開発に比べて、影響範囲が段違いに大きいと言えます。
そのため私たちのチームでは、速さよりも丁寧にシステム開発を進めることが重要視されています。
ここまでの説明の中でも「なぜそうしたのか？」「本当にそれでいいのか？」という考え方が繰り返し出てきていることがお分かりいただけたかと思います。
お客様や他のメンバーのことを考え、システム開発のプロセスを一つひとつ着実に進めていることが印象に残ると同時に、その大切さを実感しました。
個人開発でも、機能テストは取り入れられる
上記の内容の全てを個人開発に取り入れるのは難しいし過剰だと思いますが、個人開発の段階でできることもあると感じました。
まずは、テストケースを洗い出して、テスト結果をまとめてみるということから始めてみてはいかがでしょうか。
例として「お問い合わせのためのメールフォーム」を取り上げてみます。
「お問い合わせ本文（必須、1000文字以内）」という項目を1つ取っても、
- 空欄の場合はエラー表示になるか？
- 1000文字丁度の場合は確認画面に移動し、1001文字になったらエラー表示になるか？（境界値分析という考え方）
- HTMLタグが含まれている場合、確認画面でちゃんとエスケープされているか？
…など、様々なパターンが考えられます。
加えて、テストケースやテスト結果をまとめる段階も、読み手に分かりやすく伝えることの練習になります。
こういった考え方やスキルは一朝一夕に身につくものではないと考えています。今のうちに練習しておくことで得られるものも大きいのではないでしょうか。
おわりに
本記事では、私が企業でのシステム開発を経験して感じた個人開発との違いについて、実際のシステム開発の流れを交えながら説明しました。
企業でのシステム開発の雰囲気を理解する助けになったのなら何よりです。
テストケースを洗い出したり、結果を分かりやすくまとめたりする部分は、個人開発のうちから練習できる部分ではないかと思います。
将来エンジニアを志す方は、是非参考にしてみてください！
Discussion