スタイル・エッジ技術ブログ

士業集客支援/コンサルティングのスタイル・エッジのエンジニアによるブログです。

【モダン開発 #2】実践!DDD × レイヤードアーキテクチャ in Laravel

はじめに

こんにちは!スタイル・エッジの SHISO です。 弊社ではある業務システムの開発プロジェクトにて、ドメイン駆動設計(DDD)に挑戦しました。
※ 詳しい経緯についてはこちら

今回は、Laravelを利用するという条件の下、DDDとレイヤードアーキテクチャを実現していくにあたり、具体的にどのような設計方針で進めたのか、またどのように実装に落とし込んだのかなど、紹介していきたいと思います。

目次

アーキテクチャ

DIP(依存性逆転の原則)を用いたレイヤードアーキテクチャを採用しました。

レイヤードアーキテクチャ図
レイヤードアーキテクチャ

Laravelフレームワークの一部概念については、意図的にレイヤーを逸脱することを許容しつつも、 原則として、依存関係は上位から下位のみ許可する方針としています。

ディレクトリ構成

※本記事で言及しない部分は省略しています。

app/
├─┬ Application/ (アプリケーション層)
│ ├── Actions/ (ユースケース)
│ └── Dtos/
├─┬  Domains/ (ドメイン層)
│ └─┬ 境界づけれられたコンテキスト/
│   └── 集約/
├─┬ Http/ (UI層)
│ ├── Controllers/
│ ├── Requests/
│ └── Voos/ (ビュー用オブジェクト)
└─┬ Infrastructure/ (インフラ層)
  ├── Models/
  ├── QueryServices/
  └── Repositories/

各層の責務や実装方針、特徴

具体的に各層に持たせた責務と、実装方針をピックアップして紹介します。

Domain層

ビジネスの概念と、ビジネスが置かれた状況に関する情報、およびビジネスルールを表す層です。
主に下記ドメインオブジェクトのパターンで分類し表現しました。

  • エンティティ
  • 値オブジェクト
  • 区分オブジェクト
  • コレクションオブジェクト
  • ドメインサービス
  • 仕様
  • ファクトリ

Domain層は、境界づけられたコンテキストや関連性によってディレクトリを切っていきます。最小単位は集約ごとです。

エンティティ・値オブジェクト生成時のデータ整合性担保のタイミング

エンティティ・値オブジェクトの生成は、基本的に各オブジェクト内のファクトリメソッドで行うようにしました。
新規生成用ファクトリメソッドでは、データ整合性担保のバリデーションを行った上でオブジェクトを生成します。
DBからの再構成用ファクトリメソッドでは、パフォーマンスも考慮し、データの整合性は担保されている前提で、バリデーションは行わず生成しています。

また、ローカルエンティティや値オブジェクトを保持するエンティティ(集約)の生成では、ルートエンティティのcreate処理にて、集約内のデータ整合性担保を行いました。

<?php

// 受付エンティティ
class ReceptionEntity
{
    private function __construct(
        public readonly ?string $id,
        public readonly string $receptionAt, // 受付日時
        public readonly ReceptionType $receptionType, // 受付種別
        public readonly string $name, // 氏名
        public readonly ?Tel $tel, // 電話番号
    ){}

    // 新規生成用ファクトリメソッド
    public static function create(
        string $receptionAt,
        ReceptionType $receptionType,
        string $name,
        ?string $tel,
    ): ReceptionEntity
    {
        // データ整合性担保のバリデーションを行った上でオブジェクトを生成
        validator(
            ['receptionAt' => $receptionAt, 'name' => $name],
            self::rules()
        )->validate();

        // 集約内のデータ整合性担保はルートエンティティのcreate処理で行う
        if ($receptionType === ReceptionType::New && is_null($tel)) {
            throw new \Exception('新規受付の場合、電話番号は必須です。');
        }
        $tel = isset($tel) ? new Tel($tel) : $tel;

        return new self(null, $receptionAt, $receptionType, $name, $tel);
    }

    private static function rules(): array
    {
        return [
            'receptionAt' => ['date'],
            'name'        => ['max:10'],
        ];
    }

    // 再構成用ファクトリメソッド
    public static function reconstruct(
        string $id,
        string $receptionAt,
        ReceptionType $receptionType,
        string $name,
        ?Tel $tel,
    ): ReceptionEntity
    {
        // データは整合性担保されている前提で、バリデーションは行わない
        return new self($id, $receptionAt, $receptionType, $name, $tel);
    }
}

// 受付種別
enum ReceptionType
{
    case New; // 新規
    case Old; // 既存
}

ただ、集約内の情報だけでは生成ができない・データ整合性担保ができない場合は、ファクトリオブジェクトを別途作成し、 そこでエンティティの生成を行っています。

<?php

// 受付エンティティのファクトリ
class ReceptionEntityFactory
{
    // 集約内の情報だけでは生成ができない、またデータ整合性担保ができない場合は、ファクトリオブジェクトで生成
    public function create($name, ...): ReceptionEntity
    {
        // 例)同じ名前の受付が存在する場合、「既存」と判定
        $receptionType = isset($receptionEntityRepository->findByName($name)) ? ReceptionType::Old : ReceptionType::New;

        return ReceptionEntity::create($name, $receptionType, ...);
    }
}

エンティティ識別子はDBのAutoIncrementによる自動採番で生成

本来であれば、識別子はエンティティ生成時に採番した方が一意であることを担保できますが、今回はDBのAutoIncrementより自動採番で遅延生成することにしました。
理由としては、DBMSを今のところ変更する予定がないことと、一番は普段から馴染みのあるORM(Eloquentモデル)を使った時の挙動と近く、実装コストが格段に低くなるためです。
ただ、今後アプリケーション側で識別子を早期生成する場面は考えられるため、識別子の型はintegerではなくstringで定義しました。

バリデーションはLaravelのValidatorファサードを利用

今回開発した業務システムでは、管理する情報数や永続化において担保する必要のあるルールが多く、ドメインオブジェクトの属性ごとにバリデーション処理を記載すると、クラスが肥大化してしまう問題が起きました。

<?php

// before
class UserEntity
{
    private function __construct(
        public readonly ?string $id,
        public readonly string $name,
    ){}

    public static function create(string $name): UserEntity
    {
        // 下記のようなバリデーション処理がたくさんでき、クラスが肥大化
        if (mb_strlen($name) <= 10) {
            throw new \Exception('名前は10文字以下でしか登録できません。');
        }

        return new self(id: null, name: $name);
    }
}

そのため、属性ごとのバリデーションルールについては、LaravelのValidatorファサードを利用し、よりシンプルに記述できるようにしました。

<?php

// after(一部省略)
    public static function create(string $name): UserEntity
    {
        // LaravelのValidatorファサードを利用
        validator(['name' => $name], self::rules())->validate();
        return new self(id: null, name: $name);
    }

    private static function rules(): array
    {
        return ['name' => ['max:10']];
    }

