システムエンジニア（SE）の仕事ってなに？

僕が友達や親戚等と飲んでるとシステムエンジニアってどんな仕事？と言われる事がある。
この場を借りて説明しようと思う。

システムエンジニアを一言で定義すると「システムを作る人」と言っても意味が分からないだろう。
だが、僕は説明が面倒なの時にはこのように話す。
それでも食い下がって聞いてくる場合はもう少しまじめに話す。「POSレジシステムを作ったり指紋認証システムを作ったりしてるんだ。」と・・・。

まぁ、それをきてもよく分からない仕事なんだけど。
基本的には今まで人が行っていた部分を効率化（自動化）するものがシステムである。では、その為にはどのような事が必要であるかを考えてみる。

１．効率化したい事を纏める（依頼側の仕事）

そもそも何をどう効率化したいかと言う事は依頼側が考える事です。（というか、依頼側でしか考えれません。）
「周りがシステム化を行っているからシステム化を行う」等の不純な動機でシステム化を進めても効果がでにく、逆効果になる場合が多いです。どのような事を自動化したいのか検討してそれを請負側に説明する必要があります。
しかし、依頼側はどのようなものが自動化出来るかを知らない場合が多くこの部分を他の会社に任せがちです。しかし、業務を一番知っているのが依頼側なのでこの部分を纏める事を他の会社に任せてしまうと意図と違うものが出来る可能性が出てきます。（これは現場を知らないマネージャー等が行っても同様の結果になります。）
なので、経営者がITに弱いのとITで効率化と言う観点では致命的になる場合があります。（自社のオリジナルで戦ってるうちは良いのですが、競合等が出てきて飽和状態になった場合はITを駆使してコストを下げる戦略がとられます。その際に、ある程度の知識を付けておく事が重要になります。）

※次に書く要求定義を行う人が優秀な場合は経営者にITの知識が多少欠けていても効率的なシステムが出来る場合があります。（もちろん、逆の場合もあり要求定義を行う人が無能な場合は経営者にITの知識があっても上手く行かない場合があります。）しかしIT導入をこのような博打に頼ってしまう事は経営者としては不本意な状況だろう。

※無能な人に限って言い訳がうまく（言い訳がうまいので商売が成り立っていると言っても良いくらい本当に上手い）最終的に無駄な投資をしている場合があります。（システムは作成コストも導入コストもかかるため少ししないと効果が出ない場合があります。）

２．効率したい内容を引き出す（要求定義）

先にも書いたようにお客様がITに明るいとは限らない。と言うより、明るくない場合の方が多い。（たまに異常に詳しい人がいて、それはそれで大変だったりもするw）そうなると依頼側が何を効率化したいのかを引き出す必要がある。ここで重要なのは詳細については詰めない事である。（細かいところまで話を進めるとドツボにハマる場合がある。）
依頼側がITに明るくない場合は、概念として「この作業がこうなると効率化されますよね？」と言うように一つ一つの作業をどのように自動化するかを決めて行く事にある。（なので依頼側は作業を纏める必要がある。）
何が自動化されるとどのような効果が出るかまで想定出来ればかなり良い要求定義となる。

ここで引き出しきれないと、システムが出来つつある時に「あれ？この部分は自動化されないの？自動化されると思ってたんだけど。あの時に言わなかった？」と言う状況に陥る事がある。どんなに要求を上手く引き出せても、このような事は必ず起こる。なので最小限にとどめるか、初期のうちに依頼側に思い出してもらう方法がある。それがウォータフォール型の考えとアジャイル型の考えになる。

※ウォーターフォール型はとにかくミスを無くして一つ一つ堅実に潰して行こうと言う完璧主義な方法。一方でアジャイル型は小さい機能をすぐに作ってどんどん依頼側に確認してもらいながら進めようと言う確認型の方法。

３．作業内容をコミットする（要件定義）

ウォータフォール型とアジャイル型では方法が違いますが、ここフェーズでどの部分を自動化するかをお互いで合意をとります。１と２で話した内容から要求を要件に変えます。（この要件が元になって○個の要件があるから幾らと言う契約を結ぶケースが殆どになります。）
ただし、この要件定義には幾つかの問題をはらんでいます。

