ID:67201さん

## 概要 独立行政法人で長年利用されていた資金運用管理システムについて、新しく購入した債券条件に対応するための機能改修と、既存不具合の調査・改修を担当しました。 対象システムは、購入した債券情報を登録し、利金などを自動計算する業務システムです。 開発当初に想定されていなかった条件の債券を購入したことで、既存の計算ロジックでは正しい計算結果を出せないケースが発生していました。 また、長年改修を重ねてきた古いシステムであったため、債券対応以外にも複数の不具合が存在しており、プログラムの動作を調査しながら、必要な改修を実施しました。 VB.NETは本プロジェクトで初めて触れる言語でしたが、自主的にキャッチアップし、要件定義、設計、改修、テスト、導入まで一貫して対応しました。 ## プロジェクト体制 - PM：1名 - PL：1名 - メンバー：1名 ## 背景・課題 利用部門では、資金運用管理システムを用いて、購入した債券情報の登録や利金計算などを行っていました。 しかし、新たに購入した債券の条件が、既存システムの開発当初に想定されていなかったため、以下のような課題が発生していました。 - 新しい債券条件に既存の計算ロジックが対応できていなかった - 利金などの計算結果に不整合が発生していた - 長年改修を重ねた古いシステムで、既存不具合が複数存在していた - 仕様や処理の全体像が把握しづらく、影響調査が必要だった - 業務で実際に使用しているシステムのため、利用部門の業務を止めずに安全に改修する必要があった - 改修後も、利用者の実作業が大きく変わらないように配慮する必要があった 単にプログラムを修正するだけでなく、債券条件ごとの計算パターンを整理し、業務フローとシステム処理の両面から正しく要件を把握する必要がありました。 ## 担当領域 - 業務システム改修に関する要件定義 - 利用部門へのヒアリング - 業務フローの整理 - システムフローの作成 - 債券条件ごとの計算ロジック整理 - 既存プログラムの調査 - 影響範囲調査 - VB.NETによる改修 - 単体テスト・結合テスト - 導入対応 - プロジェクト進捗管理 ## 実施内容 ### 要件定義・業務フロー整理 まず、利用部門の担当者と綿密に打ち合わせを行い、現在の業務内容、新しく購入した債券の条件、既存システムで発生している不具合内容を確認しました。 ヒアリングでは、利用者の説明をそのままシステム要件に落とし込むのではなく、実際の業務の流れを整理し、業務フローとして可視化しました。 そのうえで、現行業務の進め方をなるべく大きく変えずに、新しい債券条件へ対応できるよう、システムフローを作成しました。 ### 債券条件ごとの計算ロジック整理 債券の条件によって計算方法が異なるため、ロジックツリーを活用し、条件ごとの計算パターンを整理しました。 具体的には、以下の観点で整理しました。 - 債券条件ごとの分岐 - 利金計算に影響する項目 - 既存ロジックで対応できる条件 - 既存ロジックでは対応できない条件 - 改修が必要な計算パターン - 既存処理への影響範囲 これにより、条件漏れや改修漏れが発生しないようにしたうえで、プログラム改修の対象箇所を洗い出しました。 ### 既存システムの調査・不具合改修 対象システムは古く、過去の改修も重ねられていたため、処理全体の見通しが悪い状態でした。 そのため、既存プログラムの動作を一つずつ確認し、どの処理でどの計算が行われているのかを把握しました。 調査では、以下の点を意識しました。 - 画面入力値がどの処理で使用されているか - 計算ロジックがどこに実装されているか - 条件分岐がどのように行われているか - 修正による他機能への影響がないか - 既存不具合の原因がどこにあるか 調査結果をもとに、新しい債券条件に対応できるようVB.NETで改修を実施しました。 ### テスト・導入対応 改修後は、要件定義で整理した条件をもとにテストを実施しました。 債券条件ごとの計算結果が期待通りになるか、既存機能に影響が出ていないかを確認し、利用部門と認識を合わせながら導入まで対応しました。 また、業務で実際に使われるシステムであるため、導入後に利用者が混乱しないよう、現行業務の流れを極力変えない形で改修することを意識しました。 ## 工夫した点 ### 業務フローを整理してからシステムフローに落とし込んだこと 利用部門の要望をそのまま改修内容にするのではなく、まず業務フローを整理し、実際の業務の流れを明確にしました。 そのうえで、利用者の作業をなるべく変えずに済むよう、システム側でどのように対応すべきかを検討しました。 これにより、利用者にとって違和感の少ない改修を行うことができました。 ### ロジックツリーで計算条件を整理したこと 債券の条件によって計算方法が変わるため、条件を頭の中だけで整理すると、改修漏れやテスト漏れが発生するリスクがありました。 そこで、ロジックツリーを使って債券条件ごとの計算分岐を整理し、どの条件にどの計算方法を適用すべきかを明確にしました。 これにより、要件、改修箇所、テスト観点を一貫して整理できました。 ### 古いシステムを慎重に読み解いたこと 対象システムは長年改修されており、既存処理の全体像を把握するのが難しい状態でした。 そのため、プログラムの動きを一つずつ追いながら、どこを修正すればよいか、修正による影響がどこに出るかを慎重に確認しました。 既存仕様を壊さずに新しい条件へ対応することを重視しました。 ### 未経験言語をキャッチアップして対応したこと VB.NETは本プロジェクトで初めて扱う言語でしたが、Visual Studio上で既存ソースを読み解きながら、自主的にキャッチアップしました。 単に文法を学ぶだけでなく、既存業務システムの構造や処理の流れを理解し、実際の改修・テスト・導入まで完遂しました。 ## 成果 - 新しく購入した債券条件に対応するためのシステム改修を実施 - 利金計算などの不整合を解消 - 古い資金運用管理システムの既存不具合を調査・改修 - 利用部門と要件を整理し、業務に合った形で改修を実現 - V字モデルに沿って、要件定義から導入まで一貫して対応 - VB.NET未経験からキャッチアップし、実務での改修を完遂 - 利用部門の担当者から高い評価をいただき、継続して依頼したいとのコメントをいただいた - 自身のキャッチアップ力、既存コード読解力、エラー調査力を向上 ## 使用技術・ツール - VB.NET - Visual Studio - SQL - Windows - 業務システム - Excel ## 役割 業務システム改修担当として、利用部門へのヒアリング、要件定義、業務フロー整理、システムフロー作成、既存プログラム調査、VB.NETでの改修、テスト、導入まで担当しました。 また、小規模体制の中でプロジェクトの進捗管理も担当し、要件整理から導入まで責任を持って推進しました。

