モデリング

2022/11/29

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体|山本 正喜 / Chatwork CEO|note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか?

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5~7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか?

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか?
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム(SoR)が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。


| | コメント (0)

2022/11/06

Go言語でできることは何なのか

Go言語でできることは何なのか、について考えたことをメモ。
全くのGo初心者がいろいろ考えたことのメモ。
間違えていたら後で直す。

【参考】
とほほのGo言語入門 - とほほのWWW入門

Go言語(golang)とは? 特徴・できること・将来性を徹底解説 | 【テックストックMAGAZINE】エンジニア向けスキル・キャリア情報

Go言語にできることってなに?人気の理由をくわしく解説 | 株式会社パソナ(旧パソナテック)|ITエンジニア・ものづくりエンジニアの求人情報・転職情報

Go言語の強みと得意分野を探る(上) - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(中)1 - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(中)2 - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(下) - Go言語の強みと得意分野を探る:Computerworld

Go言語でできることとは?Go言語で作れるアプリの事例を紹介 | プログラミング大陸

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Go言語の書籍を色々読んでみて色々気づきはあった。

Go言語は、マイクロサービスアーキテクチャを実装するプログラミング言語であるらしい。
色々記事を読んでみて、Go言語は、CLIやAPIを作るのに最適な言語であると感じた。

他システムがWebサーバーからデータを取得したり更新しようとする時、APIという公開IFを設けて疎結合な設計にしたい。
Go言語であれば簡単にHTTPでやり取りできるのでWebサーバを立ち上げる必要もなく、普通のクライアントアプリケーションみたいに作ればいい。
また、Go言語では並行プロセスの実装も割と簡単なので、負荷に応じてプロセスを増やせば良く、クラウド上でAPIを公開するためのアプリとして最適。

Go言語でCLIを作るイメージは、Unixコマンドを作るイメージだろうか。
Unixであれば、/binの中に各種コマンドがexeで配置されている。
別システムがバッチ処理をキックしてシステム連携したい場合、CLIという公開IFを叩けば良い。

そんなことを考えると、Go言語はかなり特殊な状況で使うもののように思う。
業務ロジックを実装するレイヤではなく、OSやアプリの間で処理するためのミドルウェア、ないしフレームワークみたいな役割を持つレイヤで実装すべき。

また、Go言語はクラウドと相性がいい。
Go言語はクロスプラットフォームでバイナリファイルを作れるので、CLIやAPIに向く。
また、Go言語で作ったバイナリファイルのサイズを小さくできれば、クラウドのリソースを少なく押さえられる。
また、メソッド呼び出し時のアプリ起動時間を短くでき、並行プロセスで走るアプリの起動時間(ロード時間)も短くできる

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

つまり、Go言語はクラウド上でCLIやAPIを実装したプログラムに特化した言語なのだろう。
だから、マイクロサービスアーキテクチャと相性が良いと言われているのだろう。
そして、マイクロサービスアーキテクチャはドメインごとの境界で使われるので、ドメイン駆動設計とも相性がよく、それらの設計技法と密接に絡む。

そんなことを考えると、一昔前のオンプレ環境でのWebシステム構築で経験されて蓄積されたアーキテクチャ設計技法は古くなっており、クラウドに特化したアーキテクチャ設計技法をもっと探究していくべきだ、という方向性が出てくるのだろう。
このあたりの考え方もいろいろ調べている。

| | コメント (0)

2022/10/16

クラウド上の開発がJavaに与えた影響は何なのか

クラウド上の開発がJavaに与えた影響は何なのだろうか。
考えがまとまっていないがラフなメモ。
自分はAWSも知らないし、Go言語も知らないので、間違っていたら後で直す。

【参考】
Javaがサーバレスに至るまでの道のり

元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話 - DMM inside

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Javaがサーバレスに至るまでの道のりの記事を読むと、いかに軽量のWebアプリケーションを実現するか、に注力しているように思える。

従来のWebアプリケーション開発では、PerlのCGIのようなプロセス指向ではなく、JavaのServletのようなマルチスレッドの方が無駄にリソースを食わず、効率が良いと歌われていた。

しかし、サーバーレス環境では、AWS Lambdaのようにアプリをキックするような仕組みなので、アプリの処理時間だけでなく、アプリのロード時間も短いほど優位だからだ。
サーバーレス環境では、アプリを常駐させて、マルチプロセスで動く。
そして、処理が終わり、無駄に多くなったプロセスはすぐに破棄される。

