ID:84944さん

・サービス概要 　複雑なSQLを分解し中間テーブルを可視化する学習支援ツール 　 ・背景・課題認識（なぜ作ったか） 　実務で複数テーブルがJOIN・サブクエリで絡み合うSQLは、若手にとって 　「最終結果は見えても途中経過が見えない」ため理解が難しい。 　指導員が口頭で中間状態を解説する工数もかさむ。 　この「途中の中間テーブルが見えない」ことが学習のボトルネックだと考え、 　各処理段階のテーブルを可視化すれば自習で処理過程を追えるようになると判断し、 　開発に着手した。 ・実装機能①：ユーザーがアップロードした解析対象ファイルを保持する 　・課題１ 　　重いCSVファイルをアップロードした時に、レスポンが返ってこなかった 　　原因は、DBセッションを1つだけ作って全リクエストで使い回していたこと。 　　複数リクエストが同じセッションを同時に触るため、並行アクセスを想定していない 　　セッションで競合が発生していた。 　・打ち手１ 　　リクエストごとに独立したDBセッションを生成し、処理後に破棄する構成に変更 　　これで各リクエストが自分専用のセッションを持ち、セッションの共有による競合が 　　解消され、レスポンスが返るようになった。 　・課題２ 　　当初、アップロードファイルの解析用DuckDBをユーザーごとに分離しておらず、 　　他ユーザーがアップロードしたデータにアクセスできてしまうリスクがあった。 　・打ち手２ 　　DuckDBファイルをユーザーごとにフォルダを分離し、各ユーザーが自分の 　　フォルダ配下のデータにしかアクセスできない構成とすることで、 　　他ユーザーのデータへのアクセスを構造的に遮断した。 　　 ・実装機能②：SQLを解析し、サブクエリ単位に分解、各段階の中間テーブルを表示する 　・課題 　　自前パースをしてSQL解析をすると、ネストしたサブクエリや方言差で破綻する。 　　なので方言ごとに、構文構造を解析するロジックを実装しなければいけない。 　・打ち手・使用した技術 　　自前パースを避け、SQLパーサ sqlglot を採用し構文木（AST）ベースで分解。 　　これにより、構文の階層構造を正確に扱え、方言対応やメンテナンス性でも優位と 　　判断した。 ・実装機能③：中間テーブルのレコードプレビュー表示 　・課題 　　中間テーブルの件数が多い場合に全レコードを取得・描画すると、データ取得と 　　画面描画の負荷が大きく、表示が重く描画までに時間がかかった。 　・打ち手 　　学習用途としては全件を見せる必要はなく、処理過程を確認できれば十分であると 　　判断し、表示件数に上限1000件を設けた。 　　これにより取得・描画コストを抑え、描画までの待ち時間を数秒程度に短縮した。　 　 ・できること 　本サービスはSQLをサブクエリ単位に分解し、JOINやサブクエリが絡むクエリを 　サブクエリ単位のブロックに分解し、各段階の中間テーブルをプレビュー表示する 　ことで、処理過程を段階的に追える。 ・本番稼働URL 　https://querylensapp.com

