Pleasanterを用いた業務効率化システム

Excelのように利用できるOSS、Pleasanter。
弊社ではこのOSSを使って業務効率化システムを作成してみました。
本ページでは導入の経緯やどういった風に開発していったか掲載していきたいと思います。

Pleasanterとは

公式サイトから引用すると「プリザンターは、オープンソースのローコード開発プラットフォーム」とのことです。
簡単に言うとWebで操作可能なExcelのようなもの、と言えばイメージしやすいかもしれません。

ローコードとは、最小限のソースコードでソフトウェア開発を行えることを意味します。
アプリ開発と言うと開発ツールを用意してプログラム言語を利用して1から作って…となるかと思いますが、Pleasanterでは、従来の機能を活かしたままユーザー独自の機能を追加することが可能となります。
やりたいこと次第ですが、Pleasanterで用意されているスクリプト機能・サーバスクリプト機能を使えば開発ツールすら必要ありません。Pleasanter自体がアプリケーションであり、開発プラットフォームなのです。
Excelで言うとこの開発部分はマクロに近い形と言えば分かりやすいでしょうか。

Pleasanterを選んだわけ

弊社は数々のOSSを活用しており、社内のシステムとしても利用しています。
新たなツールとしてPleasanterにも目をつけており、以前Windows版を使用しようとしていたのですが、弊社の検証環境では使い勝手はあまり良くなく、社内での利用は立ち消えていました。
ですがLinux版が提供され、実際検証してみたところ、かなり使い勝手も良く、更には機能も大きく変化していました。
PleasanterはOSSの開発も活発で週に1度は更新されている状態です。
Linux版（.NetCore版）のデータベースはPostgreSQLで冗長性も考慮できるメリットがあります。
これらを総合して判断した結果、Pleasanterを採用することとなりました。

導入のきっかけ

今では「業務効率化システム」という大きな枠組みになっていますが、当初の目的は全く違うものでした。
弊社では新規事業共創グループが立ち上がりまして、新規事業を考えるにあたって今までのことも振り返ってみようとしていました。
新たなことをする前に今までのお客様を振り返ってみる。まずは弊社内のWEB問い合わせからどのようなお客様が問い合わせされているのか、そしてどんな商談が発生し、受注・失注に至ったか分析する。
これをPleasanterで実現しようとしていました。

問題１：管理しているデータベースがない

これらを実現するために必要なのが「過去の問い合わせデータ情報」と、それに紐づく「商談情報」です。
商談情報はAipoというOSS（現在は提供終了のため利用できなくなっております）を使っていたのでこちらに一部データはあるのですが、Aipoは元々商談情報を登録するようなツールではなく、弊社が大幅なカスタマイズをして利用している状態でした。
このデータべースには問い合わせを元としたデータは保存されていません。
苦肉の策として、弊社内で個々人で使っているメーラーからデータをかき集めてPleasanterに登録していきました。
途方もない量でしたがなんとか無事に登録完了し、分類を分けて集計することができました。

ですが次の問題が発生します。登録した問い合わせ内容に商談が紐づけられないのです。
弊社内の案件管理ツールは先述したようにAipoで管理していましたが、適切な情報がすべて揃っている訳ではありません。
そして似たような商談が多く存在し、どのメールがどの商談に紐づくのかほとんど判明しませんでした。
それでも分かる範囲だけでも紐づけていこうと、Pleasanterに商談管理も登録していきました。

問題２：大したことは分からない

そうして紐づけていっても問い合わせがどうなっていったのかがほとんど分かりませんでした。
紐づけられた数がものすごく少ないため、その少なさでは分析のしようがありません。
営業に確認を取ってみたりもしましたが、やはり分かりません。
ですので過去の分析をするのではなく、これからデータ収集して分析することを目指すことにしました。

問題３：他のデータも紐づけたい

