サトウ

## サービス概要 事業部から依頼される開発案件をスクラム開発を主体として機能の開発を行った。 ## チーム規模 プロジェクトマネージャー：1人 エンジニア：5人(属人的な業務をなくすため、全員が様々な業務を行った) ## 具体的な業務内容 ### 請求に追加する料金を入れ込むバッチの作成 #### 概要 新たなサービスを追加することになったため、料金設定を変更する必要が出てきた。そのため、バッチを用いて新たなサービスを利用する顧客のデータを取得し、新しい料金データの紐付けを行うバッチを作成した。 #### 担当箇所 バッチのコーディング #### 工夫した点 自分オリジナルのものを作成しないことを意識しました。他のバッチと作りを似せることで開発効率も高められる上、今後修正する場合に修正がしやすくなることが考えられたため、周りのバッチを参考に作成しました。 ### rubyで作られたバッチをnode.jsで書き換え #### 概要 機械の不具合により取得できなかったデータをバックアップデータから抽出する機能が元々rubyで作成されていた。この機能を作成した方が弊社から離れることになったため、Node.jsで書き換えることになった。 #### 担当箇所 - コーディング - テスト #### 困難状況やそれを乗り越えた経験 取得したデータをcsvで出力させる際、エラーにハマってしまい、解決に時間がかかっていた。自分のチーム内にきいても解決させることができなかったが、フランス人の同僚に相談し、csvを出力させる機能の使い方を相談して解決させることができた。

## サービス概要 社内業務の効率化を図るツールの開発。顧客情報を変更する際、今まではswaggerを使用していた。そのため、他部署からシステム部への案件伝達、システム部内でデータ変更と定期作業が発生していた。その作業をシステム部にそもそも持ってくる必要がないようにツールを作成した。 ## チーム規模 プロジェクトマネージャー：1人(エンジニア歴10年以上) サーバーサイドエンジニア：1人(エンジニア歴約1年) フロントエンドエンジニア：1人(エンジニア歴約1年) ## 開発の進め方 - API仕様書、シーケンス図、画面設計図のみを設計書として作成した。 - チームメンバーは3人のみで増員の予定もなかったため。 - 毎日進捗確認を行い、どこからどのようにどこから開発を進めるのかを話し合ってからコーディングを行った。 ## 具体的な業務内容 ### 1ヶ月半での設計〜開発(設計書の選別理由を記述しておく) 業務上、1.5ヶ月という短い期間で設計〜開発全ての工程に取り組んだ。そのため、設計書は必要なものだけを選別し、 ・API仕様書 ・シーケンス図 ・画面設計図 のみを作成して開発に取り組んだ。 ### Next.jsを用いた画面の開発 Atomic designを軸に使用して画面開発を行った。 ### AWS Lambdaを用いたCognito、PostgreSQLにあるデータの操作 API gatewayのエンドポイントを叩いてlambdaを呼び出し、そのlambda内でpostgreSQLへの接続、Cognitoを操作できるよう作成をした。Cognitoはそもそも自社で認証サービスとして使用しているため、Cognitoを呼び出す処理を今回作ったlambda内に作成した。 ## 成果、学んだ点 #### 設計図の限定 開発では設計図は必ず必須だと考えていました。しかし、設計図は必ずしも必要ではなく、新しくチームに人が入ってくる場合などで必要なことを学びました。 #### TypeScriptの活用 保守・運用業務では大きな規模になってくると、buildするだけで時間がかかるので、型エラーなどを事前に把握する必要がありました。また、会社としてもTypeScriptを導入する方向だったため、今回の開発でも活用することになりました。 長めの関数を書いた時に返り値の型をを指定しておいたことで実際に関数を動かす必要なく、型などのエラーを見つけることができました。今振り返ると、長めの関数を書くことは多々あるので、いかに開発効率をTypeScriptで上げることができるのか実感できたと思います。 TypeScriptの特性はAPIの作成で特に実感しました。try、catchでAPIを叩く仕様にしたため、成功した時、失敗した時の処理を書く必要がありました。返り値や処理を正確にできているのかの確認箇所が多く、エラーを見つけずらかったですが、型を定義しておいたおかげで返り値のエラーを防ぐことができました。また、APIを叩いて確認するのは時間がかかるため、開発効率もかなり上がったことを実感しました。 ### Next.jsの使い方 初めてNext.jsを使ったこともあり、環境変数を使う時に、 NEXT_PUBLIC_ を使わないとNext.jsでは環境変数を使うことができないということを学びました。 ### Next.jsにおけるAPI接続 フレームワークとしてNext.jsを採用したため、簡単にサーバー側のAPIに接続をすることができることを学びました。axiosやexpressなどのライブラリを検討する必要がないため、APIの使い方をチームメンバーで少し話すだけで実装を進めることができました。 ## 工夫した点 ### 設計図の限定 社内のみの開発でかつ、業務を効率化させるツールの作成だったため、以下の要点に絞って設計図を作成することにしました。 ・デザインには拘らない(デザイナーに依頼しない) ・重要な機能を持つポイントにのみ設計図を作成 そのため、処理の流れ、簡単な画面設計、APIの作りのみに焦点を当て、開発の時間を多く取れるよう工夫しました。 ### 保守、運用で学んだreact hooksでのデータ運び APIで取得してきたデータの有無で画面の切り替えを今回は行いました。そのため、データがある場合、ない場合でboolean型のカラムがtrue、falseに切り替わるように工夫しました。保守、運用で学んだことを活用して開発に活かせることができました。 ### 問題が起きた時 1. エラーが起きた部分の仕組み(データの動き、条件分岐)を理解する 2. エラーが起きそうなポイント、自分がよく起こす傾向のあるエラー(誤字、大文字小文字の区別)をまとめてポイントごとに原因を探す 3. 2でもわからなかったらネット上でエラーとなった箇所の検索をかける 4. ドキュメント読み込んで動き方を把握する 5. 周りの人のアドバイスをもらう 基本的にはこの順番で解決をしていきます。また、時間をかけすぎるのも良くないので1、2、3をそれぞれ10〜15分ほどで終わらせることを意識して取り組んでいます。 ### 次のプロジェクトで活かしたいこと - リファクタリングで誰が見てもわかりやすいコードを書く - ただDBを叩く以外にAWS Lambdaに+αでS3やDynamoなどに接続して操作を行う複雑な仕様のAPIの作成 - react hooksを使用したデータ遷移 - next.jsを使用したAPI設計 - ドキュメントは背景やなぜ作ろうとしたのかの理解から機能を理解する 僕自身、今回の開発で今までやってきたことを活かしつつ、aws lambdaとDB、 cognitoの接続と新しいことに挑戦できたのはいい経験でした。学び方に関しても、何度も復習するだけでなく、新しいことを学んだ時にこれは今まで学んだことの何が使われているのかを考えることで頭への定着率を向上させれました。この日々の行動から、個人学習で日々の業務で感じる自分の弱み・課題を改善しており、上記以外にも次のプロジェクトで活かしたいことを増やしたいと考えています。 また、ドキュメントをただ読むのではなく、背景まで理解することで、そもそもこの動きはおかしい、使い方としてはこうも考えられるなど開発効率を向上させることができます。このことも生かして今後のプロジェクトに取り組みたいと考えています。

