カスタマーストーリー｜NASA JPLのESMツール評価・選定プロセス

[0:05] リン：フランクは、NASAのジェット推進研究所（JPL）でIT専門家として働いており、業務プロセスの設計、ウェブプログラミング、データベースの設計・開発、SQLプログラミング、システムエンジニアリング、要件定義、そしてITプロジェクトなどを担当しています。彼のキャリアは約30年前、メインフレームコンピュータのオペレーターとして始まりました。その後、テクニカルプロジェクトマネージャーへと昇進し、図書館間相互貸借データベースの構築に携わりました。数年後、ITリーダーとしてJPLに移籍しました。さて、話が脱線してしまう前に、マイクをフランクに譲ります。どうぞ。

[0:51] フランク：さて、ありがとうございます。ウェビナーにご参加の皆様、ようこそ。この情報を皆様にお伝えできることを本当に嬉しく思っています。私と同じくらい興味深く感じていただければ幸いです。それでは、早速始めましょう。私のプレゼンテーションでは、利用製品を探し出し、評価するまでのプロセスを、カジュアルな形で振り返っていきます。実際に私たちが実施した時の流れに沿って、その時のままお伝えしていきます。評価のための調査を、私が実際に行った順序通りに進めた過程をお見せし、最終報告書の作成過程で作成した資料の一部もご紹介します。なお、JPLには特定の製品を推奨しないという方針があります。そのため、評価対象としたベンダーに関する情報を提示する際は、それらのベンダー名を使用しませんので、それでは、本日のウェビナーの議題についてお話ししましょう。利用製品を見つけるために調査を最初に開始した際の目標についてご説明します。次に、選定したベンダーについてお話しし、調査を実施した際にそれらのベンダーについて何が分かったかをお伝えします。さらに、採点方法についてお話しします。これは、選定したベンダーを実際に評価した方法に関連しています。スコアの結果をどのように提示したかをお見せします。これには各ベンダーの評価結果も含まれます。調査の結果について、プロセス全体の現在の進捗状況も含めてお話しし、最後に質疑応答の時間を設けます。なお、JPLからの情報公開プロセスは厳格であるため、、質問は現在行っているこのウェビナーに関連する内容に限定させていただきます。本調査で取り上げた製品やベンダーについてお話しする際、「ベンダー」とは利用ソリューションを提供する企業を指し、「製品」とは、当社が管理・保守し、お客様に提供しているソフトウェア を指します。したがって、皆様が社内で管理・保守し、お客様に提供している製品についても同様です、当社ではこれらの用語を同義語として使用していますが、本セミナーではこれらの正確な用語を厳守するよう最善を尽くします。万が一誤りがあれば、その都度訂正いたします。

[3:58]では、本題に入りましょう。本調査の目標についてお話しします。まず第一の目標は、利用状況データの「質」……いえ、すみません、「量」を増やすことでした。実は、利用状況の管理のために自社開発したツールにおいて、多くの製品がロギングデータを生成しており、私たちはそのロギングデータを利用して利用状況を収集・管理し、社内の-社内ツールでグラフを作成して提示していました。しかし、このログデータの利用には大きな問題があることが判明しました。ベンダーがバッファからログへデータを書き出さなかった場合、ログが正常に記録されないことがあり、そのデータを遡って再処理しなければならなかったのです。その結果、利用状況レポートに問題が生じ、定期的に修正を余儀なくされました。このため、社内のステークホルダーはデータに対する信頼を失い始めていました。なぜなら、遡って再処理しなければならない状況が繰り返されることで、データ収集システムの安定性が本来あるべき水準に達していないと感じていたのです。これが、データの品質と信頼性をいかに向上させるかを検討するために本調査を実施した理由の一つでもあります。調査の結果、データはステークホルダーが認識していたほど悪くはないことが判明しましたが、その認識そのものも、私たちが適切に管理すべき課題であることは間違いありませんでした。

