6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

エンジニア転職してから1年間を振り返って

Posted at

はじめに

この記事で書くこと

他業種から 株式会社ネッコス へエンジニア転職して1年が経過しました。

この1年で、
・学んだこと
・取り組んでよかったこと
・やりがいを感じたこと
・難しいと感じたこと
をゆるく書いていこうと思います。

ネッコスって?

  • LINE APIを用いた開発を行うシステム開発会社 です。

簡単な経歴

  • エンジニアコミュニティに所属してプログラミングを学ぶ(3ヶ月)
  • 知り合った方とチーム開発、個人開発をしていました(8ヶ月ほど)
  • Railsの開発で副業を経験(2ヶ月)
  • 株式会社ネッコスに入社(1年経過)

1年の業務

  • 自然言語解析と連携したlinebot開発 (lambda ruby)
  • xserverからAWSへのサーバー移管 (cakephp rds ec2)
  • 中規模システムのインフラ担当 (cognito waf ecs ecr aurola S3 Api Gateway cloudfront)
  • 書店向けシステムの開発 (Rails ecs scheduled task)
  • LIFF、LINE APIを用いたマップ検索システム開発 (Rails javascript ec2 rds)
  • マッチングサービスのLINE Webhook部分の開発 (TypeScript DynamoDB)
  • そのほかlaravel案件の機能追加や開発の進捗管理、マネジメント的なことなど

学んだこと

  • 設計(設計の難しさを学びました..)
    • お客様の利用を想定した機能出し(業務フロー、デザイン)
    • システムでの制御を図にしてまとめること(ステートチャート、シーケンス)
    • 最適なDB設計、サーバー構成の検討
  • エラー解消時の切り分け方法でどのように進めれば良いかということ
    • 例)決済サービスのwebhookが届かない
      1. 機能の概要、業務フローを理解すること
      2. 業務フロー図にまとめること
      3. 該当のソースコードを読んで処理の流れを理解すること
      4. シーケンス図にまとめること
      5. 決済リクエストが正常にされているか(ログの確認)
      6. 決済サービス内でログが残っているか
      7. webhookがサーバに届いているか(アクセスログ)
      8. プログラム側の処理が正常にできているか
  • 開発時に最低限必要となってくる資料で何が必要なのかということ(一例)
    • DB設計、ER図
    • UI画面、デザイン
    • サーバー構成図
    • 環境情報
    • スケジュール
    • 要件定義・仕様
      • 業務フロー図
      • シーケンス図
      • ステートチャート図
      • ステータス一覧
    • 運用・リリース
    • テスト
  • 要件により最適な使用技術、言語、適正なインフラサービスの選択が必要ということ
  • 10GB以上のデータを使用してのデモ開発で、データの取得と取り扱い方(sql)
  • お客様との認識合わせには開発前の資料準備などが大切だということ

取り組んでよかったこと

  • 個人サービスの開発
    • 実務で学んだことのアウトプットで効率的に個人サービスの開発ができたことです。
    • 実務で気づかなかったLINE APIの活用法なども見つけられて、仕事に活かせることができました。
  • 思い切ってこの案件をやらせてくださいと言って、ある程度の規模の開発案件を設計から開発、サーバー構築まで担当できたことです。(意見を聞いてもらえる会社)

やりがいを感じたこと

  • 依頼のあった企業との商談、要件ヒアリングから関わり、開発まで行うことができたこと。
  • 開発したサービスが初めて多くの人に使われたという経験は嬉しかったので忘れないと思います。
    ユーザ数をちょくちょくのぞいていました。それと同時に不安もありましたが、エンジニアとしての自信もついたと思います。
  • エラーの緊急対応でアサインされて対応できたこと
    エンジニアとして不具合を解決して役に立てたということで嬉しかったです

難しいと感じたこと

  • AWS、サーバ、ドメイン周りの理解
    • サーバーの移管作業では必要な作業がわからず、ドメインの変更やデータの移動、手順がわからず苦戦しました。限られたメンテナンス時間の中で作業を行う緊張感もありました。
    • インフラ周りが原因で動作せず、どこが原因なのかについては調査が難しかったです。
      毎度ホワイトボードで教えていただきました。
      基本的なことだと思いますが具体的に以下のような箇所が影響して動かなかったりだったと思います↓
      • ドメイン
      • アプリケーションサーバ
      • セキュリティグループ
      • ファイルの権限
      • SSL証明書
  • 慣れない言語での開発
    • 型のある言語での開発、これまで動的言語での経験しかなかった身からすると全然違い苦戦しました。
    • 初めてlaravelなどに触れた時は、railsでいうところの何に当たるかを置き換えて対応していました。
  • 商談
    • 要望の聞き方、要件のヒアリングで漏れがないか、議事録で入るだけでやっとです。
  • 体調面の管理
    • ずっと座り続けていたので、筋トレと運動は必須です。
      生活リズムを崩さないことも大事だと思います。

勉強会

  • 毎週集まってわからないことを質問できる場がありました。
  • 社内で簡単なLTを経験できました。LTをするとなると説明するための学習に身が入るのでよかったかも
  • CTOから開発の歴史や変遷などの話も聞けたり、単純な技術以外でも理解の深められる場でした。
  • どういったところから情報収集をしているのか、今後の開発の展望などが聞けたのも面白かったです。

今後の展望

  • 色々なサービスの設計から実装までできるエンジニアになりたいです。
  • AWSの中でも最適なサービスを選択してサービスを開発できるようになりたいです。

1年を通しての感想

異業種からの転職で実際のエンジニアとの関わりがなかった身からすると、「どんな人がどんな風に開発しているのだろう」と全てが新鮮な状態で転職してきたことを覚えています。

受託開発ということで案件ごとに全く異なるサービスの開発、お客様に関ることができ、多くの経験が積めたと思います。1年前の自分と比べて1番成長を感じたのはAWS周りの理解だと思います。案件ごとに新規開発とインフラの構築がありそれに関われたことがよかったのだと思います。

その他にも、LINE APIについての理解が深まり個人サービスまで作ることができたのはよかったです。良いアイデアが思いついたら何かサービスは作っていきたいと思っています。

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?