ツール選定の考え方

## はじめに

私の所属するエイチームコマーステックでは、最近、Webサービスやツールの選定(以下、ツール選定)を行う機会が増えています。
これには社長をはじめとした経営陣が、有限な社内エンジニアの工数を貴重なものと認識してくれて、費用対効果に見合うならアウトソースするという方針で導入を任せてくれるようになったという背景にあります。
そんな中、後輩からツール選定を行うときにどういうことに気を付けてますか？という質問をもらったのに端を発して記事にまとめてみることにしました。
一口にツール選定と言っても、クラウドサービスやライブラリ、開発ツールの選定など多岐にわたりますが、今回は一番多くの検討事項が登場しそうなクラウドサービスの選定を扱ってみようと思います。

## ツール選定のステップ

私がツール選定を行う場合、**合計4個のステップ**を踏んでいました。
導入するツールの規模にもよるので、毎回というわけではないです。

### 業務フロー整理

クラウドサービスを導入する以上、解決したい業務課題があるはずなので、どのような業務課題を扱うかを具体化していきます。
私が所属するエイチームコマーステックではECサービスを提供しており、自社ロジスティクスセンター(以下、LC)で在庫を扱っています。
たとえば、LCに**在庫管理の精度が低い**という課題があったとしましょう。

**在庫管理の精度が低い**という課題だけだと、解消すべき問題が抽象的過ぎて解決策が分かりません。
「LCにおける在庫管理オペレーションの質が低い」のであれば、Amazonのようにロボットを投入して倉庫業務を自動化する必要があるかもしれませんし、
「登録されるデータに問題がある」のであれば、入力の仕組みを見直す必要があるかもしれません。

なので、

* **実際にどういう業務を行っているのか？**
* **問題が発生しやすいポイントはどこか？**

