事業と組織の急成長を後押しするコーポレートエンジニアが実践している「ITIL4×Jira」による継続的改善

こんにちは！株式会社ニーリーでコーポレートエンジニア（以下、CE）をしている小島拓也です。この記事はニーリーアドベントカレンダー2025 の5日目の記事です！

ニーリーは「社会のインフラ」を創るべく、駐車場オンライン契約サービス「Park Direct」を展開し、ありがたいことに事業も組織も急成長しています。
そんな「Park Directを支えている人」を支え、社内のIT基盤を運用保守しているのがコーポレートエンジニアです。

この記事は、そんなコーポレートエンジニアが今年一年で取り組んだ、社内のIT基盤の課題をITIL4の考え方を取り入れ改善のサイクルを回し始めたふりかえりのお話です。

ITIL4導入前の"運用"という名の課題
なぜITIL4だったのか？：「継続的改善」への共感
私たちの「ITIL4×Jira」改善プラクティス
改善がもたらした「チームの変化」
展望：事業成長に先回りする、"攻め"のコーポレートITへ
私たちと一緒に「最強のコーポレートIT」を創りませんか？

ITIL4導入前の"運用"という名の課題

改善を始める前、私たちのチームはいくつかの課題を抱えていました。その中でも代表的だった3つを紹介します。

1. 人に依存した「場当たり的」な問い合わせ対応
従業員からの問い合わせ窓口はSlackチャンネルに統一されていました。しかし、そこにはナレッジが蓄積される仕組みがなく、過去に誰かが回答したはずの同じような質問に、CEメンバーが都度、調査・回答していました。

こういった場当たり的な対応が基本で、回答後のナレッジ化や、インシデントとして起票するフローもなく、すべてがCEメンバーのマンパワーとスキルに依存していました。

2. 手作業キッティングと山積みの返却PC
PCのライフサイクル管理も大きな課題でした。
入社対応のキッティングはほぼ手作業で、セットアップに多くの時間を費やしていました。

さらに深刻だったのが「返却PC」です。
退職やPC交換で返ってきたPCがオフィスに山積みになり、「どのPCが」「どういう状態で」「次に何をすべきか」が全く管理されていない状況でした。

3. 高度な仕組み化の先で直面した、タスクの「量」と「滞留」という新たな壁
SaaSアカウント管理（発行・停止）については、実はITIL4導入前からJira Service Management (JSM) を活用した非常に高度な仕組みが、当時のメンバーによって構築されていました。

これは私たちの自慢の一つなのですが、例えば入社申請が1件JSMで上がると、単にCEのタスクが1件起票されるだけではありません。
申請内容（職種や所属など）に応じて、その人に必要なSaaS（多い人では10個近く）を自動で判別。さらに、SaaS毎に異なる手順書リンクや、担当者の自動割り当て、果ては労務チームが行うべき作業まで、入社に必要なタスクの大部分が、自動的に複数のチケットとして整理・起票される仕組みが整っていました。

これだけでも、多くの企業にとっては一つのゴールとも言える状態だったかもしれません。

しかし、ニーリーの急激な事業成長は、この優れた仕組みのキャパシティを超え始めました。

毎月20件前後の入社対応がコンスタントに発生し、それに加えて通常のアカウント追加・削除リクエストが重なります。結果として、自動化・整理されたはずのチケットが、今度は膨大な量となって積み上がっていったのです。

ニーリーはハイブリッドワークを採用しており、「隣の人が何をやっているか」が見えづらい環境です。いくらタスクが自動で割り当てられても、

「その人が今、何件のチケットを抱えているのか？」
「担当者が気づいていない、あるいは他の業務で手が回らず滞留しているチケットはないか？」

これらをチーム全体で把握することが困難になっていました。仕組みはあっても、その運用が量に追いつかず、再び属人化とタスク漏れのリスクが顔を覗かせていたのです。

なぜITIL4だったのか？：「継続的改善」への共感

