【ウォーターフォールを無視！？】：基本設計→製造した体験談と失敗から学んだこと
2025年1月に入社したT.Nと申します。
前職でもSES会社に所属しており、約3年開発の現場に参画しておりました。
珍しい開発工程を経験したため、実体験を基に記事を作成することにしました。
今回の作業でよかった点と失敗した点をまとめ、
この記事を読んだ方が同じ轍を踏まないことを祈ります。
■作業背景
基本的に開発する際、ウォーターフォール開発(※)で進めるのが主流だと思います。
(※)ウォーターフォール：要件定義→基本設計→詳細設計→製造→単体/結合テスト→リリースを
滝のように上流から下流へ順次進めていくシステム開発手法のことです。
現場によっては基本設計と詳細設計の間に概要設計を作成することもあります。
今回私が経験したのは、基本設計→製造する方法でした。
背景として、基本設計の作成時から大幅な仕様変更が発生し、詳細設計を作成する工数が
足りないと判断し、製造だけでもリリース日に間に合わせる必要があったためだと思われます。
そのため、期限までに製造→テストを間に合わせることが必須でした。
■失敗した作業の進め方
1.製造完了してから確認依頼。
確認後、「〇〇処理の前にチェック処理を入れて欲しい」などで手戻りが発生してしまった。
期限が短いため、手戻りが発生すると後続の作業(テスト)に影響が出てしまうため、
適宜確認しながら進めていくべきでした。。
2.メッセージ内容の確認。
テスト時、基本設計時に想定していないエラーが発生した際のメッセージ内容が
わかりにくいと指摘が入り、手戻りが発生してしまいました。
こちらも適宜確認しながら進めていくべきでした。。
3.見積工数の設定。
必要な工数は予測していたものの、手戻りが発生した際のリカバリー工数の見積もりが甘かった。
後々の作業(テスト)に割く時間が減ってしまいました。。
4.クラス(関数)の設定。
汎用性が低いクラス(関数)を作成したがために、修正に大幅な時間が掛かってしまった。
手戻り等のリカバリーが発生することを予測して汎用性の高いクラス(関数)を作成するべきでした。。
5.作業分担。
工数が足りなくなった場合、すぐに相談しましょう。
手戻りの発生により工数が足りなかったため、残業を増やして作業を進めていましたが、
作業分担できるものを探して、早めに作業を他の人に依頼するべきでした。。
私の場合、テストデータの作成を依頼して、時間を大幅に削減できました！！
また作業分担できるものが見つからない場合でも
相談すれば何かしらの対応ができるため、すぐに相談しましょう！
■個人的にやってよかった作業の進め方
1.最初にある程度の処理の流れを決めるため、処理フロー(※)を作成。
(※)処理フローとは：業務や作業の一連の流れを視覚的に表現したものになります。
処理フローを作成するメリットとして、どのくらいの処理が必要になるか、
一つの処理にどのくらいの工数が掛かりそうかをある程度把握したうえで進める事ができました。
2.処理が難しい箇所から製造。
予め工数が掛かりそうな処理をテキストファイルにまとめます。
テキストファイル例)
〇〇処理：1h
△△処理：1h
☆☆処理：2h
※必要工数も記載すると尚良いと思います。
工数を確認し、自分ひとりで工数内に製造できるかを見極める。
製造できたら◯、製造できないと判断したらテキストファイルに×印を付けておく。
テキストファイル例)
〇〇処理：1h・・・◯
△△処理：1h・・・×
☆☆処理：2h・・・×
最後に×の箇所をまとめて質問する。
※まとめて質問することで、他の作業者の時間を最小限に減らせます。
3.処理に悩んだらすぐに相談。
自分ひとりで悩んでも解決しないので、すぐに他の人に相談を心掛けました。
工数が限られている場合、止まっている時間が無駄になってしまいます。。
4.テスト項目の洗い出しを相談。
製造した人と設計書を書いた人の2人でテスト内容を洗い出すと、
製造した人が想定していなかったパターンでのテストが出ることがあります。
逆も然りで、設計書を書いた人が想定していなかったパターンのテストが出るため、
その後の処理をどうするかの認識を合わせられました。
5.処理の逐次実行
一つの処理を書いたら、その処理が通るか簡易データを用いて逐次実行しました。
一括で書いてエラーが発生した場合、どこでエラーが発生したか調査する必要があるため、
大きい機能だったため逐次処理が通るかの実行は行って正解でした。
■今回の作業を通して
詳細設計がないため、実際に製造完了してから確認する流れだと認識齟齬が生まれてしまう。
どんな状況でも適宜、報連相を忘れずに行うこと！
製造後の品質をより良いものにするためにも、上記の内容に気を付けながら進めてください。