つまり、クラウドでは、DockerやK8sのようなコンテナのおかげで、アプリ環境を使い捨てにできるメリットがある。
アプリも、負荷分散に応じて必要なだけ常駐プロセスを増やして、不要になれば捨てればいい。

すると、アプリのビルド、デプロイの時間も短い方がいい。
さらに、「起動時間がレスポンスタイムに含まれる」ために、アプリの起動時間も短くできれば、サーバーレス環境ではレスポンスタイムをもっと短くできて、使い勝手が良くなる。

そういう発想がJavaにどんな影響を与えているのか?
クラウド上の開発がJavaに与えた影響は何なのか?

たまたま、Javaのモジュールシステムの話の中で、jlinkコマンドがなぜ必要なのか?という話があった。
JDK9以後は、JREが配布されないので、Javaファイルを実行できない。
そこでjlinkで実行ファイルを作る必要があるという話だったが、さらにもう一つ興味深い話があった。

Java Module System 入門 その1 - YouTube

Java Module System 入門 その2 - YouTube

jlinkコマンドを使うとランタイム専用アプリを作れるが、必要なJDKライブラリだけを読み込んで、Jarファイルを作成する。
すると、jlinkで作られたランタイム専用アプリのサイズは、従来のランタイム専用アプリのサイズよりもかなり小さくなる。
不要なライブラリを除いているからだ。
実際、デモ画面では200Mから30Mまで小さくできた例があった。

つまり、jlinkコマンドを使えば、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
その分、クラウドのリソースを抑えられるし、アプリの起動時間(ロード時間)も短くできるメリットが出てくる。

すなわち、jlinkコマンドはクラウド上で配布するアプリに適合するように作られたものなのだろう。
Javaもクラウドに特化したアーキテクチャ設計を取り込んでいるのだろう。

そんな話を聞くと、サーバーレス環境のアプリでは、ランタイム専用アプリはバイナリファイルでサイズが小さいほど優位性が高いことになる。
マイクロサービスの実装言語はGoが主流であると聞くが、その理由は、Goで簡単にバイナリファイルが作れて、さらにそのサイズが小さいので、性能的にも優れている点があるのではないだろうか?
そして、Javaもそういう流れの設計手法を取り入れるために、jlinkコマンドのようなアーキテクチャが必要になってきたのではないだろうか?

ここで、クラウド上のシステム設計では、ドメインごとにアプリを細分化したマイクロサービスアーキテクチャが流行していて一般的になってきている。
マイクロサービスアーキテクチャが必要な理由は、普通のWebシステムでもクライアントからのアクセスがブラウザだけでなく、スマホだったりタブレットだったり、色んな端末に対応する必要があるので、公開APIを通じて制御できるよに、色々分割したほうが楽になる点があるだろう。
また、逆コンウェイ戦略のように、システム開発しやすいチーム組織の観点で設計すると、小さなコンポーネントの集まりになるようにシステムを分割して、マイクロサービスアーキテクチャで連携できるようにした方がよい点もあるだろう。

マイクロサービスアーキテクチャのそんな特徴を活かすには、おそらく、Go言語やjlinkコマンドのような実装言語やビルド方法も必要になってくるのだろう。

そんなことを考えると、クラウド上のシステム開発では、フロントWebシステムをRubyやJava、Pythonで作ったとしても、AWS lambdaやマイクロサービスの部分はGo言語やjlinkを使う、といったように、複数のプログラミング言語を適材適所に当てはめて開発する必要性があるのではないか。
つまり、クラウド上の開発は、単にコンテナ部分のアーキテクチャを使いこなすだけでなく、複数のプログラミング言語を適材適所で使い分けるノウハウも必要になってくるのだろう。

この辺りは妄想に近いかもしれないので間違っているかもしれない。
ただ、クラウドというアーキテクチャは、Webリソースをふんだんに使える富豪プログラミングを可能にしたからこそ、それに特化した設計手法がどんどん現れているのだろうと思う。

この発想が正しいのか、これから検証していく。

| | コメント (0)

2022/09/18

「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった

ソフトウェアアーキテクチャの基礎」は良い本と思う。
アーキテクトが読むべき本だったと思う。
ラフなメモ。

【1】ソフトウェアアーキテクチャの定義とは何か?
以前の定義は、ソフトウェアアーキテクチャとは後から変更することが難しいモノだった。
しかし、今は、マイクロサービスの出現により、変化しやすい設計を指すようになって、ガラリと変わった。