## 概要 大手自動車メーカーの各工場を対象に、現場業務のデジタル化推進、デジタル戦略サポート、個別業務の効率化・自動化支援を担当しました。 各工場の業務には、紙、Excel、メール、手作業、既存マクロなどアナログな運用が多く残っており、業務担当者から日々さまざまな困りごとが相談として上がっていました。 それらの課題に対して、業務担当者へのヒアリングを行い、現行業務の流れを整理したうえで、RPA、VBA、Python、PowerAppsなどを活用し、業務に合った解決方法を提案・企画・開発・導入・運用保守まで一貫して対応しました。 ## プロジェクト体制 - PM：1名 - PL：3名 - メンバー：7名 ## 背景・課題 工場業務では、生産管理、品質管理、帳票作成、メール確認、データ変換、情報共有など、さまざまな業務が日々行われています。 一方で、現場には以下のような課題がありました。 - 紙やExcelを前提としたアナログな運用が多い - 業務担当者の手作業に依存している処理が多い - 既存マクロや小規模ツールが属人的に運用されている - システム間のデータ変換や転記に時間がかかっている - 現場ごとに業務ルールや運用方法が異なる - 困りごとはあるが、どの技術で解決すべきか整理されていない - RPA化すべき業務と、アプリ化・マクロ改修・運用見直しで対応すべき業務の切り分けが必要だった そのため、単に依頼された内容をそのまま開発するのではなく、現場業務を理解したうえで、費用対効果、保守性、導入スピードを踏まえた解決策を提案する必要がありました。 ## 担当領域 - 工場業務のデジタル化推進 - デジタル戦略サポート - 業務担当者へのヒアリング - 現行業務フローの整理 - 課題抽出・改善方針の検討 - RPA化要件検討・開発 - 既存ツール・マクロの改修、運用保守 - 個別業務に応じた自動化・アプリ化の提案 - 導入後の運用保守・サポート - 新規技術のキャッチアップと実務適用 ## 実施内容 ### 現場ヒアリングと業務整理 各工場の業務担当者から上がってくる困りごとに対して、まずは実際の業務の流れを把握することを重視しました。 ヒアリング時には、単に「何に困っているか」を聞くだけでなく、以下の観点を確認しました。 - 現在どのような手順で作業しているか - どの作業に時間がかかっているか - どこでミスや手戻りが発生しやすいか - どの作業が定型的で、どの作業に人間の判断が必要か - 既存のExcel、マクロ、システム、メール運用がどのように使われているか - 改善後も現場担当者が無理なく運用できるか 業務の流れを理解したうえで、RPA化、アプリ化、マクロ改修、運用変更など、課題に合った解決策を検討しました。 ### 課題に応じた解決策の提案・実装 業務効率化を進める際は、安易にRPAを導入したり、新規アプリケーションを開発したりするのではなく、保守性、運用負荷、導入スピード、費用対効果を踏まえて手段を選定しました。 特に、現場業務ではスピード感が求められるため、以下のような考え方を意識しました。 - 小さく早く導入できること - 現場担当者が使いやすいこと - 運用保守しやすいこと - 既存業務を大きく崩しすぎないこと - 将来的な改修にも対応しやすいこと 単に技術的に高度なものを作るのではなく、現場にとって「早く、安く、使いやすい」解決策を選ぶことを重視しました。 ### 個別デジタル化案件の対応 主な対応案件は以下です。 #### メール誤送信防止の既存仕組みの改修・運用保守 VBAで構築されていたメール誤送信防止の仕組みについて、既存仕様を確認しながら改修・運用保守を担当しました。 既存運用への影響を抑えつつ、現場で継続利用できるように対応しました。 #### BQN出力データの自動変換アプリの運用・保守・改修 工場で利用しているBQN出力データについて、Pythonで構築された自動変換アプリの運用・保守・改修を担当しました。 出力データの形式や後続業務で必要となる形を確認し、データ変換処理が安定して利用できるように対応しました。 #### スマートフォンを利用した生産管理情報の閲覧アプリ開発 スマートフォンから生産管理情報を閲覧できる仕組みの開発を担当しました。 モバイル側の利用を想定しつつ、PowerApps、PC動作、UiPathによる処理連携を組み合わせ、現場担当者が必要な情報を確認しやすい形を目指しました。 #### その他工場業務のRPA化 各工場の定型作業について、UiPathを用いたRPA化を担当しました。 対象業務ごとに、RPA化が適しているか、既存ツール改修で対応すべきか、運用変更で解決できるかを検討し、現場に合った形で改善を進めました。 ## 工夫した点 ### 業務理解を最優先にしたこと 工場業務は現場ごとに運用や前提条件が異なるため、表面的な困りごとだけを見て開発すると、実際の運用に合わない仕組みになってしまいます。 そのため、まずは現場担当者の作業の流れを丁寧に確認し、業務の目的、例外パターン、運用上の制約を理解することを重視しました。 ### 解決手段を固定しなかったこと 相談内容に対して、最初からRPAやアプリ開発ありきで考えるのではなく、課題に応じて最適な手段を選ぶようにしました。 例えば、既存マクロの改修で十分な場合はVBAで対応し、データ変換が中心であればPython、定型操作の自動化が必要であればUiPath、現場での閲覧性が重要であればPowerAppsを検討しました。 これにより、過剰開発を避けながら、現場にとって実用的な改善を行いました。 ### 未経験技術もキャッチアップして実務適用したこと 本プロジェクトで扱った技術の中には、初めて触れるものも多くありました。 しかし、必要な情報を調査し、既存ソースや運用を読み解きながらキャッチアップし、実際の業務改善に適用しました。 新しい技術を学ぶだけでなく、現場の課題解決に使える状態まで落とし込むことを意識しました。 ### 導入後の運用保守まで責任を持ったこと 開発して終わりではなく、導入後の運用保守や問い合わせ対応も行いました。 現場で継続利用されることを前提に、使いやすさ、エラー時の対応、改修しやすさを意識しながら改善を進めました。 ## 成果 - 大手自動車メーカーの各工場におけるデジタル化推進に貢献 - 現場の困りごとをヒアリングし、業務に合った改善策を提案・導入 - VBA、Python、PowerApps、UiPathなどを活用し、複数の個別デジタル化案件を推進 - メール誤送信防止の既存仕組みの改修・運用保守を実施 - BQN出力データの自動変換アプリの運用・保守・改修を実施 - スマートフォンを利用した生産管理情報閲覧アプリを開発 - 各種工場業務のRPA化を実施 - 業務改善の成果を評価され、組立ライン稼働管理改善プロジェクトの進捗管理を任されるようになった ## 使用技術・ツール - UiPath - PowerApps - Python - VBA - VS Code - Excel - Excelマクロ - MS Project - Windows - Microsoft365 ## 役割 デジタル化推進担当として、工場業務のヒアリング、課題抽出、改善提案、技術選定、開発、導入、運用保守まで一貫して担当しました。 現場業務を理解したうえで、RPA、VBA、Python、PowerAppsなどを使い分け、スピード感と保守性のバランスを取りながら工場業務の効率化を推進しました。

