最初に
株式会社LITALICOでエンジニアをやっている@kazuisです。
主にLITALICOが提供している障害者福祉サービスのエンタープライズシステムを担当してます。
この記事は『LITALICO Advent Calendar 2017』13日目の記事です。
新しいシステムをつくる場合、どの言語、ミドルや手法を使っていいのか迷う事もあると思います。
システムのアーキテクチャを決めるプロセスに関してかっこよくまとめているものって少ない感覚があります。
ウォータフォールでもスクラムなどの手法や、設計の書籍などは多くあります。
そして、言語やミドルウエアの情報はインターネットに溢れております。
しかし、その間のアーキテクチャ選定の勘所の情報ってあまりないような、、
自分の考えを整理する意味も込めて軽くまとめてみます。
組織や、プロジェクト毎に適切なアーキテクチャは異なるはずです。
各自・各社の”ちょうどいい”を探るためのアプローチについて書けたらと思います。
システム・アーキテクチャと大きく範囲を決めると書くのも辛くなるので
今回は、言語やフレームワークに関係する要素のみにして書いていきます。
決めるときに集めておきたい情報
システムのアーキテクチャは ”なぜシステムが必要なのか” によって大きく変わります。
ちょっと大げさにいいますと、銀行のシステム作るのか、何かのイベントサイトのミニゲームを作るのか、、、
これらは同じアーキテクチャである必要はありません。
まず、システムを作りたい理由を知る必要があります。
- ビジネス的な理由
- システム的な理由
- 技術戦略的な理由
これらを集めることによって、そのシステムに求められる要件がわかってきます。
そして、何を作るのかを知る必要があります。
業務フローをそろえて、、機能要件などそろえて、、というのも大切ですが
一番、大事にしている事は『大切にしたいコンセプト』を知る事です。
- コンセプト
- コアドメイン
コアドメインに適切なアーキテクチャが採用されていないと
なんのためにシステムを作るのかわからなくなってしまいます。
ユーザ向けのシステムだと明確に定義はされる事は多いと思いますが、エンタープライズ系は少ないと思います。
あとは普通に要件分析を行った情報が必要になります。
新しくシステムを構築する理由がシステム的な理由が大きい場合、システム要件の前に
ある程度、言語変えたいとかインフラの基盤をクラウドに変えたいとか
アーキテクチャを変える事が目的になる事はよくあるとは思います。
また、そもそもビジネスの流れが速すぎてなかなかを決定してからシステム開発を進めるのは
難しい時代なのかもしれません。
ここでは要件主体で進めるのか、フィードバック優先で進めるのかが判別できれば十分だと思います。
- システム要件
※ RDRAの分析手法がモデルベースなので、個人的には好きです。
アーキテクチャを決める観点でもシステム全体の見通しがよくなるので勉強しながら使ってます。
モデルベース要件定義テクニック 神崎 善司
ビジネス的な理由の例
新しい販路開拓や、商材のための機能がほしい。
とりあえず、XXXしたいからシステムがほしい（スピード）
大きく業務効率化を図りたい。
システム的な理由の例
もうシステムが肥大化してビジネスの拡張に追いつかない。
技術的な負債がたまっている返却したい。
使っている技術が古すぎて保守開発に難儀している。
保守費が肥大化しているので効率化したい。
技術戦略的な理由の例
将来的には、XXXしたいとか
システム戦略の実現と現在のシステムの違いがある。
集めた情報からシステム戦略を作ります
情報が集まったら、次にその問題をどのように解決するのかを決めます。
所謂、要件定義がない場合でも考えることは同じです。
ヒアリングや、温度感を感じ取りおおよその感覚を得ます。
人、モノ、金、情報、時間 というビジネス書にありがちな言葉で整理してます。
ビジネスの変化量と、コスト、開発者集めは重要な考慮すべきところだと考えてます。
この手の項目を考慮した結果、システム戦略を作ります。
| 分類 | 項目 | 思う事 |
|---|---|---|
| 人 | 開発者チームの規模 | 1人でやるのか100人でやれるのか |
| 人 | 開発者チームのスキル | 開発チームで作れるか？ 保守できるか？ |
| 人 | 開発者の集めやすさ | 採用などで人を集めやすいか？ |
| モノ | インフラの縛りがあるか | クラウド使いたいが、、使えない場合もある。 |
| モノ | 事業所の数や、人などユーザ規模など | 導入にかかる考慮がどこまで必要か |
| モノ | 既存システムとの連携 | 移行性が大切になってくる。 |
| モノ | 外部システムとの連携 | システムの境界線を知ろう。 |
| 金 | 予算 | 理想にお金がかかりすぎると、実現できない事もあります。 |
| 金 | ビジネス規模、またその予測 | データ量だったり、情報量を考慮してシステム化する |
| 情報 | モデルの関係 | ドメインの区分はシステムの区分になったりする。 |
| 情報 | 情報量 | データの分割を考慮にするべきか |
| 情報 | 情報の変化するスピード | ビジネスの変化スピードを知らないと |
| 情報 | ミッションクリティカルな業務の数 | 計算処理なんか多い業務系は |
| 情報 | セキュリティが必要な情報 | 個人情報など、重要な情報がどれだけあるのか |
| 時間 | 初期リリースまでの時間 | 初期リリース時と運用時に開発プロセス変えるかもしれない |
| 時間 | 要望の頻度 | システムの変更要望の頻度がいかほどか |
| 時間 | システムのライフサイクル | 10年運用予定なのか？2年なのか？ |
まずはシステムのスコープを決めます。
それから対象システムの分類を見極めます。
SoR（System of Record / 記録のためのシステム）なのかSoE（System of Engagement / 絆のためのシステム）なのか分類します。
SoRは、取引や会計情報など正しく記録する事が求められるシステム。
SoEは、利用者が主に使うMyページなどのユーザ毎の最適化が求められるシステム。
SoR的なシステムであれば固めなアーキテクチャを選択しようか検討します。
SoE的なシステムであれば、スピード感を持って開発できるアーキテクチャや開発プロセスを検討します。
これは、サブシステム毎に違ってもいいと思ってます。
マイクロサービスアーキテクチャを採用するならば、違って尚良しと思うところです。
＊参考：エンタープライズを主軸にアジャイルやマイクロサービスアーキテクチャの事が書かれており勉強になります。
Cloud First Architecture 設計ガイド
分類を決めたらライフサイクルに見合った
初期要求を満たすシステム構造の戦略を決めます
SoR的なシステムであれば、規模が大きくならない程度ならモノリシックなシステムでもいいかなっと思います。
マイクロサービスはトランザクションを設計するのは難易度が高いです。
データの整合性が求められる構造を作る事を考えます。
SoE的なシステムであれば、初期リリース後のシステム変更要求が多いはずなので
アーキテクチャ構造自体も追加を求められる構造にすることを決めます。
言語とかフレームワークを決めるときに考えている事
システムの構造がきまれば、それに振る舞いをつける開発言語を決める事になります。
エンタープライズのシステムを作るときに多いのはJavaでしょうか
ベンチャーなどのスタートアップなどでは、エンジニアの得意な言語やフレームワークが使われるようです。
SoR的なシステムの場合、固めな言語やフレームワークがいいと思うのでJavaを選択するもいいでしょう。
システム変更要望が頻繁にないとはいえ、定期的に変更要求があります。
学習コストがやや重いですが型があった方が構造の変更をビルドエラーとして検知できますしいい事は多いです。
構造や状態をコントロールするのには向いていると思います。
SoE的なシステムの場合、業務フローやユーザビリティの変更要求は多くなりますのでスピードが求められれます。
ガンガン修正して確認できる言語やフレームワークがいいと思ってます。RubyやPHPとかでフィードバックをもらいながら作っていける仕組みを構築していくのがいいと思います。 エンタープライズシステムでもWebサービスのようなスピード感が求められる事に対応できなければいけません。
共通で大事な事
言語やフレームワークを選択するときに機能を実現できるというのも、もちろんですが
1番大事にしているのは以下の３つです。
- 開発者チームのスキルアップ
- 開発者の集めやすさ
- 運用できるのか
どんなシステムを作っても運用・保守できなければ意味がありません。
フレームワークの流行りもあります。
開発時に選択したフレームワークは、5年後、思い出になっているかもしれません。
なので、技術的な流れを無視した言語やフレームワークの選択はできません。
流行りではなく、技術的な流れを間違わない選択が必要です。
フレームワークは廃れてしまうかもしれませんが、エンジニアのスキルを高める選択をする必要があります。
エンジニアのスキルレベルが上がればシステムは健全に維持され、作り直しも容易にできるでしょう。
そして、技術的な流れのフレームワークを使いたいというエンジニアが集まってくれるかもしれません。
( エンジニアは古いフレームワークは好きではありません、、、新しいフレームワークはモチベーションがあがります）
近年、大型のシステム作り直しでScalaとか名前が上がるのもそういう側面もあると思ってます。
（Scala好きです！）
システムを完成させ、運用する責任もあります。
そのバランスをどうとるのかがアーキテクトの腕の見せ所ではないでしょうか
最後に
エンタープライズ向けのシステムでもビジネスの流れがはやく開発初期に、アーキテクチャを決めてもそれがシステムのライフサイクルの中でずっと正しいとは限らないのです。
リタリコの事業である障害者福祉の分野は国の仕組みもまだまだ変わる段階なのでシステム対応が大変です。
壊しやすく、細かく作り直しができるアーキテクチャを目指しています。