最近作った社内ツールに利用している技術スタックと心掛けていることを紹介します

こんにちは。システム開発部のkiwiです。

普段は各サービスの開発サポートなどを行っているのですが、その中で業務を効率化するための社内ツールを作成することがあります。システム入稿用のファイルの内容確認や、ユーザー向けに配信しているメールの設定確認など用途はさまざまで、ツールによってはエンジニア以外のメンバーにも使ってもらっています。

ブラウザで動作する簡単な社内ツールの場合、技術的な制約があまりない代わりに、ほかの業務と並行して開発するため手間がかけられません。今回は、そうした状況で最近作成した社内ツールで利用した技術スタックや、社内ツール作成で心がけていることをご紹介します。

目次

社内ツールで利用している技術スタック

Vite

ビルドツールとしてViteを利用しています。

ReactやVueなどの主要なフレームワーク、TypeScriptなどの対応が整っており、またプロジェクトを作成するとすぐに作成を始められるところが魅力です。

# 対話形式でプロジェクト設定を実施
npm create vite@latest sample-app

# ローカルサーバー構築
cd sample-app
npm install
npm run dev

もっとも、最近は既存のツールのディレクトリを丸ごとコピーし、名前とリポジトリだけ変えて開発を始めてしまうことも多いです（ものぐさなので……）。

Vue.js + Pinia (+ Vue Router)

SPAのフレームワークとしてはVue.jsを使っています。

あまり深い選定理由はなく、単純に慣れていて早く手を動かせるため採用しています。React製の社内ツールもあり、統一はされていないのですが、いざとなれば作り直すことも容易な規模なのであまり気にしていません。

複雑なデータの取り扱いがなく、1ページで完結する場合は ref と computed だけで作ってしまう場合もありますが、APIからのデータ取得などを含む場合にはPiniaというライブラリで型安全にデータを取り扱うようにしています。

複数画面が必要な場合にはVue Routerを使うこともありますが、ルーティングとデータ管理が両方必要であればNuxtなどを検討するべきかもしれません。最新版（記事執筆時点ではRC版）であるNuxt 3では composables ディレクトリの自動インポートと useState を使うことで簡単なデータ管理ができるそうなので、今後採用する機会があれば試してみたいと思います。

MUSUBii + Heroicons

CSSフレームワークとして、弊社でもお世話になっているクラのこさん制作のMUSUBiiを使っています。ニフティ不動産の一部でも使われていることに加え、Bootstrapよりもスッキリした見た目になるので気に入って使っています。

コンポーネントごとの見た目がある程度定義されている形式のフレームワークのため、指定されたクラスを付与すれば整った見た目になるので、あまりデザインに時間をかけたくない場面で重宝します。

また、アイコンについてはHeroiconsを利用しています。Vue.js用のライブラリが用意されており、テンプレート内で読み込むだけでコンポーネントとして利用できるのがとても助かっています。社内ツールといえど、アイコンがあると視覚的にわかりやすくなるので積極的に使っています。

社内ツール作成時に気をつけていること

ここからは少し毛色を変えて、社内ツールを作成する時に気をつけていることを、自分自身の整理も兼ねて簡単にご紹介します。

一つのツールに機能を増やし過ぎない

一つひとつのツールができるだけ単純で、一つの役割だけを果たすように気をつけています。

特に社内ツールは管理体制が曖昧になることが多く、後からREADMEとソースコードを見ただけでもある程度何をしているか把握できるようにするためです。必要に応じてツール自体も分割し、理解の負担にならないように気をつけています。

できる操作を極力減らす

社内ツールの場合、複雑なUI設計やマニュアルを用意する工数が取れないことも多いので、そもそもユーザーが操作・入力できる範囲を極力減らすようにしています。

そもそも操作が少なければ、少しの説明で迷うことなく使うことが可能です。逆に、できるだけ少ない操作で目的を満たすことができるよう、何が課題なのかを明確にすることが必要です。また、通常は規定値が使われるフィールドなど普段操作する必要がない項目はデフォルトで隠しておくなど、できる操作が少なく見えるUIにすることも心がけています。

間違えやすい入力はブラウザ機能でブロックする

入力フォームにおいては disabled 属性や readonly 属性を活用して想定外の入力・変更をフォーム時点でブロックするようにしています。ユーザーの入力に対するバリデーションは十分に行う必要がありますが、入力者のこと（操作目的やブラウザ環境）をある程度信頼できるため、実装工数を削減するためある程度のバリデーションをフロントに任せる選択を取ることもあります。

また、入力した内容が反映されない（実際はデータの組み合わせ的に反映できないため無視している）などの挙動は、ユーザー問い合わせを防ぐためにも極力減らしておきたいです。そういう意味でも、入力の無効化などを活用し、入力できないことをブラウザ上でユーザーに知らせることが大切です。

使ってもらう様子を一緒に見る

最近、画面共有してもらいながら、実際にツールを使っている様子を見せてもらう機会がありました。初めてツールを使うメンバーに使い方を教えるためだったのですが、使いづらい部分や不親切な部分が見つかり、ツールの改善につながりました。

実プロダクトにおいても、ユーザーインタビューやユーザーテストを使って使い勝手の課題を見つけることは大切ですが、社内ツールの場合はユーザーが近くにいるため、実施のハードルがかなり低いです。特に使い方をレクチャーする場面があれば、ぜひ一緒の画面を見ながら、ツール自体の改善点も探すと良いでしょう。

まとめ

今回は、最近作成した社内ツールで使用したライブラリやフレームワークについてご紹介しました。

日々の運用の中で頻繁に確認が必要な業務やミスが発生しそうな業務をサポートするようなツールは、普段の業務で活躍しているもののあまり社外に紹介する機会がないなと思い、一部のトピックに絞って今回取り上げてみました。

ツール自体の管理体制が曖昧になりやすいなど難しい側面もありますが、今後もこうしたツールを活用し運用業務の改善に取り組みながら、新しい価値の創造に注力してまいります。