ID:57761さん

# プロジェクト概要 都内80店舗程展開しているフィットネスジム・サービスを行う企業について次の３つのプロジェクトを担当しました。 * 主要フィットネスサービスサイトの保守・運用 - 期間 2019/10 ~ 2021/6 1年9ヶ月 * 新規ブランドの子供向けフィットネスサービスサイトの開発 - 期間 2020/8 ~ 2021/6 3ヶ月 * 企業サイトのリニューアル - 期間 2021/1 ~ 2021/3 3ヶ月 全てのプロジェクトを通して共通の独自CMSを利用していました。 コンテンツの構造を自由に定義して入力し、EJSを使ってJSONやCSV、HTMLなどのフォーマットで出力するものです。 以下、各プロジェクトごとの詳細を記載します。 --- ## 主要フィットネスサービスサイトの保守・運用 ### プロジェクト概要 CMSを使ったウェブサイトのページの更新や新規ページの更新を担当しました。 コンテンツを管理するのは別の担当者になるので、コンテンツを更新しやすいように設計することも責務になります。 ### チーム情報 - リーダー 1 - フロントエンドエンジニア 1 ~ 2 フロントエンドエンジニアのメンバーとして参加 ### 開発・実装内容 - 既存ページのコンテンツ修正 - 新規ページのコンテンツ設計とページ作成 #### 【使用した技術】 - EJS - VueCLI - Javascript - SCSS - HTML #### 【課題・問題点】 - common.jsに共通ではない処理が数多く実装され肥大化しており、全貌を把握できている人がいない - 同じような機能が再利用されずに毎回実装されている - webpackすら使われていないレガシーな構成にVueCLIで作られたプロジェクトを無理やりネストした状態だった - ビルド手順が複雑なため作業者への負担が大きい #### 【改善対応】 - プロジェクト全体をVueCLIプロジェクトに統合して管理すること提案、実行 #### 【改善結果】 各機能をモジュール管理できるようになったので、毎回似たような機能を実装する必要がなくなり、ビルド手順が簡潔になったことで作業者への負担が減りました。また、common.jsのような多くなりやすいファイルも機能ごとにモジュール化して管理できるようになったので、複雑な条件分岐などが無くなり保守しやすくなりました。 VueやSCSS、JavascriptのビルドがVueCLI環境で統一されたのでビルドも一度で済むようになりました。 --- ## 子供向けフィットネスサービスを行うブランドのウェブサイト新規開発 ### プロジェクト概要 上記プロジェクトでの開発環境の改善が評価され、このプロジェクトではサブリーダーとして作業することになりました。 ### チーム情報 リーダー チームの規模は2~6人程で、リーダーは要件やリソースの調整に専念することになり 私の主な作業はメンバーのスキル別にタスクを割り振ったり、全体の進捗管理やコードレビュー 、全体の品質管理などを行いました。 ### タスク管理について タスク管理ツールは慣例でBacklogを利用していましたが、フロントエンドチーム以外の主にディレクターが利用するもので、担当者がディレクターになったりデザイナーになったりとコロコロ変わってしまう問題がありました。なので開発チームとしてのタスク管理はJIRAを利用してBacklogの管理とは切り離すことにしました。JIRAを選定したのは現場の環境がアトラシアン製品を使いやすい環境にあったのと、以前に利用経験があったこと、スプリント運用がやりやすかったことが理由です。 全体タスクと工数の見積もりは別の担当がいて、スケジュールが組まれた状態で渡されたのですが、どのページも一律8hのようなざっくりとした見積もりになっていて危機感を感じ、各ページで作らなくてはならないUIや機能ごとにタスクを分割し再見積もりを行いました。 それからリリース日までをスプリント単位で分けて全体のタスクを調整していった結果、当初の見積もりよりも若干工数が増えましたが、それでも開発期間中に終わる想定で収まったので安堵したのですが、急遽参加予定だったメンバーが不参加になりリソース不足という問題に直面しました。 実際、スプリントに割り振ったタスクが終わらずに次スプリントにずれ込むようになったので危機感がありましたが、スプリント整理の時間をチームで共有するようにしていたのでタスクが次スプリントにずれ込む様子が視覚的にも見えやすく、チームリーダーにリソースの確保やスケジュール調整など迅速に対処してもらえたのは思わぬメリットでした。 それからはチームメンバーも増えてしばらくの間は問題なく開発を進められていたのですが、開発期間半ばに差し掛かった段階で並行して進められていた要件定義とWebデザインの進捗が遅れていることが発覚しました。 確定したものから優先順位付けしてタスクを割り当てていたのですが、作るべきものが定まっていないことによって多くの開発タスクがブロックされる状況になってしまったのですが、開発期間がのこり1.5ヶ月程度あるからか要件定義の担当やデザインチームにあまり危機感がない様子だったので「このままでは本当に終わらない」という状況をチームリーダーに共有しました。 何がいつまでに確定するのかを早急に出してもらい、ブロックされていたタスクの優先順位を再度調整し、リリースまでに必須ではないものはリリース後の対応にしてもらうようしてもらい、なんとかリリースを間に合わせる様に調整することができました。これも適切にタスク分割していたから可能でしたが、当初のざっくりとしたタスクの分け方では対応が難しかったのではないかと思っています。 ### コード品質について 並行して保守していた主要フィットネスサービスサイトのコード品質が全体を通してバラバラになっていると感じていたので、今回はサイト全体の品質を統一するために次の対応を行いました。 * AtomicDesign の思想を導入したスタイルとモジュールの設計 * Clean Architecture の思想を取り入れたレイヤーの定義とモジュールの配置 * HTMLは Markup Validation Service によるバリデーションチェック #### AtomicDesignの導入 考え方をメンバーに伝えるのが難しく、スライドで説明したりレビュー中に方向修正したりしながら徐々にうまく回るようになりました。しかし後から追加でメンバーが加入したりすると、毎回それを共有する必要があったので慣れてもらうまでのコストが大きいように感じられました。 ただ、一度慣れてしまえば作られたコンポーネントを組み合わせるだけなので、開発スピードは徐々に上がるメリットも感じられたのでやって良かったと思っています。考え方の共有コストが大きいので別のプロジェクトで導入するかどうかはメンバーに応じて検討する必要も感じています。 #### Clean Architecture SOLID原則の知識があった方が説明しやすいと思っていたので、事前に勉強会などを行い考え方を伝えましたが、設計を考える経験がメンバーに不足しているのもあり、なかなか理解してもらえない状況でした。 それでも作業してもらわなければならないので、具体例としてデータ取得から画面への反映までの一連の流れを雛形として作り、それを参考に作業してもらいました。例があればそれを真似するだけなので作業に支障はあまり出ず、ときどきレビューで分割の仕方に問題があるのを指摘して軌道修正するだけで済みました。 他のプロジェクトでよく目にしていて問題だと思っていたのが、「VMにデータ取得から描画まで全て実装されている」といったことや「common.jsに共通ではない処理がif分によって大量に実装されている」ということでした。このプロジェクトではそれを回避するという課題もありましたが、実装例を共有したことが思っていた以上に効果的で、それを達成することができました。 設計の意識を持っているメンバーはもともと少なかったのですが、このプロジェクトを機に後々UIコンポーネントの設計を任せられるメンバーも出てきたので、スキル向上にも貢献できたと考えています。HTMLもdivばかりで組む様なマークアップが良くないことや、巨大なモジュールを作ると後で大変なことになるといった意識は少なくとも持ってもらえる様になったので、後のプロジェクトにもメリットがあったと考えています。 --- ## コーポレートサイトのリニューアル チームの規模は2~3人程で、私は先のプロジェクトと同様にチームのサブリーダーとして作業しました。 時系列的に「子供向けサービスを行うブランドのウェブサイト新規開発」の後で、AtomicDesign知見を得たメンバーを確保できたので、コンポーネントの分割は比較的スムーズに行えました。 この頃から現場内でTypeScriptを導入したいという意見がでてきていたので、チャレンジとして導入しました。Javascriptに比べると型やインターフェースなど覚えることがあるため、メンバーの作業効率が落ちることが懸念されましたが、抽象度の高いモジュールは事前に作成しておき、実装の一例を共有することで特に困ることなくメンバーに作業してもらえました。ビルド時に危ないコードをチェックできたり、入力補完が効くので評判も良く導入のメリットを感じましたが、ビルドにかかる時間が大幅に増える問題も出てきました。 キャッシュ周りの調整をして多少改善はしたもののビルドパフォーマンスには改善の余地が残っています。今後はWebpack以外のビルドツールを利用することも含め、パフォーマンス改善を課題として取り組む必要を感じています。

