サービスを高速に進化させる ソフトウェア技術の実際

2017.09.07
リスト
このエントリーをはてなブックマークに追加

アイデアを創出したら、いよいよサービスの実装である。この段階ではどれだけ迅速にサービスを実装し、提供し、フィードバックを得て改良し続けられるかが重要である。目論見通りに行かない場合、アイデア創出、あるいは情報収集に戻ってやり直す必要があるからだ。手戻りにも思えるが、デジタルジャーニーにおいては自然で当然のアプローチである。ではどのように迅速に実装し、改良するのか?ここではその点にスポットを当てる。

共創のためのサービス体系における「サービスの実装」フェーズでは、「アイデア創出」で生み出したアイデアを実際に稼働するサービス/システムとして実装していく。ゴールは「サービスを作ること」ではない。サービスの利用者からのフィードバックを得てアイデアの有効性を確認し、リファインしたり、方向転換を図ったりする。いわゆる「リーンスタートアップ」のスタイルでサービスを成功させるのが真の目的だ。

したがってサービスの実装では手戻りや失敗を行うこと─試行錯誤─は大前提となる。この点はSoRとの大きな違いだ。とはいえ、大きな手戻りや失敗は時間やコストの浪費となり、プロジェクトをストップさせる原因になる。そこで必要となるのは、「(1)小さく開発、(2)すぐにリリース、(3)フィードバックを受けて、(4)方向性を定める」というサイクルを迅速かつ小刻みに行う「アジャイル型の繰り返し型開発」の実践である。

繰り返し型開発を支援するソフトウェア

繰り返し型開発においては、開発やデリバリをスピーディーかつ持続的に回し、市場からのフィードバックを積極的に取り込むために、「アジャイル開発」や「DevOps」といった手法やプラクティスの実践が重要だ。単に形の上でアジャイルであるというレベルではなく、事業を担う組織や開発チームの文化、風土として定着させる必要がある。

そのために有効な手段となるのが以下で紹介するソフトウェア群だ。とりわけ(1)刻一刻と変わるプロジェクトの状況を可視化する「プロジェクト管理機能」、(2)開発資産に対して頻繁に行われる変更を整然と管理するための「バージョン管理機能」、(3)開発からデリバリまでの繰り返しのサイクルをミスなく素早く回すための「CI/CD(継続的インテグレーション/継続的デリバリ)機能」を提供するソフトウェアは欠かせない。

(1)プロジェクト管理機能

日本のシステム現場では線表(ガントチャート)を用いて進捗の予実を管理してきた。しかし、計画から実行までの期間が極端に短かったり(数時間~数日)、一度立てた計画を頻繁に変更する必要があったりする試行錯誤の繰り返しや、フィードバックへの対応を優先するプロジェクトにおいては、これは現実的でない。

こういったプロジェクトでは「チケット管理ツール」(「バグ管理システム」とも呼ばれる)や、「タスクボード」などのツールで管理するのが一般的だ。改善要望やバグなどすぐに対応すべき内容をチケットの形で管理ツールに登録し、タスクボード上でその対応状況(未着手、調査中、実装中など)を可視化するのが基本である(図1)。


図1:タスクボードの例 (GitLab社の開発支援ツール「GitLab」を使った場合の画面例)

(2)バージョン管理機能

リリースやフィードバック対応を頻繁に繰り返す場合、複数のメンバーが同一のソースコードを対象にして小規模な変更を同時並行で行わなければならないシーンが多い。その際に「ある人は古いソースコードを、別の人は新しいソースコードを変更する」といったことが起こると、整合性がとれなくなってしまう。そこで重要になるのが、バージョン管理である。詳細には触れないが、過去の任意のバージョンをすぐに復元できるようにする「タグ」、並行開発を混乱なく進めるための「ブランチ」、同時並行で行われた複数の機能追加やバグ修正を整合性のとれた形でリリースするのに役立つ「プルリクエスト(あるいはマージリクエスト)」といった機能を備えたバージョン管理ツールを利用する(図2)。


