Schwarzwald

### 作業概要 日常業務と平行して遂行。 スマホアプリに保存した写真を解析して、飲食店で撮った写真のみを保存して 表示できるFlutterアプリの開発。 ### 作業内容 - 技術選定 - スマホアプリの言語・バックエンドの言語・地図機能のライブラリ選定 - マネジメント - 4名から6名程度のタスクの切り出し - スプリントプランニング・レトロスペクティブを主導 - OJTを通じた新米エンジニアの育成 - デザイン - Figma上での、写真一覧・地図・カメラなどの画面モックの作成 - Flutter - MVC＋RiverPodでの、設計〜テスト - 撮影した写真と店舗を紐づける機能などの実装 - バックエンド - Python＋FastAPIでのAPI実装 - Firestoreの論理設計 - インフラ - Terraformを使用した、本番環境と開発環境の環境分け - Dockerでのマルチステージビルド - Github ActionsでCIを実装 - AI - TensorFlowを使用した、飲食物か否かを判定する画像分類モデルの作成 - その他 - Google Gemini API Competitionへの応募に伴う動画作成依頼　　 - https://youtu.be/bWxBYqiXnSI - 本ポートフォリオを用いた新米エンジニアの転職支援 ### 使用した技術 スマホアプリ: Flutter(RiverPod/GoRouter) サーバー: Python/FastAPI/Gemini API AI: TensorFlow/Google Colab インフラ: GCP(Cloud Run/Cloud Storage)/Firebase(Clashlytics/Analytics) IaC: Terraform CI/CD: Github Actions/CodeMagic デザイン: Figma その他: Notion/Slack ※Githubリポジトリ 1. スマホアプリ : https://github.com/schwarzwald0906/My_Gourmet 2. サーバー・AI : https://github.com/schwarzwald0906/My_Gourmet_Server ※デザイン：https://www.figma.com/design/9qlPzlsvF9CfYiYBED4yNR/My_Gourmet?node-id=2043-6006&t=gvIMF4f0fonDAWjg-0 ### 取り組んだ課題 私自身が、これまでマネジメントを経験をしたことがなく、最初の時期は本当にうまくいきませんでした。 自分の性格上、元々正論を言えばいいと思ってしまうきらいがあり、言い方がきつくなってしまうことがしばしばありました。 そして初期の頃に、あるメンバーが、私の言い方がキツすぎて、抜けてしまいました。 そこから猛反省して、以下の点に気をつけるようにしました。 1.テキスト上で言い方がきついと思ったら、ChatGPTで和らげる。 2.基本的に誰かが何かをやってくれたら、オーバーリアクションで返す。 3.テキストコミュニケーションでは、絵文字を添えて感情表現を豊かにする。 4. 相手の興味のあることに自分も興味を持つ。 5. 相手のダメなところが目についてしまうときは、いいところを書き出してみる。 6. 相手の信頼関係がどれくらいかを見極め、その距離感に応じて、言っていいラインとだめなラインを考える。 7. 相手が自分に強い感情を向けてきた時、その感情の背景に何があるか、思考をめぐらせてみる。 結果的に、初期から支えてくれているメンバーが、本当に性格が変わったと言ってくれました。1年近く経ちますが、彼は、今でもプロジェクトを支えてくれています。

### 作業内容 - UXリサーチ - 利用者の約10名に、アンケートを用いて、来院前の不安点や年齢層などを調査 - デザイン - AdobeXD上で、画面モックの作成 - フロントエンド - React/Next.jsでWEBサイトを作成 - microCMSを用いた、ブログ機能の実装 ### 使用技術 フロントエンド：React/Next.js CI/CD: Netlify その他:Google Analytics /Adobe XD/microCMS ※Githubリポジトリ https://github.com/schwarzwald0906/My_JAMStack ※サイト https://fluxus-locus.link/ ※デザイン https://docs.google.com/document/d/1DnQatZImRy-5WZCbF9_LBpkPRXmRK62JO9zQgN3--78/edit ### 取り組んだ課題 UXリサーチで、想定顧客と、来院前の不安点を洗い出しました。 その結果、顧客は、40〜60代の女性で、どんな施術をされるかわからないという不安があったことが見えてきました。 そこで、以下の点に気をつけてサイトを作成しました。 1.ネイチャー風味の優しい色合いをベースにデザイン 2.どんな施術を行われるのか、ステップごとに説明 結果として、作成から1年で、サイトのアクセス数を2倍強まで増やすことができました。