※ 実際は基底クラスなどを作成し、より実装効率を上げる工夫をしています。

Application層

アプリケーションが提供するユースケースやサービスを、ドメインオブジェクトの操作の組み合わせで実現する層です。

パラメータが多い場合はDTOクラスを利用

ユースケースクラスの実行メソッドにて、パラメータが多い場合には、データ受け渡し専用のクラスとしてDTOを利用しました。
これにより、可読性や保守性が向上し、連想配列としてそのまま受け渡す場合に比べ、型により安全性が担保されました。
また、特定の条件ではありますが、ユースケースクラスから別ユースケースクラス呼び出し時にDTOを使い回すことで実装効率が向上する場面もありました。

DTOクラスについては、その他にも開発効率を上げるために様々な工夫をしましたので、 別の連載記事として紹介します。

UserInterface層

アプリケーション外部との入出力操作(データ変換含む)を行う層です。
主にコントローラやフォームリクエスト、ビューテンプレート(Blade)が当てはまります。

ドメインオブジェクトはビュー用のオブジェクトに変換

ビュー(Blade)を作成する際、アプリケーション層から取得したドメインオブジェクトの情報を使用する場面は多々あります。
その際、ドメインオブジェクトをそのままビューへ渡すと、実装効率は上がる反面、下記デメリットも発生します。

  • 予期せぬプロパティ操作や情報更新がされる恐れ
  • ドメインオブジェクト・集約の構造を意識したプロパティアクセスの考慮により実装効率が低下
  • 判定処理やIDとリストの照合処理など、表示に関わるコード以外の実装がビュー上に散見し可読性が低下

そのため、今回はドメインオブジェクトをそのまま渡さず、最小限の記述で必要な情報のみを参照できるように、ビュー用のオブジェクトに変換して渡すようにしました。

Infrastructure層

RDB等の具体的な外部リソース技術を使用し、ドメインオブジェクト(集約)の永続化・取得を行う層です。
主にリポジトリやクエリサービスの実装クラス、Eloquentモデルなどが当てはまります。

リポジトリパターンを採用

ドメインオブジェクトの永続化・取得にはリポジトリパターンを採用しました。
理由としては、抽象リポジトリに依存させ、容易にデータアクセス処理を書けなくすることで、ビジネスロジックがデータアクセス処理に漏れることを抑制するためです。
また、データアクセス処理の隠蔽や下位レイヤのテストが容易になるといった効果も期待できます。

集約内のローカルエンティティの更新処理は2通り

エンティティによっては、ネストしたエンティティ(ローカルエンティティ)を持つものもあります。
例えば、顧客管理システムにおいて、注文エンティティ内に注文アイテムエンティティを包含し、注文詳細情報を階層的に表現する場合、注文アイテムエンティティがローカルエンティティに当たります。

集約内のオブジェクトは、データ整合性担保のためにも、必ず集約単位で更新する必要があるので、ローカルエンティティはルートエンティティと同じタイミングで永続化処理が実行されます。
ただ、ルートエンティティとローカルエンティティは別テーブルで管理されることが多いため、ローカルエンティティの更新方法として、下記2通りの方法が候補に挙がります。

  • delete/insert
  • 一意な識別子による差分更新

差分更新の場合、selectで存在確認してからupdateかinsert、何もしないなど、いくつか分岐処理が必要になり、実装が複雑になるため、基本的にはdelete/insertにて実装しました。

<?php

// delete/insert  
class Repository
{
    public function updateOrCreate(RootEntity $rootEntity): void
    {
        $rootEntityEloquentModel = RootEntityEloquentModel::updateOrCreate(
            ['id' => $rootEntity->id, ...],
        );

        // ローカルエンティティの永続化
        $rootEntityEloquentModel->localEntityEloquentModel()->delete();
        LocalEntityEloquentModel::create(['root_entity_id' => $rootEntityEloquentModel->id, ...]);
    }
}

delete/insertでも集約内のオブジェクトは必ず集約単位で更新されるため、証跡データが必要な場合、ルートエンティティから取得できます。
しかし、厳密にローカルエンティティごとに更新日時や更新者など証跡データが必要な場合では、差分更新にて実装しました。

<?php

// 一意な識別子による差分更新  
class Repository
{
    public function updateOrCreate(RootEntity $rootEntity): void
    {
        $rootEntityEloquentModel = RootEntityEloquentModel::updateOrCreate(
            ['id' => $rootEntity->id, ...],
        );

        // ローカルエンティティの永続化
        if (isset($rootEntity->localEntity)) {
            // updateOrCreateメソッド内で更にデータが存在するかの分岐処理が走る
            LocalEntityEloquentModel::updateOrCreate([
                'id'             => $rootEntity->localEntity->id,
                'root_entity_id' => $rootEntityEloquentModel->id,
                ...]);
        } else {
            $rootEntityEloquentModel->localEntityEloquentModel()->delete();
        }
    }
}

複雑なデータアクセス処理にはクエリサービスを利用

リポジトリパターンを採用することでメンテナンス性は良くなりましたが、複数集約を取得したり、複雑な条件の検索処理などはパフォーマンスが悪化しました。
そのため、集約を跨ぐ取得や検索処理など特定の処理については、CQRSパターンを一部参考にし、リポジトリとは別にクエリサービス*1というクラスに切り出しました。
ただこのクエリサービスの利用については、ビジネスロジックの重複や設計指針の崩壊などが発生し得るため、本当に利用しなければならない理由がある時のみ利用しています。

Eloquentモデルはデータベース操作でのみ利用

基本的にEloquentモデルとドメインオブジェクト(主にエンティティ)は1対1になるため、設計当初はmpywさんの記事を参考にしつつ、Eloquentモデルでドメインオブジェクトを表現しようとしていました。
しかし、Eloquentモデルは各属性ごとに更新可能であるため、属性間のデータ整合性を担保することが難しかったり、またドメインロジックやビュー用処理、データベース設定などがEloquentモデル内に混在してわかりづらい、かつファットになりやすかったため、今回Eloquentモデルはリポジトリ・クエリサービスからのデータベース操作でのみ利用しました。

その他

バリデーション実装方針

各層の責務範囲でバリデーションを行う

バリデーションは、UI層・アプリケーション層・ドメイン層の各層にて、それぞれの責務範囲内で行いました。

まずUI層のフォームリクエストでは、必須チェックや入力形式チェックなど、アプリケーション層に渡すための最低限のバリデーションのみを行います。
次にアプリケーション層では、ユースケースの実現に必要なドメインオブジェクトを利用しバリデーションを行います。
(あくまでビジネスロジックドメインオブジェクトに記載し、アプリケーション層はそれらを使って返ってきた結果をみて例外を投げています。)
最後にドメイン層にて、エンティティや値オブジェクト生成のためのデータ整合性担保のバリデーションを行います。

