ID:63188さん

## プロジェクト概要 グループ会社間で利用する発注ワークフローシステムの開発 【主なシステムの流れ】 下記のようにワークフローが流れていくシステムで画面数が24つほど、 他にもメール送信機能や、帳票プレビュー機能、SAP連携機能などがありました。 ①発注担当者が発注書に必要な情報を画面ごとに入力していく。 　→ 発注するもの・ことを明細単位で入力できる。（納入日や金額、税率や外貨など入力可能） 　→ 仕入れ先の入力、必要なファイルの添付　など ②発注登録が完了した後、承認者が承認することができる。（差し戻し、取り戻し、修正などで再度発注登録をやり直すことが可能） 　→ 発注書・納品書が取引先に送付される。 ③発注に対して納入されたら受入・計上を明細単位で登録することができる。 　→ 必要なファイルの添付、納入物の内容が問題ないか（合格・不合格）を選択できる ④受入・計上登録が完了した後、承認者が承認することができる。（差し戻し、取り戻し、修正などで再度受入・計上登録をやり直すことが可能） 　→ 支払通知書などの帳票が取引先に送付される。 自分が退場する時には、3つの会社で使用していたが、ゆくゆくはもっと増える予定で月に200近い発注がされるシステムでした。 開発体制は、リリースまではウォーターフォール開発。リリース後はアジャイル開発に近く、月1でバグ修正・新機能リリースを繰り返して行なっていました。 ## 担当 バックエンド・フロントエンドエンジニアのメンバーとしてプロジェクトに入り、基本設計書・詳細設計書の作成・修正〜リリース後の運用・保守を担当しました。 他にも新規参画者のフォローや、コードレビュー、不正ログインユーザのログ検知バッチ開発、本番データ修正のSQLパッチ作成なども行いました。 ## 使用技術 java8, intra-mart(TERASOLUNA5系, SpringBoot), PostgreSQL, HTML, CSS, JavaScript(jQuery),Git, Linux, MyBatis ## 取り組み ・バグ対応、新規機能追加、機能改修 Backlogチケットで管理されており、1ヶ月で約10~15件ほど対応、 SQL(MyBatis)、バックエンド(java)、フロントエンド(HTML, CSS)、IODBDOC(帳票ツール)、の開発・修正を担当していました。 1人で調査・修正・テスト仕様書作成・単体テストまで行い、内容によってはテーブルを修正することもあり、テーブルの設計からカラム修正・追加、新規テーブルの作成なども行っていました。 新規テーブルの追加やカラムの修正など、テーブルに修正が入る時は必ず既存のデータに影響がないかを調査し、影響がある場合にはデータパッチを作成しリリース後に問題なく動作するようにしていました。 バグの調査には、IDEのデバッグ機能や、GoogleChromeのディベロッパーツールなどを使用し原因を特定していました。 ・既存ソースのリファクタリング 既存ではグループ会社間で処理を切り替えるソースコードがif文で分岐されており、自分としては今後会社が増えた時に管理大変・テストが大変、ソースが見えにくい。といったマイナス面が多いように感じた。そのためリーダーに、修正案を提示し採用いただいた。案としては、機能単位でStrategyパターンを使用することでマスタテーブルで機能を管理できるようにし、会社が増えてもソースコードを触らないでマスタテーブルのデータを登録・修正するだけで対応できるように修正した。これによりソースコードのテストも要らなくなり使用する会社を増やす時の対応が容易になった。 ・インボイス制度開始による、計算ロジックの追加や、新しい帳票の追加 発注登録時に、担当者が明細の金額を入力することができるため 仕入れ先や税率、外貨（米ドル、台湾ドルなど）、税率（非課税・外税10%・外税8%・内税10%・内税8%・リバースチャージなど）で金額計算が必要でした。 インボイス制度開始に伴いインボイス用の税率計算ロジック(税抜の合計額に税をかける）を新たに追加していました。 計算はJavaScript内でBigDecimalを使用し、明細の金額が入力されたタイミングで計算を行い合計額として画面へ出力していました。 また、インボイス用に新たに帳票が追加されたので、IODBDOC（帳票ツール）を使用して新しい帳票のテンプレートを作成したり、プレビュー機能、帳票作成ジョブなどの追加なども行っていました。 ・画面の修正 発注承認後に内容を修正できる機能（「修正」ボタンで対象項目が活性化、「更新」ボタンでバリデーションチェックから更新）や、 発注書などの帳票を送る「メールアドレス」や「送り先の名前」を入力できる画面に新たに敬称を選択できる機能、 送り先の名前を最大10件まで入力できる機能を追加した画面作成など行いました。 「送り先の名前を最大10件まで入力できる機能」に関しては、入力欄にテキスト入力が完了したタイミングで下部に新しい入力欄を出現、逆にテキストを削除したら下部の入力欄が消えるなど動的な対応を行いました。 「発注承認後に内容を修正できる機能」では更新ボタン押下時にバリデーションチェックのAPIを実行後、結果に応じてDB更新のAPIか、元の値に入力欄を戻すという処理をJSで動作するように修正していました。 ## 工夫した点 通常5名以上のメンバーが同時に開発をしていたのでGitの管理には気を遣っていました。また、自分以外のメンバーがどのような修正をしているかは自動で入ってくる情報ではなかったので、自分で確認して他メンバーのタスク内容も把握することでコンフリクトやデグレが起きないように気をつけていました。 多い時で100ファイル以上を1チケットで修正する時などあり、他メンバーと修正箇所が重なったり、影響が出そうな時（テーブルのカラム修正・追加、同じAPIを使用している箇所など）にはの会話をしながら認識合わせを行いプルリクエストのタイミングでコンフリクトや手戻りが起きないようにしていました。 新規機能追加やテーブル追加など新しく何かが変わる時も、自分から発信を行い自分がどうゆう修正をこれからするのかをあらかじめ伝えておくようにしていました。 ## その他 Gitプルリク時のソースレビューから、基本設計書、詳細設計書の修正・作成、新規参画者のフォロー（システムについての説明や、環境構築のサポート、バグ修正や機能追加のサポートなど）も行っていました。 自分で見つけたバグや・改善余地のある機能などを見つけたときはリーダーに方向しチケットを起票していました。 そのため、自分で起票したチケットはレビュアーとして他メンバーが修正した時に確認などを行なっていました。 ソースレビューは、他機能への影響がないか、改善がちゃんとされるか、不要な処理・無駄な結合がないか、今後見たときに理解できるようなコードを書けているか（変数名、関数名や引数・関数内のコード数、分岐、ループ、コメントの粒度など）、他にも実装できる案はないか、リファクタリングの必要がないかなどを意識して行っていました。

