ソフトウェアアーキテクチャとサッカーにおけるプレーモデル
共通イメージ
最近、ワールドカップシーズンのみのにわかサッカーファンとして、色々な動画やら、本やらを読んでいた。
本の中で、「プレーモデル」という言葉がでてくる。ようするに、プレーについての監督、選手が共有する、どう戦い、何をすべきかの共通イメージである。複雑系スポーツであるサッカーでは、コンビネーションの秩序を得るためにプレーモデル、という共通イメージが必要ということだ。
ここから発想したこと
多分、サッカーでプレーモデルとされているのは、チームとしてどうプレーするのかの共通理解。
— 松下正嗣 (@masatsugumatsus) 2018年7月14日
ソフトウェア開発においては、多分、
ソフトウェアアーキテクチャ
プロセスモデル
のふたつがそれに該当すると思う。
つらつら書いてく
ソフトウェアアーキテクチャとは
ソフトウェアアーキテクチャの定義としては、色々IEEEとかの定義があるが、
個人的にはあまり、有用と思えない。不正確とも思わないけど、「So What?」な定義になっている。実際に仕事するとき、自分が念頭に置いているのは、マーチン・ファウラーが『エンタープライズアーキテクチャパターン』で記載した、Ralph Jonson(デザインパターンのGang Of Four の一人?)の言葉
アーキテクチャとは、主観的要素であり、プロジェクト内の熟練開発者がシステム設計に関して共通して理解していることに過ぎない。
ファウラーはこれに加えて、「変更しにくい」「重要なもの」という要素を何となく付け加えている。
つまり
アーキテクチャとは
- 主観的要素であり
- 熟練の
- 開発者たちが共通して理解している
- システム設計についての事柄で
- 変更しにくく
- 重要なもの
である。
個人的には、
「熟練の」というのは不要。古い大規模開発とかだと、プログラマにアーキテクチャについての理解を求めない場合もあったかもだけど、現在の規模やプロセスでそれを区別する意味はない。
「変更しにくく」も不要。今のエンジニアリングではほとんどのものが変更容易になっている。もし変更しにくいのは、多くの開発者の「共通して理解」していることだからだとおもう。
「重要なもの」も不要。共通理解が重要である、てこと以上のものはないと思う。
また、「システム設計」には当然プログラミングも含む。
だから、個人的な定義はアーキテクチャとは
アーキテクチャとは、主観的要素であり、チーム内の開発者が、システム設計/プログラミングに関して共通して理解している事柄
である。
これはサッカーにおけるプレーモデルの概念ととても近いと思う。
ソフトウェアアーキテクチャは何のために定義するのか
ソフトウェアアーキテクチャは何のためにあるのか。ここで、サッカーにおけるプレーモデルの概念が参考になる。
ボール 保持 者 と その 味方 が お互い の こと を 理解 し、「 この 選手 は ここ で ボール を 受け て 壁 パス を したがっ て いる」 という よう に、 味方 の 次 の プレー を わかっ て いれ ば、 動き出し も 早く なる はず です。
この よう に し て 共通 の イメージ を 持つ こと で、 息 の 合っ た コンビネーション プレー が 実現 する の です。 少ない タッチ 数、 特に 1 タッチ での コンビネーション プレー という のは、 どんなに 緻密 に 形成 さ れ た 守備 組織 で あっ ても 突破 する こと が 可能 です。 チーム という のは 選手 の 集まり で 形成 さ れ、 各 選手 は お互い の 性格 や 考え方 を 理解 し て いる 方 が よく 機能 する の です。
坪井 健太郎. サッカーの新しい教科書 戦術とは問題を解決する行為である (Kindle の位置No.179-187). . Kindle 版.
つまり、共通イメージをもつことでコンビネーションが促進される。また、意思決定を柔軟に、素早く行う効果もある。
また、ソフトウェアは開発し始めたばかりのときは、設計の選択肢は無限にある。だから制約を見つけることは開発の障害であるよりは、より考えることを絞り込めるため、開発を促進する。
制約は味方である。G.M.ワインバーグ
ソフトウェアアーキテクチャ定義、アーキテクティングとは、変化していく要求に対応して開発を駆動していくために、設計とプログラミングにおけるチーム内での共通理解を作り上げ、維持、変更していく行為なのだと思う。
どんなものがソフトウェアアーキテクチャなのか
ソフトウェアアーキテクチャの例として挙げられるのは、論理的に演繹できるもの、というよりは、経験的に、共有していた方がよいとされる認識のあつまり、なのだと思う。
例えば、
- 物理/論理構成
- 採用するフレームワーク
- 採用するコンポーネント分割指針(モノリシックか、マイクロサービスか、MVC、DDDなどのパターンをどのように取り入れるか、など)
- コーディングガイドライン
- テスト戦略
例えば、RDBのテーブル構造を「技術的詳細」としてアプリケーションから隠ぺいするのか、それとも、アプリのモデルとして扱うのか、といった見立てと判断も含むと思う。
これらは文書化されることもあれば、フレームワークやツール上に実装されることもある。文書化されず、文化として保持される場合もあるとは思う。
もちろん、これらを共有するためには一定水準の共通知識が必要。スペインのサッカーでは、プレーモデルを実現する前提として、様々な概念、知識(サッカーの教科書)が育成年代からトレーニングを通じてインストールされているという。
ソフトウェア開発でも同じで、アーキテクチャを理解するための基礎知識は必要なんだろうな。それがあると、個別具体的な状況に合わせた対応ができる。
チーム外のステークホルダーとアーキテクチャ
伝統的なアーキテクチャの考え方として、チームやプロジェクト外のステークホルダーとの合意が重要とされることがある。自分の定義だとその観点はでてこない。ただ、別に普通のシステムに対する要求事項として扱えばよいと思うので定義を変える必要はない。
どうせ、ステークホルダーがレビューしたり、合意したりする場合はそれ向けのドキュメントなりを提示しなければならない。
追記
どんなものがアーキテクチャでないか
- 開発者に認知されないドキュメント
- 個別機能の設計やプログラミングを助けない制約
- 共有する必要のない、一部機能やコンポーネントの詳細
追記
フレデリック・ブルックスのアーキテククチャの定義
- 利用者に知覚される製品の定義
つまり、そのシステム/ソフトウェアとはなんであるか、のイメージ。アーキテクチャは実装ではない。
Jim Coplien氏の認定スクラムマスター研修に行ってきた
アギレルゴコンサルティング社主催の7月2日〜3日に実施されたJim Coplien氏の認定スクラムマスター研修に行ってきた。
認定制度には懐疑的なんだけど、個人的にJim Coplien氏の本は好みのものが多く、彼のスクラム・パターンの研修を受けて非常に感銘を受けたので、今回認定スクラムマスター研修に行ってきた。
以下は面白かった点の備忘録。自分の貧弱な英語で通訳なしで聞いた結果なので聞き間違いや、勘違いもあるかも。(通訳は提供されてたが、自分は使わなかった。)
また、色々主張は強いが、質疑応答などでも現場のコンテキストを尊重する姿勢があった。機械的にこうやれ、と言っているわけではないとおもう。高みを目指すなら正しいのは、こっちだ!という主張と理解している。
- スクラムアライアンスとスクラムを一緒にするな
- 開発マネージャーというのはない。チームがやる。マネージャの仕事は部署間調整などチームが働く環境を整えること、そして大幅な組織改革「カイカク」をやる。チームがやるのは「カイゼン」
- 基盤となるようなビジネス要求というのは、実は安定している。変化するのは要求の理解である。
- ユーザストーリーはバックログに入れるものではない。バックログに入れるのは、要求/機能、技術、課題である。ユーザストーリーは要求を理解するためのコミュニケーションに使うもの。
- JIRAのようなバグトラッカーは無駄である。バグはすぐ直す。バックログ管理は簡単なExcelシートで充分。
- 研修のようなものもバックログに入れる。そうでないとチームから時間を奪うことになる
- ユニットテストは無駄。システムテストは無駄だけど、現時点では必要
- 完了は完了(DONE is DONE)。それ以上やることがないこと。リファクタリング、文書作成、システムテスト、性能テスト、デプロイ。全部終えて完了。POと合意する。
- 信頼を築くには、まず、自分から信頼すること。
- 心理的安全性は単なる結果。パーソナルな問題も持ち込んでいい。もし、心理的安全性を保つために、パーソナルな問題に踏み込まなかったり、壁を作っているような場合、それは病んでいるってことじゃないの?信頼が大事。
- デイリースクラムでは、ペットが死んだ、みたいなものも共有して良い。開発の障害は全て。スクラムは全体性。仕事と個人を分ける必要ない。
- チームがコミットするのはスプリントゴール。スプリントゴールによって、一体感を醸成する。
- POが出してきた要求にもチャレンジすることが大事
- アジャイルコーチを雇っても、開発チームと接触しない。スクラムマスターに対してコーチングする。(どこまで強い主張かは不明)
- スプリント毎の振り返りでは、浅い振り返りになる。年に3日とか使ってしっかりと振り返りをして改革につなげたりする。
- ベロシティなども統計的に管理する。一度ブレただけで次の予測を変える必要はない。3スプリント連続で変わったりするなら再考必要
前から思っていたけど、POの役割が死活的に重要と改めて感じた。製品ビジョンを持ち、製品機能を定義し、ROIを想定しながら、順位付けをしていく。開発者の助けを借りて、やるのだけど、かなり技術にカンが働かなければ難しいとは思う。そもそも、トヨタのチーフ「エンジニア」の役回りの一部らしいので。
講師によっては、開発者が考える、と割り切って伝えている場合もあるようだ。
coplienさんは、はっきりとは確認してないけど、基本的には開発者の助けを借りて、POが書く立場と思う(開発者も含めたステークホルダーは追記できはする)。プロトタイプを開発チームに渡して説明したりする、ということも言っていた。
ロールを全うするには、個人的には、ROIに責任もてない開発者がとやかくいうのではなく、POチーム側にエンジニアリングがある程度分かる人が入ったりする必要があるんではないか、と思った。
最後まで、内製チームを想定しているみたいだったな。受託でやるときは、顧客側がPOチームにバックログアイテムの検討を支援するエンジニア/コンサルタントを、開発チームと別契約で結んで支援してもらえばいい、と思った。コンサルティング契約とかと似たようなもの。スクラムマスターは開発チームが必要に応じて連れてくればよい。
追記①----
- 多分、スプリントプランニングの時と思うけど、3本指テストでPBIをやり切れるか、の自信を試すといい。
追記②----
上に引用したブログによると、POは顧客ではなく、開発者の組織がやり、チームのROIに責任をもつ、とある。正直、自分には「チームのROI」の意味が理解できないし、プロダクトを実際に利用する顧客ビジネスのROIがスクラムのプロセスの中のどこで考慮されるのかが、分からないから、それはbad ideaじゃないかな、と思っている。
とはいえ、それで上手くいく場合も絶対あると思う。というか、そのほうが上手くいくことがほとんどかも。実際、スクラムじゃなくても、SIとかでは、顧客が考えられない場合、製品ビジョンは開発者側が考えちゃったほうが上手くいくこと多いと思う。全体的にくだんの講師のかたは現実解みたいなものを伝えている気がする。
でも、個人的にはそれには限界があると思うので、やはり高みを目指すなら、ということ。
追記③----
coplienさんから回答が来た!
Great post! You are right — the developers help the PO with the tests, as they might help her with everything. But the PO does most of the work specifying the tests and has the final word on what end-user functionality to test and what the results should be.
— James Coplien (@jcoplien) 2018年7月7日
以下翻訳。
開発者は他のあらゆる面でPOを支援するのと同様に、テストによってPOを支援する。でも、どんなテストを実施するのか、を特定するためのほとんどの作業をPO自身が行う。そして、POがテストすべきエンドユーザー向けの機能とその機能が何をもたらすか、についての最終決定権を持っている。
google翻訳で読んだのかな?もしくはまだ、日本にいるから、誰かに訳してもらったのかも。
追記④----
ユニットテストが無駄である旨の記事
https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
上記記事のからの引用
• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.
回帰テストは続けろ。でも、そのほとんどはユニットテストではなく、システムレベルのテストだ。
• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.
広範性、形式性、独立性、正確さがあり、ビジネス価値に帰結する中心的なアルゴリズムに関してはユニットテストを維持しろ
(ビジネスルールのアルゴリズムとか?)
• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system
test — context is everything.
上記以外の場合、そのコードがビジネス価値を持ち、システムテストでもユニットテストでもテストできるのなら、システムテストを採用しろ。コンテキストが全てだ。
• Design a test with more care than you design the code.
プロダクトコードをデザインするより注意深くテストをデザインしろ
• Turn most unit tests into assertions.
• Throw away tests that haven’t failed in a year.
1年間テストして、失敗しなかったテストは捨てろ
• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth
テストはよい開発を置き換えたりはできない。高い失敗テストの比率は、開発のサイクルを短くするべきであることを示している。さらに、根本的には、アーキテクチャと設計に改善の余地が大いにあることを確証している。
• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.
もし、テストされた関数が些細なものであったなら、開発者をどのように動機付けしているのかを厳重にチェックしろ。カバレッジやその他の無意味なメトリクスはアーキテクチャを劣化させる。
• Be humble about what tests can achieve. Tests don’t improve
quality: developers do.
テストが達成できることに謙虚になれ。テストは品質を向上させない。それは開発者しかできない。
IntelliJ IDEAハンズオン に行ってきた
こちらにいってきた。
仕事で使っているわけではなく、個人用に有償版を何年か前から購入させてもらっていたのだけど、使いこなせている感が全くなかったので参加。ツールを追求するのは苦手。。。
仕事ではEclipseだけど、使いこなせている感覚はない。。。
当日のカリキュラム
・JetBrains社の紹介
・製品紹介
・TeamCity/Upsource/YouTrackなどのチーム開発製品の紹介
・各種開発ツール
・ハンズオン
・キーマップなどの初期設定
・ショートカットと補完機能をフル活用したFizzBizz
・デバッグ機能
・Git
・クーポンなど
・質疑応答
注意点
感想その他
・チーム開発のツールは少人数なら無料みたいなので必要なら積極的につかってみたらよさそう。Upsourceがよさそう。
・コード補完機能は、変数の宣言と初期化が「値.var」「変数.if」や条件式.notでコード生成したり、条件式変更してもらえたり、これは、全く知らなかった。。。流れるようにコーディングできて、使いこなすと生産性がかなり変わりそうな印象。
・デバッグ機能は、Eclipseでも使いこなしていなかったけど、実際に目の前でデモしてもらうと分かりやすかた。
※特定の条件でのみブレークポイントで止まるって機能、Eclipseにあったっけ。。。
・有償のChrononデバッガーがインストール可能なのでそれも使える、とのこと。業務ではまったときとかは使えそう。
Chronon Time Travelling Debugger | Chronon
・Gitの機能もほとんど使ってなかったのでやくだった。一部だけコミットしておくとかって結構使えそう。
結論
・時間は金で買える。
・そして、使いこなすのに時間を使うくらいなら、ハンズオン依頼しちゃうのがいいと思った。
コインチェック盗難事件とソフトウェアの複雑性
tweetをまとめる。
事件の経緯
第一報?
会社と社長について
自分のtweet
コインチェックの仮想通貨盗難事件。推奨されてたセキュリティ対策取らずにやられるってお粗末だな、と思い、CEOがあんま技術わかんない人なのかな、と思ったけど、結構エンジニア出身っぽい。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
ただ、盗難事件、これ以前にも会社で起きてたらしいので、セキュリティに問題ある、って気づくチャンスはあった。ここら辺は力の入れどころ間違ってるって意味で経営責任あるよなあ。この会社は他の通貨もリスクあると思う。少なくともハッカーに狙われているんだろうし。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
記者会見
会見読んで
セキュリティ、恐らく段階的に、やれる範囲で段階的にってことだったってことか。エンジニアの人がプロダクトデザインとか開発を見て、No2がマネジメントやる、って個人的には理想の組み合わせと思う。だからここまでうまくいっていたんだろうな。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
思ったほど記者のひどい質問は多くはなかった。ただ、やらかしちゃって怯えている若者に高圧的に出られる人って友達にはなりたくないな、とは思う。もっと知識を持った記者が入れば良い質問が出ただろう、とは思う。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
セキュリティどこまで杜撰だったかは内部分かんないから判断できないが、個人的には、扱う通貨の種類が他と比べて多すぎるのが判断ミスと思う。強みにしようとしたんだろうけど、リスクが大きすぎる。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
ベンチャーで開発を担う中心人物(CEO)がビジネスの根幹であるセキュリティ対策がどこまで進んでいるのかをリアルタイムに把握できてないほどシステムが複雑化してしまっている。その時点で制御不能に陥っていると言ってもいいと思う。起こるべくして起きた。 https://t.co/DqOqpNA83z
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
SIとかで開発する時は、基本、利用するプロトコル/方式や外部接続先は縛り、少数の専門家がセキュリティリスク含めて把握できる状態を維持すると思う。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
よく知らないが、仮想通貨の場合、複雑な通信方式があるんだろうし、対策の恒常的なアップデートがあったりするように思う。
複雑さが制御不能なレベルにまで増加しないような枠組みを作るのがソフトウェアエンジニアリングの基本。ITサービス、特にFinTechのビジネスをやるときも結構気をつけなればいけないんだなあ、というのが今回の教訓の一つ。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
セキュリティ対策が把握できてない段階で、問題だとを認識できたら、人気のない通貨の取り扱いをやめる、みたいな対応も考えられる。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
そこから考えたこと
「この人に聞けば分かる」を解決策として採用している場合、気をつけなければならないのは、「この人」の頭脳を超える複雑さを組織は扱えない、ということ。
— 松下正嗣 (@masatsugumatsus) 2018年1月26日
CEO、どう考えても優秀な人だと思う。こういう未熟さは年の功がないとどうにもできない。わきの甘さは後付けで何とでもいえるけど、周囲のおっさん/おばさんもいいアドバイスができなかったんだと思う。
追記
当初の仕様からマルチシグ使うようになってたけどやってなかったのが本当ならちとひどいかな。。。https://t.co/TN7XQdqs2I
— 松下正嗣 (@masatsugumatsus) 2018年1月27日
追記2
返金する方針らしい。興味を失ったので、続きは書かない。
書評『現場で役立つシステム設計の原則』
下記の本のレビュー記事。
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
内容
特定の理論や手法を説明したものではなく、それらをどのように組み合わせていけば、変更が楽で品質の高いシステムを開発できるのか、って問いに答えるオブジェクト指向アプリケーション開発の秘伝の書。
基盤となっているのは
- ドメイン駆動設計
- Thoutworks流のオブジェクト指向開発(マイクロサービスアーキテクチャ含む)
- XP(エクストリームプログラミング)
- データモデリング(リレーショナルモデル)
あたり
感想
最初の雑感
とにかく様々なことを勉強した上で、現場の実践で考え抜かれ、蒸留されたノウハウが詰め込まれている。ありがとうございます、としかいいようがない。本当に使えるノウハウが体系的に整理されている。
教育コンテンツとしても完成度がめちゃめちゃ高い。前提知識をほとんど要求しないので、Javaなどの静的オブジェクト指向言語とデータベースの入門書レベルをしっかり理解している人ならそれなりに理解できるように記述されている。語られている範囲が広いのに、ボリュームも少なく、頭に自然に入ってくる。これは驚異的。相当推敲を繰り返したんではないか。
古い設計理論や開発プロセスも踏まえて語られているので、昔ながらのSIの現場にも伝わる内容になっている。そして、伝統的なやり方がなぜだめなのか、どうすればうまくいくのか、がしっかりと書かれている。あとは現場で考えてね!で逃げないのって本当にすごく難易度が高い。
誰向けか
若手~ベテランまで広くお勧め。そして、SIのマネジメント層に読んでほしい。
ドメイン駆動設計との関係
エヴァンスのドメイン駆動設計にある、Entity(エンティティ)やAggregate(集約)みたいな重要なものが語られていない。これは、実は重要でない、というか、意識して作らなくてもいいんでないか、という主張なのではないか、と自分は思っている。エヴァンズのドメイン駆動設計のアップデート。だから、エヴァンスのドメイン駆動設計を知りたかったら、やっぱり原典に当たったほうが良いかと思う。
プロセス
アジャイルのような反復開発でどのように開発を進めていくのか、ということも書かれている。重要なところに当たりをつけて部品を作っていって全体をくみ上げるってのがオブジェクト指向開発、とな。。こういうのが明確に語られている本は記憶にないなあ。
そして、これはScrumみたいのを形式的に適用したらオブジェクト指向開発はうまくいかないってことになるんだよね。バックログがPO任せだと、POのやりたいことが順番に降ってくるだけ。ウォーターフォールと大差なくなってしまう。
画面とデータベースに真っ向から取り組んでいるのがいい
従来の教科書的なオブジェクト指向設計の話だと画面設計やデータベース設計と絡めて語られることがほとんどなくて、現場で一番苦労するのがそこだったりするので、
「オブジェクト指向使えない」
みたいなことになってたような気がする。
この本では、画面とデータベースという、コードを汚くする2大源泉に真っ向から取り組んで、成功しているように思える。そのブレークスルーの源は「ドメインオブジェクトの主役は値オブジェクトのようなスモールオブジェクト」って洞察だと思う。
読んでなるほどーと思ったとこ
なんとなくもやもやしてたけど、明確になった。
まだもやもやしているとこ
- 小さいWebAPI→性能大丈夫か??
- メッセージ文字列をドメインオブジェクトに直書き→国際化とかは?メッセージ一覧ほしくならないのかな?
書いてないけど、書かなくていいと思っていること
書いてほしかったこと
- テスト→多分、ユニットテストの重要性は小さくなっているはず。メンテもつらいし。開発の中でどうテストし、モデルの成長に合わせてメンテしていくのか、って話をちょっとだけでも書いてほしかった。
プログラミング初心者にはGoがいいんではないか、という話
心理学的ワークショップを組織でやるときに注意すべきこと
コミュニケーショントレーングやリーダーシップ開発、組織開発で、瞑想や深い内省を促すワークを取り入れる場合がある。
昔の感受性トレーニングなんかでは、色々事故も起こっているのでそれなりにリスクある。けど、うまく設計すれば、コミュニケーションの取り方や対人関係構築力、指導力なんかが劇的に向上することもあるので、それなりには各企業で取り入れられている。
最低限注意すべきこととしてはこんなのがあると思う。
- ワークへの参加を拒否する権利を認める。
- グループへシェアするのは自分の判断でシェアすることを強調する。
変な自己啓発セミナー紛いのワークショップだと、トラウマみたいのをシェアするのをファシリテータが強制したり、促したりすることがあるけど、そういうのははっきり言ってろくなもんじゃない。ファシリテータは出てきた時は受け止める必要あるけど、そうした上で、そういうセンシティブなコンテンツに過剰な重要性を持たせない方がいいと思う。