[5:36]このプロセスの一環として、社内ツールの使いやすさを向上させたいという課題が浮き彫りになりました。具体的には、ツールをよりサービス指向アーキテクチャ（SOA）型のツールへと進化させ、ユーザーがバックエンドの利用データを用いてレポートを作成するために、私や他の開発者に頼る必要性を減らし、ツールにアクセスして自らより多くのレポートを取得できるようにしたいと考えました。すでにこの研究の一環として機能していた社内ツールがあったため、それが今後も使い続けたいツールであるかどうかを確かめたかったのです。当初、社内ツールを構築した時点では、業界に十分なツールが存在していなかったのですが、今回の研究を通じて、それが私たちが今後も使い続けたいツールであることを確認したかったのです。社内ツールがすでに存在し、本調査の一環として問題なく機能していたため、今後も引き続きそのツールを活用していくべきかどうかを確かめたかったのです。当初、社内ツールを構築した際、業界には私たちが求める利用状況データを取得できる十分なツールが存在しなかったため、独自に開発しました。したがって、本調査の最も重要な部分は、いわゆる「自社開発か購入か（Build versus Buy）」レポートを作成することでした。これは、自社開発ツールと社内リソースがより良い解決策となるか、あるいは、業界にすでに存在し、現在利用可能な既存のソリューションの方が、本研究のニーズや社内のニーズを満たすのに適しているかを検証するものです。

[7:15]それでは、この調査を実施するために私たちが行った一連の作業について、簡単に概要を説明します。まず最初に、利用状況報告においてどのようなニーズがあるかを評価することから始めました。そして、要件の収集に着手しましたが、ここで重要なのは、既存の社内ツールを基に要件を収集したわけではないということです。社内ツールに基づいて要件を収集したわけではない、という点です。そうしていたら、単に既存の要件を満たすだけになってしまっていたでしょう。むしろ、白紙の状態からゼロで始め、「もし望むものがすべて手に入るとしたら、それはどのようなものか？　私たちが本当に求めているものは何か？　現在のツールには何が欠けていて、社内レポートのニーズを満たすために解決すべき要件は何か？」と考えました。 そこで私はウェブを検索し、調べてみたところ、現在では利用状況レポートを提供するベンダーがかなり多く存在することに驚きました。そこで、それらのベンダーを特定し、ウェブサイトを読み、オンラインのドキュメントをすべて確認しました。公開されている情報だけでベンダーについて十分な把握ができたため、そこから、私たちが求めるレポートの種類に適していると思われる候補を数社選定しました。要件を含めた情報提供依頼書（RFI）を送付しましたが、重要な点は、 各ベンダーと実際に面談し、営業担当者や技術担当者と話し合う段階になって、すでに要件を送付済みだったため、最初の打ち合わせは非常に有意義なものとなりました。具体的な質問にしっかりと焦点を当てることができ、個々の質問や要件について即座に掘り下げていくことができたからです。そのため、各ベンダーとのプレゼンテーションでは、彼らにすべての要件セットへの対応を求め、それぞれの要件をどのように満たしているか、あるいは満たしていないかについて説明してもらうという形となりました 要件セットをどのように満たしているか、あるいは満たしていないかについて説明してもらう形で行われました。

[9:36]当社がパイロット版の実行を決定したベンダーについては、営業担当者や技術担当者が提示するデモだけでなく、当社のデータを用いて実際に製品がどのように機能するかを確認したかったためです。これにより、各製品で特定のレポートを実行することも可能となり、その一連のプロセスを通じて、自社のデータを用いて各ベンダーを評価し、要件に基づいて独自に採点することができました。 そして、調査の最終段階として、これらすべての評価結果と、「自社開発か外部調達か」に関する調査の最終結果を、ステークホルダーに報告しました。

