Keisuke.I, アソシエイト, 2020年4月・新卒入社, 首都大学東京・文系

ウルシステムズで働く若手はどのように学び、活躍しているのか？

会社に入ってどうやって成長していくのか？活躍できるのか？…就職活動されている方は気になりますよね。
■ どうやったらスキルを伸ばせる？成長できる？
■ 早く一人前になるにはどうしたらいいの？
■ 自信を持つためにはどうしたらいいの？
こんな思いを持った方にウルシステムズの社員がお答えします！今回は、新卒入社2年目の若手に「どんな先輩を見て、どう成長したのか？」を聞いてきました。

自分の手でものづくりがしたかったから

大学時代に大学祭の広報チームに所属しており、その時友人が担当していたホームページ作成を目にして「コーディングできたらかっこいいな」と感じました。それがITに興味を持ったきっかけです。就活が始まって自分のなりたい像を考えるうちに、その時に感じた「コーディングしたい」という気持ちを思い出し、未経験でも技術を磨けるような会社を中心に調べ始めました。コンサルにも興味があったため、最終的には、単に作るだけではない、技術力を武器にコンサルティングするという軸で就活していました。そこで出会ったのがウルシステムズです。当時、「技術力がすごいと自ら言っている」「向上心の高い人達集まっている」「高みを目指している」という印象を持っていました。自分もそんな環境に身を置いて成長していきたい、と考え入社しました。正直、面接は手ごたえがなく（笑）不安はあったのですが、結果的に迎え入れてもらえました。
実際に入社して、想像以上に成長できる環境だと実感する日々を過ごしていて、改めてウルシステムズに飛び込んで良かったと感じています！

初めてのプロジェクトは自分が主導で

初めてのプロジェクトは社内の人事評価システム開発でした。プロトタイプ（試作版のプログラム）を作成してから本番システムを構築する計画で進行しており、プロトタイプ作成期間は先輩主導のもと自身のタスクを行っていました。ただし、先輩が主導とはいえお手伝いのような位置付けではありません。技術調査や設計書作成のような自分で考えて行動しなければ進まないタスクを担当します。今回、Microsoft Power Appsを使ったローコード開発を採用したのですが、初めて使う技術要素であるため、ドキュメントを読んだり実際に動かしてみて、何がどこまで実現できるのかの仕様を把握する作業を行いました。設計書作成も、何をどこまで記述すべきか、というところから自分で考え作成していきます。先輩にもフォローしていただきながら、プロトタイプは無事作成でき、本番システムを構築するフェーズになりました。ここまでの動きを周りに認めてもらえ、先輩が担当していた計画作成や進捗管理も含め、全体の推進を任せてもらえることになりました。初めてのプロジェクトでここまで任せてもらえることに驚きましたが、やってみたい！期待値を超えていきたい！という思いがあり、乗り越えることができました。もちろんプレッシャーはありましたが、成長するいい機会だと思うことができたので、目の前のことに集中して取り組むことができました。どのプロジェクトでもそうですが、新人とはいえ、自分で考えてアウトプットすることを常に求められる環境で動いた経験は、次のプロジェクトでも活かされています。

仕事の進め方・品質を学ぶ

実際に仕事を進める中で様々な気付きや学びを得ました。その一つが、計画の立て方です。研修中は勉強期間という認識もあり、ちょっと無理がある計画でも徹夜してでも作りきる！ということをやってしまいました。それはそれで、システムをちゃんと作り上げる経験を積めたことは非常によい経験でした。
ただ、その感覚のまま実プロジェクトに入ってしまい、計画に遅れが生じても、深夜まで残業することで無理やり計画通りに進めていました。そして、それを知った直属の先輩に「徹夜して終わらせました。は何にもえらくないよ」と言われたのが衝撃的でした。頑張るのは大前提だとしても、正しいコスト意識を持って動くことが社会人として大事、ということに気付きました。それからは、計画に遅れが出そうなら早めに相談するよう動いています。
もう一つ、設計書や報告資料を作成する中で、実プロジェクトで求められる品質も大きな学びでした。報告定例会議では、自分が作成した報告資料に対して先輩から「こう書いている意図は何？」と聞かれ答えに詰まってしまい、なかなか会議の本題に入れないことがありました。それが何度も続いてもどかしかったのですが、そう聞かれてしまう原因を考え、資料の目的や読み手との目線を合わせを意識して資料作成するようにした結果、報告資料の品質が上がって会議を順調に進められるようになりました。

次のプロジェクトではまた新しいことに挑戦

最初のプロジェクトはローコード開発でしたが、次のプロジェクトはコーディングと単体テストが主なタスクです。最初のプロジェクトとは異なる環境にわくわくしています。最近特に印象的だったのが、とある先輩が「リファクタリング（＝コードの修正）できないコードは捨てた方がいい！」と言っていたことです。もちろん作ったシステムを捨てるわけがないので比喩ですが（笑）コードを後から修正した時に動作を担保する仕組みがなければいけない。その仕組みがないのであれば意味がない。ということを伝えたかったのだと思います。
最初のプロジェクトでも、新しい機能を追加した時には過去に実施したシナリオテストをやり直して動作の担保をしていました。それと同じように、テストを自動化して繰り返すことでソースコードが修正されても品質を担保できるんだと理解できました。これからも、新しい環境で新しいことを学び続けると思いますが、どこかでつながっていて自分の知識が深まっていくんだなと思うと楽しみです。