## プロジェクト概要 クレジット会社の売上システム改修（バッチプログラム） クレジットカード売上システムバッチのパフォーマンス向上がメイン目標であり、 バッチ処理の処理時間を短縮させ、改善率200%を目指していました。 日本語のJava、独自のFW(Venus)、IDEはなくサクラエディタで実装という少し変わった現場でした。 改善率200%以外にも、独自FWを使用している箇所を普通のJavaの処理で行うような修正なども行っていました。 バッチはJP1で管理されていました。 チームメンバー：6名(内プロパー2名) ## 担当 バックエンドのメンバーとしてプロジェクトに入り、 基本設計書・詳細設計書の作成・実装・単体テスト・結合テストを担当しました。 ## 使用技術 java, 独自FW(Venus), Oracle, Git, Linux, Jenkins, jUnit, shell ## 取り組み ・既存ソースから基本設計書、詳細設計書を作成 既存の設計書が間違っていたり、そもそもなかったりしていたので改修対象のバッチプログラムを元に基本設計書、詳細設計書を作成していました。（サクラエディタを使用して既存ソースは確認していたので動作できなかった） ・リファクタリングした設計書を作成 上記で作成した基本設計書、詳細設計書をもとに、リファクタリング案を考え新たに基本設計書、詳細設計書を作成しました。 主にリファクタリング時に気をつけていたことは、下記になります。 　→ 不要なDBアクセス箇所の削除（無駄な結合なども） 　→ 関数の細分化（一つの関数で複数のことを同時にしていたり、関数の中身だけで2000行あるなど読みにくい関数を簡略化） 　→ 条件分岐の見直し（ベタ書きで加盟店番号などの業務コードが書かれており、すでに廃止されているものなどが多かった） 　→ ループ条件の見直し（本当に必要な処理なのか確認して不要なら削除したら、ループ条件を見直して少ないループで済むようにしたり、while文が多用されていたのでfor文にしてわかりやすいようにしたりなど） 　→ 独自FW使用箇所の見直し　など ・改善率:約40000%を達成 バッチの処理時間短縮で改善率200%を目標としていたが、 本日の売上の中から対象の加盟店番号の売上を検索し、ファイル出力するバッチで改善率約40000%を達成。 既存の処理では線形探索で検索していた箇所を二分探索にアルゴリズムを変更し、不要なDBアクセスの削除、ループ処理の最適化などを行なった結果、実行時間が1時間以上かかっていたバッチを処理時間1分以内で処理できるようにリファクタリングすることができました。 ## 工夫した点 ローカル環境でバッチを動かすことができなかったので、現行処理の動きを正しく理解できるように、置換機能を利用して変数の中身を追ったり、エクセルを使用して実際にどんなデータが来たらどう処理されるのかなどを細かく確認していました。 初めての現場ということもあり、チームメンバーとのコミュニケーションを意識して疑問点は自分の中で持ちすぎないようにしていました。 独自FWを使用していたので、有識者に相談したり、独自FWのドキュメントを確認し書き方や、何ができるのか、何がいけないのかを理解できるようにしていました。

