形の合成に関するノート/都市はツリーではない
2019-11-25 発売
snoozer05 による邦訳
2020-01-02 にガッと読んだ
>本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。
平鍋健児さんの文章だ！
BDUF って呼ぶのか。
>第III部には、アーキテクトがチームに向けて彫った石版は出てこない。出てくるのは、週単位のイテレーションに適したアクティビティやチームが設計の主導権を持つことを奨励するアクティビティ、そして設計をチームの第一級の関心事へと押し上げるアクティビティだ。これらの手法を実際に適用しているチームの写真も見ることができる。
>本書では、デザイン思考と人間中心手法を使い、チームと協力してソフトウェアアーキテクチャを設計していく方法を学ん でいく。このアーキテクチャ設計のアプローチは、設計判断とその判断の影響を受ける人々との結びつきを強固なものにするのに役立つ。人を第一義に考えることで、より良い設計判断が可能となり、その結果、より優れたソフトウェアを作ることができるようになる。
>銀の弾丸はない。しかし、ソフトウェアエンジニアであれば誰もが、素晴らしいソフトウェアを届けるためのプラクティスや手法、テクニックでいっぱいの銀の道具箱を持っいるものだ。第III部で紹介しているものは、いずれも私自身の銀の道具箱にあるものだ。それらを共有できることを光栄に思う。
銀の道具箱、かわいい。
>技術的負債とは、ソフトウェアシステムの現在の設計と、継続的に価値を届け続けるために必要な設計との差分のことだ。技術的負債の量は、その差を埋めるのに必要な労力を見積もることで計測できる。すべてのソフトウェアには技術的負債がある。 技術的負債は、成功のための必然的な副産物だからだ。優れたソフトウェア開発チー ムは機能を素早くリリースするために技術的負債を戦略的に利用する。そして、時を経ても価値を届け続けられるよう、定期的にその負債を返済する。
>品質特性とは、ステークホルダーがソフトウェアシステムの良さを判断するための、外部から見える特徴だ。それには、たとえば拡張容易性や可用性、保守性、テスト容易性などが含まれる。人は、ソフトウェアとやり取りする際に、必ず何らかの品質特性を体験している。
>忘れてはならないのは、ソフトウェアアーキテクトとは、単なるチームの役割だけではなく、心の持ち方だということだ。プログラマーとして開発に取り組んでいるとき、あなたは毎日何十もの設計判断を行なっている。これらの判断の中には、アーキテクチャに対して大きな影響を与えるものもある。ソフトウェアシステムの構造に影響を与える決定を行う人であれば、誰しもがアーキテクト代行だ。
ここで「デザイン思考」の話が出てくる。
>頭文字をとって「HART」と名付けよう。
「HRT」もハートって読むんだっけね。
>設計とは本質的に人間中心の取り組みだ。私たちは人のためにソフトウェアを設計する。そして、人と共に設計する。アーキテクチャにおけるあらゆる設計判断は、何らかの形で誰かの力になるものだ。すべての設計判断は、他の人々に理解され、共有されなければならない。
>Ruth Malan と Dana Bredemeyer は論文「Less is more with minimalist architecture」MB02 において、アーキテクトは必要最小限のアーキテクチャ(Minimalist Architecture)を設計すべきだと提案している。
>『パタン・ランゲージ』で、Christopher Alexander らは、253 以上にわたる土木工学の問題をよく知られた解決策と共にカタログ化した。取り上げている内容は、建築資材からコミュニティ組織のテクニック、建物の構造まで多岐にわたる。
ぼくらは何度でも Christopher Alexander の足跡と出会ってしまう。
>ソフトウェアアーキテクチャを設計する際には、新しい何かを設計するよりも、既存の設計を洗練させることに、より多くの時間を費やすことになる。以前からあるソフトウェアシステムを無視するというのは、アーキテクチャを設計する際に最も効果が薄いやり方だ。
>アーキテクチャをタンジブルにする方法には色々なものがある。アーキテクチャを図に描く、アーキテクチャをコードの中で生き生きと表現する、構造や品質特性を体験できるようなプロトタイプを構築する、アーキテクチャの一部がどう機能するかを示す簡単なモデルを作成する、関連するメタファーを作成する、システムの制御フローの一部を身ぶりで伝える、などだ。
>ソフトウェアシステムを設計する際は、異なるデザインマインドセットの観点からアーキテクチャについて考える必要がある。デザインマインドセットとは世界について考える方法だ。それによって、適切なタイミングで適切な詳細に意識を集中させることができる。
この 4 つ組は PDCA っぽさも感じる。
>ソフトウェアシステムに完成はない。ただリリースされるだけだ。ソフトウェアが決して完成しないのだから、私たちの設計アプローチにも終わりはない。既存の設計に手を加える場合でも、新しいものを作成する場合でも、アーキテクチャの一部を再考する必要があるときには、いつでも同様のアプローチを適用する。
>Christopher Alexander は「形の合成に関するノート」の中で、問題が常に解決策を念頭において定義されることを論じている。
形の合成に関するノート/都市はツリーではないにリンクしておこう。
ここでは「スイートスポット」というフレーズが繰り返される。
>George Fairbanks は『Just Enough Software Architecture: A Risk-Driven Approach』の中で、アーキテクチャがシステムにおける最大のリスク要因でなくなるまで、アーキテクトは技術的リスクを減らすように取り組むべきだと語っている。
>実際には、それぞれのステークホルダーが 1 人だけということは滅多にない。そのことを際立たせるため、私たちはステークホルダーグループという用語を使う。グループとうまくやるというのは、個人とうまくやることとは異なる。同じステークホルダーグループにいる二人が矛盾した情報や競合する情報を提供してくる可能性もある。そのため、私たちはグループ全体の関心事を理解し、時には彼らの合意形成を手助けするように務める必要がある。
コラムの中で「顧客体験アーキテクチャ」という力強いフレーズが登場する。
>あなたのチームがどのように組織され、どんな協働の仕方を好むかは、アーキテクチャ設計に影響を与える。1967 年に Melvin Conway によって考案され、Fred Brooks の『人月の神話』によって広められたコンウェイの法則は、チーム組織とアーキテクチャの関係を説明している。
>アーキテクチャにおける重要な要求を特定したら、それらを ASR(アーキテクチャ上の重要な要求)ワークブックに記録しよう。新しいソフトウェアシステムの始まりでは、ASR ワークブックは生きたドキュメントであり、急速に変化していく。アーキテクチャがまとまるにつれ、ワークブックを編集する頻度は少なくなる。しかし、逆に参照の頻度は高くなっていく。ドキュメントは重要な歴史的記録として残るが、最終的には、実行可能なテストやソースが真の情報源として ASR ワークブックの一部に取って代わる可能性はある。
>要求ワークショップの数日後、あなたは数人のステークホルダーと品質特性に関する小さなワークショップを開催する。ワークショップでは、およそ 240 個の品質特性シナリオを引き出し、優先順位をつける。ワークショップで発生したすべての懸念事項を正式に記録するわけではないものの、参加者と協力し、優先度の高い上位 7 つのシナリオを洗練させる。
さらっと書いてあるけれど、ソフトウェア開発プロセスにまつわる重要な示唆を含んだ文章だと思う。ワークショップを実施したり、あれこれ発見したり、そういった体験を経て「(要求定義なんてとうに終わっていて) 設計もけっこう進んできた」と思う人と「だんだんと要求を理解できてきた」と思う人で、このフェーズの感じ方がぜんぜんちがうと思う。
>すべてのソフトウェアシステムはアーキテクチャを持つ。けれど、それは望むアーキテクチャが自然と最後に残るということではない。設計判断を天に任せるなら、どんな運命が待っているかは言うまでもないことだ。ソフトウェアシステムをどのように構成するかについて積極的に判断を下すことで、私たちのニーズに合ったアーキテクチャを得られる可能性は著しく高まる。
>Grady Booch は、「すべてのアーキテクチャは設計だが、すべての設計がアーキテクチャではない」と述べている。「1.2 ソフトウェアアーキテクチャとは何か」で学んだように、システムのソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったものだ。アーキテクトは、これらの重要な設計判断を検討し、望ましい品質特性を満たすようにソフトウェアを構成する方法を積極的に選択する必要がある。
これを読んで「設計とアーキテクチャのちがいとは…？」となって「1.2 ソフトウェアアーキテクチャとは何か」まで戻って読み直してきた。まだ自分の言葉ですらすらと説明できるようになっていないな〜と感じる。
>現代のソフトウェア開発技術には、アーキテクチャ上の前提が含まれている。フレームワーク、ミドルウェア、ライブラリといった、すべての既製技術は哲学を持っている。技術はそれを使用する方法と時期を教えてくれる。意見を持った技術は、アーキテクチャに決定を強制する。
>技術の意見が私たちのニーズと一致しているとき、私たちは最高の状態を迎える。私たちのニーズが、技術が想定しているニーズの範囲から外れているとき、私たちはフレームワークとの大乱戦を始める準備が必要となる。
>簡単に元に戻せない決定、つまりアーキテクチャ上の設計判断は、重大だ。行き詰まることや方向間違いを避ける 1 つの戦略は、責任を持てる限り拘束力のある判断を遅らせることだ。決定しなくてはならなくなるまで設計判断を遅らせることは、調査や探求の時間を生み出すことにつながる。
>『リーンソフトウエア開発 : アジャイル開発を実践する 22 の方法』で、Mary Poppendieck と Tom Poppendieck は、重要な選択肢を失うのを避けるために、判断を下さなければならない時期まで決定を遅らせる「最終責任時点(last responsible moment)」という考えを紹介している。最終責任時点について考える代わりに、私たちは「最大責任時点(most responsible moment)」、すなわち、ソフトウェアシステムに最も良い前向きな影響を与えるタイミングで設計判断を下すことを試みたい。
>設計判断を後から変えるのが容易なのであれば、それはもはやアーキテクチャ上の関心事ではない。可能であれば、変更の可能性がある部分については後続の設計者が設計判断を下せるよう、アーキテクチャを設計しよう。
2013-01-23 のぼくがツイートして、それに t-wada さんが答えてくれていた…！便利！！
さっき「関心事っていう語彙が好き」と書いたけれど、ぼくのこの感覚は t-wada さんや moro さんのおかげで持てている感覚なのだろう、と思えた。先輩に恵まれすぎ。なんとありがたいことか…。後輩たちに恩送りしていきたいね…。
>プログラミングから私たちが学んだ設計原則の多くは、設計原則として普遍的な価値のあるものだ。たとえば、SOLID 原則の適用はオブジェクト指向に利点をもたらしたが、アーキテクチャにも同様に多くの利点をもたらす。
SOLID 原則 は、もうページをつくっちゃおう。今後も何回も参照するだろうしね。
アーキテクチャパターンのお話。実例が次々に紹介される。
>アーキテクトは、昆虫学者が新種の昆虫を発見するのとほぼ同じ方法でパターンを発見する。フィールドで過ごし、周囲の世界を観察する。そして、考えられるパターンを特定したら、それを説明し、既存のパターンと比較して分類する。発見が既存のものと似ている場合は、ブログの投稿か論文の発行を通して、既存のパターンに関する私たちの集合知にその知識を追加する。発見が新しいものだった場合には、それをチームのパターンカタログへと追加する。
>「1 ヶ月コーディングすることで、ようやく 1 時間のアーキテクティングに相当する」。アーキテクチャの欠陥は、コードを書いたり、受け入れテストを実行したり、リリース後に顧客からの苦情をレビューしたりしているときよりも、アーキテクチャを設計しているときのほうが、より早くより低いコストで修正できる。
好奇心サイクル、おもしろいな〜。ぼくらは好奇心によって理解や設計を進めているのかもしれない。
>Arlo Belshee は、「Good Naming Is a Process, Not a Single Step」の中で、「名前づけの 7 段階(7 Stages of Naming)」について説明している。
>チームメンバーの多くが、アーキテクチャ内の同じ要素を表すために異なる単語を使用している。その結果、設計についての議論は合意を持って終わるものの、後で各メンバーが異なる結論を持ち帰るだけとなっている。
>ユーザーエクスペリエンス(UX)コミュニティは、この教えをデザインスタジオとして普及させた。デザインスタジオはグループコラボレーションを促進し、チームが短期間で幅広いアイデアを見るのを助けるために厳しい時間的制約を持っている。
デザインスタジオという概念がお目見えした。
ファシリテーションの大事な話も出てきた。
アーキテクチャデザインスタジオってやつは、ここに書かれているような説明を 10 回読むより、一度でも体験してみると理解が捗るんだろうな〜と思う。やってみたい。
>ソフトウェアアーキテクチャの文書化は、悪名高いことで有名だ。コードを書く時間を奪うし、賞味期限が切れていることがほとんどだ。独自のバイナリファイル形式で書かれていて、手軽に編集できないことも多い。それに加え、それを読む人がほとんどいない! ソフトウェアアーキテクチャ記述(Software Architecture Description)のことを SAD と呼ぶ人がいるのも不思議ではない。
>共通のアーキテクチャ記述方法には、アーキテクチャ俳句(アクティビティ 21)、アーキテクチャ上明白なコーディングスタイル(「8.3 コード内にモデルを構築する」)、アーキテクチャデシジョンレコード(アクティビティ 20)などがある。
>ソフトウェア開発は旅だ。道は曲がりくねっていて、同じ目的地に通じる道がたくさんある。すべての分岐、すべてのあなたが下した判断は、ソフトウェアアーキテクチャがそうなった理由を理解する助けとなる。あなたが下した判断を理解する方法の一つに、選ばなかった選択肢すべてを列挙するという方法がある。
Pull Request 上でコードレビューをするときも、採用しなかった方法が記されていると安心するしレビューが捗るよな〜。これは大事だと思う。
>評価をプログラミング時間を奪うものだと考えるのを止めよう。代わりに、プログラミング時間をさらに強力なものにする方法だと考える。評価にかける時間はわずか 1 時間だっていいし、既存の開発プロセスの中に気付かれないよう評価を組み込むことさえ可能だ。
>評価の中で学ぶ必要があるのは、「アーキテクチャはどの程度良いか?」ということと「アーキテクチャはどのように良いか?」ということだ。これらの質問に答えるため、アーキテクチャ上重要な要求(ASR)について分かっていることを使う。アーキテクチャが ASR を十分に満たしているほど、アーキテクチャはその目的を満たしているといえる。
>高セレモニーな方法とは、形式的な決まり事で満ち、実施にコストがかかる可能性があるものだ。高セレモニーな方法は繰り返しが容易で、一貫した結果を生む。一方、低セレモニーな方法は、堅苦しくないもので、形式的な決まり事はほとんどない。低セレモニーな方法は、より早くより低いコストで実施できる。しかし、範囲は狭く、矛盾する結果を生む可能性は高くなる。
>アーキテクチャはチームの文化の一部だ。私たちは設計したアーキテクチャと日々を共に生きることを選ぶ。貧弱な設計で生きることは、耐え難いものになる可能性がある。アーキテクチャ評価は、アーキテクチャをより良くする方法を理解するのに役立つ。
>現代のソフトウェアアーキテクトは、開発チームに向けて設計するのではなく、開発チームと共に設計を行う。今日のアーキテクトは、コーチであり、メンターであり、技術の第一人者でもある。本書では、本質的なアーキテクチャとデザインの原則について説明するところから始めた。そして、第II部を通して、それらの原則を実践に移す方法を学んだ。この章では、素晴らしいソフトウェアアーキテクチャを一緒に設計する仲間として、チームを成長させ、力を与える方法を学んでいく。
>『Management 3.0: Leading Agile Developers, Developing Agile Leaders』で、Jurgen Appelo は「権限の 7 つのレベル(The Seven Levels of Authority)」について説明している。これらを使えば、設計権限をどれだけ保持するか、そしてチームに何を委譲できるかを判断できる。
デリゲーションポーカーで見たことあるやつだ！…とか思っていたら 13.4.3 がまさにデリゲーションポーカーの話だった。
>市長は喜んでいる。開始時から仕様が変わり続けたにもかかわらず、プロジェクトは当初の予定よりわずか数週間遅れで終了することができた。正式公開前の負荷テスト中にいくつかの問題があったものの、優先度の高いすべての品質特性は実現することができた。それ以外もすべてうまくいった。
>次にやること? 次は、素晴らしいソフトウェアを作るために学んだことを使う番だ! 第III部では、アーキテクトの旅を始めるのを助けるため、デザイン思考の 4 つのマインドセットを中心にした実用的なデザインメソッドのコレクションを紹介する。私はこれを「銀の道具箱」と呼んでいる。もちろん、この名前は Fred Brooks の論文『銀の弾などない̶ ソフトウェアエンジニアリングの本質と偶有的事項』へのオマージュだ。
>10 年前のソフトウェア設計の実際は、今日とは大きく異なっていた。今後 10 年でも、ソフトウェアシステムの設計方法は変わることだろう。あなたは今、未来を形作るコミュニティの一員としてそこにいる。心配しないでほしい。きっと楽しいものになる。そして、私たちはその過程で素晴らしいソフトウェアを作っていくことだろう。
02. 共感マップ
19. ホワイトボードジャム
20. アーキテクチャデシジョンレコード
24. インセプションデッキ
26. 選ばなかった道
31. コードレビュー
32. 意思決定マトリクス
>── アリストテレス
「6.5.2 設計判断をアーキテクチャの外に移す」のところで言及した moro さん、レビュアーだった…！
>最後に、これまでの「... It!」シリーズの翻訳に携わってこられた方々に敬意と感謝を記します。10 年ほど前の自分にとって、『Ship It!』をはじめとする書籍たちを「今世界のどこかで、こうやったやり方や考え方で開発していっている人たちが実際にいる!」という感覚を持ちながら日本語で読めたことは、プログラマーとしての世界観を形成していくにあたって大事な経験でした。この恩送りがうまくできたかは先になってみないとわかりませんが、願わくば、ぼくがいただいたものをうまく先の人たちに繋げられていればと思っています。ありがとうございました。
島田さんも「恩送り」と言っておったやんけ！！！
- Links
- moro
- snoozer05
- SOLID 原則
単一責任の原則 (SRP:Single Responsibility Principle)
オープン・クローズドの原則 (OCP:Open-Closed Principle)
リスコフの置換原則 (LSP:Liskov Substitution Principle)
インターフェイス分離の原則 (ISP:Interface Segregation Principle)
依存関係逆転の原則 (DIP:Dependency Inversion Principle)
- t-wada
- コンウェイの法則
#2018-06-30 #言葉
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう
メルヴィン・コンウェイ - Wikipedia
- 恩送り
あれから 10 年。まさーるさん(石井勝さん)を偲ぶ。 - t-wadaのブログ という記事を、公開された 2015 年 4 月頃に読んで、そこで出会って以降ずっと大事にしているのが「恩送り」という言葉。
「恩送り」という言葉がある。意味は「誰かから受けた恩を、直接その人に返すのではなく、別の人に送ること」とある。恩返しをしようと思っても、その人がもういないことがあり得る。この言葉を知ったのはまさーるさんがきっかけだった。
まさーるさんの歳を僕はもう越えてしまった。あれ以来まさーるさんから頂いた恩を少しずつ世の中に送ってきたつもりだが、頂いたものの大きさを考えると、これから先も少しずつ送り続けなければならないと思う。
- 2020-01-02 Thu : ジム初め
- 2019-11-25 Mon : ランニング 63 分間
- 2019-11-19 Tue : 首筋に冷たい金属
- 2019-11-25
- 5Gでビジネスはどう変わるのか
- snoozer05
- 2019-11-16 Sat : 長距離走的な思考力
- 2020-01-02
- あたりまえの根っこ「差別と社会」
- 形の合成に関するノート/都市はツリーではない
- ネットワーク思考
- コンウェイの法則
- 逆コンウェイ戦略
#2018-09-02 #言葉
#コンウェイの法則 を正しく理解した上で、実現したいシステムにあわせて組織の構造を選ぶ、って感じかね。
- Matz
- 2019-10-03 Thu : フランス語で「稲妻」という意味
- 命名重要
- 2019-09-11 Wed : CarbonとCocoa
- Pull Request
- 2019-10-08 Tue : 「優秀な遺伝子」ってものは無い
- 2019-10-30 Wed : 大きめのデプロイ
- New Links
- 平鍋健児
- BDUF
- NDUP
- ENUF
- 銀の道具箱
- デザイン思考
- HART
- HRT
- MB02
- リーン
- MVP
- パタン・ランゲージ
- PDCA
- 形の合成に関するノート
- スイートスポット
- 顧客体験アーキテクチャ
- Melvin Conway
- 人月の神話
- 最終責任時点
- 最大責任時点
- 関心事
- 2015-08-31
- 2013-01-23
- アーキテクチャパターン
- 好奇心サイクル
- 名前重要
- デザインスタジオ
- ファシリテーション
- アーキテクチャデザインスタジオ
- コードレビュー
- 高セレモニー
- 低セレモニー
- デリゲーションポーカー
- 共感マップ
- ホワイトボードジャム
- アーキテクチャデシジョンレコード
- インセプションデッキ
- 選ばなかった道
- 意思決定マトリクス
- アリストテレス