これにより、ドメイン層以外にドメインルールが漏れるなどの逆方向への依存や、コードが重複することなどの事象を回避することができました。

バリデーションエラーは可能な限りまとめて返す

エラー内容はバリデーションに引っかかる度に1つずつ返すより、可能な限りまとめて返した方が、一般的にはユーザー体験が向上します。
アプリケーション層やドメイン層も、Laravelのフォームリクエストに倣って、一通りのバリデーションを実行した後にエラーをまとめて返却するように実装しました。

終わりに

今回は、連載2回目ということで、Laravelを利用するという条件の下、DDDとレイヤードアーキテクチャを実現していくにあたり、具体的にどのように落とし込んでいったのか、特に悩んだ部分についてまとめました。

DDDはいざ実践するとなると、大枠は各文献を参考にしながら進めることはできましたが、より詳細な部分については、自分たちで情報収集・試行錯誤・取捨選択して進める必要があり、とても苦労しました。
そのため、ぜひ一例として、これからDDDを始める方や今まさに実践している方の参考になれば幸いです。


このようにスタイル・エッジでは、DDDなどのモダンな開発にも積極的にチャレンジできる環境です!
ご興味ある方はぜひ採用サイト ↓をぜひご覧ください ♪
recruit.styleedge.co.jp

次回は「【モダン開発 #3】TDDに挑戦してみた!」を投稿します。お楽しみに~

『GitLab に学ぶ 世界最先端のリモート組織』に学ぶ、リモートチームにおける心理的安全性の醸成

はじめに

こんにちは、しおです。
前回は MySQL のコードリーディングしてみる、という記事を書きました。 techblog.styleedge.co.jp

今回はコードリーディングの続きではなく、最近読んだ面白い本の一部を紹介してみようと思います。

何の本か

今回読んだのは、『GitLab に学ぶ 世界最先端のリモート組織』という本です。 www.shoeisha.co.jp

世界 67 カ国以上に 2,000 名以上の従業員を抱える GitLab 社が、リモートワークにおける方法論やカルチャーの醸成方法をまとめて無料で公開している GitLab Handbook を読み解いた本です。
GitLab Handbook は全部で4,000ページ弱ほどあり、GitLab 社で業務を行ううえで必要な知識がほぼすべて網羅されているとのこと。例えば、コミュニケーション方法から報酬の決定方法や評価方法までもがドキュメントにまとめられているようです。

『GitLab に学ぶ 世界最先端のリモート組織』の著者は GitLab の社員ということではないようですが、この GitLab Handbook を翻訳して読み解き実践することで、自社をオフィスを持たない完全フルリモート企業へと転換させました。そこでの経験を踏まえて GitLab Handbook のエッセンスを抽出したのが本書です。

本書には『心理的安全性の醸成』という独立した章が存在します。
今期の個人目標として『自分が所属するチームの心理的安全性を高める』という目標を立てていたこともあり、今回はこちらの章を中心に心理的安全性に関連した記述を拾い読みしてみました。

GitLab についておさらい

GitLab は、2011年にウクライナにてディミトリー・ザポロゼツ氏がスタートさせたプロジェクトです。

よく似たサービスに GitHub というものがありますが、GitHub と GitLab は思想が異なります。

GitHubSocial Coding を重視しており(4年前までプライベートリポジトリの作成が有料だったことからもその点がうかがえます)、Social Coding という言葉からも分かるように、GitHub にはエンジニアコミュニティのレベルを高めるという目的があり、特にOSS開発の領域で活発に利用されています。

GitLab は プロジェクト管理 を中心とした考え方で、データの秘匿性を重視するなど GitHub とは異なる思想の上で運用されており、プライベートリポジトリを無料で作成したりオンプレのサーバーを使って自社専用の環境を構築したりといったことが初期の段階から出来ました。

techblog.styleedge.co.jp なお、過去の記事にもあるように、スタイル・エッジ システム事業部では GitLab を活用してプログラムのバージョン管理を行っています。

心理的安全性について

心理的安全性とは、エイミー・C・エドモンドソン氏が定義した言葉で、「チームにおいて、『他のメンバーが自分の発言を拒絶したり、罰をあたえたりしない』という確信を持っている状態」であり、「信頼と尊敬が混ざり合う心理的に安全な文化」を指します。

心理的安全性が高い = ヌルい環境 ではない

心理的安全性の高いチームと聞くと、単純に「メンバーの仲が良くてどんなことでも言いあえるチーム」を(自分含め)想像してしまいがちです。
なかには、そこからさらに「なれ合い」「モチベーションが低い」「現状維持」といったマイナスなワードを連想してしまう方もいらっしゃるかもしれません。

前述のような状態は、下図において「快適ゾーン にいる」と言えます。しかし、チームや事業としての高い目標や基準と心理的安全性の高さは両立が可能です。

私が現在所属しているチームは、心理的安全性が高いと評価してくださる方が多いです。また私自身もそう思っており、今後も心理的安全性が高い状態をキープしたいと考えているのですが、ここで更に上を目指そうと思ったときに目標になるのが、学習ゾーン です。

メンバーそれぞれが学習ゾーンにいるチームは、気持ちよくチームとして団結して困難な仕事を成し遂げられると『恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす』にて述べられています。

これ以上は記事の本旨から外れてしまうので詳しく紹介しませんが、心理的安全性については下記の本にて詳しく説明されているので、興味がある方はぜひ読んでみてください。

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらすeijipress.co.jp

GitLab 社における心理的安全性の醸成方法

さてようやく本題です。
GitLab 社において大事にされている『職場で心理的安全性を確立する 7 つの考え』を紹介したあとに、心理的安全性を醸成するために行われている具体的な手法を2つほどピックアップして紹介していきます。

職場で心理的安全性を確立する 7 つの考え

本書で紹介されている、心理的安全性を生み出すために GitLab 社において大事にされている考えは、下記の通りです。

  1. 黄金律を破る
  2. 好奇心を歓迎する
  3. 健全なコンフリクトを推進する
  4. 従業員に発言権を与える
  5. 信頼を獲得し、拡大する
  6. 効率だけでなく有効性を促進する
  7. 創造性について別の考え方をする

ここでそれぞれの考えについて詳細に解説することはしませんが、ピックアップして解説していきます。

黄金律を破る

アメリカでは、『自分がしてほしい行為を、他人に対して実施せよ』という黄金律があります。
心理的安全性を高めるには、『他人がしてほしいと思う行為を、他人に対して実施せよ』という行動規範が大切とされています。

blog.jostle.me

上記の GitLab Handbook からリンクされている心理的安全性を高めるための方法を紹介する記事によれば、「”自分が” こうしてほしいと思うから」ではなく、チームメンバーに対してどのようなコミュニケーションのスタイル、フィードバックの種類を好むのか希望を探り、その通りに実施するということです。ここでは自分視点ではなく、相手にどうしてほしいのかを主軸に考えています。
他人が何を望んでいるのか、どのように扱われることを望んでいるのか、ということを事前に知っておき、自分基準に依らないようなスタンスを取ることで心理的安全性に貢献をもたらします。

健全なコンフリクトを推進する

チームの雰囲気を悪くしないために衝突を回避するのではなく、必要なコンフリクト(衝突)は積極的にするべき、という考えです。
ただしその際には「コト」と「人」は分けるよう気を付け、決して人格を否定することの無いように努めます。

「同意しない、コミットする、同意しない」

レビュワー・レビュイー双方に、「意見や成果物を批判されても、人格まで批判しているわけではない」という認識を持つことが大事です。
意見や成果物は客観的な視点で公正に判断されるべきであり、それは個人の人格とは別の次元で議論しなくてはなりません。 handbook.gitlab.com

そのために、GitLab では最終的に DRI (Directoly Responsible Individuals) が結論を出します。 各自が意見を述べたうえで DRI が判断し、ひとたび結論が決まればメンバー全員がその決定を尊重してコミットすることが求められます。 handbook.gitlab.com

心理的安全性を維持しながらフィードバックする

パフォーマンスを改善するためにフィードバックをするのですが、ネガティブなフィードバックをすると人間はストレスを感じてしまいます。
そこで、GitLab ではフィードバックの手法として SBI モデルを使用しています。 handbook.gitlab.com

SBI モデルでは、簡単に言うと「状況(Situation)」「振る舞い(Befavior)」「影響(Impact)」を明確にしてフィードバックをします。
例えば「昨日の進捗定例会議でメンバーが発表している最中に(Situation)、部長が腕を組んで出席者を威圧していた(Behavior)。この行動が会議の参加者に不要なプレッシャーをかけ、自由な意見や提案を出しにくくさせる(Impact)可能性があるのでやめてほしい。」といった具合です。
SBI を明確に特定することで、 客観的な事実に基づくフィードバックになります。

おわりに

ということで、『GitLab に学ぶ 世界最先端のリモート組織』という本を読んで勉強になったことをつらつらと書いてみました。
GitLab 社はフルリモートの職場ということで、弊社に完全に適用できるものばかりではありませんが、SBI モデルを用いたフィードバックや黄金律を破るという心構え等、個人単位でも実施できそうな取り組みはぜひ積極的に取り入れてみたいと考えています。
本家の GitLab Handbook にも俄然興味が湧いてきたので、『GitLab に学ぶ 世界最先端のリモート組織』をお供にしてのんびり読み進めていきたいと思います!


スタイル・エッジでは、一緒に働く仲間を絶賛大募集しています。 もし興味を持っていただけましたら、以下の採用サイトも一度覗いてみてください! recruit.styleedge.co.jp

【モダン開発 #1】「ドメインモデリング」こんな感じでやりました

はじめに

こんにちは!スタイル・エッジの SHISO です。
弊社ではある業務システムの開発プロジェクトにて、ドメイン駆動設計(DDD)に挑戦しました。
※ 詳しい経緯についてはこちら

今回は、DDDの中でも肝になってくる「ドメインモデリング」について、実際にプロジェクトで取り組んだ内容を紹介していきたいと思います。

ドメインモデリングとは

簡単に言うと「ドメインモデルを作成すること」ですが、先人達の著書*1より整理すると、下記のような定義であると言えます。

  • ソフトウェアを適用する領域から、問題解決のためにソフトウェアに落とし込む要素を取捨選択すること
  • システムにとって何の情報が必要かについて、事象あるいは概念を抽象化すること

実際に行ったドメインモデリングの流れ

大まかには下記の流れでドメインモデリングを実施していきました。

  1. 業務フロー等から「ヒト・モノ・コト」に該当するモデルをとにかく抽出
  2. システムが対象とする業務についての書籍や記事、または顧客ヒアリング等で業務知識を深めモデルを抽出
  3. 境界づけられたコンテキストを分割
  4. エンティティ、値オブジェクト、区分オブジェクト、集約を識別
  5. 仕様、ドメインサービス、ファクトリを識別
  6. ルールや属性値を元にモデルをさらに識別

あくまで大まかな流れなので、実際には行ったり来たりしてモデルを洗練することで、実用的な形へと蒸留していきました。

実際に作成したドメインモデル図の例

とにかく抽出する段階ではざっくりとしたモデル図で行いますが、最終的には主に下記のようなフォーマットでドメインモデル図を作成しました。

ドメインモデル図のフォーマット
ドメインモデル図のフォーマット
具体例として、実際に上記フォーマットでモデリングした図は以下の通りです。
※ 内容はあくまで例です。
ドメインモデル図のサンプル
ドメインモデル図のサンプル

ドメインモデル図を見れば、開発者がシステム全体の内容を把握できるようにしつつ、さらにはシステム開発のコア部分のレビューや認識合わせがこの図1つで集約できるように、戦術的設計パターンや属性ごとの型ルールまで記載するようにしました。
この方式により、開発着手前までに大方のフィードバックが可能になったため、開発着手からデプロイの中で大きな手戻りが起きることは少なくなりました。

ドメインモデリング実践で学んだこと

基本的には先人の方々の情報を参考にしつつ、ドメインモデリングに取り組みました。
ただ、実際にやってみると、参考となる情報がないことやうまくいかないこと、改めて強く意識したことなどがありましたので、いくつか紹介します。

モデリングはとにかく「ヒト・モノ・コト」に注目

業務の関心事を、ヒト/モノ/コトに3つに分類する。
 ・ヒト:個人、企業、担当者など
 ・モノ:商品、サービス、店舗、場所、権利、義務など
 ・コト:予約、注文、支払、出荷、キャンセルなど

コトに注目すると全体の関係を整理しやすい
 ・コトはヒトとモノとの関係として出現する(だれの何についての行動か)
 ・コトは時間軸に沿って明確な前後関係を持つ

コトは業務ルールの宝庫

引用元:現場で役立つシステム設計の原則

「ヒト・モノ・コト」に注目すると、大半のドメインの概念を抽象化できます(洗練されているかは別)。
また「コト」に関しては、積極的に抽象化する必要がある暗黙的な概念(ルール/仕様/イベントなど)が見つけやすくなります。

モデリングにはコード設計の観点が必要

優秀なドメインモデラは、経理担当者と一緒にホワイトボードを使うこともできれば、プログラマと一緒にJavaを書くこともできる。概念が実装から切り離せない理由の一端には、実装上の問題を考慮せずには役にたつ概念モデルを構築することができない、ということもある。しかし、概念と実装を一緒に考える一番の理由は、ドメインモデルの最大の価値がユビキタス言語を提供し、ドメインエキスパートと技術者を結びつけることにある、ということだ。

