『優れたデザインにとってコンセプトが重要な理由』
https://gyazo.com/748bf9c9e24ebca48bbb3423e23ca8bc
2023/7/3
tutorialとかblogとかCase Strudiesとかある
最近も更新されてるmrsekut.icon
読み方
独自の用語とかが多いので逐一メモるのが良さそうmrsekut.icon
ノートも重要なのでこまめに読みたいmrsekut.icon
(本文よりもノートのほうが長い)
節ごとに読むのが良さそう
登場するたびに読むのは面倒だし、章ごとだとスコープが広すぎた
行ったり来たりするので、スクボ読書したほうがストレスが少なそう
ノートの中に、「絶対これは読むべき」と「どっちでも良さそう」が並列に混じってるのあまり良くないなmrsekut.icon
断片的なのでメモを取るのも難しい
個別のノートの内容が断続的なので頭から読むのもあまり適していない
ストーリーとして頭に残るのではなく、エッセンスを頭の片隅に置いていく感じになる
本を読んでないときもそれを考え続け、また時間をあけて再読し、噛み砕いていく
せっせとノートに対するリンクを付けながら読んだほうが良いかも(?)
用語
デザイン
人間のニーズを満たす人工物を作ること
状況に適した構造を作り出すこと
概念モデル
コンセプトモデル
コンセプト
ソフトウェアデザイン
デザインコンセプト
メンタルモデル
トレース
ノート44
actionを積み重ねたスタック
訳者序文
なんか頭に入ってない文章、気の所為？
読点が多すぎるからかな
コンセプト
WHATと同じ抽象レベルで整理した機能・振る舞いをコンセプトと呼びます
本書の読み方
まだ、この本がどのへんをスコープに入れてるのかわかってないmrsekut.icon
「デザイン」や「コンセプト」が指す対象がいまいち見えてない
著者がAlloyの人だという前提知識も入ってわかりづらくなっている
第1部 動機
第1章 本書執筆の理由
動機としてわかりやすいのはこの辺か
あるソフトウェア製品が自然に思える上に洗練されていて, 基本さえ理解すれば予測どおりに反応し, それぞれの機能を強力に組み合わせられる理由を知りたかったのです.
最初はスコープがどこなのかよく分からなかったが関連するノートを見ていくとわかってきたmrsekut.icon
ソフトウェアデザインの精密さが重要だと考えている
1980年代頃はその辺の研究も盛んだったが、最近はそこが軽視(?)されている
最近はソフトウェア品質の分野などが盛ん
開発の過程を「仕様の作成」と「仕様の実装の落とし込み」の2つに分けた時に、後者に力点を置きがち
ユーザの体験に直結するのは前者であり、それを洗練したい
例えバグがなくても、そもそも使えないと価値がない
第1章のノート
5,8,14
ソフトウェアのデザインとは, ユーザから見たソフトウェアの使い勝手を決める行為だ. プログラムコードがどう動くか, その規模とは関係ない. デザイナーの仕事は, ユーザの使い勝手すべてを完全に曖昧さなく規定すること. ref 5
Alloyだmrsekut.icon
振る舞い的ってなんだ?
「小さな再利用可能な概念モデル」というのは割とわかる気がするmrsekut.icon
最近考えているもののに近そう
でも振る舞いはあまり重視してなかったな
DDDでの、境界を作り、それごとにドメインモデルを作ることを評価し、
更にコンセプトでは、コンセプトごとに関連するデータモデルを保持すると言ってる
第2章 コンセプトの発見
早速具体例が紹介されていて、グッとわかりやすくなった印象があるmrsekut.icon
明示的に共有したフォルダ
Bの変更は、Aに影響しない
e.g. Bが名前を変更したとき、A視点では名前は変わらない
e.g. Bがこのフォルダを削除すると、B視点では消え、A視点では残っている
ハードリンク的mrsekut.icon
暗黙的に共有したフォルダ
e.g. 明示的に共有したフォルダの中のフォルダ
Bの変更は、Aにも同様に影響する
e.g. Bが名前を変更したとき、Aもその変更が見える
e.g. Bがこのフォルダを削除すると、Aも見れなくなる
シンボリックリンク的mrsekut.icon
Unixのfileなどと同じコンセプトに従っている
しかし、そのコンセプトが実際の目的と一致していないため混乱が生じる
具体的な方策は全くわからないが、動機はめちゃくちゃわかるmrsekut.icon
第2章のノート
ぼちぼち
19,23,24
第3章 コンセプトの効果
様々なサービスの中核のコンセプトを眺める
例えば、
Wordのコンセプトは行ではなくパラグラフ
ページのようなコンセプトも持っていない
Maxのゴミ箱のコンセプト
削除するためのものではない
実際は削除せずに置いておく
WWWのコンセプトはURL
先を読んでから3章を読み直したほうが良さそうmrsekut.icon
コンセプトというものが具体的にどういうものかを定義せずに、コンセプトの有用さを説いてる
凄さがわかるが捉えようがないので批判のしようもない
関心事ごとにコンセプトを設計する
1つ1つのコンセプトが小さければ再利用も可能
feature的な？
文章だけ読むとコンセプトは有用だなと感じるものの、じゃあ実際にそれをやってみようとなると無理じゃんという気がするし、本当か？という気もする
まず、課題に対して、これとこれが別のコンセプト、と分離すること自体が難しい
更に、独立するだろうと見なしたコンセプト同士が本当に独立するのかも怪しい
マクロに見てる人の例外対応と、ミクロに見てる人のコンセプトが同一のものを指していてどうしょうもないmrsekut.icon
ただ、コンセプトというものを完全に捉えられている、という前提になら成立しそう
第3章のノート
第2部 基礎
第4章 コンセプトの構造
Appleのゴミ箱
コンセプトの具体例
第4章のノート
目的とゴールを区別しており、ゴールというのが個別具体的なユーザの要望という感じなのはわかったが、目的の方はイマイチ捉えづらい
もっとこういう話を深掘りして欲しいmrsekut.icon
ノートじゃない部分はこういう話が曖昧すぎる
本書では,コンセプトを平易な言葉で表して, プログ ラムコードや論理に馴染みのない読者が不安を覚えないようにしています.実際 には,正確で曖昧さがなく自動解析や実行可能コードへのコンパイルが可能にな るような形式記法を用いる方が良いでしょう.
ノート44と48がかなり量ある
第5章 コンセプトの目的
目的を明確にする
そのコンセプトの目的は本当にユーザのため？
ビジネス上の都合で存在するものも多い
第5章のノート
これすごい話だな...
デザインのミスマッチにより自爆して3名死亡、20名負傷した
第6章 コンセプト合成
コンセプトは独立している
あるコンセプトから他のコンセプトが見える
相変わらず翻訳の(?)文章が読みづらいmrsekut.icon
複数の状態マシンの同期を取る感じか
マシン同士は独立してはいるが、特定のアクションを同時に実行することがある
https://gyazo.com/df859ed87d453f368f89c649c08f7b2d
どの差分のことを言ってるんだ
todo-userのような特定のuserといった条件が付された点？
ずっとなんか、APIというかOOPのclassのような話をしているようにも見える
「コンセプト」ってなんなんだ
通知機能を再利用できます、というのは、iOSや何やらが通知用のAPIを用意していれば、他のサービスはそれを使って通知機能を実装できる、と言ってるのと変わらない
actionとstateを持った小さなまとまり、とみるなら、単なるclassのようにも思える
結局、そのclassをどう区切るか？という話が重要で、そこを深掘りしないと、何か便利なコンセプトという概念がありまっせ、という話で終止してしまうのでは
第6章のノート
第7章 コンセプト依存性
第8章 コンセプトマッピング
第3部 原則
第9章 コンセプトの特異性