これらの属人化・カオス化した状況を「なんとかしたい」と考えたとき、私たちが指針としたのがITIL4でした。

ITIL4とは簡単に紹介すると「従来のIT運用管理の効率化に加え、ビジネス部門と連携して新たな「価値」を継続的に創出するための指針や様々なプラクティスを紹介しているものになります。
ITIL4には様々なプラクティスがありますが、今回私たちが最も意識したのは「継続的改善 (Continual Improvement)」という考え方です。

「完璧な仕組みを一度で作る」のではなく、「まず現状を把握し、ボトルネックから改善し、それを測り、次の改善につなげる」というアプローチが、急成長し変化の激しい当社の状況に最適だと感じました。

そのため、まずは改善サイクルを回すことを当たり前にしつつ、各課題にあった指針やプラクティスをトライアル＆エラーで取り入れて課題を解決、コーポレートエンジニアの成果を大きく前進させることができました。

私たちの「ITIL4×Jira」改善プラクティス

ITIL4の考え方をベースに、具体的に以下の改善を行いました。

【改善1】サービスデスク：「Jira AI」による一次回答と「問題管理」への型化

私たちはまず、「サービスレベル管理」「サービスデスク（問い合わせ対応）」に着目しました。

「CEは従業員にどのようなITサービスを提供すべきか？」を定義し、現状のサービスレベルを把握することでCEの立ち振る舞いは間違っていないのかを再確認すると、クリティカルな課題（＝属人化とマンパワー依存）としてまず上がったのが「サービスデスク（問い合わせ対応）」です。

サービスデスクでは、Slackでの場当たり的な対応を撲滅するため、以下のフローを構築しました。

AIによる一次回答:
JiraのAI機能（Jira Service Management Virtual Agent）をSlackと連携。問い合わせに対し、AIがまずナレッジを検索し、自動で一次回答します。
対応フローの型化:
AIが回答できなかったもの（＝ナレッジがない or 複雑な事象）は、インシデントとしてJiraチケットを起票します。
定例会議での仕分け:
起票されたインシデントはCEの定例会議でレビューします。

これは根本対応が必要か？ → 「問題管理」プロセスに回し、詳細調査を行う。
これはFAQとして蓄積すべきか？ → 「ナレッジ管理」プロセスに回し、マニュアルを作成する

サービスレベルのチェック（健康診断）:
上記のような対応や、人による問い合わせ対応が、従業員の業務を中断させる要因になっていないか、対応時間や解決時間の計測と可視化。

このフローにより、問い合わせ対応が「ただ答える」作業から、「ナレッジを生み出し、AIにより自動で問題を解決する」という生産的な活動へと変わりました。

【改善2】PC管理：自動化とフロー化による属人性の撲滅

次に着目したのがPC管理です。当社は従業員が増加し続けておりPCの継続的な調達が続いております。
また、リモートワークや出社もいるハイブリッドワークということもあり、PC利用者はオフィスにいるがCEは自宅におりすぐに新しいPCが用意できない、というような故障時の対応に追われるケースも多くありました。
そこで、手作業だったキッティングと、山積みだった返却PCにもメスを入れ、デバイスのライフサイクル管理を改善しました。

キッティングの自動化:
Jamf (MDM) とスクリプトを導入し、PCを渡すまでのキッティング工程を大幅に自動化・効率化しました。
デバイスのライフサイクル管理見直し：
PCが必要になったタイミングから、返却、修理、廃棄といったパターンの洗い出しと整理を行い、それを元にJSMを使ったチケット自動作成やステータス管理＆可視化により、抜け漏れの無い運用を行い、フローとマニュアルも整備しました。

これにより、誰が対応しても、キッティングや返却されたPCが素早く効率的に次のステップに進むようになりました。

【改善3】タスク管理：「可視化」×「Jiraスプリント」で"量の壁"を超える