## プロジェクト概要 全国に点在する9つの電力会社を束ね、各中給システムから送られてくる電力をもとに、電力の需給調整をおこなうシステムを構築していました。すでに稼働しており、今回新たに新規機能を追加するために、プロジェクトに参画していました。 ### 担当した役割 1.約1ヶ月間、要件定義において、JavaScript /Javaで客先提示用の画面モックを16画面作成しました。 2. 8月から2023年3月に至るまで、低レイヤーの演算機能の新規機能1機能分を基本設計からほぼ全て任されていました。（詳細は以下） 　新規機能追加にともなうDB論理設計 　新規作成ファイルにともなう外部I/F設計 　Astahでのデータクラス設計 　Plant UMLでの業務ロジックのフローチャート作成 　C++でのコーディング（3000行ほど） ### 使用技術や開発環境等 フロントエンド：JavaScript / CSS / HTML /JSP バックエンド：C++（演算機能）、Java（演算管理） DB：PostgreSQL OS：linux 仮想環境：Virtual Box ### 取り組んだ課題 1. フローチャートの作成 内部のシステムで保持しているデータと、外部から送られてくるデータに応じて、 各パターンに分けて処理を実行するのですが、当初分岐をうまく切り分けることができず、冗長な作りになってしまいました。 処理を見直し、引数をたくさん持つ作りになっていたことに気づきました。 冒頭の分岐で、場合分けに応じて使わない引数を削っていく方針に変えました。その結果、変数を削り、 シンプルな作りにすることができました。 2. データクラス設計 新規追加する機能に伴い、どこにデータクラスのクラス及び変数を追加するか検討しました。 追加する観点として、以下を意識しました。 ①メソッドで変数を呼び出すときに、呼び出しやすい位置にあるか ②既存の処理に対して、最小限の変更で済むかどうか ③既存のデータクラスと、意味的な整合性が取れているか 特に上長が、②を気にされていたので、ソースコードを入念に調べて、問題ないか検討しました。 3．未習得技術のキャッチアップ JavaScriptとC++は、それぞれ未習得言語だったので、 それぞれUdemyや学習書籍を用いて勉強しました。 特にJavaScriptに関しては、今まで全くやってこなかったので、アプリを自分で作って勉強しました。 作成したTodoアプリは、以下になります。 https://github.com/schwarzwald0906/todo-js その頑張りが評価され、2ヶ月目からより重要な演算機能の実装の方に回していただきました。

## プロジェクト概要 クレジットカードのリプレイスにおいて、以前炎上で中断していたシステムを今回再構築するプロジェクトでした。 基本的に機能ごとに、Javaでビジネスロジックをcsvに吐き出し、ETLツールでcsvをインターフェースに変換することで、各機能の責務範囲を細分化する、パイプラインアーキテクチャでの開発でした。 ### 担当した役割 もともとJavaでの開発・テストを担っていましたが、炎上していたので、設計の見直しを行うことも多々ありました。 詳細は以下の通りです。 ・Javaでの1機能分のビジネスロジックの開発および機能改修（5000行ほど） ・DJunitを用いたテストコードの作成・実行 ・単体テストでの、コマンドプロンプトのログ解析を通じた障害対応 ・ETLツールを使用したテスト及びETLツールの改修 ・Tera Term（Shell Script）を用いた資産のリリース ### 使用技術や開発環境等 バックエンド：Java DB：Oracle OS：windows ### 取り組んだ課題 1. やる気のない他社の社員を、どうやって巻き込んで、期限内に仕事を終わらせるか 3ヶ月間という短い期間の参画でしたが、業務で評価され、炎上も相まって仕事をたくさん振られました。その中で自分以外の社員に、仕事を振り分けていくタスクが発生しました。 工数が厳しいなかで、あまりやる気のない他社の社員をどうやって巻き込むか、課題を突きつけられました。 取り組んだことは以下の2つです。 ①あやふやだった責務範囲を明確にする。 →これによりお互いやることが明確になりました。と同時に、言い逃れのできない状況を作り出すことで、プレッシャーをかけることができました。 ②放置せずに、厳しかったら早めにアラートをあげてもらう。 →元々無理な工数でやっていたので、アラートをあげてもらい、本当に難しかったら早めに上長に報告することにしました。 それにより、上長から手が空いた別の社員を増員してもらいました。 結果として、ぎりぎり仕事を終わらせることができました。 2.他社の社員のその場しのぎの対応を、根回しをしたうえで上長を巻き込んで解決 クレジットカードの紛失に関する機能の単体テストを任された時、あまりにも設計と実装を乖離していました。 実装担当者は、40代で私よりも経験があり、かつPJでの立場が上でした。 私がなぜこのような実装をしたかと伺うと、時間がなかったからとのご回答をいただきました。 ただ、このままでは、明らかにこの後の工程で皺寄せが来ることは目に見えていたので、 要件定義・設計担当者に相談しました。その方も、このままではまずいと私に同意してくださいました。 この根回しを挟んで、上長に、〇〇さんもこう言っています、と相談しにいきました。 結果として、上長は私の相談に乗ってくださって、結局実装をもう一度設計に合わせることで、合意を取ることができました。 3. メソッドの共通化によるリファクタリング 一度中断されていたPJを、もう一度要件定義から見直して再開したため、 開発も、すでに記述されたソースコードをもう一度イチから見直して、開発をおこなっておりました。 私の担当した機能は、カードの新規発行でしたが、機能のなかに、クレジットカードの信用情報取得が含まれてました。 その際、信用情報の取得は一回で完結するものではなく、本人確認情報や家族付帯情報など、さまざま情報を参照する複雑な作りになっていました。 ただ、複数回処理が行われるうち、メソッドを共通化できる部分があったため、共通化して全体の見通しをしやすくしました。 結果としてソースコードを500行ほど減らすことができました。 4. マニュアル作成による作業効率化 炎上案件で、かつ人の入れ替わりの激しいPJだったため、新しく入ってくる人にどう対応するかが非常に大きな課題になっていました。 私が参画するまでは、周りの方は人に聞くことで対応していたようですが、私は、マニュアルを作成しました。その結果、一から入ってきた方にも、マニュアルをまず読んでもらうことで、お互いの時間を短縮し作業効率が向上しました。

