ID:84329さん

プロジェクト経験概要 自動車整備業務で使用されるiOS業務支援アプリの開発・改修に従事。 本アプリは、Bluetooth Low Energyで接続した外部測定機器からデータを取得し、作業状況の表示、測定結果の判定・保存、関連情報の管理、外部システムとのデータ連携を行う業務用アプリです。 既存アプリへの機能追加、UI改修、不具合調査を中心に担当。主にiPad向けに開発し、一部機能ではiPhoneの画面サイズにも対応しました。 チーム情報 ・開発体制：複数名でのチーム開発 ・役割：開発メンバー ・担当工程：既存仕様・ソースコード調査、設計内容確認、実装、UI改修、不具合調査、実機テスト ・主な担当機能：入力画面、作業進捗画面、測定結果画面、Bluetooth接続制御 ・使用技術：Swift、UIKit、SpriteKit、CoreBluetooth、Realm、SnapKit、Git ・開発環境：Xcode、iPad、iPhone、Bluetooth対応外部機器 チーム全体ではアプリ全体の開発・保守を行い、その中で入力画面、作業進捗画面、測定結果画面、Bluetooth接続制御に関する機能を担当しました。 開発・実装内容1：業務情報入力画面およびOCR結果の入力制御 【概要】 業務に必要な情報を入力・確認する画面について、OCR結果の反映、入力値のバリデーション、表示項目の切り替え、画面遷移制御、端末サイズに応じたレイアウト改修を担当。 【どのような機能の開発・実装か】 OCRで取得した文字情報を入力欄へ反映し、利用者が認識結果を確認・修正できる機能を実装しました。 入力内容が所定の形式を満たしているかを項目単位で判定し、不備がある場合は後続画面へ遷移できないよう制御しました。 入力エラー時には対象項目の枠線や表示状態を切り替え、修正が必要な箇所を視覚的に把握できるようにしました。 また、画面遷移元や取得済み情報の有無に応じて、必要な入力領域のみを表示する処理を実装しました。 【課題・問題点】 OCR結果には、文字の誤認識、桁数不足、形式不一致などが含まれる可能性があり、そのまま後続処理へ渡すと誤った情報が登録される問題がありました。 また、利用条件によって必要な入力項目が異なるため、すべての項目を固定表示すると不要な入力欄まで表示され、操作が分かりにくくなっていました。 加えて、iPadとiPhoneでは画面幅が異なり、固定的なレイアウトでは入力欄やボタンの重なり、画面外へのはみ出しが発生していました。 【打ち手・使用した技術】 既存仕様とソースコードを確認し、各入力項目について文字種、桁数、必須・任意などの条件を整理しました。 Swiftで項目ごとのバリデーション処理を分離し、すべての必須項目が条件を満たした場合のみ後続画面へ遷移できるよう制御しました。 UIKitを使用して通常時、入力中、エラー時の表示状態を切り替え、入力不備のある項目を視覚的に判別できるようにしました。 画面遷移元や取得済みデータに応じた表示切り替えは、Swiftの状態管理と条件分岐を用いて実装しました。 レイアウトにはSnapKitを使用し、Auto Layout制約を整理。固定座標への依存を減らし、端末サイズに応じて余白や表示幅を調整することで、iPadとiPhoneの両方で表示が崩れにくい構成にしました。 また、NotificationCenterを使用し、別画面で更新された情報を対象画面へ通知して表示内容へ反映しました。 使用技術 Swift：入力値の判定、状態管理、画面遷移制御 UIKit：入力欄、ボタン、エラー表示の制御 SnapKit：iPad・iPhone向けのAuto Layout制約 NotificationCenter：画面間の情報更新通知 【成果】 入力不備がある状態で後続処理へ進むことを防止し、誤った情報が登録されるリスクを低減しました。 エラー対象を画面上で明確に表示することで、利用者が修正箇所を判断しやすくなりました。 また、利用条件に応じた表示切り替えと複数端末への対応により、不要な入力を減らし、操作性を改善しました。 開発・実装内容2：作業進捗画面および処理順序の状態制御 【概要】 複数の作業対象について、未実施、実施中、完了といった状態を画面上に表示し、所定の順序で作業を進める機能の改修を担当。 また、誤操作や再確認が必要な場合に、指定した対象を未実施状態へ戻し、再度作業できる機能を実装しました。 【どのような機能の開発・実装か】 各作業対象の状態に応じて、画面上の図形や表示色を切り替える機能を実装しました。 作業完了後は、現在位置と内部状態を参照し、次の作業対象へ自動的に遷移する処理を改修しました。 また、利用者の操作により、選択した対象の状態を戻して再処理できる機能を追加しました。 チーム全体では複数の作業画面を開発しており、その中で画面表示と内部状態の同期、次の対象を決定する遷移制御、再処理時の状態復元を担当しました。 【課題・問題点】 再処理や画面遷移を行った際に、画面上の表示状態とアプリ内部で保持している進捗状態が一致しなくなる問題がありました。 表示だけが未実施状態に戻り、内部の現在位置が更新されていない場合、次に選択される作業対象が意図した順序と異なることがありました。 また、利用条件によって作業対象数や処理順序が異なるため、条件分岐が複数箇所に分散し、影響範囲を把握しにくい状態でした。 【打ち手・使用した技術】 既存コードを確認し、画面表示を更新する処理、内部状態を保持する処理、次の対象を決定する処理に分けて調査しました。 Xcodeのブレークポイントとログ出力を使用し、操作前後の現在位置、進捗状態、次の遷移先を確認。表示と内部状態がずれる条件を特定しました。 修正時は画面表示だけを変更するのではなく、Swiftで管理している内部状態、現在位置、次の遷移先を同じタイミングで更新するよう処理を整理しました。 再処理時には、選択対象だけでなく後続の作業順序への影響も確認し、必要な範囲のみ状態を戻すようにしました。 UIKitで画面操作とジェスチャーイベントを制御し、SpriteKitで作業対象の図形、色、進捗状態の描画・更新を行いました。 再処理機能にはUIGestureRecognizerを使用しました。 また、複数画面に重複していた遷移処理について、共通化可能な処理を整理し、同様の修正を複数箇所へ個別に反映する必要を減らしました。 使用技術 Swift：進捗状態、現在位置、遷移先の管理 UIKit：画面操作、ジェスチャーイベントの制御 SpriteKit：作業対象の図形、色、状態表示の更新 UIGestureRecognizer：再処理操作の検知 Xcode：ブレークポイント、ログを用いた状態調査 【成果】 画面表示と内部状態の不一致を改善し、現在の作業対象と進捗状況を把握しやすくしました。 再処理時にも意図した順序で作業を再開できるようになり、一部の作業をやり直すために全工程を最初から実施する必要がなくなりました。 また、状態遷移処理を整理したことで、既存機能への影響範囲を確認しやすくなり、保守性の向上にもつながりました。 開発・実装内容3：Bluetooth外部機器との接続および通信状態制御 【概要】 Bluetooth Low Energy対応の外部機器とアプリを接続し、測定データをリアルタイムで取得・表示する機能について、既存処理の調査、不具合修正、接続状態制御の改修を担当。 【どのような機能の開発・実装か】 処理開始前に必要な外部機器が接続されているかを確認し、未接続の場合は接続操作を行う画面へ誘導する処理を実装しました。 また、利用する機器の種類や設定状態に応じて、接続処理や初期設定を切り替える既存機能について調査・改修しました。 チーム全体では外部機器との通信機能を管理しており、その中で接続状態と画面状態の不一致調査、未接続時の処理制御、機器種別に応じた条件分岐の確認を担当しました。 【課題・問題点】 外部機器との通信が一度切断された後、画面上では接続済みのように見えても、実際には測定データを受信できない場合がありました。 その結果、通信が成立していない状態でも後続処理が開始され、利用者が測定を進められない問題がありました。 また、複数種類の外部機器に対応していたため、機器ごとの接続条件や初期設定に関する条件分岐が複雑になっていました。 【打ち手・使用した技術】 CoreBluetoothの接続開始、接続完了、切断、データ受信に関する既存処理を追い、内部で保持する接続状態と実際の通信状態がどの時点でずれるかを調査しました。 画面遷移時の接続状態、選択中の機器種別、データ受信イベントの発生状況をログへ出力し、Xcodeのブレークポイントと併用して再現条件を整理しました。 Swiftで通信状態と処理開始可否を管理し、接続が確立していない場合は後続処理を開始せず、接続操作を促す画面へ遷移するよう制御を修正しました。 NotificationCenterを使用して接続状態や受信データを対象画面へ通知し、画面表示と通信状態が一致するようにしました。 また、機器種別を判定する条件分岐を確認し、選択した機器に応じて必要な初期設定が実行されるよう処理を整理しました。 使用技術 CoreBluetooth：接続、切断、データ受信処理の調査・改修 Swift：通信状態、処理開始可否、機器種別の管理 NotificationCenter：接続状態および受信データの画面通知 Xcode：ログ出力、ブレークポイントを用いた不具合調査 【成果】 通信が成立していない状態で後続処理が開始されることを防止し、接続状態に応じて適切な画面へ遷移できるよう改善しました。 切断後に測定データを受信できないケースについても、再現条件と処理の流れを明確にし、画面状態と通信状態の不一致を改善しました。 また、複数種類の外部機器に関する条件分岐を整理したことで、機器ごとの接続・設定処理を確認しやすくしました。 開発・実装内容4：作業結果画面および詳細情報表示 【概要】 複数の作業対象について結果を一覧表示する画面と、作業時に使用した設定情報や関連情報を確認する補助画面の実装・改修を担当。 【どのような機能の開発・実装か】 各作業対象の結果を一画面で確認できる一覧表示を実装しました。 iPadとiPhoneでは利用可能な画面幅が異なるため、端末サイズに応じて結果の配置方法を切り替えるレイアウトを実装しました。 また、結果画面を離れずに、作業時の設定情報や関連条件を確認できる詳細情報表示を追加しました。 チーム全体では結果データの管理や保存処理を行っており、その中で保存済みデータの画面表示、画面部品の構成、端末別レイアウト、詳細情報表示を担当しました。 【課題・問題点】 表示する情報量や端末サイズによって、文字や画面部品の重なり、画面外へのはみ出しが発生していました。 また、結果のみが表示されていたため、その結果がどの設定や条件に基づいて処理されたものかを画面上で確認しにくい状態でした。 さらに、画面ごとに表示処理を個別実装すると、表示内容を変更する際に複数箇所の修正が必要となり、保守性が低下する懸念がありました。 【打ち手・使用した技術】 Realmから保存済みの作業結果と関連情報を取得し、Swiftで画面表示に必要な形式へ変換しました。 結果表示は作業対象単位で再利用できる画面部品として分割し、UIKitを使用して一覧画面を構成しました。 SnapKitによるAuto Layout制約を使用し、iPadでは複数項目を並べて表示し、iPhoneでは縦方向を中心とした配置へ切り替えることで、端末サイズに応じた画面構成にしました。 表示位置、余白、縦横方向の並びを調整し、データ件数が変わった場合でも画面が崩れにくいようにしました。 詳細情報は、現在の結果画面を維持したまま確認できる補助パネルとして実装しました。 端末幅に応じて表示サイズを変更し、結果一覧を確認しながら関連情報も参照できるようにしました。 使用技術 Realm：保存済みの作業結果、設定情報の取得 Swift：表示用データへの変換、端末条件の判定 UIKit：結果一覧、詳細情報パネルの画面構成 SnapKit：iPad・iPhone向けのレイアウト制約 【成果】 複数の作業結果を一画面で確認できるようになり、利用者が対象ごとの結果を比較しやすくなりました。 端末サイズに応じてレイアウトを切り替えることで、iPadとiPhoneの両方で情報を確認しやすい画面へ改善しました。 また、作業時の設定情報や関連条件を同じ画面から確認できるようになり、結果の背景を把握しやすくなりました。 画面部品を機能単位で整理したことで、表示内容の変更や追加にも対応しやすい構成になりました。 プロジェクトを通じて身につけたこと 既存システムの改修では、対象機能だけでなく、画面表示、内部状態、データ保存、外部機器との通信など、関連する処理全体の流れを把握することが重要だと学びました。 不具合調査では、再現手順を整理した上でログ出力やブレークポイントを使用し、どの処理段階で期待値との差が発生しているかを切り分けました。 仕様が不明確な場合は、既存コードや関連画面を確認して仮説を立て、確認事項を整理した上でチームメンバーへ相談することを意識しました。 実装後は正常系だけでなく、未入力、通信未接続、途中切断、再操作、端末サイズの違いなども含めて実機確認を行い、既存機能への影響がないことを確認しました。

