職務経歴書

最終更新日: 2021/12/01

目次

個人データ

言語経験

保有資格など

職務経歴

株式会社I社(2016/05/16〜)

企業概要

研究者交流サイトプロジェクト(顧客: E社)

プロジェクト概要

2020/10〜2020/12の期間に担当したプロジェクトになります。 研究者交流サイトプロジェクト(顧客: J社), および研究者交流サイトプロジェクト(顧客: H社)、研究者交流サイトプロジェクト(顧客: N社), と関連します。既存システムを、E社様向けにカスタマイズして提供しました。

構成

Webアプリケーションである『交流サイト』、およびアプリケーション告知のための静的サイト(以降『告知サイト』)を扱いました。基本的な構成は研究者交流サイトプロジェクト(顧客: H社)案件と同じです。

本案件より、サイトのメンテナンス画面表示機能を追加しました。従来は瞬断が発生しておりました。ALBを加え、そのルールセットを更新して画面を切り替える構成にしました。ビジネス的理由から、テスト、ステージング、本番環境共通でひとつのALBを使用することになりました。従来は環境別にスタックを作成しておりました。従来の切り分けになじまないため、3環境共通のCloudFormationスタックを新規に追加しました。このスタックでは、AWSリソースはALB,ACM,S3等を使用します。

チームメンバー

顧客窓口および外部仕様決定者1名、顧客窓口およびスケジュール決定者1名、開発者2名、以上計4名のチームでした。

担当業務

開発者として参加しました。 交流サイトのインフラ構築およびアプリケーション開発を中心に行いました。 適宜顧客窓口、外部仕様決定、スケジュールについてサポートしました。

私が体調不良や事故で抜けた時でもプロジェクトが回るよう、引き継ぎを進めました。交流サイトのインフラ/アプリケーション更新について、インフラ担当者に引き継ぎました。

工夫した点

フロントエンドの各種アセットを、保守管理を行いやすい構成に変更しました。過去案件研究者交流サイトプロジェクト(顧客: J社)で記載したとおり、本アプリケーションは社外の個人開発者のかたから引き継いだものです。JSライブラリはCDN読み込み、もしくはコピーしたものをサーバーに保存するかたちで活用していました。自作JSスクリプトはJSファイルだけでなくPHPファイル内Scriptタグにも存在していました。

今回改善するにあたり、まずページごとに必要なJSスクリプトおよびJSパッケージの依存関係の把握を行いました。それからPHP内ScriptをJSファイルへ切り出しました。外部パッケージはnpmで管理するようにしました。Webpackを導入し、ページごとに必要なファイル群をバンドルして読み込むようにしました。その後、自作JSスクリプトをすべてTypeScript化しました。なお、社内プログラマー数名とすり合わせた結果、JSも書くことはできる設定にしてあります。CSSもSassを活用可能な設定を行いました。その後既存のCSSファイルをSCSSへ置き換えました。

研究者交流サイトプロジェクト(顧客: N社)

プロジェクト概要

研究者交流サイトプロジェクト(顧客: J社), および研究者交流サイトプロジェクト(顧客: H社)の別顧客の案件です。既存のシステムを、N社様向けにカスタマイズして提供しました。2020/08〜2021/01の間にわたるプロジェクトでした。

構成

Webアプリケーションである『交流サイト』、およびアプリケーション告知のための静的サイト(以降『告知サイト』)を扱いました。詳細は研究者交流サイトプロジェクト(顧客: H社)案件と同じです。

チームメンバー

顧客窓口および外部仕様決定者1名、顧客窓口およびスケジュール決定者1名、デザイナー1名、開発者2名、以上計5名のチームでした。

担当業務

インフラ構築およびアプリケーション開発を中心に行いました。 顧客窓口、外部仕様決定、スケジュールについてサポートしました。

前回案件にて、私の担当範囲が広がりました。体調不良、事故などが私に起きた時、プロジェクトが立ち行かなくなることを懸念しました。いわゆるバス係数が低い状態です。手始めに、告知サイトのインフラ構築および運用をインフラ担当者へ引き継ぎました。

工夫した点