(1)本当に作れるか分からない。
この時点では要求を要件に変えただけなので、本当に作れるかどうかは不明です。後述しますが、作る為にかかる金額も分からない場合が多いです。
この要件定義を行う際にある程度の設計技術を持っていると「本当に作れるのか/どれにどれくらいの金額がかかるか等」を算出できるので見積としての信頼性が高いものが出来ます。

(2)依頼側はそれが妥当であるか判断出来ない。
色々要件を突き出されても、それを作ってもらっても依頼側の要求を満たせる事項であるのかを判断する事が出来ない。すなわちそれは、不利益を被る要件（作った後で幾らでも言い訳されてしまうようなもの）でも呑んでしまう可能性をがある。
また、逆に要件の重みが分からず無茶を言ってしまいいらない機能がついたりもの自体が出来ない場合があるのだ。

※基本的にこの要件で契約を結ぶ方法は双方に不利益を出す場合が多く、現在はこのフェーズで契約を結ぶ事は見直されつつあります。（官公庁や金融系等のお堅いところではまだこの動きがあまりない。）
⇒アジャイル型では都度都度依頼側に確認をして作るため、このような契約を行う事はあまりありません。

4．実際にどうやって作るかを検討する（設計）

要件が決まるといよいよ本当に作れるのかを本気で検討します。（要件定義でもある程度は検討します。要件定義の時点で本気で検討しろと言われそうですが、要件定義で本気で検討を行うと要件定義をした時点で機能が出来ていると言う状態になってしまうくらい時間がかかってしまうのです。）
この設計によってシステムの出来が決まると言うくらい重要な部分である。また、この時点で作られr他設計書が実装する際の仕事量を決める重要な仕事である。それだけ重要な部分で難しいためこれが出来る人は殆ど居ないのです。（出来ていると思う人は大勢居るが・・・。）
このフェーズが難しい理由は以下になる。

(1)要件定義に矛盾がある。
要件定義を元に設計をしてみると一つ一つの要件には矛盾が無いが、つなげて考えると矛盾が発生する事がある。これは当たり前の事で、一連の業務を矛盾無く行っている会社は皆無であり何かしらアドリブで業務を遂行している部分が存在するからである。そのアドリブの部分（イレギュラーな部分）を設計しようとすると矛盾に突き当たるのだ。（なので要件定義をする場合には設計技術がある方が圧倒的にスムーズに行くのである。）
こうなると、再度依頼側に要件の確認をすると言う作業が発生する。

(2)技術的な問題が解決出来ない。
要件定義を行う人は設計技術があった方が良いと書いた。設計技術についても同様で実装技術がある事が望ましい。その理由は、実際に実装出来ない設計書を書いても「絵に描いた餅」になってしまうのだ。
この設計者は普通の実装能力よりも広い知識を必要としており、要件と要件を技術的にどのようにつなげるかを考える事が難しく矛盾を生みやすい。

(3)イレギュラーケースの洗い出し。
一般業務ではイレギュラーが発生してもその場の人間が対応するが、システムではそうは行かない。時には本当に天文学的な確率でしか起こらないような事でも対応する設計を考えなければならない。
そして、このイレギュラーケースを考えるのが難しく時には依頼側に「このようなケースの場合はどうやって対応してますか？そもそもこんなケースって今まで発生した事がありますか？」と聞きに行かなければならない。
業務もろくに知らない場合は、このイレギュラーケースを考えだすのはとても困難になるのだ。
ただ、この部分は設計者よりも実装者の方が気づきやすく設計した後にイレギュラーケースによって設計自体が全てやり直しと言う話も珍しくない。

(4)説明能力が必要になる。
プログラムには「だいたい」とか「普通なら」と言う事が一切通じない。厳格に物事を決める必要がある。なので、実装者には正しく細かく説明をしなければならない。すなわち、通常の会議以上に慎重に物事を早く正確に伝える説明能力が必要になる。
実装者は今まで経緯や業務について知らない場合が多いので、業務を考えれば当たり前の事でも説明する必要がある。（優れた説明者は背景や業務についての説明が上手く、ある程度実装者が自分で考えれるような知識を与えてから設計について話す。
この説明についても一度実装をしていれば、どう説明されれば実装しやすいかが分かるので設計者は実装経験が必須となる。

５．実装する（プログラマー）