引用元:エリック・エヴァンスのドメイン駆動設計
ドメインモデリングしてソフトウェアに落とし込む時には、どのモデルオブジェクトが何をするのものなのかに注意を払う必要がある。つまり、オブジェクトの振る舞いを設計するということだ。振る舞いに適切な名前をつけて、ユビキタス言語の本質が伝わるものにしておきたい。

引用元:実践ドメイン駆動設計

上記にもあるとおり、モデリングにはコード設計の観点も必要です。
実際にモデリングした際は、確かに思考の半分は「オブジェクトを部品として利用できそうか」「単一責務になっているか」「組み合わせたときにユースケースの実装ができそうか」など実装イメージやコード設計になっていました。

効果が薄い箇所はモデリングしない

DDDはメリットも大きいですが、デメリットとして、ドメインモデリングや実装のコストが膨らんでしまうことが挙げられます。

業務システムには、そこまで重要な業務ルールが絡まないドメインオブジェクトや、データのみ管理したいドメインオブジェクトなどが中にはあります。
そのような場合、細かくモデリングして実装すると、デメリットがメリットを上回ってしまうこともあります。

DDDを駆動している原則
・コアドメインに集中すること。
ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること。
・明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること。

引用元:エリック・エヴァンスのドメイン駆動設計

そのため、DDDの原則にもある通り、コアドメインではなく、DDDのメリットが薄い範囲に関しては、モデリングしないという選択肢も必要です。

コードに落とし込むまでモデリングは終わらない

もちろんデプロイした後も、常にドメインモデルは進化させていくことは大前提です。

ですが、開発フローを一部分切り取ってみてみると、今ある業務知識からドメインモデリングを終えたら、あとは実装だけと思い込みがちです。(私だけかもですが...)
しかし、実装に入った後に、重要なことや追加モデリングの必要性に気づくことは、やはり多々あります。

重大な発見はいつでも、設計や実装をするために努力する際に現れる

高度なスキルを持つ技術者が設計し、それほどスキルのない労働者が製品を組み立てる。このメタファは数多くのプロジェクトを台無しにしてきたが、理由は1つ、単純なことである。
すなわち、ソフトウェア開発は、すべてが設計なのだ。
分析、モデリング、設計、プログラミングのように責任を過剰に分離することは、モデル駆動設計の妨げになる。

引用元:エリック・エヴァンスのドメイン駆動設計

エヴァンスさんは「ソフトウェア開発はすべてが設計」と提唱しています。
開発に入ると、モデリングに戻る必要が出てきても、億劫さが邪魔をすることがたまにありますが、コードに落とし込むまでモデリングは終わっていないという意識を持つことは大事です。

本題とはずれますが、ドメインモデリングを行わなかった今までの開発フローの場合、実装に着手してから、仕様詰めやヒアリングの深掘りが必要な箇所に気づくことが多々ありました。 しかし、ドメインモデリングを行うようになったことで、実装前に限りなく細部まで設計が行え、手戻りが少なくなった、ということはとても実感しています。

序盤のドメインモデルは跡形もなく消える

まだ実践経験が少ないからかもしれませんが、序盤の方でモデリングした内容は、業務知識をアップデートしていく中で、大幅に変更されることが多いです。
これがエヴァンスさんの言うブレイクスルーなのかは判断が難しいですが、ドメインモデルはどんどん進化していくという心構え進化させる勇気(一度作ったものを壊す勇気)は必要です。

集約は可能な限り最小限に

・集約を大きくするメリット
 - 整合性を確保する実装とテストが簡単になる
・集約を大きくするデメリット
 - 処理するデータ量が増える
 - 排他制御の範囲が大きくなる

引用元:ドメイン駆動設計 サンプルコード&FAQ

モデル同士の整合性担保を考えていくと、気がつけば集約が大きくなっていることがあります。
集約が大きいと、上記以外にも「親エンティティクラスがとにかく肥大化する」などのデメリットがあるので、強い整合性担保の必要性がなければ、ドメインサービスに切り出したり、結果整合性を使うなどして、集約は可能な限り最小限にすることが推奨されます。

値オブジェクトは共通化の観点でもモデリングできる

エンティティや仕様オブジェクトなどは、オブジェクト間で振る舞いや属性などが同じでも、本質的には違う(責務が違う)ことが多いので、共通化という観点でモデリングすると、痛い目を見ます。
ただ、値オブジェクトに関しては、不変かつ交換可能で、さらにプリミティブな値の延長のようなオブジェクトであるため、同じコンテキスト内であればオブジェクト間で共通目的で利用されることが多く、共通化観点からも見つけることが可能です。

終わりに

今回は、連載1回目ということで、ドメインモデリングで具体的に行ったことや、実践を通して学んだことについてまとめました。
ドメインモデリングは型のようなものがあまりなく、方針から自身で試行錯誤する場面が多かったので、ぜひ一例として、これからDDDを始める方や今まさに実践している方の参考になれば幸いです。
ただ、私自身まだまだドメイン駆動設計に関しては経験が浅いため、今後も業務や実践で得た知見は引き続きアウトプットしていきたいと思います。

このようにスタイル・エッジでは、DDDなどのモダンな開発にも積極的にチャレンジできる環境です!
ご興味ある方はぜひ採用サイト ↓をぜひご覧ください ♪
recruit.styleedge.co.jp

次回は「【モダン開発 #2】DDDやレイヤードアーキテクチャを実現するために」を投稿します。お楽しみに~

【連載始めます】DDD・TDDに挑戦してみた!

はじめに

こんにちは!スタイル・エッジの SHISO です。
この度弊社では、数年間運用してきた業務システムをフルリプレイスする機会があり、 その中でドメイン駆動設計(DDD)やテスト駆動開発(TDD)などを取り入れたモダンな開発に挑戦してみました。

今回はこのような挑戦に至った経緯に触れつつ、
若手&モダン開発未経験メンバー中心の体制で進行するにあたり実際に行った取り組みや工夫した点を、 連載形式でご紹介していこうと思います。

経緯

今回フルリプレイスすることになった業務システムは、ありがたいことに約8年間クライアントの皆様にご利用いただいておりました。
快適にご利用いただけるよう、日々運用保守・機能開発を行なってきたのですが、だんだんと開発スピードが出せなくなってきている事実がありました。

主な原因として下記が挙げられます。

  • ビジネスロジックの分散・重複
  • 業務知識、システム仕様の属人化

このような状況が、今後の機能拡充においてボトルネックとなることが明らかだったため、DDDTDD、依存関係や責務を明確にしたレイヤードアーキテクチャなどを取り入れた、よりモダンな開発手法でフルリプレイスすることになりました。

連載予定

投稿日 タイトル
9/27 【モダン開発 #1】「ドメインモデリング」こんな感じでやりました
11/17 【モダン開発 #2】実践!DDD × レイヤードアーキテクチャ in Laravel
1/29 【番外編】気が利くDTO!データオブジェクトライブラリ「Laravel-data」を導入してみた
2/29 【モダン開発 #3】TDDに挑戦してみた!
3/28 【モダン開発 #4】モダン開発で工夫した8個のこと

