この記事は「エンジニア組織の開発生産性・開発者体験向上の取り組みをシェアしよう！ by Findy Advent Calendar 2023」の参加記事になります。
この記事の背景
私は普段、管理画面や社内ツールをローコードで構築できる『クエリア』というサービスを作っています。
その中で、管理画面や社内ツールの課題を解決したいというお客様とお話する機会が多く、また、自分自身も同様の課題を抱えていました。
しかし、社内向けシステムの課題やその解決策などの話はあまり表に出てこず、各社それぞれ、なんとなくやりくりしているような状況なのではないかと考えています。
そこで、改めて プロダクトチームがどのように管理画面や社内ツールの開発に向き合っていくべきなのか、どうすれば上手くいく可能性を上げられるのか を私自身の考えも含めてまとめてみます。
対象読者
- 管理画面や社内ツールを作りたくても一向に進まないチームに所属している人
- 管理画面や社内ツールを作りたいけど、リソースの分配方法や進め方などで迷っている人
- 特にエンジニアリソースが切迫しているスタートアップのプロダクトチームにいる人
プロダクトチームから見た管理画面・社内ツール開発の課題
1. プロダクトのリリースサイクルが遅れる
管理画面や社内ツールの大きな課題の1つに、プロダクトのリリースサイクルへの影響が挙げられるかと思います。
どうしても、管理画面や社内ツールの開発にはエンジニアリソースが必要となってしまうため、そこを計算に入れたリリースサイクルを作れていない場合に、遅れが生じてしまうことがあります。
2. コミュニケーションの齟齬が発生しやすい
管理画面や社内ツールは主にビジネスサイドが利用するケースが多いと思います。
そうなると、課題を感じているのはビジネスサイドなので、ビジネスサイドとエンジニア間のコミュニケーションの齟齬が生まれ、お互いにストレスを感じてしまうケースも少なくありません。
特に、課題の本質が伝わらないまま、管理画面や社内ツールの開発を行ってしまい、社内リリース後に「想定していたものと違った」などの反応をされてしまうこともあります。
ビジネスサイドとエンジニア間のコミュニケーションフローが整備されてれば、こういった問題は最小限に抑えることができますが、そうでない場合、コミュニケーションの課題というのは根深い問題です。
3. エンジニアの開発体験が良くない
管理画面や社内ツールの開発は決して楽しいものではないという印象を持つエンジニアも多いと思います。
その要素として、 「毎回同じようなものを作っている」 や 「本当に役に立つのか確信が持てない」 などが挙げられます。
組織によっては、管理画面や社内ツールに新しい技術の検証という要素を取り込むことで、エンジニアのモチベーションも上げつつ、社内のナレッジを蓄積するというやり方をしている組織もありますが、スタートアップなどの余裕のない組織が取れる選択ではありません。
管理画面・社内ツールはどれほど重要なのか？
管理画面や社内ツールの開発には多くの課題が存在することは上で述べてきました。
しかし、これらの課題を解決してまで取り掛かるだけの価値が管理画面や社内ツールにはあるのでしょうか？
これは矛盾に聞こえるかもしれませんが、管理画面や社内ツールはエンジニアを楽にするものだと思っています。
管理画面があればデータ操作がエンジニアから手離れする
管理画面や社内ツールは、データ操作を民主化するものなので、今まで技術者に依存していた操作を非技術者も実行できるようにするものです。
もし管理画面や社内ツールが存在しないと、いつまで経ってもデータ操作がエンジニアに依存してしまい、エンジニアリソースを圧迫する原因となってしまいます。
便利な社内ツールはエンジニアを楽にする
また、様々な社内ツールはエンジニアの作業を効率化するために利用することもできます。
例えば、バグ調査をサポートする社内ツールを作れば、今まで色々なサービスにログインし、手動でログを見たり、データベースにアクセスしてバグの原因を探っていたところを、ログ収集APIとデータベースを統合して調査を行えるツールを構築することで、バグ調査の時間を圧倒的に楽に、効率よく行うことができるようになります。
少し前に、元Metaのエンジニアのエピソードが少し話題になりましたが、この中で社内ツールに言及されています。
彼は自分自身が感じた社内の課題を、社内ツールを開発して解決し、その社内ツールが組織内でスケールして、全体の労働時間の削減に貢献したというものです。また、このような活動がMeta社から評価され、追加のボーナスや株を付与されたそうです。
チームではバグレポートから関連した情報を抽出するのに時間がかかっていた。
それを解決するために彼はAndroidエンジニアにも関わらず、社内ツールを開発し、それが多くのチームの労働時間削減に貢献した。
管理画面・社内ツールはどのように開発するべきか
ここまで管理画面や社内ツールの課題と重要性について言及してきました。とはいえ、社内ツールの開発がうまく回っている組織は多くないと思います。
では、どのような管理画面や社内ツールを開発していくべきでしょうか？今回は組織的な観点と開発手法的な観点から考えてみます。
組織としての仕組み作り
継続的に管理画面や社内ツールを開発する上で、組織として取り組んでいくことがとても重要です。このセクションでは、組織としてどのように取り組んでいくべきかを深ぼっていきます。
1. ビジネスサイドが起票し易い体制を作ってあげる
管理画面など、社内向けのシステムの利用者はビジネスサイドであることが多いです。しかし、ビジネスサイドとエンジニアサイドには少なからずリテラシーに差があることが多いと思います。
なので、ビジネスサイドが利用しやすいツールを選び、起票できるようにしてあげることが重要です。
例えば、ビジネスサイドでも容易に利用ができるTrelloやJiraなどのツールとSlackなどと連携して、ビジネスサイドはTrelloやJiraに起票し、エンジニアが所属しているチャンネルに通知されるなどの起票システムなどが挙げられます。
2. 課題を適切にヒアリングし、開発タスクに翻訳する
ビジネスサイドからの起票があった際に、すぐに開発タスクにするのではなく、ビジネスサイドとエンジニアの間に立つ人がしっかりとヒアリングをして、エンジニアがタスクとして取り掛かりやすい形に翻訳する とうまくいくケースが多いように感じます。
主に以下のような作業を行ってあげると、ビジネスサイドとエンジニアサイドの認識の齟齬が最小限に抑えられるかと思います。
- 課題をエンジニアが理解できる形に言語化する
- 解決策を開発タスクに落とし込んで分解する
- 上記を解像度高く落とし込めるまでヒアリングを行う
GitHubのIssueになるのは、このタイミングです。
3. 適切に優先度を定める
ここでは2で落とし込んだ開発タスクをエンジニアと最終確認をしていきます。エンジニア目線で開発タスクを確認し、実現可能性があるか、過度な工数がかかるものではないか などを確認していきます。
エンジニアが課題を理解でき、開発タスクとしての解決策まで落とし込めたら、工数が見えてくると思います。
ここで、開発工数や代替手段の有無を考慮にいれつつ、適切に優先度を決めることになります。
4. 作る前や作っている途中に少しでも疑問があれば、再度ヒアリングする
いざ開発に入る際に、実装しているエンジニアが少しでも課題や解決策に違和感を感じたら、すぐに実装をやめ、再度ヒアリングに行くべきです。
課題の本質は本当に合っているか、この機能を作れば本当にその課題が解決できるのか、少しでも疑問に思ったら、社内向けのツールの場合はユーザーが社内にいるはずですので、すぐに聞きにいきましょう。
開発手法の選択
いざ管理画面や社内ツールを開発しようとなっても、開発方法は様々です。
それぞれの方法について、どういう場合に適しているかを見ていきます。
オールインワンのフレームワークを使う
もしあなたがRuby on RailsやDjangoで開発している場合、Rails AdminやDjango Adminなどが選択肢に入ってくるでしょう。
これはメンテナンス性や拡張性をある程度犠牲にできるのあでれば、すでに作ってあるモデルなどを再利用できるので、RailsやDjangoのユーザーにとって良い選択となるかもしれません。
ただ、常に技術負債という課題が付きまとう選択です。定期的なリファクタリングやライブラリのアップデートなどメンテナンスをしていく工数を許容できる場合は、この選択をとっても良いと思います。
フルスクラッチで作る
フルスクラッチと言っても、CSSライブラリ程度は利用するかもしれません。
しかし、ゼロから作る以上エンジニアリソースが多くかかってしまうことは言うまでもありません。また、社内向け特有の権限管理など複雑な実装も必要になります。
それだけでなく、デザイナー、フロントエンドエンジニア、バックエンドエンジニアとのコミュニケーションも発生し、ゼロから1つのアプリケーションを作るのと同等の工数を要します。
これらのリソースを確保できる場合は、この選択をとっても良いでしょう。
ツールを使う
この方法は圧倒的に早く、エンジニアの工数を少なく実装できることが一番大きなメリットです。
エンジニアリソースを最小限にしつつも、スピードは担保しなければいけないケースにとても向いた選択肢です。
また、リファクタリングやライブラリのアップデートなどのメンテナンスコストも大幅に削減することができます。
また、以前にもローコードで管理画面を作ることについて書いた記事がありますので、もし興味のある方がいれば見てみてください。
さいごに
今回は管理画面や社内ツールをどのように開発すべきかというテーマで記事を書いてみました。
私たちは、上で述べてきたような課題を解決するために、ローコードで管理画面や社内ツールを構築できる『クエリア』というサービスを作っています。
今管理画面や社内ツール開発が進まなかったり、これから作ろうと考えている人は無料でトライアルができますので、ぜひ一度体験してみてください。
Discussion