[10:39]これに関連して、私はシステムエンジニアリングのプロセスも実施しました。これには、要件定義書、コンテキスト文書、調査結果といった一般的なシステムエンジニアリング要件文書の作成が含まれていました。そして、これらをすべてまとめ、1つの大規模な報告書として上層部に提出しました。ここで強調しておきたいのは、私たちが要件を収集する際、チームメンバー全員と話し合うことが極めて有益だったということです。具体的には、上層部や、ライセンスファイルの変更やサービス提供を管理するライセンス管理担当者、顧客に提供する個々の製品を具体的にサポートするプロダクトリーダー、そして分野リーダーと話し合いました。ここでいう「分野」とは、当社のステークホルダーグループを指し、機械工具のマネジメントチームや機械エンジニア、 電気エンジニア向けの電気ツール、そしてソフトウェア システムツールといった各分野のステークホルダーグループです。そこで、これらすべての情報を収集したところ、そうすれば、私たちと同様に、誰もがそれぞれわずかに異なる情報を求めていることに気づくはずです。例を挙げると、マネージャーたちは、時間の経過に伴う利用状況に関する詳細な情報を求めていました。ライセンスはどのように使用されているのか、十分なライセンス数はあるのか、といった点です。一方、製品サポートリーダーたちは、拒否通知がどれほど発生しているか、誰がそれを受けているのか、そして拒否の原因は何なのか、といった点により関心を寄せていました。こうした点が、ツール自体の要件策定の原動力となりました。ですから、利用状況レポートに関与するすべての関係者から要件を収集することをお勧めします。 利用状況レポートが示す内容に関与するすべての関係者から要件を収集することをお勧めします。

[12:56]そこで、要件を収集した後、パイロット運用を開始したところ、調査の結果、選定した製品については、相当数の製品に対応していることを確認する必要があることが判明しました。これは、社内の-社内ツールが、ログを用いたライセンス配信（ソフトウェア ）に対応していなかったという問題に遡ります。また、より多くの製品をサポートするために既存の製品を置き換えることとなった場合、その代替となる製品には、非-サポートされていない製品データをインポートできることを確認する必要があることがわかりました。その重要性は、顧客に提供しているあらゆる製品について、その利用状況をベンダーのツールに取り込む手段を確保したいという点にあります。提供している特定の製品について、その製品がログを生成しない場合を除き、ベンダーの製品に利用状況データを取り込む方法がないとは言い切れませんでした。

[14:32]私たちは、多くのパーソナライズされたレポートが必要であることを認識しました。これは、非常に多くのステークホルダーが、さまざまな角度からデータを確認しているという事実にも表れています。そのため、このツールがすべてのステークホルダーのニーズを満たすのに十分な堅牢性を備えていることを確認する必要がありました。また、ステークホルダーは「常にツールにアクセスしてログインし、レポートを実行する」ことを望んでおらず、データが自分たちの元へ届くことを求めていたことがわかりました。そこで、朝になると、スケジュールされたレポートがメールで配信されるようにしたいと考えました。日次レポートの場合もあれば、週次レポートを希望する人もいます。これが私たちの重要な要件の一つでした。

[15:24]また、ベンダーのツールから生成されるレポートに、当社の人事情報が確実に含まれるようにしたかったのです。その点で重要だったのは、生成したいレポートには、例えば、当社の人事部門や組織構造内の各グループが、具体的にどのようにツールを活用しているかといった観点からのデータ分析が含まれる必要があると判明したことです。しかし、利用状況のデータは生の状態で提供されるため、、その情報は含まれていないため、ベンダーのツールがそれらの情報を統合し、組織全体の観点からクエリやレポートを作成できるようにする必要があります。

[16:13]我々は、拒否事由の報告体制が確実に充実していることを確認したいと考えており、その報告は焦点を絞ったものである必要があります。ご存知の通り、製品によっては、ライセンスのリリースに移行する前に拒否事由が記録される場合があるためです。そこで、ベンダーの製品内における拒否事由の報告機能が、発生する様々な種類の拒否事由に対応できることを確認したいのです。また、ステークホルダーの一人は、リアルタイムの-タイムの情報を得ることに非常に強い関心を示していました。つまり、システム上で今何が起きているか、誰が現在ログインしているかといった情報を、そのユーザーがどのグループや部署に所属しているかという人事情報と照合することです。