※内容や更新予定日は、追加・変更の可能性があります。

続けて「【モダン開発 #1】「ドメインモデリング」こんな感じでやりました」も投稿します。お楽しみに~

デザイナーからディレクターにジョブチェンジした時の話

こんにちは!システム事業部のKOです。
スタイル・エッジに入社してはや6年目となります。
普段はディレクターとして案件の進行管理やクライアントワークと
幅広い方々と関わりながら日々仕事をしています。

そんな私ですが、元々はデザイナーとして中途入社しておりまして、
今回ディレクターにジョブチェンジした時の話を記事に起こしてみることにしてみました。
職種を変えた上で感じたことをお伝えできればと思います。

私がディレクターになったきっかけ

前提として…決してデザインが嫌いになったからとかではございません!笑
自分自身のキャリアを考えた時に「より企画段階から関わりたい」「デザイン以外にもクライアントと関われる仕事がしたい」との想いが強くなり、上司に伝えた所『ディレクターやってみる?』とお話を頂いたことがきっかけでした。

デザイナーとして長年生きてきたので、職種を変えることに対しては不安を感じることもありましたが、自身の今後のキャリアを考えた上でチャレンジしてみようと決意しました。

そこからまずはアシスタントディレクターに近い形で案件に入っていき、徐々にシフトチェンジしていく中で、本格的にディレクターとしてのキャリアを歩み始めました。

ディレクターとして働くようになってからの話

長年デザイナーとして制作に携わってきた経験もあるので、制作の流れや過程もわかることからうまく立ち回れると思っていた自分がいましたが、そんな甘い話ではありませんでした…

例を挙げますと、

  • スケジュール管理
  • テキストコミュニケーション

など

どれもデザイナー時代に経験していたことでしたが、
ディレクターとして対応する場合は、案件全体を考慮した視点で物事を考えないと上手く立ち回れずに、当初は思い悩む日々が続きました…

ただ、悩みと同時に職種の違いによる新しい世界を感じることで、やりがいにつながりなんとか乗り切れたと思っています。 その結果として、デザイナーからディレクターへのジョブチェンジを成功することができたのかなと今は感じています。

デザイナーだったからこそ活かせているスキル

デザイナーとして培ったスキルはディレクターになっても財産として根強く活きています。
そんな中でも特に活かせていると感じるスキルをご紹介します。

①デザインの良し悪しを言語化できること

デザインに対しての良し悪しを判断できること、それを上手く伝えること。
フィードバックをしっかり言語化したもので返せる所はデザイナーとしての経験が大いに活きている部分だと感じています。

「なんかいいね!(よくわからんけど)」
「なんか気に入らない!もう少しなんとかして」
という抽象的な表現でのフィードバックではなく、

「〇〇だから、このデザインはしっかり考えられれていいね」
「〇〇だから、ここは〇〇のような考え方を取り入れて調整してほしい」

など「〜だから」とデザインの意図を汲み取り理解した上での、フィードバックを行える事が強みだと思います。
そうしたことがデザイナー側としても納得感の持てるフィードバックへと繋がるものになるのではと思っています。

②クオリティ管理

依頼者が求めている意図を汲み取り、デザイナーの視点で紐解きワイヤーフレームに起こし、制作チームに連携して作り上げていく。
クオリティを見れるという所も成果物の品質を担保できる一因だと思います。

工数感の把握

依頼に対してどのぐらいの日数、時間が必要となるかを作業者レベルで判断できる所はデザイナーでの経験が生きている場面だと感じています。
デザイナーとしての観点があることで、クライアントからの依頼に対しその場で概算を提示できることや、 自分の場合はデザイン+コーディングを行っていた経験があるので、工数算出の部分で認識のギャップを減らせていると実感しています。

④資料の作成・提案

デザイナースキルを最も活かせる場だと思います。
クライアントや社内に見せるものとして、完成したものをイメージできるラフなど、
見栄えを考慮した構成案を作れることは大きな強みだと思います。

ディレクターとして大事にしていること4選

個人的な考えの部分もありますが、ディレクターとして特に心掛けていることを4つ紹介します。

テキストコミュニケーション

特にディレクターになってから一番苦戦した所でもあり、一番重要なことだとも感じています。
相手からうまく情報を引き出すテクニックや確認を早く取るための文面など、
キャッチボールを極力少なく、簡潔な文章で伝えるということは常に意識して取り組んでいます。

案件の責任を持つこと

「責任」についてはデザイナー時代ももちろんありましたが、
ディレクターになってからはより感じる機会が多くなり、意識付けられました。
案件においてクライアントの窓口かつ社内の最終確認者という立場上、
自身の勘違いやミスによっては制作メンバーにも影響を及ぼしたり、 確認時の見落とし一つでも自社の評価に直結する場合もあるので、 常に制作部署の代表者として責任感を持って対応するように心がけています。

適切な方向に導くために決断する

依頼内容によっては状況に応じて断る勇気も必要なことだと思っています。
ただ断るのではなく相手の意見を尊重した上で、 より適切な代替案を提示し、正しい方向性へと導くことが重要だと感じています。
目的に対して何を優先とするか、その決断を下すこともディレクターの大きな役割だと思います。
自身だけでなく、チームにも影響を与えることを常に考えるようにしています。

リスペクトをすること

これはディレクターという観点ではなく、
自分の仕事をする上での考え方にはなりますが、
誰に対してもリスペクトの心を持って接することを大事にしています。
「相手の意見を聞く、相手を尊重する、相手のことを想う」
自分もそう思われる人でありたいのでこの気持ちを忘れず仕事に取り組んでいます。

最後に

今回私のジョブチェンジを行った話をさせていただきましたが、
スタイル・エッジはとても柔軟性のある働き方ができると私は思っています。

一例として「留学制度」というものがございます。

・フロントエンドエンジニアだけどデザインをやってみたい
・デザイナーだけどコーディングをやってみたい

と興味関心がある場合は、実際に留学生という形で希望職種を経験できる制度です。
自身のキャリアパスを広げる施策として、留学制度を取り入れています。

今後はより「ディレクターだけどデザインを一部担う」など、
各々が培ってきた得意なスキルを発揮できる場を作っていけるようなビジョンを模索しているので、より柔軟性に富んだ働き方ができるのではないかと思います。

スタイル・エッジでは一緒に働く仲間を募集しております。
興味をお持ちいただけましたら是非とも下記を覗いてみてください!

recruit.styleedge.co.jp

AppSheet で社内向けツールを作った話

はじめに

こんにちは。スタイル・エッジの YH です。

前回のブログ執筆からおよそ1年半が経過し、新卒で入社したてホヤホヤだった私もついに3年目…😨
今まで多様な業務を経験させていただきましたが、今回はノーコード開発に携わった際に利用した「 AppSheet 」というツールをご紹介します。

