KINTOとKINTOテクノロジーズのヘルプデスクが連携した（していっている）お話

はじめに

こんにちは！KINTOテクノロジーズ（KTC）のコーポレートITグループに所属するTKGです。

普段はコーポレートエンジニアとして「サービスデスク・オンボーディング運営」を行っています。

先日、「KINTOテクノロジーズ MeetUp！～情シスによる情シスのための事例シェア4選～」というタイトルで「コーポレートIT領域に特化した、事例発表＋座談会形式の勉強会」を開催しました。

今回は、その勉強会で事例発表した内容について、補足を交えながらご紹介します！

まずは発表資料

発表資料についてはSpeaker Deckに格納しております。

KINTOとKINTOテクノロジーズのヘルプデスクが連携した（していっている）お話 - Speaker Deck

テーマ選び

私は現在、KTCとKINTOの両方の籍を有しており、その両方でヘルプデスク領域を担当しております。

その中で何か発表したいと考えていたときに、親しい会社同士でどんな連携をしているのか？という事例はあまり目にした記憶がなかったので、テーマとして選びました。

正直、「映え」るようなことはしておらず、この内容を発表してもよいのだろうか。。。という葛藤はありました。

ですが、そういうネタこそ発表すべき！と自分を奮い立たせて内容をまとめていきました。

KINTOとKTCについて

KINTOとKTCの連携の話。となると関係性からお伝えするべきと考えました。

両社の関係はわかりづらいな。と入社前からも入社後もずっと思っていたので、その立ち位置から説明させてもらいました。

親子会社ではなく、兄弟会社であること。また、その生い立ちについてざっくりと解説させてもらっております。

KTCはKINTO向けの開発のみをしている・・？とも思われることもありますが、親会社であるトヨタファイナンシャルサービス（TFS）向けや、一般顧客向けのアプリ（myroute、Prism Japan）の開発もしております。

IT環境は両社でかなーり異なります。

上記の簡易カオスマップ上ではKINTOもフルクラウドのように見えますが、基幹系のシステムは社内NW上にオンプレで動いております。

なお、KTCは社内NW自体ありません。各拠点は独立しております。弊社室町オフィスは7F・16Fに拠点があるのですが、それぞれ独立しております。

オンプレの機器は、各拠点のNW機器と複合機のみとなります。

両社のIT部門の構成になります。

KINTOはサービスデスク（ヘルプデスク）とインフラ管理（ITサポート）の2つに分かれているのに対して、KTC側は5つに分かれております。

今回お話するのは、私が担当しているKINTO側の「ヘルプデスク」。KTCの「Tech Service」になります。

ともにヘルプデスク業務を担っている部門になります。

KTCの各組織の役割については、それだけでも複数記事になるレベルなので、ここでは省略させてもらいます。

以上がKINTO、KTCの関係のお話になります。

エピソード1. 問い合わせの窓口に両社でJira Service Management（JSM）を導入したお話

KTCではJira Software（Jira）を利用して問い合わせの受付をしておりました。

当初はうまく回っていたのですが、従業員が増えるにつれて、従来のJiraでの運用では不具合が出てくるようになりました。

課題としてはチケットが自由記述のみで記載者・ヘルプデスク双方で負荷になっていること。ヘルプデスクでのステータス確認やセンシティブな内容の受付ができないことがありました。（問い合わせ窓口のJiraは全社員に公開されておりました）

カスタムしていくことで、これらの課題解消もできたとは思うのですが、ここに工数を割くのではなく、専用のITSM（IT Service Management）ツールを導入し、よりスタッフがエンジニアリング（本来為すべき業務）に集中できる環境に近づけていく。と決まりました。

ツールについてはいろいろと比較検討もしたかったのですが、使える時間は限られていた中で、社内でAtlassian社の製品が使われており、親和性を考えてJira Service Management（JSM）を使っていくことにしました。

10ライセンスが1年間無料利用可能で検証のしやすさがあった。というのもポイントでした。

