社内SEが抑えておきたいパッケージ・ツール導入のメリット＆プロセス

といった疑問に答えます。

本記事で、実際に社内SEとしてパッケージ・ツール選定を進めた経験をふまえパッケージ・ツール導入のプロセス・勘所・注意する点を解説していきます。

といった内容を解説していきます。

パッケージ・ツール導入とスクラッチ開発の違いとは？

パッケージ・ツール導入とスクラッチ開発の定義です。

パッケージ ・ツール導入・スクラッチ開発どっちがいい？議論はありますが、結論、社内SEは自社の機能・ケーパビリティーを予定している金額・期間で実現できる方法を選択すべきです。

あくまでもシステム導入は、手段であり目的ではありません。

手段としての選択肢は多様に持つべきです。

ここまでの話が、一般論です。

しかし、私の結論としては、社内SEはパッケージの導入を推進すべきです。本記事で、その理由を解説します。

パッケージ ・ツール導入のメリットとは？

パッケージ ・ツール導入のメリットで解説します。

こういったメリットに関して詳しく解説していきます。

スクラッチ開発しなくともニーズを既存パッケージで十分満たせる

ITで解決したいのはビジネスの課題です。ソリューションを作ることが目的ではありません。自社の課題解決の手段としてシステムの導入を行います。その課題はほとんどのケース競合他社も抱える悩みです。その為、ほとんどの場合、その解決手段のソリューションパッケージもほとんどの場合、世の中に存在します。

もし、自社が唯一無二のビジネスモデルを行い、かなり特殊業務がある場合は別ですが、そうだとしても特定の領域を除きほとんどの領域ではパッケージでまかなえるはずです。例えば、人事、会計等々。

業務水準を業界標準・競合に追いつける

別の見方では、自社でスクラッチ開発ではなく、パッケージ ・ツール導入を検討する場合そのパッケージに合うレベルまで自社の業務レベル・プロセスを引き上げることができます。

競合優位性の強化・画一につながらないプロセスであれば率先してパッケージ ・ツール導入の検討が費用削減・効率化にメリットがあります。

パッケージのほうが性能がいい

スクラッチ開発であれば、今の業務をベースに自社に最適なソリューションを開発可能です。しかし、その要求・仕様・設計も自社エンジニアの能力に依存します。一方、パッケージでは専門のエンジニアがソフトウェアの開発専門に日々明け暮れます。

餅は餅屋を考えると、一流の専門のエンジニアが開発するパッケージと、片手間で開発を行う社内SEが設計するソリューション、性能・機能が優位なのはかなり容易に想像できます。

社内SEの目的は、一流のソフトウェアを作るではなく、ビジネスのドライバーとしてIT化を推進することです。

メンテナンスも楽

社内SEのリソースは限られています。スクラッチ開発部分にメンテ要員をアサインするよりは、パッケージ ・ツール導入しソリューションの維持管理をアウトソースするほうが効率的ではないでしょうか。

コストも結果易い

一見、スクラッチ開発した方が安く感じるかもしれません。しかし実際には、インフラの管理、開発人材の確保等々様々なコストが発生するため、サービスとしてパッケージを利用するほうが安くすむ場合がほとんどです。

将来性もある

将来性に関しては、２つの視点が必要です。
①パッケージであれば、パッケージ開発企業が日々ソリューションを成長させてくれる。この点は相当なメリットです。
②スクラッチ開発したソリューションは、なかなか創造的破壊ができません。これはビジネスにとってデメリットです。せっかく作ったシステムだからと言って、一度開発してしまうとどうしても守りになります。ビジネスは日々進化し、システムも進化が必要です。いくら時間・コストをかけスクラッチ開発をしたからと言って、時代遅れな仕組みは捨てる必要があります。しかし、スクラッチ開発だとなかなかそうはいきません。

＊補足：内製の場合特に自分で自分の仕組みを否定し作り直すのは相当難しいのが実態です。

パッケージ・ツール導入のプロセスとは？ ４W４Hで覚えよう

パッケージ ・ツール導入プロセス・流れを解説します。

大きく
・検討・選定プロセス
・設計・開発プロセス
・運用プロセス
と分類できます。

パッケージ選定で特に特徴的なプロセスが、「検討・選定プロセス」になります。

以下で解説していきます。

以下のリンクて解説している設計・開発プロセスはスクラッチ開発用のプロセスの解説ですが、基本どのパッケージにするか決まったら後はほぼ一緒なので、 「検討・選定プロセス」にフォーカスし解説します。開発プロセスは以下の記事でご確認下さい。社内SE初心者【システム開発基礎ガイド】全体像理解～開発～テスト

