茜 渡邉

課題 ー 以下のような課題点があり、このプロジェクトに至った。 会員数約400万人、職員約100名強が在籍する一般社団法人が存在する。 某団体は、会員情報の管理、出版した本の販売などの事務作業を手作業で行っていた。 職員の業務効率改善のため、業務をシステム化したいとのご要望があった。 プロジェクトの第4フェーズからプログラマーとして参加。 第4フェーズでは主に書籍購入のためのECサイト機能、会費支払機能を追加。 会員向けの機能では、ECサイト、会費支払機能を追加。 職員向けの機能では、注文管理機能、支払状況確認機能を追加。 現在はプロジェクトは終了している。 取り組み プロジェクトの中では主に以下の開発業務に取り組んだ。 ①定期購読決済バッチ 定期購読決済バッチの詳細設計、開発、テストを担当 【課題】 毎月会員に向けて販売される定期刊行物が存在する。 定期刊行物の受注、支払管理、発送管理をシステムで自動で行いたいとのご要望があったため、定期購読処理に関連するバッチを実装した。 【取り組み】 定期購読決済バッチ機能では、C#、SQLを用いてDBから決済対象データを抽出し、受注データを作成、APIを用いて決済を外部システムに要求する開発を行った。 ②画面のレイアウト修正、新規検索画面の作成 詳細設計、開発、テストを担当 【課題】 画面レイアウトを修正したいとのご要望があった。 システムからバッチの実行結果を確認したいとのご要望があった。 【取り組み】 レイアウト修正では、React、JavaScriptを用いてレイアウトを修正した。 管理者がシステムからバッチの実行結果を確認できるようにするために、新規検索画面を作成した。 ブラウザから入力された検索条件をサーバー側に飛ばし、C#、SQLにてデータを取得、取得結果をブラウザに返し、React、JavaScriptを用いて表示した。 ③会費領収書作成バッチ機能 詳細設計、開発、テストを担当 【課題】 従来は紙で発行していた会費領収書をPDFで会員管理システムから出力、確認できる機能がほしいとのご要望があった。 【取り組み】 ご要望に対応するため、領収書作成バッチ機能を実装した。 従来の領収書のレイアウトに合わせてhtml、cssで領収書PDFを設計、作成した。 C#、SQLを用いて領収書発行対象データをDBから取得し、作成したPDFをAzureのCloudにアップロードする一連の機能の詳細設計、開発、テストを担当した。 会員管理システムからAzure上の領収書をダウンロードする機能を開発した。 ④結合テスト 結合テストを担当 【課題】 リリース前に結合テストを実施する必要があった。 【取り組み】 上司が作成したテスト仕様書をもとに結合テスト業務を担当した。 ⑤リリース後の運用、保守業務 不具合の修正、追加のご要望に対する詳細設計、開発、テストを担当 【課題】 システム稼働後、ユーザー様からシステムの不具合や追加のご要望が寄せられる。 【取り組み】 不具合の原因はログを確認して特定、コードを修正した。 追加のご要望にそって、詳細設計、開発、テストを行い、追加機能を実装した。 プロジェクト内では、開発からテストまで一週間以内で完了する小規模な機能開発を担当している。 工夫した点 上司との認識の不一致による手戻りをなくすために、開発機能について疑問が生じたときは必ず確認するように心がけた。 より良い改修方法や、ユーザビリティを意識したさい、追加すべきと考えられる機能を発案し、採用された。 ユーザー様からログイン画面にて、エラーが生じるとご連絡があった。 原因は、ログインIDは数字のみで構成されるにも関わらず、文字列が入力可能となっていたことだった。 ログイン履歴をDBに保存する処理で、ログイン履歴を記録するテーブルのログインIDカラムはint型であり、varchar型を登録しようとしたときにエラーが生じた。 上司からはテーブルのカラムの型をstring型に変更する指示を受けたが、DBに入力間違いのIDを記録する必要はなく、DBへの登録処理の前に、コードで入力された値をチェックし、数字に変換できない文字列の場合は、ユーザーに数字で入力するようにメッセージを出力する方が既存のシステムへの影響が少ないと考えたため、上司に提案した。 提案した結果、採用された。 提案した方法で、すでに稼働しているシステムに大きな変更を加えることなく、問題を解決することができた。 後の改修が容易になるように、開発するときはコードを共通化を意識した。 自分の担当外の他のエラーを発見した場合は、他プログラマーとの競合を避けるため、予想外の影響が生じることを防ぐため、上司に修正の可否を確認してから修正をしている。

# 課題 ー 以下のような課題点があり、このプロジェクトに至った。 大手商社が利用する基幹システムがある。 基幹システムには貿易で生じる商取引の管理、在庫管理などの機能がある。 日々、ユーザー様から基幹システム保守チームに、システムの改善、不具合に対するご要望が寄せられる。 ユーザー様からのご要望の例としては、検索項目の追加、出力される帳票のレイアウト変更、入力データが反映されない不具合の原因究明などが上げられる。 # 取り組み 保守業務では詳細設計の作成、開発、テスト、リリース業務を担当した。 プロジェクトの中では主に以下の保守業務に取り組んだ。 ①既存画面への検索条件、検索結果項目追加 詳細設計、開発、テストを担当 【課題】 ユーザー様から、既存画面への検索条件、検索結果項目追加したいとのご要望があった。 【取り組み】 検索条件の追加では、アプリケーションデザイナ(統合開発環境)を用いて、ドラッグアンドドロップで画面に表示する検索項目を追加した。 検索条件の追加に伴い、既存のコード、SQLを修正する必要があった。 PeopleCode、SQLを用いて既存のコードを修正、DBから条件に該当するデータを取得、画面に表示されるようにした。 アプリケーションデザイナとは、PeopleSoft用の統合開発環境であり、既存のフレームワークを用いて、ドラッグアンドドロップで画面を作成することができる。 ドラッグアンドドロップで画面を作成できる点では、WordPressに近いイメージ。 画面に表示されるページ、検索ボタンなどの画面を構成する個々の部品ごとに、PeopleCodeでコードを記載することで、ページ遷移、ボタンを押下するなど画面へのアクションに対して、実行される処理を決めることができる。 ②帳票のレイアウト修正 詳細設計、開発、テストを担当。 【課題】 ユーザー様から、既存の帳票に表示する項目を追加し、レイアウトを修正したいとのご要望があった。 【取り組み】 ご要望に対応するため、SQR(PeopleToolsで使用される帳票作成用言語)を用いて出力帳票のレイアウト修正を行った。 SQLを用いた帳票の作成のイメージとして、HTMLを用いて画面を作成する作業が挙げられる。 開発が完了した後は、テスト仕様書を作成しテストを実施した。 テストが完了した後は、上司にレビューを受け、本番環境にリリースした。 工夫した点 テスト仕様書の作成では、テスト仕様書の承認者の手間を減らすため、第三者が見て一目で要点、改修内容を理解できる資料作りを心がけた。 具体的には、テスト確認項目に番号を振り、エビデンスの改修箇所に対応させ、吹き出し、枠線、字体を太字にして改修箇所を強調させた。 上司に資料が見やすいと評価をいただいた。 帳票のレイアウト修正業務にて、同様の修正を6つの帳票に対して行う課題があった。 当初は一つずつ作業する予定であったが、共通コードを一つ作成することで解決できることに気がつき、上司に提案した。 提案は採用され、工数を1/6に減らすことができた。