駒鳥です。
いくつかのエントリーで書いてるのですが、僕は以前SIerと呼ばれる界隈でSEをやっていました。
その後、アプリやWEBを自社開発している会社に転職したのですが、転職したことで圧倒的にやらなくなった仕事があります。
それが、Excelを使った作業です。
SEの仕事は、どういうわけかExcelを使った作業が多いのです。
SEはExcelで何をしているのか。Excel職人と揶揄される実態
SEは、Excel職人と揶揄されることがあります。
プログラミングよりもExcelで作業をすることが多く、ソースコードよりもExcel書いた量の方が多い、という状況も珍しくないためです。
Excel職人と揶揄されるその実態はどんなものだったのか。
当時、SEであった僕がExcelで何をしていたのかで考えてみます。
いくつかあるのですが、大きくは２つです。
- 仕様書をExcelで作成する作業
- テストのエビデンスをまとめる作業
仕様書は全てExcelで作っていた
SE、SIerはシステムを開発、活用することでクライアントの課題を解決することがその存在意義です。
しかしながら、ただ開発そのものだけをするのではなく、その前後でExcelを使って仕様書を作り、それを納品しています。
仕様書、というのもウォータフォールの考え方に則るといくつかあって、
設計書（基本設計書、詳細設計書、など段階の異なる仕様書が複数存在する）
テスト仕様書（これも単体テスト、結合テスト、など複数の段階が存在）
が存在します。
設計書はExcelではなくWordで作成している現場もありましたが、僕が経験したのはExcelオンリーです。
この設計書に何を書くかというと、例えばシステムの要件をまとめていたり、画面であればどんな項目が表示され、またインプット可能かをまとめたものです。
Excelというのは、本来の用途からは外れますが、シートをページや章に見立てたり、方眼紙のように扱うことでレイアウトが手軽に作成できるという特徴があります。
つまりドキュメントを作成するのに便利なツールとして利用されている、というわけです。
この場合、本来の表計算としての機能はほぼ使われません。
ウォータフォールでの開発をするにあたって、要件定義から開発に入るまで、ほぼほぼこのExcelで設計書を作るというのが仕事の大半を占めていました。
作成したExcelファイルは、設計書、仕様書として最終的に納品される成果物なので、ある程度作り込むことが求められました。
そして作成した設計書に対応する形で、記載された内容を見たいしているかどうか、確認観点をまとめたテスト仕様書が作成されます。
当然ながらこれもExcelで作ります。
プロジェクトによりますが、多くの画面を持つシステムを構築するような場合、画面１つずつに設計書とテスト仕様書が同時に存在することになります。
このどちらも、やはり納品する成果物です。
テストのエビデンスは、スクリーンショットをひたすら貼ったExcel
さて、実際にプログラムの実装が完了したら、単体テスト、そのあとは結合テスト、と検証を進めていかなくてはなりません。
そして、その工程の成果物として、テストのエビデンスを作成していきます。もちろんExcelです。
これは何をするかというと、プログラムが意図した通りの挙動をすることを証明していく、まさにエビデンスの作成というわけです。
例えば、あるフォーム画面を作成する際のことを考えてみましょう。
入力した値によって挙動が異なる、バリデーションチェックのような処理があったとします。
まずフォームに、想定される文字列を入れた状態の画面をスクリーンショットで保存し、Excelに貼り付けます。
そのあと、エンターなどを押して処理が想定通りに動いたあとの画面をスクリーンショットで保存し、やはりExcelに貼り付けます。
次に異常系のテストです。桁が少なかったり、禁止文字が含まれる文字列を入れた状態の画面をスクリーンショットで保存しExcelにはります。
エンターを押して、バリデーションチェックによってエラーが出た画面をスクリーンショットで（以下略）
と、こんな感じでひたすら動作確認をしては、画面をスクリーンショットで保存してExcelに貼る、という作業を繰り返します。
これは、プログラムがちゃんと機能していますよ、という証拠（エビデンス）であると同時に、ちゃんと検証という作業を行なっていますよ、という証拠（エビデンス）でもあるのです。
当然、このExcelファイルも成果物として納品しなくてはなりません。
気がつけば、仕様書と合わせて膨大な量のExcelファイルが出来上がっています。
「これ誰が見るんだろう」と考えながら、ひたすらスクリーンショットをペタペタと貼っていた過去が懐かしい。無論戻りたくはないですが。
いったいなぜ、こうなってしまっているのか。
なぜSE,SIerと呼ばれる人の仕事は、Excelで作業するものが多いのか。
当然一概には言えないものの、僕なりに言語化すると、そういうビジネスモデルだから、という結論になると思っています。
クライアントから、元請けとなるSIerやコンサル、そして二次受けとなるSEへとお金が流れていくわけですが、下流へ行けばいくほど、その売り上げは、システムやプロダクトそのものの価値ではなく作業工数で計算されることが多くなります。
人月に基づく、労働集約型のビジネスモデルは、今も多くのSE・SIerに支持されています。
内容ではなく、作業のボリュームが大きいほど、売り上げが大きくなるというロジックですね。
であれば。
実際開発作業だけだとそんなに工数のかからないシステムの構築であったとしても、その前後に仕様書のような手のかかる物を作成する工数を乗せてしまう方が売り上げは大きくなります。
作成したExcelファイルは成果物として納品する。
この１連をパッケージ化してしまっているのが、今のSE、SIerに多く見られるビジネスモデルです。
下請け、外注当たり前であるからこそドキュメントの重要度が高くなっている
このビジネスモデルに起因していますが、上述の通りSIerの世界では、下請けや外注が当たり前です。
複数の企業がプロジェクトに絡んでくると、その分情報伝達をする機会が増えます。
口頭で伝えていていては事故がおきます。
すでに決まっている仕様はドキュメントとして残しておき、また各企業の責任を明確にしておくことが、正しくプロジェクトを完遂するためには必要になります。
ただ、実際は、それが形骸化してしまっている、というのが今のSIerで起きていることです。
これらの状況のため、実際の作業者であるSEには、プログラミングよりもExcelでの作業の時間の方が大きい、という状況が生まれるのではないか、というのが僕の考えです。
今、僕が務めている会社も、SIer出身のエンジニアが大勢います。
彼らに、SIerのころExcelの作業多かったんだよねーという話をすると、大抵の場合共感を得られます。
プログラミング、物作りがしたかったのに、Excelばっかりで嫌になった。
そう感じて転職に至る人も多くいて、かつこのモデルは（これまでも変わってきていないように）しばらくは変わらないでしょう。
Excelでの業務ばかりで辛い、と感じたら、早めの転職をお勧めします。
それでは。
★転職の際に活用したい、オススメエージェントサービス3選★
