ID:71072さん

VisualBasicで構築されていた食品卸会社の基幹システムをReactで再構築 主な機能として、在庫・発注・受注・製造の管理を実現 フロントはReact、バックエンドはLaravelで構築 # 役割 Webフロントエンド/バックエンドのエンジニア # 主な担当業務 設計（画面設計・API設計・機能設計・テスト設計） 実装（画面実装・API実装） プルリクエストのレビュー（バックエンド・フロントエンド） # タスク内の実績 *** ### 【タスク1】 #### レシート出力機能の実装 メンバー：二人（自分は設計・開発・レビューを担当、もう片方は開発を担当） 【課題1】 **要件定義段階でタスクの深掘りが出来ていなかった** 私がプロジェクトに参画した時点では、要件定義は完了しており、お客様から現行システムの仕様書をいただいていました。しかし、仕様の深掘りが不十分で、仕様書だけでは実装に必要な情報が不足していました。 【上記課題に対して以下を実施】 ・ meetを使用して、口頭でやり取りしてしまうと時間が取られてしまうので、資料を通して仕様の深掘りをする ・また、お客様は新システムの動きを理解できていないので、基本提案ベースでやり取りをする 【功績】 ・ 仕様の深掘りが適切に行われ、実装に必要な情報が不足することなく、スムーズに開発を進めることができた。 ・スケジュールの遅延やコストの増加を防ぐことができた。 【課題2】 **仕様が複雑なこともあり、開発者と設計者で認識齟齬が発生する** 私が、作業のフローを設計し、その設計書（フローチャート）をメンバーに提供して実装していく手法を取っていました。しかしながら、実装の段階で設計書の仕様が複雑であり、設計内容と異なる実装が行われ、その都度手戻りが生じました。 【上記課題に対して以下を実施】 ・TDD開発手法を提案し、設計書の作成と同時にテストコードの実装を行うようにした。 【功績】 ・ 設計の仕様と実装の乖離を最小限に抑えた。 ・テストコードの導入によって実装段階での仕様漏れに気づくことができた。 ・プロジェクト内で初めてTDD開発をやったので、メリデリをチーム内に共有した。 *** ### 【タスク2】 #### データの一覧・新規登録・更新・画面の実装 メンバー：一人（画面設計・開発を担当） 【課題1】 **画面の機能が拡大し、結果としてコードが膨大になり、可読性が低下した** お客様の追加要望に対応するたびに機能が増加し、それに伴いコードが複雑化し、可読性が低下しました。この結果、機能の変更や追加ごとに不具合が頻発し、開発におけるコストが膨れ上がりました。 【上記課題に対して以下を実施】 ・この問題に対処するため、画面を作り直すことに決定しました。新しい設計では、可読性が悪くなった理由を洗い出し、以下の改善点を導入しました。 改善点１：ReduxFormでの全値管理を見直し、Formに必要な値だけを管理し、計算可能な値はReactのuseMemoを利用して効率的に処理するようにしました。APIに渡す際にはFormの値とstateを適切に結合させる処理を導入する 改善点２：useEffectを使用していたが、その柔軟性からくる可読性の低下と責任の集中を避けるため、useEffectを最小限に留め、useMemoとuseCallBackを組み合わせて処理を効果的に実現するよう心掛けました。 改善点３：処理の細分化を行い、関数コンポーネント外に切り出す際に破壊的関数にならないよう慎重に実装する 【功績】 ・処理の責任が分散され、画面の修正スピードが格段に上がった。 ・改善点を意識して実装することで、他の画面でもコードの可読性が向上し、レビューの効率が向上しました。 *** # タスク外の実績 *** ### 【実績1】 **バックエンドのデバッグツールが不足している** プロジェクトではバックエンドをデバッグする際にステップ実行とログファイルしか利用していなかった為、デバッグと処理の最適化に時間がかかっていた 【上記課題に対して以下を実施】 ・Laravelのclockworkというデバッグツールを提案し、導入させた ・clockworkの効果的な使用方法やN+1問題の解消法についての知識を共有するため、Laravelの勉強会を開催し、チーム全体に普及させました 【功績】 ・チーム全体でN+1の問題に対する認識が高まり、リファクタリングの意識が一層強化されました。 ・デバッグプロセスの改善により、業務の効率が向上しました。 *** ### 【実績2】 **バックエンドのコードを修正しても、修正がすぐに反映されない** コードを修正して、POSTMAN等でAPIを実行しても、すぐに反映されず、コンテナを再実行する等の無駄な時間が発生していた。 【上記課題に対して以下を実施】 ・Laravelの処理を高速化する手段としてopcacheを使用していましたが、opcacheのキャッシュ作成処理が60秒に1回となっていたことが原因でした。そのため、コードが変更されたら都度キャッシュを作成するよう設定に見直しました。 【功績】 ・チーム全体の作業効率が向上した ### 【実績3】 **GitHub Actionsを使用して、自チーム内にCIを導入** 参画時、テストコマンドをローカル環境で実行していたため、マージ前のコマンド実行漏れによりdevelopブランチにデグレが発生し、手戻りが繰り返されていました。 【上記課題に対して以下を実施】 ・他チームでCIが導入されていることを知り、Github Actionsのレクチャーを受けた後、自チームに必要な設定を含むyamlファイルを作成し、PR作成時にテストコードが実行されるようにしました。 【功績】 ・developブランチでのデグレ発生を防ぎました。 ・GitHub ActionsとCIについての知識が不足していたため、チーム内で勉強会を開催し、メンバー全体の理解を深めました。