【2】アーキテクチャの重要な要素は、トレードオフの決定だ。
品質、コスト、スケジュール、スコープのバランスから、一番最良のものを選ぶ。
それぞれの要素を最大限にするのではなく、トータルでバランスが取れているものを選ぶ。

【3】アーキテクトに期待されている役割。

アーキテクチャ決定を下す。
アーキテクチャを継続的に分析する。
アーキテクチャの最新のトレンドを把握している。
アーキテクチャ決定の順序を徹底している。
様々な技術に精通している。
事業ドメインに詳しい。
対人スキルや政治力を持つ。

【4】ソフトウェアアーキテクチャを語る上で、XPの偉大さがある。

XPでは、プロセスよりも経験的に知られていたプラクティスを重視した。
たとえば、テストが多いほど品質が良くなる経験から、テスト駆動を生み出した。
継続的インテグレーション、コードの共同所有、継続的デプロイなど。

【5】ソフトウェアアーキテクチャの法則は2つ。

1つは、トレードオフが全て。
トレードオフが見つからないならば、分析が不十分な事実を知るべきだ。

2つ目は、HowよりもWhyが大事。

【6】モジュール性とは何なのか?

モジュール分割するアーキテクチャのテクニックの利点は分かる。
しかし、モジュールの実現方法はあまり知られていない、とメイヤーは言った。
この話は、コンポーネント志向につながる。

Javaならば、当初のJDKはパッケージで分割した。
しかし、それだけでは扱いづらいので、Jarというコンポーネントが導入された。
しかし、Jar同士でパッケージ名が衝突する場合があるから、module systemがJava9から導入された。
つまり、Javaもモジュール性の実装方法に苦労している。

【7】本の途中のコラムがとても参考になる。

【7-1】スウェーデンで軍艦ヴァーサ号を製造したが、初めて処女航海に出ようとした時に、すぐに港で沈没した話。

失敗の原因は、アーキテクチャ特性を全部盛り込みすぎて、軍艦が重すぎてしまい、バランスが取れなくなり沈没した。
数多くの利害関係者の要求を最新鋭の軍艦に盛り込んだために、軍艦として実現できなかった。

今のソフトウェアアーキテクチャの話も同じ。
ユーザのたくさんの要望を盛り込みすぎると、結局使い勝手の悪いシステムになってしまうし、それ以前にスケジュールが伸びすぎて永遠にリリースされないシステムになるリスクすらある。

【7-2】ドメイン駆動設計の意義は、境界づけられたコンテキストという概念により、アーキテクチャ設計手法が大きく変わった点にある。

ドメイン駆動設計の出現以前は、組織内の共通エンティティは再利用を重視していた。
しかし、再利用を重視しすぎて、ビルドが困難になり、チーム間の調整が難しくなり、ソフトウェアの複雑さが増大し、多くの問題を引き起こした。
たぶん、ソフトウェアプロダクトラインの話も同じ。

ドメイン駆動設計の出現後、境界づけられたコンテキストの考え方により、各エンティティは局所化されたコンテキストの中で最もよく機能すればいい。
つまり、組織全体の共通エンティティは不要であって、問題領域ごとにエンティティを自由に作り、その中で最適化されたエンティティを作ればいい。
問題領域のドメインの境界上で調整すればいい。
つまり、この考え方がマイクロサービスにつながるわけだ。
マイクロサービスの実装言語はGo言語が主流である。

各ドメイン内のシステムはRailsだったりPythonだったりPHPでもよく、複数のプログラミング言語で作られたシステムとGo言語によるマイクロサービスがAWSのようなクラウド上で動くアーキテクチャが多いわけだ。

【8】コンポーネント設計では、分割の観点は何か?

コンポーネント設計とは、アーキテクチャの分割であるという考え方。
レイヤーアーキテクチャがよく使われる。
たとえば、Javaの依存性注入(DI)、DLLやJarなどのコンポーネント。

この考え方を進めると、開発スタイルはコンウェイの法則に縛られることになり、複雑な組織構造が反映された複雑なアーキテクチャになってしまう。
だから、逆コンウェイ戦略という考え方が出てきた。

一方、コンポーネント設計とは、ドメインによる分割であるという考え方。
これはドメイン駆動設計であり、マイクロサービスアーキテクチャにつながる。

