ID:49334さん

親会社の従業員が使用する社内システムが古く、簡単に変更が難しくなってきた為、Python, Django, Vue.jsに置き換えるプロジェクトに従事しています。 複数機能が存在しているので、複数チームに分かれて別々の機能を担当しています。 私達のチームは取引先を管理するマスタの置き換えを担当しました。 ## プロジェクト体制 - 全3チーム - 1チーム4人 ## 私の役割 - メンバー（主にバックエンド担当） - 別PJにてリーダー経験があった為、今回のリーダーの補佐をする ## 課題 チームに参画時に以下のような課題がありました。 - フルリモートでのチーム開発が初めて - 4人中、2人がPython、Django、Vue.jsをやるのが初めて - 2人のうち、私が一人 - 同じプロジェクトに他2チームが関わっていて、チーム間の連携がうまくいっておらず、画面デザインの差異やコードの重複などが発生してきている ### フルリモートでのチーム開発が初めて まずは、お互いの自己紹介（好きなこと、得意なこと、この先やりたいこと）と、リーダーズ・インテグレーションを実施してリーダーとメンバーの相互理解から始めました。 そのあと、このチームではどのようにコミュニケーションを取っていくか（Slackでやり取りするだけでよいのか。頻繁に打ち合わせをするのか）が最初の課題になりました。 開発初期は要件定義をから入りましたが、誰かがMarkdownで要件定義書を書いてPR→レビューをするだと、以下の問題が考えられました。 - 要件定義に時間がかかり過ぎる - 文字から読取る情報のみだと、メンバーの受け取り方が変わってきて誤解が生じやすいのではないか - 文字の表記に対して、「この日本語は間違っている」みたいな感じのPRのレビューが溜まっていって辛くなる そこで、Slackで非同期なコミュニケーションは取りつつ、Google meetでチーム用の雑談部屋を作っておき、口頭で話がしたいときには、そこで行うように場を作ることを提案しました。 要件定義に関しては、口頭で話し合うことにより、その場で「この要件の抜け漏れがないか」をチーム全員ですり合わせることができたので、要件に大きなズレが生じずに進める事ができました。 このとき、口頭のみだと議論が空中戦になりやすいので、ユーザーストーリーマッピングなどを併用し、「ユーザーはどんな行動を取っていくのか」「その中で課題と感じているのはどこか」と要件を組み立てていくことができました。 ### 4人中、2人がPython、Django、Vue.jsをやるのが初めて 今回のプロジェクトは既に先行チームがいて、技術選定は済んでいました。 その選定された技術に対して、私達のチームではプロダクトで使った経験が無いメンバーが半分だったので、誰かのPRをちゃんとレビューができない問題が出てきました。 これに対してモブプログラミングを提案して、経験の浅いメンバーに積極的にドライバーをやって頂きました。 1日の半分以上の時間をモブプロに当てて、それを3週間続けていきました。 目的としてはスキルレベルの差異を埋めるためでしたが、他には以下のような効果がありました。 - チーム内でのコーディングのスタイルを認識合わせできた - フロントエンド担当、バックエンド担当も一緒に巻き込んでやることにより、APIのエンドポイントの仕様をその場で決めていけた - チームメンバーの仲が一番良くなった #### 個人の技術的課題について 私自身の技術的に足りない課題である、Django Rest Framework、Vue.jsの理解度については、このモブプロを通じて適宜詳しいエンジニアに質問することで深めていくことができました。 そもそも4月最初ではどこまでがDjangoで、どこからがDjango Rest Frameworkなのかといったフレームワークの境目もわかっていなかった状況でした。 自己学習にDjango Rest Frameworkのチュートリアルを音読して手を動かして、現場でのプロダクトコードの差異を見比べてみて、疑問に思った箇所はモブ中に詳しいドライバーに聞いて、都度疑問を解消するようにしていきました。 まずは自分自身が感じている疑問を言語化しておくことを意識し、有識者に会った際にすぐ話を聞けるようにしていきました。 ### チーム間の連携がうまくいっておらず、画面デザインの差異やコードの重複などが発生してきている プロジェクトの目的の一つとして「画面デザインの統一」があった為、事前にスタイルガイドを策定していました。 私達のチームがスタイルガイドに記載されていないような項目に直面したとき、チーム内で独自に決めてしまっていいのか、それをどのように決めたらいいのか、どこに話し合ったらいいのか、といった場が無いことに気づきました。 それを解消するために、各チームのフロントエンドエンジニアに声をかけ、上記のような困りごとを解消するための定例会とSlackでのチャンネルを設けることにしました。 職能別でチーム間のミーティングの場を持つことによって、1チームだけでは決めづらいことを持ち寄り、その場で決めてもらうようにお願いしました。 この定例会の発足時、「どうやったらその事項は決定するのか」といった意思決定の仕方も一緒に考え、それが固まった後はフロントエンド担当にお任せするようにしました。 ### その他、チーム間の横断的な作業の実施 - E2Eテスト(Cypress)を提案し、導入する - OpenAPIの生成ツールとして、Django Rest Swaggerを使用していましたが、非推奨となっていた為、drf-yasgへ移行を実施する - 他チームへDjango Rest frameworkでのテストや、drf-yasgを導入するための支援 - デプロイを手動でやっていたのを、GitHub Actions（手動トリガー）に変更し、デプロイ手順の簡略化を実施 ## 最終的にどうなったか 作ったプロダクトは本番へリリースし、ユーザに使って頂いている状態です。 大きなバグもなく今の所使って頂いておりますが、チーム内でのふりかえりで、以下のような問題点が上がってきました。 - 今後の機能追加をどうやっていくか - APIのテストコードが多すぎて(300件ほど)、後で見直した時に仕様が理解しづらいのではないか - デザインの統一がしきれなかった、共通コンポーネント化を進めることができなかった - APIの同じリソースに対して、パラメータとレスポンスがだいぶ変わる為、DjangoのSerializer自体を分けていったほうが良いのではないか これらの問題に関しては、今後もこのチームで別機能の開発をしていきながら、リファクタリング・機能改善に充てる時間を取っていくことで、今後のTryとして考えています。