・プロジェクト概要 　従来は保証プランが1種類（50%固定）に限定されていた。 　機能拡張後はユーザーのニーズに合わせて複数のプラン（50%、80%など）から 　保証プランを選択できるようにプロジェクト推進中である。 　この機能拡張により、上位プラン（80%等）が選択されることで、 　1件あたりの保証料収入の増加を見込める。 　（年間1億円以上の売上増加見込み） ・チーム情報 弊社社員（4名）＋オフショア開発 　 ・担当 　要件定義フェーズから参画し、保証プラン選択に伴う要件整理、保証プラン機能の 　設計、保証委託料の計算仕様の策定、テスト設計までを主担当として実施した。 　テストの実施は自身が作成したテスト設計に基づき後輩に依頼し、成果物の 　レビューを担当した。 ・技術 　PowerShellで保証プラン（50%/80%等）の複数パターンのテストデータを一括生成し、 　SQLでOracleの保証プランマスタへのテーブル定義変更およびテストデータのINSERTを 　実施した。マスタ設計はDB(Oracle)上で行った。 ・課題 　既存システムは保証プラン（50%固定）をハードコーディングしており、 　単一プラン前提の作りになっていた。 　当初の要件でも「保証プランは変わらない」とされていたが、 　プロジェクト途中でプラン内容が変更されることが判明。 　ハードコーディングのままでは、保証プラン変更のたびに 　ソース改修・再テスト・再リリースが必要となり、保守コストと改修リスクが 　高い状態だった。 ・打ち手 　ハードコーディングされた値を単純に複数プラン対応へ書き換える案も検討した 　がそれでは「途中でプランが変わる」という判明した実態に対応できず、 　将来のプラン追加・変更のたびにコード改修が発生する。 　そこで、設計工程において、保証プランをコード上の固定値ではなく、DB(Oracle)上で 　保証プランマスタとしてデータ保持する方針を採用した。 　プランの追加・削除をマスタのレコード操作（登録・削除）で完結させ、 　ソース改修を伴わずに運用側でプラン変更へ対応できる構成とした。 　これにより、当初想定になかった「プランが変わる」要件変更にも改修コストを 　抑えて追従できるようにした。 　（ハードコーディングのままではプラン変更のたびに改修・再テスト・再リリースで 　約0.5人月を要していたが、マスタ操作のみで対応可能となり0人月に削減）

・プロジェクト概要 　従来、法人との新規契約締結は書面郵送による署名・捺印が必要でしたが、 　外部システムと連携して、オンライン上で電子署名が完結する仕組みを構築しました。 　月間約150件の契約締結を電子化し、個人契約と共通のシンプルなフローを適用。 　これにより法人側の押印・郵送負担を解消するとともに、社内のオペレーションコスト 　の最適化を実現しました。 ・チーム情報 　弊社社員（5名）＋オフショア開発 ・技術 　外部電子署名システムのAPI応答をPowerShellで再現するモックを作成し、 　正常系・エラー系の接続テストを自社側で先行実施できるようにした 　 ・担当 　要件定義フェーズから参画し、外部電子署名システムとの連携仕様の要件整理・設計、 　テスト設計、テスト実施までを一貫して主担当として実施した。 ・課題 　本機能は外部電子署名システムとの連携が前提だったが、連携先である外部システム 　側の改修が遅延していた。自社側の開発・テストが外部改修の完了を待つ状態となり、 　スケジュール全体が遅延するリスクが高まっていた。 ・打ち手 　外部改修の完了を待たず着手できるよう、連携部分をモック化して自社側の開発・テスト 　を先行させた。これにより外部側の遅延に開発全体が引きずられることを回避し、 　自社側の作業を予定通り進行させた。

・プロジェクト概要 　従来、更新契約書は書面を郵送することで署名・捺印を得ていましたが、利便性の向上 　とコスト削減のため、電子署名サービス「GMOサイン」を用いた電子契約フローへと 　改修を行いました。月間約400件発生する更新業務を電子化して、郵送費や印紙代の 　削減に加え、書類の発送・回収に伴う事務工数を大幅に削減しました。 　これにより、更新手続き完了までのリードタイム短縮と、社内オペレーションの最適化 　を実現しました。 ・チーム情報 　弊社社員（３名）＋オフショア開発 ・担当 　更新書面の発送から回収までを電子化したフローに対し、契約者がWeb上で 　署名完了できること、社内側で回収状況を追跡できることを確認した ・技術 　テスト失敗時にLinux上でアプリケーションログとWebサーバーログを確認し 　エラー発生機能の特定。 ・課題 　プロジェクト途中からの参画により、既存の画面遷移とGMOサイン連携部分の仕様 　差分を十分に把握できていなかった。加えて、既存の設計資料は正常系が中心で例外時の 　挙動の記載粒度が粗く、オフショア実装との前提認識にもズレが生じやすい状態だった。 　このままではテスト観点の抜けが起き、不具合を見落とすリスクが高かった。 ・打ち手 　設計書だけでは例外時の挙動や連携仕様の細部が読み取れなかったため、 　設計書の読み込みに加えて先輩社員への確認と実機操作を併用した。 　資料・有識者・実挙動の3つを突き合わせることで、仕様の解釈違いによる 　テスト観点の漏れを防ぎ、途中参画でも実務レベルの仕様理解に引き上げた。