図2:バージョン管理機能(タグ、ブランチ、プルリクエスト)

(3)CI/CD機能

繰り返し型開発のサイクルを素早く回すために欠かせない取り組みが「自動化」だ。特にコンパイルやテストのように「あらかじめ手順が決まっている」「何度も繰り返す必要がある」といった作業は、自動化しないとスピードは上がらない。例えば1回のリリースで変更した部分が小さくても、変更していない箇所への影響の有無も含めテストは行う必要がある。これを人手でやっていると、どうしても時間がかかってしまう。これに対し、テストを自動化すれば改修からリリースまでの時間を短縮できる。

テストの自動化を適切なタイミングで実行するのがCIツールだ。例えばバージョン管理システムにアップデート版を登録したら、即座に自動でテストが実行される。さらに、「テストをクリアしたアプリケーションを、自動的に実行環境にデプロイ(配備)する」ことも可能だ。CI/CD機能を利用すれば、これまで日や月の単位でかかっていた作業を、分や時の単位で終えることができるようになるのだ(図3)。


図3:テスト自動化と継続的インテグレーション/継続的デリバリ(CI/CD)の効果

リーンにサービスを提供できる開発・実行環境「MetaArc」

説明した(1)~(3)のソフトウェアは「アジャイル型の繰り返し型開発」を実現するために欠かせないが、もちろんこれらだけではない。オープンソースソフトウェア(OSS)の活用やWeb APIによる既存サービス機能の利用、コンテナ技術を中心とするマイクロサービス・アーキテクチャの採用など、今日では迅速にかつ低コストでサービスやシステムを開発、リリースする技術が普及しつつある。そして、そうしたソフトウェアや技術を使いこなすための基盤環境がクラウド、富士通で言えばMetaArcである。次にMetaArcを例に、もう一歩踏み込んで解説しよう。

MetaArc上で動作するサービスを開発・実装する場合、開発環境の制約はない。Microsoft製品になじみがあるチームならば「Visual Studio Team Services」、OSSを活用したソフトウェア開発を得意とするチームならば、OSSの世界で広く使われている「GitHub」といったふうに、プロジェクトの事情やチームメンバーのスキルセットに合わせて自由に開発環境を選ぶことができる。

開発環境に比べ、より多くのコンピュータ資源を必要とし、柔軟に設定する必要もある実行環境はどうか?他の多くのクラウドサービスと同様だが、MetaArc上にも「実行環境の構築」を完全に省略できる仕掛けがある。それが次に説明する「CF」だ。

CFによるサービス実行

CFはオープンソースのPaaSである「Cloud Foundry」をベースにした実行環境である。CFは「コンテナ型仮想化技術」を用いてアプリケーションを起動するため、ハイパーバイザー型のVMであれば分単位でかかるデプロイ処理も、秒単位で行うことができる。当然、より多くのインスタンスを稼働させるスケールアウトも、コマンドひとつで行える。この場合もコンテナ型仮想化技術が適用されるため、起動は秒単位だ。これにより最初は少ないインスタンス数でサービスを提供し、利用が増えてくればインスタンス数を増加させる、という形の運用が可能になる。「余裕を持って最初から多めのインスタンスを起動しておく」といった配慮は不要になるため、無駄なコストもかからない。

リーンスタートアップによるサービス提供には、CFのような仕掛けは不可欠だ。Cloud Foundryに関しては多くのドキュメントがあるので詳細は省くが、上記のような仕掛けにより「(1)小さく開発、(2)すぐにリリース、(3)フィードバックを受けて、(4)方向性を定める」というサイクルを加速できるのだ。

サービス実装の更なる加速

