親: Design it を読んだ - t_hazawaの日記
概要
- 第三部には、アーキテクチャ作りに使える38個のアクティビティが紹介されているのだった
- 第二部までと異なり、かなり素早く読める
14章
- 問題を理解するために使えるアクティビティ
第三部 いろいろなアクティビティから 1分
14章問題理解のティ 1.5分
229 問題を定義しよう
ムのビジネス目標を定義しよう システム
230 ティ1 たった一つを選べないならどれ？ 3.5分 (12行)
トレードオフが難しいときに
選択はこのティの中で変更可能
厳しい会話を早めにすることが目的 (大事そう)
合意して、たった一つを選んでみる
対立する品質特性を戦わせてみよう
精度vs 高速さ
技術的負債の少なさとリリースの速さ
意外とセキュリティが最優先だったり
可用性とコスト 8.5分
想像したより、1つのティについて詳しく書いてあるな(3ページ)
トレードオフスライダー 8.5分 で順番に並べてみてもいいかもね
232 ティ2 共感マップ 9ふん (11行)
(所要時間10-30分)
ブレストでダーの気持ちを把握するティ
多分ダー自身がいなくても可能 (ダーの気持ちを想像する(多分)) 10.5分
象限 その人のする行動 その人の作るもの その人の発言 思考 10.5分
聞いていること 見ていること やっていること(言っていること) 考えていること(感じていること)
ダーさんそれぞれについてグリッドをつくる(縦横軸)
インサイトを強調表示で書き入れよう 11.5分
Mural がリモートで便利らしい 12分
ドット投票(小さな丸いシールを貼る)
品質特性を象限にして、似たようなこともできるよ 15分
使う機会があったら使ってみたいティだった (4象限に付箋をはってく)
236 ティ3 GQMワークショップ (15行)
Goal Question Metric
Goal ゴールとなる品質特性など
Question Goalが満たされたかをどのように明らかにするか説明する
Metric 質問に答えるための施策 16.5分
この品質を満たすにはどうすればいい？それはどうやって測る？ 17.5ふん
さらに測る対象のデータも書くらしい 18分
それぞれのコストも書くらしい
で、どのメトリックとデータを使うかを決めるのがゴール 18.5分
アーキテクチャの外側でデータを取ることもできるかもね 19.5分
一度考えたら、また再度(数カ月後とか数年後とかに)同じ計測方法でいいね、とできるのもいいところ 20分
一つのゴール「パフォーマンスのボトルネックを探る」でも、複数の質問が出てきて、それぞれ複数のデータを使う感じ
だから、こういうツリーを作るのが大事なんだね
日々の仕事(じゃないけど)で
うーん、こういうふうに列挙する時はツリーできるといいのかもね (日頃列挙してると思う) 22分
239 ティ4 ダービュー ステークホルダーインタビュー 22分 (19行)
ダーについて質問しよう、というティ (ごく当たり前な気がする) 22.5分
トピックを持って質問に臨もう 23分
ューの目標を事前に定めておこう
ダーとの関係値もできるよ
(所要時間30-60分) 24分
積極的なュアーは1,2人、対象も少数かな
インタビュー後に詳細なメモを書くこと
得意です (全部メモするのが) ちゃんと要点をまとめています 25分
ューの感想も書きましょう ューから得られたインサイトも書けるといいね 26分
最初からチャの関心事について聞くのはやめよう その前に一般的な部分の質問がある(とのこと) 27分
質問で誘導しちゃダメよ
アイデアをまとめるときに対象者の言葉を使えると良い
実際のユーザやダーにューできるといいかもね
監督者じゃなくて現場の人とか
データをもってくといいかもね 28分
ュアーが質問と対象者に集中できるように、書記はべつの人がいいね 28.5分
例
置き換えようとしている。古いムの計画は？ システム
廃止期間についてューしてる (ごく普通の仕事の会話に見える) 29.5分
242P まで
時間まとめ
今日は28分かけて、4つのティの部分を読んだ 14ページかな。
ちょうど1ページ2分だ。
60行書いてるので、 30分書くのにかかってるはず(純粋には -2分で 14ページ読んだことになる)
(不整合)
Design It は372ページまで(あと130ページ)ある。
ティは38まである
ページ数的には、あと9日、ティ数としても、あと9.5日で読み終えるでしょう
4つめは当たり前だったけど、ちょっと考え方の足しになったかも(曖昧な感想)
今日もDesign It 第三部ティ集 3分
ティ5 前提リスト 243 (できてそう)
前提を出しきらないとムは死ぬよ
一人合点はよくないと忠告するのが大事らしい 5分 244
自分ごと
かなりできてると思う 何をするにしても手元に 案件.txtを書いてやってるし
これはできてないなと思うティに下線をつけたりすると良いと思った 6.5分
ティ6 品質特性ウェブ 8.5分
ティ 2とか3ででてきた手法 9分
品質特性を特性ごとにレーダーチャートにして貼る
まず、重要な品質特性を5～7出す必要がある (可用性とかコストとかセキュリティとか) 10.5分
付箋に書いて貼るのは関心事 (多分関連することなら何でも良い) 11分
最後に、優先順位をつけて(ドットシール投票)、品質特性シナリオ(一般的な叙述文)をつくる11.5分
ティ7 ミニ品質特性プ 248 13分
ワークショップ
ミニでも～3時間かかる 15分
人数が10人以上になりそうだったら、複数回にわけて、最後に全員でシナリオ統合をしようね 16.5分
やはり、品質特性ウェブに付箋をはっていく感じ(ティ 6と同じ？) 17.5分
付箋がシナリオ素材 これから品質特性scenarioを作る 18.5分
余裕があったら、事前アンケートすると精度高まるよ 20.5分 252
重要なものをscenario洗練させようね 21分
ティ7だと大掛かりだから、品質特性が11個くらいウェブにあったりする 21.5分
機能じゃなくて、品質特性の話をするのが大事だよ 22.5分
ティ8 Point Of View Madlib 23分 254 (前の部署でやってた) (できてる)
視点穴埋めゲーム
誰は何をする必要がある。なぜならこういう理由があるからだ。
でもまぁ、なんでいるかはやはり手元の .txtに書いてるし、コンフルにも書いてる
5回のなぜテクニックはそのうち調べようと思う (手元にメモ) 27分 256
似た手法
目標の丘 Design Hills
Who が What をできる。 しかもその上 Wow! だ。
インパクトを示せる
表に書いたりもできるよ 29分
今日の感想
品質特性ウェブというものが世の中にあって、ニーズを洗い出すときに使えるかもと思った。
時間まとめ
ティ集は、文字でページが満たされてないので、はやくよめる
アクティビティ
27分で ティ5-8 。 243-258 (16ページ)
まぁ、いい感じの速度では。
372がゴールなので、 あと 110ページ。 7日でおわる
本全体は 24日で終えることになる計算
ティ9 応答測定のたたき台 259 1分 (いいかも。)
議論のためのたたき台
「仮に正常に使える期間を99.9%として考えてみましょう」的な？ 2分
そうみたいだった
確かにいいかも。 要件を考えるときに (99.9%ができそうかも) みたいにスタート地点を書くといいかも 3.5分
ティ10 ダープ 261 ステークホルダーマップ
まだ「問題理解」のティ (多い)
プを作ると、ダーの見落としが減るよ
その人とどういう関係かもわかるよ
その人の役割を書こう
(感想) まぁ、書いておいた方が後からきた人もわかりやすいかな
自分では書いたことがないと思うけど、joinしたプロジェクトでは最初に携わった人が書いていた
確かにユーザとかインフラを整備してくれる人や役員や株主 などはいつも見ている表には載ってないかも(そんなに把握する必要性は感じないけれど)
多分、(顧客に)真に必要なものがなにかがわかってないような難しい案件では、ダーを洗い出すのは大事かも 8.5分
15章
- 解決策を探るために使えるアクティビティ
15章 潜在的な解決策を探るためのティ 265 9.5分
解決策(=チャ)はトの知識があれば無限大 (アーキテクト) 10分
基本はリデザイン (他の事例の再適用)
ティ11 チャの擬人化 266 11.5分 (おもしろそう、機会があったらやってみたい) (◯◯くん呼びをこれからもたまにしようと思った(やってる))
おもしろそう
チャが人間的感情を持って話すように書く
動機、目標、刺激に対する応答 などを説明する
◯◯くん (ex. AWS Lambdaくん、DBくん)
ョンのために正確さを犠牲にするのは価値ある (コミュニケーション) 13.5分
「どれだけアクセスがよあるとDBくんは苦しい」「Redisくんは同時何接続かまでは大丈夫なので、1接続がアクセスしまくっても大丈夫」
ティ12 チャプブ 268 16分 (アーキテクチャフリップブック)
途中で演習ででてきたもの
スライドを使って、チャを進化させていくティ
なぜそうなったかが書き残されるので、どこが要点なのかが後世に伝わる 17分
(感想) 難しいチャが必要なときには参考になるかもと思った
ティ13 CRCカード 272 18分 (手元の.txtに簡易設計をつらつらと書いてるのはできてる)
Coponent Responsibility Collaborator Cards
コンポーネント - 責務 - 協調相手
クラス - 責務 -協調相手 の拡張版
その3つを名刺的なカード(名刺よりは大きい)に書く
これを書くとどう役立つんだろう (読み進める) 20分 273
ちゃんと書き出してみると、実際のチャやASRとのズレを見つけられるらしい
まず品質特性scenarioがカードになって、それに最初に応答するコンポーネントのカードから作って、それが使うコンポーネントのが次々に書かれるらしい
つまり、カードでプログラミングする感じ (設計) 22分
事前に簡易にプログラミングすると、間違いなどを見つけやすいね、コーディングしてから見つかるとダメージが大きいね、という話みたい
275で、このコンポーネントに責務と協調相手が集中してて神クラスになってる みたいなのが視覚的に分かるのはよさそうだった
(感想) これも、大きな仕組みづくりのときには やれたらいい感じっぽかった
多分、手元で、何をするために何があって、それは何を使うみたいに .txt に書いてるのとやりたいことは同じ 25.5分
ティ14 概念マップ 277 26分
チャはドメイン(概念)に規定されるので、ドメインを明らかにしよう
ER図みたいなのを書く
使ったりする人やシステムにでてくる概念のER図化 28.5分
(感想) 問題が大きかったら、この図を作って、この部分をどういうシステムで埋めるぞ と決めていくとよさそう (問題が大きかったら) 29.5分
今日の時間まとめ
28.5分で ティ9-14 (6つ) P. 259-280 (22ページ) 進んだ
大体1分で1ページ弱なのでいい感じ
372がゴールなので あと 92ページ (4.5日程度)
2021/01/23 14:57
今日は7ページ勉強する P.286 まで
ティ15 分割投資 280
チームを小さくしよう
細かくしすぎると全体最適にならない場合があるよ。探索範囲は1つのチームに含めたり、全体で発表会をしたりするといいよ
小グループでの作業は1週間以内くらいがいいよ 281
グループには明確な使命をもたせようね 282
深さ優先チ(同じ分野)と幅優先チ(色んな解決方向探し)があるよ アプローチ
プを小さくすることで、本当に大事なところだけにしか取り組めなくなるよ
発表の準備にも時間がかかるよ
やること計画と発表結果の例 284
こうしてチームはマイクロサービスの設計を開始できる知識を得たのだった2021/01/23 15:09 285
今日も7ページよむぞ2021/01/24 19:06 293まで
ティ16 イベントストーミング 285
ドメインについてのイベントを探す手法
疑問点を付箋にすることで、議論が途切れず、可視化もできるよ 288
中には深堀りしないといけないイベントもあるよ
ティ17 グループポスター 290
成果物としてポスターができる
チャのアイデアがのるらしい(ER図的な図だったりする)
アクティビティ編続きから 1分
ティ 18 ラウンドロビン設計 293 2min
素早く回してアイデアを多く得る(2個～)(30分前後)
3～11人
作成 批評 出た課題の解決を試みる
設計の環境が制約されるので創造性が育まれる
紙にスケッチ(アイデア)を書いて、書いた紙を回して批評して、さらに別の人が課題の解決策を書くことで相互作用的ないい効果が生まれる
(感想) なにか新しいことをやりたかったらやってもいいかも 6分
ティ19 ホワイトボードジャム 296 6分
ホワイトボードを使って話し合いをすること
ホワイトボードマーカーの色は何種類もあるといい
みんなで書き込む
まとめを写真とともにwikiに書きましょう
作成 - 共有 - 批評 フロー(自然に行われること) 8.5分
ホワイトボード上のスケッチより、それをネタに行われる議論の方が大事 (この記録も大事)
(ここで300ページに到達) 2021/01/25 16:29 10分
16章
- 設計を触れられるようにするアクティビティ
16章 設計を触れるようにするティ 301 10.5分
(感想) どのくらい触れるようにするのかは、自分の興味の強いところだ
とくに「プロトタイプ」とはどういうものか (興味津々) 11.5分
プの例 プロトタイプ (色々なやり方がある)
ト ドキュメント
実験
計算
物語る
演技
ほとんどが30分以内で作れるものだ 13分
ティ20 チャンド 302 13.5分 アーキテクチャデシジョンレコード (自分は「影響」も書けるといい。書いてみるかも)
設計判断を記録していく
現状のチャについてのコンテキストを提供できる
アーキテクチャ思考を訓練
重要な判断の例 が303に乗ってる 15.5分
タイトル コンテキスト 内容 ステータス 影響 ← チャンドテンプレ
ステータス: 下書き、提案済み、承認済み、廃止、非推奨
古い記録(過去の判断)への参照をつけるのも大事 16.5分
短く、1,2ページに保てるとよい
チャ俳句(ティ21)や ムメタファー(29) もオススメ 17.5分
なぜ Gitgubと Travis CIを利用する方がいいかがチャンドの形で提案されている
これが採用されたら、これがこのままコンテキストとしてできてる
しかし、自分の場合、やはり既に、手元.txtには必ず経緯が書かれていて結構できてた
足りてない部分: 影響。影響は意識しては書いてないかも 19.5分
ティ21 チャ俳句 305 20.5分
ダーが実際に使えるように小さくまとめよう
理解が容易になる
チャのいいところを宣伝するチラシができる
他のより詳しいトを参照する判断基準に使えるチラシ ドキュメント
(感想)タンジブル(チャが触れるように)になってるなぁ 22分
コンパクトに次のことをまとめる
解決策全体の簡単なまとめ
重要な技術的制約の一覧
主要な機能要求の概要
品質特性の優先リスト
根拠と妥協点を含む、設計判断に関する簡単な説明
使用されているアーキテクチャ様式とパターンのリスト
上記以外に価値を持つ図表だけのリスト
(感想)なんか結構でかそう24.5分
1ページにするためにそれぞれを簡素にかくらしい
重要なことだけを書く
生きたドキュメントなので修正OK
「Lionheart プロジェクト」みたいなプロジェクトくらいの大きなものについてのチラシとして書く
ティ20 (チャンド)と違って、個々の判断とかムの一部とかについてチラシを作るのではない 26分
ひと目でプロジェクトがどういうもので、どういう技術要素とかがあるのかがわかるね
(感想) プロジェクトごとに書いてあると確かに理解が早くなりそうだった
ティ22 コンテキスト図 308 28分
ムとダーたちの関係を書く ステイクホルダー システム
確かに関係がわかりやすくて、ムがタンジブルになってた (初見の人へのわかりやすさが必要なときにはつくろう)
(たまに作ってる感) 30.5分
時間まとめ
今日は29.5分でティ18-22 (5つ)すすんだ 293-309(16P)
372がゴールなので、あと 63ページ (4日)
感想
「影響」は書いてみようとおもった (経緯はかいてる)
初見の人にわかりやすさが要るときは、必要な図を引き続き書こうと思った
チラシ (チャ俳句、ティ21)は書いたことなかったので、必要なときには作ると良いと思った
23, 24
ティ編つづきから 1分 触れるようにする編
ティ23 まずこれ読もうリスト 309 (既にやってた)
ドキュメントを探すのに役立つト
キュレーションやリーディングリストを作る
(自分ごと)
監視とか、数値確認用ツールとか、目次的なのは既につくっていた！
概要になぜ重要なのか書かれているとさらにわかりやすいよ
公式や市井のWeb上のドキュメントでもいいよ (低コスト) 4分
「監視」とか「数値確認用ツール」みたいな細かいスコープだけでなく「◯◯プロジェクト全体のこれをよもうリスト(目録)」を作ると初学者にわかりやすいよ 5.5分
歴史的資料も載ってると、コンテキストがつかみやすいよ
ティ24 インセプションデッキ 311 6.5min
インセプション 方向づけ
方向性をあわせるために、プロジェクトの開始時に10個方向づけをみんなで決める 7min
バンドだったら即解散しそう でも、悪い話は早めにするべきで、この方向づけが一致したバンドはずっと存続しそう
10個の方向は簡単なテキストとか簡単なスライド
なぜやる どんなビジョン どんな価値を作るか スコープの範囲 主なステークホルダー 基本的な解決策 主なリスク どのくらいの作業&費用 トレードオフへの向き合い方 初回リリースはいつ
Afterglowの場合
なぜやる: 蘭ちゃんだけ別のクラスになってかわいそうだから
どんなビジョン: ロック
どんな価値: ライブしたり曲を作る きいたらアガる
スコープの範囲: 近場のガールズバンドファンにライブで届く
主なステークホルダー: 自分たち 親 近場のガールズバンドファン
基本的な解決策: 普通に練習したり屋上で歌詞を考える
主なリスク: 家業の華道が大変
作業&費用: 週3で2-3時間ずつくらい練習、みんなお金持ちなので大丈夫
トレードオフ: 正確さとかうまさよりも自分たちらしさが大事
初回リリースの時期: 3～4ヶ月後に1stライブ
…というふうに、いろんなプロジェクトに使えるのだった 12.5分
というか、これが決まってないとブレる
できたらレビュー&修正
自分たちらしさを見失わないために定期的に見返そう (重要)(2章)
(感想) 同じ方向を向くのには必要そうだった
Afterglow も これを作っていれば 1章や2章で時間をかけて悩まなくてよさそうだった
ティ25 モジュール分解図 314 14.5min
ツリー図 16.5min
いろんなものをモジュールに分解する
一番上のルートは 「システムは何と何と何でできている」になる
ソフトウェアを使ってツリーを書くといいよ
大きい図を部分図に分割するといいよ 19.5min
大きさを含めて描くこともできるよ
(またAfterglowの例) バンドリ→ガルパ→Afterglow→美竹蘭→華道の家元の娘→親・華道との葛藤
バンドリ→ガルパ→Afterglow→美竹蘭→華道の家元の娘→かなりお金持ち→{自分の部屋の家具, 大きな一軒家}
重要な要素を入れ忘れないようにしよう！
ティ26 選ばなかった道 22min 317
却下した理由とともに書き残されていると、判断のコンテキストや論理的根拠があとからわかるよ 22.5min
短くわかるのに十分な量だけかいてあればいいよ
例: パッケージムとクラウドムの融合 (更新間隔が違う)
これこれはコストがえられる利益より上回る的な 26min
コストと価値のバランス
「5人一緒にいるためには、毎日4時間練習する必要はない」
選ばれた道がなんだったのかが気になる (書いてあった)
ティ27 学習や判断のためのプ 319 29min プロトタイプ
学習や判断のために自分で軽くやってみよう
阿部さんがよくされてるイメージ
プロトタイプをどこまでのものにするのかの計画が大事 足りなかったりやりすぎたり 31min
プを使い捨てるか、よかったときに本番にも使うかを前もってきめよう
プではスピードのために品質を引き換えにしないといけない場合があるよ
タイムボックス(2日とか)の最後に、試してみたもののいいところ悪いところがわかって判断につながるよ 321 33.5min
今日のまとめ
時間
今日はティ 23-27(5つ) 32.5min 309-321(12ページ)
372がゴールなので あと 51ページ(4.5日)
何を大事にするのかはっきりさせておくのが大事
あとはドキュメントの作り方 小ネタというかコツみたいなのだったので、日頃気づいた中で実践していきたい
というか結構できてる気がする
27
ティ編つづきから 触れるようにする編 2分
ティ28 321 シーケンス図
ごくたまに自分でも書きます(2,3年に1度)
ちなみにここでは
実線の閉じた矢印: 同期リクエストmsg
実践の白抜き矢印: 非同期リクエストmsg (例になさそう)
点線: 応答
テキストベースで保存できるといいかもね 4.5min js-sequence-diagram とか
ティ29 ムメタファー 324 6min
システム
ムを他の出来事で例える
思い出に残る 7min
ポップカルチャーや食べ物
クローラの頻度についての例
17章
- 設計の選択肢を評価するために使えるアクティビティ
17章 設計の選択肢を評価するティ 329 9min
評価のティ
悪いことを早期にみつけよう
ティ30 チャグ 330 10.5min
アーキテクチャ ブリーフィング
建設アーキテクトがクライアント教育したり進捗共有するための一般的な方法 11min
ソフトウェアでも数十年使われている手法 11.5min
質疑応答時間を15-30min(以上) とろう
準備には説明の長さの2倍の時間がかかる
目安にしようと思う(もっとかけてしまってるかも感)
質問や意見をするのは最後にしよう (メモっておこう) (やってる…はず)
書記もいるよ(できてる) 15.5min
ティ31 コードレビュー 333
ューの中でチャのことを教えることもできるよ 16.5min
初期のューは10分程度で済むよ
複数レビュアーの参加を推奨しているチームが多いよ 17min
ューは視野が狭くなりがち。コードの長期的な進化に目を向けよう 18min
設計評価はコードレビューの中ではできないよ
チェックリストがあるといいかもね 正しさ 一貫性 テスト容易性 保守容易性 信頼性 スケーラビリティ 20min
ティ32 意思決定マトリクス 336 20.5min
ルーブリック…通知表の項目
7項目以下
(本文で詳しく出てきたティ)
ティ33 振る舞いの観察 339 22min (できてる)
ムに計測の仕組みを追加する
計測結果でダーの関心する質問に答える
KibanaとかDatadogとかでできてるね
必要な時は専用ログを吐く
GQMプ (ティ3) などで指標を決めよう
Goal Question Metrics
ティ34 質問 意見 懸念 QCC 341 25min
Question Comment Concern
これでチーム内で知識が流通するらしい
チャについて知っていることや、実は知らないこと、心配していることを学習するプを開くティ
ワークショップ 27min
そのことについてブレストする 付箋を書きながら
意見 黄色 質問 青色 懸念 ピンク
最後にまとめをする やるべきことを決める(優先順位 & 担当者)
ティ35 リスクストーミング 344 29min
リスクについてブレストする
やはり付箋を使う リスクの危険度ごとに色が違う
やはり次にやることを最後に決める (できてる)
チャのスケッチを見ながらやることで発想がたくさんでる 31min
まとめ
説明の準備に2倍の時間は目安にしようと思う
できてることが多かった感
29分で ティ28-ティ35(8個) 321-347 (26ページ)
今日ははやかった
372がゴールなので、あと 25ページ(1,2日)
28
ティ編つづき あと1.5日 評価編 1分
ティ36 サニティチェック 347
チャのことを考える抜き打ちテスト 1.5min
認識や知識のズレがなおる 348
ムの知識を文書化する
未知の未知も明らかになる 2.5m
本当にいきなり5min(長くても10min)で終わるようなクイズというか問いかけを出すティ 3m
必要であればNext Actionを最後に決めよう
罰や昇進のために使ってはいけない
定期的に実施するといいよ
例: 技術要素の選定理由はどれでしょう？
(感想) 知識が行き渡ってないときにはよさそう
ティ37 オクルー 350 6m シナリオウォークスルー
チャが特定の品質特性シナリオをどう満たすか(満たさないか)話をすること
1つの品質についての打ち合わせに20-30min かかる 8m
会議では質問をしよう
3-7人でやろう
シナリオウォークスルーの名の通り、どう品質特性を満たすかのストーリーを述べる 11.5m
ティ 38 スケッチして比較 354 13m (常に比較するのはよさそう)
比較対象をスケッチによって作って比較判断できるようにしよう 13.5m
議論は議事録とかでのこそうね 14.5m
話し合いをすすめて合意形成を勝ち取ろう 15.5m
現在と未来の比較とか
図(スケッチ)があると比較しやすいよ
(感想) 常に案を比較しようと思った
図も大事だと思った 17m
この後は著者紹介、参考文献リスト
あとがき
習慣が大事 アリストテレス
It! シリーズの一冊だったらしい
HeadFirst おもしろくてすき
It! もオライリーの本
感想
設計のやり方というかテクニックはわかった
デザインパターンはHeadFirstを今度こそ読もうと思った 22分
時間まとめ
ちょうど12/28に始めた記憶なので、 Design it は 31日でおわった
372ページだったので、一日 12ページだった。
これが足りてるか足りてないかは 次の「スケジュール感つくり」で分かる...
