
Observian
Observian は Lucidscale を使って、顧客のために新たに最適化された AWS、GCP、Azure クラウドソリューションを設計するためのチーム間の調整を行っています。
セールス担当に問い合わせる主なメリット
- 既存のアーキテクチャを可視化
- 現状を把握し、顧客との連携を図る。
- 新 たに最適化されたソリューションを設計
- 顧客の AWS、GCP、Azure アーキテクチャの新しい、または最適化されたソリューションを構築。
- 知識の属人化を防止
- 知らずに知識が属人化してしまうリスクを低減。
- アーキテクトやエンジニアのオンボーディングを改善
- 新人エンジニアやアーキテクトがすぐに業務に慣れるよう、必要な情報を一元化。
業界: Tech
サイズ: Small (1-100 employees)
役割: Professional Services, IT
Observian は、クラウド移行、ディザスタリカバリ、セキュリティ、コンプライアンスやコスト最適化などのクラウドサービスを提供するクラウドコンサルティング企業です。

デジタル変革が企業の最重要課題とされる現在、古いシステムやクラウドプロセスを見直し、最適化するための時間とリソースを確保するのは容易ではありません。
Observian は、企業のクラウド運用改善を支援するクラウドコンサルティング企業として、クラウドサービスやソフトウェアのデリバリーを専門サービスやマネージドサービスと併せて提供しています。ネットワークやアプリケーションからクラウドやデータベースの移行といった分野を対象に、再設計のサポートからアプリケーションの刷新プロジェクトまで、その業務範囲は多岐にわたります。
顧客数の急増に対応するため、Observian では業務をスマートにスピードアップできるソリューション、可能であればビジュアルソリューションを必要としていました。同社では、Lucidscale を使って顧客の既存のアーキテクチャを可視化し、高度なアーキテクチャ図を手早く提供することで、顧客のインフラストラクチャ理解、オンボーディングの改善や社内での知識移転の管理を支援しています。
既存のアーキテクチャを可視化
Observian が提案を行い、計画を実行するためには、まず顧客のアーキテクチャの現状を把握する必要があります。
ただ、顧客のアーキテクチャを深堀りしていくには、過去数年、時には数十年の間に構築されてきた内容を見極めていくフォレンジック的な視点が求められます。「顧客の環境内のさまざまな部分を精査し、一つ一つ確認していくことになります。インフラストラクチャやアプリケーションにとどまらず、ネットワークとそれに接続されているあらゆる要素が調査対象となります。」Observian の共同創業者でアーキテクチャ担当バイスプレジデントを務める Scott Plamondon 氏はこう語ります。
ただ、そうした調査に大枚をはたく顧客を相手にする場合には、時間勝負となります。「できる限りのインサイトを得られるよう、当社側でかける時間が長くなれば、専門サービスに顧客が支払う金額も高くなるということになります。」
現状を理解し、将来のあり方を計画する上では最新の状態が反映されたクラウドアーキテクチャ図が不可欠です。しかし、Observian でソリューションアーキテクトアソシエイトを務める Aravind Marthineni 氏によれば、十中八九の確率で顧客の社内には現状を正確に反映したクラウド図が存在しません。
図があったとしても、大抵は後付けです。「監査対応や新製品の設計を行うときに使う程度でしょうね。」Plamondon 氏は続けて、「製品や機能が完成すると『計画とは全然違うものが出来上がったけど、とりあえずこの図は送っておくよ』ということになる」のが常と言っています。
顧客の図は古いバージョンが最新版として使われていることも多く、開発サイクルで行われた正当な変更の説明や記録がされていません。直近の24時間以内にされた変更が確認できないことすらあります。クラウド環境は従来のオンプレミス環境に比べて変化が著しいため、クラウド図は陳腐化しやすい傾向があります。
顧客とのコンサルティングや連携の中で、Observian はこうしたクラウド図を作成して Amazon Web Services (AWS)、Google Cloud Platform (GCP) や Microsoft Azure インフラストラクチャの変更の計画と検証に利用していますが、こ うした図の作成には非常に時間がかかり、詳細が正確に捉えきれない点が課題でした。
1つ、2つのクラウドアーキテクチャを図式化するのも大変な手間なのに、Observian が対応しなければならないアーキテクチャは多数にわたります。「1日に3社の新規顧客を獲得することがありますが、顧客によって求められるクラウド図の内容や側面はまったく異なります。こうした局面で救世主となったのが Lucidscale でした。クラウドからアーキテクチャを直接インポートできるツールは他にありませんでしたので、Lucidscale はまさにその点で先端を行っていたといえます。」Marthineni 氏はこう語ります。
「かつてはクライアント向けの図の作成に4時間から7時間もかかっていましたが、今では既存の図を取り出して少しばかり手直ししてビューを変更し、15分足らずで送信できるようになりました。」
Lucidscale の活用で、顧客の AWS、GCP、 Azure クラウドアーキテクチャの図のスピーディな自動生成に加え、クラウドコンソールと図を切り替えることなく、図内でメタデータにアクセスできるようにもなりました。Lucidscale の図は AWS、GCP、Azure からインポートしたメタデータを基盤に生成されているため、Observian ではネットワークルール、アカウント、リージョンや VPC の概要などの複数の視点から顧客のクラウドを視覚化でき、チームはよりスムーズに顧客の環境を正確に把握し、顧客の求める形でクラウド図とその側面を提供することができています。
Observian では、Lucidscale を使って図をカスタムのビューに絞り、インフラストラクチャの特定の部分へと掘り下げて細部に対応しています。Plamondon 氏はこんな例を挙げます。「顧客にサービスの変更、追加や削除を行ったと伝えられた場合でも、実際に何を行ったかが分かるため、状況が把握しやすくなります。実際にその環境内で確認するのと同じかといえば違いますが、自分自身、またチームが正しい方向に進む上では十分な情報が得られます。」
Lucidscale は Observian のアーキテクチャレビューのサービスフローに直接組み込まれています。Marthineni 氏はこのプロセスを通じて調査結果や顧客への推奨の精査を行っています。
「クラウドアーキテクチャ環境は絶えず進化し、変わり続けています。あらゆる状況を追跡し、非常に精度の高い成果物を顧客に提供する上で Lucidscale が大いに役立っています。」Marthineni 氏はこう説明します。
顧客と一緒にステージを設定した後、Observian のチームは確信を持って、顧客の求める新しく、最適化されたソリューションの構築を進めることができます。
新たに最適化されたソリューションを設計
Observian では、顧客のために新たに最適化された AWS、GCP、Azure クラウドソリューションを構築する過程で、Lucidscale と Lucidchart の両方を常に活用しています。
そのワークフローは以下のようなものです。
- 現在の環境を把握して検証 (Lucidscale)。
- 新規のソリューションまたは最適化を設計 (Lucidscale、Lucidchart)。
- 将来の状態を示す図を使って顧客の承認を獲得 (Lucidchart)。
- 将来の状態を示す図を実装のガイドとして利用 (Lucidchart)。
- 図を更新し、実装が正しく行われたことを確認 (Lucidscale)。
Observian では構築する内容を計画として Lucidchart で図式化し、全員が将来の状態を把握するために使い、この図を構築や実装のガイドとしても活用することで、顧客への納期の短縮を実現していると Plamondon 氏は説明します。
実装が完了した後も、ただ何もせず顧客の反応を伺うのではなく、Lucidscale を使って構築が計画通りに正しく行われたことを検証します。相違が見つかった場合は、最も重要な情報を掘り下げて必要な対応を取り、望ましい成果が得られるまでこのプロセスを繰り返します。
知識の属人化を防止
Observian では、時短や共通認識の醸成、変更の計画や検証に加えて、知識がいつの間にか属人化してしまう、いわゆる「仲間内の智恵」リスクの防止のためにも Lucidscale を活用しています。これは、ある従業員が退社するとその人だけが抱えていた知識も一緒に消えてしまい、社内のプロセスや顧客との関係に大幅な遅延や障害が生まれるリスクを指します。
例えば、5人体制の運用チームであったとしても、インフラストラクチャ全体を完全に理解しているのはその中の1人か2人でしょう。ジュニア開発者など、その他のメンバーはバグの修正や小規模なインフラストラクチャの変更を担当していることが多いものです。
こんな中、悲劇が起こり、メンバーが病欠したり、休暇を取ったりしている最中にインフラストラクチャの障害が起こったとしたら、どうなるでしょう。
「大規模なインフラストラクチャの障害が発生すると、そうしたジュニア開発者にはどのコンポーネントに問題が発生しているのか分かりませんので参照すべきものが必要になります。そこで、図を用意しておくのが重要となるのです。問題の発生時だけでなく、時間の経過と共にチームメンバーが入れ替わる際にも重要です。」Marthineni 氏はこう説明します。
アーキテクトやエンジニアのオンボーディングを改善
1人のメンバーだけが知識と問題の答えを抱え込む事態を避けるため、必要な情報は新任のエンジニアやアーキテクトにもすぐにアクセスできるようにする必要があります。「新メンバーが入るたびに、誰かが新入社員に知識を伝えなければならず、工数のロスが生じていました」と同氏は説明します。「[Lucidscale を使えば] インフラストラクチャ全体を記録した図を作り、ドキュメントにピン留めして常に最新の状態に保てます。」
新任のエンジニアやアーキテクトも Confluence 統合でチームの Confluence ページに埋め込まれ、常に更新されるインフラストラクチャ図を参照できるので、研修をシニアレベルのメンバーまかせにすることがなくなります。「分からない点があったら、チームリーダーやマネージャーに相談して解消することができます」と Marthineni 氏は話します。
Plamondon 氏は、どんなプロジェクトであれ、スピードと透明性、信頼を基盤に対応することで、きめ細かい顧客管理と顧客関係の向上が実現し、成功につながっていると話します。同社では、プロジェクトの開始前にアーキテクチャ図で社内調整を行い、顧客にスケジュールやサービス提供内容、成功へのパスを十分に理解してもらうようにしています。
Lucidscale を活用して、Observian は戦略的提案を行い、さらに顧客が理解でき、維持できる質の高い成果を実現しています。チームと顧客との間にこうした共通認識があってこそ、クラウドから得られた洞察をクラウドの成功につなげるという同社の約束を実現することができるのです。