# プロジェクト概要 - 主にTV局関係のウェブサイト運用などで使われる独自CMSの開発プロジェクトに途中参画 - Vueによるフロントエンドの実装を担当 - インフラ2名、バックエンド3名、チームリーダー兼フロントエンド1名、フロントエンド1名 CMSは入力できる項目の構成を自由にカスタムして、データに応じて様々な形式（HTMLやJSON、CSVなど）で出力するプロダクトで内部的にはEJSテンプレートを利用する形でした。 --- ## こだわった点 - バリデーションのタイミング - 入力内容を不要にリセットしない状態管理 - アプリ全体で見た時のデザイン、使い勝手 バリデーションのタイミングや入力内容の保持については特に細かい指定がありませんでしたが、共通の処理が実装済みでした。しかし、入力後にデータを送信するタイミングで初めてチェックされるものだったので使い勝手が悪いと感じていました。 入力した時点でバリデーション処理を行う様にしたほうが使い勝手が良くなると思い、チームリーダーに提案してそれを実装しました。共通処理は実行するたびに画面内の全てのフォームをチェックする実装だったので、各フォーム入力に対して個別にバリデーションできるような調整も合わせて行っています。 また極力無駄な再入力をなくす様に調整しました。 フォーマットのような特定の選択肢を選ぶことでそれに応じたフォームが自動生成される画面では、フォーマットを切り替えた時点で入力していた情報が全てリセットされる実装でしたがこれではスキーマが一致するフォームも問答無用でリセットされてしまいます。再入力が面倒なケースが多くあったので、スキーマが一致するフォームについては入力をリセットしない変更を入れてUXを改善しました。 独自のUIを組み込むこともありました。vuetifyを利用していたのでUIパーツ自体を作ることはあまりなかったのですが、vuetifyにないパーツを求められたりした場合(例えばGoogleカレンダーのようなUI)には、こちらで一から作成しコミットするといった具合です。デザイナーはいなかったので自分でUIを考える必要があり、極力vuetifyの見た目と合わせても違和感ないように調整していました。 --- ## 後のプロジェクトに活かしたこと このプロジェクトで初めてスクラム開発を経験しました。以降のプロジェクトではこの経験を踏まえて以下のことを意識して行う様になりました。 ・全体のタスクについて工数を把握しやすい粒度に分割すること ・チームメンバーに対して、タスクの難度を考えてそれぞれタスクを割り当てること ・各メンバーの作業進捗具合によって、タスクを再分配すること ・日々の朝会を通してメンバーの不満、悩み、問題をくみとって必要に応じてプロジェクトに反映すること このプロジェクトを経験した後に１画面につき8hのような見積もりとそれを踏まえたスケジュールが組まれたプロジェクトを渡されたことがあるのですが、簡単なHTMLとCSSで作成できるものからAPIと連動させて動的にデータを表示させる画面とでは見積もりは異なるので、実装するUIや機能ごとにタスクを分割して再見積もりを行い、最初の見積もりを行った担当者に報告、工数にズレがあるのであればリスケやリソースの追加を依頼して調整するといったように事前に対応することを意識する様にしています。 チームメンバーについては必ずしも優れたメンバーに恵まれるといったことはなく、スキル的にコーディングだけできる方からSPAを実装できるような方まで様々なので、各メンバーに無理な負荷がかからない様なタスク分割も意識します。スキルだけならまだいいのですが、進捗が厳しいのにギリギリまで相談しなかったり、技術的な困難を相談できずにため込んでしまう様な方も中にはいるので、心理的安全性にも意識する様になりました。毎朝のミーティングで各メンバーの状況を聞き、進捗が厳しいメンバーに対してはタスクを再分配したり技術的なサポートを行ったりすることで負担を減らしたり、悩みをため込んでメンタルに問題が出てしまったメンバーには愚痴や悩みを環境を整えたりして悩みを溜め込む必要は無いということを"意識"してもらうといったこともプロジェクトを円滑に回すために考えるようになりました。