## 概要 工場の組立ラインにおける稼働管理業務について、既存の手作業中心の運用を見直し、データ連携とUiPathによるRPA化を推進しました。 従来は、ライン停止情報が記載されたレシートを1時間に1回手動で印字し、その内容をExcelへ手入力したうえで、マクロを実行して稼働状況を管理していました。 本プロジェクトでは、対象工程のネットワークを他工程のネットワークと接続し、PMSからライン停止情報を取得できる構成へ変更しました。そのうえで、PMSから出力されたデータをInputとしてUiPathで処理し、従来手作業で行っていた印字後の転記・集計・確認作業を自動化しました。 ネットワーク改修は他部署が担当し、私はPLとして全体の進捗管理・部署間調整を行いながら、RPA化の要件検討・開発を担当しました。 本取り組みにより、約8,000時間/年の工数削減に貢献しました。 ## 背景・課題 組立ラインの稼働管理では、現場の停止情報を正確に把握し、稼働状況を管理する必要がありました。 しかし、従来の仕組みは古く、ライン停止情報が記載されたレシートを1時間に1回手動で印字し、Excelへ転記したうえでマクロを実行する運用になっていました。 そのため、以下のような課題がありました。 - ライン停止情報を記載したレシートを1時間に1回手動で印字していた - 印字された情報をExcelへ手入力していた - Excelマクロを手動で実行して稼働状況を管理していた - 転記作業に時間がかかっていた - 手入力によるミスや確認漏れのリスクがあった - 現場担当者の作業負荷が高かった - 関連部署が複数あり、ネットワーク改修、データ取得、RPA化の認識合わせが必要だった 単純にRPAで画面操作を置き換えるだけではなく、ライン停止情報をどのように取得し、どのデータをInputとして扱い、どの範囲を自動化するかを整理する必要がありました。 ## 担当領域 - PLとしての進捗管理 - MS Projectを用いたスケジュール・タスク管理 - 関連部署との調整 - RPA化対象業務の整理 - UiPathによる自動化要件検討 - UiPathでのRPA開発 - PMS出力データをInputとした処理設計 - 課題発生時の部署間調整 - マイルストーン遅延を防ぐための進捗コントロール - テスト・運用引き継ぎ ## 実施内容 ### 現行業務の整理 まず、現場で行われていた稼働管理業務の流れを整理しました。 従来は、ライン停止情報のレシート印字、Excelへの手入力、マクロ実行という流れで管理していたため、それぞれの作業がどのタイミングで発生しているか、どの情報が必要か、どの部分を自動化できるかを確認しました。 手入力していた情報をPMSから取得できるようにすることで、手作業を削減できる見込みがあったため、ネットワーク改修後のデータ取得フローを前提にRPA化の要件を整理しました。 ### データ連携を前提としたRPA化 対象工程のネットワークを他工程のネットワークと接続し、PMSからライン停止情報を取得できる構成へ変更しました。 そのうえで、PMSから出力されたデータをInputとしてUiPathで処理し、従来Excel上で行っていた作業を自動化しました。 RPA化では、以下の観点を意識しました。 - PMSから出力されるデータ形式の確認 - RPAで処理しやすいInput設計 - 既存Excel・マクロ運用との接続 - 手入力作業の削減 - 処理エラー時の確認方法 - 現場担当者が運用しやすい処理フロー ### PLとしての進捗管理 本プロジェクトでは、ネットワーク改修、PMSからのデータ取得、RPA化といった複数領域が関係していました。 ネットワーク周りの改修は他部署が担当していたため、私はPLとして全体の進捗を管理し、各部署がいつまでに何を対応する必要があるかを明確にしました。 MS Projectを用いてタスクやマイルストーンを管理し、部分的な遅れが発生した場合でも、最終的なマイルストーンに影響が出ないように調整しました。 ### 部署間コミュニケーションの調整 関連部署が複数あったため、各部署間で認識のずれが発生しないよう、中間的な立ち位置でコミュニケーションを取りました。 具体的には、以下の点を明確にしました。 - 各部署の担当範囲 - 必要な作業内容 - 期限 - 依存関係 - 判断が必要な事項 - 課題発生時の対応方針 問題が発生した場合は、関係部署と早期に連携し、原因確認や対応方針のすり合わせを行うことで、プロジェクト全体への影響を最小限に抑えました。 ## 工夫した点 ### RPA化だけでなく、業務フロー全体を見直したこと 単に既存作業をUiPathで置き換えるのではなく、現行のレシート印字、Excel手入力、マクロ実行という流れそのものを見直しました。 PMSからデータを取得できるようにすることで、手作業を減らし、より機械的に処理できる業務フローへ改善しました。 ### 部署間の認識ずれを防ぐ進め方をしたこと ネットワーク改修、PMS、RPA開発と複数部署が関係していたため、各部署の認識が少しずれるだけでも後続タスクに影響が出る可能性がありました。 そのため、各部署が「いつまでに」「何を」「どの状態まで」対応する必要があるのかを明確にし、認識齟齬が起きないように調整しました。 ### マイルストーンを意識した進捗管理 個別タスクでは一部遅れが発生することもありましたが、プロジェクト全体のマイルストーンに影響が出ないよう、タスクの優先順位や対応順序を調整しました。 単に進捗を確認するだけでなく、遅れが発生した場合のリカバリー方針を意識して管理しました。 ### 現場が運用しやすい自動化を意識したこと 製造現場で継続利用される仕組みのため、RPA化後も現場担当者が結果を確認しやすく、異常時に対応しやすいことを重視しました。 処理対象データ、出力結果、エラー時の確認ポイントを整理し、運用に乗せやすい形で自動化しました。 ## 成果 - 組立ラインの稼働管理業務をデータ連携・RPA化 - 1時間ごとのレシート印字後の手入力・集計作業を削減 - PMS出力データをInputとしたUiPath処理を構築 - 手入力による転記ミス・確認漏れリスクを低減 - 複数部署が関係するプロジェクトをPLとして推進 - MS Projectを用いてスケジュール・タスク・マイルストーンを管理 - 当初予定に沿ってプロジェクトを完了 - 約8,000時間/年の工数削減に貢献 ## 使用技術・ツール - UiPath - MS Project - Excel - Excelマクロ - Windows ## 役割 PLとして、プロジェクト全体の進捗管理、関連部署との調整、タスク・マイルストーン管理を担当しました。 また、RPA化担当として、UiPathを用いた自動化要件の検討、設計、開発を担当しました。 複数部署が関係するプロジェクトにおいて、部署間の認識ずれを防ぎながら、製造現場の手作業削減と業務フロー改善を推進しました。

