ID:84535さん

＃プロジェクト経験概要 自社の卸売業者向け流通情報管理パッケージのサブシステムとして、営業担当者等がPC・スマートフォンから商品、在庫、取引、単価、リベート、得意先、売上、支払情報等を検索・確認するWebシステムを開発しました。 3名体制の開発でリーダーを担当し、自身も商品検索・得意先検索を中心とした主要機能の設計・実装を行いながら、開発スケジュール・進捗管理、タスク分解・割り振り、発注元部署との仕様調整、打ち合わせの進行など、開発全体の取りまとめを担当しました。 ＃チーム情報 ・体制：3名 ・役割：リーダー ・マネジメント規模：2名 メンバーへのタスク割り振りでは、原則として3日程度までで完了できる粒度にタスクを分解しました。 また、類似機能については同じ担当者が継続して実装した方が既存実装を横展開しやすいため、機能間の関連性や担当の連続性も考慮して割り振りを行いました。 進捗が遅れた場合は、後続タスクで期間を短縮できる箇所やレビュー待ち時間を見直し、全体スケジュールへの影響を抑えるよう調整しました。 進捗・担当タスクはRedmineで管理し、発注元との確認事項や課題については課題管理表を用いてチーム内で共有しました。 ＃画面仕様の具体化・発注元との調整 【概要】 発注元から提示された画面一覧・画面イメージをもとにデモシステムを作成し、実際の画面を確認してもらいながら詳細仕様を具体化しました。 【課題・問題点】 初期資料には検索条件や表示項目などの大枠は記載されていましたが、Webシステムとして実装するために必要となる詳細な画面挙動までは決まっていませんでした。 特に、 ・画面遷移や戻る操作 ・検索条件の保持 ・スクロール方法 ・数値の端数表示 ・項目の配置や表示位置 ・パンくずリスト ・単価等の具体的な表示方法 などについて、発注元と認識を合わせながら仕様を決定する必要がありました。 【対応等】 まず提示された画面イメージをもとにデモ画面を作成し、レビューを通じて追加の表示項目や細かな操作要件を確認しました。 Webシステム上での一般的な実装方法や、それぞれの案にした場合の見え方・操作性を説明したうえで選択肢を提示し、発注元と相談しながら仕様を具体化しました。 業務固有の単価計算や用語については、その都度発注元へ確認し、画面・機能設計へ反映しました。 ＃検索機能・データ構造の設計 【概要】 商品検索・商品詳細、得意先検索・得意先詳細を中心に、在庫、取引、単価、リベート、売上、支払等の関連情報を検索・表示する機能を設計・実装しました。 【課題・問題点】 画面に表示するデータは、メインシステム側から連携されるViewを利用する構成となっていました。 発注元からViewテーブル定義書が提示されていましたが、実際の画面要件と照合すると必要な情報が不足している箇所や、データ間の関連性を確認する必要がある箇所がありました。 また、Viewの処理負荷も考慮する必要があり、必要以上の情報を連携しないようデータ構成を確認する必要がありました。 【対応等】 Viewテーブル定義書をもとに物理名を整理し、各画面で必要となる表示項目・検索条件と照合しました。 その中で、 ・画面表示に必要だが定義上不足している情報 ・既存データとのリレーションを利用できる箇所 ・別経路で取得可能なためViewに保持する必要性が低い項目 などを洗い出し、発注元と確認・調整しました。 画面要件とデータ構造を突き合わせながら、必要な情報を過不足なく取得できる構成になるよう設計を進めました。 ＃主要機能の設計・実装 【概要】 主に以下の機能について、機能設計・画面設計からバックエンド、フロントエンド、SQL、テストまで担当しました。 ・商品検索・商品詳細 ・商品を起点とした在庫・取引・単価情報の検索 ・商品に紐づくリベート情報の検索 ・得意先検索・得意先詳細 ・得意先に紐づく取引・売上・支払情報等の検索 ・各画面の表示制御、入力チェック Java／Spring Bootによるバックエンド実装、HTML／CSS／JavaScript／jQueryによる画面実装を行い、検索条件、表示制御、バリデーション、検索SQL等を含む画面単位の設計書もMarkdown形式で作成しました。 また、バッチ処理については機能設計および設計書作成を担当しました。 ＃開発管理・品質確保 【概要】 自身も主要機能を実装しながら、3名体制の開発進行と品質管理を担当しました。 【対応等】 メンバーの実装完了時にはソースコードを確認し、開発途中にはリファクタリングを行う期間も設けて、機能実装だけでなくコード全体を見直す時間を確保しました。 画面については、開発途中から発注元部署等が確認できる開発環境を用意し、完成後にまとめて確認するのではなく、実装途中から継続的にフィードバックを得られるようにしました。 試験仕様書についても内容を確認し、開発・試験を並行して進めながら品質を確認しました。 ＃GitHub Copilotを活用した開発効率化 【概要】 GitHub Copilotを、デモ画面の作成、類似機能の横展開、コード確認、リファクタリングなどに活用しました。 【工夫した点】 既存コードだけを参照させた場合、実装意図や設計方針の解釈にばらつきが出ることがあったため、設計書や開発規約をMarkdown形式で整理し、システムとしてどのような考え方で設計・実装しているかを参照できるようにしました。 これにより、単に既存コードを模倣させるのではなく、設計方針を踏まえた形で類似画面の横展開やリファクタリングを行いやすくしました。 ＃性能確認 【概要】 開発・試験完了後、本番利用時に想定されるデータ量を用いた性能確認を実施しました。 【対応等】 取引規模が最大級の顧客を基準として想定データ量を確認し、マルチテナント構成上に検証用の顧客スキーマを作成しました。 その環境で実際に検索や画面遷移を行い、大規模データを保持した状態でも実用上問題のない応答となるかを確認しました。 ＃その他の担当内容 ・機能設計、画面設計 ・ER図、テーブル定義の作成 ・テスト仕様書の作成、テスト実施 ・バッチ機能設計書の作成 ・Redmineを用いた進捗管理 ・タスク分解、担当者への割り振り ・打ち合わせの進行、資料作成 ・発注元部署との仕様確認、追加要望への対応 ・GitHub Copilotを利用したコード確認、リファクタリング ＃成果 主要機能の設計・開発・試験を完了し、実運用で想定される大規模な顧客データを用いた性能確認まで実施しました。 その後、発注元部署による受入試験を完了し、Web検索システムの初期版として納品しました。

＃プロジェクト経験概要 自社パッケージである大学向け業績管理システムのVersion 2開発に、開発メンバーとして途中参画しました。 Version 2では、従来は画面ごとに個別カスタマイズしていた入力ページについて、項目定義をもとに汎用的に生成・設定できる構成への変更が進められていました。 参画時点では画面や主要機能の大枠は作られており、既存仕様の調査、新規機能開発、既存機能の改修、バグ修正、レスポンシブ対応、外部ライブラリを利用した機能拡張などを担当しました。 ＃チーム情報 ・体制：4～5名 ・役割：SE ・PL：1名 ・開発リーダー：1名 ・開発メンバー：2～3名 実装した機能については、ほぼ毎日PL・開発リーダーと画面動作を確認し、フィードバックを反映しながら開発を進めました。 ＃既存仕様の調査・影響範囲確認 【概要】 詳細な仕様書が整備されていない既存システムについて、現行画面、ソースコード、DBを確認しながら仕様を把握し、担当する改修や新規開発の影響範囲を調査しました。 【課題・問題点】 Version 2側には既存システムをもとにした画面や主要機能の大枠が作られていましたが、画面上の動作だけでは、 ・フロントエンド側で行われている表示制御 ・バックエンド側のバリデーション ・その他の内部的な制御 などを把握できないため、既存ソースから仕様を確認する必要がありました。 また、DBへのカラム追加や区分追加などの改修では、その変更が既存機能のどこまで影響するかを確認する必要がありました。 【対応等】 まず現行画面で実際の動作を確認し、そのうえで関連するソースコードやDBを調査しました。 影響範囲調査では、対象となるカラム名や区分名、関連する文言などでコード検索して対象箇所の当たりを付け、既存の類似項目がある場合はその実装を追跡しました。 完全な新規項目の場合は、画面を起点として関連処理を確認しながら改修箇所を特定しました。 既存システムの導入・カスタマイズに関する業務仕様など、ソースだけでは判断できない部分についてはPLへ確認しながら進めました。 ＃相関項目設定機能の設計・実装 【概要】 入力内容に応じて、別の入力項目の表示／非表示や必須／任意を切り替えるルールを設定できる機能を新規開発しました。 例えば「海外講演を選択した場合のみ国名入力欄を表示する」といった項目間の依存関係を、画面ごとの個別実装ではなく設定情報として管理できるようにする機能です。 画面構成、データ構造、バックエンド処理、JavaScriptによる動的制御、バリデーションまで担当しました。 【課題・問題点】 Version 2では、従来は画面ごとに個別実装していた入力項目を、利用者側でも設定・追加できるよう汎用化する方針がありました。 そのため、これまで各HTMLやController内に個別実装できていた項目間の依存関係についても、設定情報として登録し、生成された各入力画面へ汎用的に反映できる仕組みが必要でした。 また、フロントエンド上で表示・必須制御を行うだけでは、画面側の不具合や通信状況などによって正しい制御が行われなかった場合に、不正なデータが登録される可能性がありました。 【対応等】 相関条件のデータ構造を自身で設計し、各大項目に対して最大100件の条件を設定できる構成としました。 相関条件には主に、 ・条件判定元となる入力項目 ・条件によって影響を受ける入力項目 ・表示／非表示に関する設定 ・必須／任意に関する設定 ・数値の範囲、以下などの条件区分 ・判定基準となる値 を持たせ、各入力項目のIDを利用して項目間の関係を定義しました。 入力画面表示時には登録済みの相関ルールを取得し、各項目に必要な情報を持たせたうえでJavaScriptから入力値の変化を監視し、条件に応じて表示／非表示、必須／任意を動的に切り替える処理を実装しました。 また、登録時にはバックエンド側でも相関ルールを取得し、入力内容が設定された条件を満たしているか再検証しました。 相関ルール自体の登録についても、フロントエンドでの基本的な入力チェックに加え、バックエンド側で不正値、ルール間の矛盾、重複などを検証しました。 ＃レスポンシブ対応 【概要】 PC向けに作られていた各画面について、スマートフォンでも必要な情報を確認し、操作できるようレスポンシブ対応を行いました。 【課題・問題点】 PC画面のレイアウトをそのまま縮小するだけでは、テーブルの横幅が収まらない、操作ボタンが画面下部へ移動して使いづらくなるなどの問題がありました。 また、単純に情報を非表示にすると業務上必要な情報まで確認できなくなるため、各画面で必要な情報を残しながら、スマートフォン上での表示方法を検討する必要がありました。 【対応等】 表示方法に一意の正解がないため、PL・開発リーダーへ確認する前に複数の表示案を作成し、実画面を比較しながら仕様を決めました。 具体的には、 ・テーブルをスマートフォン表示時に横スクロール可能に変更 ・必要な列を固定表示 ・ボタンサイズや配置の変更 ・PC向けの長いボタン文言をスマートフォン向けに短縮 ・画面下部までスクロールしないと操作できないボタンを、上部や画面右下などへ配置 といった対応を行いました。 また、画面ごとに個別対応するだけではなく、項目ごとに「スマートフォンで表示するか」「表示する場合の幅をどうするか」といった情報をDB側で設定できるようにする方針を、レビューの中でチームとして決定しました。 スマートフォン向けの短縮ボタン文言については、自身でレスポンシブ用の文言をメッセージプロパティへ追加して対応しました。 ＃リッチテキスト機能の拡張 【概要】 Quillを利用したリッチテキスト入力機能について、実運用上の追加要件に対応するための調査・機能拡張を担当しました。 【課題・問題点】 リッチテキスト機能の中でも特にテーブル機能について、既存のQuillおよび利用可能な拡張機能だけでは、実運用上必要となった機能をそのまま満たせない部分がありました。 【対応等】 既存機能や利用可能な拡張方法を調査し、不足する部分について追加実装を行いました。 対応した要件には、 ・テーブル罫線 ・セル内テキスト装飾 ・プレーンテキスト貼り付け などがあります。 ＃その他の担当内容 上記以外にも、担当タスクに応じて以下を実施しました。 ・DB定義変更に伴う既存機能の影響範囲調査・改修 ・バグ修正、軽微な機能追加 ・Controller、Criteria、API、Form、Service、Mapper、SQL等の追加・改修 ・必要に応じたModel等の処理用クラス作成 ・独自バリデーション、アノテーションの実装 ・HTML／CSS／JavaScript／jQueryによる画面開発 ・外部ライブラリの調査・機能拡張 ・PL・開発リーダーとのレビューを踏まえた機能・UI改善 ＃成果 自身が案件を離れる時点では、主要機能の開発が進み、社外の営業担当者向けにVersion 2の機能・画面を説明できる状態まで到達していました。 その後は、細かな不具合修正やテストを進める段階となり、自身は別案件へ移りました。

