ID:67603さん

プロジェクト概要（目的・人数・体制）

レガシーな生産システムと販売システムにSAPに置き換える。
情報システム5名、ITコンサル15名、営業統括6名、生産部門5名の計31名体制。

プロジェクトにおける自身の役割

1. マスタ整備
2. エンドユーザーへの教育
3. 業務フロー作成
4. 要件定義
5. 運用保守

当時の背景／抱えていた課題等

現場の方が情報システム部、ITコンサルの言っていることが理解できずに、双方伝えたいことが伝わらない状態でした。
また、業務をパッケージに合わせて変えるのではなく、パッケージシステムを業務に合わせようとしたため、多くのアドオン機能が必要になっていました。

自身が発揮したバリュー及び成果

・データーベース構築の際のデータークレンジング移行整理の一時的データーベースを格納、定義付けに関わり分かりやすい管理を行った。結果、マスタの稼働時には業務に影響を与えず、大きなデータ移行を達成した。
・現場の営業管理への教育実施。営業管理の業務経験を活かし、新システム（SAP）の操作マニュアル、業務運用のマニュアル、また業務のトレーニングも実施した。Power Point資料を作成する際は、アニメーションやイラストを活用し、受講者の復習意欲を高める工夫を意識。営業現場で勤務する従業員とは積極的にコミュニケーションをとることを心がけ、互いに質問や意見を交わしやすい雰囲気を作ることを心がけた。
・統合テストではシナリオからテストの作成までを行った。工場、営業現場と連携を密にとり、問題点の洗い出しとスケジュール管理を行った。
・SAP稼働後は現場からシステム問合せに対応し、必要に応じてシステムコンサルや情報システム部と連携しながらシステム改修を行った。システム改修をするときには、事前に費用対効果を収益還元法ベースで試算し、マネージメントに上程するようにした。その結果、本当に現場で必要な改修のみ行われ、かつ効果が高い案のみを上程出来た。

プロジェクト概要（目的・人数・体制）

世界3大ERPシステムのテクニカルサポートエンジニア。
同製品サポートエンジニア15名体制。

プロジェクトにおける自身の役割

法人のお客様からのお問い合わせに対して調査・デバッグを行い、バグか仕様か判断する。
バグだった場合、各国のエンジニアに報告し、BugFixするよう依頼する。

当時の背景／抱えていた課題等

ERPシステムの知識に乏しいお客様からの問い合わせがくることがあり、質問内容が明確でない、お客様自身が問い合わせ内容を理解していないことがありました。

自身が発揮したバリュー及び成果

Dynamics担当。問い合わせ対応、デバッグ、開発部門へのエスカレーションを実施。
・ 相手、場面に応じたコミュニケーションを行う。文字でのコミュニケーションを好まれるお客様にはメールで回答を行い、複雑な内容の場合にはできるだけTeamsで画面を共有して説明を行った。こうした丁寧かつスピーディな対応が評価され、回答後に頂くお客様からのフィードバック（５段階評価）は、4.7以上をキープしていた。
・お客様の言葉を鵜呑みにして、そのままエンジニアに伝えるのではなく、自分で手を動かして、現象の再現を行った。標準環境で再現しない場合にはDBやコードの共有をお願いする等して、現象の再現を試みた。もしお客様の環境でのみ現象が再現した場合には、デバッグを行い、原因の切り分けを行った。その結果、エンジニアからの回答を待つ時間が短縮され、エンジニアの信頼も得られた。
・チームメンバーとの関係を良好に保つ。チームでは担当分野が別れていた。（サプライチェーンと会計）しかし、ERPはサプライチェーンの問い合わせでも会計の知識が必要だったり、逆のパターンも存在する。担当の問い合わせに対しての責任は各自が持つが、チーム内で問い合わせに対してわからないことがあったときに相談しやすくするために、自分から挨拶をしたり、何気ないコミュニケーションを図った。
　また、これは海外国籍の同僚に対しても同様で、彼・彼女たちがお客様にメールを送信する前には添削をしたり、日本の文化・慣習で困っていることがあれば進んで手を差し伸べた。その結果、海外エンジニアと英語で込み入った話をするときには英語ネイティブの同僚に同席してもらい、自分が伝えたいことが明確に伝わってないと感じるときには補足をしてもうらことができた。

プロジェクト概要(目的・人数・体制など)

