独学VBAerが開発部に異動して学んだ開発プロセス
こんにちは、みなとやです。
これまで私はVBAやGoogle Apps Scriptなどを使って業務改善ツールを独学で開発していました。しかしリリース後の事象があったりと課題も多く、開発プロセスを基礎から学びたくなり、昨年10月に社内公募で異動しました。社内アプリのディレクションに携わる中で、ひと通りの開発プロセスを経験したので、学んだことを整理してアウトプットしていきたいと思います。なお、開発プロセスは現場や会社によって微妙に異なるため、参考程度にご覧ください。
開発プロセスの基本
一般的に、システム開発の現場では「要件定義」「設計」「実装」「テスト」の流れで開発を進めます。それぞれの概要は以下の通りです。
要件定義
プロダクトの責任者であるプロダクトオーナー（以下PO）やディレクター（以下Dir）などで「なぜやりたいのか」「何をやりたいのか」といった要求を整理し、その要求を叶えるために何が必要か、システム的に必要な要件を整理します。スコープ定義やワイヤーフレームの作成、ワイヤーに基づいたUIデザイン、インタラクション設計などを行ったうえで仕様書にまとめ、開発段階で仕様変更が起こらないようにします。
設計
プログラマー（以下PG）がDB仕様やIF仕様などの内部設計を行い、要件定義に基づいてシステム的にどうやって実現するかを決める「基本設計」と、詳細な分岐パターンの整理やUMLを用いた内部設計を行い、基本設計に基づいてどうやってプログラムを書くかを決める「詳細設計」を行います。
実装
PGが詳細設計に基づいたコーディングと、それらの動作確認を行います。
テスト
PGがコーディングしたプログラムの品質を担保する「コードレビュー」や、コーディングしたものが意図通り動作するかの確認と、要件漏れがないことを担保するための「単体テスト」、個々に作成したプログラムを組み合わせた時、実業務と同様のユーザーシナリオでも期待通りに動作するかを担保するための「結合テスト」を行います。そしてPOやDirが要求通りに作られていることを確認する「受け入れテスト」など、複数のテストを行ったうえでリリースします。
大枠としては、上記の流れに従って進めますが、開発手法は現場や会社に応じて様々です。代表的な開発手法として「ウォーターフォール開発」「アジャイル開発」があります。
ウォーターフォール開発
要件定義からリリースまでの一連の工程を上流から下流まで順番に進める開発手法は、「ウォーターフォール」と呼ばれています。この手法は、流れる滝にたとえられ、1970年代から行われている歴史の長い開発手法です。シンプルで汎用性が高いため、日本では最もポピュラーな開発手法です。
アジャイル開発
「アジャイル」とは素早い、機敏なという意味で、アジャイル開発はソフトウェアの機敏な推進を実現する開発手法の総称です。大きな単位では区切らず、小さな単位で実装とテストを繰り返して開発を進めていくのが特徴で、「スクラム」「カンバン」「エクストリーム・プログラミング」など、アジャイル開発の中にも様々な手法があるようです。海外での調査によると、
・海外で調査したソフトウェア開発者10万1,500人のうち、86％近くがアジャイルを採用
https://cmc-japan.co.jp/blog/12-commonly-used-methods-of-agile-software-development/
とのことで、最もポピュラーな開発手法だそうです。
所属チームの開発のプロセス
異動後、私が所属したチームでは社内向けの申込書作成システムを作成しており、アジャイルのカンバン手法で開発を進めています。要件定義からリリースまでの流れをまとめてみました。
要件定義（PO/Dir）
開発プロセスの基本で記載したのと同様に、要件定義をおこないます。所属チームではプロジェクト管理ツール『Jira』にEpic（タスクを一定のジャンルでグルーピングしたもの）を作って、『Confluence』に概要やユーザー操作イメージ、修正対象画面、UI、発生する可能性のある条件分岐、エラー時の挙動、データパターン、テスト観点などの要件を整理してまとめ、仕様書をつくります。
基本設計/ストーリーポイント設定（開発PM/PG）
POやDirが仕様書をもとに概算見積りができる程度の説明をし、PGが要件定義に基づいてシステム的にどうやって実現するかを決める基本設計を行います。その上で次回着手する企画をすり合わせ、企画が決まったら、開発チームをまとめる開発PMが、PGに対してプランニングポーカーを実施してストーリーポイント(作業量)の見積もりを行います。
結合観点の作成（PG/QA）
仕様書に記述されている内容に沿っているか、機能要件と非機能要件に対する動作や振る舞いが適切かどうかを確認するため、品質担当のエンジニア（以下、QA）が結合観点を洗い出してExcelにまとめ、PGが確認します。
結合観点のレビュー（PO/Dir）
上記が仕様書に記述されている内容に沿っているかを、Dirが1次レビュー、POが2次レビューを行います。
実装（PG）
開発プロセスの基本で記載したのと同様に実装作業や「コードレビュー」「単体テスト」を行います。また、毎朝全員で進捗報告会を実施し、前日の作業報告や困りごとがあれば相談し、コミュニケーションを取ります。
結合テスト（PG/QA）
開発プロセスの基本で記載したのと同様に「結合テスト」を実施します。
受け入れテスト（PO/Dir）
開発プロセスの基本で記載したのと同様に「受け入れテスト」を実施します。
リリース日の調整/広報（PO/Dir/PG）
問題がなければ、PGとリリース日の調整を行い、社内にメンテナンス日時を広報します。
リリース（PO/Dir/PG）
利用ユーザーが作業していない時間帯にリリースします。リリース直後に担当PGとDirは初動確認を行い、連携先の社内システムにデータが反映されているかなどの動作確認をします。問題がなければ、社内にメンテナンス完了の投稿を行います。
振り返り会（PO/Dir/開発PM/PG/QA）
隔週金曜日に振り返り会を実施し、全員でKPTを行います。開発工程で問題があれば共通認識を持ち、翌週以降に選んだTryを実施して改善を図ります。
なぜこのようなプロセスを踏むのか
異動当初はなんでこんなに様々なプロセスを踏むのかと感じていました。これには理由があって、「V字モデル」と呼ばれる設計工程とテスト工程をリンクさせる考えに基づいているようです。
まず、実装したコードに問題がないかを「コードレビュー」を確認し、コーディングしたものが意図通り動作するかの確認と要件漏れがないかを「単体テスト」で確認します。更に、基本設計の際に作成した結合観点の通りに動作するかを「結合テスト」で確認し、最後に企画時の要求通りに作られていることを「受け入れテスト」で確認します。以上の流れで開発を進めることで合理的なテストを実施でき、事象を抑えた品質の良い機能をリリースできます。また、実装前の結合観点で何重にもレビューを行うことで、実装後に結合観点の漏れに気づいて開発が止まったり、追加の開発工数がかかったり、プロジェクトが遅延するのを防ぐ効果もあるようです。
感想
これまで独学でモノは作れるようになっていましたが、作り方が良くなかったと再認識した半年でした。異動して開発プロセスを経験し、基礎から学び直す機会を頂けて良かったです。
特に要件定義のフェーズでPOやDirであらゆるデータパターンやテスト観点を洗い出していても、結合観点の作成でPGのレビュー、QAのレビュー、Dirレビュー、POレビューと何重にも進める過程で、新たに気づけたテスト観点が多数ありました。様々な知見を持つメンバーで何重にもレビューを行うことで、実装前に品質の向上を図って事象が起こりにくくなり、安全にリリースすることができました。この経験を通じてチームワークの重要性を再認識し、協力して開発を進めることの大切さを学びました。前部署で携わった社内アプリやツールでも、今回のような進め方をしていれば事象は抑えられたのではと考えています。
また、ウォーターフォール開発のように定められた期間に複数の機能を盛り込んでリリースしてPDCAを回すことも多かったですが、途中で状況が変わって仕様変更になり、余計な工数をかける事もしばしばありました。アジャイル開発のように機能単位で少しずつ改善していく方が、途中の仕様変更や状況の変化にも対応しやすく良いと感じました。
開発プロセスやアジャイル開発の考え方は、開発以外のの業務でも同じようにアウトプット物の品質向上に取り組むことができると考えています。今後はなるべく様々な視点からの意見を取り入れて、少しずつ改善していこうと思います。
この記事が気に入ったらサポートをしてみませんか？