＃プロジェクト経験概要 カタログやチラシのページ構成、レイアウト、掲載情報等を管理する既存システムのバックエンドマイグレーションに参画しました。 移行要件として決まっていたJava 8、Oracle Database 19cへの更新を起点に、既存システムの構成や依存関係を調査し、Spring、iBatis、ライブラリ管理方式などを含めた移行方針の検討・実施を担当しました。 開発環境構築、非互換調査、ソースコード修正、依存関係整理、実行環境設定、単体試験仕様書の作成まで、技術作業を主担当として進めました。 ＃チーム情報 ・体制：3名 ・役割：SE ・PM：1名 ・PL：1名 Java 8、Oracle Database 19cへの移行以外の技術的な移行方針については、自身で調査・検討したうえでPM・PLへ共有し、方針を決定しながら進めました。 ＃マイグレーション方針の検討・実施 【概要】 Java 6からJava 8、Oracle Database 11gから19cへの移行を前提として、既存のSpring 3、iBatis、各種ライブラリ等をどのような構成へ移行するか調査・検討しました。 【課題・問題点】 JavaやOracleだけを更新しても、既存のフレームワークやライブラリをそのまま利用できない箇所があり、単純なバージョン変更ではシステムを動作させることができませんでした。 また、既存機能の中には新しい環境では利用できなくなったものもあり、個別に代替方法を検討する必要がありました。 【対応等】 まずJava 8へ更新し、発生したビルドエラーや依存関係の問題を確認しながら、必要となる技術要素を段階的に見直しました。 調査結果を踏まえ、 ・Spring 3からSpring 5への移行 ・iBatisからMyBatisへの移行 ・Mavenの導入 ・XMLベースのController設定からアノテーションベースへの移行 などの方針を決定しました。 Mavenについては移行上の必須要件ではありませんでしたが、今回のマイグレーションで複数ライブラリの依存関係を調整する必要があることに加え、今後の保守性も考慮し、導入コストや影響とのバランスを踏まえて採用しました。 ＃非互換への対応 【概要】 フレームワークやライブラリの更新によって利用できなくなった既存機能について、代替方法を調査・実装しました。 【課題・問題点】 廃止された機能の中には比較的小さな修正で置き換えられるものもあれば、既存構成のまま無理に対応すると影響範囲が広くなったり、今後の保守性に課題が残るものもありました。 また、iBatisからMyBatisへの移行ではSQL定義全体に修正が発生するため、単純な一括置換だけではなく、変換後の動作を確認する必要がありました。 【対応等】 比較的影響の小さい機能については、既存ライブラリの実装内容も確認しながら代替処理を実装しました。 一方、影響範囲が広いものについては、短期的な修正量だけでなく移行リスクや今後の保守性も考慮し、より標準的な方式への移行を選択しました。 その一例として、既存のXMLベースのController設定については、一部のみを残して対応するのではなく、アノテーションベースの構成へ移行しました。 iBatisからMyBatisへの移行では、SQL定義ファイルに必要となる修正を行い、変更内容についてテストコードを作成しながら動作を確認しました。 その他、Spring 5で利用できなくなった機能やライブラリについても、必要に応じて検証用コードを作成し、移行可否や代替方法を確認しました。 ＃バックエンド単体試験仕様書の作成 【概要】 バックエンド向けの既存単体試験仕様書が存在しなかったため、既存のフロントエンド試験仕様書を起点として、バックエンドの処理を網羅する試験項目を作成しました。 【課題・問題点】 当初は既存のフロントエンド試験仕様書をもとに単体試験項目を作成する方針でしたが、それだけではバックエンド内部の処理や分岐、エラー処理を十分に確認できないという課題がありました。 そのため、既存資料を利用しながら、バックエンドとしてどこまで確認すべきかを整理し、試験項目の作成方法自体を検討する必要がありました。 【対応等】 既存のフロントエンド試験仕様書から画面イベントを抽出し、各イベントから呼び出されるAPIを特定しました。 そのうえでControllerからService、DAOまで処理を追跡し、 ・API単位での処理確認 ・内部処理の条件分岐 ・エラー処理 などを確認して、フロントエンド側の試験だけでは不足する観点を試験項目へ追加しました。 また、後続で参画するメンバーでも同じ基準で試験項目を作成できるよう、 ・画面イベントからAPIを特定する方法 ・ControllerからService、DAOまで処理を追跡する方法 ・分岐やエラー処理を試験項目へ追加する際の判断基準 ・試験仕様書のテンプレート を整理し、作成方法の標準化を進めました。 ＃成果 Java 8、Oracle Database 19cへの移行を起点として、Spring 5、MyBatis、Maven等を含む新しい構成へ段階的に移行し、ビルドエラー・実行時エラー・各種非互換を解消しながら、主要機能を新環境で動作確認できる状態まで進めました。 また、既存のバックエンド向け試験仕様書がない状態から単体試験項目の作成方法を整理し、後続メンバーへの展開を想定した手順・判断基準・テンプレートの整備を進めました。 後続メンバーへの展開・検証を進めている途中でプロジェクトの契約終了が決定したため、試験作成方法の標準化については整備途中の段階で終了しました。

