流れ
要件&課題の洗い出し
製品や技術を入れるには理由があります。ではその理由はなんなのか？というのを整理するフェーズです。ビジネス要件や技術要件、その他解決したい問題なんかをざっくりあげるフェーズです。
- As-Is(現状)とTo-Be(未来)の整理
- 両者のギャップの洗い出し
- ギャップを埋めるための機能の洗い出し
- As-Isのうち引き継ぐ必要がある機能の洗い出し
- 非機能部分の洗い出し (性能、セキュリティ、運用、拡張性、監視...など)
- その他、前提条件の洗い出し (金額、特定のベンダを使うこと、社内ナレッジの確認、サポートの必要性...など)
- 社内に詳しい人が多い技術を選ぶ
- 市場に詳しい人が多い(採用しやすい)技術を選ぶ
- 学習コスト
- 維持運用コスト
- 世の中の流れ/トレンドを意識する(意識しすぎるのもダメだけど、やっててモチベーションあがるとか市場価値が上がるという観点も持っておきたい)
机上検討と調査
このフェーズでは洗い出した条件を満たすような製品探しや全体構成を決めます。またもう少し進んだら、PoC(概念検証)を実施します。
- 機能を満たす製品、技術を調査する (ネット、人に聞く、本など)
- 1で洗い出した方式をまとめて、方針ごとにメリデメをまとめ比較できる資料を作る
- 2で作った方式を比較し、メインとする方針を決定する
- 3で決めた方針に対してPoCを行う
- PoCしないと比較できない場合は、洗い出した方式全てに対してPoCを行ったのちに比較を行う場合もある
- PoCの結果をもとに大まかな方針を決定する (要件を満たせていないところは微調整しつつ)
机上検討と調査の方法について
まずは対象のソフトウェアがどんなものなのかを調査します。
ソフトウェアバージョンを確定させる
調べる対象のソフトウェアのバージョンを決める。基本的にはステーブルになっている最新版がよいが、使いたい機能がRCやβの場合もあったり、サポートが一部受けられないバージョンなどもあるのでケースに応じて採択する。
ドキュメントリーディング
まずは公式サイトやGitHubのREADMEを読みあさり、その技術のコンセプトや成り立ち、目指している方向性を大まかに把握する。有償の場合は、どこでお金を儲けているのか？に着目し金額感がユースケースに適合するかを調べる。
ソースコードリーディング
対象のソフトウェアがOSSの場合に発生する工程。
コードを見て、特に重要なコンポーネントに関する挙動を調査する。この工程はいわばホワイトボックステストに近いと個人的には捉えている。このタイミングでドキュメントにアーキテクチャ図がなければソースコードから絵を起こすのが良い。 またソフトウェアのライフサイクルについても絵にまとめること。
実際に動かしてみて挙動を確認するのがブラックボックステストで、大抵の場合はこっちの方が早い＋コードリーディング知識がいらないのでこっちを採用しがち。(ちゃんと読める人には頭が上がりません）
ソースコードが見れない場合は否応なくブラックボックス的な確認となる。
ここまでできたら、続いて機能・非機能観点から評価を行う。
評価項目の作成
要件洗い出しのところできちんと整理ができていれば、それにそぐう形で評価項目を作成する。
評価項目は他のソフトウェアや製品と比較することになるので、Excelやスプレッドシート などに○/△/×といったわかりやすい値と評価をかけるようにする。
機能要件は洗い出しやすいが、非機能のところは抜け漏れしがちなのでIPA資料などを参考に網羅的にチェックするようにする。また導入背景に既存の運用や文化の改善などシステム外の課題を解決する場合などはそれらも含めて項目を記載すること。
試験の実施
試験項目に沿って評価を行う。評価に使った環境や構成、試験方法について記録しておく。
ソフトウェアが条件を満たせないことが確定した場合は対応策を講じるのか（改造する、他と組み合わせるなど）、それとも検証を終了するのか、要件を緩めるのかについて都度判断を行う。
評価
最終的に作成されたデータを確認しどの方針でいくのか？について答えを出す。この時どのようなプロセスをたどり、方針を決めたのかについてドキュメントに残しておくこと。（後々技術選定理由などが闇に葬られると困りがち）
テクニック
完全に新しい分野の技術を評価するわけでなければ、基本的には似たような製品・ソフトウェアを過去に評価したような記事が見つかるはずなので、その流れを参考にすると評価項目観点の作成を車輪の再発明する必要がなくなる。