以上、紹介した開発・実行環境は、繰り返し型開発にとってなくてはならない手段である。しかし、これらを駆使したとしても、最新技術をふんだんに使ってサービス開発を行う場合、技術習得や技術検証、あるいは複数の技術のインテグレーションには、どうしても時間がかかる。例えば、コールセンター業務を行っている企業が「自社のデータベースに蓄積されている豊富な応対データを活用して業務の機械化を行いたい」と考えた時、実現に向けてどのように考えるだろうか?

データはすでに豊富にある。このデータに「機械学習」を適用すれば、利用者が望む回答を的確に導き出すサービスができそうだ。またユーザーインタフェースには「チャット」を使えるし、「音声認識技術」により電話対応するのも手かもしれない。しかし利用者による問い合わせを、どう認識すればいいのだろう? それには「形態素解析」が使えそうだ…。必要な技術はこのように揃っているが、それを本当に使いこなせるだろうか?

もちろん富士通では、それができる技術者を訓練し、育成している。しかし一人ですべての技術に精通する技術者は残念ながら存在しない。未経験の技術者と比べればはるかに早くアプリケーションを構築できるにせよ、どうしても一定の時間がかかってしまうのだ。もしかしたらその間に他社に先を越されてしまうかもしれない。そうならないためには実装スピードを上げるための仕掛けが必要だ。

そこで富士通では(1)「先端技術をインテグレートしたAPI群」と(2)「業種・業務の共通機能をサービス化したソフトウェア部品」をセットで提供する取り組みを進めている(図4)。言うまでもなくこれらは万能ではないし、むしろ利用シーンは限定される。SoEというよりSoRに近いサービス開発に向く手法である。それでも我々はリーンスタートアップには欠かせないと考えている。これらは初めの第一歩であり、第一歩をスムーズに踏み出すことでより本格的なSoEに展開できる面もあるからだ。


図4:サービス実装を加速させるソフトウェア部品やAPI利用の仕組み

(1)先端技術をインテグレートしたAPI群

機械学習、チャット、音声認識技術、形態素解析といった先端技術をインテグレートしたサービスを準備している。ここには最適なマイクロサービスや自社システムをサービスとしてプラグインで組み込む機構も備えており、実装したいサービスの短期構築を可能としている。個々の技術に精通していなくても素早くサービス実装を行えるのがメリットだ。技術的な実現性検証の対象が大幅に減ることになるため、先程述べたコールセンター業務の例では、プロトタイプ開発の期間を大きく短縮できる。または、実データを活用した検証にもすぐに着手でき、サービス開発を迅速にできる。

(2)業種・業務の共通機能をサービス化したソフトウェア部品

前述のコールセンター業務を多様なお客様接点の実現やサービス品質向上のためにチャットボットを活用して自動応答システムを実現する場合、「受付、応対、記録」といった標準的な応対のプロセス、応対のためのユーザーインタフェース、質問検索や返答に用いられるチューニングされた標準データ、こういったものが共通機能やテンプレートとしてあれば開発のスピードアップが可能だ。これらをAPI経由で利用できるソフトウェア部品として提供する。また、これらのソフトウェア部品は動的な改善機構を備える。例えば「アクセスログの自動解析と業務改善提案の機能」、「質問・応答履歴の自己学習によるナレッジの精度向上機能」などだ。これらの機能により「成長し続けるサービス」の実現をサポートする。

継続的成長のエコシステム確立に向けて

富士通では、こういったサービス群をいち早く提供することにより、業務サービスの実装を加速する。そして、実際のサービス実装現場から得られたフィードバックをもとにして、共通サービス自身も改善していく。このように、業務サービスと共通サービスの双方が相互に良い影響を与え合い、継続的に成長できるエコシステムの確立に取り組んでいくつもりだ。

執筆者:川上 真一(富士通 デジタルフロント事業本部 デジタルフロントセンター)
倉知 陽一(富士通 デジタルソリューション事業本部 シニアディレクター)

この記事は、IT Leaders特別編集版『Knowledge Integration in Action 2017 in Summer』からの抜粋です。

トップ写真:Nongkran_ch/Getty Images

EVENTイベント