mine03

# 概要 ## サービスの概要 社内システムで使用するクラウドインフラをIaCを用いてアセット化する試みです。 プロジェクトごとに求められる多様な要件に対応したクラウドインフラ環境を高速に提供するため、 あらかじめクラウドインフラをアセット化しカタログとして選択可能にしました。 ## 使用技術 - 開発環境：Cloud9での管理、aws cliでのリリース - IaC管理：Codecommitでのバージョニング ## 実際に提供するアセットの一例 - フロントエンド - 静的webサイト : WebACL + S3+Cloudfront - 静的webサイト+CICD : WebACL + S3+Cloudfront + Codecommit + Codepipeline + Codebuild - バックエンド - ECS自動起動自動終了 : Stepfunction + EventBridge - ECS Fargate構成（詳細は省く）

# 概要 ## サービスの概要 商品開発ダッシュボードを作成しました。 商品に対する基本情報と実績を表示するツールです。 ユーザーはダッシュボードを確認することで、問題のある商品の特定から改善に向けた行動をとることができます。 - これまで商品の基本情報と売り上げ実績が別々に表示されていたが、本ダッシュボードでレポートを作成する手間を省ける。 - これまで商品レビューは軽視されてきた状況だが、本ダッシュボードでお客様の声を意識した開発ができるようになった。 ## 使用技術 - 利用言語：Python(サーバー側), Javascript(フロントエンド側) - ライブラリ：Mecab(キーワード抽出), D3.js(ワードクラウド), echart(時系列グラフ) - フレームワーク：Django,Backbonejs - その他：Docker, SVN, MySQL # サービスの運営上での課題と工夫 ## dockerによる開発環境構築 - 課題 開発環境と本番環境、他メンバーPC間で環境にズレが生じる可能性があるため、環境構築の手間や環境が壊れた時のリスクが生じる。 - 使用技術 docker使用。 - 工夫 svnの導入と組み合わせることで、ソースの管理と環境の管理を行い、完全管理が可能になっている。 - 成果 環境間の差異をなくし、5分で開発環境を構築することができた。 後にAWS EC2への移行の話が出たが、windowsとlinux間での環境差異を考慮しなくても良い状態になった。 ## Webサーバー(フロントエンド) + データ提供APIのアーキテクチャ(バックエンド) - 課題 複数メンバーでの開発のため、マージの際には競合が発生してしまう可能性がある。 - 使用技術 WebAPI - 工夫 フロントエンドとバックエンドで開発メンバーを分け、 互いの領域でないソースは編集しないというルールを設ける。 - 成果 コンテナ単位(フォルダー単位)でのソースの管理を行い、マージの際の競合はなくなった。 フロントエンドとバックエンドが明確に分離され、変更に耐えるシステムになった。 # 開発の詳細 ## これまでのプロジェクトの流れ 1. プロジェクトキックオフ 2. ダッシュボードテンプレート選定 3. docker+django 4. メンバー追加,SVN導入 5. ダッシュボード第一弾完成 上記達成時点より、以下の本格的な開発サイクルがスタート 1. 商品開発部レビュー 2. レビュー内容優先順位付け 3. APIデータ構造決定+ダミーJSONデータ作成 4. 各担当が各々のローカル環境で各分野を開発 5. コミットを実施&ローカル環境での動作確認 6. 本番環境を更新 上記のサイクルを用いて、以下の3点を実装 1. キーワードクラウドによる商品レビューの頻出単語の可視化 2. 売り上げの時系列グラフ化 3. CSV管理 → MySQLデータベース管理による高速化 ### キーワードクラウドによる商品レビューの頻出単語の可視化 - 経緯 商品開発チームより「ユーザーレビューを活かす取り組みを始めるために直感的なユーザーインターフェースにしたい」という要望があったため実装。 星ごとにワードの色を変えることで、レビューのネガポジのキーワードを直感的に拾える工夫をした。 - 使用技術 Python+Mecabでレビューからキーワード+頻度を抽出。 抽出したデータをD3.jsライブラリーを用いてワードクラウド化。 - 工夫 言語分析は「ユーザーレビューを活かしたい」という要件により、再利用性が重要だと予測。 言語分析APIとしてコンテナを作成して対応した。 ### CSV管理 → MySQLデータベース管理による高速化 - 経緯 開発チーム内部より「表示速度を早くすることでデモンストレーションにも対応できるようにする」という取り組みが始まった。 - 使用技術 抽出速度のボトルネックがCSVでの探索にあったことから、CSVでの管理からMySQLでの管理に変更。 - 工夫 会社内の基幹データベースと直接繋げると様々なリスクが発生するため、CSV連携の方式を採用。 「基幹DB→CSV→ダッシュボードDB」という連携方式になった。 CSVとダッシュボードDBではSQLLoaderを使用してデータの洗い替えを行い、 上記を実施するスクリプトを作成することでデータの鮮度を保つように工夫した。