## 概要 不動産管理業務における長期修繕計画の作成業務について、UiPathを活用した業務自動化・標準化を担当しました。 これまで担当者の経験や判断に依存していた長期修繕対象工事の抽出作業を整理し、機械的に判定・抽出できる業務フローへ改善しました。 また、長期修繕計画の作成に必要な見積情報の収集、必要書類の確認、不足見積がある場合のユーザー連絡までを自動化し、部門全体で約13,000時間/年の工数削減に貢献しました。 ## 背景・課題 長期修繕計画の作成業務では、物件情報、修繕履歴、工事項目、見積情報など、複数の情報をもとに対象工事を判断する必要がありました。 しかし、従来は担当者ごとの経験や判断に依存している部分が多く、以下のような課題がありました。 - 長期修繕対象工事の抽出基準が属人化していた - 対象工事の判断に時間がかかっていた - 必要な見積情報の確認・収集に手作業が多かった - 見積不足時のユーザー連絡が手作業で発生していた - 作業量が多く、担当者の負荷が高かった - 確認漏れや連絡漏れが発生するリスクがあった 特に、長期修繕計画は物件ごとの将来費用や修繕時期に関わるため、単に作業を早くするだけでなく、判断基準を整理し、安定して処理できる仕組みにする必要がありました。 ## 担当領域 - 現行業務フローの整理 - 長期修繕対象工事の抽出条件整理 - 属人化していた判断基準の標準化 - UiPathによる自動化設計・実装 - 見積情報収集フローの自動化 - 不足見積の判定ロジック設計 - ユーザーへの連絡処理自動化 - テスト・運用確認 - 業務担当者向けの運用整理 ## 実施内容 ### 長期修繕対象工事の抽出基準整理 まず、担当者の経験に依存していた長期修繕対象工事の抽出作業について、判断に必要な条件を整理しました。 どの情報をもとに対象工事と判断しているのか、どの条件で除外しているのか、例外的な確認が必要なケースは何かを洗い出し、機械的に判定できる形へ落とし込みました。 これにより、人によって判断がばらつきやすかった作業を、一定の条件に基づいて処理できる状態に改善しました。 ### UiPathによる対象工事抽出の自動化 整理した抽出条件をもとに、UiPathで長期修繕対象工事の抽出処理を自動化しました。 自動化では、単に画面操作やExcel操作を置き換えるのではなく、以下の観点を意識しました。 - 判定条件を後から見直しやすい構成にする - 例外ケースを確認しやすくする - 処理結果を業務担当者が確認できる形で出力する - エラー発生時に原因を追いやすくする - 手作業での確認・修正が必要な箇所を明確にする ### 必要見積の収集自動化 長期修繕計画の作成に必要な見積情報について、必要な見積が揃っているかを確認し、収集状況を自動で判定する仕組みを整備しました。 これにより、担当者が目視で確認していた見積収集状況の確認作業を削減しました。 ### 不足見積の連絡自動化 必要な見積が不足している場合には、対象ユーザーへ連絡する作業も自動化しました。 不足している見積内容を判定し、ユーザーに対して必要な情報を連絡することで、確認漏れや連絡漏れのリスクを低減しました。 ## 工夫した点 ### 属人化していた判断を機械的に処理できる形へ整理したこと 本プロジェクトでは、RPA化そのものよりも、属人化していた業務判断をどのように整理し、機械的に処理できる条件へ落とし込むかが重要でした。 担当者の暗黙知をそのまま自動化するのではなく、判断条件、例外条件、確認が必要なケースを整理したうえで、UiPathで処理できる形に設計しました。 ### 自動化対象を作業単位ではなく業務フロー全体で捉えたこと 単一作業の自動化に留めず、対象工事の抽出、必要見積の確認、不足見積の判定、ユーザー連絡までを一連の業務フローとして捉えました。 これにより、局所的な効率化ではなく、長期修繕計画作成業務全体の負荷軽減につなげました。 ### 運用しやすさを重視したこと 自動化後も業務担当者が確認・運用しやすいように、処理結果やエラー内容が分かる構成を意識しました。 また、すべてをブラックボックス化するのではなく、人間が確認すべきポイントを残しながら、定型的な確認・連絡作業を自動化しました。 ## 成果 - 属人化していた長期修繕対象工事の抽出作業を標準化 - 対象工事を機械的に抽出できる業務フローへ改善 - 必要見積の収集状況確認を自動化 - 不足見積がある場合のユーザー連絡を自動化 - 確認漏れ・連絡漏れのリスクを低減 - 部門全体で約13,000時間/年の工数削減に貢献 ## 使用技術・ツール - UiPath - Excel - Windows - 業務システム ## 役割 業務改善・RPA開発担当として、現行業務の整理、課題抽出、抽出条件の標準化、UiPathでの自動化設計・実装、テスト、運用整理まで担当しました。 単に手作業をRPAに置き換えるのではなく、属人化していた判断業務を整理し、再現性のある業務フローとして仕組み化した点を重視しました。

