## プロジェクト概要
### プロジェクト要約
開発体制を組織し、外部ベンダーに委託していたプロダクト開発を自社内で内製化するプロジェクト
### 背景
開発の依頼のために細かい仕様書の作成を求められる、発注から開発着手まで3週間の期間が空く、1行の文言修正に工期2週間で10万かかるなど、プロダクト開発を推し進める上で外部ベンダーとのやり取りや費用感、開発スピードがネックになっていた。こうした課題を解決し、よりクイックかつ柔軟な開発を行うべく、本プロジェクトが持ち上がった。
### プロジェクト規模
#### 期間
1年間
#### メンバー
- 開発エンジニア兼エンジニア採用担当：1名
#### 担当
開発エンジニア兼エンジニア採用担当
### プロダクト概要
経営課題を抱えた企業とコンサルタントをマッチングさせる Webアプリケーション。企業からは案件の提示やコンサルタントのスカウトが行え、コンサルタントからは案件への応募、スカウトへの返答などが行える。システムの構造だけ見ると、採用サービスとよく似ている。
#### 使用技術
- JavaScript
- jQuery
- Laravel blade
- PHP
- Laravel
- MySQL
- AWS
- Docker
### 本案件から得た貴社で役立てられる経験
- 開発業務の内製化
- 0からのエンジニア採用：半年で3名のエンジニアを獲得
- AWS, Docker 開発環境構築
- Laravel アプリケーション開発
### プロジェクト全体を通じて苦労したこと
- 技術的な相談が出来る人の不在。エンジニアは自分一人で、行き詰ったことは調べるか、Q&Aサイトで聞くか、メンタリングサービスを活用するかで乗り切っていった。
- 外部ベンダーとの関係性構築。必要な情報は引き出しつつ、内製化しようとしていることは知られないようにしつつ、という塩梅の調整に苦労した。不信感を持たれず、開発出来る範囲を増やしていくということを意識しながら、LPの修正→軽微な機能修正→大き目な既存機能の修正→新規機能開発と手を広げていった。
## プロジェクト詳細
### AWS 開発環境構築
#### 前提
- 兎にも角にも開発環境がないことには始まらないと考えた
- 最初は本番環境の AWS 上で動いているアプリケーションと GitHub リポジトリのみがある状態
#### 課題
- 外部ベンダーに開発環境構築手順の共有を依頼するも、社内の独自環境を使っているため手順がないとの返答を得た
#### 解決策
- 本番環境の AWS 上のアプリケーションを参考に、AWS 上で開発が行える環境を作成した
- 書籍や AWS の公式オンデマンドを参考にインプットを行った
- IAM, VPC, EC2, RDS, Route53, S3, SES, Workmail から構成した
- VSCode の拡張機能を用いることで、AWS 環境のソースコードへのアクセスを可能にした
#### 苦労した点
- AWS キャッチアップの際の言葉や概念の理解。
- アクセス時に画面が描画されない原因の特定。「このサイトにアクセスできません」の画面のデバッグに時間がかかった。
- VSCode から AWS 環境に接続する際の SSH 接続に失敗原因の特定。色んなソースに当たったが、自分の環境にマッチするエラーがなかった。
### Docker 開発環境構築
#### 前提
- AWS 開発環境のみがある状態
#### 課題
- 今後エンジニアを増やしていくにあたり、各個人向けに AWS 上に環境を構築していたら莫大なコストがかかる
#### 解決策
- AWS 開発環境を参考に、Docker 環境を作成した
- 書籍や公式ドキュメント、外部メンタリングサービスの情報を参考にインプットを行った
- 本番環境を真似て、APP コンテナと DB コンテナからなる構成で作成
#### 苦労した点
- docker-compose.yml の構成方法。公式ドキュメントのベストプラクティスを参考に作成した。
- イメージの選定とインストールが必要なコマンドの特定。本番環境と差異がないよう、phpinfo を頼りに1つ1つ確かめていった。
- APPコンテナが上手く立ち上がらないエラー解決。Windows + WSL2 + Docker の構成特有のエラーらしく、解決に時間を要した。
### LP の修正
#### 前提
- Docker 開発環境がある
- アプリケーションのキャッチアップがまだ十分には行えていない状態
#### 課題
- 内製化を推し進めていることを外部ベンダーに知られたくないが、開発は行っていく必要がある
#### 解決策
- 短いサイクルで修正を重ねたいという意図があり、かつロジックの面ではアプリケーションへの影響が少ない LP の修正を交渉し、本番反映までこぎつけた
#### 苦労した点
- 外部ベンダーとの交渉。修正を素早く行っていきたいという意図を伝えつつ、不具合があった際にはこちらで責任を持つ、という取り決めで合意に至った。
### 利用方法紹介用モーダルの実装
#### 前提
- Docker 開発環境がある
- アプリケーションのキャッチアップがまだ十分には行えていない状態
- LP の改修実績はある状態
#### 課題
- 本格的にアプリケーションに手を加えていきたいが、まだベンダーからは開発許可が取れていない状態
- 初見のユーザからアプリケーションの使い方がよく分からないという声が上がっていた
#### 解決策
- ボタンを押すと利用方法モーダルが立ち上がるという比較的影響の少ない機能を追加し、本番反映してよいかという体で交渉に臨み、合意に至った
#### 苦労した点
- 既存コードへの影響調査。jQuery のコードがあちこちのファイルからインポートされていたことに起因する。
### タグ表示および検索機能の追加
#### 前提
- Docker 開発環境がある
- 軽微な機能開発を行った状態
- 何とはなしにアプリケーションのキャッチアップを行えた状態
#### 課題
- 本格的なアプリケーションの開発を行っていく必要がある
- 企業様から「今案件を探しているコンサルタントは誰なのか把握したい」「情報更新があったコンサルタントを知りたい」との声があがっていた
#### 解決策
- コンサルタントにタグ付けを行い、表示および検索をかける機能を追加した
- DB でタグを保持するカラムを持っておき、Laravel の Eloquent を用いて更新およびデータ取得、jQuery + blade で出し分けを行う
- 外部ベンダーには、テストをお願いする形で協力を依頼した
#### 苦労した点
- 既存コードの読解。変数名が1文字、_ 始まりなのにクラスの外から参照される関数がある、if 文の3重のネストなど、中々に読み応えのあるコードの書き方がされていた。
### エンジニア採用
#### 前提
- エンジニアは自分1人
#### 課題
- 外部ベンダーを切り離しても安定的に開発を進められる体制を作るべく、最低あと2名はエンジニアを獲得したい
- エンジニア採用のノウハウは一切ない状態
#### 解決策
- 社内で利用実績のあった採用媒体でエンジニアにリーチできそうなものの運用に着手した
- 履歴書情報を元に刺さりそうな文言を一人一人考え、スカウトを打った
- 社外のエンジニア採用セミナーに参加し、求人情報をブラッシュアップした
- 人事の方に情報をエンジニアに関する情報を共有し、スカウトやエージェントへの展開を依頼した
- 自分でも採用サービスに登録し、心惹かれたスカウト文言は徹底的に取り入れていった
#### 苦労した点
- 面談実施数を伸ばす方法。そもそも認知をとるのも難しい上、他社と比べて売れるものが少ないという点で苦労した。
- 相手の経験を引き出す会話方法。素の姿を教えていただくにはどうしたらいいのかと試行錯誤した。
### お気に入り機能の追加
#### 前提
- エンジニアが自分以外に1人入ってくださったタイミング
- 外部ベンダーも薄々こちらの動きを察し出した状況
#### 課題
- 新しく参画してくださったエンジニアの方の定着を図る必要がある
- 社内から「気に入ったコンサルタントにすぐにリーチ出来るようにして欲しい」との声が上がっていた
#### 解決策
- お気に入り機能の要件定義～開発の手前までの切り分けを行い、手を動かすフェーズを新規参画してくださったエンジニアの方にお任せした
#### 苦労した点
- ドメイン知識の共有。暫く触れていて自分では当たり前になっていたことも、初見の人からするとほとんど未知のものであるということもしばしばあった。