### 概要 社内の全ての業務ソフトウェアのDB接続方式をOO4O形式からODP.NET形式に変更するプロジェクトに障害・品質担当として参加しました。 障害・品質担当としてメンバーの開発の過程で発生したバグ、障害の管理を行い、 これらの情報をナレッジとして蓄積しプロジェクト内で発生していたバグ対応時間を2/3に減らしました。 主な使用技術はVB6,VBA,Visual Studio データベース接続方式刷新プロジェクト 勤務期間：2021年7月~ ### 具体的な仕事内容 ・開発 ・障害・品質担当 メンバー：5名 利用言語：VBA,VB6 フレームワーク：.NET Framework ＜内容＞ ・社内システムのデータベース接続方式「OO4O」がoracle 11g以降使えなくなるため「ODP.NET」を使用した接続方式に変更 ・VBA,VB6で書かれたソフトウェアの品質を保ちつつ接続方式の刷新を行う ・障害・品質の担当としてメンバーからのバグ,イレギュラー報告を集約し対応策を返答する。 ### プロジェクトの流れ 各ソフトの刷新前に仕様を確認。同時に画面のキャプチャーを取得し、変更前の状態を保存。テスト項目についても作成。 その後、参照設定とコードを変更しDB接続方式をOO4Oミドルウェアを利用する方式からODP.NETを利用する方式に変更。 刷新前後でソフトウェアの品質に変更がないかどうかを確認し、問題がなければテストを通過。 以上の流れを5人で1200ソフトウェア分行う。

### 概要 心臓の血流解析会社でパッケージソフトの刷新プロジェクトに2年参加しました。 主な業務内容はソフトウェアの画面・機能の変更に伴う内部機能の移植。 さらにテスト担当としてテストコードの作成を実施し、ISO規約という国からの研究費を得られる規約を突破しました。 主な使用技術はC#,Visual Studio 医療用血流解析ソフトウェア刷新プロジェクト 勤務期間：2018年4月~2020年4月 ### 具体的な仕事内容 ・開発 ・テスト担当 利用言語：C# フレームワーク：.NET Framework ＜内容＞ ・心臓部分に疾患を抱えた方の血流を数値解析、シミレーションにより可視化する血流解析ソフト「iTFlow」の刷新プロジェクト ・画面部分のコード移植とテストコード開発という役割を担う。 ・テストコードの開発によりISO規約を突破。結果、国からの研究費を得る。 ### プロジェクトの流れ ソフトウェアの刷新対象の旧画面に紐づいている機能一つ一つについて、 .NET Frameworkとしてあらかじめ用意された新画面に移植を施す。 その際に新機能の追加や.NET Frameworkのバージョンアップに伴うコードの変更にも対応。 一機能の移植が完了した後はテストコードを動かしてISO規約を満たした状態であるかどうかを確認する。