研究者交流サイトプロジェクト(顧客: H社)のプロジェクトマネージメントは失敗だったと判断しました。その改善のために動きました。プロジェクトの進め方についてチームで共通認識を持ち、スムーズに仕事を進めることを目的としました。具体的には作業の抜け漏れ防止、担当がはっきりしない業務を減らすことを実現を目指します。アプリケーション開発プロセスをステップに分け、各ステップの仕事内容を定義(例: 外部仕様とは何か、何では無いか)、仕様ツールを例示(例: XD)、成果物(例: XDによるプロトタイプ)を定義しました。キックオフミーティングを開催し、上記プロセスでプロジェクトを進めることでチームの合意を取りました。また、分担の合意を取りました。 以上により、従来あいまいだった責任と権限の所在をはっきりさせました。担当者間で協力するのはもちろんですが、各ステップで最も責任をもってあたるべき担当者を決めました。 結果、仕事の依頼、リマインドが行えるようになりました。前回H社案件のように、未着手業務を自分がすべて巻き取る、という事態は回避できました。

研究者交流サイトプロジェクト(顧客: H社)

プロジェクト概要

研究者交流サイトプロジェクト(顧客: J社) の別顧客向けの展開プロジェクトです。H社向けカスタマイズ、および運用を行いました。2020/06〜2020/08の期間のプロジェクトでした。

構成

Webアプリケーションである『交流サイト』、およびアプリケーション告知のための静的サイト(以降『告知サイト』)を扱いました。

交流サイトについてです。インフラ構築はCloudFormation(SAM)で行いました。使用したAWSリソースはLambda, EC2, S3などです。EC2のプロビジョニングおよび構成管理は、ヘルパースクリプト及びユーザーデータにて設定しました。具体的にはDocker, Git, Nginx, cron, CloudWatchエージェント設定、ヘルパースクリプト自体の設定、などの設定です。CI/CDはGitLab CIを使用しました。以上は私が担当しました。なお、Lambdaはユーザーからアップロードされた画像のリサイズおよびサムネイル生成に活用しました。

告知サイトもインフラ構築はCloudFormation(SAM)で行いました。使用したAWSリソースはEC2です。交流サイト同様EC2のプロビジョニングおよび構成管理は、ヘルパースクリプト及び[ユーザーデータ]にて設定しました。具体的にはDocker, Git, Nginx, CloudWatchエージェント設定、ヘルパースクリプト自体の設定、などの設定です。CI/CDはGitLab CIを使用しました。以上は私が担当しました。 告知サイトのアプリケーションレベルでは、DockerおよびDockerComposeを用いてnpm環境および環境別設定をコンテナ化して静的ファイルをビルドしていたようです。

チームメンバー

交流サイトは、プロジェクトマネージャー1名、開発者1名、アドバイザー1名でスタートしました。 告知サイトのほうは、同プロジェクトマネジャー1名、デザイン兼フロントエンド開発者が1名でした。

開発者は、従来インフラ担当を行ってきた方でした。アプリケーション開発を希望し、本プロジェクトの担当になりました。 私は、当初は、サポートのためのアドバイザーとして参加しました。

担当業務

当初は、システムをよく知る者としてアドバイザーとして参加しました。

しかし、関わってみると、数行の文言による要求をお客様から数行いただいただけの状態ででプロジェクトマネージャーが実装をアプリケーション開発担当者に依頼していました。仕様決定をアプリケーション開発担当者とともに行いました。具体的には顧客の要望ヒアリング、プロトタイプ作成、スケジュール作成および合意などです。

上記準備の後、一週間ほど、アプリケーション開発担当者(普段はインフラの方)に実装頂きました。しかし、やはり開発経験がないため、進捗が上がりませんでした。スケジュールには全く間に合わない進捗でした。そのため、私が実装にも加わりました。(なお、進捗次第で開発に参加することは開発担当者と私で事前に合意済みででした)。その後、アプリケーション開発担当者の方は他案件が忙しくなり、本プロジェクトには深く関わらなくなりました。

最終的に、顧客折衝、要望ヒアリング、スケジュール作成、デザイン、仕様決定、インフラ構築、実装など、契約以降のほぼすべての業務を引き受けました。

工夫した点

当初の開発担当者の方が、開発業務を担当するのは初めてでした。そのため丁寧な説明を心がけました。実装の際、設計を行い方針を文字で伝達。お互いにリモートワークでしたので、Visual Studio Live Shareにて実際にコードを書くところを見せて説明しました。

従来、お客様から数行の文言による要求を受け取り、それが開発者に伝えられ、開発者がデザインおよび実装を行う、というやりかたが頻繁に起こっていました。本プロジェクトではプロトタイプ作成を行いました。お客様と合意を取って実装後の変更を減らす、デザインと実装を分けてデザインのクオリティを上げる、細かな点まで反映したプロトタイプを作って実装前に懸念事項に気づくなどの目的のためです。プロトタイプ作成にはXDを使いました。デザイナーの負担を下げるため、私がヒアリングおよびXDでプロトタイプを作成し、デザイナーにレビューいただく形で作成しました。