[17:18]さて、調査のこの段階では、要件をまとめ、ベンダーと話し合い、パイロット実施のためのベンダーを選定し、システムに自社データも投入しました。これにより、利用率管理ツールに何が必要かについての初期的な情報が明らかになりました。そこで、パイロットを実施したベンダーについて学んだ点について、簡単に説明したいと思います。ベンダーAは、非常にすっきりとしたモダンなインターフェースを備えていました。一つひとつ詳しく説明はしませんが、重要な点として、すっきりとしたモダンなインターフェースがあったことが挙げられます。この製品ではオンサイトでのパイロット実施はできませんでしたが、設計されたオンラインインターフェースを備えており、レポート作成に利用できるデータも豊富でした。ベンダーAについて私たちが重要だと認識した点は、最後の箇条書きにある通り、データの提示がサーバー視点で行われていたことです。これが重要な理由は、当社のトライアドシステムでは、3つのトライアドすべてから同時にレポートを実行することができなかったため、レポートの観点から制限があったからです。また、このベンダーには、拒否件数をフィルタリングする機能に問題がありました。

[18:58]そこで問題が生じました。ベンダーBについては、私たちが学んだことや重要な点は以下の通りです。つまり、ベンダーBのの製品は非常にスリムで洗練されており、JavaScriptもほとんど使われていませんでした。生成される画像も非常にシンプルでしたが、必要な機能はすべて備わっており、ベンダーAと比較しても、不承認件数をフィルタリングする機能があり、レポートの範囲を制限することができました。しかし、ベンダーBについて興味深かったのは、そのスリムさゆえに、レポートの量を増やすという研究要件をベンダーBが満たせるかどうかを評価せざるを得なくなった点です。

[20:01]ベンダーCについてわかったことは、ユーザーインターフェースが非常にうまく設計されていたということです。ベンダーCに関して私たちにとって特に重要だったのは、ローカルに保存されるLDAPデータでした。その重要性は、それによって当社の組織内LDAPシステムにかかるリソース負荷が軽減された点にあります。つまり、ベンダーは情報を収集するために常に当機関のLDAPシステムにアクセスする必要がなくなり、また、ベンダーは人事情報とその経時的な変更履歴も保存していたため、例えばグループの人数が変更された場合、その情報も自動的に更新されました。これにより、グループ情報の推移を把握できる点が重要でした。 ベンダーCは、他のベンダーと比較して多数のライセンスサーバーに対応しており、25種類の異なるライセンスベンダーをサポートしていました。また、ベンダーCには、私たちが-社内のツールに備わっていた機能で、私たちも気に入っていたものがありました。それは「疑似ベンダー」の作成機能です。ライセンス管理に携わっている方ならご存知かと思いますが、一部の製品サプライヤーはライセンスファイルを送信する際、複数の製品を1つのライセンスファイルにまとめて送ってくることがあります。その場合、そのデータを抽出し、顧客に提供している個別の製品として利用状況を把握できるようにする必要があります。ベンダーCにはその機能があり、私たちはその点を高く評価しました。

[21:46]そこで、ベンダーを評価し、ベンダーによるデータ収集が行われていました。ベンダーの能力と当社のニーズや要件を適切に照らし合わせられる段階に達したと判断した時点で、採点プロセスを実施しました。その経緯は以下の通りです。まず、各要件に対して重み付けを行い、その重み付けを10点満点で評価しました。私は1～5点スケールではなく、2～10点スケールを採用しました。これは個人的に、レベル8やレベル10の要件が満たされた際には、それらの重要な要素に対してより高い点数が付与され、一方、レベル2やFといった低レベルの要件がが満たされなかった場合にスコアが下方へ偏るようにしたかったからです。これが私の最初の目標でした。2つ目の目標は、それによって、経営陣やステークホルダーにとって、より意味のある最終スコアが算出されるようにすることでした。重み付けされた各要件についてベンダーを評価し、各要件ごとにスコアを付与しました。その後、そのスコアに重み付け係数を乗算し、それが各ベンダーの各要件に対する最終評価となりました。

