Eito

### プロジェクト概要 このプロジェクトは既に別の開発会社が3割程度作りかけていたのですが、開発会社の都合で納品することが難しくなったため、弊社に依頼されました。 ### チーム構成 * PM × 1（私） * エンジニア × 3名（私を含む） ### 本プロジェクトでやったこと * プロジェクトマネージャー(要件定義を含む顧客折衝, スケジュール管理, タスクの切り出しと開発チーム内のエンジニアへの割り振り) * バックエンド, フロントエンドの開発(主に担当した機能…カート機能、商品購入機能、パスワードリセット機能、csvでの商品登録/削除機能、請求書/納品書のPDF出力機能など) * フィードバック対応と修正 *サーバーの移管 *開発メンバーのコードレビュー ### 課題 * 元のソースコードはControllerにビジネスロジックが書かれていたり、ハードコーディングが所々されていたりとソースコードの品質が悪かった * テンプレートリポジトリを元に開発していたためか、使用されているコードと使用されていないコードが存在していた * 請求書の発行や会員ランクによる商品価格のかけ率計算等のややこしい計算式が画面によって計算式が微妙に異なっていた ### 取り組み * 元のソースコードを全て書き換えると大幅な改修が必要なので、既存のコードは残しつつ、弊社側で書く部分のコードだけは可能な限り拡張性や保守性を考慮したコードを書くようにしました * コードを削除することで、動いていた部分が動かなくなったりしないように明らかに使われていないコードや余分なコメントアウトのみを削除しました。 * スプレッドシートで要件定義をするときに計算式の仕様のみ別シートにまとめ、開発メンバーに仕様を分かりやすく共有し、リモートで開発をする際はMeetでもくもく会を開くことで、コミュニケーションを多くとりながら開発をしました。 ### 工夫したこと * 開発メンバーの手持ちのプロジェクトの忙しさを考慮し、工数にバッファを持たせたスケジュールで開発を進めた * 互いにタスクを巻き取りやすくするために完了させることが難しそうなタスクに関しては期限5日前にはチーム内で共有することをルール決めしました。

### プロジェクト概要 恋愛マッチングアプリのPHP(Symfony) からPHP(Laravel)へのリプレイスとリファクタリングを行いました。 ### チーム構成 * PM × 1 * エンジニア × 5名（私を含む） ### 本プロジェクトでやったこと * バックエンド, フロントエンドの開発(主に担当した機能…ユーザースワイプ機能(マッチングアプリのユーザーをOKかNGに仕分ける機能)、ユーザー登録機能、運営からのニュースをpush通知/メール送信する機能、LaravelのSoftDeletesをオーバライドしたtraitの作成など) * フィードバック修正 * 開発メンバーのコードレビュー ### 課題 * 詳細設計を書いたことのなかったエンジニアが、設計書を作成したため、開発している途中で開発者が設計書の間違いに気づき、大幅に設計書の修正が行われるというのが度々起こった * 新しく未経験で入社したエンジニアが複数人、このプロジェクトに参加したことで、コードレビューの工数が増えた ### 取り組み * マッチングアプリのスワイプ画面などの処理や考慮事項が多い機能を作るときには、コードを書く前にXmindというマインドマップアプリを使って、フローチャートを作成し、本当に設計書が合っているのかをリプレイス前のソースコードや設計書の作成者に細かく確認をとりながら開発を行いました。 * 未経験で入社した方にはプルリクに指摘したコメント等を元に"プルリク提出前チェックシート"を作ってもらい、プルリクエストを出す前にそのチェックシートに沿って確認してから提出してもらうようにした * DBから取得する情報などによって変数名の命名を形式化した ### 工夫したこと 個人的な経験ですが、開発経験が少なかった時に一人で1時間以上も調べていたことが他の人に聞いたら3分で解決したということが度々あったので、新しく入ったエンジニアの方には分からないことがあったら、私を含む開発経験が1年以上あるエンジニアにどんなに忙しそうにしていても、質問してもらうようにした

