社内ITサービス利用申請に関するintra-mart活用事例

2018/10/25 Enterprise Web Solution 2018での、木村の講演資料になります

Transcript

1. 社内ITサービス利用申請に関する intra-mart活用事例 木村 雄一郎 株式会社リクル－トテクノロジ－ズ ＩＴソリュ－ション本部 インフラソリュ－ション部 社内インフラ３グル－プ 2018/10/25
2. 2 株式会社リクルートテクノロジーズ 木村 雄一郎 ◆発表サマリ ◆発表者 リクルートグループの社内ITサービス利用の申請ワークフローシステムの再構築を行いました 本日は、以下について具体的にご紹介します ご参考になるものがあれば幸いです リクルートグループの社内ITサービス提供において申請関連・ システム構成管理・アプリ配布基盤などのアプリ構築・運用を担当
3. １．はじめに～リクルートとは 3
4. 4 リクルートグループについて 創業 1960年3月31日 「大学新聞広告社」としてスタート グループ 従業員数 40,152名 （2018年3月31日時点） 連結売上高 21,733億円 （2017年4月1日～2018年3月31日） 連結経常利益 1,917億円 （2017年4月1日～2018年3月31日） グループ 関連企業数 361社 （連結対象子会社、2018年3月31日時点） 目指す世界観 「あなた」を支える存在でありたい
5. 5 リクルートの事業内容について ライフイベント領域 進学 就職 結婚 転職 住宅購入 車購入 出産/育児 旅行 ビジネス支援 生活/地域情報 グルメ・美容 ライフスタイル領域 選択・意思決定を支援する情報サービスを提供し、 「まだ、ここにない、出会い。」を実現する。
6. 6 リクルートのビジネスモデルについて リクルートには、ユーザーとクライアントという2つのお客様が存在します。 企業と人（B to C）、企業と企業（B to B）、人と人（C to C）、すべての間に立ち、 双方にとって最適なマッチングを図る「場」を提供しています。 ユーザーとクライアントを新しい接点で結び、 「まだ、ここにない、出会い。」の場を創造する。
7. 7 リクルートグループにおけるリクルートテクノロジーズについて リクルートテクノロジーズは、リクルートグループのIT・ネットマーケティング領域のテクノロジー開発を担う会社です。 リクルート ホールディングス リクルートキャリア リクルート住まいカンパニー リクルートライフスタイル リクルートジョブズ リクルートマーケティングパートナーズ リクルートテクノロジーズ リクルートスタッフィング スタッフサービス・ホールディングス リクルートコミュニケーションズ メディア & ソリューション事業 （株）リクルート 人材派遣事業 Recruit Global Staffing B.V. HRテクノロジ― 事業 RGF OHR USA, Inc. その他海外派遣グループ会社 Indeed,Inc.
8. 8 リクルートテクノロジーズの役割について 技術・ソリューションを磨き続け、リクルートの各サービスがもつ価値を最大限に発揮できるようビジネスへ実装。 ITの側面からサービスを進化させることを通じて、世の中に新しい価値を提供していきます。
9. 9 リクルートテクノロジーズの事業内容について 将来のニーズを見据え、新しい技術のR＆D・ソリューションの開拓を実現。 検証を続け、いち早く活用できるレベルに引きあげることで、中長期的なビジネス競争優位を構築していきます。
10. 10 リクルートテクノロジーズの組織構成について リクルートテクノロジーズは5つの統括本部で構成されています。 各統括本部の下に、さらに部・グループが続きます。 企画統括本部 ITマネジメント本部 リクルートテクノロジーズ ITマーケティング本部 ITソリューション本部 経営企画、広報、経理/人事/総務ほか いわゆるコーポレートスタッフ 事業と一体となり、開発ディレクションやエンハンス、 大規模開発プロジェクトの推進を担う UXデザイン、ウェブマーケティング基盤の開発、 サービスデザインの検討から実装を担う サービスプロダクトの開発、サービスインフラやAP基盤の開発、運用を担う ITエンジニアリング本部 リクルートグループ共通の社内システムやインフラ等の ソリューション企画・開発・運用を担う
11. 11 リクルートテクノロジーズが提供する社内ITサ－ビス 幅広い社内ITサ－ビスを企画、提案から保守運用まで全方位で提供しています。 運用規模 提供サ－ビス例 基幹系システム 40社 ID管理/会計・販売・人事管理システム 端末 45,000ID コラボレ－ション ネットワ－ク 電話/スマホ ファイル共有 4.2PB 53,000ID 35,000台 国内700/海外14拠点 標準VDI/セキュアVDI 統合ファイルサ－バ Office 365(メ－ル/Skype/Teams) iPhone/iPad/IP電話 LAN/WAN/グロ－バルNW 40,000台 PC/VDI専用端末 3,000台 Mac
12. ２．社内ITサービス提供の業務カイゼン 12
13. 13 申請システム 端末 • 標準パソコン • 新規 • 返却 • 費用負担組織変更 • 利用環境設定 • 紛失 • CYOD Windows • 新規 • 廃止 • 変更 • 紛失 • CYOD Mac • 新規 • 廃止 • 変更 • 紛失 ネットワーク • 標準ネットワーク配線工事 • 独自ネットワーク配線工事 • 独自ネットワーク管理情報 変更 プリンタ/FAX • プリンタ新規導入 • プリンタ移動 • プリンタ返却 • プリンタ管理責任者変更 • ICカード購入 • ICCR取付・取外し • FAXポート増設 • セキュアプリンタ登録・解除 依頼 • コピー・FAX機新規導入 • コピー・FAX機返却 • パンチ取付・取外し • プリンタオプション設定 固定電話/FAX回線 • 各種申請 • 一般電話・FAX工事申請 電話/スマホ • スマートフォン • 新規 • 解約 • 使用者/管理者変更 • 費用負担組織変更 • ガラケー • 解約 • 使用者/管理者変更 • 費用負担組織変更 • モバイルカード • 解約 • 使用者/管理者変更 • 費用負担組織変更 • 共通 • 機種変更 • ナンバーポータビリティ • 社内内線電話利用 リクルートグループ各社に提供している社内ITサービス申請(40種類超)を担うシステム
14. 14 申請システム 手作業 カイゼン前 － 業務概要 申請 承認 受付・調整 出荷・ 工事指示 納品・工事 課金 ユーザ部門 コストチーム 運用チーム 申請システム 手作業(Excelマクロ)管理 サービス 利用 ユーザ部門 取引先 会計情報システム ID管理システム 調達先外部システム 構成管理システム システム間の連携不足＆ 手作業ばかり マスタ関連 出荷・納品 関連 その他 インシデント管理システム 工事進捗管理システム 関連システム エンハンスが大変 Excel中心の手作業運用
15. 15 カイゼン前 － 業務にかかわる課題 intra-martを採用  申請受付以降、サービス提供までの業務がシステム化されていない、かつ進捗管理も すべて手作業  課金データの作成も手作業 内容  人事情報や会計用情報や機器管理データが自動連携しておらず、不要データを 都度クリーニングする必要あり 手作業が多い 課題 システム間の 連携不足 1 2  API連携等、他システムとの連携機能がある  進捗状況管理のため、データベースのテーブル構造が公開されている  エンハンスが容易 新システムの要件 システム再構築を検討  フルスクラッチのため、機能追加だけでもDBテーブルの追加やワークフローの新規追加が 個々で必要となり、開発工数が膨大になってしまう エンハンスが大変 3
16. 16 申請システム カイゼン後 － 業務概要 申請 承認 受付・調整 出荷・ 工事指示 納品・工事 課金 ユーザ部門 コストチーム 運用チーム 申請システム サービス 利用 ユーザ部門 取引先 会計情報システム ID管理システム 調達先外部システム 構成管理システム マスタ関連 出荷・納品 関連 その他 インシデント管理システム 工事進捗管理システム 関連システム CSV サービス利用状況に応じた 入力チェック システム内で の進捗管理 申請内容に応じて 関連する他の申請を 自動で起票 人手を介さずに 他システムと連携 API連携 マスタの一元管理 課金データを自動作成 DB参照 申請システムでの一元管理
17. 17 カイゼン後 － 業務にかかわる課題の解決  申請受付以降の業務も申請システム上で管理  課金データ作成を自動化 対応 内容  人事情報や会計用情報や機器管理データを自動連携  クリーニング作業を自動化 業務にかかわる課題に対して、新システム構築時に以下の対応を実施し、 申請～納品～課金までの業務カイゼンを行いました 1 2 3  画面作成部品等が用意されているため、フルスクラッチに比べ開発工数を抑制 できる 作業自動化 他システムと自動連携 エンハンスが容易 その他、intra-martにしたことで、利便性向上にもつながりました  大量の申請を一つにまとめる ことが可能  自動入力補助  複数ファイルの一括 アップロードが可能  過去申請の流用が可能 1  対応できない納期は入力を 不可能にする  電話でヒアリングしていた詳 細内容を選択項目に追加  複数の申請でアップロード されたファイルが一括ダウン ロード可能 2 運用担当者の利便性 ユーザの利便性
18. ３．intra-mart導入時に気を付けたポイント・苦労した点 18
19. 19 気を付けたポイント スクラッチ開発は行わない  スクラッチ開発や標準機能のカスタマイズは行わず、intra-martの標準機能をフル活用して開発しました  パッケージに合わせて業務設計の見直しを実施（代替案の提示）  画面イメージを早めに共有し、パッケージ内の機能を前提に業務を回すイメージをつけた 生産性が高い  intra-martの標準機能として用 意されている画面作成部品を利用 し、ユーザ利便性の高い画面を容 易に実現できた  データベースへの項目追加まで自 動で行われるため、項目追加が容 易に対応できた 効果1 intra-martのバージョン アップに対応しやすい  リリース後にバージョンアップ対応をし たが、バージョンアップに伴う大きな 問題は発生しなかった トラブル対応負荷を軽減  パッケージの範囲内での開発のため、 製品保守範囲内であり 保守窓口へのQAがしやすい 効果2 効果3
20. 20 既存運用の洗出しが不十分  運用担当者との初期コミュニケーションが不十分で、開発を進めた後に運用担当 者との認識齟齬が発覚し、設計後に要件追加が多数発生 苦労した点 追加要件が開発途中に多数発生し、構築当初はバグが多数発生した 品質管理の体制が不十分  当初、特殊制御が不要な申請を想定し、少人数かつメンバークラスのみで開発 実際は、多数のシステム間連携や複雑な入力チェックが必要となり、設計難易度 の高い開発となり、結果として設計考慮漏れによるバグ等が多数発生 原因2 原因1 追加要件の多数発生 バグの大量発生  認識齟齬が発生した箇所の棚卸を実施し、要件定義を再度実施  既存要件及び追加要件に対して、運用担当者と再協議し、要否の判断  リーダークラスの要員を追加  レビュー厳格化やテストケーステンプレート化等のプロセスを制定 当初計画を変更することなくC/Oを実現 構築初期に比べバグ発生率が大幅に減少
21. ４．その他取組み 21
22. 22 その他取組み一覧 ③Ansibleとの連携 ①RPAとの連携 ②Microsoft Teams との連携 本プロジェクトでは業務カイゼンを進める中で、以下取組みも実施しました
23. 23 例）権限付与の場合 ①RPAとの連携 運用作業のRPA化 ユーザへの特殊権限付与やデータ抽出等の定型運用作業を自動化しました ①作業依頼 利用者 運用担当 ②権限付与 RPA起動 ②‘権限付与 ③対応完了通知 RPA 申請システム
24. 24 ②Teamsとの連携 処理依頼のTeams連携 処理依頼通知をメールのほか、Microsoft Teamsにも通知するようにしました Teamsとは・・・ Microsoftのチャットベースの コラボレーションツール 申請 承認 受付・調整 出荷・ 工事指示 納品・工事 課金 ユーザ部門 コストチーム 運用チーム サービス 利用 ユーザ部門 取引先 ユーザA 会話のやり取りが案件ごとにスレッド化された 履歴で表示されるため、 どのようなやり取りが発生したかがわかりやすい XXXXXXXXX
25. 25 ③Ansibleとの連携 リリース作業の自動化 申請 システム Git 資材管理 リリース対象資材をGitから取得し、 商用環境にリリース 自動化後 開発者 資材配置 自動化前 申請 システム 商用環境に リリース 開発者 リリース 担当者 開発 環境 ファイルサーバ 資材配置 資材一覧を元に開発 環境/ファイルサーバ から資材を取得 資材一覧 チェックリスト 取得した資材とチェック リストを元にリリース用 資材を作成 リリース 担当者 開発 環境 資材リリース
26. ５．今後の取組み 26
27. 27 誰でも開発できる？ GUIで開発可能なので、誰でも開発できる～ パッケージに多くの部品があるので、誰でも開発できる～ 他システムとの連携や、複雑な入力チェック、会社毎に制御するユーザ向け機能を 実装する場合は、開発のスペシャリストが必要です でも本当は！！ エンハンス開発は誰でもできるようにしたいんです え～要注意です！！！！ 今後は、誰でもエンハンス開発を行えるよう検討を進めています ワークフローの開発ツールって一般的にこういうイメージがないですか？
28. 28 運用者によるエンハンス開発を実現するためのプロセス制定 画面やメールの修正は運用担当者でも変更できるようフロー・手順を整備します 申請 システム 利用者 開発担当 ②要件出し・変更依頼 ③確認依頼・回答 ⑤修正・確認 申請 システム 利用者 社内ITサービスの 各運用担当 開発担当 ②変更内容連絡 ③修正 ④確認・管理 ①要望 ①要望 AS-IS TO-BE ⑥管理 ④設計書修正確認 社内ITサービスの 各運用担当 スクラッチ開発していないため実現できるはず・・・