システム開発のプロセスと反省点

雑記

先日、会社にてシステム開発の全行程を経験する機会がありました。これまで、個人でプログラムを作っていたときはあまり意識していませんでしたが、チームでの開発となると足並みを揃えるために決まった工程でシステムを作っていくことになります。

私が担当したのは要件定義→設計→プログラミング→テストの工程ですが、実際にやってみることで色々な発見がありました。この記事では、各工程で行うべきことと私が感じた反省点を紹介します。


企画


始めに、どのようなシステムを作るのか、企画を行います。基本的には、既存ツールの改良点や問題点を探して、どのように解決していくかを検討していく段階です。

ただし、今回のプロジェクトでは私はこの工程に関わらなかったので、ここでの詳しい話は割愛します。本プロジェクトでは、社内で用いるためのツールの機能追加を行うことが決定していました。


要件定義


システムの方針が決定したら、次にどのような要件が必要かを洗い出します。

システムの要件としては、機能要件、非機能要件、システム要件があります。私が担当したのは機能要件でした。ここでは、最初に現行ツールの仕様を把握し、ここからどのような機能を追加していくべきかを検討します。


この工程で苦労したのは、なんといってもヒアリングの会議を設定することです。今回開発する機能は他所のチームでも利用されるため、各チームに赴いて要件を聞いて回る必要がありました。

ここで要件を聞き漏らすと後でカバーするのが困難になるため、なるべく多方面に要件を聞いておく必要があります。メールでの質問だけでは意見の相反が出たときに対処が難しいので、基本的に私は会議招集してヒアリングを実施していました。

しかし、会議招集しても音信不通の人、無断欠席する人がいたり、意見が対立して会議を予定時間内に集結させることができなかったりと、主に人間関係の調整に苦労することになりました。今思えば、チームのキーパーソンを事前に調査しておいて、より少人数で会議を行った方が建設的だったかもしれません。

また、ヒアリングの日程がギリギリだったりすると、夏休などで人が集まらなかったりするので、ヒアリングに係る計画作りも重要だと学びました。要件定義にかけられる期間は決まっていたので、各ヒアリングにおいて何を質問するのかを計画立案時点で検討しておくことが必要だったと反省しています。

いずれにしても、エンジニアとはいえ一般的な会社で必要な「折衝力」と「計画力」は問われることを痛感した次第です。


設計


この工程では、挙げられた要件を満たす画面とテーブルを定義します。画面定義ではブラウザ上に映し出されるフォームなどの配置を決定し、テーブル定義ではどのようにデータを格納していくのかをRDB形式で決めます。


先ほどの要件定義書もそうですが、ここでは全ての資料をエクセルで作成しました。なんと、画面定義もエクセルで設計しました。いわゆるエクセル方眼紙ですね。(笑)

私たちのシステムではデザインが全てBootstrap頼みなので、このグリッドシステムとエクセルの相性が結構良いのです。行や列を増やすのも容易ですし、要件定義書と設計書が一つのエクセルファイルに収まってしまうので、意外と見やすく使いやすかったです。おそらく、今使っているはてなブログのデザインもエクセルで簡単に再現できると思います。

ただし、複雑なデザインにはもちろん対応していませんし、ボタンのイベントを再現することはできません。そのあたりで困っている方は、Prottなどのワイヤーフレーム専用ツールを使う方が良いと思います。


インフラ設定


今回開発するシステムはWebサービスなので、公開するためのWebサーバーを用意する必要があります。この工程は私の担当ではなかったので詳しくは知りませんが、某クラウドサービスからインスタンスを1つレンタルして、そこにApacheでWebサーバーを構築したようです。

コミット時のCI/CDは実装されていませんでしたが、定期的に自動デプロイが行われる仕組みになっていたので、私の方で何か操作をするということはありませんでした。


プログラミング


この工程では、設計書の通りにプログラムを作成していきます。GitLabで開発用ブランチを作成し、そこに新たなサービスを追加します。


ここでは、とにかくコミットの競合が発生しまくって大変でした。gitを使っている以上、ある程度の競合は仕方ないのですが、共通で利用される部品を減らすことでもっと競合を減らせたのではないかとも考えています。

また、分からないことをすぐに質問しなかったことでスケジュールが逼迫してしまうこともありました。私が2日悩んで解決できなかったエラーを、先輩エンジニアは10分で解決したということもありました。おそらく、一人で悩みを抱えて無駄に時間を費やす方が結果的に迷惑がかかるので、萎縮せずにすぐ質問するべきだったと思います。ただし、同時に上手い質問方法も知っておくべきかもしれません。


このように、色々ありましたが何とか期間内にプログラムを完成させることができました。


テスト


最後に、別の人が作ったテスト仕様書の通りに画面テストとバッチ処理テストを行います。このテストを通過すれば、晴れてシステムリリースとなります。

ただし、実際には不具合がタケノコのように発生するため、この工程の大半はエラー対処に終始することになります。


ここでは、テスト自動化の是非について考えながら業務を行っていました。例えば、バッチ処理ならテストコードを書くことで出力結果との比較が自動化できそうです。しかし、画面テストでは使い勝手の確認やモンキーテスト（思いつき操作）も必要となるので、全てを自動化するのはできないかもしれません。

また、本来なら不要でしたが、今回は試しにエビデンスも作ってみました。これは、画面テストを行った証拠としてスクリーンショットを残しておくというものです。今回は何の準備もなしにエビデンス作りを決行したので、スクリーンショット撮影からエクセルへ貼り付けまで多大な時間を要しました。少なくともエクセル貼り付けくらいは自動化できそうですが、確かにこの工程を丸々無くしたいという考えは理解できたような気がします・・・。


このように、今回のプロジェクトのテスト工程では、より効率的なテスト実行方法について考える良い機会となったと思います。


リリース


テスト工程において、目に見える不具合は全て取り除いたので、最終的にサービスのリリースまで到達できました。あとはシステムの使いよう次第ですが、この後に本番使用で挙がった不具合を保守する人員が決められるようです。

ということで、これにてシステム開発は完結です。


まとめ


この記事では、要件定義からシステムリリースまでの工程について、作業内容と反省点について簡単に紹介しました。

会社によって、どのようにシステム開発を行うのかは若干異なるかもしれませんが、大きな流れはあまり変わらないはずなので、今回の記事が誰かの役に立てれば嬉しいです。


以上です。