お客さまの未来をデザインする、アークウェイの開発コンサルティング

DevOps Hubでは、DevOpsを実践している企業のインタビューをお届けしています。第3回は、株式会社アークウェイのコンサルティング サービスについて、お話を伺います。
(写真：左から株式会社アークウェイ　中西庸文氏、奥田直人氏)
株式会社アークウェイは、2004年東京に設立。ソフトウェアアーキテクチャを中心とした開発プロセスの策定・導入、開発標準化のためのコンサルティング サービスを提供しています。

DevOpsとは、IT部門のビジネス貢献度を向上させる取り組み

──貴社の事業について教えてください。

奥田：弊社の「アークウェイ」という社名は「Architecture Way」を由来としておりまして、ソフトウェアを通じて、お客さまの未来をデザインしていく『未来デザイン』というビジョンの元、事業を展開しております。

我々は、ITシステムの根幹である、ソフトウェアアーキテクチャに対して、未来の姿を定義するための戦略を練るコンサルテーション、ソフトウェアアーキテクチャそのものの構築、ITシステムへの適用、新技術の導入を主な事業として展開している会社でございます。

──お二方のチームではどのような業務を行われていますか。

中西：私は、DevOpsグループのリーダーをしております。DevOpsを導入したいお客さまや、生産性・品質の向上を命題として掲げているお客さまに対して、どのように開発・運用を改善していけばいいのかをコンサルティングさせていただくことが多いですね。製品導入から使い方、開発工程のプロセス改善まで、お客さまの目指すべきゴールに辿り着くためのロードマップを描き、ステップ・バイ・ステップで段階的にゴールを目指して行くコンサルティングを行っています。

奥田：私は、イノベーショングループに所属しています。新しいテクノロジーをお客さまにソフトアーキテクチャとして、コモディティ化して導入するのが、主な仕事ですね。特にここ１、2年はマイクロサービスアーキテクチャにフォーカスしています。マイクロサービスアーキテクチャと、それを取り巻く新しいテクノロジーを組み合わせて、プラットフォームを選定し、お客さまに展開しています。

マイクロサービスは概念であるだけでなく、実装も伴います。「今、世の中でマイクロサービス化が進んでいるのに、私達は何から始めればいいんだろう」と、皆さん困られてしまっているケースが多いのですが、そういった問いに答えるべく、日々活動しています。マイクロサービス化を進めると、今までのITシステムよりも、小さなサービスがたくさん立ち上がることになるので、サービス群を維持・メンテナンスしていきながら、かつショートタイムで価値提供できるようにリリースし続けなければならなくなります。そう考えますと、DevOps、そして自動化を実施しないと立ち行きませんので、OSSも含めたプラットフォームも含めてお客さまにご提案しています。

アークウェイ　アーキテクチャソリューション部　イノベーショングループ　グループ長　アーキテクチャーデベロッパー　奥田直人氏

ーマイクロサービス化を進める上でもDevOpsは不可欠ということですが、貴社の中でDevOpsの定義はありますか。

中西：一般的に言われているように、「開発部門と運用部門が協調する」という点はもちろんその通りなのですが、結局はエンドユーザーに迅速かつ高い品質で、確実にソフトウェアとしてのビジネス価値を提供し続けることなのだと思います。それによって、IT部門のビジネス貢献度を向上させる取り組みではないかなと考えています。

奥田：DevOpsという言葉にDevとOpsは含まれているんですけど、「Userが入っていないな」といつも思っていました。本来は Dev と Opsが協調して構築・改修したソフトウェアをユーザーがすぐに確認し、ビジネス価値につながるか、業務をよりよくできるかを判断してリリースする必要があるはずです。ユーザーが利用してこそのソフトウェアですので。

中西：「いつも現場から要求ばかり来て、終わらない開発になっちゃう」というような声をよく聞きますが、ユーザーのビジネス価値に繋がる要求以外はやらなくていいんですよね。いかに無駄を省いて圧縮してリリースタイムを短くするかということが大事なので、要求を実現すべきかどうかの判定をしていただくためにも、やっぱりユーザーって不可欠なんですよ。