PHPアプリケーションを、DBの保守管理を行いやすい構成に変更しました。過去案件研究者交流サイトプロジェクト(顧客: J社)で記載したとおり、本アプリケーションは社外の個人開発者のかたから引き継いだものです。従来、PHPからのDB操作はSQLを書く、DBスキーマのバージョン管理はなく、おそらく必要に応じスキーマダンプを取っていたようです。ORMおよび、DBマイグレーションツールを導入しました。

サードパーティCookie廃止の対応計画策定

プロジェクト概要

客先常駐での仕事でした。常駐先は、ECサイト構築および運用サポートを行う会社でした。2020/05、チームに加わり作業しました。

構成

全体像は不明です。後述の担当業務では、Perl, PHPのスクリプトを修正しました。

チームメンバー

4人で本プロジェクトを担当しました。いずれもプログラマーです。要望、修正方針は常駐先とすり合わせて決定しました。

担当業務

常駐先サービスの挙動をコードリーディング、サードパーティCookie廃止時の影響箇所を特定、修正箇所および修正内容を決定、社内共通開発環境にてサードパーティCookie廃止時の挙動テストを行いました。

工夫した点

特筆事項はありません。

コメント付与

プロジェクト概要

客先常駐での仕事でした。常駐先は、ECサイト構築および運用サポートを行う会社でした。2020/04、チームに加わり作業しました。

既存コードの特定箇所に特定のコメントを追記する、という非常に単純なプロジェクトでした。修正箇所が膨大にありました。

構成

全体像は不明です。後述の担当業務では、Perl, PHPのスクリプトを修正しました。

チームメンバー

5人で本プロジェクトを担当しました。いずれもプログラマーです。要望、修正方針は常駐先とすり合わせて決定しました。

担当業務

5人で既存コードの修正を行いました。修正内容は非常に単純なものでした。特定のコードに特定のコメント付与するというものでした。しかし、修正箇所が膨大にありました。

工夫した点

私ともうひとりのメンバーで、修正処理の自動化を行いました。 該当箇所を判定、置換するスクリプトを書きました。

改ざん検知システム

プロジェクト概要

2020/02〜2020/04の間、社内プロジェクトとして開発しました。 リリースには至りませんでした。

構成

サーバーサイドはJSON APIとして機能するPythonのFlaskインスタンスが4つ、クライアントサイドはVue.jsを使ったSPA、という構成でした。

機械学習を見据えていたためPythonを選択しました。Pythonや機械学習の習熟に時間がかかることを考慮し、クライアントサイドのライブラリはメンバーで使用経験のあるVue.jsを選択しました。

チームメンバー

私と後輩の2名でした。

担当業務

私と後輩で、ユースケース図、クラス図作成、実装を行いました。

工夫した点

特筆事項はありません。

研究者交流サイトプロジェクト(顧客: J社)

プロジェクト概要

2019/10〜2019/12の期間、既存Webアプリケーションの運用代行を行いました。従来、個人開発者のかたが顧客ごとにインスタンスを立てて運用していたアプリケーションです。今回の顧客は国立法人であり、運用要件が従来顧客よりも厳しく、個人で対応することが難しいとの理由で、弊社がカスタマイズおよび運用を引き受けました。

なお、本件以降の新規顧客向けの開発運用も、弊社で引き継ぐこととなりました。

構成

元々、アプリケーションは個人開発者の方によって開発済みでした。Apache+PHPの構成でした。PHPファイル数100未満程度の、フレームワーク等は使っていないシンプルな構成でした。弊社にてDocker化しました。また、ミドルウェア設定ファイルもリポジトリ管理下におきました。

クラウドはAWSを利用しました。具体的にはEC2, CloudWatch, S3, SNS, CloudFormation(SAM)等を使用しました。

チームメンバー

チームは上司と私の2名でした。

プロジェクト初期に上司が折衝および契約を行いました。また、契約満了時に請求書を発行しました。

それ以外の業務はすべて私が担いました。具体的には、ミドルウェア設定をリポジトリ管理、アプリケーションをコンテナ化、本案件向けカスタマイズの詳細仕様決定および実装、脆弱性診断および見つかった脆弱性の修正、AWSインフラ構築、監視設定、負荷試験、納品物作成、顧客問い合わせ対応などを行いました。