# プロジェクト概要（目的・体制） 「マイナポータル」における「健康保険証の利用登録」と「公金受取口座の登録」に関わるバッチ処理の開発を担当しました。プロジェクトはウォーターフォール開発モデルに基づき、参画時には既に外部設計が完了し、内部設計のフェーズに進行していました。 # 役割 バックエンドエンジニア # 主な担当業務 設計（バッチ処理の設計・SQL設計） 実装（バッチ実装・SQL実装） プルリクエストのレビュー（バックエンド） # タスク内の実績 *** ### 【タスク1】 #### 通知機能のバッチ設計 【内容】 外部設計書を基に、通知機能のバッチ処理を詳細に整理し、必要なデータを取得するためのSQLを設計し、それに基づく設計書を作成いたしました。 【工夫した点】 ・ 処理の円滑な実現を図るため、データ取得段階での最適化に特に配慮しました。なお、参画時にPostgreSQLに十分な知識がなかったため、主体的に学習し、ローカル環境にPostgreSQLをダウンロードして、自身が設計したSQLの実行計画をEXPLAINコマンドを使用して確認しました。 ・プロジェクト内で初めての内部設計書作成という状況で、設計書のフォーマットが確立されていなかったため、30％の完成度で早期にPLに提出し、PLとの認識合わせを行いながら内部設計書のフォーマットを確定させました。 *** ### 【タスク2】 #### 通知機能のバッチ実装 【内容】 Spring Batchを使用して、自分で作成した内部設計書を基に、バッチ処理を実装 【工夫した点】 ・テストの徹底性向上のため、Junitを活用して以下の3つのテストパターンを導入しました。 　１．全体の流れを網羅したテスト 　２．処理を細分化し、部分ごとにテストを行う細分化テスト 　３．ハンドリングやログ出力が正常に機能していることを確認する異常系テスト テストカバレッジを高い水準で維持し、結合テストフェーズにおいてバグの発生を最小限に抑えました。 ・開発効率向上のため、Eclipseの機能を習得し、setter/getterの自動生成、テンプレート、リファクタリングなどの機能を積極的に活用しました。同時に、チーム全体にドキュメントを作成し、全体の生産性向上に寄与しました。 ***