ーユーザーの反応を見て、何を継続すべきか、やめるべきか、事業として判断することが重要なのですね。貴社で取り組んでいるDevOpsについて教えていただけますでしょうか。

奥田：弊社では、DevOpsをお客さまに提供することを前提として、このソフトウェアの組み合わせ、運用の仕方、回し方だったら良くなるというのを自分達でドックフードして、その結果を元にお客さまに提示しています。

中西：私のチームでは、開発を改善したいというお客さまのサポート、DevOpsという考えの定着化、適応・展開をしています。

開発側とビジネス側のギャップを埋める

ー貴社で、長く活用されているツールはありますか。

中西：Visual Studio Team Services としてクラウド環境で利用できるようになる以前から、Team Foundation Server(TFS)をずっと使用しています。TFSはオープンソースと比べて、一度入れてしまえば、タスク管理、ビルド、CI、デプロイ、自動テストなど、たくさんのことができるというメリットがあります。色々なツールを組み合わせる時、オープンソースだと組み合わせがうまくいかなかったり、コンフィグレーションが大変になってしまったりするところを、簡単にできる点も便利ですね。

また、お客さまから「VSSのサポートが切れるんだけど、TFSで何ができるのかよくわかりません」「使い方がわからないので、教えてください」というお問い合わせをよくいただきます。まず、お客さまには「本当は何がやりたいんですか」とお聞きして、導入の目的を掘り下げて整理します。その上で、機能が膨大にあるのでどの機能から使えば定着できるのか、学習順序を組み立ててメンタリングでお教えして「この部分ができていないと、このデータが取れませんよ」ですとか「この部分ができてないと、デプロイができないですよね」といった改善のご提案をしていますね。

アークウェイ　アーキテクチャソリューション部　DevOpsグループ　グループ長　コンサルタント　中西庸文氏

ーTFSにしても、バージョン管理システムにしても、まずは使ってもらわないといけないですよね。

中西：チケット管理については、やはり現場ではチケットの粒度に悩んでいたりすることもありますし、個人の開発作業に閉じてしまったりしているケースもあります。自分のローカルマシンの中でバージョン管理システムを使っていながら、一週間ぐらいチェックインしないで溜め込んでしまうんですよ。チェックインの時に、競合してしまってトラブルになるというケースも多いんです。そういったお客さまに「そもそも開発ってこうあるべきじゃないですか」というところからアドバイスをしております。

ーDevOpsでの自動化を始める前提となるバージョン管理システムの動向についてですが、まずは、Gitの使い方から勉強をされている企業さまも多いのでしょうか。

奥田：OSSや一部のサービス開発ではGitが利用されるようなっていますが、バージョン管理システムの利用比率としてはまだまだ Subversion などの中央集約型のバージョン管理システムを利用されているお客様が多いですね。GitHubでOSSさながらに開発している企業の華々しい舞台の反対側では、Subversionをやっと完全に使いこなせるようになったという方や、「私達もGitに移行するべきなのか」と、まだまだ苦しまれているお客さまはたくさんいますよ。

中西：自分でデベロップメントブランチを切るという行為自体が理解できなくて、「ブランチとは、サーバー側でリリースするために分けるものであって、自分の作業のために切るものじゃない」という考え方をお持ちの方もいるので、そのシフトチェンジというのも必要ですね。プルリクエストという文化も、まだ浸透し辛いものがあります。

ー貴社では、ツールの機能の捉え方から使い方まで、きめ細やかなメンタリングをされているのですね。その他、お客さまが開発現場で悩まれていることはありますか。

奥田：ユーザーでしたりステークホルダーの方が求めているスピード感と、開発現場が持っているスピードには、非常に大きなギャップがあるなと感じています。発注工程などがあって、「早くリリースしたい」という思いが、開発現場に失われて届いてしまうことがあります。ビジネス側からすると、半年経てば商流も状況も全然変わってしまいますが、かたや開発側は半年とか一年のスパンでしかリリースできないと、皆さんかなり苦しまれていますね。