工夫した点

個人として初めてAWSコンソールを操作しました(おそらく会社としても1,2案件で使ったのみ)。従来案件では、サーバーとミドルウェアを社内インフラ担当者に用意してもらい、アプリを構築していました。

本案件では、インフラ構築の段階から私が担当しました。最初に一時間程度、インフラ担当者からAWSコンソールからの基本的AWSリソース（EC2、セキュリティグループ等）の作成および設定方法を教えていただきました。その後ドキュメントを参考にログ監視、アラートのメール通知設定等を行いました。最後に、CloudFormationでのコード化を行いました。本パッケージは他顧客にも展開予定であり、今後の省力化のために行いました。ただし、一部リソースはCloudFormationでは管理しきれず、AWS CliやAWSマネジメントコンソールからの操作が要る状態です。

旅行サイトリプレースプロジェクト

プロジェクト概要

2019/02〜2019/09の間、一般消費者向けの、旅行ツアーおよび航空券予約サイトのリプレースを行いました。

構成

Linux(CentOS), Apache, MySQL, PHPです。EC-CUBE4を拡張する形で開発しました。

チームメンバー

チームは計5名、各々別プロジェクトも抱えながら参加しました。

私以外の4名は、インフラ担当1名、デザイン兼一般ユーザー向け画面の作り込み担当1名、管理画面担当1名、一般ユーザー向け（申込みフロー意外）担当1名でした。

担当業務

開発者として参加しました。 一般ユーザー向け画面の申込みフロー関連画面の実装を行いました。 サーバーサイド、クライアントサイド共に担当しました。 私にとって消費者向けのアプリ構築は初めてでした。業務向けアプリよりも高度なデザインを実装しました。(デザイン自体は社内デザイナーさんにやっていただきました。)

実装以外にも、開発中は開発体験向上の施策も行いました。 社内開発環境、お客様プレビュー環境の設定を行いました。

開発がひと段落してからは、脆弱性検査および負荷試験を行いました。（脆弱性修正、ボトルネック改善は適時チームで分担しました。）

工夫した点

CD(継続的デリバリ)を導入しました。具体的には、developブランチに変更があると、自動で社内ステージング環境に反映されるようにしました。(お客様プレビュー環境もボタン一つで更新できるようにしました。) 本プロジェクトでは毎週、開発の進捗をPMに報告しておりました。報告ミーティングの直前は、developブランチを社内ステージング環境に反映していました。従来は手作業で更新しており、属人化や作業ミス、更新忘れが発生していました。本プロジェクト開発時、ちょうど社内GitLabのバージョンアップがあり、GitLab CIが統合されたバージョンのGitLabに更新されました。 以前よりCI/CDに興味があったため、私の方で本プロジェクトのCI設定を行いました。(権限の問題で、Shared Runnerの設定はインフラ担当の方に依頼しました。) 更新作業が不要になった結果、上述の属人化などの問題が解消されました。加えて、報告直前のMR（マージリクエスト、GitHubで言うPR）のマージの精神的ハードルが下がる、などの効果があったように思います。

他にも開発体験向上のため、GitLabと社内チャットの連携を設定しました。従来GitLabでMR、レビューコメントなどをつけるたびにチャットに別途投げていた無駄が解消されました。技術的には簡単です。ただ率先してやったのが自分でした。

開発が一段落したのち、脆弱性検査、負荷試験を行いました。 脆弱性検査では、『体系的に学ぶ 安全なWebアプリケーションの作り方』を参考にOWASP ZAPを使用しました。また、同時期にBlack Hat USA 2019に参加したのですが、そこで学んだBurp Suiteを使用しました。 負荷試験では、『Amazon Web Services負荷試験入門』を参考に、JMeterを使って試験しました。 脆弱性検査、負荷試験ともに、要修正点が見つかりました。とくに、負荷へ配慮した開発ができておらず、要修正点が数箇所みつかり、ボトルネック改善に時間がかかりました。アプリ開発だけしているだけでは身につかない視点を得ることができました。

旅行業務管理アプリ機能拡張プロジェクト

プロジェクト概要

2018/10〜2018/11の期間、旅行代理店を営む顧客企業および顧客企業の顧客で使う、旅行業務管理用Webサービスを開発しました。 開発者として参加するとともに、スクラムマスターも担当しました。

スクラムマスター担当の経緯

