ソフトウェアアーキテクチャとサッカーにおけるプレーモデル
共通イメージ
最近、ワールドカップシーズンのみのにわかサッカーファンとして、色々な動画やら、本やらを読んでいた。
本の中で、「プレーモデル」という言葉がでてくる。ようするに、プレーについての監督、選手が共有する、どう戦い、何をすべきかの共通イメージである。複雑系スポーツであるサッカーでは、コンビネーションの秩序を得るためにプレーモデル、という共通イメージが必要ということだ。
ここから発想したこと
多分、サッカーでプレーモデルとされているのは、チームとしてどうプレーするのかの共通理解。
— 松下正嗣 (@masatsugumatsus) 2018年7月14日
ソフトウェア開発においては、多分、
ソフトウェアアーキテクチャ
プロセスモデル
のふたつがそれに該当すると思う。
つらつら書いてく
ソフトウェアアーキテクチャとは
ソフトウェアアーキテクチャの定義としては、色々IEEEとかの定義があるが、
個人的にはあまり、有用と思えない。不正確とも思わないけど、「So What?」な定義になっている。実際に仕事するとき、自分が念頭に置いているのは、マーチン・ファウラーが『エンタープライズアーキテクチャパターン』で記載した、Ralph Jonson(デザインパターンのGang Of Four の一人？)の言葉
アーキテクチャとは、主観的要素であり、プロジェクト内の熟練開発者がシステム設計に関して共通して理解していることに過ぎない。
ファウラーはこれに加えて、「変更しにくい」「重要なもの」という要素を何となく付け加えている。
つまり
アーキテクチャとは
- 主観的要素であり
- 熟練の
- 開発者たちが共通して理解している
- システム設計についての事柄で
- 変更しにくく
- 重要なもの
である。
個人的には、
「熟練の」というのは不要。古い大規模開発とかだと、プログラマにアーキテクチャについての理解を求めない場合もあったかもだけど、現在の規模やプロセスでそれを区別する意味はない。
「変更しにくく」も不要。今のエンジニアリングではほとんどのものが変更容易になっている。もし変更しにくいのは、多くの開発者の「共通して理解」していることだからだとおもう。
「重要なもの」も不要。共通理解が重要である、てこと以上のものはないと思う。
また、「システム設計」には当然プログラミングも含む。
だから、個人的な定義はアーキテクチャとは
アーキテクチャとは、主観的要素であり、チーム内の開発者が、システム設計/プログラミングに関して共通して理解している事柄
である。
これはサッカーにおけるプレーモデルの概念ととても近いと思う。
ソフトウェアアーキテクチャは何のために定義するのか
ソフトウェアアーキテクチャは何のためにあるのか。ここで、サッカーにおけるプレーモデルの概念が参考になる。
ボール 保持 者 と その 味方 が お互い の こと を 理解 し、「 この 選手 は ここ で ボール を 受け て 壁 パス を したがっ て いる」 という よう に、 味方 の 次 の プレー を わかっ て いれ ば、 動き出し も 早く なる はず です。
この よう に し て 共通 の イメージ を 持つ こと で、 息 の 合っ た コンビネーション プレー が 実現 する の です。 少ない タッチ 数、 特に １ タッチ での コンビネーション プレー という のは、 どんなに 緻密 に 形成 さ れ た 守備 組織 で あっ ても 突破 する こと が 可能 です。 チーム という のは 選手 の 集まり で 形成 さ れ、 各 選手 は お互い の 性格 や 考え方 を 理解 し て いる 方 が よく 機能 する の です。
坪井 健太郎. サッカーの新しい教科書 戦術とは問題を解決する行為である (Kindle の位置No.179-187). . Kindle 版.
つまり、共通イメージをもつことでコンビネーションが促進される。また、意思決定を柔軟に、素早く行う効果もある。
また、ソフトウェアは開発し始めたばかりのときは、設計の選択肢は無限にある。だから制約を見つけることは開発の障害であるよりは、より考えることを絞り込めるため、開発を促進する。
制約は味方である。G.M.ワインバーグ
ソフトウェアアーキテクチャ定義、アーキテクティングとは、変化していく要求に対応して開発を駆動していくために、設計とプログラミングにおけるチーム内での共通理解を作り上げ、維持、変更していく行為なのだと思う。
どんなものがソフトウェアアーキテクチャなのか
ソフトウェアアーキテクチャの例として挙げられるのは、論理的に演繹できるもの、というよりは、経験的に、共有していた方がよいとされる認識のあつまり、なのだと思う。
例えば、
- 物理/論理構成
- 採用するフレームワーク
- 採用するコンポーネント分割指針（モノリシックか、マイクロサービスか、MVC、DDDなどのパターンをどのように取り入れるか、など）
- コーディングガイドライン
- テスト戦略
例えば、RDBのテーブル構造を「技術的詳細」としてアプリケーションから隠ぺいするのか、それとも、アプリのモデルとして扱うのか、といった見立てと判断も含むと思う。
これらは文書化されることもあれば、フレームワークやツール上に実装されることもある。文書化されず、文化として保持される場合もあるとは思う。
もちろん、これらを共有するためには一定水準の共通知識が必要。スペインのサッカーでは、プレーモデルを実現する前提として、様々な概念、知識（サッカーの教科書）が育成年代からトレーニングを通じてインストールされているという。
ソフトウェア開発でも同じで、アーキテクチャを理解するための基礎知識は必要なんだろうな。それがあると、個別具体的な状況に合わせた対応ができる。
チーム外のステークホルダーとアーキテクチャ
伝統的なアーキテクチャの考え方として、チームやプロジェクト外のステークホルダーとの合意が重要とされることがある。自分の定義だとその観点はでてこない。ただ、別に普通のシステムに対する要求事項として扱えばよいと思うので定義を変える必要はない。
どうせ、ステークホルダーがレビューしたり、合意したりする場合はそれ向けのドキュメントなりを提示しなければならない。
追記
どんなものがアーキテクチャでないか
- 開発者に認知されないドキュメント
- 個別機能の設計やプログラミングを助けない制約
- 共有する必要のない、一部機能やコンポーネントの詳細
追記
フレデリック・ブルックスのアーキテククチャの定義
- 利用者に知覚される製品の定義
つまり、そのシステム/ソフトウェアとはなんであるか、のイメージ。アーキテクチャは実装ではない。