まだ、リリース自体に数時間はかけているお客さまも多くて、いかに記録し自動化していくか、オペレーションをより効率化していくかということが求められていると思います。我々も現場の適用まで考えた時に、この製品の組み合わせ、このやり方が最適か、熟考した上でご提案していますね。

それぞれの業種、業態の持っている文化もあります。例えば、金融業界の場合、情報系と、勘定系では持たなければいけない特性が全く異なるので、そこを考慮した時に、本当に何が良いのかを考えてお出しすることが我々に求められているのだと思います。理想のDevOpsの姿が一つの雛形としては存在しているとは思うのですが、その企業の制約や文化に照らし合わせた時に同じ姿になるかというと、決してそうではないと我々は考えています。

継続的なボトルネックの発見・改善

ーDevOpsの導入によって、お客さまにどういった効果がありましたか。

中西：生産性の向上、コスト削減という点が大きいです。各個人が何の作業をしているのか全然わからない状況から、相手が何をやっているのか、自分の作業の前にやるべきタスクは終わっているのか、自分は作業に取りかかれるのかというのが、見えるようになるという副次的な効果もあります。そもそも開発自体がクローズドな環境での業務なので他の方への興味を抱きづらいところから、チームとして意識し合ってメンバーが同じゴールに進めるようになったというお話も聞きますね。

奥田：DevOpsをやることで、別のボトルネックが洗い出されて、短縮されたリードタイムが別のボトルネックを見つけてくれる、つまりボトルネックを解消すれば、別の場所が目立ってきます。

具体的な例で言いますと、大手の製造業さまで実施した時には、実は開発自体のボトルネックよりもビジネスとしての意思決定、ITシステムに対しての発注っていう行為の方が遥かに長かったということがありました。DevOpsを導入しているので、構築してリリースするまでは2週間。でも、その開発の決定までに2週間かかっているという、意外なボトルネックが判明したこともありました。

ーDevOpsが継続的なボトルネック発見・改善につながっているということですね。

奥田：DevOpsを導入すると、コスト削減、品質向上といった効果は当然得られますが、それ以上に、ITの中だけで閉じていたら絶対に見つけられなかったボトルネックが目立ってくるというのは大きな効果だと思います。今までは、エンタープライズですと、SIerに発注してお任せしていたものが、そうではなくて自分達もちゃんとシステムのことを見なければいけないし、SIerの付加価値もビジネス側の要求にもっとフォーカスしないといけないという歩み寄りが出てくる、そのように文化が変わっていくトリガーになると考えています。

中西：DevOpsは、エンドユーザーがビジネス要求をハンドリングするための責務を持つこと、運用と開発のチームがITによってビジネス価値を提供すること、この二つが一体となってビジネスに向かっていきましょうという工程だと思うんです。

時代とお客さまに合った設計図を提供し続ける

ーお二方のチームの今後の展望を教えてください。

奥田： AI,Bot,IoTは、外せない領域だと思いますし、実際取り組みも始めているところですね。IT自体にもAIの良さを取り入れて行きたいのもありますし、運用のボトルネックをAIが見つけてくれるサービスを活用していけるようできればと思っています。また、できるだけ運用に関しては自動化して、運用と開発は最初から設計図として意識して作り、プラットフォームを含めたアーキテクチャを提供していきたいです。

中西：お客さまの状況・課題に合わせて、検討前、検討中、導入中とDevOpsのサービスを細分化し、適用していく取り組みを、続けていきたいなと思います。全体を把握して、ロードマップを描いて、お客さまと共通のゴールに向かって進み、将来的には「IT部門のビジネス貢献度の向上」を目指していきたいです。

アークウェイさまのきめ細やかなコンサルティングがお客さまの継続的なボトルネックの発見・改善につながり、IT部門の価値を向上させていることが伝わってきました。
お話しいただき、ありがとうございました！