ドメインごとに開発チームを作ることにより、コンウェイの法則のリスクを避けられる。
逆コンウェイ戦略をそのまま実現しやすい。

【9】アーキテクチャスタイルとは、アーキテクチャのパターン集。

モノリシックアーキテクチャと分散アーキテクチャに分かれる。

モノリシックアーキテクチャ:

レイヤーアーキテクチャ →TCP/IPとか。
パイプラインアーキテクチャ →Unixとか。
マイクロカーネルアーキテクチャ →コアシステム+プラグインの構造。Eclipse、Jira、Jenkinsとか。

分散アーキテクチャ:

サービスベースアーキテクチャ →フロントエンド+バックエンド
イベント駆動アーキテクチャ →デスクトップアプリ。非同期システム。
スペースベースアーキテクチャ →ロードバランサー。インフラの仮想化。クラウド。
オーケストレーション駆動サービス指向アーキテクチャ →よく分からない。使われない。
マイクロサービスアーキテクチャ →ドメイン駆動設計とか。

分散アーキテクチャが今の流行だが、8個の誤信がある。
ネットワークは信頼できる。
レイテンシーがゼロ。
帯域幅は無限。
ネットワークは安全。
トポロジーは決して変化しない。
管理者は1人だけ。
転送コストはゼロ。
ネットワークは均一。

他にも、分散ロギング、分散トランザクションなどもある。

これらの観点をトレードオフとして考えるべき。

| | コメント (0)

2022/06/17

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンクがあったのでメモ。

【参考】
組み込みUMLでの、分析モデリングでのクラスの識別アプローチについて文献まとめ - 千里霧中

組込みソフトウェア開発と設計をちょっと調べている。
やっぱり設計手法にはUMLを使っている方が僕は理解しやすい。
それに関する書籍のリンクの記事があったので、メモしておく。

【1】組込みソフトウェア開発のためのオブジェクト指向モデリング (組込みエンジニア教科書) | SESSAME WG2

この本はとても分かりやすかった。
湯沸かしポットを題材として、実際にクラス図、状態遷移図まで落とし込んでくれている。
この本の感想は以前書いた。

組み込みソフトウェアの根本問題~対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい: プログラマの思索

【2】リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection) | ダグラス,ブルース, Douglass,Bruce Powel, 博之, 渡辺, 株式会社オージス総研

【3】リアルタイムUMLワークショップ | ブルース・ダグラス, 鈴木 尚志

持っているけど理解できていない。

【4】組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発 (OOP Foundations) | 博之, 渡辺, 和人, 堀松, 政彦, 渡辺, 和記, 渡守武

古本屋で見たことがある。
今度読んで見る。

【5】UML動的モデルによる組み込み開発―分析・設計・実装・テスト | 政彦, 渡辺, 哲史, 石田, 康二, 浅利, 周作, 飯田, 修二, 山本 | Amazon

今度読んで見る。

【6】オブジェクトデザイン (Object Oriented SELECTION) | レベッカ・ワーフスブラック, アラン・マクキーン, 株式会社オージス総研 藤井 拓, 株式会社オージス総研 藤井 拓, 辻 博靖, 井藤 晶子, 山口 雅之, 林 直樹

オブジェクト指向設計のうち、責任の割当に注力して書かれている。

【7】実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 | クレーグ・ラーマン, 依田 智夫, 今野 睦, 依田 光江

僕は第1版、第2版を読んだ。
第1版では「オブジェクト指向設計の肝はコラボレーション図(協調図)です」という一節がすごく心に響いた。
クラスへ責務を割り当てるときに、UML2.0ならコミュニケーション図を書いて、責務が集中しないように疎結合にしたり、関連する責務は集めて凝集度を高くする、などのアドバイスがあった。

| | コメント (0)

2022/05/06

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。

| | コメント (0)

2022/04/13

事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき

ドメイン駆動設計勉強会に参加してみて、事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべきという指摘になるほどと思えたのでメモ。
ラフなメモ。

【参考】
【ドメイン駆動設計勉強会】事業活動を理解して設計しよう! - connpass

増田さんの講演がすごく分かりやすかった。
問題意識は、事業活動をどのようにモデル化していくか?
事業活動をシステム化する時に、どこに注力すればいいのか?

まず、自社と外部の事業活動は、ピクト図で商品やお金の流れをシーケンス図のように表して、モデルにする。
自社の内部プロセスは、ポーターのバリューチェーンを使って、主活動と支援活動に分類する。