※本記事では2023年7月現在の情報を掲載しています。 最新の情報は AppSheet 公式リファレンスをご覧ください!

アプリをノーコードで開発しよう

ノーコード開発とは、コーディングなしでシステム開発を行う手法のことを指します。
GUI で処理を作成でき、インフラ関連の構築も不要であることが特徴で、非エンジニアの方でも簡単にアプリケーションを作成できます。
今回取り扱った Google が提供している「AppSheet」もノーコード開発ツールの一種です。

まずノーコード開発の手始めとして、事業部内で利用する勤怠管理ツールを開発することになりました。
アプリでできることは下記の通りです 👇

  • アプリで出退勤や所在を登録すると、勤怠連絡用のチャットに自動連携される
  • 勤怠情報がチーム別・プロジェクト別でアプリ上から確認できる

実際の開発期間は、仕様検討も含めておよそ1ヶ月ほど。
ノーコード開発の手軽さを体感しました 🎈

次は日報ツールだ!

勤怠管理ツールの開発実績からノーコード開発の可能性を見出し、次なる野望として全社向けの日報管理ツールを作成することになりました。
実際の運用に乗せるまで結果的におよそ2.5ヶ月ほどかかりましたが、この取り組みのなかでノーコード開発の便利さと難しさを実感することができました。

本記事では開発中の所感をもとにノーコード開発の得手・不得手を紹介していきます。

使って分かったノーコードの強み

環境構築が不要なので、すぐ実装に取り掛かれる

ノーコード開発ではアプリを新規作成した直後から開発に取り掛かることができ、インフラ周りの準備がほぼ不要です。
開発前の準備には専門の知識が必要になる場合が多いため、この辺りを AppSheet が担ってくれることは開発の敷居をかなり下げてくれるように感じました。

例えば AppSheet の場合、 AppSheet Database という独自のデータベースをアプリ作成と同時に自動で用意してくれます。
その他、通常の開発であれば必要になるパッケージのインストールやサーバ周りの構築などの工程が必要ですが、AppSheet ではプラットフォームに用意されているため環境構築自体が不要です。
即実装に取り掛かれるこのスピード感は、ノーコード開発の大きな強みと言えるでしょう。

共有方法に関しても、Google アカウントさえあれば公開範囲を設定するだけなのでお手軽にアプリ開発に取り掛かれます。

とにかく開発スピードが速い

仕様さえ固まれば GUI 操作ですぐに実装することができます。
対象データの一覧表示のような View なら、ものの 5 分で実装することができました。

データの表示だけでなく、登録フォームも簡単に実装できます。
特にバリデーションの設定が簡単で、Google Sheets でのデータ管理で課題となる入力規則の設定や、必須・任意項目の指定などもマウス一つで簡単に設定することが可能です。
(一部バリデーションの指定にコーディングが必要になる場合もありますが、Google Sheets や Excel の関数をご存じの方ならすぐに AppSheet 独自の関数に落とし込めそうです。)

ちなみに、実際の画面がコチラ👇

Viewの設定画面

諸々設定するとこんな感じの画面がお手軽に作成できます✨

作成されたタスク一覧画面

Google and the Google logo are registered trademarks of Google LLC, used with permission.)

GUI なので何をやっているか分かりやすい

AppSheet では「ボタンを押すと ○○ をする」というような機能面の開発を「Action」という機能を使って行います。
この場合、「どのテーブルに」「どんな条件で」「何を行う」というのを GUI で指定・確認できるので、開発経験が浅くても開発のハードルが低くなるのではと思いました。

また、何かしらの処理や動作をトリガーにするデータ操作や、Webhook による連携を「Automation」という機能を用いて開発します。
Automation ではフロー図に処理を書いていくため、一目でなんの処理が行われているのか見やすいという利点があります。

下記は実際の Automation 設定画面になります💁‍♀️
これならプログラミング経験がない方でも簡単に実装できそうですね!

Automation設定画面

Google and the Google logo are registered trademarks of Google LLC, used with permission.)

使って分かったノーコードの弱み

「できること」「できないこと」がハッキリわかれる

ノーコード開発ではそのプラットフォームに用意されている機能がすべてになります。
つまり、用意されていない機能や処理は実装できない(ローコードで実装できる場合でも、かえって冗長になることがある)という弱点があります。

このような処理を実現する奥の手として、AppSheet では Google Apps Script(GAS) の呼び出しが可能です。(戻り値も取得できます)
しかし「GAS の呼び出し」というオーバーヘッドが発生しているのか、処理が遅くなる感覚がありました。

実際、別で開発したアプリでは AppSheet での実装が難しい部分を GAS で補ったのですが、処理自体の遅さが気になったのはもちろんのこと GAS 実行時のエラーキャッチが難しかったです💦
そういう点でもプラットフォームに用意されている機能以上のことを実装するのはハードルが高いと感じました。

チーム開発には不向き

AppSheet は個人開発を想定して構成されているようで、チーム開発には適していません
これは小規模ながらもチームで開発を進めていた日報ツール開発では大きな障壁となりました。

例えば、一般的な開発で用いられるバージョン管理ツール(Git や Subversion など)の役割を担えるような機能が AppSheet にはありません。
(過去の履歴を自動でバージョンとして残し、特定のバージョンを指定して変更を戻すことなどは可能です)
このため複数人で一つのアプリを編集しなければならず、変更がバッティングすると実装した機能が消えてしまったりするので運用には工夫が必要でした。

日報ツール開発時は、チームで開発するために下記のような運用ルールを策定しました。

  • 自己検証は公開中のアプリを複製して作成した別環境を用意して行う
  • 同時に公開中のアプリを編集しないよう、専用チャットで作業を行う旨を周知するよう徹底する

プラットフォームの品質への依存度が高い

提供されたプラットフォームで開発している以上、プラットフォーム自体のバグやシステムエラーには太刀打ちできません。
またメンテナンスによる瞬断の有無は運営側のアナウンスを待つ他なく、AppSheet の場合(肌感ですが)こういったアナウンスが遅い印象があります。

ちなみにスタイル・エッジでは対策として

  • 公式サイトのアナウンスを定期的に確認する
  • プラットフォームのメンテナンスがある場合は、利用者に予めアプリの使用を控えてもらうようアナウンスする

などを行っています。

最後に

ここまでノーコード開発の強みや弱みを書いてきましたが、やはり「誰でもツールを作れる」のは魅力的だと思います。
これまで Google Sheet 等で管理していたデータをアプリ化するだけでも、データの集計や入力ミスの防止などに大いに役立つと感じました。

このように、スタイル・エッジでは Web アプリケーションだけでなくノーコードツールなどの新しい技術を取り入れた社内ツールも作っています!
ご興味ある方は最近リニューアルされた採用サイト ↓をぜひご覧ください ♪ recruit.styleedge.co.jp