【概要】
プログラミングの勉強のため、動くものを作りたいと考え、元々作りたかったマッチングアプリの開発を行いました。
既に運用されているアプリを参考に、HTML、CSSをメインにモックの開発を行いました。
【どのような機能の開発・実装か】
筋トレ好きな男性が集まるマッチングアプリの開発。
【課題・問題点】
しばらく同じ作業（フロントの作成）が続き、プログラミングをする機会があまりなかったので、次のオセロ作成に移る。
【打ち手・使用した技術】
HTML、CSS、Vue.js

プロジェクト概要(目的・人数・体制など)

【概要】
プログラミン勉強のため、オセロの開発を行いました。
ネットで学習をしながら一人で開発をするのは大変でしたが、エンジニアのコミュニティに参加して出会った方やStack Overflowを用いて何とか動くものを作りました。
【どのような機能の開発・実装か】
オセロゲームの作成。
【打ち手・使用した技術】
HTML、CSS、Vue.js

プロジェクト概要(目的・人数・体制など)

PM２名、フロントエンド2名、バックエンド6名、アプリエンジニア2名、の計12名のチーム構成。
SAPに連携した倉庫システムの開発を行いました。

プロジェクト概要（目的・人数・体制）

既に運用しているシステムのリバースエンジニアリング。
チーム構成は、PM2名、運用保守2名、サーバーエンジニア3名の計7名構成。

プロジェクトにおける自身の役割

コーディング、テストを担当しました。
3か月程度テストの実施とテストの作成を行いました。
その後6か月程度不具合の解消を行った後に新規機能の開発に携わりました。

当時の背景／抱えていた課題等

システム自体は既に稼働していたのですが、不具合が多く、私が所属している会社にリバースエンジニアリングの依頼がきました。
ユーザーとプロパーの方も要件（労務）に関する知識がなく、要件が固まっていないことが課題でした。
テストも要件が分かっていない人が作成していたため、テスト結果があるべき姿と乖離していました。

自身が発揮したバリュー及び成果

FuelPHPフレームワークを用いた設計から開発、テスト、リリースまでを担当。
・常にユーザーの使い勝手を意識し、設計に対して疑問があればPM、設計担当者に背景を確認した。それらを咀嚼したうえで、より良い設計があればそれを提案した。その結果、機能によってはよりシンプルな設計で開発することができた。
例えば、承認フロー登録・変更画面で、設計当初は変更時は既に登録されているユーザーを空白にすることでそのユーザーは消去する動きにしていたが、それではユーザーが分かりにくいと考え、各ユーザーの横に「+」と「－」ボタンを追加した。それからjQueryを用いて消去するユーザーは非表示にする動きを加え、感覚的に操作できるようにした。
・自分だけの知識で実装が困難な場合には一人で抱え込まずに、リーダーに相談をした。その結果、必要な要件の実装ができた。また、アドバイス頂いたことは素直に実施し、自習も怠らない。（まずは公式ドキュメントを読む、Udemyの受講、技術書を読む）
・実装時には性能向上を意識し、MySQLのクエリを最適化した。その結果、実行時間を半分以上削減することができた。
・他者が作成したテストを鵜呑みにするのではなく、要件を整理して、理解したうえでテストを見直した。その結果、元のテストが誤っていることがわかり、正しいテストを作成することができた。
・FuelPHPフレームワークを用いて開発を行っているのか、「なぜ」動かくのかを意識しながら開発を行っている。
・基本的にリモートワークが前提の職場であったが、出勤するときには周りの人に挨拶をして、コミュニケーションを図り、チームの関係構築にも働きかけた。その結果、チャット内・通話共に疑問点があった時に質問しやすい雰囲気を作ることができた。

プロジェクト概要（目的・人数・体制）

出版社向けの経理システムリプレイス。
チーム構成は、PM3名、エンジニア10名の計13名構成。

プロジェクトにおける自身の役割

モックを作成した後、現在は基本設計、コーディングを担当しています。

当時の背景／抱えていた課題等

インボイス対応に伴う経理システムのリプレイスを行っています。
途中コロナや、要件がなかなか決まらないことからスケジュールがタイトになっていますが、
設計・開発をする上での疑問・質問は都度確認をして手戻りがないように心がけています。

自身が発揮したバリュー及び成果

リーダーが言いたいことをくみ取って、設計書に反映するように意識しています。
基本はチャットでのやりとりですが、画像を用いて、お互いの認識の齟齬が無いように工夫しています。