## プロジェクト概要 損害保険会社のドライブレコーダーの在庫管理システムを開発しておりました。 アプリJavaのSpring Frameworkを使っており、 画面→contoroller→service→entityという依存関係をとっているオニオンアーキテクチャでの開発でした。 しかし、詳細設計が詰めきれておらず、単体テストで炎上していました。 ### 担当した役割 単体テストで生じた障害の修正対応から入り、結合テストでのテスト設計や打鍵まで行いました。 詳細は以下の通りです。 ・Javaのcontroller, service, entityクラスの障害対応、またそれにともなう横展開の修正 　→特に在庫引当の周りの制御 　※簿記の知識が活きました。 ・入力チェックと業務チェックのリファクタリング ・障害対応にともなう詳細設計書の修正 ・設計書及び実装の差分調査 ・ステージング環境でのテスト設計書の作成及び打鍵 ・Redmineによるチケットの作成、管理 ・SVN、Gitによるバージョン管理 ### 使用技術や開発環境等 フロントエンド：Thymeleaf バックエンド：Java（Spring） DB：MySQL（A5M2） OS：windows インフラ：AWS ### 取り組んだ課題 ・在庫引当周りの制御に関する機能改修 PJは、ドライブレコーダーを車に搭載することで契約を結ぶ形式の保険でした。 その際に、ドライブレコーダーの在庫管理とそれに関連する仕訳の制御で問題が頻発していました。 返品・交換・破損による取り替え・取り消しなどで、仕分けがそれぞれどうなるかに関する知識を持った方がPJに少なく、 外部設計から内部設計に落とし込む際に、曖昧になってしまっていました。 その点に関して、私は簿記2級を持っていて、その経験から機能改修を行うことができました。 ・入力チェックと業務チェックのリファクタリング 通常オニオンアーキテクチャでは、各階層で責務範囲が明確に割り当てられていますが、 炎上していたため、作り込みが甘くなっていました。 私が担当した入力チェックと業務チェックでは、contoroller/service/entityで処理が混在していました。 そこで、入力チェックと業務チェックを分離し、エラー処理を統一しました。 入力チェックは、entityにspringの@Pattern処理を書いて、正規表現に統一しました。 業務チェックは、serviceからrepoisitoryを経由してDBにアクセスするので、serviceでまとめて処理を行いました。

## プロジェクト概要 食品卸会社の子会社40数社のデータを取りまとめ、親会社に送るデータ分析基盤の構築。 ### 担当した役割 サブPMとして、進捗管理や議事録作成がメインのタスクでしたが、以下の構築にも携わりました。 ・構造化データのデータパイプラインの構築 具体的には、外部I/Fからファイル定義して、取り込み口を制御し、テーブル定義書から社内ツールで変換をかけ、BigQueryに分析させる土台を構築しました。 ### 使用技術や開発環境等 インフラ：GKE , Cloud Storage,Pub / Sub, Cloud Functions , BigQuery ### 取り組んだ課題 ・BigQueryに取り込むまでの地道なデータクレンジング 子会社40数社のデータは、フォーマットが統一されていないため、統合的に制御するために様々なデータ整理の施策を行いました。 1. 各社から送られてくるフォーマットとサンプルデータから、ひたすらデータ構造を統一的なフォーマットに書き起こしていました。 サンプルデータとフォーマットが異なるときに、各社に問い合わせて確認するといった作業も行いました。 2. 外部IFからGCPに取り込む際、会社間で表現が異なるが同じ意味の語句を論物変換でまとめるといった作業も行いました。 こちらも関係各社に問い合わせる作業も兼務しました。 3. 統一的なデータとしてbigqueryで解析するために、ある会社にはあって別の会社にないデータを削ってまとめていました。とはいえまとめすぎると削りすぎることになるので、程々にとどめたり、といった非常に神経を使う作業が多かったです。 3つめに関して補足すると、データ分析基盤を構築する目的が明確でないまま、PJ自体が進行しており、方針が定まらない中での構築を進めなければならない難しさもありました。