はじめに
こんにちは。
今回はプリザンター（Pleasanter）を利用して請求書を発行するシステムを開発した際の記録をまとめます。
本システムでは、JavaScript と Python を中心に使用し、プリザンター上の請求データから Excel フォーマットに沿った請求書ファイルを自動生成する仕組み を実装しました。
開発を通じて、プリザンターの
- できること
- できないこと
- 使ううえでつまずきやすいポイント
上記を理解する良い機会にもなりました。
アプリ作成の背景と理由
これまでは市販の会計ソフトを利用して請求書を作成していましたが、いくつか課題がありました。
- ランニングコストに見合う成果が得られていない
- カスタマイズ性が低く、自社業務にフィットさせるのが難しい
請求書作成は業務上なくせない作業であり、継続して利用する機能であるにも関わらず、
「固定費が積み上がるわりに柔軟性が低い」という問題がありました。
世の中には請求書発行ツールが多数ありますが、
- できるだけ固定費を抑えたい
- 自社独自の業務フローに合わせてカスタマイズしたい
- 拡張性・汎用性の高い仕組みにしておきたい
という狙いから、今回のプロジェクトが立ち上がりました。
プリザンターを採用した理由
今回のシステム構築では、業務データの管理基盤として プリザンター（Pleasanter） を採用しました。
プリザンターを選んだ大きな理由は、以下のような特長があったためです。
-
無料で使える範囲が広い
基本的な機能は無償で利用でき、小規模〜中規模の業務アプリであれば追加コストなしで十分実用に耐えます。
-
DB設計なしでもカテゴリ分けされたデータ構造を利用できる
テーブル定義を一から作らなくても、項目追加や分類設定だけで業務データの管理が可能です。
「最低限の設計でも使える」点は、開発の初動スピードを大幅に上げてくれました。
-
UIをゼロから作る必要がなく、しかもカスタマイズしやすい
既存の画面がそのまま使えるため、UI デザインに時間をかける必要がありません。
それでいて、視認性の調整や入力項目の追加など、現場に合わせたチューニングも柔軟に行えます。
これらの理由から、プリザンターは『スモールスタートしつつ、必要に応じて拡張したい』という今回の要件にうまくフィットしました。
どのように作ったか（開発プロセス）
本システムの開発では、プリザンターの特性を理解しながら、どの部分を自分たちで実装すべきかを整理するところから始めました。
具体的には、次のようなステップで進めています。
● 1. 要件確認
最初に、実務担当者へのヒアリングを行い、
- 必ず満たすべき要件（Must）
-
実際の業務フロー
を詳細に確認しました。
ここで現場の「本当に必要な機能」を切り出すことで、後の設計ブレを防ぎました。
● 2. システムフローの作成
次に、全体の処理フローを図として整理し、
プリザンターが担当する範囲 と 外部システム（AWS・スクリプトなど）が担当する範囲 を明確に切り分けました。
これにより、どこをプリザンターに任せて、どこを自前開発するのかが明確になり、実装方針が固まりました。
● 3. プリザンターとの API 連携の可否を検討
次に着手したのが、プリザンターと外部システムをどのように連携させるかの検討です。
プリザンターは REST API を提供していますが、すべての処理が API で完結できるわけではありません。
そのため、
- どの情報を API で取得・更新できるか
- どのタイミングで API を呼び出せるか
- 外部サービス（今回は AWS）との連携が技術的に実現可能か
上記の観点で、API仕様を一つずつ確認しながら進めました。
特に今回は、
「プリザンター側でデータを管理しつつ、必要なタイミングで API を使って AWS へ渡す」
という構成を取りたかったため、API がどこまで業務フローに適用できるかを慎重に見極める必要がありました。
この検討を通じて、
- API で取得できるデータの範囲
- カラム名や内部構造の仕様
- 呼び出し可能なタイミング
などの理解が深まり、後工程の設計がスムーズになりました。
アプリで実現したこと（概要）
プリザンターに請求データ入力
↓
AWS API Gateway
↓
AWS Lambda
↓
S3 にテンプレート格納
↓
Excel ファイルを自動生成
↓
請求ファイルのDL
プリザンター側で入力した請求情報を AWS に送信し、Lambda で Excel を生成する仕組みです。
これにより 手作業の Excel 請求書作成をゼロにすることができ、業務の属人化も大きく軽減されました。
ホーム画面
開発フロー自体はとてもシンプルだったが…
今回構築した請求書発行システムのフロー自体は、非常にシンプルです。
- 請求情報をプリザンターに登録する
- 登録された情報をもとに請求書（Excel）を作成する
- 生成された請求書をダウンロードする
- 請求書に紐づく後続タスク（送付状況・入金管理など）を管理する
工程だけを見ると、ごく基本的なワークフローに見えます。
しかし、実際に開発をスタートしてみると、
「プリザンターというツール特有の癖」 にいくつもぶつかりました。
特に大きかったのは、
- プリザンターは“言語でゴリゴリ書く”よりも ツール自体への理解が重要
- UI上の項目名と内部的なカラム名が違う
- API が触れる範囲・触れない範囲を正しく把握しないと詰まる
- 画面設計は不要だが、逆にプリザンターの思想に合わせる必要がある
といった点でした。
フローは単純でも、
ツールの構造理解が浅いまま進めると確実にハマる
ということを痛感した場面が多々ありました。
解決策として有効だったこと
プリザンター特有の癖に苦労する場面も多かったのですが、いくつか有効だった対処法があります。
● Webに情報が多く、“ノート”形式の記事が非常に役立った
プリザンターはユーザーコミュニティが活発で、
公式マニュアルよりも ブログ記事・Qiita・noteの方が具体例つきでわかりやすいことが多いです。
特に私は視覚優位なタイプなので、
「画面キャプチャつき」「実例ベース」の解説が非常に理解しやすく、問題解決のスピードが大きく向上しました。
● 元々動いているツールなので、デバッグ（UT）がしやすい
プリザンターは初期状態でも一通り動作するため、
“ゼロから作るアプリ”と違って、動いている実体を触りながら挙動を確認できるのが大きな強みです。
- 項目名を変えてみる
- API のレスポンスを確認する
- データの流れをその場で試す
といった 試行錯誤（ユニットテスト） が簡単にでき、
プリザンターの構造理解が進むにつれて、徐々にスムーズに開発を進められるようになりました。
成長したポイント・学び
今回のシステム開発を通して、技術、業務的にも多くの学びがありました。
● プリザンターの強みを実感した
実際に手を動かしてみて、プリザンターが持つ カスタマイズの柔軟性 を強く感じました。
ローコード・ノーコードにありがちな “保守のしづらさ” を意識しながら構築すれば、
長く使える・汎用性の高い業務アプリを作れるツール だと分かりました。
項目追加・ワークフロー調整・権限設定など、
「ちょっと変えたい」を短時間で実現できる点は現場運用に非常に向いています。
● Python の扱いやすさを再認識した
私は普段、専任のプログラマではありませんが、
Python は 非エンジニアでも比較的取り組みやすい言語 であると改めて感じました。
- コードが読みやすい
- ライブラリが豊富
- データ加工やファイル生成との相性が良い
といった特徴のおかげで、Excel 生成ロジックの実装もスムーズに進められました。
● システムは“作って終わり”ではなく、運用にこそ価値がある
今回の開発で、最も大きな学びは 業務フローの改善視点が不可欠 ということです。
システムを作るだけではなく、
- 運用時に必要な項目は何か
- ユーザーがどこで迷うか
- 後続タスクの管理をどう簡潔にするか
といった点まで考えることで、
業務全体の効率化につながる仕組み を作れるようになりました。
“動くものを作る” から一歩進んで、
“業務に定着する仕組みを設計する” という視点を持てたことは大きな成長でした。
まとめ
業務の中には、
「あと少しここが自動化できれば…」
という、かゆいところに手が届かない作業が多く存在していると思います。
そうした小さな非効率が積み重なると、結果的に大きな手作業コストとなり、担当者の負担にもつながります。
プリザンターのようなツールを活用するには、最初は学習コストがかかります。
しかし、将来的な時間コスト・金銭的コストを考えると、今の運用が本当に最適なのかを見直すきっかけになる と今回の開発を通して実感しました。
今回構築したのは小さなシステムではありますが、
以前は「担当者へ依頼 →請求書作成 → 承認」という手作業が発生していたフローが、
担当者への依頼そのものが不要になり、業務コストを削減できた という効果がありました。
また、Excel で管理しているデータが多い環境であれば、
プリザンターを業務データ管理の基盤として活用する選択肢は十分に有効 だと感じています。
小規模な業務改善からスタートしやすく、かつ拡張性も高いため、現場に合った仕組みを長く運用していくことができます。
おわりに
プリザンターと AWS を組み合わせた今回のシステム開発は、単なる「請求書作成の自動化」に留まらず、
業務そのものを見直すきっかけ になりました。
開発前は「既存のツールに合わせて業務を調整する」のが当たり前でしたが、
実際に自分たちで仕組みを作ってみると、
- ツールが業務に寄り添う設計ができる
- 現場の声を反映した改善がすぐに行える
- 小さな非効率でも解消すれば大きな効果になる
ということを強く実感しました。
プリザンターは、ローコード・ノーコードの気軽さを持ちながら、
工夫次第で業務フロー全体を最適化できる柔軟さがあります。
もし今、
「Excel 管理がつらい」「既存のツールだとどうしても限界がある」
と感じている業務がある場合は、一度プリザンターを選択肢に入れてみる価値があると思います。
この記事が、同じように業務改善やツール導入を検討している方の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました！