Slack社審査済みアプリ!社内プロフィール共有サービス「プロフちゃん」をリリースしました!
はじめに
今回ようやく個人開発のサービス「Slack App 社内プロフィール共有サービス プロフちゃん」をリリースしました!!
【本サービスサイト】
【Slack App Directory】
showprofilede-lr12072.slack.com
【Twitterアカウント】
【githubアカウント】
【Qiita記事】
使い方や作った経緯、苦労したことなどはQiitaの記事に投稿しましたので是非ご一読下さい!
今回のアウトプットブログではQiita記事の内容とは異なり、本サービスの制作過程を大まかに説明したいと思います。
経緯
社内プロフィール共有サービスというあまり聞かないサービスの種類かなと思いますが、なぜこのようなサービスを作ったのでしょうか?作った背景を簡単に説明したいと思います。
コロナによってたくさんの会社がリモートワーク体制をとり、同僚や先輩後輩社員と会う機会が大きく減少しました。今までは会うことが当たり前だった会社の人と会うことがなくなり、以前は出社すれば必ず話す仲だったにもかかわらず、今ではZOOM会議でのしごとの話ばかりで、全くプライベートの話をする機会がない人も多くいると思っています。
コロナが始まった頃はリモートワークによって自由な時間が増えることや通勤ラッシュに巻き込まれないというメリットがよく挙げられていましたが、現在ではほとんどの人がリモートワークに不満を持っています。特に、会社の人とのコミュニケーションの減少はリモートワーク最大の不満となっています。
コロナウイルスは「会社員と話すことができる」という当たり前の幸せを多くの人から奪ったのです。
実のところ私は現在ほとんどリモートワークをせず出社しています。所属している課が24時間体制ですので、必ず出社をする人がいなければいけないためです。幸運かどうかはわかりませんが、会社の人とのコミュニケーション不足はありません。
しかし、課の中にはシフト体制ではなく日勤体制で働く人もいて、その人たちは完全フルリモートです。そしてフルリモートで働く人たちとは働き始めてから1年半経つにもかかわらず、ほとんど話したことがありません。何が趣味で何が好きでどう仕事をするのか全くわかりません。
「出社する人たちについて何が趣味で何が好きでどう仕事をするのか当たり前のように知っているのに、、、、」
このシフト体制という特異な環境がどれほどリモートワークで社員を知る機会が失われているかを知ることができました。
このような体験から「社員を知る機会」をリモートワーク体制の会社にあればいいなと思いました。そこで思いついたのが社員プロフィール共有サービスです。社内の人が何が趣味で何が好きかなどが記載されているプロフィールを共有しておくことで、少しでも他の社員を知ることができ、雑談のきっかけになればいいなと思いました。
技術選定
社内プロフィール共有サービスという作るものが決まったので、それを作る上でどの技術を使用するのかを考えなければいけません。
バックエンドですがこれはカリキュラムで学習してきたRuby on Railsしか考えられませんでした。RUNTEQのカリキュラムはとても難しくたくさんの学びがありましたが、カリキュラムで1,2ヶ月勉強した程度の学習時間では全然足りないと感じていました。まさにRailsが「全くわからない」状態でした。理解をより深める上でも個人開発でrails newをしてRailsへの理解を深めたいなと思いました。また、Railsは短期開発に非常に向いているため、短期間で開発して早くユーザのフィードバックを得たかった自分にもマッチしていました。
次にフロントエンドとなりますが、最初はJQuery、もしくは生のJSにしようと思っていました。RUNTEQではVue.jsを学習することもできるためVue.jsを使う選択肢もありましたが、「使う理由」がなかったためVue.jsを新しく学習する必要性がありませんでした。しかし、最終的にはVue.jsを使うことになりました。
Vue.jsを使うと決めた理由はプロフィール共有サービスは入力することが多いサービスになることが想定できたからです。ユーザ(社員)が多くの情報をプロフィールに残して置いて欲しかったため、プロフィール入力をする際は「ストレスなくサクサク動く」ことが重要だと思いました。そのため、Vue.jsを使用することでユーザ体験をあげようと思いました。
※最も人気の高いReactも考えたのですが、学習コストが高いため事前学習がかなり必要だと感じ、時間がかかってしまうのでやめておきました。
そしてこのサービスの根幹であるSlack API。サービスを作ろうと考えた時に「社内プロフィール共有」という機能をどう実現させるかを考えていました。他の会社の人には見られることなく車内だけでどう共有させればいいのか、、。そこで思いついたのがSlackログインです。Slackと連携してワークスペースごとにユーザがログインできれば、ワークスペースに参加している人とのみプロフィールを共有することができます。また、社内SNSでSlackを使用している会社はかなり多いので、会社がターゲットである本サービスにはマッチしていると思いました。
まとめると以下の3つの技術を重点的に使用することが決まりました。
- Ruby on Rails(API)
- Vue.js
- Slack API
Slack APIがわからん!(開発初期)
開発初期というよりは、開発をする前の段階になりますが、3月はVue.jsとSlack APIの事前学習をメインにやっていました。上記2つの技術についてはほとんど知識がなかったので、開発を始める前にある程度の知識をつけておきたかったためです。
Vue.jsは学習コストが低いと言われているだけあって、予想よりも早く事前学習が終わりました。しかし、Slack APIの学習はだいぶ詰まりました。そもそもSlack APIはよく使われる技術ではありません。そのため、日本でSlack APIを使用したサービスがそこまで多くなく、Slack APIに関する記事数は圧倒的に少なかったです。
そのためほとんど公式のドキュメントを使用して手探りにAPIの使い方を学んでいくのですが、Slack APIは他のAPIに比べて少し複雑です。例えば、APIにアクセスする情報の範囲のことを「スコープ(Scope)」というのですが、他のプロバイダー(Twitter, GitHub, etc.)ではそのスコープが3, 4種類なのですが、Slackは30種類以上あります。
そして、どのスコープを使うかによって使えるAPIメソッドも分かれています。例えば、channels:read
というスコープを使うとchannes.info
(チャンネル情報を取得するメソッド)とchannels.list
(ワークスペース内のチャンネル一覧情報を取得)が使えるようになります。
上述したようにスコープの数が本当に多いのでAPIメソッドもその分多くなっていて、理解するのに本当に苦労しました。
Qiita記事でも書いたのですが、Slackログインに関するRailsへのサポートがかなり少ないと思っています。下記のGemがomniauth-slackというSlackログインのGemなのですが、Star数が32と少なすぎるんですよね。。
また、1番苦労したこととしてはRailsを使用したSlackログインです。約1ヶ月と長いこと悩まされました、、、。
omniauth格差がここに顕在しているように、Slackログインへのサポートが少なすぎます。。
GitHub - arunagw/omniauth-twitter: OmniAuth strategy for Twitter
それに比べてomniauth-twitterは569個もあります。
GitHub - ginjo/omniauth-slack: omniauth-slack ruby gem
ちなみにomniauthを使わずにsorceryのexternalモジュールを使う方法があると思うのですが、それもできませんでした。理由はsorceryの中のslack.rbが2016年より更新されていないためかと思われます。単純に古かった。。
余談ですが、ポートフォリオを作り終えた後GitHubログインをsorceryで実装する機会があったのですが、Slackは1ヶ月悩んだのに対し、GitHubはたったの2時間で実装できました。。。Slack、恐るべし、、!
その時の記事↓
お、お、わかる!書けるぞ!(開発中期)
開発中期は非常にコードを書くのが楽しかったをよく覚えています✨
というのもSlack APIで覚えること多すぎたのとひたすらSlackログインでつまずいていたので、普通に開発できるのがとても楽しかったんだと思います。あと、RailsやVue.jsの基礎がある程度身についていたのもあって、今までは調べてからコードを書いていたことがほとんどだったのが、何も調べずにかけることが多くなっていたことに成長を感じていたんだと思います。
特にこの段階で大変だったことは、本アプリのDB設計だったと思います。このアプリは未経験エンジニアのポートフォリオの中ではかなり複雑なDB設計をしていると思います。
特に図の真ん中周辺のhoge_blocksg
がたくさん並んでいるところとかが難しかったですね、、。詳しくはRUNTEQの講師とやりとりがある下記issueをご覧ください。
プロフカードのモデル設計 · Issue #41 · SakitaDaiki0623/prof-chan
開発後期
ある程度の開発も終わったところで、一度RUNTEQの中だけでリリースしてみました。その中でフィードバックをもらい修正をしていざリリースとなったのですが、ここで少し思ったことがありました、、。
「Slack API、理解しているの自分だけで大丈夫か?」
Slack APIはかなり多くの情報にアクセスできてしまいます。ですので、取得するのをやめておいた方がいい個人情報もきっとあって、未経験としてはかなり取り扱いが怖いです。ですので実際にこのアプリがSlack Appとして機能しているのか、問題がないのかを確認するために実際にSlack社にレビューしてもらいました。
Slack Appは提出をすることで実際にSlack社の人からアプリについて問題がないか審査いただけます。ただこれがかなり待ちます。7月に提出してすぐ帰ってくると思ったら気がつけば8月になっていました、、、。
提出してから1ヶ月半経ってようやくレビューが始まりました。しかし、すぐに審査が通るわけでもなくいくつかの修正を依頼されました。Slack上でアプリを使用する際にいくつかのバグが発覚しました。自分だとそこまで気づかない、、、。修正して再提出したらまた修正依頼。これが一週間ほど続きました。
最終的に自分のアプリはレビューを通過できました!!!長かった、ようやくリリース、、!
終わりに
実はここまで長い時間をかけても、開発当初、自分がしたかったことの50%も達成できていません。
というのもSlack APIへの理解に時間をかけすぎましたね💦 本当はコメント機能やら感情分析やらをプロフィールに反映できるようにしたかったのですが、あまり長くは開発するつもりはなかったのでリリースしました。
ただ、やはり個人開発を経験した今の自分とカリキュラムを完了しただけの自分はまったく違うと思います。カリキュラムで学んだことを実際に個人開発でアウトプットすることで理解を深めることができましたし、開発の手順がある程度理解できたので次に何かを開発するときにその手順を思い出して早く開発できるようになりました。
これからようやく転職活動ですが、本当にこれからがエンジニアの人生のスタートなのだなと考えると本当に感慨深いです。この1年間ずっと頑張ってここまでこれました。自分が入る会社はどんな会社なのか非常に楽しみです!
使用技術
バックエンド
機能における主要なGem
- devise(ログイン)
- ginjo-omniauth-slack(SlackAPI OAuth)
- pundit(認可)
- carriwave(画像アップロード)
- whenever(定期実行)
- administrate(管理画面)
フロントエンド
- Vue.js
- Tailwind CSS