### プロジェクト概要 妊婦さん向けの情報を発信するメディアアプリで、殆どの機能は別の開発会社が作りました。 ### チーム構成 * PM × 1（私） * エンジニア × 2名（私含む） ### 本プロジェクトでやったこと * 顧客折衝(要件定義含む) *アプリケーションの速度改善の調査と実施 *サーバー移管 *既存バグの修正 * フィードバック対応と修正 *機能開発の提案 ### 課題 * 書いてあるが、実際には使われていないコードがある * 変数名やコメントが適当だったりでコードの品質が低い ### 取り組み * 冗長なソースコード(loop処理の重複や無駄な条件式の削減)を書き換えた * DBからのデータ取得の仕方(テーブルを結合させてデータを取得することでデータベースへのアクセスを減らすなど)を書き換え、速度を改善した * 自分の作業範囲と重複していて、かつ、明らかに使われていないコードは適宜、削除した ### 工夫したこと 既に本番もリリースされているアプリだったので、どんなに汚いコードでも既存のコードには自分の作業範囲と重複しない限り、修正しないようにし、バグを出さないよう努めた

### プロジェクト概要 某国が日本で言うところのマイナンバーのような制度を導入するにあたって、国民のユーザー情報を管理するサービスを新規開発しました ### チーム構成 ・PM × 1 ・エンジニア × 8名（私） ### 本プロジェクトでやったこと * バックエンド, フロントエンドの開発(主に担当した機能…様々な証明書のpdf出力やダウンロード機能、モックの作成、管理画面側の市民情報の編集機能など) * 単体テストと統合テストの設計から実行 * サーバー構築 * フィードバック修正 ### 課題 * 扱うデータ量が非常に多い * 4つのアプリが各々連携しており、アプリケーションの仕様が複雑かつ作業量が多い ### 取り組み * 扱うデータ量が非常に多くなるため、DBへのアクセス回数やインサートの仕方にいつも以上に気を配った。chunkメソッド等を使用するなどしてメモリ使用量を抑えた。 * デザインパターンのDTOパターンを使用し、使用するデータを一括管理をすることで、無駄なDBへのアクセスを削減した。 * 納期が近くなった時は作業を分業体制にして、作業の効率化を図った ### 工夫したこと PMの作業量がかなり多く、残業でしんどそうだったため、PMの方と同じプロジェクトのタスクは可能な限り、こちら側で巻き取るようにした

### プロジェクト概要 Pixivに類似したイラスト投稿系アプリを新規開発しました ### チーム構成 * PM × 1 * エンジニア × 5名（私） ### 本プロジェクトでやったこと * バックエンド, フロントエンドの開発((主に担当した機能…イラスト/動画投稿機能, 運営からのニュースをユーザーにpush通知/メール通知する機能, ブロック機能など) * 単体テストと統合テストのテスト仕様書作成と実行 * 開発メンバーのコードレビュー * フィードバック修正 ### 課題 * 納期が短い * 開発メンバーが本プロジェクト以外にそれぞれ3つ程度のプロジェクトを掛け持ちしている ### 取り組み * 毎日、15分間のmtgを設け、各々の時間的リソースを1日にどれくらい割けそうかを開発チーム全体で共有し、メンバーの技術力と手の空き具合に合わせて、クライアントからのフィードバックを優先度順に手分けして対応した * 一部、統合テストがどうしてもリリース日に間に合わすことが出来なかったため、有料課金周りの機能やイラスト投稿機能などのアプリの核となる機能を優先的にテストし、それ以外の機能は開発メンバー全員でSTG環境でモンキーテストのみを行い、リリースした。その後、適宜、残りのテストと修正を終わらせた。 ### 工夫したこと * 納期が非常に短かったため、アプリの仕様的な観点で重要な機能を優先的に対応した * 仕様を十分に把握しているのが要件定義を行っているPMしか居なかったため、コミュニケーションコストを下げるために”ユーザーが投稿したイラスト作品のピックアップ数を集計する機能”を作った人は、それと類似した”ユーザーが投稿した動画作品のピックアップ数を集計する機能”も作るなど効率的にタスクを切り分けた