＃プロジェクト経験概要 Angular 7からAngular 20へのバージョンアップに伴う非互換調査を主担当として実施しました。 別担当者がAngular 20へ更新したソースコードと開発環境を引き継ぎましたが、引き継ぎ時点では複数のビルドエラーが発生し、アプリケーションを起動できない状態でした。 当初はビルドエラーの解消を目的として調査を開始しましたが、調査範囲が段階的に広がり、最終的にはTypeScriptや外部ライブラリの非互換調査、実行時の動作確認、修正方針の検討、対応工数の概算まで担当しました。 ＃チーム情報 ・体制：1～2名 ・役割：主担当 非互換箇所の調査・修正、代替ライブラリの調査、修正方針の検討、対応工数の概算、調査資料の作成を担当しました。 ＃ビルドエラー・非互換調査 【概要】 Angular 20へ更新された既存ソースについて、ビルドエラーを解消しながら、Angular・TypeScript・外部ライブラリのバージョン差異に起因する非互換を調査しました。 【課題・問題点】 Angular 7から20への大幅なバージョンアップであったため、TypeScriptの仕様変更や型チェックの厳格化、利用ライブラリの対応状況など、複数の要因によるエラーが発生していました。 引き継ぎ時点では多数のエラーが同時に発生していたため、個別に対処するのではなく、原因や種類を整理しながら調査を進める必要がありました。 【対応等】 発生しているエラーを内容ごとに分類し、まず件数の多かったTypeScriptの型関連エラーから対応しました。 主要なエラー群を解消した後、残ったエラーを再度分類し、外部ライブラリに起因する問題についてはライブラリ単位でまとめて調査・対応しました。 エラーを一件ずつ順番に修正するのではなく、同種の問題をまとめて整理・対応することで、非互換の全体像を把握しながら調査を進めました。 ＃外部ライブラリの非互換・代替手段の調査 【概要】 Angular 20へのバージョンアップに伴い継続利用できなくなった外部ライブラリについて、後継バージョンや代替手段を調査しました。 【課題・問題点】 既存システムで利用していた複数のライブラリがAngular 20に対応しておらず、ライブラリのバージョン更新だけでは解消できない箇所がありました。 また、見積もり段階での調査であったため、すべての代替候補について詳細な実装・検証まで行うのではなく、本開発時に想定される対応方法と作業規模を判断できる情報を整理する必要がありました。 【対応等】 各ライブラリについて公式ドキュメントや関連する技術情報を確認し、Angular 20に対応した後継バージョンや、同等機能を持つ代替ライブラリの有無を調査しました。 後継・代替手段が確認できたものについては、実際に置き換えを行い、ビルドエラーが解消できることを確認しました。 一方、既存ライブラリから直接移行できる選択肢が確認できないものについては、既存機能を別方式で再実装する必要があるものとして整理し、本開発時の対応方針と工数見積もりへ反映しました。 ＃実行時の非互換調査 【概要】 ビルド成功後はアプリケーションを起動し、実際の画面操作を通じて、ビルド時には検出できない実行時の非互換を調査しました。 【課題・問題点】 コンパイル・ビルドが正常に完了しても、Angularや関連ライブラリの変更によって、既存画面が従来と同じ挙動になるとは限りませんでした。 特に、ドラッグ＆ドロップによって画像を配置する機能では、対象を正常に選択できない、処理タイミングの変化によって期待した操作結果にならないなど、画面操作時に初めて確認できる問題が発生しました。 【対応等】 主要な画面・操作について実際に動作確認を行い、表示やユーザー操作に関する非互換を洗い出しました。 確認した問題については、発生する操作、事象、想定される原因を整理し、必要となる修正内容を検討しました。 ＃修正方針・工数の整理 【概要】 調査した非互換について、原因と修正方針を整理したうえで、後続の見積もりに利用できるよう対応工数を概算しました。 【対応等】 非互換ごとに必要となる対応内容を整理し、 ・同一パターンをまとめて修正可能なもの ・ライブラリの置き換えによって対応可能なもの ・既存機能を別方式で実装する必要があるもの ・実行タイミング等の挙動を確認しながら修正する必要があるもの など、対応の性質に応じて作業量を見積もりました。 調査した非互換について、発生箇所、原因、修正方針、概算工数を一覧化し、エンジニア向けの調査資料および顧客提出用資料として整理しました。 ＃成果 Angular 20への更新後にビルドできない状態だったソースコードについて、TypeScriptや外部ライブラリに起因する非互換を分類・調査し、アプリケーションを起動して画面操作を確認できる状態まで進めました。 さらに、実行時に発生する非互換についても洗い出し、各問題の修正方針と概算工数を整理することで、本開発に向けた影響範囲と対応内容を判断できる資料としてまとめました。 調査結果および修正済みソースコードは、後続工程へ引き継ぎました。