弊社社長がスクラム社内勉強会を開き、スクラム導入の機運が高まったときがありました。 以前よりソフトウェア開発手法、とくにアジャイル開発に興味を持っていた私は、ちょうど始まった新プロジェクトのスクラムマスターに立候補しました。

責務

プロジェクトチームに、スクラムを根付かせる責務がありました。

とくに、精度の高いリリース計画が建てられるようにする責務を強く感じていました。 従来弊社では、リスケジュールのさい、再度設定した期限が短すぎ、ふたたび計画に遅れてしまう、という事態がしばしばありました。リスケジュール時は、ビジネス的な観点から新期限が仮で決まり、あとは開発者がその新期限で間に合うかを回答する、という段取りをとっていました。遅れる原因は、開発者としてもプロジェクトをなんとか終わらせたいという気持ちがあるため、希望的観測でできると返答しまうことだったと推測しています。スクラムでは実績(ベロシティ)に基づきリリース計画を立てられるため、上述の問題が解決されると期待していました。

工夫

リリースまで一ヶ月しかない、開発チームの4人中3人は使用技術に詳しくない、同じチームになるのが初めての人も多い、スクラムも初めて、という余裕のない状況でした。個人的にはルールは厳格に守るのが好きですが、厳しくスクラムを運用しようとすると回らなくなると考え、柔軟に運用することを方針としました。

第二スプリント(プロジェクト二週目)は進捗が芳しく無く、チームメンバーから、時間がないためスプリントレトロスペクティブ(振り返り)を止めたい, 仕事の段取りや割り振りの仕方をスクラム導入以前のように戻したい、という声があがりました。柔軟な運用を心がけるとはいえ、そのとおり受け入れると、あまりに骨抜きのスクラムになってしまうというジレンマがありました。チームメンバーと相談し、今スプリントは一時的にスクラムイベントを停止するが、次からは復活させる、という方策で凌ぎました。(チームの崩壊は避けられたものの、プロジェクトが苦しいときに役立たないと思われているのは、自分がスクラムイベントの意義を伝えきれていないからだ、と反省しました。)

結果

本プロジェクトは、結局当初の予定に間に合いませんでした。リスケジュールすることになり、あと一週間延長すれば終わるのかどうかの回答を求められました。そのときに、実績をもとに、あと二週間は要るという回答をしました。後ろ向きの回答ですが、より現実的な回答ができるようになったという意味で進歩だったと思っています。

ブログ風Webアプリ開発プロジェクト

プロジェクト概要

2018/06〜2018/08の期間、顧客企業内およびその顧客企業の顧客で使う、ブログのような業務用Webサービスをスクラッチ開発しました。

構成

同一顧客との過去のプロジェクトで、すでに、 サーバーサイドに、APIモードで動くRuby on Railsを6インスタンス分開発していました。 クライアントサイドに、デスクトップアプリとしてElectronアプリを開発していました。

今回の開発では、 サーバーサイドはすでにあるRails APIサーバーを拡張して開発することにしました。 クライアントサイドは、新たにWebブラウザで閲覧可能なアプリケーションが必要でした。

考慮の結果、Nuxt.jsフレームワークを使用することに私が決めました。チームメンバーにVue.js経験者が多かったこと、Nuxt.jsではVue.js開発のベストプラクティスが簡単に導入できると判断したことが大きな理由です。

Nuxt.jsではSSR、SPA、静的に生成されたファイル、の3つのモードで運用できますが、今回はSPAモードを採用しました。サイト内に動的なページを含むこと、また、ビジネス的な制約から、サーバーサイドに(Node.jsなどの)プログラムを追加インストールしづらかったためです。

チームメンバー

チームは私、後輩一名、新人一名の計3名でした。

担当業務

顧客からのヒアリング、画面仕様ドラフト、内部仕様設計(API設計、DB設計等)、スケジュール見積もりは私が行いました。外部仕様はデザイナーさんに仕上げていただきました。実装は私含めチームメンバー3人で行いました。

RESTful APIを心がけ設計しました

内部仕様設計は、SwaggerでAPI仕様を書くところから始めました。(既存のRailsAPIは、根幹部分は上司に設計していただいたため、自分がゼロから書くのは今回が初めてでした。)規約として、RESTful APIを心がけました。検索結果をどう表現するか、単数形複数形をどう表現するかなどを学びました。

デザイナーさんとの協業を行いました

従来は、社内にデザイナーさんがおらず、業務システムということもあり開発時にBoostrapなどのフレームワークを使ってデザインしていました。このプロジェクトのタイミングでデザイナーさんが会社に加わり、協業しました。Adobe XDでデザインしていただき、それをコード化しました。

