皆さん、初めまして！
投稿者として記事を書く機会を頂きありがとうございます。
お初の記事投稿となるので読みにくい点が多々あると思いますが、ご了承頂きつつ最後まで目を通して頂けると幸いです。
それでは宜しくお願い致します。
投稿者バックグラウンド
- 社会人になってからLITALICO入社に至るまで、社内業務システム：スクラッチ開発・導入Onlyに一貫し携わってきました。
- 1領域/1サービスの要求/システム要件定義・業務設計～構築～導入・保守/運用まで一貫したシステム導入の従事経験あり。ゼネラリスト寄りの人物です。
本記事概要
- LITALICO中途入社社員による転職後初めてのお仕事［コーポレート領域のシステム刷新（Saas導入）：利用ユーザ数3500人超］の体験記となります。
- 導入に携わったエンジニアは投稿者1名のみ（意外にも導入できるものですね）
- Q&A形式でポイントポイントについて体験記を記載してます。起承転結があるストーリー形式の文章では無い旨、その点ご了承ください。
→「社内業務システムの導入ってこんな事やるんだ/こんなところ気に掛けるんだ」といったことを知って頂ければ幸いです。
それでは。本編へ
Q1：Saas導入ってどんなタスクがあるの？
A1：冒頭記載にある通り、Saasシステムの導入経験は無くお初の試みとなったので、先ず、今までの経験（スクラッチ開発アプローチによるシステム導入経験）で培ったウォーターフォール型の開発プロセスに沿った成果物で定義、この中から、今回のプロジェクトで必要な成果物をピックアップし準ずるタスクを定義しました。
なお、ドキュメント自体はよくある一般的に作成するものという理解ですが、個人的に重要と感じているのはドキュメント内に「何を記載・定義・合意するか」になるので、目次作りは担当するプロジェクトの性質に合わせ考えて行く必要があると思ってます。
［プロジェクト成果物一覧：（注）LITALICO標準では無いです］
参考）今回のSaas導入で定義したタスク
- 要求ヒアリング
- 製品仕様把握
- 要件定義：システム要件定義、業務フロー設計、ユースケース図作成etc
- 基本設計：周辺システムとのデータインターフェース定義、ワークフロー設計etc
- 詳細設計：なし
- 開発：なし
- テスト：テスト計画書作成、テスト仕様書作成etc
- 移行/リリース：移行計画書作成、リリース計画書作成etc
Q2：プロセスで一番大変だったこと所はどこだったか？
A2：工程の中で大変だったのは、製品仕様把握でした。なかなか全体/全量情報がまとまっている記事や資料が無く、単機能毎の情報がサイト上に乱雑に掲載されているのみだった為、把握に時間を要しました。
※例えば、今回Saas製品サービスのうち、経費と債務支払という2サービス利用になりましたが、サービス間で共有している設定やデータはこれとこれ。みたいなのがパッと見分かるものが無かったなどが挙げられます。
→結局、自身の理解の為、専用ドキュメントを作ってしましました（笑
なお、ここだけの話。全体を通して大変だったのは業務部門を引っ張って推進していくことでした（笑 ※あるある話
Q3：要求に対して0から作るスクラッチシステムと違ってSaaSは先にシステムがあり、システム要件や仕様がある状態だが、その中での要求定義〜要件定義や業務設計って、どう対応しました？
A3：本プロジェクトの大前提の方針として「システムエンハンスしない！（実際はできませんが…）製品仕様に沿った業務を組み立てる」を掲げました。（要は制約＆ここは重要！と個人的に思ってます）
その上で、製品仕様の把握を真っ先に実施（仕組みの中で何ができる/できないを確実に把握）し、かつ本製品を使った標準業務フローなるもを製品会社様よりご提供頂いていたので、標準業務フローをベースに現行業務とFit＆Gapを行い、Gapがある部分は業務ルールを変えてもらう or 別の手法で対応する（例えば、経理部門で新業務として対応する）といったことで進めました。
→進めて行く中で、そんな機能も無いの？！といった声は多々ありました（笑
補足までに「製品仕様に沿った…」はSaas製品の特性・利点を最大限活かすことが可能なので、変に手をいれることで損なわれる可能性があります。導入時点でのギャップがある部分が後に埋まることがあるので、未来を見据えた判断が重要と思っております。
Q4：開発・テストって何かやりました？
- 開発：「製品仕様に沿った業務構築」を掲げた為、未発生。唯一開発が発生した箇所はマスタデータ連携（社員情報、部門情報など）となり、この開発目的としては運用・保守の作業軽減を目的にスクラッチ開発（RDS環境準備、SQLによるデータ加工）しました。
- テスト：製品仕様はサービス提供会社様にて品質担保できているので、機能テストやデータパターンテストなどといった機能単体テスト・システム結合テストなどは実施してません。設計した業務がまわるかどうかの検証（＝UAT）のみを実施しました。
→構築（設計・開発行為）が無い分、コスト面はかなり抑えることができ大変楽でした。今まで経験してきたスクラッチ開発であれば、環境準備/利用計画の立案・運用、開発規約策定、各テストフェーズの計画etcとやることが山ほどありました（これはこれで自由に作れる。一から色々考え・把握できるので楽しいです。）
Q5：導入後のお困り・ユーザ問合せで何か発生しましたか？
-
お困り：製品設定で必要な情報の中に、①マスタ系（利用者情報や口座情報など）の他②設定系（ワークフローなど）があります。いずれもメンテナンス作業に時間要しているのが現状のお困りごとになります。
- ①データを自動連携としてつないでいきたいが、Saas製品間のデータインターフェースが異なるので、データ加工する層・仕組みが別途必要。
- 一部設定系はAPIによる変更操作ができない為、画面UI利用による設定操作になるので自動化できず、どうしても運用コストが掛かってしまう。
→データ自動連携の仕組みを考える上で、大事と思っていることは「各製品におけるデータの持ち方（ex.履歴保持型なのか最新断面のみ保持型）」といった製品上のデータ特性と「業務上の必要なタイミングで反映する」といったことをしっかり理解・把握することと考えてます。無邪気に自動連携できれば良いということではないとの理解。
-
具体的なユーザ問合せ内容：スマホアプリのログインができない、新規入社／組織変更後の精算可能タイミング、事前支払申請ができない（サービス間違え）、経費精算方法がわからない、領収書なしの交通費精算（車など）の申請方法が不明、前払い費用選択がなくなった、他部門振替時の経費精算の申請方法が不明など。
→操作面/業務面いずれの質問も多々発生しましたが、導入後2か月程で定着できました。
［ユーザ向け業務・操作習熟の為に対応した施策］
・操作マニュアルの準備、公開
※そもそも経費精算とはこんな時に利用するよ。から明記しました
・説明会の開催
・よくある問合せのFAQ化＆定期的なメールによる周知
→そこまで工夫、凝った施策は無いかなと思っております。
サマリ
今回Saas製品導入という貴重な体験を通して、感じた感想は以下になります。
- スクラッチ開発であろうがSaas製品導入であろうが、「進めて行く工程、決めて行かなくていけないこと、やっていく作業」はおおよそ変わらなかったなーという感想となります。1点大きく違うのは、業務要望/要件を聞いてからシステム化対象を決め作っていく、一方製品仕様を正確に把握し業務要望/要件がどのように実現できるかを纏めていくという工程が大きく異なり、Saas製品導入プロジェクト成功の要否は「製品仕様を正確に把握すること」かなと感じました。
- ある程度システム導入プロジェクトの標準的な開発工程が定義され、各工程で決めること・成果物はコレ！というナレッジがあれば、Saas製品導入であろうがスクラッチ開発システム導入であろうがある程度は迷わずにプロジェクト推進していけたなと感じました。
- Saas製品導入、スクラッチ開発システム導入いずれにも良し悪しがあるので一概にどちらが導入手法として適しているかは、ビジネス・業務内容に左右されると思いました（そりゃそうだ）ただその中で、ある程度業務フローや内容が、世間一般として決まっている領域（例えば今回のような経理領域：経費精算業務など）はSaas製品が有効であるよう感じました。
最後に。
今回体験記ということでつらつらと体験と感想を並べましたが、社内業務システムにおけるSaas製品導入とスクラッチ開発のバランスという点で何時か深堀して考察していってみようと思うきっかけになりました。ここまでお付き合い頂きありがとうございました。