👨‍💻

社内向け管理画面をスクラッチ開発するのはもうやめよう

2023/04/18に公開

みなさんは普段どのように社内向けのツールや管理画面を開発していますか?

スクラッチで作っている、CSSテンプレートを活用している、エンジニアにオペレーションが依存してしまっているなど様々だと思います。

今回は、社内向けの管理画面をスクラッチで開発するのはもうやめたほうがいいよねという話をしたいと思います。

私は、社内向けの管理画面をローコードで構築できる『Querier』(クエリア)というSaaS型のサービスを作っています。

正式にリリースしてからちょうど1年ほど経過した頃なので、改めて自分自身が日々感じでいる社内向けツールへの課題感や、クエリアがどのように解決していくかなどを書いていきますので、興味のある方は最後まで読んでいただければと思います。

なぜクエリアを作ろうと思ったのか

社内ツールはほぼ全ての企業に存在しています。殆どの企業は、最低でも10%程度、多いところだと半分程度のエンジニアリソースを社内向けの開発に費やしています。

また、自分自身もエンジニアとして管理画面や社内向けのちょっとしたツールを開発する体験は良いものではなく、理想を言えばやりたくないと常々感じてきました。

とはいえ、世の中のノーコードやローコードのツールはサービス固有の複雑性が存在する割に、拡張性やメンテナンス性が低く、結局リプレイスしなければいけないものばかりで、最適なソリューションを見つけることはできませんでした。

そこで、エンジニアの人が使いやすく、拡張性やメンテナンス性も高い、圧倒的に開発体験の良い社内向けのSaaS型のローコードソリューションを作ろうと思ったのがクエリアの開発経緯になります。

エンジニアは社内向け管理画面に感じている課題を自覚しつつも我慢している

今まで社内向けの管理画面やツールをローコードで使うという常識はこの世の中にありませんでした。今でもそこまで浸透しているものではありません。

なので、エンジニアはペインを感じて入るものの、仕方のないこととしてそのペインを受け入れ、我慢して社内向けのツールを開発しているのが現状だと思います。

GPTやノーコード・ローコードの登場によって、今いるエンジニアのリソースをどのように有効活用するかという視点が大切になってきているように感じます。なので、エンジニアの苦痛を極限まで減らし、よりバリューが出せる場所にリソースを最大限使ってほしいと思っています。

社内ツールの重要性

では、社内ツールはどれほど重要なものなのでしょうか?私の見解は、とても重要なものだが、エンジニアが社内ツールを開発しやすい環境が整っていないことにより、疎かになっていると考えています。

最近元Metaのエンジニアのエピソードが少し話題になりましたが、この中で社内ツールに言及されています。

彼は自分自身が感じた社内の課題を、社内ツールを開発して解決し、その社内ツールが組織内でスケールして、全体の労働時間の削減に貢献したというものです。また、このような活動がMeta社から評価され、追加のボーナスや株を付与されたそうです。

チームではバグレポートから関連した情報を抽出するのに時間がかかっていた。
それを解決するために彼はAndroidエンジニアにも関わらず、社内ツールを開発し、それが多くのチームの労働時間削減に貢献した。

参照: https://twitter.com/sakamoto_582/status/1646435095174328320

このように、課題を発見した人が解決できる最適なソリューションをスムーズに構築できる環境が必要だと思っています。クエリアはこういった社内文化への貢献をしていきたいと考えています。

社内ツールや管理画面における課題

1. プロダクトのアップデートに追従できない

社内向けのツールや管理画面は、メインのプロダクトよりも優先度が下がりがちなので、新機能がプロダクト側で実装されても、新機能に関連する管理側の機能は後回しにされてしまうことが多々あります。

そうすると、一時的に新機能に関連するオペレーションを都度エンジニアに依頼するなどの工数が発生してしまい、本末転倒となってしまうことがあります。

2. メンテナンス性の低いコードになってしまう

エンジニアは日々プロダクトの開発に追われています。そんな中で作る社内向けツールでメンテナンス性の高いコードを書くことは難しいです。

また、ライブラリの定期的なアップデートやフレームワークのバージョンアップなどにもなかなか手が回らず、気づいたら誰も変更することのできないコードベースが出来上がっていることも少なくありません。

3. UXが悪くなりがち

社内向けのツールや管理画面にデザイナーががっつりコミットして、オペレーションチームが扱いやすい画面を作ることができるチームは少ないと思います。オペレーションが事業の中核を担う事業領域であるか、かなり余裕のあるチームでないと難しいと思います。

殆どのチームでは、ユーザー体験の部分を疎かにして、機能要件の実現を最優先事項として開発しています。