ドメイン駆動設計のアプローチでは、バリューチェーンの主活動や支援活動をサブドメインに分割する。
すると、基本は、主活動は企業価値を生み出すコアドメイン、支援活動は管理業務等の支援ドメイン、汎用ドメインになる。

ビジネスロジックの複雑度や差別化の重要度の観点では、コアドメインが重要であり、支援ドメイン、汎用ドメインの順になる。
一般に、汎用ドメインや支援ドメインの品質は当たり前品質で十分であり、コアドメインの品質は魅力的品質まで高める必要がある。

増田さんの講演でもっとも興味を引いた発言は、増田さんの経験では、事業活動のシステム化では、他社との差別化につながるコアドメインよりも、他社と差別化しなくて良い支援ドメインや汎用ドメインに注力すべき場合が多かった、という内容だった。
なぜならば、他社と同じような業務では、汎用ドメインや支援ドメインで構築すれば安く仕上がるし、その分野の人材も市場から確保しやすいからだ。
そもそもそういう分野では差別化せず、市販のサービスやパッケージをそのまま流用すればいい。

また、自社の弱点として実は、支援活動の業務があるケースが多いらしい。
すると、支援活動のシステム化に注力した方が投資効果が大きいらしい。
なぜなら、支援活動にある総務・財務・人事などの部門の業務は既存のパッケージ製品が多数あるからだ。

一方、本来の自社で価値を生み出すコアドメインは、独自のシステムになるから、コストをかけて当たり前品質以上の魅力的品質まで作り込むべきだ、という流れだと理解した。

一般に、支援活動にある総務・財務・人事などの部門の業務はどこの会社でも似たような内容であり、財務報告も法律で決められた書式で報告する必要があるから、できるだけ汎用ドメインで構築した方が運用が楽だし、コストもかからない。

むしろ、コストを掛けるべき部分はコアドメインであるから、汎用・支援ドメインにはコストを掛けずにメリハリを付けた方がいい。
そんな内容だと理解した。

たぶん、一般に、支援活動の業務は汎用のERPで導入した方が良いのだろう。
今ならば、汎用的なSaaSを導入すればいいのだろうと思う。

普通は、コアドメインに当たる主活動のモデル化に注力したくなるが、むしろ、支援・汎用ドメインに当たる支援活動のモデル化の方に企業の問題がある場合が多く、投資効果が大きいという経験談が面白かった。

| | コメント (0)

2022/03/25

「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ

大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司を読んだ。
まさにロシア侵略のウクライナ紛争のタイミングで読むと、彼らがこの本で書いた通りに行動しているのではないか、と思った。
ラフなメモ。

【1】まず最初に断っておくと、この本は672ページという大著であり、注釈だけでも150ページもある。
論文みたいな本だ。
しかし、内容はとてもロジカルだ。
この本のプランは最初の第1章の最後に書かれている。

【2】まず、なぜ国家はパワーを求めて競争するのか、なぜ国家は覇権を求めるのか、という2つの問題を提示し、この問題が国際政治学で重要な根本問題であることを示す。

数学で言えばwell-defined、論文のお作法で言えば、justifyに相当するだろう。
つまり、この本で提示する問題の正当性を示す。

【3】次に、なぜ国家はパワーを求めて競争するのか、という問題を分析するために、2つのことを行う。
一つは、パワーを定義する。
もう一つは、国家が活動する舞台である国際システムにおいて、5つの仮定を置き、そこから国家がどのような行動を取るのか、を導き、最終的に最初の根本問題を解決する。

数学で言えば、公理系を最初に打ち立てて、そこから命題、定理、系を導くやり方に相当する。

僕はこの本を読んでいて、まるで過去に数学を研究していた時のことを思い出した。
数学のやり方はこういう社会科学、歴史学においても使えるのか、と改めてびっくりした。

この本を読んで、気づいた点はいくつかある。

【4】1つ目は、ミアシャイマーが提唱する理論「オフェンシブ・リアリズム」の結論は、国家は機会があれば覇権を求めて行動するので、世界は必ず対立し戦争が起こる。
ただし、その対立構造には、安定した二極世界、安定した多極世界、不安定な多極世界という種類がいくつかある。

【5】2つ目は、ポール・ケネディの「決定版 大国の興亡―1500年から2000年までの経済の変遷と軍事闘争〈上巻〉 | ポール ケネディ」の通り、国家の国力は、軍事力と経済力の2つであり、そのバランスが重要である、ということ。

