アーカイブ動画

アーキテクチャの定義、プロジェクトにおける設計・実装を解説

株式会社電通国際情報サービス
Xイノベーション本部 エンタープライズプラットフォームセンター
チーフアーキテクト　米久保 剛氏

最初に登壇したのは、2008年にISIDにジョインした、米久保剛氏だ。米久保氏はアーキテクトとして複数の大型SI案件への参画を経験した後、現在は非IT部門の担当者でもノーコードで、社内の各種申請業務を電子化するワークフローシステム「Ci*X Workflow（サイクロス ワークフロー）」の製品開発リーダーとして、アーキテクチャ設計から顧客導入支援まで担っている。

IT人材の不足が指摘されている現状について、米久保氏は経済産業省のDXレポートを紹介。レガシーシステムの保守・運用にIT・ソフトウェア人材が割かれていることが、貴重なIT人材の浪費につながっているという課題を述べた。

システムやアプリケーションは時間の経過と共に生産性が低下していくものだが、理由の一つがコードの重複などの技術的負債だと米久保氏は語っている。

「絶対にNGではありませんが、技術的負債はあくまで前借り、その場しのぎの借金のようなものです。そのため、計画的に返済できなければ次第に改修時のコストが高まり、首がまわらない状態となります」（米久保氏）

その代表的なのがいわゆる巨大な泥団子、スパゲティコードである。そしてこのような状態になってしまっては、どこかに手を加えると違う箇所で問題が生じる可能性が高い。エンジニアからよく聞かれる「怖くて触れることができない」状態である。

避けるために必要なのが「アーキテクチャ」であると、米久保氏は強調する。「後から変更することが容易でない最もハードな部分であり、初期段階から取り組む必要がある」と、アーキテクチャの重要性を説いた。

米久保氏はアーキテクチャの参考例ならびに定義を紹介し、「要素や関係がソフトウェアの構造や形状を示しているが、加えて設計と進化の原則と書かれているのがポイントです」と、補足。さらに、自身が定義するアーキテクチャを次のように述べた。

「ソフトウェアが設計されて現在の形状となっている過程や根拠、あるいは今後変化に適用して設計を進化させていく上での拠り所となるものが、示されているべきだと捉えています」（米久保氏）

このような米久保氏のアーキテクチャの概念、定義を可視化したスライドも紹介された。大きく4つの要素からなることがわかる。

1つ目は機能やビジネス要求など、アーキテクチャにより達成したいものである。2つ目は、アーキテクチャを選定する上での判断材料となった、分析・評価に関する内容や最終的な決定事項。3つ目は、実際にどのようなシステム、ソフトウェアの形状となったのか。4つ目は、これらのアーキテクチャの方針を規約・ガイドライン化したドキュメントである。

「このような要素すべてがアーキテクチャであり、それぞれを適切に形作り、維持していくのがアーキテクトの役割だと思っています」（米久保氏）

続いて、設計について解説が行われた。まずはアーキテクチャの決定要因である「アーキテクチャドライバ」だ。アーキテクチャドライバはスライドのように分類され、「制約」であればさらに「ビジネス制約」「技術制約」と枝分かれしていく。

「品質特性」は特に重要であるため、より詳しく解説された。米久保氏は国の標準規格である「JISX25010」が示す品質特性モデルを紹介した。

ただし品質特性には多くの種類が存在するため、全部を満たす必要はなく、自分たちのシステムにとって重要な要素を識別、選択する必要があるという。選択におけるポイントも重ねて語られた。

さらに、米久保氏は自社のプロダクト「Ci*X Workflow」を例に挙げ、重要視した品質特性とその理由、アーキテクチャ上の決定事項について紹介した。

続いては「機能要求」について、帳票を出力するというユースケースを例に解説が行われた。同ユースケースでは要求を満たすため仕組みの検討が必要であり、場合よっては該当製品を購入することもある。

このような事象はアーキテクチャに大きな影響を与えるために、プロジェクトの後で見つかると手戻りが発生し、大きなコストとなってしまう。そこで、アーキテクトが予め業務領域まで踏み込み、最低でもユースケースの一覧などを把握しておく必要がある、と米久保氏は語った。

こうしてアーキテクチャドライバが定まったら、充足する最適なアーキテクチャの形状を選定する。先のレイヤードアーキテクチャやクリーンアーキテクチャなどであり、複数のアーキテクチャパターンを組み合わせることもある。

選定においてはさまざまな文献や書籍などでカタログ化されているので、それらを参考にすることをお勧めすると、米久保氏は語り、Ci*X Workflowが採用したアーキテクチャ、選定における観点や判断と合わせて紹介した。

実装については、個別に開発して最後につなぎあわせるというアプローチは難しいため、ユースケースの機能を実装しながら、その中で必要な機能を取り揃えていく流れで進める。なお、選定するユースケースはサンプルではなく、リアルなケースを選ぶことがポイントだという。

自社のプロダクトを例に挙げ、どのようなユースケースをどんな理由で選んだのかも合わせて紹介された。

米久保氏は選定したユースケースをソースコードに落とし込んでいく流れ、実装における細かな規約、特に「名前空間」について、ドメイン分割を進める理由を次のように語った。

「大きな機能で分割していくと必要な機能がどこに実装されているかがわかるため、モジュール構造が明確になるという利点があるからです」（米久保氏）

米久保氏は、アーキテクトの仕事は紹介した以外にも多数あるとしながらも、アーキテクト一人が、これらすべての仕事を担うわけではなく「アーキテクトの役割を開発チームで分担していくことが大事」と、語った。

そして開発メンバーがアーキテクト業務を担う意図やメリットを次のように話し、セッションを締めた。

「アーキテクチャ的な考え方である各種原理原則などは、アプリケーション開発においても役立つものです。コード品質やチーム全体のパフォーマンス向上、専門性の広がりといった効果が得られると思うからです。またアーキテクト業務を通じて、未来のアーキテクト候補が誕生するかもしれませんし」（米久保氏）

CleanArchitecture＋軽量DDDによるコード品質の高め方

株式会社電通国際情報サービス
Xイノベーション本部
エンタープライズプラットフォームセンター　山口 翔氏

続いて登壇したのは、2023年にISIDに入社し、現在はCi*X Workflowの開発に携わる山口翔氏だ。山口氏は、一般的な3層型のアーキテクチャの課題から触れた。

「アプリケーションロジックが肥大化、重複している」「ロジックが分散しているため、ユニットテストが大変」などの課題に対する解決策も提示。それを実現するのがクリーンアーキテクチャの導入であると語る。

クリーンアーキテクチャとは、ロバート・C. マーチン氏が提唱したアーキテクチャの一例である。

ただしクリーンアーキテクチャではあくまで概念的なものであり、何か決まった方法で実装することを主張するものではない、と山口氏は補足する。では、この図を通してどのような概念をマーチン氏は主張したかったのか。2つのポイントを述べた。

• ソフトウェアの構造には意識の異なる複数の領域がある
• 領域間は常に外側から内側へと一定方向に依存する

また、クリーンアーキテクチャには広義・狭義があるため、コンテキストの中でどちらの意味で使用されているか注意が必要である。広義においては、ビジネスルールを中心に据え、外側から内側への依存のみを許容するアーキテクチャである。

一方、狭義ではマーチン氏の書籍で紹介されたコンポーネント構成例を参考にしたアーキテクチャになる。

山口氏はクリーンアーキテクチャの実装についてCi*X Workflowを例に挙げ、狭義のクリーンアーキテクチャに倣うかたちで、各種コンポーネントの配置を考えたと述べた。

「Interface Adapters」は、EntitiesやUseCasesに便利なフォーマットから、データベースエンジンやWebフレームワークに便利なフォーマットへの変換を行う。

配置するコンポーネントは、Controller、Repositoryなどであり、Repositoryはデータを取得するためのコンポーネントであり、DAOを経由してDBからデータを取得すると補足した。

UseCasesでの配置については、アプリケーション固有のビジネスルールとして、Entitiesに対して入出力するデータの流れを調整し、ビジネスの目的を達成するものだと、山口氏は語る。

具体的には「商品を登録する」「申請する」といった内容であり、一般的な文脈で語られるユースケースと同じと考えていいと補足した。

コンポーネントの配置ならびに依存関係においては、ControllerからUseCasesを呼び出し、Entitiesのオブジェクトやデータベースのデータを引っ張ってくる。そして処理を行った後、再びControllerに返すという流れとなるが、山口氏は次のように指摘した。

「Use CasesからRepositoryへの依存は内側から外側となり、クリーンアーキテクチャの思想に反してしまいます。そこで解消するために、『依存関係逆転の原則』というテクニックを使います」（山口氏）

山口氏は実際にこのテクニックを使い、再配置したアーキテクチャも紹介した。Use CasesレイヤーにDataAccessorというインターフェースを配置することで、Use CasesレイヤーとInterface Adaptersレイヤーを完全に分けられていることが示されている。

