ID:72633さん

# プロジェクト概要 ### 背景／目的 再生可能エネルギーの利用価値を最大化する上で「需給調整市場」が重要な役割を果たしています。 この、需給調整市場で主に取引される調整力として、各企業や家庭が有している、蓄電池や発電機が注目を集めています。 そこで、VPPを構築することで、顧客の付加価値想像に貢献することを目的としています。 * 用語補足 |用語|補足説明| |----|-----| |VPP<br>（バーチャルパワープラント）|仮想発電所<br>各企業が有している蓄電池や発電機を、制御することによってあたかも1つの発電所のように機能させるシステム| |需給調整市場|電力が不足したり、過多になった際に、電力の調整力を取引するための市場| |調整力|需給の調整に使う電力のこと| ### 規模感／チーム構成 40名～50名（1チーム6～10名 ✕ 4,5チーム） ### 体制 スクラムで開発を行い、各チームにプロダクトオーナー1人、スクラムマスター1人、その他は開発メンバーという体制で開発を行っていました。 # 取り組んだ課題 ### スプリントレビューでステークホルダーからのコメントが少ない スプリントごとに行うレビュー内でステークホルダーからのコメントが少ないため、インクリメントがユーザーにとって価値が高いものかを正確に評価できずにいました。 ■改善するために実施した内容 　・開発メンバー全員で説明内容を検討する 　・ステークホルダーに気にしてほしい部分を強調して説明する 　・ステークホルダーにレビューの意義を伝え、どうすればより価値が高いものを作れるか、コメントを貰えるようにした ### プロダクトコードが複雑で機能追加に時間がかかる 私がプロジェクトに参画した時点では、ある程度開発が進んで、機能が出揃っている状況でした。 ただ、プロジェクト立ち上げメンバーの中にPythonやDjangoに精通しているメンバーが少なかったこともあり、 プロダクトコードが複雑で機能追加に時間がかかっている状態でした。 ■改善するために実施した内容 　・知識を共有する場を設けた 　　→Slackで知見を共有するためのチャンネルを作成 　　→コードレビュー時にコードの意図や、コーディングの手法を伝えるようにした 　・開発メンバー全員でコードレビューする 　　→当時は修正したメンバー ＋ チームに在籍する歴が長い人という少人数でコードレビュを行っていた。 　・既存コードを参考にコピペする文化の撤廃 　　→既存コードには車輪の再開発になっている部分や、共通化できる部分もあったため、 　　　コードレビューで指摘して、メンバーの意識改革に取り組んだ

# プロジェクト概要 ### 背景／目的 マンション経営をする中で以下のような問題が存在するため、無人受付端末を設置することで解決を図りたい #### ■問題 ・管理員不足で、人件費も高騰している ・各点検作業や共用施設利用のたびに、鍵の受け渡しが大変 ・遠隔地の物件でも、24時間書類の印刷発行や申請受付をしたい ・台風や豪雨の際に、注意喚起文書を素早く効率的に案内したい ### 規模感／チーム構成 5名～7名 以下の構成要員で開発を行っていた プロジェクトリーダー：1名 要件定義要員：1名 その他は開発メンバー ### 持っている機能 * 無人の受付端末 * タッチパネル操作 * キーボックスにある鍵の貸出 * 電子マネー決済機能 * 入居者向けのWebサイト # 取り組んだプロジェクトの課題 ### PythonやDjango、Webシステムに精通しているメンバーが少ない プロジェクトの技術に精通している人が少ないため、非効率な書き方や、要件に対して実装できないといった問題が起きていた。 ■改善するために実施した内容 　・チーム内に積極的に情報発信を行う 　　→既存のプロダクトコードを改善したり、機能追加で今までにない書き方をする場合タイミングなどで、 　　　チャットで共有を行ったり、チームメンバに説明をするなどの活動を行う ### デプロイ手順が確立されていない 参画した当時、デプロイ手順が確立されていなかったため、属人化やデプロイが失敗してしまうことが多くありました。 ■改善するために実施した内容 　・デプロイ時の手順書を作成し、属人化を排除 　・一部のデプロイ手順を自動化することでデプロイの失敗を防ぐ # 工夫した実装 ### 決済機能 【概要】 マンションの施設利用料などの支払いを無人受け端末から行うための機能 【課題】 支払いが完了したかどうかをリアルタイムに検知する必要があります。 【解決策／使用した技術】 Django＋HTMLのみではリアルタイムに検知することが難しいため、 Ajaxを利用して画面上で決済端末の状態を受け取るしました。 　※画面をリフレッシュする方法はあるが、状態を保持し続けることが難しかった。 ### 画面上のコンポーネントの共通化 【課題】 ・バックエンド側では共通の処理をまとめる文化があったが、フロントエンド側にはそういった文化がなく、 同じコンポーネントがベタ書きで描かれていました ・デザインの変更が発生した際に、すべてのコンポーネントの修正が発生する 【解決策】 Djangoのtemplateをアトミックデザインを参考に各コンポーネントごとに共通部品化しました。 アトミックデザインのような決まったルールを提案することで、各メンバーに共通化の意識が芽生える。 また、ある程度決まった粒度のコンポーネントが作成されることを期待しました。 # その他の活動 ### Djangoで簡単にできることをアピール Djangoであれば、「この部分は早く開発できる」といったことをアピールすることによって、要件の優先順位決めに貢献しました。 ### 機能改善の提案 プロダクトについてヒアリングしている際に、「技術的な制約でできない」と判断されていた機能がいくつかあったので、 本当にできないかを調査、できる／できないを精査し、チームメンバーに共有しました。 これにより、システムをより良い方向に持っていくことができました。 ### 新人メンバーの教育 新人メンバーもおり、教育を任されましたので、以下の点に気をつけて指導するよう心がけておりました。 　・作成したい機能が必要になった背景なども踏まえて検討するよう指導 　・質問された際は、質問に答えるのみでなく、答えにたどり着く方法もあわせて伝える 　・Python／Django以外でも使える設計の考え方を伝える 　　→デザインパターンや、広く知られている知識（DRYの原則、SOLIDの原則など）