とある時期から今の会社に仕事が決まって、一定の期間が経ちます。
今の会社に決まるまでは、「ExcelVBA」や「AccessVBA」といったプログラミング言語を勉強してきたといった記事をいくつも書いてきました。
自分もそろそろ頃合かなとは思っていました。この「頃合」というのは自分的にいろいろ意味があって、プログラミングの知識もそこそこ蓄積してきたという感覚もありましたし、自分の人生の中でも新しいことをやりたいという気持ちもありました。
そういった状況、気持ちの中で、世の中は人手不足になっているからということもあるとは思うのですが、運よくExcelVBAを使う仕事に就くことができました。
今の仕事に就く前は、「自分もそろそろいい年齢になってきているし、今までとは全然違う職種だし大丈夫だろうか・・・」といった気持ちもありましたが、やってみるものですね。
しかし、当初はもっと簡単な仕事だと思っていました。「ExcelVBAで業務改善」する仕事なので、「これは今まで勉強してきたExcelVBAの知識を生かせるじゃないか」ということでやる気に満ち溢れていたわけです。
これは誰でもあると思うのですが、壁にぶつかったというか、「えっ？ここまで専門的にやる必要があったの？」と思った部分があったので、今回はそのことについて感じたことを書いてみたいと思います。
今の会社に入る前はExcelVBAなどのプログラミングの知識だけで良いと思っていた。
今だからこそ言えることですが、「新卒でSEになれなくて良かった」と思うようになりました。
自分が大学生で就職活動していたときは、「SE」とか「プログラマー」になってIT業界で働きたいと思っていました。当時の自分は「将来は絶対この分野が伸びる」「すごく面白い」という風にインターネットやITというものに非常に未来を感じていたからです。
けれども、歴史的な大不況の影響や自分の勉強不足もあったとは思いますが、涙を呑んで別の仕事に就くことになりました。あの時は本当に悔しくて仕方ありませんでした。
今だからこそわかることですが、じゃああの時すんなり希望の業種で希望の職種に就けたとして上手くいったか、と考えた場合「それは絶対ないな」と胸を張って言えます。
というのも、当時の自分は何らかのプログラミング言語をちょっとでも勉強していた、という訳ではありませんでしたし、何より「要件定義」とか「仕様書の書き方」といったSEの上流工程の知識や概念が全然なかったからです。
また、新卒でSEになれてしまったら経理や人事、総務などの事務的な仕事の現場の仕事内容もわからないので、そういった状況ではつくれるシステムにも限界があったかもしれません。
自分はこのブログの過去記事で書いてきているように、いくつか会社を経験してきましたが、SEを辞めた経験がある人に会ったのは一度や二度ではありません。
その時は不思議に思っていました。自分の新卒の時のSEやプログラマーという仕事のイメージは、「憧れであり、かっこよく、非常におもしろい仕事」だと思っていたからです。でも実際に自分が同じ経験をしてみることで、その理由がなんとなくわかってきた気がします。
最近、インターネットでもこの分野を調べてみてわかってきたのですが、どうやら多くのSE、プログラマーは上流工程の仕事に対して上手くはいっていない人も多いようです。
SEとかプログラマーというと、まず「プログラミング」というイメージがあるかと思います。例えば有名どころでは「C言語」とか「Java」とか、世の中には他にもたくさんのプログラミング言語があります。
ですから、それさえ勉強すれば「全てOK」とは言いませんが、自分の中では「まずプログラミングを知らないことにはどうにもならない」ぐらいのイメージがありました。
しかし今の会社に入って「現実」を知るようになります。それは「要件定義」とか「仕様書」と呼ばれるものです。
「要件定義」という捉えどころのない課題
今の会社に入って最初は上手くいっていました。プログラミングのテストという面もあったかと思うのですが、この部分の仕事はExcelVBAの勉強をちゃんとしてきたということもあって特に問題はありませんでした。
むしろ自分でも驚くぐらいできたと感じています。上長からの修正要求に対しても全て修正できたので、「あぁ、プログラミングってこんなこともできるんだな」という感覚すらありました。
しかし、ここから大きな壁が現れてきます。「要件定義」や「仕様書」といったSEの仕事における上流工程と言われる分野です。
最初は「何がわからないのかがわからない」といったレベルでした。つくるシステムに対して、やたら文章を書かされ、やたら修正されます。しかもひとつひとつの言葉の言い回しまでもです。
「なぜシステムをつくるのにこんな面倒くさいことをしなければならないのだろうか。」
「実際に作りながらユーザーに試してもらいながらつくった方が効率的ではないのだろうか。」
「そこまでする必要があるのだろうか。」
など、自分の中でいろいろと思う部分はありました。
ですが、最近になってやっと何がわからないのかがわかってきました。それは自分にとって「要件定義」や「仕様書の書き方」などの知識がなかったということです。
さすがにこのままでまずいと思い、この要件定義に関する分野の本をいくつか購入してちょっとだけ目を通しては見ました。これは今までの経験とか感覚でどうにかなるものではないですね。ちゃんと体系立てて勉強しないとどうにもならない気がします。
今の自分の状況では「要件定義」や「要求定義」の言葉の意味もちゃんと理解できていませんし、業務フローや業務プロセス、どんなUIや機能がユーザーにとって必要なのか、といったことも勉強しなければいけないようです。
SEやプログラマーを目指す人は、プログラミング言語だけではなく上流工程もちゃんと勉強しないと後で困ることになる
今だからこそ言える事ですが、SEやプログラマーを目指す人はプログラミング言語を学ぶことはもちろん、「要件定義」などの「上流工程」と言われる分野も勉強しておいた方が良いです。
じゃないと上長からの指示に対して適切な答えを返すことができず、いろいろと叱責を受けることになります。
新卒とか派遣の求人でSEの仕事内容の求める人物像とか能力に「コミュニケーション能力」という言葉をよく目にするかと思います。その時はなぜコミュニケーション能力が必要なのかいまいち理由がわかりませんでした。
というのも、SEやプログラマーの仕事というのは、「プログラミングが中心」だと思っていたからです。でも今だからこそわかりますが、実際の仕事はむしろプログラミングの割合は少ないくらいです。
そしてなぜコミュニケーション能力が必要とされるのかは、この職種の仕事には要件定義の知識が必要と書いてきたように、依頼主の希望するシステムをちゃんとつくれる必要があります。
そのためには、現在の状況や理想とするあるべき姿、そのために必要となるシステムにはどんなUIでどんな機能を入れるべきか、といった点を整理できるように、依頼主から適切に情報を引き出せなければいけないからです。
将来SEやプログラマーを目指す人は、こういった点も考えられるようにならないと、自分のイメージとズレて何かと後悔してしまうかもしれません。
ただ、SEの仕事には下流工程や上流工程があるということを認識し、そのためのちゃんとした準備ができていれば非常に楽しい仕事になると思います。
コメント