はじめに
こんにちは、システム開発グループの金谷です。
この記事では、システム開発グループの仕事の1つである社内向けのツール開発と、運用方法、ソースコードの管理について紹介します。 ABEJA では、社内で利用している Google 関連のサービス(スプレッドシート・スライドなど)や、Notion/Slack/Salesforce などの業務で使用しているサービスをより効率的に使用するためのツール開発を行っています。
記事を書いた経緯
以前は、社内向けの効率化ツールを作っても、長期的に運用することは考えず、作りっぱなしになることがありました。なので、作成者以外は仕様も把握しておらず、不具合が起きた際や機能改修する際には、作成者が触るか他の人がコードを一から把握するしかないという状態でした。ツールは毎月のように増え、この状況ではまずいということで運用方法やコードの管理方法にルールを設けることにしました。
現在では、数多くの効率化ツールが全社で使われ続けており、業務に不可欠なものをいくつも運用しています。また、これから話す内容を実施することで、開発者に属人化することなく複数のメンバーが仕様を把握し、開発できる状態になりました。今後もこの取り組みを続け、社内で使われ続ける便利なツールを作り続けられればと思っています！
この記事は
- 社内向けの効率化ツールの導入を考えている
- すでに作成しているけどうまく運用できていない
- ツール開発が属人化してしまっているせいで作った人しか触れないものが量産されている
という様な内容に当てはまる方たちに読んでいただけると嬉しいです！
社内向けツール開発時の課題
社内向けのツールはサクッと作れる反面、下記のような問題点が挙げられます。
- 開発が属人化してしまうため、他の人が動かそうと思ってもよくわからない
- コードのバージョン管理、テストがおろそかにされやすいので、不具合が起きた際に解消に時間がかかってしまう
- 開発者以外は仕様がわからず、ある不具合を機に使われなくなってしまう
などが挙げられます。
なくても業務が回るような便利ツールの場合は特に、コードの管理やテストはあまり行われず、しばらくしたら使われなくなってしまうというようなことも多いと思います。 また、属人化が問題で、不具合を原因に永久に使われなくなってしまうということもあるのではないでしょうか。 これらを踏まえ、弊社では社内向けに開発するツールもしっかり管理するようにしています。
ルールの導入時やマニュアル作成時には多少手間はかかりますが、長い目で見ると便利なツールを長期的に、保守・運用の手間を少なく使用できる分取り入れてよかったと思います。(開発し始めた当初は管理していなかったため、上記の問題点全てに当てはまっていました。。)
ABEJAでの取り組みについて
作成した社内向けツールの例
次に、これまで作成してきた社内向けツールの一部を紹介します。
ABEJAでは、主に Google Apps Script(以降 GAS)を使用して開発しています。GASはGoogleが提供しているJavaScriptベースのプログラミング言語であり、スクリプトを実装することで簡易的にGoogleのスプレッドシートやスライド、カレンダーなど様々なサービスを操作することが可能です。
また、業務で使用するNotion/Slack/Salesforceなど、外部連携用のインターフェイスが提供されているサービスのAPI等を使用することで、月次でおこなっている集計業務やデータ連携業務を自動化する、といったことも可能です。
ABEJAでは社内向けのツールを導入することで、ルーティンワークやサービス/ツール間のデータ連携の自動化を行い、工数削減や人的なミスをなくすような施策を行っています。
社員の工数を管理するためのツール
システム構成図
各メンバーが複数のプロジェクトにアサインされ、様々な工程を担当しているので、週次でどのプロジェクトのどんな業務に、どれくらい工数を割いたかを把握できるようにしています。入力された工数をBigQueryに登録し、Googleデータポータルからプロジェクトや種別毎に集計したものを表示できるようにしています。 また、勤怠管理サービスのジョブカンとも連携することで、社員の実働時間と結合しより正確な数値で集計しています。
集計したデータを元に、開発に割けている時間や、ミーティングの比率をマネージャーがチェックし、メンバーの生産性の向上のための指標になっています。
NotionとSalesforceを連携するためのツール
システム構成図
複数のサービス/ツール間で同様の情報を使用したい場面はあると思います。ABEJAでは、営業関連の情報をSalesforceに登録し、Notionでプロジェクトへのアサイン情報や進捗を管理しています。Salesforceの情報とNotionの情報は一部重複しているため、こちらの同期を自動化しています。手作業でデータの移行を行うと、必ずミスや漏れが発生するものですが、作成したツールを使用することで人手による工数の削減と人的ミスをなくすことに成功しました。
Googleスライドのフォントを変換するためのツール
システム構成図
こちらは、PDFやPowerPointなど他の形式の資料をGoogleスライドで開いた際にフォントの種類の差異が発生してしまうので、スライド内のフォントを一括で変更するために作成しました。全社員が簡易的に使用できるように、フォント変換ツールの実行はSlackからできるようになっています。
Slackではスラッシュコマンドという特定のアクションを行うショートカットコマンドを自作することができ、スラッシュコマンドから外部のスクリプトを実行することで、オリジナルの便利コマンドが簡単に作れます。 スラッシュコマンドを使用し、下記のようなフォームからGoogleスライドのURLやフォントの入力を行うだけでストレスなくフォント変換ツールの実行ができるようになっています。
Slackから実行できるツールは他にもいくつかあり、同様のシンプルなインターフェイスで利用できる様にしています。 ツールを使用するためのインターフェイスを簡単に使える様にするのも、長期的に使われ続けるためには重要だと思います！
開発・運用時の工夫
コードの管理方法
GASで書いたコードの管理はclaspというGoogleが提供しているCLIを使用して行います。 claspの使用方法は省略しますので、手順は公式のリファレンスを参照してください。以下、claspを使用するメリットを挙げていきます。
ローカル環境での開発が可能
GASは本来、Webエディタでしか実装することができませんが、claspを導入することで、ローカル環境で実装することが可能になります。
pull コマンドや push コマンドを使用することで、Webエディタとの同期が可能です。
ローカルで開発できるため、使い慣れたエディタで開発できることもメリットだと思います。
また、 push する向き先をローカル環境で設定することにより、開発環境と本番環境を分けた開発をすることも可能です。
コードのバージョン管理がしやすい
ローカル環境で開発することにより、Gitなどを使用したソースコードのバージョン管理がしやすくなります。
npmのライブラリが使用可能
Webエディタを使用したGASの開発では、ライブラリを使用することはできませんが、claspを使用することでJavaScriptのライブラリが使用可能になります。 Linter/Formatter/Unit Testなど、ライブラリを導入することで開発の幅が広がります。
このように、様々なメリットがあります。 claspの導入やライブラリの選定など、初めは手間がかかりますが、一度導入してしまえば他のツールにも流用することができるので、長期的に見ると開発はとても楽になると思います！
仕様・運用マニュアルの作成
ツール開発時の問題点にも記載しましたが、社内向けのツールは属人化してしまいがちです。そのため、他のメンバーが追加の機能開発や不具合修正対応ができるようにマニュアルの作成を行っています。どこまで詳細に書くかは、ツールの規模感や不具合時の影響範囲によって変えていますが、一番の目的はツールの開発がどのメンバーでもできる状態にしておくことです。 マニュアルには、以下の様な内容を記載しています。
使用方法について
実行方法について画面のキャプチャを使用して説明しています。実行時の前提条件や、手順、どの様なアウトプットが得られるかを記載しています。 利用方法を全社に共有することで、マニュアルを読むだけで必要なメンバーが利用できるような状態にしています。
詳細な仕様について
こちらはコードを触る可能性がある方向けの情報になります。内部的にどの様な処理を行っているかや、外部サービスと連携している場合は連携方法などを記載しています。 スプレッドシートを使用したツールであれば、各シートの役割やカラム/セルがどの様な役割を担っているかもこちらに残します。
開発に必要な情報
ツールの開発者向けに、実装環境構築の手順やデプロイ方法、コーディングルールなどを記載し、詳細な仕様と開発に必要な情報を確認することで、開発者なら誰でもツールの機能追加や不具合改修ができる状態を目指しています。
Linter と Formatter
GASはJavaScriptベースの言語であり、JavaScript用のパッケージを使用することができます。 Linterは、ESLintを使用し、構文エラーやコーディング規約に沿っているかのチェックを行います。 Formatterは、Romeを使用し、スペースやインデント等のコーディングスタイルを統一するために使用しています。
導入時は少し手間ですが、複数のツールを運用する場合はLinterやFormatterを導入するルールを定め、テンプレ化することでコードの品質を高めることができます。
テストコード
テスト用のフレームワークには、Jestを使用しています。 テストコードを書くことでツール開発の工数は膨れ上がるので、サクッと開発したい方向けではないかもしれませんが、規模感の大きいツールの場合や、長期的に運用することが考えられるもの、不具合時の影響範囲が大きいツールを開発する際には導入した方が良いと思います。
CI/CD
CI/CDには、Github Actionsを使用しています。プルリクエスト作成時にlintやformat check、テストが行われます。 その後、mainブランチへマージされたタイミングで、本番環境用のGASへのデプロイが行われるように設定しています。
外部サービスのアクセスキーの管理
GASを使用して外部のサービスと連携する場合、APIなどを実行するためのアクセスキーが必要になることが多いです。 アクセスキーを発行する際には、個人のアカウントから発行するのではなく社用のアカウントから発行し、社内のパスワードマネージャーで管理しています。 個人のアカウントで発行してしまうと、異動や離職を理由にアカウントを削除する際に、キーを再発行しなければいけないからです。また、セキュリティ上、キーの個人間での受け渡しを避けるために、パスワードマネージャーで管理しています。
まとめ
いくつかの項目で紹介しましたが、まとめると以下のようになります。
- 利用/開発ドキュメントの整備
- コードのバージョン管理
- code format/lint の自動化
- UnitTest の自動化
- CI/CD
ABEJAでは、社内ツールのような小規模な開発にも、普通のシステム開発と同様のフローを取り入れることにより、属人性を排除し、継続的に開発できる体制を整えています。という紹介でした！ 今後もより多くのメンバーにツールを使用してもらい、業務の効率化や人的ミスの削減に貢献できることを目指しています！
おわりに
本記事では、システム開発グループの仕事の一つの、社内向けツール開発について紹介しました。
システム開発グループのその他の業務も気になる方がいらっしゃいましたら、ABEJA システム開発グループと取り組みのご紹介の記事も読んでみてください！ ABEJAではエンジニアを積極的に募集しています。ABEJAでの開発に興味がある方はぜひお話しましょう！皆様からのエントリーお待ちしてます。
