ID:54620さん

# 所属 オープンワーク株式会社 # 概要 企業と求職者をマッチングさせるプロダクトの機能開発 # 体制 - PM 1名 - 開発リーダー 1名 - エンジニア 4名 - デザイナー 1名 # 担当 開発リーダー # 使用技術 PHP, Symfony, Vue.js, MySQL, ElasticSearch # 課題 企業向けのサービスの開発をメインで行っていましたが、企業によってプランが複数存在し使える機能にも違いがありました。 また、同じ機能でもプランによって表示を変えたり機能制限を設けていたりしました。 そのようなプロダクトで、あるプランで提供している大きめな機能を別のプランでも使えるようにする開発を3, 4度行いました。（総差分行数1万〜3万程度） 同じような開発はそれまでもよく行われてきていたのですが、if文を追加するやり方で実装されている事が多くソースが難解になっていました。 # 取り組み 過去の踏襲で分岐を追加して実現させていくのではなく、保守性を考えた新たな方法で実装を行いました。 まず、プラン間で共通する処理とそうでない処理があるので、共通しない処理を業務知識としてドメインレイヤに切り出し、クラスを分けました。 そうする事でユニットテストをシンプルに書く事ができたり、ユニットテスト自体で条件の説明ができるようになりました。 また、これを実現するためには既存の処理もリファクタリングする必要があるので、合わせて行いました。 次に、あまりにも共通する処理が少ない場合はURL（route）から新しくするようにしました。 そうする事でControllerレベルで別の処理を用意する事ができ、見通しが良くなりました。 ソースが読みやすくなったおかげでソースコードレビューやテストもスムーズに行われ、毎回期限内にリリースする事ができました。 # 工夫した点 ## 粒度に合わせて最適な実装を選択 設計は常に1つの選択肢でうまくいくわけではないので、常に複数の選択肢を持っている状態にし その時最適なものを選んでいく事ができたと思います。 また、各選択肢のデメリットも理解した上で進められたかと思っています。 例えばURLを変更する場合、一度払い出してしまったURLはブックマークされていたり、メールに残っている可能性もあるので安易に変更ができません。 私の担当した時のケースでは、該当プランでは新規扱いの機能だったためそういった選択肢が取れました。 ## ユビキタス言語の遵守 プロダクト開発は関係者が多くなってきたり歴史が深くなっていくと、共通言語に揺れが生じてくると思います。 完全に統一することは難しくても、自分が担当する物に関しては極力統一するようにしています。 例えば企業向けサイトの開発を行う時、一般ユーザ向けの機能にも影響があって一緒に改修する事があります。 そういった時のクラスや変数の命名、仕様書での記載は統一するように心がけていました。 その結果、他者に見てもらう時に理解してもらいやすく、コミュニケーション齟齬が起きにくいプロジェクトになりました。

# 所属 オープンワーク株式会社 # 概要 サービス内新規コンテンツの開発 # 体制 - PM 1名 - 開発リーダー 1名 - エンジニア 1名 - デザイナー 1名 - アナリスト 1名 # 担当 PM1名、開発2名、デザイナー1名、アナリスト1名体制での、開発リーダー # 使用技術 PHP, Symfony, Python, MySQL, ElasticSearch, ECR, Docker Compose # 課題 ## サービスとしての課題 弊社では世の中の会社のクチコミを載せているサービスを運営していますが、実は求人もあって応募もできるサービスです。 しかし、そういった就職マッチングサイトという認知度がまだまだ低いので、そこに課題がありました。 その課題を解決するための一つとして、各会社の推定年収グラフを一新し、唯一のコンテンツを用意することでサイト流入を増やしたり就職マッチングサイトとしての価値を高めていくというプロジェクトが立ち上がり、そこに参画しました。 開発のみで終わるプロジェクトで終わるものではなく、その後のプロモーションの予定も立っていたプロジェクトでした。 以下プロモーション活動の一部です。 https://newspicks.com/news/5434914/body/ ## 開発における課題 現行サービスではPHPを利用していますが、年収データを算出する計算ロジックをPHPの関数で実現できない事が途中でわかりました。（行列計算を行うため） また、プロモーション開始時期が決まっていた（つまり期限が決まっていた）中で、通常の開発で実現できないので工数を掛けない他の方法を考える必要がありました。 # 取り組み ## 技術選定 PHPではなくPythonであれば簡単に実現が可能だという事がわかったので、計算ロジックのみ別サーバーを作成して実装することにしました。 また、最初は年収グラフの描画を外部ライブラリを使って描画する想定でいましたが、工数やライセンス管理の煩雑さを考え自前でシンプルなviewを実装することにしました。 # 工夫した点 ## 適切な分担 経験言語によって担当を分ける事で効率的に進めました。 もう1人の開発メンバーがPythonの経験があったのでその実装を全て任せました。 そこに集中してもらうため、私は以下のようなそれ以外の作業を全て行いました。 - PHPの実装 - 共通利用するテーブルの設計・実装 - Python環境の整備をインフラエンジニアと進める - Python実装のソースコードレビュー - PMとの連携 - 進捗管理 Pythonの実装に集中してもらう事だけではなく、私の方で先にPHP側の実装を終わらせられそうだったので、終わった後にヘルプに入れると考えてこのような配分にしました。 結果的にスムーズに開発が進み、スケジュール内にリリースすることができました。 ## 見通しの良い設計 私の実装範囲の話です。 既存ページ内の機能を作り直す開発でしたが、既存のソースコードは古く複雑・難解になっていました。 そこで、既存の記述を思い切って全て削除し、DDDの観点で新たに設計・実装を行いました。 各層（Presentation, usecase, domain, infrastructure）を用意し実装を進めていきましたが、その結果以下のような成果が得られました。 - 層単位でユニットテストが書けた - 層単位でコードレビューを依頼でき、レビュワーの負担も小さくできた - ソースコードの見通しが全体的に良くなり、テスト後の修正もやり易かった ## MVPを意識した技術選定 ギリギリまで開発をしないように、MVPでリリースするということを意識しました。 要件を詰めながら並行して設計を行っていたのですが、その中でも削れそうな箇所としてグラフ描画の部分でした。 既存の機能でHighchartsというグラフ描画ライブラリ（javascript製）を利用していたので、当初は同じようにして利用できないかと考えていました。 しかし、ライブラリで用意されている定型的なグラフでは表現が難しく、ライブラリ自体のキャッチアップも時間がかかりそうでした。 そこで、わざわざHighchartsを使わなくても表現できるのでは、と考え要件をPMと見直したところ SSRでも実現できるとわかったのでその方針で進めました。 結果的にグラフ描画についての工数をほぼデザイナー側で賄う事ができ、エンジニアはロジックの構築に専念する事ができました。 ## リモート下での効率的な開発 開発期間が短いので、毎日朝会を行って進捗確認や相談を行っていましたが、それ以外でもわからなくなった時は都度画面共有をしながらペアプロを行いました。 その結果最初の見積もりよりも半月ほど前倒しでリリースする事ができました。

