ID:85789さん

【プロジェクト概要】 電力設備の停電を伴う作業計画を調整・最適化する業務システムの開発です。年間5,000件 規模の停電要求を対象に、制約条件を踏まえて作業日程を自動で割り付け、関係部門の承認 までを一つの画面群で扱います。2024年に担当した初期版の後継案件で、前回の経験を 踏まえて再度参画しました。 【チーム情報】 全体20名体制。そのうちフロントエンドの主担当として、自社メンバー2名のチームリーダー を兼ねています。顧客・元請・協力会社との窓口も担当しています。 担当範囲はフロントエンド全般と、画面から呼び出す SQL（PostgreSQL のストアド関数・ ビュー）の作成です。最適化処理本体（Python）とバックエンド基盤は別担当で、画面から その処理を起動し結果を反映する部分までを担当しています。 構成は React / Redux、PostgreSQL（Amazon Aurora）を PostgREST 経由で参照、 ローカル開発環境は Docker Compose、リポジトリは GitLab です。 【開発・実装内容A】停電要求一覧とカレンダーを同一画面で扱う主担当画面 ■どのような機能の開発・実装か 50列前後の停電要求一覧表と、日付軸のカレンダー（作業日・希望日・停止可否をバーで 表示）を1画面に並べ、横スクロールと行の高さを同期させる画面です。年度・地域・支店・ グループでの絞り込み、列ごとの検索、表示項目の利用者別カスタマイズを備えています。 同じ構成で表示対象の件名の範囲だけが異なる画面が4つあり、画面を識別するキーで 切り替える方式にしています。設計から実装・単体試験まで担当しました。 ■課題・問題点 停止可否の判定結果を件名と設備の組み合わせごとに取得する作りで、取得回数が件数に 比例して増え、年間5,000件規模では初期表示と絞り込みが重くなっていました。 また、ブラウザの拡大率を100%未満にすると、テーブル高さの再計算が止まらず レンダリングが停止しない事象が発生していました。 ■打ち手・使用した技術 取得側は、判定結果を全件分まとめて1回で取得する中間結果を関数の先頭に用意し、 以降の処理はそこから絞るだけの形へ変更して、件数に比例する取得を無くしました。 停止しない事象については、高さを測って保持値へ書き戻す処理の依存関係にその保持値 自身が含まれており、測定と更新が互いを呼び戻していたことが原因でした。拡大率が 100%未満では実測値に端数が生じて1px単位で結果が反転し続けるため、依存関係を 見直したうえで、前回値との差が1px以内なら更新しないガードを入れ、監視イベントを 1フレームにつき1回へ制限しました。同じ高さ算出処理が3画面へ複製されていたため、 3画面すべてに同じ修正を適用しています。 （React hooks / ResizeObserver / PostgreSQL） 【開発・実装内容B】最適化処理と画面の間を受け持つPostgreSQL関数群の作成 ■どのような機能の開発・実装か 画面が必要とするデータは件名・設備・グループ・承認・調整結果など複数のスキーマに 分散しており、最適化処理（Python）の出力も別スキーマの結果テーブルへ書き込まれます。 これを画面側で扱いやすい形へ整理する関数11本とビュー2本を作成しました（関数は合計 約2,500行、3スキーマ・24テーブルが対象）。取得系3本と、最適化結果の反映や承認請求 などの更新系8本という構成です。 ■課題・問題点 画面側から複数回 API を呼んで結合すると、同じ結合ロジックが画面ごとに重複し、片方 だけ修正された際に表示が食い違います。また最適化処理の出力は業務テーブルとは別の スキーマにあるため、反映の範囲と順序を画面側に持たせると処理の種類が増えるたびに 画面側が膨らんでいく状態でした。件名の抽出条件についても、表示側と処理側で別々に 書かれていると、画面に出ている件名と処理の対象件名が一致しなくなります。 ■打ち手・使用した技術 取得側は、絞り込み条件・利用者の所属による表示範囲・表示項目の並びまで関数側で解決 し、画面は1回の呼び出しで表示用の形を受け取る構成にしました。抽出条件を関数側に 寄せたことで、表示側と処理側が同じ条件を参照するようになり、両者のずれが構造的に 起きなくなっています。更新側は処理の種類ごとに反映用の関数を分け、結果テーブルから 業務テーブルへの反映を関数側に閉じ込め、画面側は対象の処理を指定するだけでよい形に しました。戻り値は処理成否とデータを含む JSON 形式で全関数共通にし、エラー処理を 1か所へ揃えています。 （PostgreSQL / PL/pgSQL / PostgREST） 【進め方について】 設計書と実際のデータベース定義が食い違っているケースが頻発していました。そのまま 実装すると結合テストの段階で初めて問題が表面化し手戻りが大きくなるため、実装前に 不明点を洗い出し、現状の実装・想定される選択肢・それぞれの影響を整理したうえで顧客 へ確認し、仕様として確定させることを徹底しました。確定した内容はその都度チームへ 共有し、個人の記憶に依存せず参照できる状態を保つようにしています。 【成果】 ・担当画面6画面分の詳細設計書と単体試験仕様書を作成し、設計から単体試験まで一貫して 　担当しました。上記A・Bは調査・方針決定・実装・検証まで担当しています。 ・自社メンバー2名の実装レビューと修正指示も担当し、共通部分の修正方針を揃えています。 ・仕様の確認を前倒しする進め方により、結合テスト段階での大きな手戻りを防げています。

【概要】 鉄道車両を管理し、設定された条件に基づいて運用を行うシステムの開発です。22名体制のプログラマとして参画し、フロントエンドの画面実装を担当しました。表示組・貸借設定、運用編成の登録・照会、仕業（車両運用）登録、基本編成の登録・照会、他システムとの連携画面など、複数の画面を担当しています。 【取り組んだ課題】 車両の編成や運用には鉄道業務固有のルールが多く、画面の項目名だけでは意図が読み取れない部分が多くありました。そのため、設計書の記載だけで判断せず、業務上どのような操作が行われるのかを確認したうえで実装するようにしました。 また、本案件から TypeScript での開発に従事しました。22名という大きな体制で複数人が同じ画面群を触るため、型定義を整備しておくことが認識の齟齬やデグレードを防ぐうえで有効だと感じ、意識して整理しました。 【成果】 担当画面について詳細設計書と単体試験仕様書を作成し、実装から結合テストまで担当しました。本案件で得た TypeScript と大規模体制での開発経験は、その後の案件でも活かしています。

【概要】 停電スケジュールを管理し、複数の候補から最適な日程を算出するシステムの開発です。5名体制のプログラマとして参画し、フロントエンドとバックエンドの双方を担当しました。本案件は予算の都合により一旦終了しましたが、後継案件（2025年〜現在）に再度参画しています。 【取り組んだ課題】 画面側だけでなく、各画面で必要となるデータを返す API も自分で作成したため、画面の要件から必要なデータ構造を逆算して設計する進め方を経験しました。 また、最適化処理が Python の外部プログラムとして用意されていたため、画面側からそれを実行し、完了を待って結果を反映するロジックを実装しました。Web アプリケーションから外部プロセスを起動する構成は初めてで、起動のタイミングや完了の判定方法を整理しながら進めました。 【成果】 フロントエンドとバックエンドを一人で担当したことで、画面と API の責務の分け方を考える機会になりました。ここで扱った外部プログラム実行の構成は、後継案件で同様の仕組みをより大きな規模で扱う際の下地になっています。