ID:48971さん

# 概要 大手携帯電話会社の端末購入Webサービス開発プロジェクト。 リリース直後から参画し、保守と第２フェーズへ向けた開発を担当。 # 規模 プロジェクト人数: 10 - 15人 案件単位チーム人数: 2 - 10人 # 保守内容詳細 仕様変更や不具合修正などの保守案件では、詳細設計、フロントエンド/バックエンド開発、単体/結合試験を担当しました。 ## 使用技術 使用した技術は下記の通りです。 - フロントエンド開発言語：JavaScript(IE対応を考慮) - フロントエンド開発ライブラリ：jQuery - バックエンド開発言語：Java SE 6 - バックエンド開発フレームワーク：OW+ - データベース：Oracle 11g ## 成果 ### フロントエンドの改善 #### 課題 参画当時、JavaScriptの知識を持つメンバーが不在であったため、フロントエンドのソースコードが複雑かつ難読で、修正が1行で済むようなエラー調査にも半日以上を要するほど保守性が低い状態でした。 #### 対策 私はJavaScriptを使用した個人的な開発の経験が3年ほどあったので、日次タスクの傍らこの問題を下記のように改善しました。 - jQueryでハードコーディングされたHTML要素参照ロジックを共通関数化 - 画面のセクションごとに同様の操作が必要な部分が多くあったため、セクションのひな型となるprototype(IE対応が要件に含まれていたためclassは使用不可でした)と各セクション用のオブジェクトを作成 - 類似する関数を共通化し、コールバックを使用することで汎用化 - thisや関数の巻き上げなどJavaScript独特のロジックが必要な部分を隠蔽 - JavaScriptでの記述に適したエディタとしてVisual Studio Codeの導入を交渉（それ以前はEclipseを使用） #### 結果 フロントエンドで発生した大半の障害について、調査から修正まで2~3時間以内に完了するようになり、フロントエンドの修正方針について伝達しやすくなりました。 ### テスト工程の改善 #### 課題 チームメンバーの平均的なテスト打鍵実施速度が1日当たり4～6件でしたが、非効率的な部分が多く見受けられました。 #### 対策 - エビデンス添付用Excelシートのテンプレート作成 - Excelでのショートカット活用 - チームリーダーと相談の上、冗長なエビデンスの簡略化 - エビデンス生成用のログ成形ツール(JavaScriptを使用した簡易Webアプリケーション)の自作 - エビデンス生成用の画面表示項目チェックツール(JavaScriptを使用した簡易ツール)の自作 - テストの趣旨・確認項目の記憶 #### 結果 私個人として、1日のテスト実施件数が12～20件にまで増えました。 この実績を基に、テスト実施手順書の見直しを提案し、不要な手順の削除と自作ツールの共有を行った結果、1日当たりに実施可能なテスト件数のチーム全体平均が8～10件にまで増加しました。 # 開発内容詳細 初期リリース時に保留となっていたクレジットカード決済機能・画面の開発チームのサブリーダーを担当しました。 決済用ツールとしてGMO Payment Gatewayを使用し、その導入方法を資料化、具体的な導入方針の定義に主体的に関わり、フロント/バックエンドにおける基本・詳細設計、開発、単体テストまでを担当しました。 ## 使用技術 上記保守案件で使用した技術に加えてGMO Payment Gatewayから提供されている下記APIを利用しました。 - クレジットカード情報トークン発行API（JavaScript用） - クレジットカード利用可能状況確認API（Java用） - クレジットカード利用者ブラックリスト確認API（Java用） - クレジットカード与信枠確認API（Java用） - クレジットカード決済実行API（Java用） ## 成果 ### プロジェクトの推進補助 #### 課題 参画した段階ではGMO Payment GatewayをJavaを使用して導入するという基本要件以外何も決まっていない状態のまま、案件が1年以上凍結していました。 #### 対策 下記内容を積極的に行うことで円滑なプロジェクト進行に貢献しました。 - ツール概要の図式化 - ツール詳細の理解と記憶 - 数十件におよぶ課題と解決方針の提示、解決状況の明確化 - 顧客（SI社員）に対する簡潔かつ十分な説明と応答 #### 結果 参画当時の私はエンジニア歴が半年足らずでしたが、案件に対する深い理解や姿勢が評価され、サブリーダーのポジションに任命されました。 また、ベンダーへ提示した複数の資料は、ベンダーとエンドユーザ間での打ち合わせにも利用され、要件定義を進めるためのツールとして貢献しました。 その1か月後には要件も固まり、半年後のリリースに向けてプロジェクトを進めて行くことができました。 ### 決済API呼出処理の実装 #### 課題 クレジットカード決済を導入するにあたって、既存の通信料合算決済時との処理分岐や、複数の外部APIの呼出を考慮する必要があった。 #### 対策 既存の決済方法との分岐を効率的に行うため、まず共通化できる処理を汎用メソッドとして分離。 加えて、各画面遷移毎に用意していたデータ保持用DTOクラスの親クラスとして共通クラスを作成することでデータの持ち回りを容易にしました。 APIの呼出は、クレジットカードのセキュリティシステムに応じて呼出順序や回数に分岐が生じるため、APIごとの処理を汎用化し、保守性を高めました。 #### 結果 データ保持用の共通DTOを作成した二次作用として、既存画面のデータ共有が簡略化されました。 また、APIごとにメソッドを分離したことで単体テストが容易になり、テスト工数が減りました。

# 概要 会員制企業・業界分析情報Webサービスの保守開発プロジェクト、並びに企業・業界情報プラットフォーム開発プロジェクトを並行して担当。 # 規模 情報サービス保守開発プロジェクト人数: 2人 情報プラットフォーム開発プロジェクト人数: 9人 # Webサービス保守開発プロジェクト詳細 日々のエラー調査と修正、並びに仕様変更時の設計・実装・テスト、特にJavaを使用したAWS Lambda向けのHTTP APIの設計・実装を担当しておりました。 実装に当たって使用した技術は下記の通りです。 - API全般開発言語：Java SE 8 - API全般開発フレームワーク：Spring Framework - データベース：Oracle 19c - Lambda APIを介したHTTPリクエスト/レスポンスの授受：T2 Framework - JavaからのDBアクセス：Doma 各APIのおおまかな処理フローは下記の通りです。 1. フロント側からリクエストを受け取る 2. 受け取ったリクエストを基に、外部APIやデータベースから必要なデータ（顧客情報、ニュース・記事内容、企業・業界情報、その他分析内容）を収集 3. 収集したデータから要求されているデータを生成 4. フロント側にレスポンスを送り返す 当プロジェクトには設計書が存在せず、実装者によっては可読性が著しく低い部分もあり、保守性が低い状態でした。 そこで、私が実装する際には英文として意味の通る命名や1メソッド1機能での実装、機能の汎用化を心がけ、タスクの余裕があるときは既存の難読な部分についても同様の修正を行っていきました。 その成果としてモジュールの可読性が高まっただけでなく、私自身のシステムに対する理解も深まったこともあり、参画から2か月後にはすべての実装タスク（3～7人日見積）を1人日以内に完了することができるようになりました。 # プラットフォーム開発プロジェクト詳細 複数のWebサービスで保持している情報を統合したプラットフォーム開発プロジェクトにおいて、データベース更新用のバッチ作成を担当しておりました。 開発環境にはWindows、テスト・本番環境にはLinuxを使用し、実際に使用した技術は下記の通りです。 - Linuxからのバッチ実行用シェル：Shell Script - バッチ開発全般：Java SE 8 - データベース：MySQL - JavaからのDBアクセス：Doma 2 各バッチの大まかな処理フローは下記の通りです。 1. ShellからJavaを実行 2. データベースからSQLによって必要なデータを収集 3. 収集したデータをJavaで加工 4. 加工データを注入したSQLを実行し、テーブルを更新 各バッチの処理内容は設計済みである一方、テーブル設計が半分以上未完の状態から参画したため、テーブルのカラム構成を仮定して実装を行いました。 そのためテーブル設計の完了・修正のたびに実装を修正する必要がありましたが、複数のバッチを並行して作成することで作業の滞りを防ぎ、それぞれのコーディングルールを極力統一することで要修正箇所の発見を容易にするよう心掛けました。