Shinya Matsumoto

①どのようなチームで 【チーム構成（人数）】 ・ディレクター（1） ・バックエンド（1） 【チーム内の自身の役割】 ・バックエンド 私は設計→コーディングを行なっていくフェーズをメインに担当しました。 ②どのような機能を 【機能概要】 人材派遣会社のホームページの保守、運用を行いました。 私は設計→コーディングを行なっていくフェーズを担当しました。 【課題とその背景】 こちらのクライアントはほとんど機能の改修はありませんでしたが、 本番環境の更新を任されていました。 毎月そのホームページにフリーで提供している壁紙があり、 それをメールで受け取り、要望があった日に壁紙を張り替えて私が本番公開を行なっていました。 ③どのような技術を用いて ◯言語：Java バージョンは6です。 ◯インフラ：AWS ・EC2 ・RDS ・S3 ・Route53 ・ACM 基本的にAWSで出来る事はAWSで行う様に統一されていました。 EC2二台をALBで冗長化し、 JenkinsでCI/CDを行い、 warをデプロイしていました。 ◯DB：Oracle ◯バージョン管理：GitLab EclipseのパースペクティブにあるEGitを使ってGUIで使っていました。 ④どのような工夫をして 【着目点】 開発手順としては、 メールで受け取った壁紙を受け取る ↓ HTMLを触って張り替え ↓ 指定された日に本番公開 ↓ メールでクライアントの担当者に張り替え完了した旨を伝える といった流れでした。 何か不具合があると、クライアントからメールや電話が来るので、 その対応から単にプログラムを書くだけでは無い、 クライアントとのコミュニケーション能力も養う事が出来ました。 【該当技術使用や行動の背景】 技術に関しては特に高度な事が要求される訳では無く、 機械的な作業ではありました。 その中で、本番公開時にJenkinsを回してCI/CDで生成したwarをEC2にscpするのですが、 その際に社内規則的に本番公開の度に、 SSHして入力するコマンドの手順書をExcelで作る必要がありました。 それ程時間を要する作業は無いですが、 業務効率化の為そのコマンドを生成するマクロを組んでExcelを作成していました。 ⑤どのような成果に繋がったのか そのホームページを訪れ周遊するユーザーに壁紙を毎月違う壁紙を提供する事が出来ました。 本番環境を触る事が要求されたので、 責任感とプレッシャーは大きかったです。 やるべき事はそれほど難しい事では無く機械的な作業ではありますが、 ミスが無いようにしっかりと確認を怠らず、 気を抜かない様に作業を行う事を意識していました。

①どのようなチームで 【チーム構成（人数）】 ・ディレクター（状況による） ・バックエンド（状況による） ・デザイナー（状況による） 【チーム内の自身の役割】 ・バックエンド 私は設計→コーディングを行なっていくフェーズをメインに担当しました。 ②どのような機能を 【機能概要】 主に人材派遣会社の人事部の方が利用する人材管理システムになります。 派遣会社に常駐するスタッフの方々の情報管理や派遣先のクライアントの情報管理、 給与計算や勤怠の管理等の人材管理システムにある基本的な機能を持つ自社のシステムがあり、 それをクライアントに合わせて各々要望があれば必要なシステムを随時追加で改修を行っていました。 【課題とその背景】 クライアントのニーズを上流の担当者であるディレクターがヒアリングを行い、 都度それを元に改修を行なっていくので柔軟に多様な課題に対応していく力が求められました。 具体的には、 　人事部の方が従業員のシフトをシステムに登録する際に、 　月の労働時間が80時間を超えた際にはエラーメッセージを出力して欲しいといった要望や、 　法律改正に伴い、 　派遣会社に登録されている派遣の方の仕事が決まった際に、 　その派遣先に送付する雇用条件が明記された書類があり、 　そこに書かれた文言を厚生労働省が掲示する、 　新たな法律に沿った形に加筆・修正して欲しいといった要望などがあり、 対応を行いました。 システムを利用するクライアントの方達の業務の内容とその要望に合わせて、 ニーズを適切に理解しバリューのあるものを勘案していくので、 フィットギャップが無いかを常に意識しながら作業を行なっていました。 ③どのような技術を用いて ◯言語：Java バージョンはクライアントによって違いますが、6、7、8が多かったです。 ◯フレームワーク：Seaser2 多くは自社独自のフレームワークを使って開発を行なっていました。 MVCのフレームワークはSeaser2が選定されていました。 ◯インフラ：AWS ・EC2 ・RDS ・S3 ・Route53 ・ACM 基本的にAWSで出来る事はAWSで行う様に統一されていました。 EC2二台をALBで冗長化し、 JenkinsでCI/CDを行い、 warをデプロイしていました。 私が行なっていた作業としては、 複数の利用者の方々が同時にシステム内でPDFを大量出力する様な作業を行なった際等で、 EC2のCPU利用率が上がって画面の表示がされなくなってしまった時には、 EC2の再起動やTomcatの再起動を行いCPUの利用率を下げるといった運用を行なっていました。 ◯DB：Oracle ◯バージョン管理：GitLab EclipseのパースペクティブにあるEGitを使ってGUIで使っていました。 ④どのような工夫をして 【着目点】 基本的に開発はディレクターからのトップダウン形式で、 クライアントからディレクターがヒアリングしたニーズを聞き、 それを元に作業を行なっていました。 【該当技術使用や行動の背景】 技術に関しては自社で過去に使用経験のある様な技術が選定されていました。 対クライアントとのやり取りが要件定義から運用まで長期で永続的に続くので、 運用中に何か問題が起きた際に対応できるナレッジを持つ人材が必要となる為、 再現利用性の高い技術を使い、 安定運用に重きを置いて保守を行なっていくといったスタンスでした。 ⑤どのような成果に繋がったのか クライアントのニーズを元に開発を行い、 常に最良、最低限のコストでスケールしていくので、 改修を行えば行う程、そのクライアントにとって価値の大きいシステムに成長させる事が出来、 バリューのある機能を提供し続ける事が出来ました。 開発を行なっていく中で、 その機能は本当に必要なのか？UIとして使いにくくないか？ 等の疑問が出てきた際はディレクターと相談を行い、 設計の改善を行う必要があるかのコミュニケーションをクライアントと取る様に促していました。 例えば、 あるプロジェクトで一ページに50枚の画像を表示するページを作る作業を行った際、 スマートフォンでレスポンシブした時にも同様に50枚の画像を表示する様な仕様になっていました。 そのページ内では画像を検索するボックスがその50枚の画像の表示の更に下にあった為、 ユーザーが検索を行おうとした時にPCでは問題無いですが、 スマートフォンで表示した際に指でスクロールを何度もする必要があり、 UIとしてこれはどうなのか？と疑問に思いディレクターと相談する事になりました。 結果として、 ディレクターとの話し合いの末PCでは画像50枚を、 スマートフォンではユーザーエージェントによる制御を入れて、 レスポンシブした際には画像20枚を表示する機能に変更になりました。 私が担当しているフェーズは下流がほとんどですが、 おかしいと感じた実装をおかしいとディレクターにボトムアップ出来ない様なプログラマーにはなりたくないと考えています。 例え的外れであっても自分が疑問に思った点はクリアにして納得のいく開発が出来る様、 常に疑問を持つ様に心がけて業務を行なっています。