## プロジェクト概要 現在参画中の案件で、クレジットカード決済システムのバッチを改修する案件です。 外部システムへ連携するときに必要なデータを保持しておくDBの追加や、 売上額・返金額の算出計算ロジック追加、外部システム連携IFの追加に伴った既存バッチへの修正などを行っています。 SAP連携を行なっていくにあたり必要なデータやIFが追加されたため、それに伴って現行の設計書修正から実装、単体テスト、内部結合テストまでを行なっています。 設計書は基本設計、詳細設計と分かれているわけではないため基本設計と詳細設計の中間くらいの粒度の内容になっています。 ソースコード設計書は、SVNで管理されており、TortoiseSVNを利用しています。 IDEにはEclipseを利用し、DBのツールとしてA5Mk2、チャットツールはSlackなどを利用してます。 FWにはSeasar2、独自FWのcrepasというものを使用しています。 単体テストケースはJUnitで作成しています。テストデータはExcelで用意しておくことでJUnit実行時にテストデータ読み込みをしてくれるSeasar2の機能を利用して用意しています。 チームメンバー：5名(内リーダー1名) ## 担当 バックエンドのメンバーとしてプロジェクトに入り、 基本設計書・詳細設計書の作成・実装・単体テスト・内部結合テストを担当しています。 ## 使用技術 java8, 独自FW(crepas), Seasar2, Oracle, TortoiseSVN, Linux, Jenkins, jUnit ## 取り組み ・設計書修正 今回対応により追加された、チェック条件や、新規テーブルへのデータ登録などの内容を既存の設計書に追記しています。 ・バッチ実装 上記で作成した設計書を元に、既存ソースに実装を行っています。 インボイス適用前の返金額計算・インボイス適用後の返金額計算などの 金額計算ロジックも実装しているので、計算に誤りがないように認識の確認などしています。 ・単体テスト仕様書、テストケース・テストデータ作成 既存のテスト仕様書へ、今回追加した実装に対してのテストケースを追記し、 仕様書をもとに、jUnitでテストケースを作成しています。 テストデータはテストケース毎にExcelで管理しており、テーブル単位でデータを作成しています。 ## 工夫した点 業界特有の言葉（債権、与信など）がどうゆう意味を持っているのかドキュメントを確認したり、有識者に確認をとって 認識齟齬がないようにしています。 まだ参画して日が浅く、自分以外のメンバーは早くから参画していたこともあり、設計書についてや業務の言葉について自分で調べた後（Slackのチャットを遡ったり、要件定義や設計書などのドキュメントを確認したりして）メンバーに認識が合っているか確認を行うようにして間違った認識で物事を進めないようにしています。