といった課題を整理するために、まずは**業務フロー整理**を行います。
対象とする業務のボリュームによりますが、複数職種が絡むなどして業務フローが複雑な場合は[アクティビティ図](https://www.itsenka.com/contents/development/uml/activity.html)にまとめることが多いです。
アクティビティ図を使うとアクションとシステムの対応が見えるようになるので、**どのアクションで問題が起こりやすいかを特定することで既存業務における問題点を洗い出しやすくなります**。
また、実務者と導入するツールの要件を協議する際に、認識を揃えやすくなるのも大きなメリットです。

経験上、

エンジニア「○○のアクションって何のためにやってますか？」
オペレーター「もともと××する目的があってやってたんですが、今は・・・なんでやってるんでしょうね。」

のようなコミュニケーションにつながるケースも少なくありません。
目的と運用が一致しなくなった場合、無駄なアクションを減らす≒要件が減ることにつながります。

このステップが完了すると以下の成果物が得られると思います。
- **業務フロー図**
- **要件定義書**
    - 当社では厳密に要件定義書を作ることは少なく、要件一覧で済ますケースの方が多いです

## ツールの把握

続いて、要件を満たすツールにどのようなものがあるかをチェックしていきます。
コアになる機能名で検索するとそれなりに情報が集まるので、まずは名前を挙げるのを最優先。
ある程度情報が集まったら機能を調べていくという流れで進めています。

在庫管理の例では**在庫管理**自体がコアになる機能なので、まずは、「在庫管理システム」 あるいは 「WMS」といったキーワードで調べて、ツールのリストを用意します。
リストは、後から比較しやすいようにGoogle スプレッドシートなどに書き出すことが多いです。
X軸にツール名、Y軸に要件を書いて数字でスコアリングできるようにして、数値化しづらい機能は備考欄に書いたりします。
書き出した後は要件に対するマッチ度をスコアとして書いていきます。
数字で表現する場合も解釈によるので扱いは難しいですが、**ツールを決定するタイミングで評価理由が分かりやすい**のでよく使いがちです。
完成すると以下のような感じになります。

|  | ツールA | ツールB | ツールC |
|:-:|:-:|:-:|:-:|
| 費用  | xx万円 | xx万円 | xx万円 |
| 備考  | xxx | yyy | zzz |
| 機能要件1 | 5 | 2 | 1 |
| 機能要件2 | 4 | 3 | 5 |
| 非機能要件1 | 3 | 1 | 2 |
| 総合評価  | 12 | 6 | 8 |

評点が低すぎたり、必須要件の充足度が低いものは切り捨てて次のステップに移行します。

このステップが完了すると以下の成果物が得られると思います。
- **ツール比較表**

## 試用

次に前のステップで選定候補に残ったツールを試用していきます。
実際に**ツールを試用するか、デモを見せてもらうなどしてUIやレスポンス**などをチェックしていきます。
なお、試用する際に契約条件で折り合わず断念するケースもなくはないですが、ここでは扱いません。

可能であれば、実務者に触れてもらえるように設定するのが好ましいと考えています。

**レクチャーなしで迷わずに操作できる**、**レクチャーすれば操作できる**, **時間をかけてレクチャーすれば操作できる**, **理解できずに混乱している**など、
実務者にとってどういうレベルのUIかによって、その後の教育コストや運用にのるかどうかが変わってくるので、結構重要なポイントだったりします。
もちろん**レクチャーなしで迷わずに操作できる**に越したことはありませんが、そのレベルのプロダクトって少ないんですよね、実際。

あとはレスポンスのチェックです。
Webサービスとしてのレスポンスに意識が向きがちですが、物理デバイスがあるのであればその動作速度もチェックします。
過去、実際にありましたが、「ラベルプリンタの印字速度が遅くないか？」という指摘をもらい、確認したところ既存のラベルプリンタの倍時間がかかっているということがありました。
1枚2秒で印刷できたとしても300枚印刷すると10分の待ち時間が発生したりと、地味に生産性に影響が出てきます。

実務者目線での指摘がもらえるので導入前に一度は現場に行くべきだと思います。
こういうケースではベンダーの担当者の方に同行いただくことが多いので、その人の応対をチェックできるとなおよしです。
営業職の方が多いですが、その時の応対の早さだったり、融通の利きやすさは運用フェーズでのサポートに直結します。

このステップではひとつ前のステップで作成した**ツール比較表**に備考が追記される程度です。

## 評価・選定

いよいよ選定に入っていきます。
この時点で**ツール比較表**は、**ツールの価格**, **機能要件**, **非機能要件**が埋まった状態になっていると思います。
私個人の感覚では、機能要件 >> 非機能要件くらいの重みなので、`機能要件の標準偏差*2 + 非機能要件の標準偏差`で比較してみるといいかもしれません。
（過去の実例でここまで厳密に求めてないですが、数値化したなら本来ここまでやったほうがいいよなと思った次第です。

このステップが完了すると以下の成果物が得られると思います。
- **導入するツールの決定**

おそらく当社に限らず導入の決裁をとったりとかもろもろあると思いますが割愛

## 導入

ひとつ前のステップでツールが決定したから終わりじゃない？と言われるとそうですが、ツールを選んで終わりとはならないので最後まで書こうかなと。
ツールが決まったらそのまま入れておしまい・・・とは当然ならず、導入フェーズに移行します。

導入フェーズで必要なのは以下のステップだと認識しています。
- 業務整理
- カスタマイズ
- 運用テスト
- 並行稼働
- 本導入

### 業務整理(2回目)

2回目の業務整理は、導入するツールに合わせて業務フローを変更していきます。
既存業務に合わせてツール側をカスタマイズするという話をよく聞きますが、**それは本当に正しい選択ですか？** というやつですね。
本当にいいツールを導入するのであれば、ツール側が想定している業務フローの方が最適化進んでいるはずなので、業務フローをツール側に寄せていきます。
これによりカスタマイズ費用も減るし、業務も効率化されやすいので、いいことはたくさんあります。
代わりに並行稼働や移行フェーズが大変になるので、トレードオフではあります。

### カスタマイズ

ツール側なのか社内システム側なのかはケースバイケースですが、どうしてもシステムを業務フローに合わせないといけない部分に手を入れていきます。
前述の業務整理ができていれば、カスタマイズは最低限に収まっていると思います。

### 運用テスト

新しい業務フロー＆カスタマイズした機能で運用テストを実施して、想定通りに運用が回るかテストしていきます。
実際には開発工程でその他のテストも実施することになりますが割愛。
運用が回らない部分があれば、業務整理とカスタマイズを再実行します。

### 並行稼働

既存フローと新フローの並行稼働を行います。
それぞれのフローのアウトプットが一致するかをチェックすることでフローの切り替えによる影響を確認するのが目的です。
既存フロー側に問題がある場合、新フローとアウトプットが一致しないといったことが発生します。
この場合、それぞれのアウトプットの差を見つけて、差の原因を特定することでどちらが正しいのかをチェックすることができます。
システムで取り扱うトランザクション数がめちゃくちゃ多いと大変そうですよね(遠い目
実務者は同じ作業を別のシステムで二重化することになるので、負担を強いることになります。
今までのシステム導入に関わっていただいたみなさんには感謝しかないです:bow:

### 本導入

既存フローから新フローへ切り替えます。
問題があったら直ちに既存フローに切り戻せるようには準備しておく。
リカバリープランがない移管は精神的にも体力的にも地獄…。


## おわりに

以上、私がツール選定で行っている**業務フロー整理** → **ツール把握** → **試用** → **評価・選定**の4つのステップ＋**導入の流れ**について触れてきました。
後輩に、こういう考え方があるよと知ってもらうことを目的に書き始めましたが、ツール選定から導入までの流れを説明している人は意外と少ないことに気付きました。
**失敗しない**とかいう接頭辞は要らないので、私はこういう風にやっているよというお話をお持ちの方がいたら、是非とも伺ってみたいので投稿お待ちしております。