BLOG

ブログ

新着記事

2020.07.31 Fabeee

【未経験】エンジニア1年生が社内副業制度で設計&開発をやってみる・その2

目次

  1. 1.自己紹介
  2. 2.おさらい(副業制度)
  3. 3.社内副業制度エントリー後の流れ
  4. 4.未経験が社内副業制度やるまで


こんにちは、Fabeeeの足軽こと「さむらい」です。
最近できたFabeeeの社内副業制度(通称Fabeeeクエスト)にエントリーして、
社内で副業をしてみたので、そのことについて書こうと思います。

※この記事はその1の続きとなりますので、まずその1から読んでいただけたら幸甚に存じます。

ただ、諸々の事情により、前回書いた担当範囲である「ツールの設計・実装」から、
「ツールの設計」のみが担当範囲となったので、
書くことがそこまで増えていないというのが、正直なところです。
なので今回は、「未経験として社内副業制度をやるまで何をしたか」を、追加で書きます。

 

1. 自己紹介

営業からFabeeeに未経験エンジニアとして2020年4月に転職をしてきた者です。

 

2. おさらい(副業制度)

制度が作られた背景や目的は前回の記事を参照してもらえればと思いますが、ざっくりどんな制度かおさらいすると、
<社内副業制度> is <社内で公募されてる業務をこなしたら現金がもらえる制度>です。

 

3. 社内副業制度エントリー後の流れ(その1の続き)

社内副業制度エントリー後は、下記の流れで進みます。
前回は1~4について記載したので、今回は4~7について書きます。
※今回私が担当したのは、「ツールの設計」業務です。

  1.       1. 案件内容の共有(打ち合わせか、テキストベース)
  2.       2. 先人達の成果物の確認
  3.       3. 担当する業務の方向性や認識のすり合わせ(基本Slack)
  4.       4. 業務遂行(不明点や相談点は都度Slack/プロジェクト管理ツールで)
  5.       5. 完了報告
  6.       6. レビュー/修正
  7.       7. 完了承認
  1.       4. 業務遂行(不明点や相談点は都度Slack/プロジェクト管理ツールで)
    •        すり合わせた内容を元に、設計を行いました。
    •        (ここまで来てもやはり、認識の相違などは生まれてしまうので、
    •        なるべく上流から設計→方向性確認→修正→下流を設計というように
    •        誤った方向に一気に進めて作業が無駄になることがないように注意しながらすすめました。)
  2.       5. レビュー/修正
    •        完成した段階で、プロジェクト管理ツールにて、レビューの依頼を行います。
    •        レビュー→修正を何度か行います。
  3.       6. 完了報告
    •       修正が完了するとプロジェクト管理者から、業務完了の旨を伝えられます。
  4.       7. 完了承認
    •        社内システムから申請書を提出し、業務完了した旨を報告し、承認を受けたら
    •        給料日を楽しみに待ちます。

 

4.未経験が社内副業制度やるまで

営業から転職して、未経験エンジニアとして入社した私が、社内副業をやるまで
どういうOJTをさせてもらったかを書きます。

 

    • CTO指導の元、一つのシステムを作ってみる(2か月弱)
      •       1. 設計
      •          まずはあえてがっつり設計ではなく、
      •           機能一覧やWBSを作ってはレビューをしてもらっていきました。
      •           ここで、システム作りにはまず整理することが必要なんだなぁと学びます。
      •       2. 仮想化地獄
      •           その後環境構築をしていくのですが、独学でRuby on Railsを学習していて、
      •           エンジニアになった気でいた私が、
      •           未経験おなじみ「何が分からないのか分からない」状態になりました。
      •           「VirtualBox内でDockerコンテナを立ち上げて、Djangoの開発サーバーを起動してみよう」
      •           Djangoが辛うじてPythonのフレームワークだと理解できましたが、他は全然わからず、
      •           意味を理解する所から始めて、試してエラーを出しては調べて試して、聞いてを繰り返して
      •           仮想化(DockerやらVirtualBoxやら)というものを少しずつ理解していきました。
      •        3. 楽しいアプリ開発
      •             初めてDjangoを使ってのアプリ制作に励んでいきました。
      •             自分の想像してたエンジニア像はこの部分だけでしたが、
      •             「意外とそうでもないのか?」と徐々に気づき始めます。
      •         4. デプロイ(HEROKUとの甘酸っぱい思い出)
      •           「デプロイ?HEROKUで一発じゃん」とか思っていましたが、全然そんなことはなく、
      •              今回はVMへのUbuntu環境のインストールからミドルウェアのインストール、
      •              VM側のアダプターの設定、
      •              Docker-composeが良しなにしていたDjangoとDBとの接続設定など盛りだくさんで、
      •             しっかり分かりませんでした。
      •        5. ドキュメントとテスト拷問
      •              今回はまだテスト設計をしていなかったので、設計をしていきます。
      •              このドキュメント記載量が半端ないと感じました。
      •              「あぁ、エンジニアってコード書いてればいいわけじゃないんだなぁ」と、
      •              少しだけ悟りを開きます。
      •               自分で書いたテストを、一つ一つチコチコと試しては、エラーを直していきます。
      •        6. API化とSPA化
      •              「完成!」と思ったのも束の間、
      •              「API(Django)とSPA(Vue.js)で分けてみよう」という、勅令が。
      •              「APIってぼんやり知ってはいたけど、作れるのか。SPAってなんだ」と、
      •              また分からない状態が始まります。
      •                Django REST Frameworkを使ってAPI化、Vue CLIを使ってSPAを作成していきました。

 

    • 上長指導の元、実際に人が使用するシステムを作ってみる(後半は上のOJTと並行しながら2か月)
      • ※長くなってしまうので、詳細は機会があれば書きます。
      • 今回は、ウォーターフォール型で開発を行っています。
      •       1. ヒアリング
      •               社内の管理部の方をクライアントに見立てて、1時間ほど必要なシステムの要件を伺いました。
      •       2. 外部設計
      •               ヒアリングを元に、今回は要件定義からAWSを想定したインフラ設計や画面設計など、
      •               実務で行われている設計を、がっつりレビューを頂きながら、行っていきました。
      •              (この辺りで、「エンジニア=プログラマー」という幻想は塵となっていました。)
      •       3. 内部設計
      •               機能詳細設計やAPI設計や画面詳細設計など、「ドキュメントな日々」を送りました。
      •       4. インフラ構築
      •              この辺りで、このシステム構築に新たな仲間が加わり、
      •              初めてチームでプロジェクトを運用していきます。
      •              チームでAWS上に環境を作っていきました。
      •       5. API、SPA作成(今ココ!!)
      •              プロジェクト管理ツールでタスクを割り振りながら、
      •              gitでコードを管理しながらプロジェクトを進めていきます。

 

  • 社内副業制度をやってみる(後半は上のOJTと並行しながら2、3週間)
    • まとめると、一通りの設計と実装を経験し、3,4カ月で社内副業制度に挑戦するまでに至りました。
    • 前回書いた通り、ツールの設計一つでもとても学ぶことがあり、
    • エンジニアの道のりは長いなと思う「さむらい」でした。