WEB問い合わせ情報の分析はできませんでしたが、他にも金額についてや見積書、請求書の管理番号など紐づけた方が一元管理できて良いのではないかと思い始めてきました。
そうなってくると「WEB問い合わせの内容」と「商談情報の内容（一部）」だけでは足りません。
正式見積時の金額や請求時の金額など、そういった諸々の情報が必要になってきます。
ですが開発担当者にはその知識がありませんでした。
ここから全社員を巻き込んでの聞き取りが始まります。

聞き取り

何を考慮しないといけないのか

弊社の「商談」にまつわるデータが何か、そもそもデータとしてどこに存在しているのか、そのデータを活用して業務はどんなことをやっているのか、多くの人に声をかけてそれを知るところから始まりました。
弊社は規模が大きい会社ではありませんが、それでも担当ごとに様々な業務をこなしています。関わりのない他業務はなんとなくイメージはあるのですが実際にどういう業務をしているのか詳細は何も分かりません。

何が商談にまつわるデータなのか知るためにはどんな業務なのか知る必要がありますし、どういう風にそのデータを活用しているのか、そのデータを活用して最終的にどういうことをしたかったのか等、色々なことを知らないといけません。
主に営業職の人たちを中心として聞き取りを開始しましたが、規模が大きくないはずの弊社でも聞き取りに時間がかかったり、何度も会議をしたり、多くの時間を費やしました。
時間はかかりましたが、開発担当者としては聞き取りを重点的にしたことによって社員が協力的になってくれたため、かなり重要なところだと感じております。

必要な情報１：何の媒体で管理しているか

大体の方が業務に使ってるのはExcelでした。
ですので、Pleasanterの「脱Excel化で業務快適化」には合致しているように思えます。
ただし合致してると言えるのはデータベースとして管理されているExcelのみで、それ以外はデータとしての落とし込み方がとても難しかったです。

必要な情報２：関連するデータ同士の紐づけ

Excel管理されているものはほとんどデータベース化されているのでPleasanterに転記するのは難しくないのですが、グループごと、担当者ごとに使っているデータが異なるため、紐づけがされていない状態です。
「自分が使いやすいように使っている」Excelなので、同じようなデータでも内容がかなり異なってしまいます。
関連するデータを見つけ、紐づけ、紐づけた情報をマージし、情報を整えるとなると、確認作業に多くの時間が必要となります。
それでも時間をかけてなんとか紐づけることができました。

必要な情報３：最終的にどんな情報が欲しいのか

データ情報を紐づけてまとめても最終的にどんな情報が欲しいのか把握する必要があります。
営業職の場合は年度ごとの売り上げ等の情報になります。こう言ってしまうと合計の売上額を出せばいいのかと思いますが、実際はそうではありません。
月ごとに集計したいのか、更に詳細を分けて何かしらの分類を分けたいのか、売り上げの実績と見込みはどういうタイミングで計上したいのか、それらを鑑みて元のデータからどうやったら集計できるのか考慮する必要があります。
この辺りの情報を揃えて、ようやくPleasanter上でテーブル設計を考え始めることができるようになってきました。

テーブル設計

何が必要で何が必要でないかが聞き取りでわかってきました。
最終的にこれらのデータに対して、どういう人がどのような場面でどういう条件で集計したいかもわかってきました。
ここからテーブル設計を始めていきます。

計上の仕様が難しい

弊社の計上の仕様が特殊なやり方をしているものが多く、集計の実現方法を考慮するのがとても難しくなりました。
Plaesanterでは自身でカスタマイズしない限り、特殊な集計はできません。
テーブル設計がかなり重要になってくるので、これからPlaesanterを使って開発する方はテーブル設計について学ばれることをお勧めします。

テーブル設計について

一応テーブル設計について簡単に解説していきたいと思います。
注意事項として念のため記載させていただきますと、テーブル設計は十人十色です。絶対的な正解はありません。
正解はありませんが、「使いやすい」設計になるかどうかが肝要です。

まず、用語の説明をします。

• カラム
  レコードの中の1属性。Excelで言うところの列。サンプルですと「ID」「名前」の項目です。
• レコード
  テーブルの中の1データ。Excelで言うところの行。行単位で1つの情報とします。サンプルですと「１」「りんご」で1レコードです。