プロジェクト経験概要 製造業向け生産管理システムにおいて、ASTERIA Warpを使用したデータ連携フローの運用・改修、テスト、不具合調査を担当。 主な業務は、既存フローの処理確認、仕様変更に伴う修正、テスト仕様書の作成、動作確認、実行ログを用いた原因調査。 また、既存の類似フローや設計資料を参考に、簡単な新規データ連携フローの作成も経験。 チーム情報 ・開発体制：複数名でのチーム開発 ・役割：開発・テストメンバー ・担当工程：実装、テスト、運用・保守 ・担当範囲：既存フローの調査・改修、簡単な新規フローの作成、テスト仕様書作成、動作確認、不具合調査 ・使用技術：ASTERIA Warp、Excel チーム全体では生産管理システムの開発・運用を担当。その中で、ASTERIA Warpを使用したデータ連携フローの改修、テスト、不具合調査を担当。 開発・実装内容1：既存データ連携フローの改修 【概要】 仕様変更に伴う、既存データ連携フローの調査・改修を担当。 【どのような機能の開発・実装か】 ASTERIA Warp上でシステム間のデータ連携を行う既存フローを確認し、連携項目のマッピング、条件分岐、データ変換などの設定を修正。 修正後はテストデータを用いてフローを実行し、想定した結果となることを確認。 【課題・問題点】 既存フローには複数の処理や条件分岐が含まれており、対象箇所のみを変更した場合、後続処理や既存の連携結果へ影響する可能性があった。 また、設計資料だけでは処理全体を把握しにくく、実際のフローを確認しながら影響範囲を整理する必要があった。 【打ち手・使用した技術】 ASTERIA Warp上で既存フローを確認し、入力から出力までの処理順序を調査。 変更対象がどの処理で参照され、どの後続処理につながっているかを確認し、修正箇所と影響範囲を整理した。 マッピングや条件分岐の修正時は、既存処理との整合性を確認し、変更箇所以外への影響を抑えるよう対応。 修正後は正常なデータに加え、未設定値や条件に一致しないデータも使用して動作確認を実施。 ・ASTERIA Warp：既存フローの調査、マッピング修正、条件分岐修正、データ変換設定、フロー実行 ・Excel：仕様内容、テストデータ、期待結果、実施結果の整理 【成果】 変更対象だけでなく、前後の処理や関連する条件分岐まで確認しながら改修することで、既存処理への影響を抑えて仕様変更に対応。 複数パターンのデータで動作確認を行い、設定変更による連携結果の不整合を防止した。 開発・実装内容2：データ不整合発生時の原因調査 【概要】 データ連携結果に不整合や未連携が発生した際の原因調査、設定修正、修正後の動作確認を担当。 【どのような機能の開発・実装か】 ASTERIA Warpの実行ログ、入力内容、マッピング、条件分岐、出力結果を確認し、問題が発生している処理を切り分けた。 原因がフロー設定にある場合は対象箇所を修正し、同一条件および関連するデータパターンで再テストを実施。 【課題・問題点】 最終的な出力結果だけでは、入力内容、マッピング、条件分岐、データ変換のどこに原因があるか判断できなかった。 また、複数の処理が連続して実行されるため、処理を段階的に確認し、問題箇所を特定する必要があった。 【打ち手・使用した技術】 発生事象、対象データ、期待結果、実際の結果を整理した上で、ASTERIA Warpの実行ログを確認。 フローが正常終了しているか、どの処理まで実行されているかを確認し、入力内容、マッピング、条件分岐、出力結果の順に調査した。 原因特定後は対象箇所を修正し、同一条件に加えて関連する正常系ケースも再確認。 ・ASTERIA Warp：実行ログ確認、処理経路の調査、マッピング・条件分岐の確認および修正 ・Excel：発生事象、再現条件、期待結果、実際の結果、調査内容の整理 【成果】 処理を段階ごとに切り分けて確認することで、不整合の発生箇所を特定し、原因調査から修正、再テストまで対応。 再現条件や調査内容を整理して共有することで、チーム内で問題の状況を把握しやすくした。 開発・実装内容3：簡単な新規データ連携フローの作成 【概要】 既存の類似フローや設計資料を参考に、簡単なデータ連携フローを新規作成。 【どのような機能の開発・実装か】 連携元から取得したデータを必要な形式へ変換し、連携先へ出力するフローを作成。 入力、マッピング、条件分岐、データ変換、出力といった基本的な処理をASTERIA Warp上で構成した。 【課題・問題点】 既存フローをそのまま流用すると、今回の仕様には不要な処理や異なる条件が含まれる可能性があった。 また、入力側と出力側の項目対応を確認し、今回の仕様に必要な処理のみを選択する必要があった。 【打ち手・使用した技術】 設計資料と既存の類似フローを比較し、共通して利用できる処理と、今回の仕様に合わせて変更が必要な処理を整理。 ASTERIA Warp上に必要な処理を配置し、入力から出力までの流れを作成した。 作成後は複数パターンのテストデータを使用し、マッピングや条件分岐が想定どおりに動作することを確認。 不明点については、既存フローや設計資料を確認した上で質問内容を整理し、先輩社員へ相談。 ・ASTERIA Warp：データ取得、マッピング、条件分岐、データ変換、出力処理の作成 ・Excel：項目対応、テストデータ、期待結果の整理 【成果】 既存フローをそのままコピーするのではなく、仕様との差分を確認しながら、必要な処理を組み合わせて簡単な新規フローを作成。 複数パターンで動作確認を行い、想定どおりにデータが処理されることを確認した。 開発・実装内容4：テスト仕様書作成および動作確認 【概要】 データ連携フローの新規作成・改修に伴う、テスト仕様書の作成、テスト実施、結果確認を担当。 【どのような機能の開発・実装か】 仕様書をもとにテスト観点を整理し、正常系、異常系、未設定値、条件不一致などを含むテストケースを作成。 ASTERIA Warp上で対象フローを実行し、実行ログと処理結果を確認した。 【課題・問題点】 正常なデータのみでテストした場合、実際の運用で発生する可能性のある未設定値や条件不一致による問題を発見できない可能性があった。 また、修正箇所だけでなく、既存処理へ影響がないことも確認する必要があった。 【打ち手・使用した技術】 入力条件、処理条件、期待結果を整理し、正常系に加えて、未設定値や条件に一致しないデータを含むテストケースを作成。 ASTERIA Warpでフローを実行し、実行ログと出力結果を確認して期待結果と比較した。 不具合発生時は、再現手順、入力内容、期待結果、実際の結果をExcelに整理。 修正後は該当ケースだけでなく、関連する既存ケースも再実施し、他の処理に影響がないことを確認した。 ・ASTERIA Warp：対象フローの実行、実行ログ、処理結果の確認 ・Excel：テスト仕様書、テストデータ、期待結果、実施結果の管理 【成果】 正常系に加え、未設定値や条件不一致を含めて確認することで、実運用で発生する可能性のある不具合を事前に発見。 再現条件と確認結果を整理することで、修正と再テストを円滑に進めた。 プロジェクトを通じて身につけたこと ASTERIA Warpを使用したデータ連携では、最終結果だけでなく、入力、マッピング、条件分岐、データ変換、出力の各段階を確認することが重要だと学んだ。 改修時は、変更箇所だけでなく前後の処理や既存機能への影響を確認することを意識。 不具合調査では、発生条件と期待結果を整理した上で、実行ログやフロー設定を順番に確認し、原因を切り分ける進め方を身につけた。