最深層Entitiesは、「Entitiesレイヤーは企業全体の最重要ビジネスルールをカプセル化したものであり、ビジネス上の核となる概念」だと、山口氏は述べた。

ビジネスロジックをUseCasesを中心に記述するとロジックが肥大化してしまい、一般的な3層のアーキテクチャと変わらなくなってしまうため、Entitiesの概念をうまく活用したい。

だが、具体的な実装方法はマーチン氏の書籍では紹介されていない。そこで、概念を補うかたちで導入したのが「軽量DDD」だ。

山口氏は、まずドメイン駆動設計(DDD)について簡単に解説した。DDDとはエリック・エヴァンス氏が提唱した設計手法で、ドメイン知識に焦点をあてた設計手法である。

DDDは戦略的DDDと戦術的DDDに大別でき、戦術的DDDのみを採用することを軽量DDDとしている。
ただし軽量DDDであってもDDDのコアとなる思想、つまりドメイン分析は必ず行うと述べた。

山口氏はDDDの中で利用している実装パターンを紹介した上で、改めてDDDとクリーンアーキテクチャにおけるEntitiesの概念を活かした配置を説明した。現構成の流れやメリットを、山口氏は次のように語った。

「UseCasesレイヤーでは重要なビジネスロジックは含めず、ドメインオブジェクト、データアクセス、外部サービスとの協調に徹するようにします。その結果、ビジネスロジックのユニットテストでは、ドメインオブジェクトやドメインサービスを中心に行えるようになります」（山口氏）

クリーンアーキテクチャに軽量DDDを加えたアーキテクチャにより、一般的な3層アーキテクチャの課題であった、技術要素とビジネスルールの隔離が実現した。
加えてユニットテストにおいてはEntitiesに集中することで、テストが書きやすくなった。またコードのドキュメント性を高めたいという課題も、EntitiesにDDDの概念を取り入れたことで、よりビジネスロジックの表現力を高めることができた。

若手エンジニアの成長を4つの学習ステップで紹介

株式会社電通国際情報サービス
Xイノベーション本部
エンタープライズプラットフォームセンター　佐藤 倫太郎氏

続いて登壇したのは、2019年にISIDに新卒入社した佐藤倫太郎氏だ。自身のキャリアを振り返りながら、若手エンジニアが成長するために自ら編み出した学習ステップを紹介した。

まずは「完全に理解した」という言葉が持つ、逆説的な側面について語った。言葉どおり受け取れば、「対象となる内容を完全に理解した」であるが、エンジニア界隈で言葉どおり受け取られることはほぼないと、佐藤氏は言う。

「エンジニアコミュニティで『完全に理解した』は、入門書を読み終えた程度の低い技術レベルのことを意味しています。背景には能力が不足している人ほど自分の無能さをメタ認知することができず、逆に自己を過大評価する『ダニングクルーガー効果』と呼ばれる認知バイアスがあります」（佐藤氏）

佐藤氏は大学・大学院と情報系の学問を専攻しており、入社後の新人研修で受けたJavaやWebアプリ開発といったテーマにおいては、比較的“できる”人材だった。

周囲から評価され、自信だけが先行して高まっていく環境下においては、「完全に理解した」という「錯覚」に陥っていく。自身がまさにそうであったと、佐藤氏は振り返った。しかし、実際の完全理解は経験を得たはるかに先にあるもの。

 

新人研修が終わり、実務に配属されてからは、ハリボテの自信は一気に崩れ落ち、どん底を味わっていく事となる。タスクの説明や議論で使われる言葉の意味が分からない事は日常茶飯事。なんとかキャッチアップし理解できても、今度はそれをどう実現すべきか分からない。一つ壁を超えると、さらに高い壁が待ち構えている。「次第に自信を喪失、迷走するようになっていきました」と、当時を振り返る。

だが佐藤氏は、そのままどん底状態で終わることはなかった。どうしたら成長できるかを考え、次に紹介する4つのステップで進める学習メソッドを編み出すのである。

【ステップ1】「知識の使い道」を考える

まずは「知識の使い道」を考えることが大事であると佐藤氏。ビジネスにおける知識はものづくりにおける道具選びと同じであり、習得する以前に、得ることで達成したい目的があるはずだと語る。つまり、学習で実現したい目的を明確化することが大事だと述べた。

