you-saku

# HRテックのSaaSを開発していました ## プロジェクト概要 * 約70問ほどの質問に答えて性格判定をする。その性格判定を人事異動や査定評価に活用する企業向けWebアプリケーションです。主に企業の人事担当者が企業の従業員さんのために利用します。 * 人材育成をより正確にそしてパーソナルに行える世界観を作るのがプロジェクトの目的です * 私はそこのWebアプリケーション開発のために参加することになりました ## 開発規模 * バックエンド：3人(社内) * フロントエンド：2人(社内) * デザイナー：1人 (社内) * 先方：3人 ## 経験業務 ### 開発 * LaravelでのCRUD作成 * GraphQLのデータ取得クエリを作成 * コードレビュー ### 開発以外 * SendGridの技術調査 ## プロジェクトにあった課題 1. お客様がサービスを利用するために必要なデータの流し込みが手作業で一回一回手順書を1から作成していた。 ## プロジェクト内で工夫した点 1. 先方へデータ流し込み手順を逐一丁寧に書く(実行するコマンドをコピペで作れるようにする) 非エンジニアを相手にするため何度も何度もレビューをいただきました。そして非エンジニアや初見でコマンドを打つ人の気持ちを汲み取れてなかったことに気づくことができました。 ## 工夫して得た成果 1. 非エンジニアの先方でもデータ流し込みができるようになった この経験からドキュメントを残す際には「誰でもわかることが大事」、「詳しすぎるくらい詳細に書くことで行間を読んでもらう必要をなくす」という意識を持つことができるようになりました。

# toB向けかつtoC向けのプラットフォームを開発していました ## プロジェクト概要 * がん患者さんとがんのプロをつなぐコンシェルジュサービス。また、がんの情報提供に特化しており、多くの役立ち情報やクーポンを提供する。特定のがん保険に加入しているがん患者さんや企業の従業員さんのためのサービス * がんの疑いを受けてから治療完了までを一気通貫でサポートできるサービスを目指している * 私はそこのWebアプリケーション開発のために参加することになりました ## 開発規模 * バックエンド ：最低2人~ピーク時8人(社内+業務委託) * フロントエンド 最低3人~ピーク時9人(社内+業務委託) * PM 1人~2人 (社内+業務委託) * 先方 5人~ (PO, テックリードx2, デザイナー, データ分析係, ビジネスサイド etc) ## 経験業務 ### 開発 * LaravelでのCRUD作成 * RDBのスキーマ作成 * NoSQLのスキーマ作成 * Salesforceとのデータ連携 * 外部サービスとのAPI連携 * コードレビュー * 小規模機能の開発リーダー * リファクタリング ### 開発以外 * 先方との要件決め * ブランチ戦略の可視化と共有 * 後輩エンジニアとのペアプログラミング * 技術調査と実装(サーバー&フロント), ドキュメント作成 * 定例議事録の作成 * 社内向けドキュメントの作成 * 社内向けAWS作業手順書作成 * 保守をしながらの新機能開発 * 本番リリース手順書の作成 ## プロジェクトにあった課題 1. リリース頻度の高さに対する実行コストの高さ 1. 継ぎ足しで作ったコードで機能の理解が芳しくない 1. PjMとPLへの属人化による、チーム内重要度の偏り 1. 開発人数の多さによる共通認識のズレ ## プロジェクト内で工夫した点 1. リリース手順書のテンプレ化 1. コードのリファクタリングと処理フローの図解、仕様まとめ 1. 開発タスクの巻き取り。それに伴う先方とのコミュニケーション実施 1. データスキーマをフロントと決めてからWebAPI開発を始める。デイリーミーティング外での積極的なコミュニケーションを行い、開発 ## 工夫して得た成果 1. リリース手順書をテンプレ化することでリリース準備が大幅に減った。先方にリリース作業を行うことも可能になり、エンジニアは開発に集中できるようになった 1. 最適解かどうかは別としてリファクタリングによってコード量が大幅に減った。また、機能のドキュメント拡充により内部外部関係なく共通認識を持ちやすくなった。 1. 雑務の依頼や仕様の質問がリードエンジニアやPMへ集中しなくなった。重要な役職の方が自分の責務に集中できる環境を構築できた 1. データスキーマを決めてから開発するのでWebAPIを作ってからフロントとサーバーサイドで認識の齟齬が発生しなくなった。モックの作成も容易になった。また、seedデータを都度整えることでフロントエンドエンジニアのローカル開発がしやすくなった。