[23:41]では、具体例を挙げてみましょう。ここでご覧いただいているのは、私の総合レポートの一環として作成した成果物の一つです。これは要件番号36で、TURは「ツール利用状況レポート（Tool Utilization Reporting）」の略です。この要件では、ベンダーの製品がカスタムレポートを作成できるかどうかが問われています。当社の社内ツールはこの要件を満たしていました。その理由は、私がシステムをバックエンドから設計した際-エンドとデータベーステーブルが存在していたため、システムに対して独自のSQLを記述する方法を知っていたのです。そのため、この要件を満たしていました。ベンダーAは、この要件を満たしていないと主張していましたが、評価の過程で、SQL文を生成してシステムに注入できるWeb GUIインターフェースがあることを発見したため、実際にはスコアを高く評価しました。ベンダーBについても同様に、バックエンドの-endのデータベースにアクセスしてデータベーススキーマを確認したところ、それほど複雑ではなく、そのデータベーステーブルを習得して生のデータに対して独自のSQL文を作成できると感じたため、ベンダーBについても同様の判断を下し、「要件を部分的に満たしている」という評価を与えました。ベンダーCもこの要件を満たしており、システムに組み込まれた堅牢なレポート機能を備えていました。今振り返ると、ベンダーCには「要件を上回る」という評価を与えるべきだったかもしれませんが、結局12点となりましたが、まあいいでしょう。

[25:44]では、私が作成した別のレポートの例をご紹介します。これは評価結果を視覚的に表現したもので、各ベンダーのスコアを素早く簡単に把握できるように作成しました。ご覧の通り、これらは10点満点での評価です。なお、ここでは実際の要件ではなく、要約のみを表示しています。実際には、このような表現で要件を記述することはありませんが、ベンダーAとBが一部の要件を満たせていないことがわかります。たとえそれらが当社の必須要件」に指定されているにもかかわらず、ステークホルダーはこれを見て、「そのツールを選択した場合、それらの要件がなくても問題なく運用できるかどうか」を自問することになるでしょう。

[26:36]では、重み付け10の要件すべての結果に関する評価基準をご紹介します。これらは必須要件であり、計15項目ありました。重み付け10の要件の中には、業界のすべてのベンダーが満たせると期待されるべき要件がいくつかあったと感じています。例えば、「稼働率の時間外レポートを作成できること」という要件がありましたが、要件収集の観点からは、重要な要件ではありますが、そのせいで、すべてのベンダーが「重み付け10」の要件でやや高めのスコアを獲得することになります。しかし、ベンダーAは、これらの「重み付け10」要件において、私が予想していたほど高いスコアを出していなかったことに気づくでしょう。ベンダーAを振り返ってみると、その理由は、彼らがデータをサーバー側の視点で提示していたためだと考えられます。そのため、、3つのシステムを合計したその他のレポートをすべて取得できなかったのです。例えば、当社の社内ツールは非常に高いスコアを獲得しましたが、それは自社で構築したためであり、当然ながら重要なニーズをすべて満たしていました。というのも、重み付け8の要件――これらは極めて重要視されていた要件で、14項目ありました――において、興味深いことに、この時点でベンダーAは、これらの要件を満たす能力において著しく遅れをとっていました。これらの要件は基本を超えるものであり、単なる基本機能にとどまらず、使いやすさを高め、当機関のニーズを満たし始める段階の要件です。これらは、ベンダーが当社のビジネスニーズをどこまで満たしているかが明確になり始める要件です。ご覧の通り、こうした領域においてさえ、当社の社内ツールですらすべての要件を満たしていなかったことがわかります。この結果は、「自社開発対購入」レポートに反映されており、調査のこの部分では、これらの要件を満たすために自社ツールへの投資が必要となる領域を示しています。ここでご覧いただけるように、ベンダーCは極めて良好な結果を示し、当社の社内ツールよりも高いスコアを記録しました。

[29:15]こちらは重み付け6の要件の結果ですが、この分野でもベンダーBはかなり遅れをとっており、当社の社内ツールもあまり良い結果を出せませんでした。ここには、社内開発ソリューションを採用すべき大きな領域があり、これが社内投資の相当な部分を占めることになります。 重み付け4の要件については、ベンダーBがここでもまた遅れをとっており、ベンダーCは当社の社内ツールよりも良好な結果を出しました。重み付け4の要件は7つあり、これらはある程度重要な要件です。一方、重み付け2の要件は2つしかなかったため、そのグラフは含めませんでしたが、こちらが最終スコアです。ご覧の通り、ベンダーCのスコアが当社の社内ツールよりも高くなっています- 社内ツールよりも高いスコアを獲得していることが分かります。ここからは、どのベンダーも社内ツールも当社の要件をすべて満たしていないことが分かります。したがって、ステークホルダーは、満たされていない要件が何であるかを評価し、それらの要件が社内プロセスに与える影響を判断する必要がある領域があります。この最終スコアチャートが示しているのは、実際には当社の社内ツールとベンダーCのどちらを選ぶかという判断が必要になるということです。

