開発未経験のエンジニアでも開発業務に就くことができるプロジェクト（つづき）

# 概要

未経験のエンジニアの方でどうやったら開発に業務に携われることができるかご相談を受けました。相談に対して回答していく中で２人で一緒に何か作っていこうという話になり、それ自体をプロジェクトとして発足しました。

8月度から継続で活動している内容になり、今回の記事は9月の内容をまとめております。8月の活動記録については以下の記事にまとめておりますので、ご興味がありましたらお読みいただければ幸いです。

■開発未経験のエンジニアでも開発業務に就くことができるプロジェクト
https://qiita.com/tamoco/items/cf657ec4d74ccbf4d493

今回はこのプロジェクトを行うことで実際に企業に面談に行く機会が増えてきました。実は開発業務に就くことができたのは9月の話で、現場が決まるまでもう少しお話がつづいています。そういった経緯も赤裸々に記事としてまとめてみましたのでぜひお読みいただければ幸いです。

# 前回(8月)は何をやったか

いろいろと２人で一緒に考えたり作業したりして以下のことができています。

- 簡易なインセプションデッキを作ることで方向性を定める
  - 目標設定の洗い出し
  - やりたいことの具体化
  - 使用する技術の選定
- 開発環境構築
  - ペアプロで開発するために環境の差をなくす
  - どの環境でも動くようにコンテナで環境の準備を整えた
- アプリケーションの作成
  - GitLabによるIssueでのタスク管理
  - 開発環境が不便と感じたら改善も行う
  - チャットアプリとして完成させることができた
- ポートフォリオの作成
  - 作成したのは単純なチャットアプリだが使っている技術は多かった
  - ポートフォリオで取り組みの経緯や使用技術に関する情報を記載
  - 成果物と併せてエンジニアとしてPRできる資料として準備することができた

# 9月は何をすることになったのか？

![8_23（日） 振り返り (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412322/07df370d-67dd-7b3a-e996-cd157be2b319.png)

8/23(月)の振り返りの`KPT`から「作ったモノをベースに新しいモノを作る」というモノがトライとして挙がりました。そのためポートフォリオが完了したのと同時にチャットアプリはクローズして、開発環境（コンテナの構成）などは引き継いで別のアプリケーションを作ることにしました。

そして何をつくるのかこれまでと同じような形で一緒に考えてみました。

![今後どういったモノをつくりたい？.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412322/6cca947e-3d52-6079-96ce-70814b24f0c1.png)

とりあえず思いついた機能を書いています。意外と少ない感じで作業に入るとアレもコレも必要だなということが多かったりします。これも１つの経験になるのかなと・・・。

# ひたすら作業

`GitLab`の別のプロジェクトとして作業を続けていきました。

https://gitlab.com/vorwort.k/spring-todo

必要な機能を`GitLab`の`Issue`として作成して実装していきます。8月と同じようにペアプロで一緒に作業しながら１つずつの機能を実現していきます。意外にやることが多くなりそうだったので必要最低限の機能に絞りながら後で拡充できるように取り組みました。

# 企業面談が決まることで割り込むタスク

日々作業を続けている中で未経験のエンジニアの方に企業面談のお話があったようです。企業面談に行くにあたり、会社（企業面談先の企業ではなく所属しているSES）からはコードの開示をお願いされました。単純に`GitLab`のプロジェクトをパブリックにして公開するだけだとPRにつながらない可能性も考えられます。実際に未経験のエンジニアの方もコードを公開するに対して不安があるようだったので効果的にPRする方法を整理していみました。

![コードの公開を効果的にPRするには？.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412322/92136828-5caa-ed48-27d6-477df022cc8e.jpeg)

現状の課題として未経験エンジニアの方の不安を、現状の課題として書いてもらいました。結構不安に思われていることが出てくるモノですね。

現状の課題に対して解消できそうな解決案を一緒に考えていきました。単純にコードを公開して説明できるかどうかという不安が大きいようなので、そこをフォローする解決案を選択しました。

そして実際に取ったアクションは`GitLab`の`Wiki`を作成していただきました。`Wiki`にはこれまで行ってきたインセプションデッキや振り返りの内容などを記述したり、継続して行っているプロジェクトについても記述しています。こういった成果物に対する解説があるだけで印象が大きく変わると思われます。

[GitLabのWiki: プロジェクトの経緯と今後] (https://gitlab.com/vorwort.k/yasuda-spring/-/wikis/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E7%B5%8C%E7%B7%AF%E3%81%A8%E4%BB%8A%E5%BE%8C)

## 余談
会社（企業面談先の企業ではなく所属しているSES）からはコード量が少ないのでコードの一部だけ見せればよいのではというお話もあったようで解決案として追加しています。複雑なアルゴリズムなどが書いてあればそういった解決案も有効そうです。ただし、今回の場合はコード量も少なく一部だけみせた場合の効果は薄いと考えて採用を見送りました。


# 企業面談に行った結果

未経験エンジニアの方に話を伺うと成果物に対するリアクションはそこまでなく感触が微妙とのことでした。設計書や定義所を作成した経験を問われた際に回答にするのに困ったとのことです。9/13（日）の振り返りでも`Probrem`として挙がりました。

![9_13（日） 今週の振り返り.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412322/3ace99a0-7fc8-c43f-4015-b504e7149b11.jpeg)

## 企業面談を踏まえてこれからやること（Tryの設定）

企業面談での課題も改善活動して取り込みつつチャレンジすることにしました。具体的には「仕様書を作ってみる」ということですが、単純に仕様書を作ってみるだけだと面白味がなかったので`Swagger`によるAPI定義や`Schemaspy`によるER図を自動生成することをTryとして設定しました。

継続的にチャレンジし続けた結果、`schemaspy`でER図を作成し`.gitlab.ci`で`pages`に公開することができました。本音をいうとパイプラインの処理の`dind(docker-in-docker)`でER図を作成してそれを`pages`にデプロイしたいところですが一旦は公開して閲覧できるようにしています。

[scheamaspyによるER図] (https://vorwort.k.gitlab.io/spring-todo)


## 実際にはすでに内定はいただいていた・・・
１週間後にわかったことですがこの企業面談で内定をいただくことができました。結果的には無事に開発業務に就けることになりましたが、上記のTryは継続的に続けていくことにしました。内定をいただいたことによって一旦このプロジェクトは完了することにしました。

# このプロジェクトを振り返って

たった２人のプロジェクトとして始まりましたがチームとして考えながら進めてこれました。少しずつ有効だと思える成果物を作っていくことで、「開発業務に就く」という目標を達成することができました。
開発未経験のエンジニアの方でも一緒になって考えて進めていけばエンジニアの技術や考え方は成長し評価されるようになりました。技術力やPR方法がわからず不安なエンジニアの方もいらっしゃると思いますが、今回のようなアプローチを少しでもお役に立てれば幸いです。