### プロジェクト概要 AR技術を使ったライブ配信サービスです。 このプロジェクトは私が入社する前から始まっていたプロジェクトでしたが、いわゆる炎上プロジェクトとなっていました。 私が入社した時は他の社員の方が担当していたものの、その方が退職することになり、私がプロジェクトの担当になりました。 ### チーム構成 * PM × 1（私） * ブリッジSE × 1名（オフショア） * エンジニア × 3名（オフショア） * 外部のAR開発会社 * 外部のデザイン会社 ### 本プロジェクトでやったこと * プロジェクトマネージャー(要件定義を含む顧客折衝, スケジュール管理, オフショアへの開発の指示, 外部開発会社の選定や依頼) * バックエンドの工数の少ない機能の開発(メール送信やバグの修正など) *アプリの速度改善を目的とした調査 ### 課題 * プロジェクトを引き継いだ時点でバグやデグレが多発しており、炎上していた * バグが多発しているせいで、毎週のように定例会でクライアントから怒られるため、プロジェクトを担当していた社内のエンジニアやオフショアのブリッジSE、エンジニアが次々と辞め、メンバーの入れ替わりが激しいせいで仕様を把握するのに時間がかかった * ユーザーへの振り込みの計算式などのややこしい仕様が多い、かつクライアントの求める仕様が頻繁に変わった * 外部のステークホルダーが多く、チャットのやり取りが多いせいで自分自身の他のプロジェクトにかける時間やコーディング時間が減少し、プルリクを出せる数が減った ### 取り組み * バグが頻繁に起きる原因を調査した結果、STGサーバーにdevelop_new, develop_oldなどの謎のブランチが沢山あったので、整理してもらい、a successful git branching modelに従ってブランチ管理をしてもらった * プルリクのタイトルやコミットのメッセージがあまりにも適当でバグが起きたときにどの修正分が問題なのかが追えなかったので、タイトルとコミットメッセージの書き方を形式化した * オフショアと弊社側の契約内容には単体・統合テストが含まれていたものの、バグの内容が明かにテストをしていないようなものだったので、開発者にSTGにデプロイした後に正常に挙動していることを示すスクショや動画をエビデンスとして提供してもらった * 定例会にブリッジSEだけではなく実際に開発を行なっているエンジニアにも出席してもらい、当事者意識を出来るだけ持ってもらうようにした * 計算式などのややこしい仕様をまとめたGoogleスライドを作り、仕様が変わるごとに変更した日付とともに更新した * ソースコードを読んだり、書いたりしているときにチャットに即レスするために目を離すと、自分が作業していたコードを追い直すのに時間がかかるため、チャットに返信する時間とソースコードを書く時間を時間帯で分けた ### 工夫したこと PMとしての時間だけではなく、Webエンジニアとして自分が手を動かす時間を捻出するために、タスク内容を把握した上で自分がやらなくても良いタスクは出来るだけ他人に任せた。 クライアントからは「〇〇(私の名前)さんがプロジェクトに入ってから、バグが少なくなった」という言葉をもらい、今でもこのプロジェクトのPMを担当しております。

### プロジェクト概要 恋愛マッチングアプリです。私が入社する前からリリースされているアプリで設計からリリースまで弊社とオフショアのパートナー会社で行なっています。 ### チーム構成 * PM × 1（私） * エンジニア × 4名（オフショアとフリーランス） ### 本プロジェクトでやったこと * プロジェクトマネージャー(要件定義を含む顧客折衝, スケジュール管理, オフショアへの開発の指示) *バックエンドの工数の少ない機能の開発(メール送信やバグの修正など) * Lambdaを使用したEC2インスタンスとRDSの自動起動/自動停止のスケジュール設定 *マーケティング、現状のアプリの仕様、クライアントの費用、技術的な観点(サーバーへの負荷など)、UI・UXに基づいたコンサル *アプリの速度改善を目的とした調査 ### 課題 * 追加機能を実装するときにWebデザイナーが日本語を話せないベトナムの方だったため、クライアントが希望するデザインにならずに要件定義が長引いた ### 取り組み * Webデザイナーとして実務経験のある私がサーバーへの負荷などの技術的な問題を考慮しつつ、Adobe XDでデモを作るのを画面共有しながら主にMTGでのやりとりで要件を定義していきました。 ### 工夫したこと 私が所属している会社ではコンサルの事業を行っていないのですが、クライアントからマーケティング面での課題を相談していただいたときに、その課題を解決するためにはどうしたら良いかを競合アプリを含む、様々なアプリの調査をし、定例会で提案した結果、いくつかの提案が承認され、実装されることになりました。 (例: 登録ステータスによる異なる文章でのメールの通知、ユーザー登録するための手入力を短く感じさせ、かつ開発工数が少ないUIの提案など)

### プロジェクト概要 このプロジェクトは現在進行中で、詳細設計を作成している段階です。 ### チーム構成 * PM × 1 * エンジニア × 1名（私） ### 本プロジェクトでやっていること * 要件定義 * 詳細設計 ### 工夫していること このプロジェクトは現在進行中のものですが、要件定義と詳細設計を担当しています。 * 詳細設計をする時は自分が書いているSQLが最適なデータの取得方法なのかを意識しながら、書いております * APIインターフェースを多次元配列にしないなど、RESTの原則に沿った開発者フレンドリーな設計書を作っています