「エンジニアって、Excelばかり使っているって本当？」
「SEなのに、プログラミングはしないの？」
そう疑問に感じている方も多いのではないでしょうか。
私は文系・IT未経験からIT企業に新卒で入社し、今は新人SEとして働いています。
研修とOJTを経て、
今はプロジェクトで画面内結合テストを担当しています。
結論から言うと、エンジニアはExcelばかりです。
少なくとも今の私の仕事は、7割くらいがExcel作業です。
この記事では、エンジニアがExcelを使う理由、Excel作業を正直どう感じているのかを、
実体験をもとに紹介します。
結論｜エンジニアはExcelばかり。新人SEの今の仕事は7割がExcel作業
入社前は、エンジニアといえばプログラミングをする仕事だと思っていました。
しかし実際は、Excelを触っている時間のほうが圧倒的に長いです。
OJT期間はExcel作業が3割くらいでしたが、
10月にプロジェクトへ配属されてからは、7割くらいがExcel作業になりました。
テストケースを確認し、テスト結果のスクショをExcelに貼り、
手順書をExcelで作る。
そんな毎日です。
正直に言うと、Excel作業はあまり好きではありません。
ただ、Excelはエンジニアから離れても、
どこでも使えるスキルです。
使いこなせるかどうかで、仕事のスピードにも差が出ると感じています。
SEの仕事内容とExcel作業の割合
SEの仕事はプログラミングだけではない
SE（システムエンジニア）の仕事は、プログラミングだけではありません。
システム開発は、大きく次のような流れで進みます。
1.要件定義：お客様が「どんなシステムを作りたいか」を聞いて、まとめる
2.設計：画面や機能、データの持ち方などを決めて、設計書を作る
3.製造：設計書をもとに、プログラミングをする
4.テスト：作ったシステムが設計どおりに動くかを確かめる
この中で、プログラミングをするのは「製造」の部分だけです。
それ以外の工程では、設計書やテストの資料を作る作業が中心になります。
そして、その資料の多くはExcelで作られています。
新人SEは、この中の「製造」や「テスト」を担当することが多いです。
私も今は、テストを担当しています。
OJTは3割、プロジェクト配属後は7割がExcel
私のExcel作業の割合は、時期によって大きく変わりました。
| 時期 | Excel作業の割合 | 主な仕事 |
|---|---|---|
| OJT期間（6～9月） | 約3割 | 社内システムの画面の製造、単体テスト |
| プロジェクト配属後（10月～） | 約7割 | 画面内結合テスト、エビデンス作成、手順書作成 |
OJT期間は、訓練・勉強という側面が強かったです。
そのため、プログラミングや画面の動きの確認、設計書を読み込む時間に、
多くの時間を使えました。単体テストもありましたが、
全体で見ると、Excel作業は3割くらいでした。
一方、プロジェクトに配属されてからは、お客様に出すシステムなので、
テストの比重がそもそも大きくなりました。
私はプロジェクトの手助けするチームの一員として、
300画面ほどあるうちの1画面の動きをテストしています。
※1日の流れは、
エンジニアの1日の仕事内容は？新卒1年目のリアルなスケジュールを紹介
で紹介しています。
エンジニアがExcelでやっている仕事内容
では、エンジニアはExcelで具体的に何をしているのでしょうか。
私が実際に使っているExcelを紹介します。
テストケース一覧
テストケース一覧は、「どんなテストをするか」をまとめたExcelです。
今のプロジェクトのテストケース一覧は、次の4つのシートでできています。
| シート | 中身 |
|---|---|
| 対象と前提シート | テストする画面の概要、ログインするユーザー、事前に投入するテストデータ |
| テストケースシート | テストの内容（1行に1ケース） |
| 網羅シート | 確認すべき観点を、どのくらいテストできたか |
| 要確認シート | 今回はテストしない箇所と、その理由・注意事項 |
その中でも、「テストケース」シートには、次のような列があります。
- ケースID、ケース名、優先度（高・中・低）
- 観点（見た目、実際のデータ、ログインしていない場合、権限がない場合など）
- 前提、テストデータ、操作
- 期待する画面、期待する通信の結果
- 実施結果（1回目・再実施）、備考
1つの画面だけでも、10ケース以上あります。
「対象と前提」シートには、テストデータを投入するためのSQL文まで書かれています。
私は、このテストケースを読んで、書かれている操作どおりに画面を動かし、
期待どおりの結果になるかを確認しています。
エビデンス
エビデンスとは、「テストをちゃんと実施した」という証拠のことです。
テストをしたときの画面のスクリーンショットを撮って、Excelに貼っていきます。
作業の流れは、次のとおりです。
- テストケースを読む
- 画面を操作する
- 必要に応じて、ブラウザの検証ツールや
A5:SQL（データベースの中身を確認するツール）で確認する - スクリーンショットを撮る
- Excelに貼り、確認した場所を赤枠で囲む
まとめ方は、プロジェクトによって違います。
前のプロジェクトでは、「初期表示」「画面イベント」「入力チェック」などに分けて、
10枚くらいのエビデンスを貼っていました。
テスト項目は、例えば次のような書き方で、1つずつ○を付けていきます。
- 画面上部にタイトルと戻るボタンが表示されること
- 対応内容が空白のみの場合、送信ボタンが押せないこと
- 対応内容に500文字入力でき、501文字目は入力されないこと
1画面で24項目ほどありました。
今のプロジェクトでは、1シートに1テストケースで、シートをどんどん増やしていく形です。
手順書には、次のようなルールが決められています。
- シート名はテストケースの番号にする。NGの場合は「番号_（NG）」にして、シートの見出しを赤にする
- 検索系の画面は、デザイナーが作った見本の画面と、実際の画面を左右に並べて貼る
- エビデンスは、操作の手順ごと・期待する画面ごとに残す（1ケースで6枚になることもある）
- データを登録・更新するテストでは、テスト前とテスト後のデータベースの中身をExcelなどに出力して、並べて貼る
1つの画面のエビデンスで、スクリーンショットが60枚ほどになることもあります。
テストでNG（バグ）が見つかったら、課題管理ツールでチケットを発行します。
件名や担当者、優先度、期限日などを決められた書き方で入力し、
実装担当の人とやり取りして修正してもらいます。
手順書・WBS
ほかにも、次のようなExcelを使っています。
- 手順書：環境構築や結合テストのやり方をまとめたもの
- WBS：プロジェクトの作業と、その期限や作業時間を管理するもの
前のプロジェクトでは課題管理表もありましたし、
OJTのときは、日報や作業時間を記録するのにもExcelを使っていました。
※環境構築の手順書については、
環境構築は難しい？新人エンジニアが苦戦したポイントを実体験から解説
で紹介しています。
SEがテストばかり・Excelばかりになる理由
お客様に出すシステムは、テストが重要だから
SEがテストばかりになる一番の理由は、お客様に出すシステムでは、
テストがとても重要だからです。
お客様に納品したあとにバグが見つかると、大きな問題になります。
そのため、プロジェクトではテストに多くの時間をかけます。
新人は、まずそのテストを任されることが多いです。
そして、テストの内容や結果を記録するのに使われるのが、Excelです。
テストばかりになると、自然とExcelばかりになります。
昔からの慣習で、インストール不要・誰でも開けて共同作業もできるから
Excelが使われる理由は、次のようなものだと思います。
- 昔からの慣習：IT業界では、昔からExcelで資料を作る文化がある
- インストール不要なことが多い：多くの会社のPCに最初から入っていて、
すぐに作業ツールとして使える
- セキュリティの面：新しいツールを入れるよりも、安心して使える
- 共同作業ができる：他の人と一緒にファイルを編集できる
ただ、個人的には、もっと使いやすいツールを使いたいというのが本音です。
正直、Excel作業は好き？嫌い？
テストは好き寄り。でもExcelは使いづらすぎる
正直に言うと、Excel作業はあまり好きではありません。
テスト自体は、どちらかというと好きです。
画面を動かして、期待どおりに動くかを確かめる作業は、嫌いではありません。
ただ、Excelが使いづらすぎます。
直感的に作業しにくく、分からないことを1個1個AIに聞かないといけません。
エビデンスに写真や吹き出しを付けようとしても、
パワポよりも画像や図形が扱いづらいです。
前のプロジェクトでは、一度パワポに貼り付けて加工してから、
Excelに貼り付けていたくらいです。
写真や表の調整で何時間も失い、レビューでは細かく指摘される
Excel作業では、平気で何時間も失ってしまいます。
写真の大きさを調整したり、表を整えたりするだけで、
何時間もかかることもあります。
作ったエビデンスは、3年目くらいの直属の上司にレビューしてもらいます。
レビューでは、かなり細かく指摘されます。
- 画面の縮小率がそろっているか
- 写真の大きさが適切か
- 赤枠がきちんと確認箇所に合っているか
エビデンスを見やすくするために必要なことなので、
最初だから指摘が多いのだとは思います。
ただ、半年経っても未だに上手く使いこなせないのは、嫌な点です。
プログラミングと違い、自分のペースで進めにくい
OJTでプログラミングをしていたときは、個人作業だったので、
ある程度自分のペースで仕事ができました。
一方、今のテスト・Excel作業は、プロジェクトのお作法に従う必要があります。
通話しながら画面共有して教わることも多く、自分のペースを作りにくいです。
上司が忙しいとチャットも返ってきにくくなるので、
モチベーションを保ちにくいと少しだけ感じることもあります。
Excel中心の業務で学べること・限界
手順書を作ると、DBやミドルウェアのつながりが分かる
Excel中心の業務でも、学べることはあります。
特に勉強になったのは、環境構築の手順書を作ったときです。
人に教えるための資料なので、自分が深く理解していないと書けません。
そのおかげで、DBやミドルウェアがそれぞれどのようにつながっているのか、
イメージできるようになりました。
テストだけでは、理解できることに限りがある
一方で、限界もあると感じています。
テストでは、コードやコマンドをそんなに打つわけではありません。
画面の動きを何回見ても、理解できることは限られていると思います。
テストの経験は、ある程度にとどめておくのがいいのかなと考えています。
プロジェクトにいる間は、Excel作業が多い状態が続くと思います。
やりがいを求めるなら、請負のプロジェクトにいるのがいいのかもしれません。
使いこなせると差がつく
Excelは、使いこなせるかどうかで差が出ます。
私の上司は、手順書を作るのがかなり早いです。
私も、少しずつ便利な使い方を覚えています。
- Altキー：Altキーを押しながら図形や画像を動かすと、セルの枠にぴったり合わせられる
- オブジェクトの選択：「検索と選択」の「オブジェクトの選択」を使うと、図形を一気に選択できる
- AIの活用：テストケースが読み取りにくいときは、
会社が許可しているAIにExcelを読み込ませて、分かりやすく説明してもらう
嫌々やるのではなく、ショートカットキーなどを覚えながら進めるのがいいと思います。
エンジニアのExcelに関するQ&A
SEなのにプログラミングしないのは普通？
普通だと思います。
SEの仕事は、要件定義・設計・製造・テストと幅広く、
プログラミングをするのはその一部です。
特にお客様に出すシステムでは、テストに多くの時間をかけるので、
新人はテストやExcel作業が中心になることも多いです。
Excelが嫌いでもエンジニアになれる？
なれます。私もExcelはあまり好きではありませんが、
エンジニアとして働けています。
ただ、エンジニアはExcelを使う場面がとても多いです。
嫌いでも、ある程度は使えるようにしておくと、仕事がかなり楽になります。
文系でもSEの仕事についていける？
ついていけると思います。
私も文系・IT未経験から入社しましたが、研修とOJTを経て、今はプロジェクトで働いています。
むしろExcelについては、学生の頃から使っている人のほうが有利です。
文系・理系はあまり関係ありません。
※文系からSEになった体験は、
で紹介しています。
就活生は、入社前にExcelを勉強しておくべき？
入社前に、特別にやっておくべきことはありません。
気が向いたら、家計簿などをExcelで付けてみるくらいで十分だと思います。
ただ、パワポやWordよりは、死ぬほど使います。
それだけは覚えておくといいと思います。
まとめ｜Excelはエンジニアの必須スキル。使いこなせると差がつく
エンジニアはExcelばかりです。新人SEの私の今の仕事は、7割がExcel作業です。
お客様に出すシステムではテストが重要なので、
テストケースの確認やエビデンスの作成、手順書の作成など、
Excelを使う仕事が自然と多くなります。
正直、Excelは使いづらく、好きではありません。
ただ、Excelはエンジニアから離れても、どこでも使える知識です。
使いこなせるかどうかで、仕事のスピードにも差が出ます。
これからエンジニアを目指す方は、
「エンジニアはプログラミングだけの仕事ではない」ということを知っておくと
、入社後のギャップが少なくなると思います。
この記事が、エンジニアの仕事内容をイメージする参考になれば幸いです。
コメント