しかし、エンジニアが不足していて、採用も難しく、プロダクトのリリースサイクルを崩せないという事情から、社内向けツールや管理画面をスクラッチで作る以上、UXが疎かになってしまうのは、仕方ないことのように思えます。

4. 煩雑な権限管理

ちゃんと社内のセキュリティを担保しようとすると、権限管理は必須の機能です。しかし、ただでさえリソースが無い中で権限管理機能を実装するのはかなりヘビーなタスクとなってしまいます。

その結果、「ここは見ないでね」などのオペレーションでカバーしているケース、もしくは、しっかりとしたリソースを使って作り込むかのどちらかになってしまいます。

ノーコード・ローコードの課題

1. 業務フローの複雑性に対応できない拡張性の低さ

ノーコード・ローコードの課題として、事業の成長とともに、要件が複雑になってくると、結局スクラッチで作り直さなければいけなくなってしまう拡張性の低さは、特にエンジニアであれば感じることが多いと思います。

特にノーコード系のツールはコードを書くことを前提として設計されていない分、コードを書ける機構は用意されているものの、一気に複雑性が増して、開発体験が悪い上に、実現したいことも100%達成できないなどが起きてしまいます。

ここは大きな課題だと捉えて、クエリアを開発する際は、複雑な要件にも対応できるような拡張性の高さを意識して開発しています。

2. プロダクト固有の概念による学習コスト

また、ノーコード・ローコードの2つ目の課題として、サービス固有の概念の学習コストが高いという問題もあると思います。

普段使い慣れた開発言語を書けば実装できてしまうエンジニアにとっては、固有の概念を学習するストレスは計り知れません。

なるべくエンジニアが知っている概念を持ち合わせていれば、容易に類推できるようなサービス設計である必要があると考えています。

クエリアの解決策

1. 圧倒的にシンプルなUI構築

社内向けの管理画面やツールには複雑なUIが必要であることはあまりないと思います。なので、クエリアでは、UIに関して何も考えずにドラッグ・アンド・ドロップするだけで、体験の良い画面が作れるように意識して設計しています。

また、業務フローの変化にも対応できるように、配置したコンポーネントの再配置もしやすいように設計しています。

コンポーネントを座標ベースの絶対配置をしてしまうと、何か1つのコンポーネントを動かした際に、周辺のコンポーネントも動かし直して調整しなければいけません。

そこで、クエリアではコンポーネントを相対位置で保持しているので、1つコンポーネントを動かしても他のコンポーネントが自動で調整されるようになっています。

これにより、初速もメンテナンス性も高いUI構築体験を提供しています。

querier_dnd_demo

2. コードを書ける余地を残した高い拡張性

業務フローは複雑になりがちで、データに関わるロジック部分の拡張性は妥協せずに、あえてコードを書けるような余地を残すように設計しています。

また、クエリアでは基本的な全ての場所でJavaScriptを記述することができます。フロントエンド/バックエンドに関わらずエンジニアであれば基本的な文法は書けるであろうJavaScriptをベースに作られているため、新しい概念を学習する必要はありません

さらに、REST APIやGraphQLとの連携にも対応できるので、プロダクト内の機能だけでは実現できない複雑なロジックもAPIが提供されていれば実現することが可能です。(もちろん、GitHubやStripe,HubSpotなど外部APIを使うことも可能です)

対応データソース(2023年4月時点)
  • MySQL
  • PostgreSQL
  • Firebase(Auth, Firestore)
  • Mongo DB
  • Dynamo DB
  • REST API
  • GraphQL
  • Google スプレッドシート
  • Amazon S3
  • Amazon Athena
  • Google Cloud Storage
  • BigQuery
  • Salesforce
  • Slack Webhook

querier_select_js

3. AIを活用したデータ操作の民主化

最近大きな盛り上がりを見せているAIですが、クエリアも積極的に活用していこうと考えています。先日、MySQL、PostgreSQLのSQLをデータ構造に合わせて出力するアシスト機能をリリースしました。

コードを書ける前提の設計で、エンジニアに使いやすいベースを持ちつつ、AIやGUIで上からラッピングすることで、シンプルなものを作るときはノーコードで、よりカスタマイズしたい場合は、エンジニアフレンドリーなローコードで構築できるプロダクトを目指していきます。

querier_ai_demo

クエリアが目指すもの

クエリアが目指すのは、社内向け管理画面やツールの構築ソリューションを提供することで、プロダクトチームの開発生産性の向上既存エンジニアのリソース最適化をサポートすることです。

社内の課題に気づいた時に、最適なソリューションを大きな工数をかけず、サクッと構築できるという当たり前を作ることで、世界中の労働力がより効率化され、イノベーションが加速すると考えています。

現在、社内ツールや管理画面に大きな課題を感じている方は一度クエリアを触ってみてください。無料のトライアルも行っています。

クエリア

Discussion