RPA入門

こんにちは!スタイル・エッジの310です。

簡単に自己紹介をしますと
出身は愛知県、色んな意味で激動の時代を生き抜いてきた1985年生まれです。
帰宅後は3歳になる娘と、日々一緒にお風呂入る入らない論争を繰り広げています。

職歴は一風変わっておりまして
家屋の壁紙を貼る仕事、車のライン工場、パチンコ屋、バンドマン(楽曲制作/編集)、アパレルなどを経験し
前職は『ITコンサルタント』として、主にRPAツールを用いた業務効率化の提案、構築をしていました。

現在は『コーポレートエンジニア』として、ITサポートや端末、アカウントの準備といった基本となる業務や、AppSheetやRPAを用いた業務の効率化、自動化を担当しています。

はじめに

例えば、1名の入社申請が発生し、端末をお渡しするまで、どれくらいの時間を要していると思いますか?
弊社の場合ですと

  • アカウント準備で約50分
  • 端末準備で約30分

Wチェックを行う関係もあり、スムーズに進んだとしても1時間半はかかります。
またチェックを待つ=自分の業務が滞るため、強制的に複数の業務を同時進行する必要が出てきます。

こういった業務を効率化するべく、現在、RPAを用いた検証を進めており
アカウント準備に関しては、セルフチェックを含め10分~15分程度で完結できるようになりました。

今回はその経験から、RPAの入り口だけでも感じていただければと思い
1.RPAとは
2.事前の準備~構築まで
3.RPAのメリット
4.RPA導入前に考えること
をご紹介していきます。

1.RPAとは

詳細は割愛しますが、人がやっている業務をロボットに任せてしまおうということです。

例えば

  • Excelスプレッドシートから情報を取得しシステムへの入力(出力)
  • 毎月の勤怠システムの締め作業
  • 請求書の作成
  • メール送信

のような定型業務は特に向いています。

少し応用したモノとして

  • 届いたメールの内容を判定し、テンプレートから自動返信
  • フォルダ内に新規ファイルが追加されたら自動的にアップロード

といったロボットを構築することも可能です。

2.事前の準備~構築まで

実際に自動化しよう!となったら以下の順で進めていきます。

  • 業務の可視化
    →やっておくと構築が楽になります。手順を見直すことができるため、ナレッジ化やそもそもの効率化につながることもあります。

  • 自動化ツールの選定
    →例えばフォルダ内のファイルの移動や結合だけであれば、VBS、VBAの方が圧倒的に速いというケースもあります。自社内のスキル保有者状況と相談にはなりますが、コスト、保守面を踏まえ、色々な方法を検討します。

  • いざRPAの構築
    →上記を経て、RPAで自動化をしよう!となったらいざ構築へ入っていきます。実際のUiPathでの構築画面は以下のようになります。

画面左側にある【アクティビティ】と呼ばれる動作のパーツを
画面中央の【デザインパネル】の部分へドラッグ&ドロップを行い
画面右側の【プロパティパネル】で設定を行います。
※図ですと大量に設定項目がありますが、全部を設定するわけではなく、利用するブラウザであったり、入力された文字を変数に収納するかなど2,3か所設定するだけです。

あとはコツコツと組み立てていき

  • 自身の環境で動作検証
  • 利用部署(クライアント)環境での検証
  • 必要に応じて修正、改善

という工程を経て、最終確認したらロボットの完成です!

RPAのツールによりますが
作成したロボットはZIPファイル等にまとめて共有するだけのため非常に共有も楽です。

細かな部分として

  • 効果測定
  • サイトやシステムの仕様変更時の保守やトラブル発生時の対応の取り決め

このあたりも行っておくと盤石です。

3.RPAのメリット

自動化したい!となったときに、マクロ、VBS、バッチのようなスクリプトやプログラムで補えるケースもありますが、プログラムを書けなくても、パーツを組み合わせるだけで誰でも構築できるというのは大きなメリットです。

また『Power Automate』や、諸条件はありますが『UiPath ※Community版』のような無料で使えるツールもあり、無料で使える=利用者が多い=情報が多いという好循環により、何か困ったときは調べれば大体の情報を見つけられるというのも大きなメリットかと思います。

無料版のRPAであれば、セキュリティ面、利用停止やサービス終了等のリスクを考慮し
問題ないと判断ができる場合は導入してもよいと思います。
もしも有料版のRPAを導入する場合、以下の3点は事前に確認、整理しておくことが大切です。

費用対効果と導入目的

RPAツールの導入では約50万~100万円前後と相応の金額が年間で発生してきます。
単純計算ですが、時間給2000円と仮定した場合、年間250時間以上の削減が見込めるか
または、費用相応のES(従業員満足度)向上 に寄与できるかといったところは大きなポイントになります。

RPAの導入意義として人手不足の解消という面もありますので、費用のみを見るのではなく『何をどうしたいか、どうなってほしいか』を定めておくことはとても大切なことではないでしょうか。

ライセンス形式

RPAツールによって、フローティング型ライセンス、ノードロック型ライセンスというものがあります。

フローティング型

 概要:契約したライセンスの数だけ自由に使うことができるタイプ
 メリット:様々な部署で利用することができ、柔軟な運用が可能
 デメリット:ライセンス管理が必要、費用が高め

ノードロック型

 概要:ライセンスと端末が紐づくタイプ
 メリット:フローティング型と比較して安い、ライセンス管理が不要
 デメリット:端末交換時に変更手続きが必要、専用端末を設けることになる

個人的な見解としてはフローティングライセンスの方がおすすめですが、開発は専門部署が行い、使うのは別部署という場合は

  • 開発部署:フローティング(開発&実行の両方可能)
  • 利用部署:ノードロック(実行のみ可能)

とする方法もRPAツールのライセンスによっては可能です。

ロボットの管理者

RPAに限らずですが、どこの部署がライセンスを管理するのか であったり
構築、保守は誰が行うのか など予め決めておく必要があります。

導入したものの、属人化してしまったり、野良ツールと化してしまっては
構築当初は良くとも、だんだんと改修が困難になり業務の変化についてこられなくなってしまいますので
ロボットの運用方針は固めておきましょう。

最後に

私自身まだRPAの構築歴は浅いのですがUiPath等のRPAツールではAPI連携が可能なものもあるため、非常に可能性を感じています!

無料版であれば、法人個人問わず利用ができますので

  • プログラミングは難しすぎて挫折してしまった・・・※わたしもそうです( ^ω^)
  • 何かデジタル技術による効率化の取り組みをやってみたい!

という方がいらっしゃいましたら、ぜひ試してみてはいかがでしょうか。

そんな私が働くスタイル・エッジでは
一緒に働く仲間を募集しています。
最近リニューアルされた採用サイト↓もカッコイイ作りになっていますので、ぜひご覧ください♪ https://recruit.styleedge.co.jp/