＃プロジェクト経験概要 社内でExcelや共有フォルダを中心に行われていたプロジェクト管理業務のシステム化を目的として、Webアプリケーションのプロトタイプ開発を担当しました。 従来は、プロジェクトの提案段階からExcelで情報を管理し、プロジェクトIDも手動で採番していました。また、部署ごとにRedmineなど利用するツールが異なり、見積情報についてもExcelファイル単位で管理されていたため、情報の検索や履歴管理、入力漏れの把握などがしづらい状態でした。 着手時点で決まっていたのは、こうした管理体制を改善したいという目的とキックオフ資料までで、詳細な要件一覧、画面構成、DB設計などは決まっていませんでした。 ＃チーム情報 ・体制：2名 ・役割：SE ・PM：事業部長 既存のExcelや社内資料を調査して機能・画面・DB構造の叩き台を作成し、PMとほぼ毎日レビューを行いながら仕様と実装を具体化しました。 ＃プロジェクト管理機能の設計・実装 【概要】 プロジェクト登録・進捗管理を中心として、社員・稼働、タスク、見積、日報など、プロジェクトに関連する情報を一つのWebアプリケーション上で管理する機能を開発しました。 【課題・問題点】 詳細な要件や画面構成、DB設計が用意されておらず、既存業務もExcel、共有フォルダ、部署ごとの管理ツールなどに分散していました。 そのため、既存業務で何の情報を管理しているのか、どの情報同士が関連しているのかを整理したうえで、システム上の機能やデータ構造へ落とし込む必要がありました。 【対応等】 既存のプロジェクト管理用Excel、見積資料、勤怠・日報関連資料などを確認し、管理項目や業務ルールを整理しました。 まずプロジェクト登録・進捗管理の大枠を実装し、その後、必要となる画面・機能・テーブルを段階的に追加しました。 画面構成、入力必須項目、モーダルの利用箇所、テーブル構成などについては、自身で案を作成したうえでPMへレビューを依頼し、フィードバックを反映しながら具体化しました。 DBはプロジェクトと社員を中心に設計し、プロジェクトの状況、所属部署、金額、担当社員、社員ごとの担当期間・人月などを管理できる構成としました。 また、日報機能については、リモートワーク時の運用を想定した話から既存の新人向け日報フォーマットを確認し、システム上の機能として実装しました。 ＃既存Excelとの入出力・見積履歴管理 【概要】 既存のExcel運用からWebシステムへ段階的に移行できるよう、 ・システムに登録したプロジェクト情報を既存形式のExcelへ出力 ・既存形式のExcelをアップロードし、システムへ反映 する双方向の連携機能を実装しました。 【課題・問題点】 既存のExcelにはプロジェクトや見積に関するさまざまな情報が含まれており、それらを単純に読み書きするだけではなく、どの情報を同一のデータとして扱うか、どの情報を履歴として保持するかなどを整理する必要がありました。 一方で、最終的にはExcel管理そのものをやめることが目的であり、プロトタイプ開発でもあったため、Excel連携部分をどこまで汎用化するかも検討事項となりました。 【対応等】 既存Excelごとに入力・表示されている情報を洗い出し、それぞれの情報の関係を整理したうえでDB設計へ反映しました。 Excelのセルとシステム上の項目との対応は既存フォーマットを前提として実装しました。共通化・汎用化も検討しましたが、Excel連携は主に移行期間中の利用を想定していたため、実装コストとのバランスから過度な汎用化は行いませんでした。 また、過去の見積Excelそのものを保存するのではなく、業務上必要となる「その時点でどのような見積内容だったか」という情報を履歴用テーブルへ保持する構成としました。 Excel取込時には、必要な情報の不足や形式不正をチェックし、正常に読み取れた場合も即時登録せず、登録予定の内容を画面上で確認してから反映できるようにしました。 ＃売上・目標ダッシュボード 【概要】 部署ごとの年間目標・現在売上や、月別売上を確認できるダッシュボード機能を実装しました。 【課題・背景】 この機能は当初から具体的な要件として提示されていたものではありませんでした。 既存資料を調査する中で、月次の全社会議向けに部署ごとの売上や目標を別途集計していることを把握し、プロジェクトや見積の情報をシステム上で管理するのであれば、同じデータを利用して確認できるようにすると有用だと考えました。 【対応等】 既存資料をもとに必要な表示内容を整理し、 ・部署ごとの年間目標と現在売上の棒グラフによる比較 ・見積・発注情報をもとにした月別売上の集計・表示 を実装しました。 既存業務を調査する中で自身が必要性を見つけ、機能として追加したものです。 ＃その他の担当機能 上記以外にも、以下の機能を担当しました。 ・ユーザー・社員管理 ・タスク・子タスク管理 ・プロジェクトのフェーズに応じた入力内容の切り替え ・社員ごとのプロジェクト稼働情報管理 ・見積情報の登録・管理 ・日報管理 ・画面構成・画面遷移の検討 ・DBテーブル・リレーションの設計 ・動作確認 ・PMレビューを踏まえたUI・機能改善 ＃成果 約半年間の開発で、プロジェクト管理、進捗管理、社員・稼働管理、見積管理、Excel入出力、日報、売上集計、ダッシュボードなどの主要機能が一通り動作する、デモ可能なプロトタイプまで実装しました。 その後、自身が別案件へ参画することになったため、開発をPMへ引き継ぎました。

