ID:54620さん

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

# 概要 サービス内新規コンテンツの開発 # 担当 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でも実現できるとわかったのでその方針で進めました。 結果的にグラフ描画についての工数をほぼデザイナー側で賄う事ができ、エンジニアはロジックの構築に専念する事ができました。 ## リモート下での効率的な開発 開発期間が短いので、毎日朝会を行って進捗確認や相談を行っていましたが、それ以外でもわからなくなった時は都度画面共有をしながらペアプロを行いました。 その結果最初の見積もりよりも半月ほど前倒しでリリースする事ができました。