道具性
ソフトウェアの道具性
例
スプレッドシート
Cosense
Notion
VSCode
Figmaとかも
この辺の関連性を感じる
出現した要件をすぐに実装すること自体が悪いわけではない
そのようにすると、抽象を発見する前にやっちゃうからで、そこが問題
逆に言えば、爆速で良い抽象を発見できるなら高速にタスクを処理しても良い
が、基本無理
ある課題に対する機能は無限に考えられる
その中のどれを選択すればよいのかというのは、
サービスの方向性、ユーザの性質、既存の機能との関連、などから帰納的にしか決定されない
本当の目的としては、良い抽象を発見する、良い道具を作るという点
ユーザに対する新機能もそうだけど、プログラムの中でも同じ
なにか今のinterfaceで満たせなかった時に、すぐに緊急ハッチを作ってしまう
すぐに改修しない
今わかっている要件に対する機能を考える際に、
道具性、可変性、使役性あたりを意識する
その特定の問題のみを解決できればokというわけでもない、ということを視野にいれる
ユーザ視点の道具性、コントロール権
ユーザの都合で工夫ができる方が良い
ソフトウェアが正解を提示するのでなく、道具を提示して改変できるようにする
将来の仕様の変更への対応しやすさ、どういう変更があるか
上と同じ話
例えば、業務フローなどは、利用者(B)のその時々の都合や工夫によって容易に変更できるべき
今の業務フローをそのままソフトウェアに組み込んでしまうと、
変更しづらい
変更するためにソフトウェアを修正しないといけないのでコストがかかる
変更のためのハードルが上がる
ちょっと微妙だけどコストかかるしこのまま運用でカバーするか....、になってしまう こう変えたくなることもあるだろうな、こう変わることもあるだろうな、というポイントを意識して、概念に対する適切な良い抽象を発見する必要がある 高度だmrsekut.icon
塩梅が難しい
例えば、特定の1社のto Bの場合、
DSLなどを提供するのもよいが、
そのDSLの抽象を超える変更が入った場合、余計にコストがかかる
DSLの変更と、その処理の変更
塩梅が難しい
抽象的になるほど、利用できる人が限られていく
プログラミング言語は、かなり抽象的なツール
言語の文法を知れば、たいていの道具を自分で作れる
しかし、その言語の文法などを覚えるのに時間がかかる
DSLだと、できることを制限する代わりに、覚えるコストも減らせられる
スプレッドシートはテーブルを扱うという点で抽象的
ただ、テーブルはよく知られたパターンなので、使える人も多い
Cosenseぐらいの抽象度のものでも使用できる人が限定される
という事実に割とびっくりするmrsekut.icon
・で箇条書きとか、[リンク]を作るとか、そもそも言語化だったりとか、そういう要求でさえ実は高度だったりする ツールのルールを学んででも、コントロール権を握りたいか？というバランスが大事
開発者目線では
ルールを最小にする
その中でできることを最大化する
あたりを探っていかないといけない
ルールの抵抗感を無くする
例えば、DSLを書いてね、という要求はハードルがある
それをGUIで良い感じに見せればハードルが下がるかもしれない
例えば、Markdownのエディタとか
シャープの数で# 見出しのレベルを調整できるよ、というのと
「大」「中」「小」というボタンを用意するのでは、
できることは同じでも、感じるハードルは割と違うだろう
ルールを暗記しなくていい
説明書を読まなくてもいい
でも色々できる
というものが求められている
提供する道具の数と、組み合わせの数
提供する道具の数が少ないほど、ユーザが覚えるべきことが減る
提供する道具の組み合わせの数が多いほど、ユーザができることが増える
多い道具と、多い組み合わせ可能性を比較すると、
多い道具の方が、具体性は高い
覚えることは多いが、考えることは少ない
膨大なユースケースを提示されている感じ
これをしたいときはこれを使う、というパターンの記憶になる
組み合わせが多い方が、抽象度が高い
できることは、ユーザに委ねられている
ユーザの能力に依存する
ユーザが自身で発想や試行錯誤をする必要がある
エラーになる組み合わせも存在する
提供者も全ての組み合わせを把握できているわけではない
どう組み合わせてもエラーにならない方が良い
気にすることが減るので
プログラミング言語だと、linterや型やsyntax等のルールで防止してる
サポートする機能の下限の抽象度の道具を提供する(?)
例えば、プログラミングという作業は、
チューリング完全な道具を用いて、プログラムを組んでいく
この際に、Lazy Kのようにたった3つの関数を提供するだけプログラムは組める もっと言えば、0と1の2値でも組める
しかし、実際はこれはプリミティブすぎ
提供する道具は少ないが、組み合わせの数が多すぎる
例えばElmなどのDSL
フロントエンドを開発するにはこれぐらいの抽象度の低さでも十分機能する
テキストを書く道具
MarkdownとCosenseは、感覚的に、同じような抽象度に位置している
Cosenseの方が抽象度高い感じもする
[]という一貫した記法
[*** ]は任意の数増やせる
記法の種類が少なく、覚えるルールが少ない
ある軸で、抽象度を高めると
覚えることが減る
提供する道具が減る
Markdown ←→ Cosense (高)
ある軸で、抽象度を高めると
道具性の観点？
覚えることが増える
できることが増える
Cosense ←→ プログラミング言語 (高)
よくわからなくなってきたmrsekut.icon
「抽象度」で整理しようとしているのが行けない？軸がよくわからない
Lazy KとC言語を比べた時に、
Lazy Kの方が抽象度が低い、という視点
抽象度は同じ、という視点
どちらもチューリング完全なので、作れるものの能力は同じ
Lazy Kの方が抽象度が高い、という視点
提供している道具が抽象的
その3つの関数を組みわせれば何でも表現できるのだから、抽象度は高い
抽象度が低い関数というのは、例えば、「fetch」みたいに目的が決まってるやつ