データ設計を起点に考えるアプリ開発―実践を通して見えた課題と成長―

こんにちは！
iUから実習に参加している権藤有作です。

今週は大きくわけて2つの業務に取り組みました。

1つ目は、SharePointを用いた社内ポータル構築および観戦メモのデータ設計ワークです。
2つ目は、Power Appsを用いた備品管理アプリの開発です。

今週の業務内容

①取り組み内容
本業務では、SharePointを用いて社内ポータルの構築を実施しました。ポータル内の情報は「ニュース」「申請」「ツール」といったカテゴリごとに整理し、利用者が迷わず目的の情報にたどり着けるよう導線を意識した構成を検討しました。

また、ワールドカップの観戦メモアプリのデータ設計においては、チーム情報や試合情報など記録すべき項目の整理を行いました。その際、単に項目を並べるのではなく、実際の利用シーンを想定し、「後から見返して活用できる情報とは何か」という視点で設計を行いました。

②業務を通じての気づき
本業務を通じて、ポータルは機能の羅列ではなく、「利用者が迷わず使える構造」を設計することが最も重要であると学びました。また、データ設計は単なる項目整理ではなく、「業務の本質理解」に基づいて行う必要があると理解しました。

当初は項目を網羅的に用意すれば十分だと考えていましたが、「利用目的を軸に設計する」という視点が不足していたことに気づきました。その結果、自身の課題として「全体像の理解不足」と「設計粒度の甘さ」があると認識しました。

①取り組み内容
本業務では、SharePointリストをもとにPower Appsで備品管理アプリの作成を行いました。具体的には、備品一覧表示、予約機能（開始・終了時間設定）、重複チェック機能、キャンセル機能の実装に取り組みました。

また、時間管理のロジックにおいては、変数（varNow）やSwitch関数を用いて処理を構築しました。しかし、実装を進める中で試行錯誤が必要となり、結果として時間内にすべての機能を完成させることはできませんでした。

②業務を通じての気づき
本業務を通じて、アプリ開発はUIの構築ではなく、「データ設計と業務ロジック」が基盤であることを理解しました。また、OnSelectやDefaultといった各設定は相互に影響し合うため、一箇所のミスが全体の動作に影響することを実感しました。

さらに、エラー対応においては、「どこで・何が・なぜ起きているのか」を切り分けて考えることの重要性を学びました。一方で、自力で解決しようとする意識が強くなりすぎた結果、時間を浪費する場面もあり、効率面での課題が明確になりました。

これらを踏まえ、本質的な課題は「時間管理」と「適切な切り替え判断」であると認識しました。

今回の取り組みを通じて、データ設計は「業務理解 → 項目設計 → システム化」という流れで考える必要があることを学びました。業務の全体像を把握した上で必要な情報を整理し、それをシステムへ落とし込むことが重要であると実感しました。

また、アプリは単なる入力ツールではなく、「業務プロセスを再現し、最適化するもの」であるという認識を持つことができました。さらに、限られた時間の中で成果を上げるためには、「すべてを実装する」のではなく「重要な要件を見極めること」が重要であると理解しました。

加えて、エラーは単なる障害ではなく、構造理解を深めるためのヒントであると捉えられるようになりました。

今後は、作業前に「目的 → 全体像 → 詳細」の順で整理する習慣を徹底し、効率的に業務を進めていきます。また、「一定時間で解決できなければ質問する」という基準を設け、時間の使い方を改善していきます。

さらに、設計段階では「利用者視点」と「業務フロー」を必ず言語化し、実際の利用シーンを具体的にイメージしながら設計を行います。エラー発生時には、「画面・コントロール・式」の3点から原因を切り分け、論理的に解決を図ります。

今後も要件整理や設計フェーズにおいて価値を発揮できるよう、本実習で得た知見を継続的に活かしていきたいと考えています。