- ブログ
どんなプロジェクトでも大切なこと
2026.08.17 Mon

お久しぶりです。S.A.Tです。早いもので、前回の投稿から、1年近くが経ちました。
今回は、私が計3つの異なるプロジェクトにてテスト業務に取り組む中で、学んだことや感じたことを記していきたいと思います。
それぞれのプロジェクトでの働き方について
これまで、3つのプロジェクトで業務を行う中で、同じテスト業務であっても、プロジェクトによって仕事の進め方やコミュニケーションの取り方が大きく異なることに気づきました。
チームの規模や役割分担、開発担当者との関わり方が変われば、仕事をするうえで求められる意識や行動も変わります。
テスト業務担当エンジニアの視点から、それぞれのプロジェクトの違いを整理してみました。
| 比較項目 | プロジェクトA | プロジェクトB | プロジェクトC |
| チーム規模 | 少人数 リーダー1名 | 少人数 リーダー1名 | 大人数 リーダー複数名 |
| テストの進め方 | テストチームで テスト項目書を作成し、 テストを実施する | 一人で テスト項目書を作成し、 テストを実施する | テストチームで 作成済みのテスト項目書に 沿ってテストを実施する |
| 開発メンバーに相談する際の 連絡方法 | 直接のやり取りが中心 | 主にチャットで確認し、 状況に応じて 直接やり取りする | テストチーム内で 質問を取りまとめて、 リーダーが開発側へ確認する |
それぞれの環境で学んだこと
プロジェクトA
研修明けの初仕事となったプロジェクトAでは、少人数のチームで、テスト手順書の作成からテストの実施までを行いました。
疑問点や作業の方向性について、ミーティングですぐに確認できることが良いポイントで、メンバー同士で状況を共有しながら進めるため、認識のずれや作業の遅れにも気づきやすかったと思います。
ただし課題もあり、複数人で手順書を作成する場合は、それぞれが異なる考え方で作業を進めると、記載方法や内容にばらつきが生じてしまいます。
そのため作業を始める前にチーム内で方向性を決め、共通の認識を持つことが重要でした。
最初にリーダーへ方向性を確認し、実際の記載例となるテンプレートを作成しましました。メンバーが同じテンプレートを使って作業することで、できるだけ判断の軸がぶれないように工夫をしました。
この経験から、チームで仕事を進めるときは、最初に方向性やルールをそろえることが大切だと学びました。
プロジェクトB
プロジェクトBでは、基本的に一人でテスト手順書の作成からテストの実施までを担当しました。
自分で優先順位や作業手順を考え、工夫しながら効率的に仕事を進められる点は、この環境の良さでしたが、自分から発信しなければ、作業の進捗や抱えている問題が周囲に伝わりにくいという難しさもありました。
そのため、作業の節目ごとに進捗状況を上長へ報告しました。それから口頭での報告だけでは内容が曖昧になったり、記録が残らなかったりするため、必要に応じてチャットなどで文章に残し、後から確認できるようにしました。
開発担当者へ質問する際にも工夫が必要でした。チャットでは回答を得るまでに時間がかかる場合があるため、一度の質問で状況と確認したいことが伝わるように、内容を整理してから送ることを意識しました。
伝え方については、以前sinzさんが投稿した「伝えたつもりにならないために」も参考になると思います。
この経験から、一人で作業を担当している場合でも、進捗や問題を周囲へ伝えることが大切だと学びました。また、相手が状況を把握しやすいように情報を整理することも、仕事を円滑に進めるために必要だと感じました。
プロジェクトC
プロジェクトCでは、作成済みのテスト手順書に沿って、複数人のチームでテストを実施しました。
複数のリーダーがいるため、判断に迷った際に指示を仰ぎやすく、細かな疑問についてはテストチーム内ですぐに確認できます。多くのメンバーと協力しながら作業できることが、この環境の良さです。
ただし、気をつけなければならないこともあります。
テスト手順書があらかじめ作成されているため、作成者の意図や仕様の背景を正しく理解できていないと、認識のずれが生じることがあります。また、開発担当者への質問はテストチーム内で取りまとめて行うため、すぐに回答を得られないこともありました。
そこで私は、テストを始める前に仕様書と手順書を確認し、問題なく進められる部分と疑問点を整理するようにしました。自分の作業だけでなく、一緒にテストを実施するメンバーの進捗も把握し、必要に応じてフォローできるように意識しました。
開発担当者へ質問する際は、プロジェクトBでの経験を生かし、現在の状況と確認したい点を簡潔に整理しています。できるだけ少ないやり取りで解決できるよう、相手に伝わりやすい質問を作ることを心がけています。
この現場では、自分の担当作業だけでなく、チーム全体の進捗や周囲の状況を意識することの大切さを学びました。
3つプロジェクトで共通して大切だと感じたこと
3つのプロジェクトの体制の違いに戸惑いもありましたが、試行錯誤しながら働くなかで、共通して大切だと感じたことがあります。
それは、一人で働いているわけではない ということです。
当たり前に思えることですが、どのような環境であっても、この意識を持つことは大切だと考えています。
システム開発に携わる仕事では、一人ですべての作業を完結させることはできません。自分の作業の前後には別の人の作業があり、作成したものを確認する人や、その結果を受け取る人がいます。
短い進捗報告であっても、相手が状況を理解しやすいように書くことで、確認にかかる負担を減らせます。疑問点や問題を早めに共有すれば、作業が長時間滞ることを防げるかもしれません。また、自分だけでなく周囲の進捗にも目を向けることで、困っているメンバーをフォローできる場合もあります。
プロジェクトによって、仕事の進め方や連絡手段、求められる行動は異なります。だから自分の仕事が周囲の人とつながっていることを意識し、相手の立場を考えて行動することは、どのプロジェクトでも変わらず大切だと思います。
相手を意識した報告や質問、情報共有といった小さな行動の積み重ねが、チーム全体の円滑な作業につながり、最終的にはより良い成果物を作ることにつながると考えています。
今回は、3つのプロジェクトでの経験を振り返り、それぞれの違いと、共通して意識すべきことについて考えてみました。
これまでの経験を文章にすることで、自分が仕事をするうえで大切にしたい考えを、改めて整理することができました。
次回の記事をいつ、どのような内容で書くかはまだ決まっていません。今回のように働くことについて書くのか、それともサッカーについて趣味全開で書くのか、少しずつ考えていきたいと思います。
最後までお読みいただき、ありがとうございました。S.A.Tでした。