あの高度なJSMの仕組みがあってもなお発生した、膨大なタスク量と滞留という課題。私たちはこれに対し、ITIL4の「継続的改善」とアジャイルの考え方を取り入れ、Jiraの機能をさらに活用することで立ち向かいました。

ダッシュボードによる徹底的な可視化: Jiraのダッシュボード機能で、「チーム全体のチケット状況」「メンバー個々の抱えているタスク」「期日超過チケット」をリアルタイムで可視化しました。「誰が」「何を」「どれだけ」持っているか、ハイブリッドワークでも一目瞭然です。
アジャイル（スプリント）の導入: CE業務にまだ試行錯誤中ですがJiraのアジャイル（スプリント）機能を取り入れました。これにより、今やるべきタスクが明確になり、タスクの粒度を調整することで、特定タスクがスタック（滞留）するのを早期に発見できるようになりました。
リマインドと定例の型化: ダッシュボードで滞留を発見したら、担当者への自動リマインドや、チーム内でのフォローが即座に行える文化を醸成しました。また、定例会議でのタスク確認も型化し、抜け漏れを最小限に抑えています。

これにより、せっかくの自動化・整理の仕組みが、膨大な「量」によって機能不全に陥ることを防ぎ、安定したサービス提供を継続できる体制を再構築しました。

改善がもたらした「チームの変化」

これらの改善活動（まだ道半ばですが）によって、CEチームには明らかな変化が生まれました。

何よりも、タスク漏れや従業員からの問い合わせ対応漏れが圧倒的に減りました✨

ハイブリッドワーク環境下で「誰が何を抱えているかわからない」という状態が解消され、ダッシュボードで常に状況が可視化されています。もし担当者が休んでも、他のメンバーが自然にカバーできる体制が整いつつあります。

そして、最も大きな成果は、業務の課題や非効率な部分が可視化され、チームでお互いに「もっとこうしよう」と改善点を出し合うことが自然なサイクルになりつつあることです。

展望：事業成長に先回りする、"攻め"のコーポレートITへ

私たちは「継続的改善」の歩みを止めません。

これからは従業員の生産性を最大化し、事業成長を加速させる"攻め"のコーポレートITとして様々な挑戦をしたいと考えています。

私たちが描く未来は、大きく分けて2つあります。

1. AIと自動化による「究極のセルフサービスポータル」の実現

現在のJSM（リクエスト）とSlack（問い合わせ）という2つの入り口がある状態から、さらに一歩進んだ従業員体験（EX）の向上を目指します。

目指すのは、「従業員がITの利用を意識すらない」状態です。

例えば、Slackでの「〇〇のSaaSを使いたい」という何気ない投稿に対し、AIが意図を汲み取り、JSMの申請チケットを下書きし、本人に提示する。上長の承認後、バックエンドでRPAやAPI連携が走り、自動でアカウントが発行され、PCに必要なソフトウェアがプッシュ配信される…。

このような、人の手を介さない「ゼロタッチオペレーション」を拡大することで、従業員はリードタイムなく本来の業務を開始できます。そして私たちCEは、その自動化によって創出された時間で、より付加価値の高い企画や戦略的な業務にリソースを集中できるようになります。これは単なる効率化ではなく、全社の生産性をブーストするための重要な戦略です。

2. 事業分析とサービスデザインの高度化による"先回り"

ニーリーの事業成長は非常に速く、従業員数は増加し続け、Park Directに続く新たなプロダクトも生まれています。この変化の激しい環境で、CEが後追いの対応に終始していては、事業のボトルネックになりかねません。

そこで私たちは、ITIL4の「事業分析」「サービスデザイン」といったプラクティスを本格的に導入・高度化していきたいと考えています。

これまでは、人的リソースの制約もあり、既存SaaSを網羅的に使いこなすための横断的な提案や、事業部の細かな業務フローに入り込んだ分析までは、手が回らない部分もありました。

今後は、CEから事業部へ積極的にアプローチし、