せつさんの紹介とSESの概要
aozora.fm第103回目。第103回目は、ゲストに、せつさんをお迎えしております。せつさん、よろしくお願いします。
はい、よろしくお願いします。
はい、では、せつさん、自己紹介をお願いします。
はい、せつと申します。SESでずっと20年以上ぐらいやってきているエンジニアっていうところ以外は普通のエンジニアだと思います。
はい、ありがとうございます。今、ありましたように、せつさんとは、技術書店の新刊ですね、SESに関する本で、ちょっとツイッター上でつながりができまして、
ぜひ、SES話じゃないですけど、そのあたりの話をさせていただきたいということで、今回ゲストにお呼びした次第になります。
というわけで、本題のSESの話に入っていこうと思います。
はい、よろしくお願いします。
はい、じゃあ、まず、そもそもSESって何?ってところから入っていきたいんですけど、基本的なところ、SESはシステムエンジニアリングサービスの略であるっていうのは、まあ、これはいいですよね?
そうですね、はい。
問題はこの先で、じゃあ、何がどうなると、自分はSESだ、あの人はSESだとなるのか、というのが正直私わからないんですけど、せつさん、このあたりってどう思ってます?
そうですね、確かにこの定義ってとてもふわふわしていると思っていて、基本的にはやっぱり、順位契約で契約を結んで仕事をしているっていうのが一番ふさわしいというか、SESだなっていう感覚はあるんですけれども、
ただ、最近話を聞いていると派遣契約を使っているケースもちらほらあるとか、そちらに切り替えていってるとか、そういう話もあるので、これは余計にわからなくなってきたなというのが正直なところですね。
そうなんですよね。これ、私の理解というか認識と、せつさんの認識と、あとさらに一般的な、特にツイッターで言われるSESっていう文脈だったりとか認識って、またこれどれも違うので、そのあたりすげえ難しいなって思ってるんですけど。
そうですね。それが、論争が起きる元になったりしてることもやっぱりあると思うんですよね。
そうなんですよね。なんか、自分の言うSESとあなたの言うSESずれてるのに、なんか空中性みたいなことをやっちゃってるみたいな、ありますよね。
そうですよね。そもそもそのSESっていう言葉自体が、どこから出てきたのか誰も知らないんですよね。
わかる。起源、私も調べたんですけど、どこにも出てきてない、書いてないんですよ。
はい、ないんですよ。僕、結局20何年、そのSES的な仕事をしてるんですけど、最初にそのSES的な働き方をしてた頃には、SESっていう言葉なかったんですよ。
そうですよね。
はい。それがいつの間にかSESっていう言葉ができてて、なるほどっていう。でも気がつけばみんながSESって言うようになっていたっていう。
そうなんですよね。あれ不思議ですよね。
はい、とても不思議で、気になったのは最初のSESの会社にいた頃に、社長がよく、我々はサービス業であるっていうようなことを言っていて、
それがちょっとSES、システムエンジニアリングサービスの部分に引っかかっているのかなっていう、それをとある時期から急に言い出したんですね。
そのちょっと後あたりからSESっていう言葉が流行り始めて、ひょっとしてこれはって思ったりもしたりもしますね。
なんか業界的にそういうのがあったんですかね。
社長が自分で言い始めたってことはおそらくないと思うので、その同業他社との話から出てきたようなキーワードと言いますか、標語じゃないですけれども。
たぶんどっかで聞いて、あ、これいいじゃんみたいななった感じしますよね。
そんな気がしてます。
いやーそうなんですよね。
世間一般のSESのイメージ、ちょっとこの後話す契約形態の話にも関わってくるんですけど、
世間一般が抱いているSESのイメージっていうのを、瀬津さんから見るとどんなイメージを皆さん抱いているように見えますか。
やっぱりよく言われるのが、技術力があまり高くないっていう。
なんでそこに繋がるんだろうっていうのはちょっとあるんですけれども、やっぱり一般的な見解としてはどうもあるっていうのと、
システム開発ですとか、現場における末端を占めてるっていうイメージはやっぱり持たれているのかなと思います。
専門家、プロフェッショナルみたいなイメージとは本当に掛け跳ねられたというか、全然違うところになってしまっているところはありますよね。
そうですね。確かに大抵のSESの会社では、エンジニアのキャリアプランまでそこまで考えて案件をアサインしたりは、それほどしてない会社の方が多いっていうのは確かにあるとは思っていて、
要はそのエンジニアがキャリアプランを構築しにくい環境になってしまってるとは思うんですけど、それゆえに専門的にはなりにくいとは思うんですけど、
SESの契約形態とその問題
かといって、それで必ずしも劣っているかっていうとそういうことはないのではって思うんですよね。
いやー、そうなんですね。その辺りのギャップというか、現場で働いている我々SES従業員契約のエンジニアと、世間一般で見られているSESのイメージと、
あとはSESでちょっと嫌な目にあったというか、それこそ経歴差症みたいな感じの扱いを受けた人たちの遠差というか、負の声みたいなところの中にいろいろ混ざり合ってしまっているところはありますよね。
ありますね。
では、次にちょこちょこ出てきた契約の話で、準移任契約ってところにフォーカスを当てていきたいんですけど、そもそもこの準移任契約っていうのは、
元となる移任契約、移任という考え方があって、それに当てはまらないので、準、移任、準がついたという経緯があります。
要は法律的な契約は移任契約、移任という言葉になって、法律外の契約は準移任になるという認識でいます?
SESさんはこの辺り、詳しくなかったら全然するし、いただいていいんですけど、どうでしょう?
この辺り、ちょっとX状で話すことがあって、それの過程でポケットロップを買いまして、移任とか準移任の辺りの法律周りを見直したんですけれども、
その定義で全然合ってますね、完全に。
法律外行為が移任で、法律外行為が準移任。
法律上、その準移任はほとんどの面で移任と同じ扱いになるので、準をつけた準移任として、
大体の内容、項目において、移任の場合に準ずるという定義になってますね。
はい、ありがとうございます。
準移任契約の契約の種類というかね、タイプとしては2つありまして、利効割合というタイプと成果報酬、成果報酬型ですかね、という型の2つがあります。
利効割合というのは、働いた時間分だけ、100時間働いたら、時間あたりいくらなんで100時間分お支払いしますよっていう利効割合と、
何かしらの成果を持って、その成果を収めると、それに対して報酬を支払う、成果報酬型という2つがある認識でいます。
この成果報酬型っていうのは、2020年ぐらいですかね、数年前にできた新しい仕組みというか型なんですけど、ここも認識があってそうですかね。
いや、これすいません。今聞いて初めて知りました。
お、なるほど。
全然把握しなかったです。
で、私このあたりの、特に新しい方の成果報酬型っていう部分が世の中に知れ渡っていないので、先ほど話したような世間一般のSESのイメージみたいのがあるのかなと思っていて、
要は利効割合ですと働いた分だけお金がもらえるので、残業いっぱいして別に経歴というかスキルが浅いエンジニアでもアサインして現場に放り込んでしまえばお金になってしまう。
それ故に経歴差症であったりとか、人を掻き集めてきて現場にぶち込むみたいな、世間一般でいうようなSESのイメージが出来上がってしまったんじゃないかと思っている次第ではあるんですけど、そのあたりどうでしょう。
そうですね。やっぱりそれの印象が強いとは思うんですよね。ただ、現場に入っている、僕ら10人に入っているエンジニアからすると、下手なことをすればすぐに切られるってやっぱり認識が結構ありまして、
特にこれ多分チーム単位で入っているわけではなくて個人単位で入っているエンジニアだと顕著だと思うんですけれども、それこそ僕が見た範囲でも3ヶ月契約を結んでいて、ただ単価に明らかに見合っていないパフォーマンスしか出ない人が、もう2ヶ月の時点でちょっともうこれはということで切られたっていうケースもあったりしまして、
そこまでスキルが低いエンジニアでもちゃんと契約を取って継続できるかっていうとそんなことはないと思うんですよね。
本当それはおっしゃる通りだと思っていまして、そのあたりも現実とイメージのギャップなのかなと思っていまして、
おっしゃる通りやっぱりビジネスなんですよね。お金のやり取りが発生しているものではあるので、それに見合ったアウトプットが出ないのであれば当然契約終了っていうのはそれはそうだよねって感じなので、
なんかそのあたりもうちょっとこう、おざなりというかあまり訴状にならないというか話題にならない、見逃されている部分なのかなっていうのは私も思いますね。
現場の課題とSESの魅力
ですよね。なんか違和感がとてもあるんですよね。
SES側の人間からしてしまうと。あと多分これ自分がチーム単位で入ったことがほとんどなくて、一人で入っていることが大半だったんですね。なので余計にそれはあるかもしれないですね。
なんかそのあたりも啓蒙じゃないんですけど、知ってほしいというか、わかってほしいみたいなところはちょっとありますよね。
ではまあ契約についてはこんなところにして、ちょっとSESここがイケてないじゃないですけど、現場の我々が感じている問題点みたいなところを話していければなぁと思うんですけど。
実は自分は結構SESの現状に満足してしまっているところがあって、あまり不満に思っているポイントっていうのがそんなにないんですね。
これまで所属してきた会社に対して不満があったことはあるんですけど、それはSESだからっていうよりはその会社がだからっていう部分が割と大きくて。
そういう意味でもちょっと自分はちょっと世間一般のSESエンジニアのイメージから外れてしまうかもしれないですね。
その不満を持ちつつもその立場に甘んじているっていう形ではなくて、望んでその立場にいるっていう感じになってしまって。
なるほど。ありがとうございます。
そうですね。ちょっと話の切り出し方が良くなかったかもしれないんですけど。
そういう意味で言うと、私も別にSESという働き方に不満というか、思うところはあってももう絶対やめたいとか、なくすべき悪みたいなところは思っていなくて。
実際やってみてすごい面白いなとかやりがいを感じる部分はあるので、なんかそういうところも含めてもうちょっと広まっていくと、現実が広まっていくと嬉しいなっていうところはありつつ、
まあちょっとここは問題というかどうにかしてほしいみたいなところはあるっていうのが現状です。
SESの法律問題
具体的にじゃあどういうところが問題なのかっていうと、例えば偽装KIになりやすいというのがありまして、これはもうなりやすいというか横行している、それが当たり前になってしまっているみたいなところもあるかもしれないんですけど。
ひょっとしたら節さんはチームで入ったことがないっていうことなので、経験があまりないかもしれないんですけど、いわゆる指揮命令権的なところですね。
順位任で仕事を受けた受託側と発注元とあるんですけど、その間の指揮命令権っていうのは法律で決まっていて、それを破ると偽装刑をという罪というか、法律違反になってしまうっていうのがあるんですけど、
これが現場にいると平気の平座へ破られるというか、発注元が意識してくれないくてすげえ困るっていうのが結構、もっかいのところ、私の結構大きな悩みなんですけど。
確かにそれはありますね。これをSAS側というかエンジニア側というか、そちらが意識しなければならないっていう状況が何でってなりますね。どちらかといえばこれは発注側が意識しなければいけない問題ではっていう。
いやそうなんですよね。あれなんでなんでしょうね。発注側が多分違反したら訴えられる側なんですけど、訴えられないと思っているのか、はたまた本当に知識がないのか、なんか何もしてくれないというか、ルール違反なにそれみたいな感じでやってくるの、本当不思議なんですよね。
その人についての知識がないっていう割合は結構高そうな気はしてますね。意図的にやっているというよりは。
いやそうですよね。大体この我々のようなSASのエンジニアって大手のSIRさんに仕事をいただくというか、そこに行くことが多い印象なんですけど、スーツさんはそんなことが多いですか?
所属している会社によりきりになると思うんですけれども、本家はやっぱりSIRの下にぶら下がってっていうパターンがやはり一番多いと思いますね。今たまたま自分は結構SIRと離れた部分でやってることが多いんですけれども、最初2つの会社はSIRからの仕事しかないっていう形でしたね。
そうなんですよね。そこで疑問なのがSIRと本当に情報セキュリティとか社内統制、社内のルールみたいな、めちゃくちゃうるさいんですけど、なぜかそこの順位任とか偽装系を置いてから頃はあまり教育されてないというか話題に上がらなくて、何なのかなってすごい思うんですよね。
これはそうですよね。我々がSIRさんの中に入ってもかなり実感しますよね、そのSIRさんの中のルールのガチガチさというか。その中において確かに順位任契約の取り決めじゃないですけども、そういったところについてはあまり見られていないっていうのは結構不思議な感じはありますね、確かに。
いやーそうなんですよね。やっぱりどこもそんな感じなんですね。
はい、じゃあ一旦次のトピックというところに行くと、また私が思うところだと客先常駐みたいなところがあるかなと思ってまして、これは物理的にお客様のところに出社するっていうのもあるし、フルリモートでも結局お客様のスラックワークスペースとかTeamsとかZoomとか、
そういった部分でしか会話しない。要は自社の人を会話しないっていうのが結構あるかなと思っていまして、これもよしあせはあるんですけど、大多数の人は結構マイナスというか、あまりよくは感じてないのかなと思うんですけど、この辺り、瀬さんはどうでしょう?
自分はそうですね、あまりマイナスに思ってないというか、逆にお客さんと近いところで仕事をしたり、お客さんの中で飛び込んで仕事ができる環境の方が個人的には好ましいなと思っていて、そういう意味では客先常駐の方が主張に合っているっていう感じはありますね。
なんかそういうレベルで、そういう意味で言うと、客先でやりたい、お客様により近いところでって思ってるのに、自社のルールだったりとか、鑑賞みたいなものだったりとか、何かその出社日っていうか、記者日って言うんですかね。
なんか自社に来いみたいな日があったりして、なんかそういうのがあるとうとましいというか、ストレスに感じたりするみたいなところはないんですか?
そうですね、過去に行った会社は記者日があって、今の会社はもう社内の連絡が全部スラックで済ませるっていうタイプなので、あんまりそういった考え方がないんですけれども、やっぱりお客様のところにどっぷり使って仕事してると、何でわざわざ記者日に戻ってもそんなにやることないんだけどなっていうのとか、
たぶん一番よくあるのは社内向けの勤務票というか、渡すためだけに記者するとかあると思ってて、何でしょうね、お客様のためにならない自社の業務、やる意味あるのっていう感覚にはなってしまいますね。
めちゃめちゃわかりますね、それ。さっきもちょっとBMSなのでみたいなお話があったと思うんですけど、本当にその流れで言うと、お客様に貢献するためにやっている、それこそ我々のITエンジニアとしての知識とか技術っていうのをそこに使うというか、
それで貢献するなので、なんか謎の自社に対するドキュメント的なとか報告書的なとか、よくわからん自社集会みたいなのに参加して、果たしてこれはお客様に何の役に立っていて、言ってしまえばいくらの価値があるのかみたいな。
この時間分お客様の作業をやった方がいいんじゃないかみたいな、思ったりすることはありますよね。
記者日で例えば自社に戻って、自社の人間と相談なり戦略会議をして、お客様に今後こういうアプローチをしていこうですとか、お客様のためになる戦略作りみたいなのができるのであれば意味はあると思うんですけど、だいたいはこれ報告会とかしてますよね。
だったらメールでいいのってばかり言う。
そうなんですよね。
アジャイルじゃないんですけど、本当にお客様のためを思ってというか、お客様に貢献するみたいなのが薄いかなと思っていて、本当に契約が続いていればそれでいいよ、問題を起こさなきゃいいよみたいな感じで、
ご要議期じゃないんですけど、言われたことを無難にやってこいみたいな空気感はちょっとありますよね。
そうですね。逆に本当に今ふと思ったんですけれども、この記者日を本当に有効活用して戦略にできている会社はおそらくですけど、自宅メインにシフトしてしまってるんじゃないかなという気はするんですね。
SESだけだと本当に社員が増えないと会社としての収益が上がらない。ほぼほぼ人数に比例しちゃうんですよね。しかもそんなに利益率は高くないっていう。そこをなんとかしようと思うとだいたい自宅にシフトするっていう形になると思っていて。
いや、そうっすよね。そうなんだよな。一人で3件くらいやれるんだったら利益率は上がってくるんですけど、むっちゃけ無理なので。そうなんですよね。
契約上も時間をお客様に渡すことで、先ほどの利向割合ですね。これが基本になっちゃうと思うので、そうなると一人で3人分みたいな仕事の仕方はなかなか難しいですから。
そうなんですよね。さっき言った客先常駐みたいなのもあって、だいたいお客様先で朝会だったり夕会だったりみたいなものがあったりとか、お客様がやっぱり日中9時、17時とかで働いているので、そこに合わせるとなると他の案件も日中なんだけどってなると。
どう考えてもブッキングしてて無理ってなっちゃうんで、そこは無理だよなってのはありますよね。
そうですね。そこも結局解決しようと思うと、やっぱり住宅に倒すっていう方向性になってしまう気がしますね。
そうなんですよね。その辺りも日本のIT業界というか、システム開発業界の慣習というか、よくないというか、構造的欠陥というか、みたいなところはちょっと考えちゃいますよね。
新人育成の課題
そうですね。
はい、では次のトピックいこうかと思うんですけど、これもちょっと最近ツイッターで話題になっていたとこなんですけど、
新人とか経験が浅い、何なら未経験の人の教育とか育成についてSESだとどうすればというかどうしたらみたいな部分で一つあるかなと思うんですけど、
瀬さんとしては今までの経歴でそういった場面に出くわしたりとかやってきたみたいなところありますか?
これはありますね。正直話をすればやっぱり。
プロパンさんの若手を教育する機会はやっぱりよくあって、それと別に他社から来た同じような従業員の方に教育はしてはいけないんですけどせざるを得ない状況になることはありますね。
グレーで何とかその知識の共有、業務知識の共有ですとか、チームとして作業を円滑に進めるためのとかそういった形でごまかせるようにはしているんですけど。
めちゃくちゃわかりますね。
これなんでNGというかグレーみたいな話になってしまうかっていうと、さっき言った指揮命令権の問題があって、他の他社さん、パートナーさんみたいな言い方をするんですけど、
他の会社の人が指揮命令を受けられる人っていうのは決まっているので、全然関係ない人がこうやってください、このチケットやってくださいみたいなことを言っちゃうと、さっき言った偽装受け合いっていう法律違反とらわれる可能性があります。
なので仮に教育育成みたいなとこだったとしても指揮命令はできないんですよね。なのでなんとなく手順というか参考情報この辺にありますよぐらいのふわっとした言い方みたいな感じになってしまうっていう感じですよね。
そうですね。おっしゃる通りです。
いやーそうなんですよね。本当そこが難しいと思っていて。で、私もその順位任契約で自分の契約の内容すべて細かく見ているわけではないんですけど、いくつか聞いた確認した範囲だと、業務内容、契約上の業務内容としては〇〇システムの開発とか、
開発に必要な業務一切を行うとか一式みたいな契約の内容にどうやらなっているらしくて、なんで開発に必要ですって発注元に言われちゃうと、それこそ今言ったような教育とかそういったことも契約上はやらなきゃいけないっていうかやれちゃうんですよね。
ただ、順位任という法律の都合上、指示命令ができないので、そこが何か矛盾というか、個人的にはこのSESっていう構造というか、仕組みの限界というか、歪みを感じているところなんですけど、そういうところはありますよね。
はい、ありますね。先ほどおっしゃってた契約の内容は、自分は契約書そのものを見ることが結構多いんですけれども、自分の契約に関わる。やっぱりそのまるっと剥がれてるんですよね。
はい、とても。で、ひどいときになると9割はシステムの開発に関わる業務があって、残り1割はその他って書いてあって、その他は何でしょうかって。こういう書き方をしたら何でもありののではっていう。
その他はひどいな。
というケースもあったりしまして、やっぱりその業務を進める上で必然的に教育に近いことをやらなければならないのは確かに本当に往々にしてあると思います。自分も本当に。
SESの法律と働き方の課題
で、これ、その順位認定契約の筋を通そうとすると、その発注元に掛け合って、ダレサレさんにこういう指示を出してくださいみたいな。で、指揮命令系統を守ってもらうみたいな。働きかけをしないといけなくて、なんかすごい何これっていう状態になるんですよね。
はい、そうですね。正直この順位認定契約をこのエンジニアの常駐業務に適応すること自体がちょっと間違っているのではっていうのは正直思いますね。順位認定契約ってもともとそういう状況は想定してないでしょうっていう。
いやーマジそれなんすよね。これやっぱり邪髄じゃないですけど、現場を知らないお上のお役所の人が適当に作ったとしか思えない感じしちゃいますよね。
働き方に合った法律があると嬉しいんでしょうけど、そんな細かいケースバイケースまでは見てられないのかもしれませんが、さすがに法律では。
まあそうなんですよね。だからその後々じゃないですけど偽装敬老みたいな問題視される部分が法律で整備されてはいっててると思うんですけど、結局その歪んだ土台を無理やり補強しようとしているので、
さっき言ったような、これやりたい、やらなきゃいけないんだけど偽装敬老になっちゃうからなーみたいな、逆に足枷みたいになっちゃってるみたいな。きっと本当は順位認定側というか受託側を守りたい、弱者として扱われる側を守りたいがゆえの意図だと思うんですけど、逆にちょっと苦しめてしまっているみたいなところはありますよね。
そうなんですよね。本来はそう、守るための法律だと思うんですよね、これ。
いやーやっぱり話を見るといろいろこう思うところというかありますね。
そうですね。で、おそらくは結構みんながやっぱり感じていることだと思うんですよね。
一旦ちょっとネガティブなところはこの辺にして、最後にちょっとSESエンジニアの将来みたいなところについてちょっと会話していけたらいいかなと思うんですけど、さっきの教育の話もそうですし、あとはその自分のキャリアですね。
これからどうしていくのがいいかとか、なんか展望的なところがあればとか、あとはこういうところ帰っていったらお互いハッピーだよねみたいな感じの話ができたらなぁと思うんですけど、そのあたりはどうでしょうか。
ちょっと自分はそうですね、結構現状に慣らされてしまっているかもしれないですね。あまり改善ですとか未来っていうのはちゃんと見えてないかもしれないですね。今結構楽しいので正直な話。
そうですね、なんか私が思うところだと、今瀬さんにおっしゃっていただいた部分が結構あるなぁと思っていて、そうSESで働くのって結構楽しいんですよね。楽しい面があるっていうのが正確なのかもしれないですけど、なんかすごい辛いとかもうSESイコールブラックみたいなことはないんだよ。
ちゃんとやりがいとか楽しさとか、ポジティブな部分もあるんだよっていうことを伝えていきたいみたいなところは私も本当に思っていまして。
正直今私がSESを辞めない、自社サービスとかSIIに転職しないのはその楽しさがあるからっていうところはあるので、なんかそういう部分を私もそうですし、瀬さんもそうですし、現場のSESエンジニアがもっと発信して、
イメージ改善じゃないですけど、伝えていけたらいいなーっていうのは一つ思うところではありますね。
SESと比べるではないかもしれないんですけど、フリーランス結構ポジティブなインストがやっぱり一般的に強いじゃないですか。
昔ながらの一人で何でもやるフリーランスがあって、そこに今割と多いエージェント型の契約代わりだけはエージェント会社が見てくれるタイプのフリーランスがあるじゃないですか。
さらにそこから繋がるところとしてSESがあると思っていて、SESはエージェント型のフリーランスに加えて会社がケツ持ちしてくれる。その代わりちょっとマージをもらうよっていう感じのくらいのイメージがいるんですね。
結局自分も今SESのエンジニアとしてやってて、イメージとしてはずっと傭兵のつもりで結構思いますね。
これが一人でやってる傭兵でも、チーム単位でやってる傭兵団でもいいんですけれども、困っているところに行って困り事を解決して、さあ次っていうイメージでどんどん経験を積んでいくというよりは、
先にその前にそもそもお客さんの困り事をどんどん解決していく。短いスパンで。っていうのが個人的には楽しいしやりがいもあるって思ってますね。
いやーめっちゃいい話ですね。ある種ギルドじゃないですけど、ギルド的なクエスター戦場的なところから仕事をもらってお役立ちしますよみたいな感じでやっている部分はあるので、
そういう意味でちょっと正社員っぽいというか正社員のフリーランスみたいなちょっと矛盾した表現になっちゃいますけど、みたいなところは確かにありますよね。
やっぱりフリーランスかっこいいなとは思うんですけど、やっぱり踏み切りにくい。特に今自分みたいに過程を持っていると特にというのもあって、そこをSESというのは選択肢的には悪くないのではないかなと思ってますね。
いやーそうなんですよね。やっぱりそうなると結構自分の技術力、この技術力っていうのは単純にプログラミングとかなんかAWS、GCPみたいなインフラ的なところみたいないわゆるハード的なところではなくて、
ソフトスキル的なところ、お客様とのやりとりだったりとか、さっきちょっと出たようなうまく教育育成していくみたいなところのうまくやっていく能力みたいなところとか、そういった意味でのジェネラルな能力っていうのが求められる立ち位置なのかなっていうのはちょっと思っていて、
キャリア的な話をすると、そういう部分に将来への鍵というか、これから先生き残っていく重宝される鍵、キーがあるのかななんていうのは最近ちょっと思ったりするところですね。
そうですね。結局今AIとかが出始めてきてて、技術的な部分が若干脅かされそうになっている中でも、そういったソフトスキル的な部分って最後まで生きてくる部分じゃないかなと思っていて。
お客様と接するポジションであれば、そういう立ち回りが見かけると思うんですけど、なかなかそういうポジションばかりではないと思うので。
SESだと、結局お客さんのところに飛び込む環境じゃん。そんなにコミュニケーション得意なタイプではないんですけれども、それでもお客さんに与えるイメージですとか、印象ですとか、その辺を考えながらの立ち回りっていうのはやっぱりお望みについてきた感じはありますね。
やっぱりそうですよね。ありがとうございます。
その辺りそうですね。今SESで頑張っているエンジニアの方もそうですし、現場でSESとか順位任のエンジニアの方を接する機会があれば、その辺りもちょっと見たり気にしたりしていただけるとありがたい嬉しいかなと思う部分であるかなと思います。
では、SESについてはこの辺にしとこうかなと思うんですけど、何か話漏れたというか、これも話しておきたいみたいなことありますか?
全然大丈夫です。全部引き出していただきます。
ありがとうございます。
ITエンジニアの現体験
じゃあちょっと残り時間でちょっと駆け足かもしれないですけど、プログラミングITエンジニアの現体験っていうのを今このAzure FMでトークテーマと設定しているので、その辺りをお聞きしていけたらなと思っております。
まずITエンジニアの現体験からお聞きしたいんですけど、ITエンジニアになりたいと思ったきっかけとか、現体験みたいなものがあったら教えてください。
自分の場合ですと、最初に中学校の頃に情報処理室があったんですけど、そこのパソコンでたまたまベーシックが書けたんですね。
当時の技術の教科書の週3のところにギリギリベーシックの超初歩のプログラミングの内容があったんですよ。
これを見て、当時僕はゲーム商人だったので、自分でゲームを作れるんじゃないかと思って、家にパソコンがなかったんですけど、学校の情報処理室にも常駐してひたすらゲームを作るっていうのをやっていて、そこが現体験になりますね。
だから最初はITエンジニアじゃなくて本当にゲームプログラマーを目指していました。
そのゲームはベーシックで動くゲームってことですよね?
はい、そうですね。
じゃあひょっとしてベーマガみたいな、ベーシックマガジンみたいな雑誌から見ながら打ち込んで動かすみたいなことも、ひょっとして経験が終わりだったり?
そうですね。自分が住んでいるところが田舎すぎて、ベーマガが売ってなかったんですけど、1年に1回とか半年に1回ぐらいで特集号みたいなベースみたいなのが出たんですね。
そっちには一応プログラムが載っていて、フロッピーで入っていて、そこからコードが取れるっていうのがあって、それは確か参考にしていました。
じゃあオリジナルで作るゲームもあれば、そういった打ち込み系のゲームも試してみて、ちょっと改造して遊ぶみたいなことをやられていたところが現体験みたいな感じなんですかね?
はい、そうですね。
じゃあ結構プログラミングコードを書くのが楽しいみたいなところが現体験みたいな感じなんですね?
はい、それは正直今でもありますね。正直、いちいちコードを書いていても全然来ではないタイプ。
なんか偏見と言えば偏見感はしていないですけど、結構コードを書くのが楽しい、プログラミング重視みたいな方って、さっきおっしゃったようなビジネス的感覚みたいな、お客様に対してみたいなところを結構嫌がるというか、
あまり重視されないイメージがあったんですけど、瀬津さんはそのあたりのバランス感覚というか、なんかわかってらっしゃるというか、その辺すごい素晴らしいなぁと思うんですけど、やっぱりそれは仕事としてやってみて身についてきた感覚みたいな感じなんですかね?
仕事としてもありつつ、作るとなるとゲームデザインも自分でやるじゃないですか。結局ゲームデザインしようと思うと、ゲームをやるプレイヤーも想定しなきゃいけなくて、そのためにどうすればいいかみたいな。
行動よりももうちょっと上の設計ですとか、要件定義の部分にもなってくるんで、そこをどうしたらいいか、いいものをしたいなっていうのが、わりと業務システムですとかの要件定義とかそういったところとも結構被ると思っていて。
作っても楽しいですし、設計するのも楽しいですし、お客様と話をして、こういう方法だったらこの業務の要件を解決できるじゃんとか、そういったところを模索するのも好きっていう感じですね。
めちゃくちゃ僕の理想とするというか、僕もそのタイプのITエンジニアなんですけど、それすごいわかりますね。
楽しいと思うんですよね。
そうなんですよね。なかなか伝わりづらい部分ではあるんですけど、ある種その理想というか、ちょっとNイコール1かもしれないですけど、理想のエンジニアのマインドセットみたいなところはあるのかなとちょっと思いますよね。
ITエンジニアの楽しさ
それにちゃんと自分のスキルがついてこれているかというところはさておき、やっぱりそうなりたいっていうビジョンを持ってやってますね、私。
私も同じくスキルがついているかどうかはともかく、そういう心構えでやっているというところはあります。
じゃあ次の質問で、ITエンジニアをやっていて楽しいと感じる点を教えてくださいっていうんですけど、これはいくつか話題に出てきたあたりですかね。
自分は多分お客さんの反応がやっぱり一番嬉しいというか、喜んでくれるみたいな。
これがユーザーだともっと嬉しいのかもしれないんですけど、結構僕は直接反応が見れるのが楽しいっていうのもあって、
例えば社内システム改善して社内業務がうまくなるようになったみたいな話ですとか、結構その近いところからのリアクションを糧として仕事している感じはありますね。
やっぱりフィードバックがあるとモチベーションにすごいつながりますし、当然フィードバックなので良い悪いはあるんですけど、やっぱりそれが目に見えて返ってくるっていうのはすごいやる気につながりますよね。
そうですね。悪い反応をもらった時も、そうしたら何くそっていう話にはなりますし、ここを直さないとなっていう話とか。
本当そのあたりこだわりすぎてるというか、どうしてもエンドユーザーじゃないととか、ユーザーの近くでみたいなことを考えがちなというか考えるエンジニアの方が多いんですけど、
我々のような客先常駐で言えば、結局その客先の開発会社の方がまずお客さんであって、その先にまたそのシステムを使う人だったりとか、発注する人だったりとか、
我々の業界というか、SI業界的な用語で言えば省流っていう言い方をするんですけど、そういう省流の流れみたいなのがあるので、本当にエンドユーザー、エンドまでいかなくても使ってくれる人、反応をくれる人、フィードバックをくれる人っていうのはいるので、
そういう部分も気づいてというか、見落とさずにちゃんと付き合って取り組んでいきたい部分では、私個人としてはありますね。
プログラミングの原体験
はい、同感です。
はい、ありがとうございます。
じゃあ次、プログラミングについてお聞きしたいんですけど、ちょっと質問の内容というか答えがかぶる部分があるんで、かぶってたらさっき話した話で全然いいんですけど、
プログラミングを始めたきっかけとか、原体験としては、さっき言ったやっぱりベーシックの授業ですかね、の部分になるんですかね。
そうですね。実際にはもう授業でその辺やらなくて、本当に自分でも独学で進めてしまったんですけど、原体験としてはそこですね。
はい、ありがとうございます。じゃあ、プログラミングを教えて楽しいと感じる点を教えてくださいという質問もあるんですけど、
こちらもさっき言ったようなフィードバック的なところだったりとか、まあ単純にコードを書いているのが楽しいみたいな感じですかね。
そうですね、はい。
なんかこうプログラミング、コードを書いて楽しいって感じるのは、ちょっと言語化が難しいかもしれないですけど、どういったところに楽しさというか楽しみを生み出している感じなんですかね。
これは多分つながるのはパズルゲームですとか、パズルを解くとか、そういったところにつながっていると思っていて、
あとはそうですね、プログラミングを学んだあたりの頃で言うと、その通読の問題、ちょっと難問的な問題を解く楽しみとか、そういうのと結構近いかなと思っています。
なるほど、ありがとうございます。
それは本当にありますよね、プログラミングって結構人によっては決まったものを打ち込むだけみたいな印象を抱かれている方はいるかもしれないんですけど、
どっちかというと何もない荒野にどうやって家を建てていくかとか、どうやって道を引いてインフラ的なものを作っていくかみたいなところの方がしっくりくるかなという部分はあって、
それこそさっき言ったようなパズルゲームのような積み立てて積み立てて連鎖だったりとかある形を表していくみたいな、
その一個一個は全然単なる文字列ピースなんですけど、完成した全体像を見るとすごく美しい一枚絵になるみたいな、そういった感覚ですよね。
そうですね、はい、そんな感じです。
はい、ありがとうございます。
プログラミング、ITエンジニア的なところの話、きっかけ原体験としてはこんなところで大丈夫でしょうか?
もともとゲームプログラマー目指してたんですけれども、僕が就職、ゲームプログラミングの専門学校に行ってたんですね。
なのでそこからゲームプログラマーになるつもりだったんですけど、学校に来る求人がありますね、ゲーム会社からの。
それを見ると当時、2000年ですね、自分が就職した頃の求人がすごく良い内容で、
例えば、月給15万社保なしですとか、使用期間3ヶ月間無給ですとか、そういう求人が普通に来るんですよ。
これは普通に食べていけないなって思いまして。
そうなんですね。
改善されてますね、はい。
当時はそんなんでしたけど。
ゲーム開発の、ゲームプログラミングの専門学校に来る求人でもそのレベルというか、そんな内容だったんですね。
逆にそれなりに真っ当な求人は多分大卒にしか出してないとか。
なるほど。
はい、当時です。
じゃあ、総合職じゃないですけど、企画総合職、プログラマーみたいなところでちょっと格差じゃないですけど、みたいなのがあったような感じだったんですかね。
多分その当時、専門学校に求人投げてるような開発会社は、すごい小さいところが多かったと思います。
なるほど。
確かにそうですよね、80年代後半ぐらいの、それこそドラクエFFみたいなゲーム開発の当時の話、いつはみたいなの聞いてると、本当そういう感じの昭和というか。
そうですね。
同僚環境っていうのはありましたよね。
はい、そんな感じです。
残業代という言葉をどこを見回しても存在しないという、求人はどこにも行ってなかったですね。
知り合いのゲーム開発経験ある方に聞いてみると、大体皆さんそういう感じのことをおっしゃっていたので、当時って感じの話ですね。
当時作ってたプログラム、自分が作ってたゲームがPHPを使ってたんですよ。
そうなんですね。
当時ネットゲー、MMORPGとかあの辺が出始めた頃だったので、自分たちでも何とかそっちに寄せられないかっていうので、結局WEB側に寄せてゲームをやってたんですね。
卒業研究じゃないですけど。
卒業製作ですね。
結局それってやってることはWEBベースのシステムと何ら変わりないっていう。
変わらない。
だったらそっちでも結構は自分は楽しめるんじゃないかっていう。
なるほど。
ちょっとその辺り、今回ちょっとSES中止にしてしまったので、
SESについての告知
節さんの経歴というかITエンジニアとしてのみたいなところがあまり深く掘り下げられなかったので、あれなんですけど。
今後機会があればその辺りもぜひともよろしくお願いします。
はい、その際はぜひよろしくお願いします。
じゃあ、プログラミングITエンジニアところもこんな感じで大丈夫ですかね?
はい、大丈夫です。
じゃあいい時間になったので、この辺りで締めていこうかなと思うんですけど。
何か全体としてこれだけは言っておきたいとか、これ言い残したとかありますか?
大丈夫です。全部吐き出し切ったと思います。
はい、ありがとうございます。
ではまずこのポッドキャストの告知からしていきたいと思います。
このポッドキャスト、アウトドアFMではゲストを募集しています。
話したい、楽しいことがあれば誰でもOKです。
今までポッドキャスターに出たいけどハードルが高いなーとか、そんなすごい話題なんてないよーって人でも大丈夫です。
普段楽しんでいること、趣味の話、仕事の話、何でも大歓迎なのでお気軽にご連絡ください。
連絡方法はTwitterのDMやハッシュタグ、お便りフォームなど何でも大丈夫です。
また、アウトドアFMではご感想やご意見をお待ちしております。
Twitterでハッシュタグ、シャープ、アウトドアFM、シャープ、AOZORAFMをつけてツイートしてください。
配信ページのお便りボタンからもお便りを送ることができます。何卒よろしくお願いいたします。
さらにお願いになりますが、アウトドアFMではご支援を募集しております。
フィクシブファンボックスかオフセイというサービスで支援できますので支援してもいいよーという方は配信ページのリンクから可能ですのでよろしくお願いします。
ではゲストからの告知ということで、節さんから何か告知ありますでしょうか。
特にないと思ったんですけれども、今回のSESについての本を出しておりますので、そちら無料で配布しておりますので、ご興味のある方はよろしくお願いいたします。
ギリショ店のオンラインマーケットで無料でダウンロードできるということですよね。
はい、そうです。
ではその半分ページのリンクを掲載しておきますので、興味ある方はぜひ見てみてください。
はい、ではエンディングトークということで、フォトキャストの収録どうでしたっていうことをお聞きしたいんですけど、どうでしょうやってみて。
はい、ちょっと緊張します。なかなか喋るのが結構緊張するとそうですね、早口になっちゃったりとか。
そうですね、初めてフォトキャストの収録みたいな経験されると、皆さんやっぱり緊張するとか、話題本当にない15分とかしか、10分とかしか喋れないみたいなことをおっしゃるんですけど、
今1時間以上はもう収録しているので、全然普通に喋れますし、私が聞いていても全然緊張しているとかは全然思わなかったので、もう普通に楽しくお話しさせていただけたかなと思っております。
はい、ありがとうございます。
はい、ありがとうございます。ちなみにどうですか?会話的には楽しかったですか?
はい、非常に。だいぶ自分語りした感じがありますが。
いやいや、今回はそこが目的だったんで。ありがとうございます。
では、第103回目ですね。第103回目はゲストに節さんをお迎えしてお送りしました。節さんどうもありがとうございました。
はい、こちらこそありがとうございました。
