こんにちは！
情報経営イノベーション専門職大学から実習に参加している後藤麗奈です。
今週は大きく分けて3つの業務に取り組みました。
1つ目は、Power AppsとSharePointを使用して開発している部品在庫管理アプリのエラー原因調査と機能修正です。履歴表示の並び替え処理や、削除したデータを復元するゴミ箱機能を中心に、データ構造や処理内容を確認しながら改善を進めました。
2つ目は、A社からいただいた追加要望をもとに、在庫管理アプリを実際の業務でより使いやすくするための機能改善案を検討しました。製造業では部品単体の管理だけでなく、製品を構成する材料も管理する必要があるため、BOM（部品構成表）の導入について検討しました。
3つ目は、これまで作成したアプリの構成や実装内容、発生したエラーとその解決方法を整理し、後任者が継続して開発できるよう引継ぎ資料と操作マニュアルの作成・修正を行いました。
今週は、機能追加だけでなく、実際の業務で利用されるシステムとして必要な設計やデータ管理について深く考える機会となりました。
Power Apps在庫管理アプリのエラー調査・論理削除復元機能の修正
現在開発している部品在庫管理アプリでは、入庫・出庫・棚卸・履歴管理など、部品の登録から在庫確認までをPower AppsとSharePointを組み合わせて一元管理しています。
今週は、実装した機能が実際の運用でも正常に動作するか確認するため、各画面の動作検証とエラー原因の調査を行いました。中でも重点的に確認したのは、履歴一覧画面の並び替え処理と、誤って削除したデータを復元できるゴミ箱機能です。
履歴一覧では、SortByColumns関数を使用して日付順に並び替える処理を実装していましたが、指定した列が正しく認識されず、期待どおりに並び替えが行われない問題が発生しました。
原因を調査した結果、Power Appsで指定している列名とSharePoint側の内部列名が一致していないことが原因であると判明しました。そのため、SharePointのデータ構造を確認し、正しい列を参照するよう修正しました。
ゴミ箱機能では、削除した履歴を完全に削除するのではなく、一時保存用のSharePointリストへ移動させる「論理削除」の仕組みを実装しました。
しかし、Patch関数でデータを移動する際に、文字列・数値・日付・選択肢・ユーザー情報などのデータ型の違いによるエラーが発生しました。
そこで、SharePoint側の列設定とPower Apps側で渡している値を1項目ずつ確認し、Value関数やDateValue関数、Selected.Valueなどを使用して適切なデータ型へ変換したことで、削除・復元処理を正常に動作させることができました。
この対応を通じて、Power Appsでは画面の見た目だけでなく、データ構造やデータ型を理解することが重要であると学びました。さらに、実際の業務で利用されるシステムでは、削除機能を実装するだけでなく、誤操作時に復旧できる仕組みを備えることが、利用者が安心して使用するために重要であると感じました。
A社と在庫管理アプリの機能改善案についての話し合い
現在作成している部品在庫管理アプリについて、A社と実際の業務を想定した運用方法や改善点について話し合いを行いました。
A社からは、現在のアプリでは対応できていない業務フローへの対応や、より実務に適した在庫管理を実現するための機能追加が求められました。
中でも重要な要望は、「入庫履歴がない部品でも出庫できる仕組み」と、「製品単位で必要な部品を確認できるBOM（部品構成表）機能」の検討です。
現在のアプリでは、入庫履歴をもとに在庫数を管理しているため、入庫登録されていない部品は出庫できない仕様となっています。しかし、実際の現場では、システム導入前から保有している初期在庫や、緊急対応により入庫処理より先に出庫が必要となる場合もあります。
そこで、入庫履歴だけを基準とするのではなく、在庫マスタを基準に現在の在庫数を確認し、出庫の可否を判断する仕組みへの変更案を検討しました。
製造業では、部品を個別に管理するだけでなく、製品を構成する材料をまとめて管理することも重要です。
例えば、チョコレート製品を製造する場合には、カカオ・砂糖・牛乳・包装資材など、複数の材料を組み合わせて1つの製品が完成します。
現在の部品管理では、それぞれの材料を個別に管理することはできますが、「どの製品にどの部品が必要なのか」という関係性までは管理できません。
そこで、製品と部品を紐付けるBOM（部品構成表）リストを追加し、製品を選択すると必要な部品一覧を表示できる仕組みを検討しました。Power Appsでは、Filter関数やLookUp関数を利用し、選択した製品IDをもとに関連する部品情報を取得する構成を考えました。
この検討を通じて、システム開発では依頼された機能をそのまま実装するだけでなく、利用者の業務内容や運用方法を理解し、それに適したデータ構造や処理を設計することが重要であると学びました。また、現場の課題を踏まえてシステムを改善していくことが、より実用性の高いシステム開発につながることを実感しました。
後任者が継続して開発できるように引継ぎ資料および操作マニュアルの作成・修正
これまでの実習で作成してきた部品在庫管理アプリについて、後任者がアプリの構成や処理内容を理解し、今後の修正や機能追加を継続して行えるよう、開発者向けの引継ぎ資料を作成しました。
引継ぎ資料では、単なる操作方法ではなく、アプリの仕組みや処理内容を理解できるよう、以下の内容を整理しました。
・プロジェクト概要
・Power AppsとSharePointのシステム構成
・各SharePointリストの役割とデータ構造
・Power Apps各画面の役割
・入庫・出庫・棚卸登録処理の流れ
・在庫マスタ更新処理の仕組み
・検索機能（Filter、StartsWith、SortByColumnsなど）の処理内容
・編集機能の実装方法
・削除・論理削除・復元機能の処理の流れ
・使用しているPower Apps関数と役割
・発生したエラーの原因と解決方法
・未実装機能および今後の課題
重点的に整理したのは、開発中に発生したデータ型エラーやSharePointの列名不一致によるエラーです。原因だけでなく、どのような確認を行い、どのように修正したのかまで記録しました。
例えば、Patch関数を使用してSharePointへデータを登録・移動する処理では、文字列・数値・日付・選択肢・ユーザー情報などのデータ型の違いによってエラーが発生しました。SharePoint側の列設定とPower Apps側で渡している値を確認し、Value関数やDateValue関数などで適切なデータ型へ変換することで解決しました。
一方、SortByColumns関数による並び替え処理では、Power Appsで指定した列名とSharePoint側の内部列名が一致していなかったことが原因でした。そのため、SharePointの列設定を確認し、正しい列を参照するよう修正しました。
これらの内容を記録したことで、後任者が同じ問題に直面した場合でも、原因調査に時間をかけることなく対応できるようにしました。
加えて、今後の改修や保守を行う際の注意事項も整理しました。Power Appsでは、データ件数や画面数、コントロール数が増えると動作速度に影響するため、必要以上のデータやコントロールを配置しないことを記載しました。
Filter・SortByColumns・Searchなどの関数については、委任警告（Delegation）に注意し、データ件数が増加した場合でも正しく検索できるよう、委任可能な関数を優先して使用することをまとめました。
SharePointについても、データ件数の増加による検索・表示速度の低下を防ぐため、必要に応じてインデックス列を設定し、必要なデータのみ取得することを注意事項として記載しました。
さらに、改修前にはPower Appsの「名前を付けて保存」やエクスポート機能を利用してバックアップを取得し、問題発生時に以前の状態へ戻せるようにすることも引継ぎ事項として整理しました。
削除・復元機能に関するSharePoint構成についてもまとめました。現在、入庫・出庫・棚卸履歴では、削除データを一時保存するSharePointリストの作成と削除・復元処理が完了しています。
一方、在庫管理機能では、削除データを保存するSharePointリストが未作成のため、今後の対応事項として記載しました。今後、在庫管理機能へ削除・復元機能を追加する際には、専用の保存リストを作成し、Power Apps側の処理と連携させる必要があります。その際は、既存の履歴リストと同様に、Power Appsで使用する列名やデータ型をSharePoint側と一致させることが重要です。
利用者向けの操作マニュアルについては、アプリを初めて使用する担当者でも迷わず操作できるよう内容を見直しました。従来は文章による説明が中心でしたが、実際のアプリ画面を掲載し、操作する場所や入力項目が分かるよう改善しました。
具体的には、入庫登録、出庫登録、棚卸登録、履歴一覧の確認、履歴検索、履歴編集、履歴削除、削除した履歴の復元方法について、画面画像を用いて説明しました。また、部品ID、品名、数量、担当者、日付などの各入力項目についても、それぞれの役割が分かるよう説明を追加しました。
今回の資料作成を通じて、引継ぎ資料は開発者がシステムの仕組みや修正方法を理解するための資料であり、操作マニュアルは利用者が正しくアプリを操作するための資料であるという違いを理解しました。また、システム開発ではプログラムを作成するだけでなく、開発内容や操作方法を第三者へ正確に共有するためのドキュメント作成能力も重要であると学びました。
新しく理解したこと
今回の業務を通じて、アプリ開発では機能を追加することだけでなく、その機能が実際の業務でどのように利用されるかを考慮して設計することが重要であると理解しました。
Power AppsとSharePointを用いた開発では、画面やボタンの作成だけでなく、データの保存・取得・更新方法を含めたデータ構造の設計が、システム全体の動作に大きく影響することを学びました。
また、Patch関数を使用した登録や削除・復元処理では、文字列・数値・日付・選択肢などのデータ型を正しく理解することが不可欠であり、データベース構造を把握する重要性を実感しました。
さらに、委任警告（Delegation）への対応やSharePointのデータ件数増加による性能低下への対策、バックアップ取得、未実装機能の整理などを通じて、システムは完成して終わりではなく、運用・保守・引継ぎまで見据えて設計することが重要であると学びました。
今後にどう活かすか
今後システムやアプリを開発する際には、すぐに実装へ取り掛かるのではなく、利用者の業務内容や課題を理解した上で、必要なデータ構造や処理の流れを整理してから開発を進めたいと考えています。
今回の経験から、初期段階でデータ設計やシステム構成を明確にしておくことが、後の機能追加や修正を容易にし、品質の高いシステム開発につながることを学びました。
Power AppsとSharePointで経験したデータ型エラーや列名不一致による問題についても、エラー内容だけを見るのではなく、データの流れや保存先まで確認しながら原因を特定する力として今後の開発に活かしていきたいです。
さらに、引継ぎ資料や操作マニュアルの作成経験を活かし、自分だけが理解できるシステムではなく、他の人も継続して利用・改善できるよう、目的や背景まで伝わる分かりやすい資料作成を心掛けたいと考えています。
今後の学習や実習では、プログラミングやツール操作の技術だけでなく、利用者の課題を把握し、業務改善につながるシステムを設計・提案できる力を身に付け、将来のDX推進やシステム開発に活かしていきたいです。