# サービスの概要 2000アクセス/dayを記録したwebアプリケーションを作成しました。 - twitterの会話の履歴をもとに人脈相関図を作成するツールです。 (url:https://fanstatic.short-tips.info/twitter_network/@nominz) ユーザーはsns上の人間関係を見える化することで、これまで見えなかった人脈ネットワークの近隣のアカウントとコンタクトを図れるようにアカウントの運営を改善できます。 # 技術の概要 1. AWS,EC2 Ubuntu上に0から環境を構築。 1. 上記二つを繋ぐためにGit,Githubを使用。 1. その後、改修、拡張、本番環境と開発環境の移行のしやすさの観点からdockerを導入 1. google analytics,google seach consoleを用いて数値分析,seo対策を行い、検索順位を60位から5位以内に改善。 # サービスの運営上での課題と工夫 ## Dockerによる開発環境構築 ・課題 自前のPCはMacであるがEC2上にはUbuntuで管理しているため、開発環境と本番環境に環境面で差異が出てしまう。 ・使用技術 dockerとdocker-composeを使用。独学で書籍からdockerの知識を会得し,ymlファイル,dockerfileを0から作成した。 ・工夫 副次的効果として1プロセス1コンテナの原則に基づいた設計をすることでサービスが肥大化しても対応できる構築にできた。 ・成果 開発環境と本番環境のPC環境の面での差異をなくし、安定した品質に繋げることができた。 ## Git,Githubによる安全な管理と素早いリリース ・課題 高速な開発サイクルにより需要や運営の状態を見ながらサービスを柔軟に変更できるのが個人開発の強みだが、EC2上にあるサービスを直接操作するとソースの保守のリスクやリリースまでのサイクルに影響が出る。 ・使用技術 Git,Githubを利用したソースの管理へ切り替える。 ・工夫 「git add」から「git push~」までを入力するのが手間なのでそれらを一括にしたシェルを作成し 合わせて本番にリリースする際のコマンドもまとめ、こまめなコミット,プル,リリースができる体制をとった。 ・成果 改修からリリースまでのスパンを短く(平均15分の短縮)できた。 また、開発期間中にPCが故障し開発環境へアクセスできなくなるアクシデントが発生したが、 Githubへ保存していたためソースを失わずに済んだ。 ## 開発の全体像 利用言語：Javascript,Python3,Nginx ライブラリ：D3.js フレームワーク：Django その他：Lets'Encrypt, Docker, Docker-compose, Git, Github, EC2 ＜内容＞ ・twitterの会話の履歴をもとに人脈相関図を作成するwebアプリケーション ・ローカルに開発環境を、AWS,EC2 ubuntu上に0から環境を構築 ・上記二つを繋ぐためにGit,Githubを導入 ・改修、拡張、本番環境と開発環境の移行のしやすさの観点からdocker-composeを選択 ・Let's Encryptを用いたhttps対応 ・twitterのデータはtwitter apiを利用して取得する ・データベースはgithub上で管理 ## これまでのプロジェクトの流れ 1,AWS,EC2を購入 2,docker-composeを導入し、仮のwebアプリケーションで実装が可能か検証 3,ローカルでの開発環境にdocker-composeを使ったdjangoアプリケーションを作成 3,visual studioのremote機能を用いてEC2上でも動くかどうかを確認 4,ローカル開発環境とEC2開発環境を繋ぐGithub,Githubを導入 5,Route53を用いてドメイン取得 上記の手順で本格的な開発サイクルがスタート 1,ローカルの開発環境で開発を行う 2,gitを用いてadd commit pushを行う 3,EC2からpullを行う 4.本番環境の動作が問題ないかを確認 上記のサイクルを用いて、以下の4点を実装 ・D3.jsを用いた人脈図の可視化 ・Let's Encryptを用いたhttps対応 ・github上へのデータ保存 ・html css改良によるUIUXの改善 ・レスポンシブ化