検討・選定プロセス

5W1Hぽくまとめると、４W４Hになります。

ビジネス課題を明確にする

ツール導入・パッケージ導入は手段であり、目的ではありません。。。。とわかっているのに、いつの間にかツール導入プロジェクトに矮小化するプロジェクトが後を絶ちません。最初に、なんの為にこの施策を実施するのか文章化が必須です。

そして、（当たり前の）重要なポイントが、ビジネス課題の明確化はビジネスサイドが責任を持つ必要があります。間違ってもIT側がリードしてはいけません（インフラ系の仕組みはOK）。

解決すべき課題を明確にする

ビジネスの課題を明確にできたら、なんのプロセス・ツール・データに問題があるのかといったもう一段下げた具体的な課題を明確化する必要があります。課題感によっては、パッケージも１つでは足りず複数導入が検討な場合もあります。

責任者・意思決定者を明確にする

解決すべき課題とアプローチが明確にするのと並行し、それぞれのアクティビティーの責任者・意思決定者を明確化すべきです。これを怠ると、いつの間にかIT主導のプロジェクトに代わっているケースが後をたちません。

ITは解決する課題の手段であり、、、全てではありません。

時間軸を決める

並行して、時間軸を決める必要があります。仮のマイルストーンもないプロジェクトでは、緊張感もなくただただ時間とコストを浪費していきます。

時間を切ることにより、物事を逆引きで考える逆算思考でプロジェクト推進ができます。逆算思考のメリットは、「【逆算思考のやり方】課題を素早く解決するロジカルシンキング」の記事で詳しく解説していいます。

候補ツールベンダーを選定する

解決すべき課題が明確になったら、どうその課題を解決するか？の検討に入ります。ここまでの検討が大体進めばSierから支援を受け進めるのも手です。

RFI/RFPを実施する

候補ツールの選定が決まれば、あとは、RFI/RFPを実施します。RFI/RFPご存じない方は、以下の記事が参考になります。

RFIとRFPの違いは何か？RFQを含めて解説 | Promapedia（プロマペディア）

ITシステムを開発する業者を募る際、RFI・RFPを作成します。 今回はRFIとRFPの違いについてお話ししていきます。

ssaits.jp

評価基準を定める

パッケージ選定の重要な工程の一つが、評価基準を決める工程です。どんな観点でツールを評価するか事前にしっかり決めておかないと、情報収集後なんとなく評価して、なんとなく偉い人のさじ加減で決まってしまうなんて事になってしまいます。最終的には責任者が決定すべきですが、プロジェクトで合意できる形で意思決定をできるように準備が必要です。

決める、決めてもらう

スクラッチ開発と違い、パッケージ選定はどのツール・パッケージにするのか判断が必要です。判断軸があいまいだと決定もあいまいになります。判断軸を決める段階で、決めるために必要な人・要素・情報を意識して準備が必要です。

パッケージ選定の評価で利用できる基準とは？

パッケージ選定時に利用できる検討の軸・観点をいくつか紹介します。

等々、あげられます。

こういった観点の何にどれくらい重みつけをするのかを決めパッケージ選定を進める必要があります。

パッケージ選定の注意点と本記事のまとめ

本記事のまとめと、パッケージ選定の注意点をまとめます。

まずは、パッケージ選定のメリットです。

・スクラッチ開発しなくともニーズを既存パッケージで十分満たせる
・業務水準を業界標準・競合に追いつける
・パッケージのほうが性能がいい
・メンテナンスも楽
・コストも結果易い
・将来性もある
・競合に追いつける

ここでの注意点＋重要なポイントは、
・パッケージ導入は手段であり、目的ではない
・社内SEはスクラッチ開発にこだわらずパッケージ選定も積極的に視野に入れる
・特に、一度作った仕組みがある場合創造的破壊の必要性を認識する

この重要なポイントをふまえたプロセスのおさらいです。

・Why 　ビジネス課題を明確にする
・What 解決すべき課題を明確にする
・Who 責任者・意思決定者を明確にする
・When 時間軸を決める
・How 候補ツールベンダーを選定する
・How 　RFI/RFPを実施する
・How 評価基準を定める
・How 決める、決めてもらう

WHY/　WHATは特に重要ですね。ここが落ちると、目的が曖昧になりツール導入の為のプロジェクトになってしまうリスクがあるので注意しましょう。