そして、その目的に向かって学習を進めていくことを、佐藤氏は「目的ドリブン」と表現した。例えば、「新製品を開発するプロジェクトでクリーンアーキテクチャを使うことが決まっており、どこで学べばよいのかと調べているうちに本日のイベントに参加した」といったケースだ。

学習には好奇心軸で進める「好奇心ドリブン」もあると、佐藤氏は言う。両者に優劣があるわけではないが、若手の学習効率の観点で目的ドリブンがいいのではと指摘し、その裏付けとなる理由も語られた。

特に佐藤氏が強調したのは、会社の業務で生じたタスクをそのまま目的に設定する学習方法である。そもそも若手は与えられたタスクと実行できる知識やスキルにギャップがあることが大半のため、逆にそのギャップを埋めることで多くのことが学習できるからだ。

また、不安や焦燥感から、仕事が終わってからのプライベートな時間だけを使って、（業務とは関係の無い）全く新しい技術を身につける事には限界があると指摘。自身の歩みも重ねて、次のように話した。

「特に周りに優秀なエンジニアが多いと漠然と焦ってしまい、使う予定もない技術などあれこれと手をつけてしまいがちです。しかし、結果としてどの技術も身につかないといった事例が結構ありました」（佐藤氏）

【ステップ2】学習の「広さ」と「深さ」を決めていく

目的ドリブンで学習を進めていくことが効率的であることはわかった。だが、この方法には注意すべき二つの「罠」があるという。一つは、目的達成に必要な最低限の学習に終始してしまい、関連知識の学習機会を逃す事。もう一つは、、逆に関連する技術をすべて学ぼうという過大な目標を設定してしまうケースだ。

後者においては一見良さそうにも見えるが、限られた工数のなかで最大限の成果を得るためには、学習範囲を絞ることが重要だと佐藤氏は語る。

そこで佐藤氏は「Must」「Want」の2軸で学習対象を絞っていく手法を考える。対象となるテーマが目的達成のために必要な度数を示すのが横軸のMust。個人的な関心の度合いを示したのが縦軸のWantである。

さらに度合いのボリュームにより「S、A、B、C」と領域を分けた。SやAはしっかりと学習する、Bは微妙ではあるが無視はできない。Cに置かれた内容に関しては学習対象外とすると判断することで、学習の効率化や無駄なコストを抑えることができるというロジックである。

佐藤氏は現在、エンタープライズアプリケーションの開発基盤「aiuola」の開発に携わっている。その中のSAML認証機能のライブラリーバージョンアッププロジェクトを例に挙げて説明した。

SAMLやSSOについては必須とした。一方で今回のタスク（目的）達成のためにはIdPなどは深い理解はいらないだろうと判断。個人的な関心もなかったため、C領域とした。

「書き出して見ることで何をどの程度学習すればよいのか、判断基準になると考えています」（佐藤氏）

【ステップ3】学習を「タスク」化して進めていく

ステップ2で定めた学習対象を着実に学んでいくためには、JiraやNotionといったプロジェクト管理ツールを利用し、個々の学習タスクをチケット管理するのがおすすめだと佐藤氏は言う。

学習を進めていく上で新たに学ぶべき関連対象が、簡単に追加できる。優先順位が管理しやすい。学習済みのステータスが増えていくと、達成感やモチベーションが高まるといった理由からだ。

佐藤氏は学習教材の選定については重視するのは質であり、一般的に評価の高い良書などがおすすめだという。ただし、質を構成する「正確性」「網羅性」「可読性」といった要素は、学習対象や目的により重要度が変わってくるので注意が必要だと語る。

「例えば、SAMLの仕様を理解しようと思い参考にしたのは、主に公式ドキュメントでした。可読性については微妙でしたが、正確性、網羅性が重要であったからです」（佐藤氏）

また、Want要素や好奇心ドリブン的な学習対象の場合は、記憶に定着しづらい面があるため、ハンズオン形式のeラーニング、公式チュートリアル、資格試験などが適していると語った。

【ステップ4】「完全に理解」する

このようなステップで学習を続けることによる「完全理解」は、冒頭のケースと違って決して悪いことではない、と佐藤氏は言う。

逆に自信がないと、どん底状態であったときのように焦燥感に駆られたり、未知の仕事に対して消極的になってしまうからだ。つまり、成長が停滞してしまうのだ。自分にはあくまで謙虚で、未熟なテーマについては学びを継続することが大切となる。

一方、目的を達成したテーマにおいては「完全に理解」強気マインドで、向き合っていくべきだと、佐藤氏は指摘。「完全に理解したので余裕だ」という面持ちで、周囲にアピールすることが重要だと語った。