## サービス概要 電気の供給先・需要先をマッチングさせて顧客が選んだ供給先から電気を届けてもらうサービス。電気の消費量や月々の請求金額などを確認ができる。また、選んだ供給先はどの程度環境に配慮した発電を行っているのかも確認可能。 ## チーム規模 プロジェクトマネージャー：1人 エンジニア：5人(属人的な業務をなくすため、全員が様々な業務を行った) ## 具体的な業務内容 ### 電力需要量取得のエラー対応 - 概要 - エラーアラートで数人の顧客の料金計算ができていないエラーを検知した。需要量の取得をバッチができていないことを発見したが、そのバッチ内ではエラーが発生していないため、需要量が取得できなかった原因の調査を行った。 - 担当箇所 - 原因把握 - 対応方法の確立 - 設計書の読み込み、エラーログの確認でエラーが取得できていないポイントの絞り込み - バッチの起動回数では対応しきれない量のデータがDBに蓄積されていたことを確認 - ビジネス側には、影響がないことを確認してすぐにビジネスには影響がないこと胸を連絡した。 - 工夫したポイント - ログ出力用のコードを入れ込むことを提案。 - ビジネスへ影響が出ないよう、優先順位をつけて調査を行った。 ### 電力の需要・供給場所を把握するwebページの作成 - 概要 - 会社がアピールしたい発電所を紹介するページを新たに作成し、保守・運用を行う。 - 新しく追加するサービスのため、以下を行った。 - 必要なデータの取得し直し - 取得したデータのグラフ化 - youtubeリンクの貼り付け - お客様の契約内容によって表示するアカウント画面、ログインへの移行画面の内容の変更 - 担当箇所 - 契約の手続きが完了したときに表示するログイン誘導画面の作成(顧客の契約内容によって表示する画面の変更) - 契約内容によってフッターに付け加えるリンクを作成した - 開発の進め方 - 開発開始前に誰がどこを担当するのかを決め、毎日朝会で進捗確認、どう進めるのか、困っていることを確認した。 - スケジュールはあらかじめ他の部署やビジネスサイドと話し合って決めていたが、進捗に合わせてスケジュールを変更しながら開発を行った - 工夫した点 - 契約内容が変わることをどのように表現するかを工夫した - 新しくboolean型のカラムを作成することで契約内容を変えれるようにした。 - 新しいサービスを契約する場合のみ新しく作成したカラムをtrueにするよう定義し、新しく作成したカラムがtrue、falseのときによって表示内容を変更する仕組みにした。 - 今回のページの作成ではReact.jsのHooksを採用し、新しいカラムの情報はhooksで持たせるようにした。そのため、state、propsをいちいち使う手間を省くことができ、可読性も向上させることができた。 - カラムの値の変化で表示する内容を分ける際に、表示する内容や必要なデータをコンポーネントごとに分けるように工夫した。 - 修正が出た場合でも必要最小限のコンポーネントの修正を行うのみにできた。 - いろんなコンポーネントで使うようなデータでは一番大元となるコンポーネントに記述し、一部分でしか使わないようなデータは細かく分けた小さなコンポーネントに書くように心がけた。 ### 運用保守時に発生する英語対応 - 概要 - 保守時での英語対応 - 担当箇所 - デプロイエラー時に英語で問い合わせを行い、原因を突き止め、解決 - 英語で来る技術情報をチームに共有 - 工夫したこと - デプロイエラー発生時に開発チームでの操作過程に問題は見当たらなかった。 - 自動デプロイを行っているツール側に英語で問い合わせる必要があり、自分が英語でのやりとりを行い、意思疎通できるようにした。