ID:75711さん

# プロジェクト概要 ・某団体が運営している会場オークションに対するDX ・エクセルをベースとした運用からの脱却、それに付随するメール、FAXでのコミュニケーションの効率化 ・複写用紙を使用した運用の改善 # 開発体制 * PM:上長 * メンバー：私（単体で対応） # 使用技術 * C# * SQLServer * Blazor .NET6.0(現在は.Net8.0) * MudBlazor * SignalR * xUnit（運用の中で追加） * Docker（運用の中で追加） # 実装内容 ## MudBlazorの導入 ### 概要 全体的に、システムの見栄えを良くするために、フロントサイドのフレームワークを導入。実際、テーブルの表現、ボタンの表現、入力欄の表現等、全体的にリッチな表示になった。 ### 課題・問題点 前例が無かったため、導入方法から自分で調査し、導入に至った。また、MudBlazorの導入によってBootstrapのグリッド機構が効かなくなってしまったので、MudGridの記法に改めて実装を進めた。 要素同士の間隔を狭く表現しなければならない等、レイアウトの課題に悩まされた際は、ブラウザの開発者ツールから実際のhtmlを確認し、要所要所でMudBlazorを使わない記法も組み合わせながら解決してきた。 ## オークション会場画面の実装 ### 概要 ユーザーが運営するオークションが会場オークションであり、入札金額を操作する端末とは離れた場所に、スクリーン投影用のパソコンを設置する必要があった。その際、入札金額を操作する端末とスクリーン投影用の端末で、入札金額等を同期する必要があった。その際に、SignalRを使用した。 １つだけ、社内にSignalRの導入実績があるソリューションがあったため、そちらを参考に導入した。 ### 課題・問題点 セリ中はかなり高速で入札が行われるので、高頻度のSignalR Hubへのリクエストが発生するが、同期先端末に届く情報は、順番が保証されておらず、入札価格が下がる現象がテスト段階で確認された。 同期先画面の制御として、入札価格が現入札価格より低い場合は金額更新しない判定を追加した。 ## 落札会員署名画面の実装 ### 概要 旧来の運営で、落札会員は手書きのサインで署名する運用があり、その運用を残す必要があった。そこで、ユーザーにはiPadを導入してもらい、タッチペンで署名できる機能を実装した。 ### 課題・問題点 いざユーザー端末で書いてみると、線が表示されたりされなかったりし、あたかも書けないボールペンのような挙動をした。それについて、システム側での改善は難しかったが、iPadの設定で、「スクリブル」をOFFにすることで挙動が改善した。 ## 帳票出力全般 ### 概要 ActiveReportsを使用して帳票を出力した。どうせなら、当時新機能として打ち出されていた、Blazor Viewerを使う方針で進んだ。 ### 課題・問題点 旧来、LocateDataSourceイベントを使う事で、レポートへデータソースを渡していたが、Blazor Viewerではこの建付けで実装できず、別な方法を模索した。結果、データソースにJsonを指定し、レポートの「パラメータ」にJson文字列をセットすることでデータソースを渡す方法で解決できた。 しかし、その後文字サイズがあまりに小さくなった場合、画面上のプレビューのレイアウトが崩れる問題が解決できず、Blazor Viewerはお蔵入りとなり、サーバー生成＋ダウンロードのスキームに変更となった。 ## テストコードの実装 ### 概要 オークション開催後、金額を取りまとめて請求明細書を出力する機能において、金額不一致のインシデントが発生。再発防止策として、テストコードを実装した。今後、バグが発見された際に、テストコードに追加していって、より精度の高いシステムに成長する見込みとなる。 ### 課題・問題点 テストコードでは、具体的なDBのデータを前提とした実装を行いたいシーンが多々ある。その際、テストで使用するDBを手運用にしてしまうと、テスト実行時にテスト用のDB由来のバグが発生、あるいは運用方法そのものを忘れてしまい、テストコード運用が形骸化する問題がある。 そこで今回、テストコードにDockerを導入し、コンテナ生成から、DB生成、シードデータ入力までをテストプロジェクトの初期化処理に加えることで、実行時間は多少増えるが、テスト用DBの手運用問題を解決した。 # 本プロジェクトにおけるアピールポイント 私の長所は、主体性であると思っております。 本プロジェクトにおいては、PMは上司１名、実装担当は私一人で対応したプロジェクトでした。PMである上司は要件定義の段階まではサポートして頂きましたが、その後は基本的に私の方で実装を進め、ユーザーと細部のすり合わせを行い、適宜問題解決を行い、完成までたどりつきました。 運用においても、インシデントを出してしまったことは反省すべき点ですが（「テストコードの実装」）、次発生しないように仕組みとして対応案を提案し、実装まで完結させた点は、私の魅力が表れていると考えます。「次、同じ失敗をしない為にどうするか」をきちんと自分事として考え、主体的に対応できたことの結果だからです。