[31:11]こちらがすべての要件に関するヒートマップです。これを見れば、各ベンダーおよび当社の社内ツールのパフォーマンスを、非常に素早く、かつ一目で把握することができます。私が興味深かったのは、「要件を上回る」というカテゴリーを設けたのですが、予想していたほど多くありませんでした。「要件を上回る」という項目はもっと増えると思っていたのですが。もちろん、緑は「要件を満たしている」、黄色は「ある程度要件を満たしている」、赤は「要件を満たしていない」を表しています。このグラフの重要な点は、レベル4の要件を見ると、ベンダーBやベンダーCだけでなく、当社の自社開発ツールでも要件を満たせていないという大きな赤いブロックがあることです。業界標準のベンダーAはそれらの要件の一部を満たしていましたが、この領域については、改めて要件を見直し、『これらは本当に私たちが問うべき質問なのか』と自問する必要があります。なぜなら、業界標準のツールではそれらの質問に答えられていないことが判明しているからです。

[32:39]さて、製品の評価と採点が終わりましたので、次は「自社開発か外部調達か」の検討における最後の段階、つまり採点結果を投資コストと比較する段階に入ります。これがその結果です。ここで、購入コストのグラフの線は、それ自体を基準としています。スコアだけを見てコストを推測できないようにしたかったため、コストは目立たないようにしています。これは規模に対する相対的なものですが、正確に表現されています。これを見れば、各ツールにかかる実際の投資額や、社内開発のコストが社内ツールのコストは、要件を満たすために社内で投資すると予想していたコストを表しています。また、ここでのコストには、維持管理の人件費は含まれていないことをお伝えしておきます。これは、そのコストが固定費であり、各ツールを通じて同じであると予想していたためです。

[34:13]さて、この調査の結論ですが、前のグラフでもお分かりのように、ベンダーCはその分野において投資額あたりの機能数が最も多いことが判明しました。つまり、ベンダーCの方が、当社の社内ツールよりも投資対効果が高いと判断したのです。自社開発ツールよりも優れた投資対効果をもたらすことが判明しました。ベンダーCには、当初の要件定義書には盛り込まれていなかった機能さえ備わっていることが分かりました。そして最終的な結論として、自社ツールの再構築にかかるコストと、ベンダーC製品を購入することで得られるメリットを比較した際、そのコスト差を正当化することはできないと判断しました。したがって、「自社開発か購入か」という検討の結果、購入を選択し、ベンダーCの製品を導入しました。

[35:17]さて、現在の状況ですが、ベンダーのフェーズ1導入を完了したところです。これには、ベンダーの製品でネイティブにサポートされているすべての対象ライセンスツールのインストールが含まれていました。驚くべきことに、これらは当社が顧客に提供しているツールのかなりの割合を占めていました。現在、データを収集している段階では、社内ツールとベンダーCのツールを並行して稼働させており、今後時間をかけて、社内ツールを段階的に廃止していく予定です。社内ツールの段階的な廃止を進めていく予定です。その間、社内関係者を対象に、ツールの使用方法やレポートの検索・理解方法に関するトレーニングを継続して実施しています。また現在、関係者が求めるカスタマイズされたレポートを作成するプロセスも進めています。

[36:29]ここで私たちが経てきたプロセスは、私が考案したものではなく、標準的なシステムソフトウェア システムエンジニアリングの実践です。このプロセスに関する参考資料は、この本に記載されています。第22章で具体的に解説されています。ですから、ソフトウェア の要件に関連するベンダー評価のプロセスについて調べてみることをお勧めします。評価を行う上で業界標準を参照し、活用できたことは非常に役立ちました。これにより、評価を行う自信がつき、経営陣に向けて作成する報告書が業界のベストプラクティスの一部であることを確信できました。本日はお集まりいただき、お聞きいただきありがとうございました。皆さんがこの内容を興味深く感じてくださり、ご自身でもこのようなプロセスを試してみたいという刺激を受けていただければ幸いです。