はじめに
こんにちは、LRM株式会社でセキュリオを開発しているアアツです👋
お久しぶりです。前回の投稿からだいぶ時間を空けてしまいました。
本記事では、私が新卒1年目に約10ヶ月をかけて取り組んだ「LINE WORKS×セキュリオ通知連携」の開発について、振り返りながらまとめていきます。
機能についてひとことで言うと、eラーニングの受講依頼や催促通知など、セキュリオからの通知をLINE WORKSで受け取れるようにするものです。2026年1月にリリースしました！詳しくは下記のプレスリリースをご覧ください😃
背景
なぜ今のタイミングでこの記事を書いているのか。
理由はシンプルで、2年目に入り少しだけ余裕を持って1年目を振り返れるようになったからです。約10ヶ月の実装期間、3〜4回もの実装の作り直し、認証の壁にぶつかり、関係者の多さに驚かされつつも、無事にリリースできた──その過程は、一度ちゃんと言葉にしておきたいと思いました。
概要
今回実装したのは、セキュリティ教育クラウド 「セキュリオ」 と、ビジネスチャットツール 「LINE WORKS」 を連携させ、セキュリオからの各種通知をLINE WORKS上のチャットに届ける機能です。
LINE WORKS側のアプリケーションは、LINE WORKSサービスパートナープログラムに参加することで利用できる App Console から作成しました。
管理者がLINE WORKSでアプリを有効化し、実際に通知が届くまでの流れを簡単に図にまとめました。
LINE WORKS連携のシーケンス図
詳細
入社数ヶ月、突然のチャンス
2025年4月、開発チームのロードマップ会議で、部長から「LINE WORKS連携、やってみる？」と声をかけていただきました。入社して間もない自分にそういった機会を任せてもらえること自体が、今思えば大きなターニングポイントでした。
LINE WORKSサービスパートナープログラム参加への道のり
LINE WORKSとの通知連携を実現するためには、まず「LINE WORKSサービスパートナープログラム」に参加する必要がありました。
サービスパートナープログラムとは、LINE WORKS公式サイトで次のように説明されています。
お客様がLINE WORKSファミリー製品をより便利に活用するための各種サービス（連携アプリケーション、連携ソリューション及び関連サービスを含む）を提供する企業を対象に、LINE WORKSファミリー製品の価値提案の協業を推進します。
（出典: LINE WORKS サービスパートナープログラム）
ざっくり言うと、LINE WORKSのアプリディレクトリに自社サービスを掲載し、LINE WORKSと連携した機能をお客様にお届けするための協業支援制度 です。今回のセキュリオからLINE WORKSへ通知を送る連携も、この枠組みの中で実現しています。
恥ずかしながら、入社して間もない私にとって、サービスパートナープログラムという言葉自体、それまで耳にしたことのないものでした。
このプログラムに参加するためには、約款の確認、社内稟議、関係各所との調整、そしてLINE WORKS様への申請といった、いくつかのステップを踏む必要がありました。普段の開発業務とはまったく異なる種類の準備を、一つひとつ進めていきました。
幸い、この工程を一人で担ったわけではありません。上司や先輩、関係部署の方々が必要な手続きを丁寧に伴走してくださり、何をいつまでに進めるべきかを共有しながら、着実にステップを踏んでいきました。
普段はコードを書くことが中心の自分にとって、エンジニアの仕事は技術を形にすることだけでは完結しない──お客様や提携先との関係づくりそのものが、サービスを世に出すための土台になっているのだと体感できた、貴重な時間でした。
そして、無事に締結が完了しました。ここから、いよいよ実装が始まりました。
認証実装の壁 — Developer Console と App Console
通知連携の実装で、最初に立ちはだかった壁が 「認証」 でした。Service Account認証（JWT）を使ってAccess Tokenを取得し、Bot APIを叩く──文字にするとシンプルですが、実際には3〜4回も実装を作り直すことになりました。
LINE WORKSの公式ドキュメントを最初に開くと、多くの場合 Developer Console を前提とした手順が目に入ってきます。しかし、私たちのようにLINE WORKSサービスパートナープログラムに参加し、LINE WORKSの アプリディレクトリに自社サービスを掲載する 立場で開発する場合、使うのは App Console の方です。
App Consoleはサービスパートナープログラムに参加した後にはじめて閲覧できる管理画面で、ここでアプリの作成・各種クレデンシャルの発行を行います。
正直に言うと、当時の私はこの違いをすぐには理解できませんでした。ドキュメントの該当箇所を読んでいるつもりでも、自分のユースケースとは異なる章を読んでいた──そんな状態が、しばらく続いていました。
実装を進めている途中で、想定通りに動かない場面が何度もありました。JWTの署名エラー、スコープの設定ミス、トークンの有効期限、Bot IDとService Account IDの取り違え……踏める罠は全部踏み抜いた、そんな状態でした。仕様書を腰を据えて読み込むよりも先に、まず手を動かしてしまう──いわゆるトライアンドエラーに近い形で実装を進めてしまっていたことも、振り返れば大きな反省点です。
一人で抱え込まずに済んだこと
幸いだったのは、一人で抱え込まずに済んだことです。社内の先輩エンジニアには、ホワイトボードの前で一緒にフローを整理してもらったり、オンラインでも何度もミーティングを設定していただいたりしながら、認証フローについて繰り返し話し合いました。それでも解けない部分は、LINE WORKS様にも質問させていただきました。
今振り返ると、認証の壁を越えられたのは、間違いなく 「人に頼ることを恐れなかった」 ことが大きかったと思います。
「動くコード」と「理解しているコード」
作り直しを繰り返すなかで、自分のなかで一つの確信ができるようになりました。それは、「動くコード」と「理解しているコード」はまったく別物だ ということです。
コピー&ペーストで動いてしまうコードは、動いた瞬間は嬉しいのですが、少し要件が変わった途端に崩れます。逆に、なぜその実装なのかを自分の言葉で説明できるコードは、壊れてもすぐに直せます。
この感覚を手に入れられたことは、認証まわりで何度も作り直した経験からの一番大きな学びでした。
リリースと達成感
LINE WORKS様と何度も日程を擦り合わせながら準備してきたリリースの日が、いよいよやってきました。
そして迎えた 2026年1月29日。セキュリオでLINE WORKS連携が、ついに本番リリースされました！🎉
10ヶ月かけて積み上げてきたものが、ようやく本番環境で動き始めた瞬間でした✨
実装期間を通して 最も 達成感を感じたのは、初めて本物のテナントに通知が届いたのを確認できたとき でした。開発環境やテスト用の自テナントで通知が動くことは、それ以前から確認できていました。しかし、本番のお客様テナント宛にメッセージが届く瞬間の感覚は、それまでとはまったく別物でした。
何度もrevertして、書き直して、ようやくたどり着いた認証フロー。何度も先輩やLINE WORKS様に助けていただいた設計。そのすべてが、たった一通のLINE WORKS通知としてお客様の手元に届く──画面の向こうに人がいるんだ、ということを、これほどリアルに感じた瞬間はありませんでした。
そしてもう一つ、リリース日にアプリディレクトリ上で公開作業を完了させたときの 「やり切ったぞ」 という気持ち。これは、作っている最中には決して味わえない種類の達成感でした。
形にして、世に出す
エンジニアの仕事の醍醐味は、やはり 「形にして、世に出す」 ところにあるのだと思います。
10ヶ月のあいだに何度つまずいても、何度revertしても、最後にこの瞬間が待っているのなら、すべての試行錯誤に意味があった。心からそう思えるリリースでした😊
「届ける」までに関わる人たちと、「なぜ」を考える姿勢
リリースを迎えて、もう一つ強く印象に残っていることがあります。それは、作ることと、お客様に届けることは、別の仕事だ という気づきでした。
そもそもLINE WORKS連携は、お客様からの強いご要望をきっかけに動き出した機能でした。特に 医療系の企業様を中心に、「セキュリオの通知を、業務で日常的に使っているLINE WORKSで受け取れるようにしてほしい」という声を多くいただいていました。
要望が現場の営業からPdMに渡り、優先度が議論されてロードマップに乗り、そして実装担当として私のところに「やってみる？」と回ってきました。いま振り返ると、私が「やります」と返事をしたあの瞬間には、すでに多くの人の手を経たバトンを握っていたのだと思います。
ところが当時の私は、リリース直前に 広報担当者へのプレスリリース依頼の声がけがかなりギリギリになってしまった という、スケジュール管理の甘さを露呈してしまいました。理由はシンプルで、それまでの私は「開発」のことしか視界に入っていなかったからです。
実際は、機能が一つお客様の手元に届くまでには、こんなにたくさんの人が関わっていました。
- お客様から要望が届く
- 営業がその要望を受け取り、現場の声として整理する
- PdMが要望を取りまとめ、ロードマップに落とし込む
- エンジニア（私）が設計・実装する
- 広報が世の中に向けてリリースを発信する
- CSがリリース後の問い合わせや活用支援を担う
書き出してみると、本当に多くの人の手を経ていることがわかります。当たり前のことなのかもしれません。けれど、入社1年目で開発に没頭していた私にとって、これは結構な発見でした。
「なぜ」を「自分の言葉」で考えるエンジニアへ
この経験以降、私の中で大きく変わったことがあります。それは、「なぜやるのか」を必ず自分に問うようになった ことです。
それまでの私も、「ただタスクをこなせばいい」と思っていたわけではありません。それでも、自分の実際の動き方を冷静に振り返ってみると、結果的に「渡されたタスクを順番に実装していく」だけになってしまっていた──そんな1年目でした。
機能の一つひとつにも、工程の一つひとつにも、必ず「なぜ」が存在します。なぜこの機能を作るのか。なぜこのタイミングでリリースするのか。なぜ広報に共有するのか。なぜCSに仕様を渡しておくのか。
大切なのは、その「なぜ」を 自分の言葉で言語化できる状態にしておく ことだと、今は思っています。
なぜなら、「なぜ」がずれていると、課題の捉え方もずれ、作るものもずれてしまうからです。結果として、お客様が本当に求めていたものとは違うものを作ってしまい、使われない機能になってしまう。それを防ぐために、誰に対しての課題なのか、なぜそう思うのか、なぜ今やるのか──を一つひとつ深掘りしていくことが大切だと、今は強く思っています。
1年目の私に決定的に足りなかったのは、まさにこの 「なぜを言語化しておく姿勢」 でした。
おわりに
最後に、この場を借りて感謝を伝えさせてください。
今回のLINE WORKS×セキュリオ通知連携は、私ひとりの力で実現できたものでは到底ありません。声を届けてくださったお客様、要望を拾って社内につないでくれた営業、優先度を判断してくれたPdM、実装で支えてくれた先輩エンジニア、リリースを世に届けてくれた広報、そして導入・活用をサポートしてくれたCSまで──本当にたくさんの方々の協力があって、はじめて形になりました。改めて、関わっていただいたすべての方々に感謝しています。
そしてこの記事を読んでくださっている方へ、二つだけ伝えたいことがあります。
一つ目は、恐れずに挑戦してほしい ということ。うまくいかないことだらけで、何度も作り直して、心が折れそうになる瞬間もあるかもしれません。でも、手を伸ばしてやってみたからこそ、得られるものが確かにあります。
二つ目は、「なぜ」を「自分の言葉」で常に考えてほしい ということ。実装の前に、機能の前に、なぜ今これをやるのかを自分の言葉で言語化しておく。それだけで、日々の判断の質がまったく変わってきます。
挑戦することと、「なぜ」を考えること。この二つは、きっとあなたの大きな財産になると、私は信じています👍
参考
Discussion