当初はKTCのみでの導入の流れではあったのですが、KINTO/KTCで連携を進めていた中でKINTOでの課題感も知り、両社で協力して進めていく流れになりました。

導入についてはKINTOから実施しました。

まず「早く勝てる」KINTOで導入・運用実績を作り、それらを活かしてKTCで展開を進めました。

KINTO導入に際しては大きな懸念もなく進められたのですが、KTCでは導入にあたって複数懸念がでてきました。

当時具体的に出てきた懸念としては、下記が上げられます。

Q1. アカウント発行、権限変更等のサービスリクエストにおいて、他のリクエストを参考にできなくなると労力がより大きくかかってしまうのでは？

A. JSMではサービスリクエストの種類ごとに最適化したフォームを作成できるため、他のリクエストを参考にする必要自体がない

Q2. （全員が申請できるため）マネージャの許可なしでのサービスリクエストが発生するのではないか？

A. 発生すること自体はあるが、ヘルプデスク側で適宜マネージャに連携するようにした

また、最近JSM導入についての意見を複数部署のマネージャに伺う機会を得たのですが、懸念されていたネガティブなことがなく、また自分のリクエストが見やすくなっている。として以前より格段によくなった。という評価をいただきました。

まずは導入。という状態でした。

問い合わせフォームの最適化は適宜進めており、フォーム内の「やってみたらいらない項目だった」を削除したり、一括申請を作成したりと改善を進めております。

また、この中で「ナレッジベースの拡充」をトップに上げていただのですが、問い合わせの分析をしている中で、ナレッジベースが特に必要となるインシデント関係の問い合わせより、サービスリクエストのほうが比重が大きい。ということがわかりました。

これは、KTCは技術者集団でITリテラシーが高いことに起因しているのではないか？と想像します。

そのため、自分で解決できるインシデント系よりも自分で完結できない（＝管理者しか行えない）サービスリクエストの比重が大きくなっているのだと思います。

現在は、サービスリクエストを減らす。より早く処理できるようにする。ことに注力をしております。

Episode.2 KINTOのPCリプレースをKTCのノウハウ使ってコスト削減したり便利にした（していってる）お話

KTCではキッティングは基本アウトソーシングを利用しております。

ですが、急に入場が決まることもあり、MDMを利用したキッティングの自動化を進めております。

多いと月に20名超入場することも！

このあたりの効率化の詳細は下記の発表資料を参照ください。

Windowsキッティング自動化のススメ - Speaker Deck

対してKINTOでは、ベンダーにイメージ展開からの初期的なキッティングを実施してもらい、その後に個別のアプリインストール等行っておりました。

Intuneを利用しての設定等すでに進めていたところもあるのですが、さらなる効率化についてはきっかけがない状態でもありました。

そんなときに、KINTO PCの大規模リプレース案件を進めることになり、KTCとより強く協力して効率化を進めていくこととなりました。

KINTO/KTCで協力しながら過去資料を見直すことで、今までは手作業が必要な部分を廃止したり、手動での設定をIntune代替しました。

その結果、ベンダーに依頼していたイメージ作成対応が不要となり、効率化を実現できました。

効率化について進んで来たところではあるのですが、まだまだ効率化の余地はあると考えております。

KTCとは環境が違うため、「ゼロタッチ」までの距離はだいぶ遠そうですが、少しづつでも改善し、「ちょいタッチ」まで進めていきたいと考えております。

最後に：先人への感謝は忘れず

KINTO/KTCはともに創業から数年しか経っていない状態で、急造で環境を整える必要がありました。

当時の方々は、創業の混乱の中で、その時のベターを選択して積み重ねてきましたのは疑いの余地もありません。

環境も変わってきた中で、きっかけがあり改善がうまくできたのが今回取り上げた事例となります。

KINTO/KTCはおたがいに、まだまだ整っていないところも多く、改善の余地は両社でも大きくあります。

われこそは！という方がおりましたら、ぜひぜひJoinして、ともにKINTO/KTCのIT環境をよりよくし、スタッフがエンジニアリング以外に時間を取られない、最高のパフォーマンスを発揮できる場にしていきましょう！