「このような姿勢で仕事に臨んでいれば、より難しいタスクや別のテーマにもアサインしてもらえる機会が増え、結果として新たな目的が生じます。成長サイクルを回していくことが大事です」（佐藤氏）

【Q＆A】参加者からの質問に登壇者が回答

セッション後はイベントを聴講した参加者からの質問に、登壇者が回答した。

Q．負債の多いシステムを適切な状態に戻していくのに大切なことは？

米久保：巨大な泥団子になってしまった場合は、リプレースしか選択肢はないと思います。改善を進めていく際は、まずは構造、モジュール、最低限などのルールなど、どこから手をつけていくのかを見定めることが必要です。

手を加える際はテストコードを揃えることで、壊してしまうリスクを軽減します。網羅的にユニットテストを揃えるのはコスト面からも難しいため、E2Eテスト自動化ツールなどの活用、リファクタリングを進めていくなどの対策がありますが、地道に少しずつ改善していくことが必要だと思います。

Q．モノリシックアーキテクチャとマイクロサービスアーキテクチャ、どちらが何に適しているか？

米久保：メリットとデメリットを考える必要があります。マイクロサービスアーキテクチャにおけるメリットは、サービス単位でデプロイができること。例えば、障害が起きたときに一部分だけの被害で済むこと、スケーリングする際に必要なだけの能力を高められること、などです。

デメリットは、分散システムならではの複雑性が生まれることです。中でも最たるデメリットは、分散トランザクションです。このようなメリット・デメリットをすべて集めて評価した上で、マイクロサービスの方がモノリシックを上回っていると判断できれば、選択すればよいと思います。

最近ベストプラクティスとされているのが、まずはモジュラーモノリスで始める。そしてどうしても必要になったときに、必要なところをマイクロサービスに移行していくといった手法です。

Q．ドメインサービスを多用しすぎるとビジネスロジックが分散し保守性が下がるといった問題は生じないのか？

山口：ドメインサービスは多用しないというのが基本的な考えです。そのため、ドメインオブジェクトで振る舞いを持たせて不自然だった際に、ドメインサービスを検討します。実際、我々のプロダクトもドメインサービスはそれほど多用していません。

米久保：どれもドメインサービスで実装すると、ロジックが分散する自体が発生します。EntityやValue Objectに振る舞いを持たせようとした際に居心地が悪かったり、複雑性が増すなどの解決策や最後の選択肢として、ドメインサービスは適用すべきだと思います。

Q．「本業が忙しく学習の時間を確保できない」といった悩みはなかったのか？

佐藤：そうした悩みがあったからこそ、目的ドリブンという考えに行き着いたのです。目的が業務タスクであれば、プライベートな時間でなくてもいい。業務時間内で学習が許容されるからです。その上で派生したものを学習していきました。それでも時間が確保できないときは、寝る前に1時間学習タイムを設けるなどの工夫をしていました。

山口：スマホ完結で学習できる方法を考えています。現在は、Udemyなどのアプリなどをスマホに入れて学習しています。

Q．これから取り組みたいエンジニアリング領域など今後の目標は？

米久保：20数年のキャリアを経て、ようやくアーキテクトとして一人前になれたのかなと感じています。今後はより領域を広げるとともに、これまで経験してきたことを後進に伝授していきたいと考えています。

山口：アーキテクチャの考え方を練り込めば、開発者の負担が減り、ビジネスも早くまわります。そうした状況を実現するアーキテクトを目指したいです。

佐藤：アーキテクトとして活躍していくためには、インフラ・ネットワーク・セキュリティといった広範な知識が必要だと考えています。業務と絡めながら学習することで、エンジニアリング能力全体を底上げすることが短期的な目標です。

Q．マイクロサービスアーキテクチャを選択した場合のマスターデータの取り扱いは？

米久保：マスターデータを管理するサービスは1箇所とし、そこに他のマイクロサービスから問い合わせる、というのが基本形だと思います。パフォーマンスなどに問題が生じる場合は、データベースのレプリカを作成する、メモリにキャッシュするなど、いろいろな選択肢があります。メリット・デメリット、トレードオフを分析して判断を行う。それらの分析のもと判断したことを伝えることもアーキテクトの役割だと思っています。

株式会社電通国際情報サービス
https://www.isid.co.jp/

株式会社電通国際情報サービスの採用情報
https://career.isid.co.jp/