## 概要 紙ベースで運用されていた経理業務に対して、kintoneを用いた業務アプリケーションを新規開発・導入し、請求書のスキャン、情報抽出、データ登録、関連情報の引き込み、承認フローまでを電子化・自動化しました。 従来はkintoneやOCRなどの仕組みはなく、紙の請求書をもとに担当者が内容確認、転記、照合、承認依頼を手作業で行っていました。 本プロジェクトでは、kintoneを経理業務のデータ管理・承認基盤として新たに構築し、UiPath、AzureOpenAI、AzureAI Document Intelligence、AzureAI Searchを組み合わせることで、紙中心だった業務をデジタル前提の業務フローへ移行しました。 また、OCR結果の揺らぎによって発生するキー不一致の問題に対して、AzureOpenAIとレーベンシュタイン距離による類似度計算を組み合わせ、表記揺れに強い照合ロジックを構築しました。 本取り組みにより、部門全体で約5,600時間/年の工数削減に貢献しました。 ## 背景・課題 経理業務は、紙の請求書を中心に運用されており、請求書の確認、必要情報の転記、既存情報との照合、承認依頼、保管までを人手で行っていました。 当時はkintoneのような業務アプリケーションや、OCRによる読み取りの仕組みは導入されておらず、紙書類と手作業を前提とした業務フローになっていました。 そのため、以下のような課題がありました。 - 請求書の内容確認が紙ベースで行われていた - 請求書情報の転記や登録が手作業だった - 承認依頼や確認状況の管理が属人化しやすかった - 紙書類の回付、保管、確認に時間がかかっていた - 入力ミス、確認漏れ、転記漏れのリスクがあった - 月次処理時に作業が集中し、経理担当者の負荷が高かった - データとして蓄積・検索・再利用しにくい状態だった 単に一部の作業をRPA化するだけではなく、紙を前提とした業務そのものを見直し、データを中心に処理できる業務基盤を構築する必要がありました。 ## 担当領域 - 紙ベース経理業務の業務フロー整理 - 電子化後の業務フロー設計 - kintoneアプリの新規開発・導入 - kintone上でのデータ管理・承認フロー設計 - UiPathによる自動化設計・実装 - AzureAI Document Intelligenceによる請求書情報抽出 - AzureOpenAIを活用したOCR結果の補正・判定 - AzureAI Searchを活用した関連情報の検索・引き込み - レーベンシュタイン距離による類似度判定ロジックの検討 - 請求書スキャンからkintone登録までの自動化 - テスト・運用整理 ## 実施内容 ### 紙ベース業務の可視化 まず、紙で運用されていた経理業務について、請求書の受領、内容確認、転記、照合、承認、保管までの流れを整理しました。 どの情報を請求書から読み取っているのか、どの情報と照合しているのか、どのタイミングで承認が必要になるのかを洗い出し、電子化後の業務フローを設計しました。 単に現行作業をそのままシステム化するのではなく、紙であることを前提に発生していた作業を見直し、データとして扱うべき情報、承認時に必要な情報、人間が確認すべき情報を整理しました。 ### kintoneアプリの新規開発・導入 紙運用から電子運用へ移行するため、kintoneを用いて経理業務用のアプリケーションを新規に開発・導入しました。 kintone上では、請求書情報、関連情報、承認状況、処理ステータスを管理できるようにし、紙の回付に依存していた業務をデータ中心の運用へ変更しました。 主に以下の観点で設計しました。 - 請求書情報の登録項目 - 関連情報との紐づけ - 処理ステータス管理 - 承認フロー - 確認が必要なデータの見える化 - 後続業務で利用しやすい項目設計 ### 請求書スキャンからkintone登録までの自動化 請求書をスキャンした後、AzureAI Document Intelligenceで請求書情報を抽出し、UiPathを用いてkintoneへの登録処理を自動化しました。 対象とした主な処理は以下です。 - 請求書ファイルの取得 - OCRによる請求書情報の抽出 - 抽出結果の整形 - kintoneへのデータ登録 - 関連情報の引き込み - 登録結果の確認 - エラー時の通知・確認 これにより、従来は人手で行っていた請求書内容の確認、転記、登録作業を大幅に削減しました。 ### OCR揺らぎによるキー不一致の解消 OCR結果には、取引先名、請求項目、管理番号などの表記揺れや読み取り揺らぎが発生するため、単純な完全一致では既存データと紐づけられないケースがありました。 この課題に対して、AzureOpenAIによる文脈理解と、レーベンシュタイン距離による文字列類似度計算を組み合わせ、OCR結果と業務データの照合精度を高めました。 具体的には、以下のような観点で照合しました。 - 完全一致しない文字列の類似度判定 - OCR誤読が発生しやすい文字列の補正 - 取引先名や項目名の表記揺れ吸収 - 類似候補が複数ある場合の確認フロー - 自動判定してよいケースと人間確認が必要なケースの切り分け OCRを導入するだけでは解決できない、実務上のデータ照合問題に対して、AIと文字列類似度計算を組み合わせて対応しました。 ### AzureAI Searchを活用した関連情報の引き込み 請求書から抽出した情報をもとに、AzureAI Searchを活用して関連情報を検索・参照し、kintone登録時に必要な情報を引き込めるようにしました。 これにより、担当者が手作業で確認・検索していた関連情報の取得を効率化しました。 ### 承認フローの整備 kintone上で承認フローを整備し、紙の回付に依存していた承認業務を電子化しました。 登録された請求書情報をもとに、承認状況や処理ステータスを管理できるようにすることで、確認漏れや対応状況の不透明さを減らしました。 ## 工夫した点 ### 紙運用をそのまま置き換えず、業務基盤として再設計したこと 本プロジェクトでは、既存システムへの自動登録ではなく、紙で運用されていた業務に対してkintoneアプリを新規に開発・導入しました。 そのため、単に作業を自動化するだけでなく、請求書情報をどのようなデータ構造で持つべきか、承認フローをどう設計するか、後続業務でどのように利用するかまで含めて設計しました。 ### OCR導入だけで終わらせなかったこと 紙書類の電子化では、OCRを導入するだけでは実務に耐えないケースがあります。 特に請求書は、取引先ごとにフォーマットが異なり、読み取り結果の揺らぎや表記揺れが発生します。 そのため、AzureOpenAIとレーベンシュタイン距離を組み合わせ、OCR結果を業務データと照合できる形に補正・判定する仕組みを構築しました。 ### AIとルールベース処理を組み合わせたこと すべてをAIに任せるのではなく、AIが得意な文脈判断と、レーベンシュタイン距離による機械的な文字列比較を組み合わせました。 これにより、柔軟性と説明可能性のバランスを取りながら、経理業務で利用できる照合処理を目指しました。 ### 人間確認が必要なケースを残したこと 経理業務では正確性が重要なため、OCRやAIの結果をすべて自動確定するのではなく、判定が難しいケースや類似候補が複数あるケースでは、人間が確認できるようにしました。 自動化範囲と人間確認範囲を切り分けることで、効率化と品質担保を両立しました。 ## 成果 - 紙ベースで運用されていた経理業務を電子化 - kintoneアプリを新規開発・導入し、経理業務のデータ管理基盤を構築 - 請求書スキャンからkintone登録までを自動化 - AzureAI Document Intelligenceを活用した請求書情報抽出を実現 - AzureOpenAIとレーベンシュタイン距離によりOCR揺らぎによるキー不一致を解消 - AzureAI Searchを活用し、関連情報の検索・引き込みを効率化 - kintone上で承認フローを整備 - 手作業による転記・確認・登録作業を削減 - 部門全体で約5,600時間/年の工数削減に貢献 ## 使用技術・ツール - UiPath - kintone - AzureOpenAI - AzureAI Document Intelligence - AzureAI Search - レーベンシュタイン距離 - OCR - Windows - Excel ## 役割 業務改善・自動化担当として、紙ベースの経理業務の整理、電子化後の業務フロー設計、kintoneアプリの新規開発・導入、UiPathによる自動化、AI-OCR活用、照合ロジック検討、承認フロー整備まで担当しました。 既存システムの一部自動化ではなく、紙運用だった経理業務に対して、データ管理基盤、AI-OCR、RPA、検索、承認フローを組み合わせ、業務全体を電子化・自動化した点を重視しました。

