ID:45230さん

# プロジェクトの説明 2016年頃に業務委託で関わっていたプロジェクトです。 レストラン・飲食店をオンラインで予約をするWebサービス（食べログやRettyと同系統）で、価格層が少し高めの店舗の絞って掲載されるところが差別化のポイントです。 期間としてはリリース前から1年ほど関わっていました。 # 基本的な技術構成 当時は少し珍しかったSingle Page Applicationです。Backend for Frontendの層はExpressで構成されており、画面はRedux・Reactで開発を行っていました。私を含めたフロントエンドのメンバーの担当領域はAPI・デザインを以外を全てやるという割り振りでした。 技術的にはチャレンジしがいのある要素が多く、非常にやりがいのあるプロジェクトでしたが、アサイン直後の3ヶ月が苦労の連続でした。 - React・Reduxが実務初経験 - JavaScriptのテストコード（Mocha）を書くのも初めて - 外部から新規に参加したメンバーだったので、ドメイン知識が全然無い こうした要因が重なったことで、参加当初はかなり苦労しました。ですが、先にプロジェクトに参加していたメンバーのにドメイン知識を質問しまくり、実際にコードを書き続けて反復練習をすることでなんとか切り抜けました。 # チャレンジしたこと - 画面パーツのコンポーネント指向開発 - リリース後のリファクタリング ## 画面パーツのコンポーネント指向開発 それまではPHPやJavaといったサーバーサイドでHTMLを丸ごとをレンダリングする手法しかやったことがありませんでしたが、Reactでは画面をコンポーネント指向で開発していくことになります。開発アプローチするにあたって、[Atomic Design](https://atomicdesign.bradfrost.com/)をチーム全員で学びました。 昨年は自分の考えをアウトプットするため、コンポーネント指向開発の話を勉強会のLTで行いました。 https://speakerdeck.com/rukiadia/atomic-designdeyi-shi-sitaikoto-inspired-by-flocss ## リリース後のリファクタリング リリース後は作ってきた画面のコンポーネントの粒度の大きさや汎用性を振り返りつつ、数人のメンバーとリファクタリングに積極的に取り組んでいました。既にテストコードがあったことで安全にリファクタリングを進められたことは、今の自分の開発にも活きているように思えます。 ## 企画にも参加してみる コードを書くだけでなく、企画 # プロジェクトを振り返ってみて 最終的にはサービスが大きくグロースせずにチームも解散になってしまいましたが、得られるものは多くありました。 ## 良かったこと - 事例が多くない技術スタックでプロダクトを作る挑戦ができた。 - 規模の大きいチームで働けた。 この2つです。 ### 事例が多くない技術スタックでプロダクトを作る挑戦 当時のReactやNode.jsといったモダンな技術を使いつつ、試行錯誤しながらプロダクトを作るのは最高に楽しかったです。「使ったことない技術スタックでも必死にやればなんとか形にできる」という自信にもなっています。 ### 規模の大きいチームで働けた このプロジェクトのチームはデザイナーやQAも含めると30人超の人数で構成されていて、所属もバラバラでした。プロダクトを運営する社員の方をはじめ、他社から業務委託で出向してきている方やフリーランス契約の方もいらっしゃいました。 それまで制作会社の受託案件が主だった私にとっては初めての体験でした。私自身がマネージャーをやっていたわけではないですが、プロジェクトマネジメントのことを真剣に学ぼうと思ったきっかけになっています。 ## 反省したこと 巨大なPull Requestを作りがちだったことが大きな反省点です。 一人あたりのタスクの粒度が大きく、それを細かくタスク分解せずに通しでPull Requestを作ってしまっていました。レビュアーに大きな負荷を与えるし、手戻りが発生した時のコストも大きかったりと様々なデメリットがありました。 チーム開発をトラブルなく進められるよう、今はタスクの粒度を強く意識しています。

# プロジェクトの説明 現在所属している会社で行なったプロダクトの画面フルリニューアルです。 https://party-calendar.net/ レガシーコードからの脱却と、Bootstrapに強く依存したデザインからの脱却の両軸を目指したプロジェクトで、期間としては2019年3月〜6月頃です。リニューアル後のプロダクトの運用を現在も継続中なので、「参加期間はどのくらいですか？」の項目は「1年以上」としています。 # 基本的な技術構成 フレームワークはCodeIgniter3とDjango2系の併用です。リニューアル前はCodeIgniter2を独自に拡張したものを使用していました。DjangoはAPIとして動いており、Webとネイティブアプリの両方から参照されている状態です。 CodeIgniterは単なるMVCではなく、MVPパターンを用いて開発をしています。 Viewの責務がControllerに影響してファットコントローラーになることを防ぐのが目的でそうしています。RailsでいうところのDecoratorパターンがイメージとしては近いかもしれません。 CSSは[FLOCSS](https://github.com/hiloki/flocss)を基本としつつ、少しだけ手を加えた構成にしています。JavaScriptは将来的に「React + TypeScript」の導入を検討していたので、TypeScriptで書くようにしています。 # プロジェクトを振り返ってみて ## 良かったこと - 問題の少ないCSS構成が出来た。 - チームが纏まるきっかけになった。 ### 問題の少ないCSS構成が出来た 汎用性を持たせすぎず、捨てやすいCSSにしたことでメンテナンス性を高めることが出来ました。 粒度の大きい画面パーツをなるべく作らず、ページ固有のパーツとして運用するようにしたことで予期せぬ箇所のデザイン変更が起こりづらくしています。 ページの分類は以下のようにしています。 - TOPページ - 検索ページ - ここのデザインを大きく変えたくなったとしても、他のページをあまり意識せずに済む - 詳細ページ - フォーム系のページ ### チームが纏まるきっかけ プロジェクトの終盤は非常に大変でした。スケジュールの見積もりミスによる小さな遅れが積み重なったことで、リリース予定日を結果的に1ヶ月遅らせることになりました。 ここで良かったのは、「何故遅れてしまったのか」「どうすれば同じ失敗を繰り返さずに済むか」といった改善策を考える土壌がチームに生まれたことです。 この土壌があることで「前回失敗をしたから、今回は別のアプローチに挑戦してみよう」といった改善のサイクルが生まれました。 個人単位だけでなくチーム単位でも定期的に振り返り会、向き直り（※カイゼン・ジャーニーを参照）をすることでチームを上手く機能させる試行錯誤を今も続けています。