• テーブル
  Excelで言う表のようなもの。サンプルですと「果物テーブル」です。

テーブルを扱う際には普通のツールならカラムサイズ等も考慮しないといけませんし、テーブルを素早く検索するために考慮しなければならない様々なことが存在します。
ですがPleasanterはテーブルに属するカラムさえ考えれば問題ありません。
果物テーブルではIDと名前さえあれば良いので、これで完成です。追加で新たにカラムを入れたい時は簡単にカラムが追加できます。

ただし、ここで考慮しなければならないのが冗長性です。
果物テーブルを購入した人の情報を追加したいという要望があったとします。その場合、1つのテーブルにすべて収めるとこうなります。

似たようなりんご購入者のレコードがあるのがお分かりかと思います。
この場合、購入者が複数存在することによってりんごと言うデータを複数登録しなければなりません。
つまり冗長なデータ、無駄なデータが存在することになります。
この無駄を無くしていくことを「正規化」と呼びます。このテーブルを正規化していくと下記のようになります。

テーブルを分けてマスタとすることで、頻繁に更新するテーブルは購入情報テーブルのみで、果物テーブルは購入ごとに更新しなくて済むことが分かります。
ただし正規化もやりすぎると逆に無駄になってしまうことがあります。

数々の情報をテーブルにまとめ、正規化し、適切なテーブルを作る。
人それぞれの設計思想によって何が適切なのかが変わってしまうため、「テーブル設計は十人十色」となる訳です。

なんとか完成

弊社の計上の仕様が難しいと前述しましたが、色々な人に何度も聞き取りを行い、設計を練り直してなんとか完成することができました。
どんなデータが存在し、どういう風に利用し、どんな結果が欲しいのか。よく分からないまま実施しようとしてもできないものです。
ただしExcelが普及している昨今では、Excel利用者は自然とテーブル設計の思想ができているのではないでしょうか。
Pleasanterはテーブル設計がかなり気軽に行えるので、試行錯誤しながら触っていくとブラッシュアップできるのではないかと思います。

まとめ

弊社では完成したものをリリースして、社内でも業務効率化ツールとして現在使用しております。
一通り開発し、利用してもらった際に感じたメリットを挙げていきたいと思います。

メリット１：直観的に開発できる

やはり開発をしたことがない人でも直観的にできそうだ、と言うのがメリットになるかと思います。
セットアップマニュアルさえ見れば簡単に導入できますし、その先のGUIもテーブル設計等面倒なことを考えなくても「なんとなく」で触ることが可能です。
また、開発も用意なので利用者からの簡単な要望ならすぐに叶えることができます。

メリット２：バグ対応や機能追加等サポートが手厚い

Pleasanterは色々な機能がどんどん追加されており、更新頻度がかなり高いです。
バージョンアップ情報を見る限り、バージョンアップごとに何かしらのバグが修正されているのでサポートは十分かと思います。
「こういう機能が欲しいけど今は無い」という状態であっても、Gitで要望が多く挙げられているためそれが取り入れられる可能性が高く、今後も更に便利になる可能性が高いと感じています。

メリット３：開発可能な範囲が狭くても開発できる

Pleasanterで提供されている開発範囲は限られていますが、それでも十分開発できます。
OSSなのでもちろんすべて自由に独自開発できますが、バージョンアップが高頻度に行われるので直接手はつけたくない、けれど開発はしたい。そう思った弊社の要望にも応えてくれるアプリケーションでした。

まとめ

弊社では完成したと言いましたが、まだ足りない機能もありますし、実は聞いていた仕様が実態と異なっていたということも判明してきました。
ですのでまだ開発は終わりません。業務効率化するために開発し続ける、これがまさに昨今流行のDXなのかなと感じております。
これからも頑張って開発し続けていこうと思います。

技術情報

• Pleasanter製品情報
  • 基礎情報
  • TIPS
    • Pleasanterを用いた業務効率化システム

商標について

関連サービス