## 概要 個人開発として、OpenAI Codex CLIやローカルLLMを活用したAIマルチエージェント型の開発支援基盤を設計・実装しました。 複数のAIエージェントに役割を分担させ、要件整理、調査、実装、テストを並行・分担して進められる仕組みを構築しました。 業務でのAI駆動開発の知見を深めるため、単なるツール利用ではなく、AIを活用した開発プロセスそのものを自作・検証しています。 ## 背景・課題 AIコーディング支援ツールは便利な一方で、長時間の開発では以下の課題がありました。 - 会話履歴が長くなると意図がぼやける - 調査、実装、テストの責務が混在しやすい - AIの出力品質がプロンプトに大きく依存する - トークン消費やコストが増えやすい - ローカル環境で安全に検証したいケースがある これらを解決するため、AIエージェントの役割分担、実行履歴の管理、ローカルLLMの活用、Windows環境での実行支援を組み合わせた開発基盤を構築しました。 ## 担当領域 個人開発のため、企画、設計、実装、検証、改善をすべて担当しました。 - AIマルチエージェント構成の設計 - 親エージェント、調査エージェント、実装エージェント、テストエージェントの役割設計 - Windows環境での起動・運用改善 - ローカルLLM連携の検証 - 実行履歴、セッション、指示ファイルの管理 - 失敗時の復旧フロー設計 - プロンプト最適化 - トークン消費削減の検討 ## 実施内容 ### マルチエージェント構成の設計 以下のように役割を分けた構成を設計しました。 - Parent：全体方針の管理、タスク分解、進行制御 - Research：技術調査、仕様確認 - Implement：実装 - Test：動作確認、テスト、問題指摘 これにより、1つのAIにすべてを任せるのではなく、工程ごとに責務を分けて開発を進める形にしました。 ### Windows環境での実行改善 Windows上で複数エージェントを扱いやすくするため、複数ウィンドウ起動、実行状態の確認、停止・再開フロー、ログ確認の仕組みを整備しました。 また、長時間実行時に発生しやすいセッション管理、トークン消費、停止条件の扱いについても改善しました。 ### ローカルLLM活用 実装やテストの一部をローカルLLMに切り替えられるようにし、クラウドAIの利用量を抑えながら開発を進められる構成を検証しました。 LM StudioやOllamaなどのOpenAI互換APIを活用し、用途に応じてクラウドAIとローカルLLMを使い分ける構成を試しました。 ### プロンプトと開発標準の整備 AIに対して一貫した品質で作業させるため、開発ルール、設計方針、実装制約、テスト方針をプロンプトとして整備しました。 特に、英語プロンプトによるトークン削減、実装対象の明確化、不要な再調査の抑制、ファイル変更範囲の制限などを工夫しました。 ## 工夫した点 ### AIの役割を分けたこと 1つのAIに調査から実装、テストまで任せると、方針がぶれたり、検証が甘くなったりすることがあります。 そこで、各エージェントの役割を明確にし、人間の開発チームに近い形でタスクを分担させる構成にしました。 ### コストと品質のバランスを取ったこと すべてを高性能なクラウドAIに任せるのではなく、実装やテストの一部をローカルLLMで処理できるようにすることで、コスト削減と開発継続性の両立を狙いました。 ### 実務に応用できる形を意識したこと 個人開発ではありますが、業務でAI駆動開発を導入する際に必要になる、標準化、レビュー、実行管理、再現性、保守性を意識して設計しました。 ## 成果 - AIマルチエージェント型の開発支援基盤を構築 - 調査、実装、テストを分担する開発フローを実現 - Windows環境での実行・運用改善を実施 - ローカルLLMを活用したコスト削減の可能性を検証 - AI駆動開発を実務に応用するための知見を獲得 ## 使用技術・ツール - Node.js - TypeScript - OpenAI Codex CLI - Claude Code - LM Studio - Ollama - Git - GitHub - PowerShell - Windows - ローカルLLM ## 役割 個人開発者として、企画、設計、実装、検証、改善をすべて担当しました。 業務改善エンジニアとしての実務経験を活かし、AIを使った開発を一過性の効率化ではなく、再現性のある開発プロセスとして扱うことを意識しました。