介護施設向けの入居者請求システムの受託開発を行いました。 ## 入居者請求システムの概要 介護施設に入居している方が、毎日どんな食事を食べた・サービスを使ったかを記録し、その費用を毎月請求書を発行するシステムとなります。 ## プロジェクト体制 - 4人チーム - PO 1人 - リーダー 1人 - メンバー 2人 ## 私の役割 - メンバー（主にバックエンド担当） ## 開発の流れ 第一フェーズ（システムの導入） 第二フェーズ（保険点数計算システムとの連携） ## システムの導入 別拠点で導入されていたBashとHTMLで作られたシステムから、必要機能を抜粋したものを抜き出して開発し、システムの導入を1ヶ月で行いました。 このときの課題として - 納期までの時間が少ないこと - 介護業界の知識についての不足 の2点がありましたが、 毎日POと話し合いながら介護業界の知識を仕入れつつ、チーム全員で齟齬が無いかを確認しながら進めていきました。 途中、何でも画面上でテストが発生することが予想された為、早めにE2Eテスト（Selenium ide）を導入して対応しました。 ## 他システムとの連携 システム導入後のフェーズで、保険点数を計算するシステムから請求金額を受け取り、こちらのシステムが発行する請求書に載せるシステム連携の開発が始まりました。 このときAWS Lambda 、Pythonで他システムから出力されるCSVファイルを受け取り、自社のシステムで扱えるデータに変換するAPIの開発を担当しました。 開発初期の段階ではデータが連携されるフォーマットが定まっていなかった為、 - CSVを受け取って必要なデータだけに変換する - 必要な計算・変換ルール - 自社システムが扱うデータ形式に変換する これら3つのロジックに分離をして、受け取るデータのフォーマットが変わった時に変更しやすいよう対応をしました。 少ししてから、当初の連携されるデータフォーマットが変わり、工数を掛けることなくロジックの変更が安全にできました。