「IT業界＝プログラム」と思う人はかなりいると思う。まさにその部分がこのフェーズである。しかし、ここまで読んでいただければ分かる通りここまでの道のりは険しく遠い。それだけ、IT業界と一言で言っても様々な仕事があるのだ。
実装者は今まで考えたものを実際に作り上げる人である。

これらの記事を読んでいれば分かると思うが、一番しわ寄せがくるフェーズである。今まで考慮して出来た矛盾がどばっと発生し、設計や要件定義まで巻き戻るような事がどばどば出てくるのだ。
何はともあれ、上記でも書いたようにプログラムには融通が利かない。その融通が聞かない言葉を覚えなければ実装は出来ない。それがプログラムである。（僕が一番好きなフェーズである。）そして、そのプログラムを使って今まで考えた事を実装するのがプログラマーなのだ。
蛇足だが、このフェーズが一番外部の人を入れる事が多い。

プログラムをする際に起こる問題はあまりに多い為、幾つか目を引きそうな問題を上げる。

(1)プログラム能力が無い人が多い
意外だと思われるかもしれないが、プログラム能力が無い人がこの実装を行っている場合は非常に多い。そもそもプログラムを基礎（本や講座等）から学んだ人が少なく独学で学んだりそもそも全く出来ない人がいる為、出だしの一歩で破綻する場合がある。
多くのプロジェクトではエースプログラマー（僕もプログラムだけをやってた時代はこう呼ばれてた）と呼ばれる人々が主力プログラムを書いてピンチを切り抜けると言う事が珍しくないのだ。
⇒逆に素人プログラマーは居ると生産性を大きく下げる（他人の邪魔になる）場合がある。

なぜこのような状況になっているかと言うと、そもそも小学校～大学までの間にプログラムを学ぶ機会が殆ど無いためである。社会人になってから本を買って勉強している人は基礎力も付くが、基礎力を付ける必要がある時期を無駄にしてしまうケースが殆どなのだ。（会社自体でも教育機関がしっかりしていないため）

(2)矛盾を全て解決する必要がある。
今まで書いている通り、要件定義や設計では矛盾を生みやすい。（そもそも業務に矛盾があるため）その矛盾が表面化するフェーズがここである。（実装が弱い時はテストフェーズで見つかる場合もあるが、テストフェーズで多くの矛盾が表面化した場合はそのプロジェクトは失敗である。）
「このケースとこのケースを実装して組み合わせるとおかしな事に！」で設計者に確認すると要件の確認になって、依頼側に問い合わせ・・・なんて光景も珍しくない。
あと、往々にして起こるのが作った設計書が殆ど役に立たず実装者が再度設計をし直すと言う事。設計者が実装経験があればそのような事も若干減るが、設計者が実装経験が無ければ殆どは無駄な資料を作っていただけになる。

(3)仕事の仕方を知っている人が少ない。
１や２のような事があり思い通りに仕事が進まないと、想定していた時間をあっという間に使ってしまう。そこで時間を使い切ると人を増員する。増員した人は説明から始めなければならない為、説明に余計時間を取られて・・・。
実装フェーズってとっても忙しいイメージがあって、毎日徹夜しているプログラマーと思われるかもしれない。しかし、実際は人の使い方を学んでない人が指示をしているだけでやっている事の殆どが無駄な事だったりもする為、忙しい振りをしているだけの人も結構居る。周りが帰らないから何となく残業してみるとかとても多いです。
でも、これはそもそも仕事の采配が間違っている為に起こる。

(4)パーキンソンの法則が当てはまる。
混沌としている為か、凄くパーキンソンの法則通りの時間の使い方を・・・。これ以上書くと止めどなくなるので、この辺でやめておきます。

これ以外にもテスト工程がある。しかし、ここでテストの事まで書いてしまうと今までの書面と同じくらいの記事を書く必要があるので今回は割愛する。

なんだか最後の方は問題だけを提起している気がしてきたが、、、
実際のところ、このように書いたのはあくまで一例であり現場毎によって仕事の仕方は全然違ったりもする。（上記の進め方は結構スタンダードである。しかし、スタンダードが良いわけではない。この業界はまだまだ成熟していないため「この方法が一番良い！」みたいなプロセスはまだまだ出来ない。）

・・・何となくシステムエンジニアの仕事が伝わっただろうか？

※注
何かを作り出す場合は１の部分が企画に変わる。

P.S.
今度は僕が実際に仕事をしていた現場の実態でも書こうかと思う。