今回は当社の正社員エンジニアとして働くM・Tさんに、プログラマーとして持っておきたい考え方や、今後のキャリアについて座談会形式でキャンプ生からの質問に答えてもらいました。
プログラマーとして未経験から働くときにどんなことを求められているんだろうか、と考えている方はぜひ読んでみてください。
プロフィール
| 名前 | M・T |
| 年齢 | 40代前半 |
| 経歴 | 業務系アプリケーションの開発に携わり、現在はPMとして某大手企業のサービス開発に携わる |
目次
ー 開発会社で働くとなったら、あらかじめどんなことをしておいた方がいい、こんなこと知っておいたほうがいいよ、といったものはありますか？
開発会社に入るのであれば、どのプロジェクトにつくかっていうのがまだわからない可能性があるので、そうなったときは今まさに勉強していることを復習するのが一番いいかなって思います。
あと、これから実際にソースを書いたり、もともとあるソースに対して修正を加えたりすることってあると思うので、そういう部分になれるためにいろんな書籍がでているので、そういった書籍を呼んでいかに自分で相手に分かりやすいものを書くのかを意識しながら復習するっていうのが大事だと思います。
他にも、その会社のやっていることとか、お客さんがどういうことやっているのかとかといったこともサイトとか調べたらでてくるので、事前にインプットしてやっておけばいいかなと思います。
ー もともとフロントエンドで就職をしようとしていたんです。ただ、フロントで参加していてもサーバーサイド言語ができるとなお良いみたいな話を聞きました。フロントもできてサーバーサイドの方も技術があるっていう人ってニーズとして増えているのかどうかが気になりました。
ニーズ的にいうと、たぶん両方できないとたぶんダメで。
どっちが好きですかっていうのはたぶんあると思うんですけど、好きなのは別にどちらでもいいですけどね。
将来は基本的には両方できないとダメだと思っています。なんでかっていうと、管理画面に入れたものがフロント画面にでてくるじゃないですか。逆にフロント側にいれたものが管理側にでてくる。
そうすると開発の時ってフロントだけやれっていうのではなくて、フロントと管理っていう一つの機能、応募機能、フロント側で応募するための画面、応募した情報を実際に管理側でみて。
その管理側で得たデータを見ながらステータスの確認ですね。
応募したその人の条件は何なのかとか、その応募した人とコンタクトとりたいなってなったらそこからその人に直接メールを投げるとか。
なので、企業としてはフロントだけやってもなぁっていうのはあるそうなんです。両方できるっていうのがお客さんに対しても喜ばしいことだなとは思います。
ー 僕は前IT企業にいたんですが9か月で辞めてしまいました。その理由は、ずっと運用保守系の仕事をやっていて、全くプログラムの開発とかには携わらずにルーティーンな作業しかできないことが嫌になりました。
そこでここのキャンプを見つけて、参加しました。
次に転職するときには、できたらまた同じような徹はふみたくないんで、「保守運用とかをやりたくない」って言いたいですけど、それって企業側からしたらNGってなります？
たぶん開発っていうのは保守と新規の開発っていう大きく2つあるのかなと考えていいと思うんです。やっぱり常に新しい開発をしているわけではないんですよね。
自分で作ったものを継続的にお客さんに使ってもらう。そうすればお客さんにお金が入ってくる。保守っていうお金が入ってくるんですよ。会社の観点から言うと、長くお客さんをつかんでおきたいので保守契約を結びます。
なので僕は新規だけやりたいんですっていう表現ではなくて、運用保守をもちろん今までやってきたんで、その能力をいかしつつ、新規案件にチャレンジしたいんですっていう表現の方がお客さん、相手に対してはいい印象を与えると思います。
運用で養ってきたこういう能力を活かして、新規の開発に活かしていきたいですみたいな。
保守もずっとそのものをそのままをキープするための作業ではなくて、そのサービスをどれだけ永続させられるかっていう部分で、結局新しい開発は絶対にでてくるはずなのね。
自分で何かを作らせてもらえないのが辛いっていうのなら分かるんですけど、保守が嫌だっていうのはちょっと違うのかもしれないです。
ー 旧システムから新システムにデータを移行する、という仕事を以前していたのですが、この経験は強みになりますか？
大変でしたね。でも移行の経験ってすごいいいと思いますよ。
今システム開発って新規につくるケースと今ある既存のシステムから新しいシステムにリプレイスしますっていうものに大きく分かれるんですよ。
今ある程度、どこの会社も自分のサイトとかサービスって持ってるからけっこうリプレイス系とかが多いと思うんです。
その時に、やっぱりマストなのが移行なんですよ。意外とね、ここみんな甘く見てるんですけど、実は移行が一番大事で。
もともとあったデータがちゃんと新しいシステムで見れるか使えるかっていうのが大事なんですよ。これできないともうリプレイス、ようするに新規に開発したっていうところが全部台無しになってしまう。
そこって実際開発会社とかお客さんって意外と盲点でぬけがちなんですよ。そういう経験があるっていうのは今後自分の武器になると思うので、逆にそういうところを売りにしてもいいかもしれない。
そういうことも経験したのでそれを踏まえてやっぱり、新規開発にチャレンジしたいっていう。そう思いますね。
ー 35歳前後くらいからフリーランスになるか、それとも戻ってやていくかっていうのをきっと選ぶときがくるからっていう話を聞いたんですけど、実際にありましたか？
まぁその35歳っていうところを軸にして仮説にして考えたときに、35歳で何を今までスキルとして持っているかによると思うんですよね。
別に35歳でも全然企業には転職できますしね。35歳だと、一通りの開発ができて、チームのリーダーができて、なんかこう一通りの新規開発だけじゃなく今いった保守運用とかができる人ってやっぱ重宝されるので。
そういう人は別に35歳でフリーにならなくても、企業に入ることが僕はできると思ってますし、そういうニーズはまだあると思います。
逆にフリーは基本的には自由度が高いんですよね。自分で仕事を見つけたりとか、フリーランスを斡旋している会社もあるのでそういうところ経由で仕事を見つけるのもいいと思うんですけど。
でもその分自己管理が非常に大変なので。まぁその分だから返ってくるものが大きいと思うんですけど。でも技術以外のところがちゃんとできないと。
そのためには今まで一緒にやってきたお客さんであったり同僚に対して、ある程度信頼を構築しておかないと、なんか自分が仕事ないな困ったなっていうときに、やっぱりそういう人経由でお願いすることってたぶんでてくると思うんですよね。今やっている仕事もしくは友人でもいいですし、そういう普段の人間関係とかしっかりしていないと、フリーになったとき大変だと思います。
もしいずれそういうことをやりたいのであれば今からそういう準備をしておく必要はあると思います。
フリーランスになった知り合いも、今までお世話になったお客さんから仕事をもらってる人が大半です。新規に獲得するってかなり大変なんですよ。
やっぱり身近にお世話になっている人とか、そういう関係の人とから仕事をはじめつつ広げていく。そこからですね。それが難しいなっていう人はやっぱりおすすめできないなとは思います。
ー 仕事をしている中で大事にしている考え方はありますか？
仕事するときにたぶんみなさん設計書とか何かインプットがあって、それを元にプログラミング開発してくださいってなると思います。
もちろん与えられたものをしっかりやるっていうことも大事なんですけど、もらったインプットが正しいとは限らないんですよ。
設計書だって不具合は入っていたりします。設計書見ながら開発しているときに、なんかこれおかしくねっていうのがたぶんでてくると思うんですよ。
そういう部分を素直におかしいって思って必ずリーダーとかに「こういう仕様なんですけど、本当に合ってるんですか」って聞いたり、疑ってみるってすごい大事なんですよ。
実はそれが確かにそうだねってそれが不具合だったりするんです。自分で当たり前だなって思ったことがちょっとずれてるなって感じたらそれは素直に疑って、それが本当に仕様だったら、こういう業種のところはこういうイレギュラーな仕様なんだなって理解すればいいし。
そうじゃなければまさに自分の疑ったことが正しいわけだから、常に言われたことをするよりは必ず疑いの目を持つというか、疑念の感情を持つっていうのが大事になってくるのでそれはちょっとやってほしいなって思います。
ー 後輩とかで一緒に仕事していて楽しい人ってどんな人ですか？
楽しい人ですか。やっぱりね、いろいろ聞いてくれる人が楽しいよね。
黙々とやってると、こっちからどうよって声かけない限りこないのはちょっと寂しいので。
いろいろお話できる人の方がそれは楽しいと思いますよ。だってコミュニケーションなければ楽しい楽しくないもそもそもないですから。
たぶん声かける方が喜んでくれると思いますよ。「僕ここの部分こうやって考えているんですけど、こういうやり方でいいんですか」とかという感じで、ちゃんと意味のある会話ができるのであればすごい有用だと思いますよ。先輩とかも喜んで答えてくれると思うので。
あと一人で抱え込むのもよくないですね。分かんないでずっとどうやったらいいんだろうって調べながら試しながらやってるっていう。確かここにも分からなかったら30分までにとかって書いてありましたよね。
やっぱり1年目2年目とかの人は、一人で抱え込んじゃう人が多いんですよ。やっぱり質問しづらいのかどうかわかんないんですけど。
ついつい何とか自分で解決しなきゃいけないんだって思って自分でやるんですけど、それが2時間も3時間もたって、上の人から進捗どうだって言われて「これが止まってわかんないんです」っていったら「なんでそれ早くいわないんだよ」って。
結局スケジュールが遅れることになるんですよね。なので30分くらいでいいと思います。自分である程度分からないなって思ったら素直に質問するっていうのがいいと思います。恐れずに。聞かない方がよっぽど恥だと思うので。そこは心がけた方がいいかもしれないですね。
ー マネージャーの役目として、チームのモチベーションを高めたり、お互いの意思疎通できるような環境をつくるために何か心がけていることって何かありますか。
これたぶん一番難しいと思います。コミュニケーションないチームの生産性はね、やっぱり下がるんですよね。
この前Googleが発表していましたね。うまくいくチームと失敗するチームの違いって最終的に何だっていったらやっぱコミュニケ―ションの問題だとか。
それを構築するには今やってる案件でこの設計書だったらはいどうぞやってくださいっていうのは僕はちょっとNGかなと思っていて。
やっぱりそのそもそもその仕事ってどういう人たちがいて、どういう背景に使われるのかとかそういうことをしっかりメンバーに伝えて僕は今システムのこういうところをちゃんと把握したうえでやってもらうっていうことがやっぱり大事かなと思う。
一回ブリッジSEっていう立ち位置で中国の大連っていうところで仕事・案件をやっていたことがあるんですね。某アミューズメント系の案件だったんですけど、システムがめちゃめちゃ膨大で画面とかも2000くらいあるんですよ。
実際に自分がどの画面でやってるかっていうのも正直分かんないくらいなんですよ。最初は言われたとおりやるんですけど、やっぱりそれくらい数あるとだんだん生産性下がってくるんです。
自分は何をひたすら同じことやってるんだって。それじゃまずいなっていったときに、そもそもこの人たち何のためにやってるのかわかんないのかなって思ったんです。
それでそこの某アミューズメントのいろんな写真を自分でダウンロードしてパワポで資料作って、あなたのやってることはこういうアミューズメントのパークのこういうシステムをやってるんですよってアミューズメントにこんなキャラクターがいて、このキャラクターこういうことやってるんだとか、この性格こうなんだとか。
メンバーは結構そういうの楽しんで聞いてくれて。そうするとなんか自分のやってることに意味がついてくるんでしょうね。
そうするとおのずと生産性がやっぱり戻ってきたので。やっぱりやるためには何のためにとかそういうとこってひもづけって大事なんだなとその時に思いました。