【6】3つ目は、ハルフォード・マッキンダーが提唱した地政学の理論に似ているな、という点。

ランドパワー - Wikipedia

シーパワー - Wikipedia

オフェンシブ・リアリズムでは、覇権を求める国家はせいぜい地域覇権しか達成できない。
すると、今の世界地図から見れば、米国や英国のような海側から覇権国家を目指す国家と、ユーラシア大陸で覇権を求めるソ連、中国、ドイツ、フランスなどの国家に分別される。
基本は、大陸国家と海側国家の対決構造が必ずあるように思える。

ここで面白い点は、日本は海側国家の立場になり得たのに、実際は朝鮮半島や中国の一部を植民地化して大陸国家を目指そうとしていたことだ。
戦前の日本は、国際システム上では、当初は明治維新の後、西洋列強の植民地にならないように近代化を果たしたが、地域覇権を目指す方向に自然に活動し、最終的には、米国と戦争を起こすという自殺行為で最終的に破綻した。
「なぜ日本は無謀な戦争を決断して負けたのか」という問題は日本の歴史学でいつも問われるが、オフェンシブ・リアリズムの理論では「国際システム上では、国家は必ず覇権を求める行動を取らざるを得ないから、それから逃れることはできない」という結論になると思う。

また、ランドパワーとシーパワーの境目となる箇所がまさに紛争地になるのだろうなと思う。
だから、欧州大陸ではウクライナがNATOとロシアの中間地帯にあるし、朝鮮半島では、朝鮮半島の南部分はシーパワーである米国の影響力の配下にある、という例になるのだろうか。

【7】4つ目は、以前読んだウォルフレンの本「日本 権力構造の謎〈上〉 (ハヤカワ文庫NF) | カレル・ヴァン ウォルフレン」、ハラリの本「サピエンス全史セット【全2巻】 | ユヴァル・ノア・ハラリ」によく似ているな、と思った。

欧米人の歴史学や社会学の本はページ数が膨大で、その内容は非常にロジカルに書かれていて、自分たちの意見もはっきりしている。
しかも、その意見の正当性を示すために、大量の事例や事実を集めて補強しているし、反論されそうな内容は予め予想していてそれに対する反撃の意見と対症療法まで示している。

大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司でも、米国、英国、フランス、ドイツ、ソ連、日本、イタリアの過去200年間の歴史をふりかえり、膨大な事実を自分の意見の正しさの証明に使っている。
そして、こういうオフェンシブ・リアリズムのような、普通の人間にはあまり心地よくない理論の話には反論したくなるが、それに対して、自分の意見の正当性と正しさを説明するために膨大な文章を使ってロジカルに組み立てている。

僕はこういう本は好きだ。
読むのは割としんどいけれど、メモしながら、ロジックの流れを追いかけてみると、最初の5つの仮定から定理が導かれ、最終的な結論まできちんと抑えられているのが分かる。

論文作成の技法part1~論文の構造: プログラマの思索

論文作成の技法part2~論文作成の観点: プログラマの思索

【8】大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司では、最終章で「中国は平和に台頭できるか?」を設けて解説しているが、内容は悲観的だ。
まあ、オフェンシブ・リアリズムの立場ではそういう論理的な帰結になるだろうと思う。



| | コメント (0)

2022/03/20

マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか

渡辺さんのブログを読んで、マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのかどうか、という問題提起をしていると感じた。

アジャイルとマイクロサービスは最悪な組み合わせ - 設計者の発言

データモデリングで考えれば、サブシステム分割の単位は、CRUD操作で閉じるようにシステム分割すべき。
一方、マイクロサービスは僕の考えでは、外部インターフェイスの一つのアーキテクチャに過ぎないのに、ものすごいシステムアーキテクチャみたいな幻想があって、システム分割論と混同する開発者が多いのでは、と思う。

アジャイル開発というプロセスでは、特にスクラムでは、プロセスに特化していて、ソフトウェア技術や設計アーキテクチャの話はあえて避けていると思う。
だからこそ、スクラムという開発プロセスのフレームワークはIT業界のあらゆるプロジェクトに適用できるし、製造業など他の業界でも使われるようになった。
しかし、それですべての問題が解決できるわけではない。
実際、XPやScrumを生み出した人たちのキャリアを見ると、ソフトウェア開発の経験がとても豊富で、オブジェクト指向設計、テスト駆動開発、継続的インテグレーションなど数多くのベストプラクティスを生み出している。
彼らは技術的要素を軽視しているわけではない。