モダンなフロントエンドツールに触れました

npm, webpack, Sassなどのツールを活用しました。いままでもnpm, webpackは一応使っていたものの、あまり自分から設定を変更することはありませんでした。今回、npm scriptsを追加したり、Sassを導入するためにwebpack設定を変えたり、いままでより能動的に使いました。

留学業務アプリ開発プロジェクト

プロジェクト概要

2017/05〜2018/01の期間、旅行代理店業務を営む顧客企業の留学業務システムをスクラッチ開発しました。

構成

サーバーサイドはRuby on RailsのAPIモード(ちょうどRails5がリリースされたころでした)、クライアントサイドはElectron + Vue.jsで構成しました。

チームメンバー

チームは上司一名、私、新人一名の計3名でした。 プロジェクト前半は上司が折衝、システム構成および外部仕様設計を行い、私と新人は内部仕様設計および実装を担当しました。 プロジェクト後半は私が折衝および外部・内部仕様設計、新人が実装を行いました。

新人を指導しました

新人はRuby, JSともに未経験者でしたが、私が少しずつ指導しました。明確な指示をすること、明確な説明ができることだけ教えることを心がけました。徐々に任せられる範囲は広がり、プロジェクト最終期には実装はほぼ任せられるまで成長してくれました。

自動テストを導入しました

私の知る限り、弊社では自動テストは行っていませんでしたが、今回サーバーサイドの自動テストを導入(、および後輩に強制)しました。仕様変更の回帰テストが簡単に行えるようになり、プロジェクトが安定するようになったと思っています。

環境をDocker化しました

弊社では、開発環境構築手順はWikiにメモ、本番環境更新はtarファイルを固めてアップロードするという手順が一般的だったと認識しています。本プロジェクトでは開発環境および運用環境は、私がDockerおよびDocker Composeで記述しました。(本番環境の設定はは一部を上司に修正いただきました。)環境構築および本番環境更新を少ない手間、小さいリスクで実施できるようになったと思っています。

自動リントチェックを導入しました

細かい工夫で言うと、後輩がデバック用コード(byebug, debuggerなど)を入れたり、一貫性のない空白文字をいれたままコミット、プッシュすることがありました。git hookでpush時にデバッグ用コードがないかチェックするrubyコードを書いたり、rubocopなどの静的解析ツールを導入するなどの機械的な補助を行うことも行いました。

本番化を担当しました

本番化も当初は私が担当しました。本番環境と同一のステージング環境を構築し、ステージング環境で確認してデプロイ手順を固めました。いまでは後輩に任せています。

リポジトリ運用を工夫しました

運用開始後、追加開発済み機能の時間的、部分的にフレキシブルなリリースが求められるようになりました。従来のシンプルなgit-flowでは対応が難しかったため、フィーチャーブランチの切り方、マージの仕方の運用を工夫しました。詳細はブログ記に記述しました。

その後

現在、顧客企業内で使用いただいています。バグ修正や追加要望対応を継続しています。

金融業務Webアプリ TomcatからRailsへの移行プロジェクト

2017/03〜2018/07にかけて、顧客企業の業務用WebアプリケーションをTomcatからRailsへ移行しました。 チームは私一名でした。 顧客との折衝から実装まですべて担当しました。 既存アプリケーションの仕様書がほぼ無いようなものだったので、サイトの挙動とコードを見て仕様を読み取り、適宜内部仕様を変えて実装しました。

購買情報管理Webアプリ グラフ描画のFlashからJSへの代替プロジェクト

2016/11〜2017/03にかけて、RailsWebアプリ内にてFlashで描画されていたグラフのJavaScript化を行いました。 チームは私一名でした。他の先輩からアドバイスをもらいながら開発しました。Highchartsライブラリを使用しました。

ECサイトおよび在庫管理アプリ開発プロジェクト

2016/06〜2016/10にかけて、顧客企業との折衝を行いました。チームは3人程度でした。

社内ツール作成プロジェクト

2016/05〜2016/07にかけて、社内で使う技術者日報ツールおよび営業日報ツールの開発を行いました。 Ruby on Railsにて、会社の先輩方の助言を頂きながら、一人で開発しました。(いちおう新入社員2名であったが、実質私ひとりで開発)

M株式会社(2011/04/01〜2014/06)

企業概要

業務内容概要

金融業界にて、新規/既存の法人営業を担当しました。