【前編】開発者に贈る最新のクラウドアーキテクチャとアジャイル開発の肝とは～「DIGITAL Decision 2022 “Engineer Night”」レポート
コロナ禍に突入してから、ビジネスを取り巻く環境は様変わりしました。
日本の開発者たちが企業のデジタルトランスフォーメーション（DX）を支え、グローバルに活躍する開発者としてステップアップし続けるには、スキルを身につけることはもちろん、最新の技術動向を常にキャッチアップすることも重要です。
船井総研デジタルが主催した「DIGITAL Decision 2022 “Engineer Night”」では、最先端技術を用いて活躍するスペシャリストが複数登壇。前編では、クラウドアーキテクチャとアジャイル開発について、ゲストスピーカーが語りました。
【登壇者 ※登壇順】
株式会社船井総研デジタル 代表取締役
柳楽 仁史（なぎら ひとし）
株式会社ゼンアーキテクツ
プログラマー兼ソリューションアーキテクト
芝村 達郎（しばむら たつろう）
株式会社エムティーアイ
アジャイルコーチ
雨宮 賢幸（あまみや まさゆき）
クルーズ株式会社 執行役員 CTO 兼
CROOZ SHOPLIST株式会社 技術統括部長
鈴木 優一（すずき ゆういち）
Microsoft米国本社
Senior Software Engineer – Azure Functionsプロダクトチームのシニアソフトエンジニア
牛尾 剛（うしお つよし）
株式会社船井総研デジタル
執行役員ソリューション事業本部
竹下 圭(たけした けい)
目次
これから世界の主役は「開発者」開発者が世界のビジネスを支える時代の到来
登壇者プロフィール
代表取締役
株式会社船井情報システムズ代表取締役常務、株式会社船井総合研究所執行役員社長室長、株式会社船井総研ホールディングス執行役員CSR・IR室担当などを経て、株式会社船井総研コーポレートリレーションズ代表取締役社長に就任。
2022年7月 より新和コンピュータサービス株式会社と統合し、株式会社船井総研デジタルの代表取締役社長となる。
本イベントは、船井総研デジタルの代表取締役 柳楽 仁史氏が、「船井総研デジタルが目指す世界観」を明かす形で幕を開けました。
船井総研グループは、コンサルティング事業を主軸として50年以上の歴史を有する企業です。直近では、昨今のデジタルシフトに注力すべく、新会社の船井総研デジタルを立ち上げました。
船井総研デジタルが掲げる世界観は複数あり、中でも特徴的なのは「これからの主役は開発者である」と明言していることです。
「これまではハードウェアを作る方たちが世界のビジネスを支えていましたが、今後はソフトウェアを開発する方たちがビジネスの中核を担います。また、開発者は、身につけるべきスキルやノウハウをより深掘りしつつ、領域を広げなければなりません」（柳楽氏）
今後はクラウドが主戦場になることが予想されます。クラウド市場は世界的に今も成長を続け、もはや「オンプレミスの代替物」ではありません。
つまり、オンプレミスとクラウドは対になる概念ではなくなりました。開発者はこうした社会の変化にも柔軟に追随する必要があります。
開発者の定義はあいまいに。その意味とは？
世界のビジネスの中核を担う開発者が関わる領域は今後もますます広がっていくでしょう。
「これまでの開発者は『コードを書いていれば良い』と思われがちでした。しかし、DevOpsの時代では、IaC（Infrastructure as Code）*¹やコンテナオーケストレーション、セキュリティ、運用など多岐にわたる領域を、細分化せず一人のエンジニアが担うことになるでしょう」
*¹ IaC（Infrastructure as Code） : サーバーなどのシステムインフラの構築を、コードを用いて行うこと
フロントエンドやバックエンドのように明確に役割が分けられることはなくなり、開発者の定義はあいまいなものとなるでしょう。開発者はこうした変化に追随しなければなりません。また、柳楽氏はエンジニアの働き方も変わっていくと予測します。
最初に柳楽氏はこれからの主戦場が「クラウド」であることを言及しましたが、船井総研デジタルでは、今回のイベントを開催する前に、参加者にクラウドインフラに関するアンケートを実施しました。
「あなたの好きなクラウドはAmazon Web Services（以下、AWS）とMicrosoft Azure（以下、Azure）どちらか？」と問いかけたところ、全体の75％が「AWS」、25％が「Azure」と回答しました。
AWS派が多数を占める中、船井総研デジタルはAzureに注力する姿勢を見せています。
パブリッククラウド市場が成長する中でも、同社はAzureがより成長するだろうと見込んだためです。
本イベントでも、Azureをベースとした開発手法という切り口から、最前線で活躍するスペシャリストをゲストスピーカーとして招きました。
次項からその講演内容をお届けします。
AzureのMVPが語るクラウド活用の勘所。「最新のクラウドアーキテクチャ」には疎結合が最適
登壇者プロフィール
プログラマー兼ソリューションアーキテクト
まずは「Microsoft Azureで実現する最新クラウドアーキテクチャ」と題し、ゼンアーキテクツの芝村 達郎氏（@shibayan）が登壇しました。
芝村氏はプログラマー兼ソリューションアーキテクトとして活躍しておりMicrosoft Azureの分野で「Microsoft MVP」を受賞しています。
芝村氏は、最新のクラウドアーキテクチャの定義を以下のように述べます。
「最新のクラウドアーキテクチャとは、常にアップデート可能で疎結合*²なものを指します。最新のAzureサービスを使えば多くのメリットを得られますが、活用したからといって必ずしも最新のクラウドアーキテクチャを設計できるわけではありません」
Azureに限らず、クラウドアーキテクチャのアップデートはアプリケーションと比較すると非常に速く、設計した瞬間こそ最新のものであっても、どんどん古い技術として扱われます。
芝村氏自身も「翌日にはより優れた新サービスが登場しており、アーキテクチャの一部を置き換えた方が良い」という場面を何度も経験したと語るほどです。
疎結合である点を重視する理由は、最新のサービスを次々と取り入れられるためです。
密結合*³なシステムでは一部のみをアップデートすることが難しくても、疎結合であれば必要な部分のみをアップデートすることが可能になります。
*² 疎結合 : 細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のこと
*³ 密結合 : 細分化された個々のコンポーネント同士が密接に結びついている状態のこと
リソースが必要なときに必要な分使えるクラウド
クラウドを使うメリットは、コンピューティングリソースが必要なときに必要な分だけ使えること、不要になったらリソースを捨てられることです。
クラウドアーキテクチャを構築する際、いかに簡単にスケールアウトできるかにも注目すべきだ、と芝村氏は述べます。
例えば、深夜帯にバッチ処理*⁴を行うサービスを構築すると、並列実行やスケーリングが難しくなります。障害発生時のリカバリも難しく、バッチ処理はクラウドとの相性は良いとは言えません。クラウドサービス上でバッチ処理とよく似た処理を実行する場合は、イベントドリブン*⁵で実現できないか、という点を優先的に考える必要があります。
*⁴ バッチ処理 : ひとまとまりのデータを一括して処理する方式のこと
*⁵ イベントドリブン : コンピュータプログラムの開発および実行方式の一つで、利用者や外部の別のプログラムなどが引き起こす出来事に対応する形で処理を記述あるいは実行する方式のこと
ソフトウェアの信頼性向上に欠かせない2つのポイント
芝村氏は、クラウドサービスの裏側にあるのはコモディティ化されたハードウェアであり、オンプレミス環境と比較すると、ハードウェアの信頼性は低いと指摘します。このハードウェアにおける信頼性の低さをソフトウェア処理によってカバーし、高い信頼性を実現しているのがクラウドです。
つまり、その上で動作するアプリケーションも、ソフトウェアレベルで信頼性を高める工夫が求められます。
信頼性の向上において重要なのが「リトライが容易な設計」と「べき等性*⁶の担保」です。Azureが提供するPaaS（Platform as a Service）*⁷は、メンテナンスによるアップデートなど、意図しないタイミングで再起動を実行します。セキュリティの脆弱性に対処すべく再起動した場合であっても、ソフトウェアの信頼性を保つには、リトライの容易な設計、べき等性の担保が重要です。
*⁶ べき等性 : 「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念
*⁷ PaaS（Platform as a Service） : クラウドにあるプラットフォームを利用するサービス。クラウドサービス側がソフトウェアの実行環境を提供するサービス形態
一見すると難しいように思われがちですが、疎結合のアーキテクチャを設計する段階から組み込んでおくと、2つの条件を同時に満たしやすくなります。
最新のクラウドアーキテクチャが必要となる3つの理由
そもそも、なぜ最新のクラウドアーキテクチャの導入が求められているのでしょうか。
芝村氏は、その理由は大きく分けて3つあると解説します。
1.高いスケーラビリティと可用性を確保できる
クラウドサービスを採用する際、スケーラビリティと可用性*⁸の高さを求める企業は多いでしょう。クラウドサービスでは、CPUリソースを自由に増やしたり減らしたりできるため、サービス自体のスケーラビリティは高いです。
また、データセンターで障害が発生した際にもビジネスを継続できる可用性の高さもメリットです。
スケーラビリティと可用性をさらに高めるには、PaaSの利用とイベントドリブンであることが重要です。バッチ処理では対応が難しい意図しない再起動にも対処できるよう、疎結合である最新のクラウドアーキテクチャが求められます。
*⁸ システムが継続して稼働できる能力のこと
2.サービス運用のコストを削減する
「オンプレミスで利用していたハードウェアの保守費用が高いため、クラウド移行でコストを押さえたい」と考えている企業は多いでしょう。
しかし、長期的な視点で考えるとオンプレミスの方が運用・保守費用は安く信頼性が高いというケースもあります。Azureのコストは割高と言われる場合もありますが、それはクラウドに最適化したアーキテクチャに構築されていないためです。
芝村氏は、「リソースのコストや人的コストを最適化するためには、マネージドサービスを積極的に利用し、Microsoftにおまかせする。このようにクラウド環境へ最適化することが重要です」と補足します。
3.開発環境の整備で価値提供をスピードアップする
開発者の本来の役割は、サービスやアプリケーションを顧客に提供することです。この役割を果たせるように、企業は開発者にとって働きやすい環境を整備しなければなりません。
そのためには、Visual Studio Code（以下、VSCode）やGitHubを組み合わせて開発者体験を高める必要があります。DevOpsとIaC（Infrastructure as Code）などを取り込み、アジリティを高めることも1つの方法でしょう。こうした工夫によって、開発のスピードと価値提供のスピードを同時に上げることが可能です。
全ての要件に対応できるアーキテクチャは存在しない
クラウドは有用である一方、「全ての要望に応えられるクラウドアーキテクチャは存在しない」ことを理解する必要があります。「何のためにAzureが必要なのか？」「何が目的なのか」を正確に把握して、ビジネスサイドが求める要件とズレないように注意することが必要だと芝村氏は強調します。
「エンジニアに任せた際、起こりがちなのが過剰なアーキテクチャの構築です。RDB1つで賄えるのにサービスを追加し、リソースや費用面で失敗してしまう。笑い話のように思われがちですが、実際には現場で起こっています」（芝村氏）
Azureを使う目的は、スピーディにサービスを開発して顧客に届けることです。「カッコいいクラウドアーキテクチャを構築する」ことが目的化しないよう注意が必要だと芝村氏は呼びかけます。
アプリケーション開発をスムーズに進めるには？
アプリケーションは小さく、かつ疎結合に作ることで、開発やテスト、デプロイが非常に行いやすくなります。顧客への提供も早められるでしょう。Azureの場合は「Azure Function」などのFaaS（Function as a Service）を組み合わせることで、アプリケーションを小さく作ることが可能です。
「企業にとって真に必要なものは顧客へのサービス・製品の提供である」と前置きした上で、開発者にとって開発しやすい環境について芝村氏はこう説明します。
「アプリケーションの要件・目的、開発サイクルを考慮した上で、適切な規模でアプリケーションを設計しましょう。アプリケーションを小さく作ることで、利用するAzureのサービスやリソース数は増えます。管理や新たなテスト環境の構築は多少煩雑となるため、自動化が必須です。DevOpsやIaCを開発者が管理できる環境を構築して、スムーズに開発できるよう配慮しましょう」
アプリケーションの開発に役立つデザインパターンはすでに公開されています。こうしたデザインパターンを優先して採用し、組み立てることで目的のアーキテクチャを実現することが可能です。
Azureの場合は「Azureアーキテクチャセンター」で、デザインパターンやMicrosoftが考えたユースケースを日本語で紹介しています。開発者は実証済みのデザインパターンをうまく利用すると良いでしょう。
開発者が恐れる「失敗のリスク」を低減する方法
開発から提供までのスピードを上げるためには、VSCodeとGitHubの連携も欠かせません。AzureポータルからGitHubにサインインすれば、簡単にデプロイのパイプラインが作れるようになっており、VSCodeの拡張からAzureのアカウント管理、リソースの新規作成、デプロイも簡単に行えます。
さらに芝村氏は「開発から運用までに必要となる機能は、VSCodeとGitHubを組み合わせることでフルサポートされています。Azureを使う場合、開発の初期段階からDevOpsを簡単に組み込めます」と補足します。
開発段階でよくある問題は「デプロイしたいけど、失敗のリスクが怖い」というものです。こうした問題を解決するポイントは「自動化の推進」にあります。開発者が嫌うような作業は、DevOpsとIaCを全面的に導入することで自動化することができ、結果的にアジリティも高められます。
そもそも失敗のリスクがある操作を行えないようにしたり、操作時にプラットフォーム側からブロックしたりすることも可能です。「Azure Policy」の機能を使えば、セキュリティに甘いリソースをデプロイさせないように設定できます。
- Azure Policy
- Azure Active Directory
- Azure RBAC
これら3つの機能は、失敗が発生するリスクを防ぐのに有効です。
「最新のクラウドアーキテクチャを実現できるサービスは、Azureに全て用意されているので、安心して活用してください。PaaSやサーバーレスは、正しく使う分には非常に使い勝手の良いサービスです。アーキテクチャセンターでアンチパターンやベストプラクティスを学び、間違った使い方につながるアーキテクチャを組まないようにしましょう」（芝村氏）
DX時代に不可欠な「アジャイル」とは。ビジネスアジリティの向上こそがDXの本質
登壇者プロフィール
アジャイルコーチ
次のセッションでは、「DX時代に求められるアジャイル」と題してエムティーアイの雨宮 賢幸氏が登壇しました。エムティーアイでは2010年からアジャイル開発を導入しており、雨宮氏はスクラムマスター、プロダクトオーナーといった役割を経験し、現在ではアジャイルコーチとして活動しています。
ビジネスアジリティを「企業がビジネス環境、外部環境の変化に素早く対応する能力」と定義する雨宮氏は、この能力を高める2つの視点を明かします。
「DXの本質である『ビジネスアジリティの向上』には2つのアプローチが必要です。1つ目はアジャイル開発以外の領域でどのように開発者が関わるか、という『エンジニアリングからの越境』です。2つ目はアジャイル開発そのものをどうやって進化させるか、という『エンジニアリングにおける進化』です」
もっとも、アジャイル開発でソフトウェア開発のアジリティを向上させたとしても、ビジネス全体を俯瞰するとアジリティの向上をあまり感じられないケースもあると雨宮氏は補足します。
つまり、事業目線ではアジャイル以外にも求められる要素があるということです。
そこで雨宮氏は、次のように問いかけてみることが重要だと説きます。
- 顧客は要求を正しく表現できているか。
- プロダクトを通して提供したい価値はそもそも事前に検証されているのか。
- 課題や目的について、お互いに納得するまで顧客と議論できているか。
この3点です。
「我々の仕事においては、機能作りが目的化してはいけません。あくまでも、ビジネス上の課題解決をゴールに設定する必要があります。ビジネスを成長させるために、アジャイル開発以外にも選択肢がないか考え、プロダクトを実現する目的（Why）やプロダクトによる解決策（What）を改めて明らかにすることが大切です」（雨宮氏）
「プロダクト4階層」でCore、Why、What、Howを明確化
プロダクトを実現する目的（Why）やプロダクトによる解決策（What）を考えるとき、雨宮氏は「プロダクト4階層」というフレームワークを活用しています。
1段階目では、プロダクトの核となるミッションやビジョン、事業戦略を定義します。
2段階目では、その定義に基づいてWhyを突き詰めていきます。
例えば、誰をどのような状態にしたいのかというユーザー側の目的と、なぜ自社がするのかというプロダクト側の目的を設定する、といった具合です。
3段階目のWhatでは、プロダクトによる解決策として、ユーザー体験の設計やビジネスモデルの構築、ロードマップの策定などを行います。
4段階目では、プロダクトの具体的な実現方法（How）を考える必要があり、一般的に開発者が担っている業務はこの領域です。
ここでエンジニアリングのスキルを発揮することが求められますが、目的や要求があいまいなものとなっている場合は、開発者はHowに限らず、WhyやWhatにもチャレンジしなければなりません。
Why・Whatを明確化するための打ち手
WhyやWhatを明らかにするにはどうすればよいでしょうか。
Whyに関しては仮説の検証を繰り返すことが重要だと雨宮氏は語ります。
「初期段階から仮説検証を繰り返す必要があります。例えば、ユーザーとして想定しているターゲットは存在するのか、顧客は本当にお金を払ってでも使ってくれるのか、などです。『ニーズのメカニズム』を使ったインタビューを通じて、こうした仮説の一つひとつを検証して確度を上げることが重要です。また、顧客への価値提供を可視化するために『バリュープロポジションキャンバス（Value Proposition Canvas：VPC）』を用いる場合もあります」
Whatに関しては、顧客体験（UX）の向上や、現状の業務とあるべき姿の業務との乖離といった観点から、どのようなソリューションが必要なのか考えることが重要だと雨宮氏は説きます。そのためには、さまざまな方法論やツールを活用することも有効です。
「As-Isフローで現行体験を分析し、To-Beフローで将来の体験を描くことで、必要となるソリューションが見えてきます。エンドユーザー向けでUXを重視した案件では、『ペルソナ』や『カスタマージャーニーマップ』でWhatを明確化するケースが多いです。ステークホルダーが多く登場し、バックオフィス業務が重視される、法人・官公庁向けの案件では、『ステークホルダーマップ』でステークホルダーとのやりとりを洗い出して可視化したり、『サービスブループリント』でサービスの利用者・提供者の動きを時系列で表して把握したりします」（雨宮氏）
デザイン思考アプローチと“守破離”でビジネスアジリティを向上
Why、Whatの明確化において要となるのが「デザイン思考アプローチ」です。
これは、課題と解決策を発見する際にアイディアを出し合う“発散”と、選択肢を絞り込む“収束”を繰り返すものです。
デザイン思考アプローチは1人で行える活動ではありません。あくまでも、ステークホルダーを巻き込んだワークショップ形式で進めることが重要だといいます。
雨宮氏が所属するエムティーアイでは「Miro」といったオンラインホワイトボードツールを使い、メンバーが一丸となってフロー作りやアイディア出しに取り組んでいます。
「エンジニアがWhyやWhatにもチャレンジする機会・環境があるなら、デザイン思考アプローチには積極的に関わると良いでしょう。WhyやWhatを突き詰めて整理することで、顧客の要求を正しく受け取ることができます。このとき得た情報は、アジャイル開発の際にも役立つはずです」（雨宮氏）
アジャイル開発では、チームを組んで決められたイベントをこなし、プラクティスを適用しているケースが多いと思いますが、こうしたプロセスを経るだけで満足してはいないでしょうか。雨宮氏は「ビジネスアジリティを高めるために、アジャイル開発でもっとできることはないか。ここまで考えたときに出てくるのが“守破離”です」と話します。
守破離とは、日本の芸術・武道の修行における過程を示したものです。“守”は指導者から基本を教わり、ルールを忠実に守る段階です。“破”は他の流派も学びつつ、自分なりのやり方を模索していく段階と言えます。“離”では独創性を発揮し、自分のやり方を生み出していきます。
「アジャイル開発は“守”で満足してはいけません。もっと“破”や“離”に積極的にチャレンジする必要があります。アジャイル開発を発展、進化させるためには、データドリブンな継続的改善が肝になるでしょう」（雨宮氏）
エムティーアイ独自の「Kaizen Culture」を構成する3本の柱
ここからは、アジャイル開発を含むプロジェクトを効果的に進めるためにエムティーアイが行っている取り組みを紹介しましょう。
エムティーアイでは、データの収集・可視化を行い、データドリブンな意思決定を進めることに注力しています。意思決定後は継続的な改善と正しい評価を実施しており、このサイクルを繰り返すことで、「Kaizen Culture」の定着化を図っています。このKaizen Cultureを支えているのが次の3つの取り組みです。
1.Project Maturity Level
「Project Maturity Level」は、プロジェクトの成熟度を評価したものです。複数のカテゴリーが存在し、アーキテクチャやセキュリティ、アジャイル、QA（品質保証）の観点から、アーキテクトやスクラムマスターがチェックリストを用いて評価を実施。定期的に行うことによって、成熟度の変化を把握することができます。
評価終了後は、下図のように表やグラフとして可視化され、前回のスコアからの変化を確認することができます。Project Maturity Levelはプロジェクト単位のみならず、会社全体の成熟度も把握できる画期的な手法と言えます。
2.MTrix
「MTrix」は、プロジェクトの管理に関わるデータを計測する仕組みです。
「社内のユーザーがActive Directoryで認証認可を通し、Azure DevOps Servicesを使える状態を整え、データを入力することでプロジェクトを管理しています。データの具体例としては、例えばBacklogのアイテムやストーリーポイント、作業、作業時間、バグ、リスクなどが該当します。Azure DevOps ServicesのデータをPower BIにエクスポートして、各メトリクスの集計結果とグラフを表示します」（雨宮氏）
Power BIにて「Project Quality」や「Quality per Sprint」、「Productivity」、「Risk」といった観点から、情報をグラフ化・可視化します。バグ情報や1つのストーリーポイントに要した時間、工数の予実などの情報をモニタリングして管理できます。
こうしたツールを組み合わせたMTrixが実現すれば、品質や生産性の改善、リードタイムの短縮を含むバリューストリームの改善にもつながります。
3.Situation Board
「Situation Board」は、ダッシュボード上に表示するサマリーレポートです。
Project Maturity LevelやMTrixのデータを取り込むことで、経営層やマネジメント層が閲覧し、プロジェクトの状態を確認できます。オープンソースプラットフォームの「SonarQube」と連携してソースコードを解析し、結果を表示することもできます。
雨宮氏はエムティーアイにおけるKaizen Cultureについて、次のように紹介します。
「当社のマネジメント層は、現場を訪れてプロジェクトの状況を把握する『Gemba Walk』を定期的に実施しています。データドリブンな意思決定や改善措置の実施を可能にしている当社の『Kaizen Culture』は、ご紹介した3つの柱から成り立っています」
同社では、アジャイル開発の外側「エンジニアリングからの越境」、内側となる「エンジニアリングにおける進化」の両輪を回すことで、品質・生産性の向上と改善し続けるカルチャーを根付かせています。こうした努力こそが、ビジネスアジリティの向上にもつながっていると雨宮氏は最後に締めくくりました。
⇒イベントレポートの後編はこちら
フルリモート勤務OK
★Azureスペシャリストチーム立上げメンバー募集！
2022年7月に発足した船井総研デジタルでは一緒にAzureでシステム開発日本一を目指すメンバーを募集しています。
会社も事業もアジャイルに成長していく環境で、毎日ワクワクしながら新たな仕事に参加したい方を、歓迎しています。