マイクロサービスはSaaSのようなWebシステムでは、外部インターフェイスの公開APIとして優れている技術と思うが、それですべての問題が解決できるわけでもないし、この辺りの技術の実装はとても難しいと個人的に思っている。
なぜなら、こちらが仕様を準備して想定しているような使い方を、外部APIを利用する人たちはしない時が多いとか、非機能要件のうち性能要件やセキュリティ要件の実現が非常にシビアだったり、割と罠が多いからだ。

この辺りの技術は色々考えてみたい。

| | コメント (0)

2022/02/02

諸問題を組織論に持っていくのは目的を手段化していないか

諸問題を組織論に持っていくのは目的を手段化していないかと気づいたのでメモ。

【参考】
(1) ひさてるさんさんはTwitterを使っています 「エンジニア意識高くなると組織論みたいなとこに興味出てくるのはそうなんだけど、技術とドメインにこだわることから離れてマネジメント手法こそが最優先みたいな思想を見ると、いくらアジャイルのプロセスなんだぞと言ってても、やはり人は大地から離れて生きていくことはできないのという気持ちになる」 / Twitter

(1) 杉本啓さんはTwitterを使っています 「本当にそう。組織論にかぶれると、あらゆることが組織の問題に見えてくる。コンサルティング会社にいたころ、同じプロジェクトにアサインされたコンサルタントに、問題構造分析で、すべての問題構造図で「根本の問題」の箇所に「組織が悪い」と書く人がいて、辟易した。 https://t.co/jNsklAq4a7」 / Twitter

(1) akipiiさんはTwitterを使っています 「チャンドラーの、組織は戦略に従うの経験則に、暗黙的に流れてるのだろうと思う。こういうビジネスが必要だと思っても、人や組織がマッチしてないじゃないか、と分かって、組織づくりばかりに専念してる感じかな?」 / Twitter

(1) 杉本啓さんはTwitterを使っています 「僕が、コンウェイの法則をあまり好きじゃないのも、この辺が遠因。」 / Twitter

DXとは組織論である」みたいな論調が最近はやたら多い。
確かにその傾向はあるだろう。
DXを実践するには、IT化した業務、ソフトウェアを基盤にしたビジネスモデルが必要だから、それを実行できる人や組織が必要だ。

しかし、その本質は、「組織は戦略に従う」というチャンドラーの経験則に過ぎないと考える。
なぜなら、DXを実現する経営戦略が先にあって、その戦略を実行できる組織が必要だよ、という事実が、たぶん、どこにでも普遍的に見られるだけだからだ。

だから、色んな諸問題を組織が悪いから実行できないのだ、だから組織を何とか変えよう、という動きに進んで、それが自己目的化していないだろうか?
本来は戦略を実行するのが目的なのに、組織を変えることが目的化してしまっている、みたいな場合が日本では割と多いのではないか。

そして、なぜ、色んな諸問題を組織が悪いから実行できないのだ、という論点にすり替わってしまうのか、という問題の原因も見えてくる。

実は、「組織(構造)は戦略に従う」というチャンドラーの経験則とは逆に、「戦略は組織(文化)に従う」というアンゾフの経験則がある。
たぶん、会社の偉い人が意思決定した戦略に社員を従わせたいのに、実際はうまく行かない原因は、社員が従わないからだ。
それは組織文化にあるからだ、ということなのだろう。
特に官僚組織では、その組織形態そのものがなかなか変わらないので、長年の慣行が組織文化として固まってしまう場合が多いだろう。

野中郁次郎先生の「失敗の本質」を読むと、日本人は、「組織(構造)は戦略に従う」「戦略は組織(文化)に従う」という経験則に振り回されているような印象を受ける。
本来は、組織は戦略を実行するための仕組みの一つに過ぎないのに、その仕組が暴走自動車みたいにハンドル操作が効かなくなり、勝手にあらぬ方向へアクセルを踏んで自爆した、みたいな感じ。

一方、特に米国のMBAの参考図書に上がっている組織人事論の本とか読んでいると、彼らは、組織を動かすための能力やスキルへ抽象化して、誰もが身につけられる普遍スキルに仕上げているように思える。
リーダーシップ論などは特にそう思う。

| | コメント (0)

より以前の記事一覧