＃プロジェクト経験概要 出版社が運営する書籍情報・キャンペーン情報等を掲載するWebサイト、物販ECサイト、および社員向けEC管理サイトの保守・運用を担当しました。 2025年10月～2026年3月は主担当、2026年4月～7月は必要時のバックアップとして対応し、2026年8月以降は前任者の離任に伴い、PMと相談しながら実作業を基本的に単独で担当しています。 日常的な問い合わせ・障害調査、軽微な改修、データ更新、サーバー設定確認から、定期・臨時リリースまで幅広く対応しています。 ＃チーム情報 ・体制：2名 ・役割：SE PMと連携しながら、調査・改修・検証・リリース等の実作業を担当しています。 ＃障害・エラー発生時の調査対応 【概要】 エラー通知やシステム上の不具合が発生した際に、ログ、DB、ソースコード、サーバー設定等を確認し、影響範囲の把握から原因調査、修正まで対応しました。 【対応例】 外部の流通システムとの連携処理でエラーが発生した際には、まず支払処理や配送等の業務への影響有無を確認しました。 その後、アプリケーションログや処理履歴を調査したところ、特定日のバッチ処理が長時間継続した後に通信が遮断されていることを確認しました。 当初は連携先システム側の障害も想定し、外部システム側へ発生時間帯の状況を確認しましたが、該当時間帯に障害は発生していないことが判明しました。 そこでバッチ処理自体の設計・設定まで調査範囲を広げた結果、wgetのリトライにデフォルト設定が使用されており、失敗時の再試行を十分に考慮した構成になっていないことを確認しました。 リトライ設定を見直すとともに、再発防止の観点から、将来的には処理失敗時のエラー状態やリトライ状況をアプリケーション側で管理できるようにする必要があることも整理しました。 このほかにも、SSHでLinuxサーバーへ接続してログや設定ファイルを確認し、必要に応じてDB・ソースコードまで追跡しながら原因を切り分けています。 ＃改修・リリース対応 【概要】 日々の保守業務の中で確認された軽微な不具合や改善事項を蓄積し、定期的な月次リリースや、必要に応じた臨時リリースを実施しました。 【対応等】 レイアウト崩れや特定条件下で発生する軽微な不具合、バリデーション、文言、CSS等の修正候補を日常的に整理しています。 月次リリースでは、緊急性の低い修正候補の中から、他業務との兼ね合いや修正ボリュームを踏まえて対象を選定し、 ・ソースコード、CSS、設定ファイル等の修正 ・検証環境での動作確認 ・リリース資材の作成 ・本番環境への反映 まで対応しています。 業務影響が大きいものや早急な対応が必要な問題については、月次リリースを待たず、臨時リリースとして対応しました。 ＃その他の担当内容 ・顧客からのシステム利用方法等に関する問い合わせ調査 ・DBデータの確認、更新 ・データ登録、修正、一括登録対応 ・キャンペーンページ等の追加・表示対応 ・wget、cron等のサーバー設定の調査・修正 ・機能追加依頼に対する影響範囲調査、見積もり ・定例会議の議事録作成

