久々にQiitaでの投稿です。
いよいよ今年も最終週を走り切るのみになりました。早い人はお休みに入っている方もいるのでしょうか？
今年はギリギリまで仕事をして終えることになりそうなので、ゆっくりと過ごそうと思うと実は今週末の過ごし方が意外と重要なことに今更気づいて焦っている今日この頃です。
さて、今年はお仕事でPleasanterが身近になった1年でした。7月にはパートナー企業にもなり、12月にはアワードでニューカマー賞を頂き、2025年はさらに気を引き締めて頑張っていきたいと思います。
今年から初めてPleasanterのアドベントカレンダーにエントリーさせて頂いました。何を書くか迷っていたのですが、◯◯をやってみたシリーズなどではない形で書いてみることにしました。
Pleasanterを少し使い慣れてきた頃にふと立ち止まったことがありました。パッとすぐに答えが出ず塩漬けにし続けたテーマを来年に持ち越さないようにアドベントカレンダーをきっかけにして考えてみることにしました。
Pleasanterとは
Salesforceやキントーンを使ったことがある方であれば、そういった業務アプリのOSS版とでも言ったら良いでしょうか。筆者としてはあれこれ調べて理解するより、触ってみて体感していただけると魅力が伝わるのではないでしょうか。
ノーコードおよびローコード双方のメリットを併せ持つ強力な機能を備えており、技術的な知識がなくても簡単に業務アプリを作成できるツールです。
今回の話
本格的にPleasanterを使ってあれこれ試していく中で機能や使い方を理解して、選択肢を一通り手に入れたところでした。
カスタマイズにも慣れてきて、何でもできそうな気がするというハイな状態です。淡々と1人で作って行く分には何も気にならないのですがチームや複数人で開発をすることを考えると少し気になることがありました。
DXや業務改革を目的にPleasanterを導入する際にはできるだけ現場でプログラミングができる人を増やしたいと考えていました。そのため、エンジニアが壁を作って非エンジニアが入ってくることを拒むことを避けたいと思っています。
しかし、非エンジニアとエンジニアが同じ場所を使ってプログラミングをすることは色々な問題が発生すると思います。お互いが持つべき関心領域を分けられるといいなと思うことがあったり、サイトを横断してDRYの原則をどのように保っていくかや業務上で重要なロジックを分離することなどを考えていくうちに、 APIサーバーを立てると幸せになれるのかな？ と素朴に思うことがありました。
今回はそんな疑問が少しでもすっきりできるように言葉にしながら考えてみたいと思います。
Pleasanterでできるカスタマイズとは？
まず初めにPleasanterでできることを改めて整理してみました。
スクリプト/サーバースクリプト
Pleasanterの管理画面からJavaScriptでカスタマイズのプログラムを書くことができます。違う言い方をすればGoogle App Scriptやマクロというと馴染みがあるかもしれませんね。
今となっては驚くような話ではないのですが、JavaScriptはフロントエンドとバックエンドの両方で使用することができます。
PleasanterでもJavaScriptをフロントエンドとバックエンドの両方で動かせるようにサポートしており、フロントエンド側をスクリプトと呼び、サーバーサイド側をサーバースクリプトと呼んでいます。
エンジニアの方にとっては、フロントエンドとバックエンドを使い分けることはさほど難しくないと思いますが、非エンジニアにとっては仕組みを理解するところから苦戦するかもしれません。
Pleasanterでは、このスクリプトとサーバースクリプトはカスタマイズの最も中心的な役割を果たします。
拡張スクリプト/拡張サーバースクリプト
Pleasanterでは頭に拡張とついたスクリプトがあります。これはPleasanterの決められたディレクトリに直接ファイルを配置することで実行できるスクリプトです。
何かあった時の影響範囲も広く、基本的にはシステム寄りエンジニア寄りの人たちしか触らない特殊な領域と言えます。
本家のコード修正
玄人向けになると思いますが、オープンソースソフトウェア(OSS)で公開されているPleasanterを独自でカスタマイズして使用することです。OSSだからといって好き勝手にやっていいという訳ではなく、適用されているライセンスを守って許された範囲で開発が必要です。
結局何に悩んだの？
Pleasanterを使いながら実際にどのようなことに悩んだのか書いてみました。
①エディタの使いにくさ
Pleasanterを使っていく上でまず最初に悩んだのがエディタの使いにくさでした。
使い始めて間も無くしてエディタ風のUIがリリースされて使い勝手はかなり改善されましたが、当時はテキストエリアに直書きという状態でした。高校生の頃に初めてプログラミングを学んでメモ帳でプログラムを書いていた頃を思い出して懐かしかったです。
回避策としてPleasanter -> VS Code -> Pleasanterと一手間加えることでストレス感はかなり下げることができました。
②サイトテーブルで汎用的に使えるライブラリ
スクリプトやサーバースクリプトはサイトと呼ばれる単位でしか保持・参照できないことです。似たようなことをしようと思っても同じ処理を別のサイトのスクリプトにコピーする必要が出てきます。
DRYの原則ではないですが、普段から冗長なコードを書かないように教え込まれたエンジニアの感覚としては、コピペして同じコードが増殖していくのはなんとも言えないむず痒さを感じてしまいます。
もちろん、拡張スクリプトや拡張サーバースクリプトを活用することで汎用的なモジュールを他でも利用しやすいようにできることは知っています。しかし、変更のたびにPleasanter自体の再起動が必要になることを考えるとあまり積極的に活用したいとは思えませんでした。
③誰がスクリプトを触るか
Pleasanterで誰がカスタマイズするかという点も気になるところです。1番統制を効かせやすいのはスクリプトなどはすべてエンジニアが触ることだと思いますが、エンジニア不足や現場主導の業務改善を考えるとエンジニアが最前線に出て何かするということは避けたいと考えている派です。
そう考えた時に後方支援的にコードのレビューやサンプルコード、チュートリアルなどを用意してあげることもあると思いますし、直接コードを書いて渡してあげることもあります。筆者として1番避けたいのはITリテラシーの高い現場の担当者とエンジニアが同じ場所のスクリプトを書くことです。
非エンジニアとエンジニアが同じ場所で共存してコードを書くのはかなり大変です。よくある例として、現場の人が勝手にスクリプトを編集して壊れて問題や相談に発展するパターンです。このパターンは発生頻度が少なければエンジニアの人も優しくサポートすると思いますが、頻度が増えてくるとフラストレーションが徐々にたまってきて行くところまで行くと「勝手に触ったら、知らん」となるか「編集不可」になるかです。
他のパターンとして、非エンジニアとして敷居が上がってしまい本来狙っていた現場の人たちが主導してスクリプトを書くことが避けられてしまうことです。これによりエンジニアに要望が集中してパンクしてしまうことになり、現場の業務改善スピードが現状と変わらないか一気に減速してしまうことになりかねません。
④ソースコードの変更管理
数十行くらいのスクリプトであれば日々の変化や何かあった時にもまだ気づけるレベルだと思いますが、複雑なことをしようとするとコードが膨れ上がってきます。また、1人で完結すればいいのですがチームでコードを書くこともあり得ます。予期せぬ問題が発生した時にいつどこで誰がコードを変更したのかは知っておきたいものです。
力技で頑張ろうとすれば、VS Codeなどに持っていってから人手をかえしてGitHub上で管理することで解決できます。
どうやったら解決するの？
コミュニティにも顔を出すようになり、様々な人と情報交換をしていく中で色々な情報が手に入りました。
今進んでいる施策やPleasanterとして抱えている課題も知ることができ、その中で自分が感じていることは既知の問題で既に解決に向けて動いていることなどもありました。
統合開発環境 in Pleasanter？
解決できそうな悩み：①②④
思うことを色々と頭の中でわーっと湧きあがらせていたのですが、改めて冷静に考えてみると主流の統合開発環境(IDE)を使いこなして慣れてしまった人が突然テキストエリアのプレーンテキストしかない世界に放り込まれるとそれはそうなるよと思いました。
エンジニアが開発するために悩んで試行錯誤を繰り返してたどり着いたものが統合開発環境だと思っているので、Pleasanterで開発するためのストレスを減らしていくとたどり着く先はPleasanterの中に統合開発環境が埋め込まれることになります。
Pleasanter上のエディタに欲を求めていくとキリがないということに気づいたので別の方法を考える必要がありそうです。
Visual Studio Codeとの連携
解決できそうな悩み：①②④
Google App Scriptの開発環境をVisual Studio Codeでローカル開発する仕組みです。claspとかasideを使って実現することができます。
同じようなことがPleasanterできるようになるとVisual Studio Code使いの筆者からすると大変嬉しいです。
本家の開発者との会話の中やイベントなどで耳にすることが増えてきたので、近い将来このような仕組みがサポートされているのではないかと楽しみにしています。
外部APIサーバー
解決できそうな悩み：①②③④
ピッタリとハマるシーンはないと思いますが、現場とエンジニアが同じ場所を主戦場にプログラミングをするとハッピーな結末を迎えないということを考えるとできるだけ、領域を分けて運用したいと考えると外部APIサーバーが幸せになれるのではないかと考えています。
もしかすると、Pleasanterを動かしている環境によっては手軽に1つサーバーを増やすことが難しいこともあるともいます。
筆者は、どちらかというと仮想化やコンテナ化派ということもありますが、こういったシーンで手軽にサーバーを増やしやすいのは仮想化やコンテナ技術のメリットの1つではないでしょうか。
冒頭でお話ししたようにJavaScriptでバックエンドの構築もできるため、プログラミング言語を変えることなくAPIサーバーも構築することが可能です。
APIサーバーを立てると幸せになれるのか？
幸せになれるのかの答えを出してみようと思うのですが、その前にPleasanterにはAPI機能があり、外部からでもPleasanterを操作することができるのですが、今回はAPIを使用してAPIサーバーで全部の処理を担うことは考えていません。
その前提で改めてメリットとデメリットを書いてみました。
メリット
- 作業領域の分離: スクリプトとサーバースクリプトは現場向け。APIサーバーはエンジニア向け
- DevOpsやCI/CD、テスト自動化など通常のシステムの仕組みやノウハウを活用しやすい
- 共通処理やシステムとして握っておきたい業務上の重要な処理を分離できる
- 他の関連システムとのハブ的な役割も担いやすい
- Pleasanterがモノリシックになりにくい
デメリット
- 管理するサーバーが増えることでの管理コスト
- APIサーバーとの通信分のパフォーマンス低下(処理によっては許容できないことも)
良し悪しや向き不向きは様々な要因が絡むため、0/100で良し悪しの答えを出しにくくはありますが、今回のアドベントカレンダーをきっかけに書き出すことですっきりしました。
最終的にはパフォーマンス部分がどれだけ影響するかによりますが、幸せになれることは多いと感じました。Pleasanterを使っている方々とも意見交換しながらより幸せになれる形を探していきたいですね。
皆さん、良い週末を