## 概要 現在、社内の業務改善・DX推進を目的として、AI駆動開発を活用した業務アプリケーション開発の標準化と、スクラッチ開発の推進に取り組んでいます。 従来のRPAやローコードツールによる業務自動化に加えて、Next.jsやTypeScriptなどを用いたWebアプリケーション開発も選択肢に入れ、業務課題に応じて最適な解決方法を選べる体制づくりを進めています。 また、AIツールを単なるコード生成補助として使うのではなく、要件整理、設計、実装、レビュー、ドキュメント整備まで含めた開発プロセス全体に組み込み、再現性のある開発手法として整備することを目指しています。 ## 背景・課題 これまでの業務改善では、UiPathやPower Automateを中心としたRPA・自動化の活用が主でした。 一方で、業務要件が複雑化するにつれて、RPAだけでは対応しづらいケースや、個別業務に合わせたWebアプリケーションとして構築した方が保守性・拡張性の面で適しているケースも増えてきました。 また、AIツールを開発に取り入れるうえでは、個人ごとの使い方に依存しやすく、以下のような課題があると感じています。 - 要件の渡し方によってAIの出力品質が大きく変わる - AIが生成したコードのレビュー観点が属人化しやすい - 設計方針や実装ルールが曖昧なままだと、保守しにくいコードになりやすい - AI活用が個人の作業効率化に留まり、チームの開発プロセスとして定着しにくい - 生成された成果物の品質をどう担保するかが課題になる そのため、AIを「便利な補助ツール」として使うだけでなく、開発標準や設計ルールと組み合わせ、チームで再利用できる形に整備する必要があると考えました。 ## 担当領域 主担当として、以下の領域を中心に推進しています。 - AI駆動開発の進め方の検討 - 業務アプリケーション開発における標準化方針の整理 - 要件定義、設計、実装、レビューの進め方の検討 - Next.js / TypeScriptを用いたスクラッチ開発の検証・推進 - GitHubを活用したソース管理・開発フローの整備 - README、環境構築手順、開発ルールの整備 - AIツールの活用方法の検証 - チーム内へのナレッジ共有 ## 現在取り組んでいる内容 ### AI駆動開発プロセスの整理 AIツールを場当たり的に利用するのではなく、開発工程ごとにどのように活用するかを整理しています。 具体的には、以下のような観点で検討しています。 - 要件定義時にAIへ渡す情報の整理方法 - 設計前に明確化すべき制約条件 - 実装前に作成すべき設計メモの粒度 - AIに任せる作業と人間が判断する作業の切り分け - AI生成コードのレビュー観点 - エラー調査やリファクタリングでのAI活用方法 - READMEや手順書の自動生成・整備方法 特に、AIにいきなりコードを書かせるのではなく、業務要件、設計意図、責務分割、制約条件を明示したうえで実装させることを重視しています。 ### スクラッチ開発への適用 業務改善の手段として、RPAやPower Automateだけでなく、Webアプリケーション開発も選択肢に入れています。 現在は、Next.js、TypeScript、GitHub、VS Codeなどを活用しながら、業務アプリケーション開発に必要な構成や開発ルールを検証しています。 検討・整備している内容は以下です。 - フロントエンド構成 - 認証・権限管理の考え方 - Dataverseなど外部データソースとの連携方針 - APIルートの責務分割 - ログ出力・監視の考え方 - 環境変数やシークレット管理 - README、.env.example、.gitignoreなどの標準整備 - 開発者が再現しやすい環境構築手順 ### 開発標準の整備 今後、AI駆動開発をチームで活用しやすくするため、開発標準の整備を進めています。 単に「AIを使って早く作る」のではなく、以下の観点を重視しています。 - 保守しやすいフォルダ構成 - 命名ルール - 責務分割 - エラー処理 - ログ設計 - セキュリティ観点 - レビュー観点 - ドキュメント整備 - 他メンバーが引き継ぎやすい構成 AIを活用するからこそ、設計やレビューの基準を明確にし、人間が品質を担保できる状態を目指しています。 ## 工夫している点 ### 業務改善の視点を起点にしていること 開発技術の検証だけでなく、現場業務の課題をどう解決するかを起点に考えています。 これまでUiPathやPower Automateを用いた業務自動化に携わってきた経験を活かし、業務フロー、例外パターン、運用負荷、保守性を踏まえたうえで、RPA・ローコード・Webアプリ開発の中から適切な手段を選べるようにすることを意識しています。 ### AIに任せる範囲を明確にしていること AIには、実装案の作成、リファクタリング、エラー調査、ドキュメント作成、設計案の壁打ちなどを任せています。 一方で、業務要件の解釈、設計判断、品質基準、リリース可否の判断は人間側が責任を持つようにしています。 これにより、AIのスピードを活かしながらも、業務システムとして必要な品質を担保できる進め方を検討しています。 ### 開発プロセス自体を資産化しようとしていること アプリケーションを作るだけでなく、プロンプト、設計メモ、開発ルール、README、レビュー観点なども含めて資産化することを意識しています。 これにより、次回以降の開発でも同じ進め方を再利用でき、個人のスキルや経験に依存しすぎない開発体制につなげたいと考えています。 ## 現時点での成果・進捗 - AI駆動開発を業務アプリケーション開発に適用する方針を整理中 - Next.js / TypeScriptを用いたスクラッチ開発環境を検証中 - GitHubを活用した開発フローを整備中 - README、環境構築手順、開発ルールの標準化を推進中 - AIツールを活用した設計・実装・レビューの進め方を検証中 - RPA中心の業務改善から、Webアプリ開発も含めた改善提案へ領域を拡張中 ## 使用技術・ツール - Next.js - TypeScript - GitHub - VS Code - Claude Code - UiPath - Dataverse - Azure App Service - Application Insights - Microsoft Entra ID ## 役割 主担当として、AI駆動開発の進め方の検討、開発標準の整備、スクラッチ開発の検証、実装方針の整理、ナレッジ共有を推進しています。 これまでのRPA・業務改善経験を活かしながら、AIを活用した開発を個人の作業効率化に留めず、チームや組織で再利用できる開発プロセスとして定着させることを目指しています。