株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『LITALICO Engineers Advent Calendar 2019』の9日目の記事になります。
障害者福祉分野でエンジニアリングを使ってシステムを作っている日々を過ごしています。
はじめに
ビジネス層の方々と、コミュニケーションを取りながらお仕事を進める日々を過ごしており以下の困り事がある方向けにちょっとでもお役に立てればと思い書いております。
- テックリード的なポジションでシステム全体の設計を考えないと行けない方
- ドメイン駆動設計をやっているが、なかなかコアドメインを見つけられない方
- システムつくる前に、何をしていいのか足踏みしちゃう方
- ビジネス層の方と同じ目線を持ちたい方
そもそも、ドメインエキスパートは忙しい人が多いので先生のようにレクチャしてくれないのでエンジニアは自分たちでドメイン知識をつける必要はありますよね
システムを作るちょっとその前に
システムやサービスを作るには、幅広い知識が必要ですが、技術以外にいわゆるビジネス知識が必ず求められます。昨今では、大規模の開発より、少人数でサービスを作っていく事が増えたり、ドメイン駆動設計をされている方も多いので１人のエンジニアに求められるインプットするべき知識量は増えているのではないでしょうか？
- ビジネス分野の知識
- 自社のIT戦略の知識
- 自社で作る・運営するサービス・コンセプトの理解
- 運営しているサービスのドメイン理解
- 運営されているシステムやデータの理解
2～3は自社の話でもあり、責任者が説明してくれる事もあると思います。しかし、1のビジネス分野の知識は、なかなかまとまっている文書はないし、あっても長い文書で読んでいるうちに何が書いてあるかわからなくなりがちです。ちょっとしたモデル化の知識があればシンプルに理解できるはずです。
ビジネス分野、業界知識と言い換えてもいいかもしれません。
EC業界、金融業界、〇〇ペイ業界、レンタル業界、小売業界、放送業界、格安SIM業界、広告業界、このレベルの抽象化されたものをモデル化します。
アーキテクト視点で役立つ事
自社の強みも、弱みもビジネス分野の理解がわかってないと理解できないですし、システム化する際にも業界を知る事によって『境界づけられたコンテキスト』を探す上にも必要な事です。ドメインエキスパートは、１つの『境界づけられたコンテキスト』のエキスパートである事が多いと思います。複数の関心事、ドメインを横断するアーキテクチャ、システムイメージを作るにはアーキテクトが業界の知識をつける必要があります。また、ビジネスの将来をビジョン化してシステムアーキテクチャを設計する上で、業界の知識、ビジネスの商流、トレンドを知る事はアーキテクトのお仕事の最初の1歩になります。そのような肩書がついてなくても昨今は少人数でサービスを立ち上げる事は多いはずですから、どのエンジニアにも必要な事だと考えてます。
LITALICOは障害者福祉の会社です。
自社のサービスの前に障害者福祉の分野の知識が必要になります。
障害者福祉の障害児通所支援を例にちょっとモデル化してみます。
ビジネス分野の知識の1次情報を探す
厚生労働省のホームページは資料がまとまっていますが、検討資料や、論点毎の資料が多いのでビジネス分野を理解するにはちょっと資料としては辛そうです。その中で、障害児支援施策というページには概要の資料もありますし、とはいえ、各資料が100ページをゆうに超える資料の塊なのですが、、。ここの資料をベースにして情報を集めます。障害者福祉は国の施策なので、資料があります。他の分野でも自社の関係する業界のベースになるビジネスモデルをまずどの情報をもとに集めるのか見極めるのは大切です。
もちろん、ステークホルダーや、ドメインエキスパートのヒアリングは大事です。これは、ヒアリングする前のフェーズに必要な事です。ドメインエキスパートがすべて正しいとは限らないからです。 ※障害者福祉は法律の塊なので、行政が提示しているルールをまず知る事が大切です。
このモデルを作る上では以下の資料を中心に読んでます。
* 児童発達支援ガイドライン
* 放課後等デイサービスガイドライン
* 保育所等訪問支援の手引き
ひたすら、読みながらこれから紹介する資料でまとめます。
ひと・モノ・金・情報の流れを知る。
業界の商流を整理するために、ビジネスモデル図解ツールキットを使って整理してます。本来なら新しいビジネスモデルなどを表現するものなのでしょうが、、業界の商流を整理するのに使ってみたりしています。これをベースに自社サービスのビジネスモデルを更新して追加していきます。この図のいいところは、ビジネス分野の価値を表現できるところです。この図で『プログラム』となっている『HOW』の部分がビジネス的な価値だと整理段階で意識しながら書いています。よい支援プログラムをどのように育てるのか、ユーザに価値を判断してもらうのかをシステム化し”最大化する”のがコアドメインになりえると予測できます。また、どの情報を知的資産にするべき業界なのかを知る事ができる整理方法だと思ってます。
※この図は、業務で使っているわけではないので正確性にかける部分はあるかもしれないです。
アーキテクト視点で役立つ事
この段階だと、業界分析に過ぎないので、自社サービスが、それを価値としてビジネスモデルを作るのかわかりません。この知識を元に、自社サービスの価値を考える事ができます。また、境界づけられたコンテキストもある程度見えてきたのではないでしょうか？ もちろん、自社のドメインのあり方によって業界と変わる事はあります。
関係者の業界への期待値を知る。
このビジネス分野に対する期待値をRDRAのシステム価値フェーズのモデルを使って整理します。本来ならば、システムをつくるときの要求分析のためのモデル技法ですが、業界分析に使います。このビジネス分野は誰にどんな価値を与えているのかを、システム価値フェーズのコンテキストモデルと要求モデルをあわせたようなモデルを作って整理します。重要なのはアクターが洗い出されており、どんな期待値をもっているのかというものが表現されているかというところにあります。ガイドラインや、マニュアルから期待値を洗い出しモデル化する事によって改めて整理する事ができます。色を変えているところは、整理時の疑問や感想を書いています。整理後にドメインエキスパートや、ステークフォルダとコミュニケーション取るときに具体化していければいいと思っているところです。
※この図は、業務で使っているわけではないので正確性にかける部分はあるかもしれないです。
アーキテクト視点で役立つ事
ユビキタス言語の洗い出し、アクターが整理される事によってシステム境界（ユーザ向け機能、管理者向け機能）を考える事に有効的に使えます。マイクロサービスのサービス単位を決めるときに参考にしたりします。
業界のドメイン・境界づけられたコンテキストを探る。
実際にドメインエキスパートや、ステークフォルダとコミュニケーションを取りながら完成させる事は前提ですが、ビジネス分野を理解する上で業界で発生するドメインを可視化します。知るというより、探るの状態に近いので、柔軟性の高いマインドマップを使って可視化しながら整理していきます。 上記２つので洗い出した情報をもとに、想定されてる業務をベースに枝を作っていきます。作りながら整理できるように、アプリやWebサービスのツールを使った方がいいと思います。もちろん、紙でもいいのですが、、書きながら業界や、業務をイメージしてアウトプットを出していきます。前述しましたが、ビジネス分野全体のドメインエキスパートがいることは稀だと思います。特定のドメインや関心事のドメインエキスパートとコミュニケーションするはずです。ビジネス分野全体でマインドマップをかけている状態が望ましいです。知らない業務、知らないドメインエキスパートを探すきっかけになると思います。
※この図は、業務で使っているわけではないので正確性にかける部分はあるかもしれないです。
アーキテクト視点で役立つ事
整理も中盤になると、ある程度の境界づけられたドメインがみえてくるように整理ができるようになります。この中からコアドメインをみつけ、ほんとにシステム化が必要なドメインを見つける事にやくに立ちます。また、自社のサービス毎にドメインも増えたりするとは思うのでビジネス分野のドメインが整理できたら、自社サービスでのマインドマップを追加していくといいと思います。業界で必ず必要なコアドメインと、自社で必要なサビドメインがわかると、システムの変化の度合いを判断できる可能性があります。自社のオリジナリティが強い業務は、基本的には変化が激しい業務と考えられるのです。サブドメインは変化がある事を前提で別のマイクロサービスへの切り離して設計するなどするとよいと思います。
最後に
これで、ビジネス分野の知識、業界知識をつける事ができました。全体が見える状態にはなったと思います。
これを武器に、ドメインエキスパート、ステークフォルダと話しながらシステム・アーキテクチャを決めて行ける準備ができました。こっから先は、自社サービスを中心としたドメイン駆動設計をすれば、より何がユビキタス言語であるべきなのか、コアドメインなのかコミュニケーションがスムーズに進むはずです。アーキテクト視点ならばマイクロサービス化する際に何をサービス化するべきなのか判断をつけやすくなるでしょう。
どの業界でも様々な業務がたくさんあり、業界が成り立っています。境界づけられたコンテキスト毎に開発をわけて開発をしたところで、すべての開発者が同じような業界知識を持って開発を進めるのは難しいです。しかし、システムアーキテクチャを作るものは、すべての業務知識を知った上でシステム・アーキテクチャを決める必要があります。少しでもこの知識を付け方を効率化し、自社サービスの価値に時間を使えるようにして行きたいです。
アプリケーションのプロではなく、システムのプロではなく、サービスのプロではなく、業界のプロのエンジニア集団を目指すエンジニアが増え事を願ってます。それはきっとサービスのプロであり、システムのプロで、アプリケーションのプロの近道だから
お知らせ
現在弊社LITALICOではデザイナーやエンジニアをWantedlyにて絶賛採用募集中です。（Wantedlyの弊社の募集一覧ページ）ぜひご気軽に、お話だけでも聞きに来てください。
明日は、@yusukefushiki さんの「カテゴリー検索の必要性を理解しよう」です。お楽しみにです。
『LITALICO Engineers Advent Calendar 2019』