＃プロジェクト経験概要 食品配送業者向けのカタログ・チラシ制作支援システムにおいて、PLとして運用保守を担当しています。 一次受け企業からの問い合わせ・障害・改修依頼に対する技術調査、対応方針の検討、改修・リリース対応に加え、外部ベンダー成果物のレビュー、進捗管理、週次定例会の進行などを担当しています。 技術面・進行面については自身で調査・判断したうえで対応方針を整理し、PMへ報告・確認を行いながら案件を進めています。 ＃チーム情報 ・体制：3名 ・役割：PL PMは契約面や最終確認を担当し、自身は技術面・進行面の取りまとめを担当しています。 もう1名のメンバーについては、対応内容に応じて自身から作業を割り振り、進捗を確認しながら進めています。 ＃問い合わせ・障害対応 【概要】 一次受け企業から寄せられる問い合わせや不具合について、事象の確認から原因調査、対応方針の検討、必要に応じた改修・リリースまで担当しています。 【対応等】 不具合発生時には、まず再現条件や影響範囲を確認したうえで、ログ、ソースコード、DB等を調査し、原因を切り分けています。 原因特定後は、 ・即時の対応が必要か ・暫定的な対応で影響を抑えられるか ・恒久的な改修が必要か ・他機能への影響がないか などを整理し、対応方針を検討します。 技術的な方針については基本的に自身で整理し、PMへ状況と判断内容を報告したうえで最終的な対応方針を決定しています。 必要に応じてソースコード修正、試験、リリース手順書の作成、DBパッチの作成・適用、臨時リリース・定期リリースまで対応しています。 ＃改修・カスタマイズ依頼の影響調査・見積もり 【概要】 一次受け企業から改修・カスタマイズ依頼を受けた際に、既存システムへの影響範囲を調査し、修正対象と概算工数を整理しています。 【対応等】 対象となる画面・ソースコード・DBを確認し、必要となる修正箇所を洗い出します。 そのうえで関連機能への影響を確認し、 ・設計、実装に必要な作業 ・試験範囲 ・リリースまでに必要な作業 を整理したうえで概算工数を算出し、一次受け企業へ技術的な説明を行っています。 ＃外部ベンダー成果物のレビュー 【概要】 外部ベンダーが作成した設計書、ソースコード、試験仕様書についてレビューを行っています。 【レビュー観点】 主に以下の観点から確認しています。 ・要件や修正内容に対して抜け漏れがないか ・既存システムの実装方針やコードの書き方に沿っているか ・設計書、試験仕様書の記述に曖昧さがないか ・システムに詳しくない担当者が読んだ場合でも、解釈が分かれず一意に理解できる内容になっているか 既存システムの改修が中心となるため、新規実装として成立しているかだけでなく、既存実装との整合性を重視して確認しています。 ＃進捗・タスク管理 【概要】 WBSや定例会を通じて、担当タスク、課題、障害・改修状況、今後の予定を確認し、開発・保守作業の進行を管理しています。 【対応等】 週次定例会では自身がファシリテーションを行い、タスクの進捗、課題、今後の予定、障害・改修状況を整理しています。 外部ベンダーのWBSについても内容と進捗を確認し、作業が遅れそうな場合にはレビューを早める、自身で一部作業を対応するなど、後続タスクへの影響を抑えるための調整を行っています。 また、週次・月次の業務進捗報告書を作成し、一次受け企業への対応状況の報告や技術説明も担当しています。 ＃その他の担当内容 ・週次定例会のファシリテーション ・週次・月次の業務進捗報告書作成 ・マイナー／メジャーバージョンアップに関する対応 ・ソースコード修正、試験 ・リリース手順書作成 ・定期・臨時リリース ・DBパッチの作成・適用 ・WBSレビュー ・一次受け企業への技術説明、対応状況の報告 ＃現在の担当状況 日々の問い合わせ・改修に対する技術調査や対応方針の検討、外部ベンダー成果物のレビュー、メンバーへの作業割り振り、進捗管理など、運用保守における技術面・進行面の実務を担当しています。