# 所属 株式会社LIFULL # 概要 不動産ポータルサイトにて、toBの商品を開発 売上を支える規模の注力商品 開発期間 - 1ヶ月目 β版をリリースし、PMFを測る - 2〜4ヶ月目 本リリース - 5〜8ヶ月目 追加機能リリース # 機能詳細 - B側のユーザが操作する管理画面にて企業の紹介動画をアップロードできるようにする - B側の管理画面にて、どの物件のページで動画を表示させるか選択できるようにする - アップロードされた動画をC側の画面で再生できるようにする - 動画を掲載しているクライアントが検索結果にて上位に表示されるようにする など。 # 体制 - 企画職 2名 - テックリード 1名 - エンジニア 5名 - デザイナー 1名 - サポートエンジニア 1名 # 担当 - テックリード - 全体システム・運用設計 - プロジェクト進捗管理 - アプリケーションのバックエンド側開発 - インフラ、フロント含むコードレビュー - リリース計画 - DBスキーマ更新、依存関係のあるリポジトリなど - テスト計画 # 使用技術 - PHP（Symfony） - typescript（Express） - ruby（sinatra） # 特筆したいポイント ## 多くのリポジトリに改修が必要 ### 苦労した点 - この会社では領域ごとにマイクロサービス化・BFF化されているため、細かいものも含め改修するリポジトリが11個に渡りました。そのうち3リポジトリは他部署管轄のものでした。 - そのうち私が手を動かし実装したリポジトリは7つでした。また、その他のリポジトリについても設計相談やレビューを含めると全てのリポジトリに関わりました。 - 改修が多岐にわたることで手間やコストがかかるという点だけではなく、リリース時に依存関係を考慮した手順にする必要がありました。リリースは自部署では完結せず、各部署に調整をかけリリース日の作業を依頼しました。 ### 工夫した点 - なるべく並行タスクを作らないよう専任レビュワーを置いたり、テストの実施は企画職やデザイナーに任せるなどリソース調整を工夫して実装に集中できる環境を作りました。 - 各リリースのタイミングを一覧化し、プロジェクト全体で合意形成して進めたことで、当日慌てずに進めることができました。（緊急時のロールバック手順も準備していました。） ## 運用フローの構築 ### 苦労した点 - 動画のアップロード先をS3にすること自体は早い段階から決まっており特に問題はなかったのですが、アップロードする元のサーバーがWAF内にあることで、動画等のサイズの大きいファイルの通信が出来ないことが判明しました。 - そのため、動画のアップロード機能を1から作ることとなり、想定工数をオーバーすることが判明しました。 - 動画アップロード機能を1から作る場合、1ヶ月程度の遅延が見込まれました。しかし、営業活動が進んでいたこともあり機能リリースを1ヶ月遅らせることはできませんでした。 ### 工夫した点 - 動画のアップロードの機能以外は完成見込みだったため、動画のアップロードのみ手動で運用することを決断しました。 - いくつかのツールにて要件を満たすか検証を重ね、最も簡易的に実現できると判断したgoogle form・googleドライブを利用することにしました。 - クライアントに操作していただくことになるため、営業メンバーに細かくヒアリングし問題ないことを確認した上での決定でした。 - 手動アップロードにより保存されたデータが、その後のリリースで自動アップロードになった場合でも問題なく動くような設計や命名ルールにしました。 # その他 - 不動産業界のため、1~3月は繁忙期です。繁忙期中にリリースすることがマストでしたが、遅延せずリリースすることができました。そして、私はこの期間週休3日制を利用していたため、週4日の勤務で達成しています。