野ッカーという新しいアイデア
今年の 2 月、『Web アプリケーションアクセシビリティ』という書籍が、技術評論社から出版された。ウェブアプリケーションのアクセシビリティに関する、576 ページに及ぶ実践的な本だ。
ウェブ制作でいうと、ビジュアルデザインからフロントエンド、バックエンドの実装、CMS などの運用についてまで、様々な書籍が毎年数多く出版されているが、ウェブアクセシビリティを中心的なテーマにしたものは、『 デザイニング Web アクセシビリティ』太田良典 (著), 伊原力也 (著)や、『コーディング Web アクセシビリティ 』 Heydon Pickering (著), 伊原力也 (監修), 太田良典 (監修)、『インクルーシブ HTML+CSS & JavaScript』Heydon Pickering (著), 太田良典 (監修), 伊原力也 (監修)など、いくつか挙げることはできるものの、その全体量からすると圧倒的に少ない。
さらにいえば、アクセシビリティの話を抜きにしても、React や Vue.js などの特定のライブラリやフレームワーク名を冠していないウェブアプリケーションについての書籍自体、稀有といえるだろう。アクセシビリティについては、ブログ記事などでのナレッジシェアが盛んだし、有志によるまとめも存在しており、情報が不足している印象はないが、やはり書籍としてまとまったものを手にできるのは嬉しい。待望の決定版だ。
ウェブサイトとウェブアプリケーション
本題からはやや逸れるが、ウェブサイトとウェブアプリケーション、それぞれに定義について一旦ここで触れておこう。
ウェブサイトとウェブアプリケーションの違いについて、明確に分けて定義することは難しいが、私は昔からよく Jesse James Garrett の図をひいて説明する。とても有名な図のはずだけれど、もしかしたらこの形式のものを見たことがないという人も多いかもしれない。書籍に掲載されているオリジナルの図には、左右に分かれた 5 階層図があるのだ。この、分かれているところが重要だ。
なお、その後この左右の表記は「機能性としての製品」と「情報としての製品」に改修されたため、ウェブサイトとウェブアプリケーションの違いを表す図としては分かりづらくなっている。まあ元々そんな図じゃないけど。ちなみに、今年出版された復刻版には改修された図が掲載されている。
私が「ウェブサイト」と定義しているのはこの図における「ハイパーテキストシステムとしてのウェブ」であり、「ウェブアプリケーション」と定義しているのは「ソフトウェアインターフェースとしてのウェブ」である。
よく、「ハイパーテキストシステムとしてのウェブ」にあたるものを「 Web デザイン」、「ソフトウェアインターフェースとしてのウェブ」を「 UI デザイン」と言ったりするのを見かけるが、それは字義的にも全くの的外れだと思う。「ウェブデザイン」は「ウェブアプリケーション」を含むし、「 UI デザイン」はウェブに限定されないのだから。（それでいうと「ウェブサイト」も微妙なのだけど「ホームページ」には別の意味もあるし、「じゃない方」を指す「ウェブサイト」以上に一般的な言葉が見つからないので、ここでは一旦「ウェブサイト」としておく。）
もちろん、たとえば EC サイトのように、ウェブサイト的なものとウェブアプリケーション的なものが混ざっている場合もある。ウェブサイトのナビゲーションに使われるハンバーガーメニューはアプリケーション的だが、それによって呼び出されるページはウェブサイト的である。一方で、ソシオメディア社や、先日リニューアルした BNN 社のコーポレートサイトのように、ウェブサイト的に作られる事が多いコーポレートサイトを、一覧と詳細をもつアプリケーションのように制作したものも（ UM法 ）当然存在する。
しかしその境界が曖昧なものだからといって、当のウェブ制作者が、自分が果たしてどちらを作っているのか全く頓着しないのでは問題がある。この区別にある程度自覚的でないと、機能的な操作体系をデザインすることはできない。
ところが、ウェブサイト向けの制作ガイドラインをウェブアプリケーションにもそのまま流用してしまっている現場にもよく遭遇する。だから「必ずパンくずを設置する」とか「ホームのことはトップページという名称にする」みたいなウェブサイト向けの規定について準拠を求められた時には、いいえ、アプリケーションにパンくずはありません。ページなんてないし、トップページもありません。といったような説明をいちいちしなくてはならないという面倒なことも発生してしまう。アプリケーションの GUI によって行われる、手順の決まっていない操作に履歴はあっても階層構造はない。Photoshop で何か一つ操作するためにパンくずが増えたりはしない。しかし、普段ウェブ制作に携わっている人でも曖昧に扱ってしまっているウェブサイトとウェブアプリケーションの違いを、現場の担当者が理解するのは困難であろうし、理解できるように説明するのはなかなか骨が折れる。これについては今後ウェブ制作者側が意識的に改善しなくてはならないだろう。少なくとも、ウェブアプリケーション専用の制作ガイドラインが必要と思われる。特にウェブアクセシビリティガイドラインはウェブサイト用のものがウェブアプリケーションにも流用されていたり、ごちゃ混ぜに書かれているケースが多い。
さて、前置きをやたら長くしてまでなぜこの区別にこだわるのかというと、この曖昧さは、HTML というマークアップ言語の性質と深く関わっていると私は考えているからだ。そして、そもそもこの違いについて認識していなければ、この先する話について、一体何を言っているのか、皆目見当がつかないだろう。
重要なのはウェブアプリケーションはソフトウェアインターフェースとして、 GUI を持っているということだ。
アクセシブルなデザインの原理
『Web アプリケーションアクセシビリティ』には、各章を通じて、ウェブアクセシビリティの定義から、WCAG などの国際的なガイドライン、今すぐにでも実践できる改善事例、具体的な実装方法、支援技術についてまで豊富に、かつ丁寧に書かれている。この本さえあれば、ウェブ制作初学者であっても確実に最初の一歩を踏み出すことができるし、経験豊富なフロントエンド実装者の技術書としても申し分無い。
また、7 章では、現代のウェブアプリケーション制作において、一人きりでは実現が難しいウェブアクセシビリティ向上について、いかにチームや組織と協働していくかについても書かれており、アクセシビリティに関わらず、人間中心設計やアジャイル開発など、なんらかのアイデアを組織に広めたいと考えている人への指南の書としても優れている。
そして最も特徴的なのが「アクセシブルなデザインの原理」と題された 8 章である。この章には、筆者である伊原力也さんがこれまでの活動の中で出会ってきた非アクセシブルになりがちなアンチパターンとその解決方法、そしてそこから導き出した原理について書かれている。
8 章に紹介されている原理は全部で 11 ある。
・シンプルなモデル
・明快な呼び名
・シングルカラム優先
・1 画面に 1トピック
・最大限のテキスト
・大事なものは常に上
・キーボードのみ、クリックのみ
・一貫性
・主導権はユーザーに
・複雑性の移動
・モードレスネス
ウェブアプリケーションに関わらず、普段ソフトウェアの制作に携わっている人なら当然分かると思うが、これらの 11 の原理のうちほとんどが、アクセシビリティ文脈に限らず、ソフトウェアのデザインにおいて重要なものだ。実際、シンプルなモデル、明快な呼び名、最大限のテキスト、一貫性、主導権はユーザーに、複雑性の移動、モードレスネスあたりは、国内外のデザインガイドラインで頻繁に採用されている。しかし一方で、それらとコンフリクトするようなものも同時に含まれている。
この矛盾については、実は本にも明確に書かれているのだが、シングルカラム優先や 1 画面に 1 トピックは、モードレス性を阻害することがあるだろう。ジェスチャーに転換できる操作をやめてクリックやキーボード押下に割り当てたら、直接操作性を欠いてしまう可能性がある。 また、大事なものは常に上というのも、明確な順序を持たない GUI のランダム性と競合するだろう。何が大事なものであるか決めるのは、ユーザー自身である。主導権はユーザーにあるのだから。それは一覧にあるステータスかもしれないし、詳細にあるメタ情報かもしれない。当然、要素同士の関係性を表現するために、レイアウトのセオリーとして上下左右の法則性は持たせるだろうけど、だからって文章を読むとかでない限り、人は別に上から順に画面を見たりしないのだ。
マルチカラムを避けたり、表示要素に順序性を持たせることは、ランダムアクセスや直接操作という、アプリケーションの GUI の、GUI 性そのものの排除でもある。プロモーションのための単発アプリケーションとか、表示要素が少ないごく単純なものであれば、それほど問題にならないかもしれないが、GUI のポテンシャルを活かせる、複雑なマルチペインを持つ業務アプリケーションのような、道具的なものの場合には致命的だ。GUI は線形に記述できない。記述したら別の意味を持ってしまう。
その上、他の原理と競合してしまうこれらの原理は、ウェブアプリケーションだからこそ発生するアンチパターンに基づいたもので、ネイティブアプリケーションにおいてはそれほど問題にならないと思われるものが多い。実際、8 章に事例として掲載されている 2 つのアプリケーションはネイティブアプリケーションなのだ。
この原理に則るなら、特に複雑な道具的アプリケーションを制作する場合、最初からアクセシブルにしたいなら、ウェブアプリケーションという選択をやめて、ネイティブアプリケーションにすればいいという事になってしまわないか？
もちろん、ネイティブアプリケーションをアクセシブルにすることが簡単というわけではない。しかし、8 章よりも前に書かれてるように、既にウェブアプリケーションとしてあるものをアクセシブルにしたり、ウェブアプリケーションにしなくてはならないという何らかの制約の中でよりアクセシブルなものを作ったりする場合ではなく、最初からどちらかを選べるのであれば、ネイティブアプリケーションとしてそれぞれのプラットフォームで作るのが最もアクセシブルになるのではないか。単にウェブが好きだからという理由ではなく、誰もが使えることが人権だからという理由でアクセシビリティに取り組むというのなら、人権のためにウェブアプリケーションという姿を捨てるべきでは無いのか？
ネイティブのアプリケーションだって、ウェブの技術を使っているのだ。HTML でアプリケーションの GUI を作ることではなく、そのようにウェブからのエンパワーメントを活かすことこそが、 “ The power of the Web ” なのではないか。
いや、あなたこの本のタイトルを忘れていませんか？『 Web アプリケーションアクセシビリティ』ですよ？、という的外れさは承知している。しかし長く複数プラットフォームでのネイティブアプリケーションの UI デザインについてやっていた立場から、どうしても私はそう考えてしまう。
そんな思いを一人、抱えていた時、この『Web アプリケーションアクセシビリティ』の 8 章のみを対象としたオンライン読書会を、私が参加している Design Book Club という読書会コミュニティにおいて開催する事となった。 Design Book Club は、デザインに関する集まりのように思えるネーミングだが、そんなものでは全然ない。576 ページある技術書の 1 つの章だけで読書会をやろうという、何ともマニアックな提案がすんなり受け入れられる自由闊達なコミュニティだ。
そしてこの読書会には、なんとこの本の著者や編集者まで参加していただける事になり、かつ、エスノメソドロジーの専門家の方やライターの方など、普段ウェブアクセシビリティに特別な馴染みのない人々も交えつつ、多種多様なテーマで盛り上がることとなった。どうしても組織論やプロセス論になってしまいがちなウェブアクセシビリティ談義において、それなりに画期的であったと思う。
まあ、発散的でまとまりがないともいうが、Design Book Club は、そのような目的論や因果律に陥らない対話を大切にしている（という事にしておこう）。
野球とサッカー
対話のテーマはどれも面白く興味深いものであったが、中でもある参加者の方の発言にあった、野球とサッカーの対比と、その例えがとても興味深かった。前述の私の思いとも一致するところがあり、実に言い得ていると感じたからだ。それはこういうものだ。
野球というスポーツは、ボールを起点に線形に展開され、ディフェンスとオフェンス切替も明確なモードの開始と終了として現れる。したがって、そのプレイについてテキストで線形に実況しやすい。だから野球は昔からラジオでの実況放送が大人気だし、ウェブサイト上の掲示板などでのテキスト実況も盛り上がるらしい。もちろん、野球においても同時多発的なプレイや駆け引きは存在するが、それを線形に記述しても、野球の野球性や、面白さは損なわれない。
一方でサッカーは広いコートの中で、ボールの周囲以外の場所においても 22 人それぞれが、それぞれの場所でサッカーをプレイしている。ディフェンスとオフェンスも次々に切り替わるし、プレイ中ボールがプレイヤーの体を離れる事も頻繁にあり、その線引きも曖昧だ。だからテキストによる線形の記述がとても難しい。ゲームの中心的な部分について抜き出して実況することは可能かもしれないが、それによってサッカーのサッカー性はスポイルされてしまう。実際、テキストでのサッカー実況は、野球ほど盛り上がらないのだという。
野球はテキストで線形に記述できる。一方、サッカーはそれが難しい。
野球とサッカーそれぞれに造詣が深い方には異論があるかもしれないが、これはあくまで、門外漢のする例えに過ぎないので、その点はご容赦いただきたい。単にその場に居合わせたもの同士の経験から、確かにそうであると盛り上がったという話だ。
そしてこの、野球とサッカーというスポーツの違いに例えるなら、HTMLで記述されるものは野球的であり、アプリケーションとは、サッカー的であるといえる。そして、線形にテキストで記述することができないアプリケーションの GUI を、線形に記述する HTMLで作るウェブアプリケーションというのはつまり、野球でサッカーをするようなものであるというわけだ。
野球でサッカーをやる
ウェブアプリケーションは野球でサッカーをやろうとしている。これはアクセシビリティ云々以前に、最初から筋が悪いということだ。全く素材に忠実とはいえない。HTML の素材に忠実たろうとするなら、ウェブサイトはまだしも、ウェブアプリケーションは無理をしすぎている。
では、素材にある程度忠実な、HTML ベースのアプリケーションとは、どういうものだろうか。サッカーボールで野球をやる、キックベースみたいなもの。線形に記述できるアプリケーションとは、ウィザードに代表されるような、いわゆるタスク指向 UI だろう。
やる事を一覧にして、首尾よく検索できるようにし、それぞれをウィザードにしてしまえば良い。ある意味モデルはシンプルになるし、できることも明白だ。当然シングルカラムで、1 画面に 1トピック、テキストも好きなだけ書けるだろう。そして読ませたい順に上から要素を構成すればいい。ウィザードとしての操作体系や構成も一貫する。複雑な手続きを、ただ質問に答えるだけでできてしまうようにもできるだろう。あとは、原理のうち「主導権はユーザーに」と「モードレスネス」を諦めればいい。
それならきっと誰でも決められたタスクを決められたように完了することができる。ユーザビリティテストでのタスク成功率も高くなりそうだ。ワークフローツールを使えば実装も容易で、最初からアクセシビリティ適合性も高い。現在の業務フローを聞いて、そのままウィザードにすれば良いから、リサーチもそれほど必要もないし、テストも楽だ。あとはなんか、かっこいいビジュアルとか、小粋なテキストを入れとけば良い。タスクを完了したら「お疲れ様でした」とかクラッカーと共に表示したらいい。完璧だ。そんなものはユーザーインターフェースではないという点を省けば。
そう、そんなものは GUI ではないのだ。
タスク指向 UI にすれば、アクセシビリティを楽に高められるわけではない。なぜ「主導権はユーザーに」と「モードレスネス」が「アクセシブルなデザインの原理」として挙げられているのかについてよく考えてほしい。複雑な GUI でユーザーが実現する様々を、無理やりいくつか抜き出して線形にして、それでウィザードを作ったとしても、それは GUI とは別物だ。作った人が予め考えて決めた事しか行えないし、創意工夫の余地もない。アクセシブルどころか、誰にとっても使い物にならないゴミみたいなものが出来上がってしまうだけだ。もしタスク指向 UI で、ウィザードみたいなもので事足りるというなら、そもそもそれは人間のやる仕事ではない。そのタスクは最初から、自動的に完了しているべきだ。マウスを使ってボタンをクリックできるようにすれば何でもアプリケーションの GUI になるわけではない。キックベースがサッカーボールを使っていてもサッカーではないのと同じように。
無論、ウェブアプリケーションも色々あるから、線形に記述できる簡易なもので、わざわざネイティブアプリケーションを制作する必要がない類のものもあるだろう。しかし例えば、業務で使うようなアプリケーションのように、道具として使う人に力を与えるようなものなのだとしたら、それがもし、サッカーなら、やはりサッカーをやるべきだ。
サッカーでサッカーをやる
サッカーでサッカーをやる、つまり、ウェブアプリケーションをやめて、ネイティブアプリケーションを作る場合、非常にパワフルな変化がある。それは何と言っても OS からの強力な支援だ。メニューバーもオーバーラッピングウインドウも、前提として最初からちゃんと用意されている。ブラウザの表示エリアの上とか下に苦労してよくわからないメニューエリアを固定したり、上に何かをのっけてゴニョゴニョしたりしなくてもいい。ブラウザのウインドウの外に出られるのだ。
そしてウェブ制作のそれと同じく、ネイティブアプリケーションにも、ネイティブアプリケーションとしての素材への忠誠がある。これについては、macOS のネイティブアプリケーション、CotEditor の開発者である @1024jp さんの美しい言葉をそのまま引用しよう。
美しいMacのアプリケーションを作ることをいつも考えてる。なぜなら美しいMacのアプリケーションは多くの人を救うことができるからだ。美しいMacのアプリケーションは日本語を話すことができて右から左に文章が書けて VoiceOver でコミュニケーションができてカンナダ語で10月を正しく描画することができる。空気のように誰もが使える。取り残さないとはそういうことだ。その美しいMacの力を正しく引き出せるかは開発者がいかに美しくアプリケーションを実装できるかにかかっている。私にはちょうどMacのアプリケーションを作るスキルセットが天から与えられているので、そこに到達できるはずである。私も美しいMacのアプリケーションで他人を助けたい。
やっぱカンナダ語が母国語の人からしたら10月も書けないエディタは見捨てられてると感じると思う。日本語話者が日本語入力に配慮していないアプリケーションに出会ったときにそう感じるように。
美しく実装するということは、例えばボタンひとつをサブクラスするときに、提供されされたAPIを適切に使って、異なる環境でもユーザが想定したように振る舞い続けることを保てるかにあると思う。コントラストを変えたとき特殊な入力デバイスを使ったときOSがアップグレードしたとき。ネイティブのフレームワークはそれはそれは思慮深く作られているので、美しさはすでに内包されているのだ。
https://x.com/1024jp/status/1704132732950048960
ウェブ制作者は、この美を超えるものを、ウェブアプリケーションで実現することができるだろうか。その HTML にアプリケーションとしての美は最初から入っているだろうか。
ウェブアプリケーションを実装したことがあるものは皆んな知っているだろう。ネイティブアプリの真似事をしようとすればするほど、苦労の割には上手くいかないし、ネイティブの動きには敵わず、OS のアップデートでそれも破壊されてしまうと。サッカーでサッカーをやってこそ、サッカーはサッカー性を持つのだ。そしてそれは、野球もまた同じである。
なぜウェブアプリケーションなのか
こんなにネイティブアプリケーションにアドバンテージがあるのにも関わらず、なぜウェブアプリケーションにこだわるのか。読書会では、このテーマでも対話があった。
言うまでもなく、ブラウザさえあれば一応あらゆる環境で使えるという点に圧倒的な優位性があるからだろう。アカウント登録は必要かもしれないが、アプリケーションをインストールする必要もない。
私自身もウェブアプリケーションの絵を描くときはよく、Figma を使っている。Figma は素晴らしいウェブアプリケーションだ。しかし macOS ネイティブなアプリケーションである Sketch の、まるで自分が拡張されたかのような使い心地には到底敵わない。慣れの問題ではなくその身体性において、 Sketch の方が脳に直結したようなスピードが出せる。けれどそうだとしても、 私は Figma を使う。Sketch は Windows で使えないからだ。私が Windows を使うことはまずないが、仕事の相手がそうとは限らない。Mac を持っていて、かつ有料のアプリケーションである Sketch を購入した人にしかそれを編集できないという状態では、やはり仕事がやりづらい。また Figma は、特にウェブアプリケーションの絵を描く場合、ウェブアプリケーションをウェブアプリケーションで描く、という意味においてある種の妥当性もあるだろう。
アクセシビリティの「アクセス」にも色々あるが、複数人での協働を支援するような場合、多様な環境で使用できるウェブアプリケーションの存在はやはり大きい。まして、決まったワークフローで書類を回覧するのではなく、みんなで同じ、一つのものを見て仕事をするというコラボレーションが盛んになってきた現代において、その優位性はますます発揮されていくことになるだろう。
もし世界中の人が Mac ユーザーになって、Apple ID をもち、Keynote や Freeform の共同編集を使えたら、ネイティブアプリの操作性を担保しつつコラボレーションを実現できるかもしれないが、私がどんなに Apple 好きであっても、あんな巨大資本が世界を独占してしまう事を手放しに賞賛したりはしない。
とはいえ、野球でサッカーをやっていることには変わりない。
そして私は、野球ではなくサッカーがやりたいし、デザイナーとしてもそういった身体性のある道具を作りたい。それぞれのアクセスの意味。分かるけれど、なんだかままならない。そんな気持ちで私は、読書会での対話を終えた。
ただ、一つ思ったのは、私は「みんなが」使えることは大切に思うけれど、「みんなで」使えることにはそれほど執着がないのかもしれない、ということだ。
わだかまり
良い対話というのは、心に消化しきれないわだかまりが残るものなのだと、誰かが言っていた。終わってスッキリするような時はむしろ、自分の意見を言って誰かを説得するような、対話とは程遠いものだった可能性もある。だから何か上手く言葉にできない、心に残ったこれはきっと良いものなのだろう。
そんな事を考えながら私は、オンラインミーティングのアプリケーションを落として、しばらくぼーっとしていた。いつの間にかスリープ状態になって、色鮮やかな背景にさまざまな国の言葉で「hello」というメッセージが描かれるスクリーンセーバーが動き出しても、私はそれをずっと見つめていた。
本来トレードオフにならないものが、ウェブアプリケーションの性質によって競合する。ウェブ制作者の多くが、ウェブアプリケーションにこだわるのは「みんなで」を重要視するからだ。
「みんなが」つかえることと、「みんなで」使えること。
— ああ、そういうことか。
私は唐突に合点がいき、新しいメンタルモデルを得た。
新しいアイデア
つまり、筆者が 8 章で掲げた「アクセシブルなデザインの原理」というのは、野球サッカー、つまり「野ッカー」※ みたいな新しい遊びをやろうぜ、というアイデアの提案だ。筆者にそういう意図があったかどうか分からないけれど。
野球にはしない、でもサッカーは目指さない。これは新しい遊びだ。
可能な限り線形にする、しかし不要なモードはできる限り排除して、ユーザーに主導権を持たせる。モードレスネスに。タスク指向 UI にはしない。だからといってネイティブアプリケーションの真似事もしない。本物には敵わないから。その分 “ 「みんなで」使える ” という、ネイティブアプリケーションにはない、ウェブアプリケーションならではのパワーを最大限に生かす。だから当然、支援技術を使って多くの人が使えるようにアクセシビリティを高く保つ。マルチペインよりもシングルカラムを優先することで、ランダムアクセスや直接操作という、GUI の GUI 性が失われたとしても、徹底的に「みんなで」を優先する方に振り切る。筆者にしか書けない、そのバランスで。
みんなで野球サッカーをやろう。そうすればそこでまた、今までにない新しいアイデアが生まれるかもしれない。この 11 の原理はそういった提案を、この 576 ページもの本を読もうとするような、意欲ある読者に向けて示しているのだ。それが筆者がこれまでの膨大な実践の中で直面した混沌（カオス）を、受け入れた先で現したもの。
そんな風に少し考えて、あらためて 8 章を読むと、その一つ一つの記述に込められた想いを感じ取れるような気がした。
この、『Web アプリケーションアクセシビリティ』の 8 章によって提示された野球サッカー、「野ッカー」という新しい観点。私たち読者、ウェブアプリケーションの制作者は、この新しいアイデアにチャレンジし、野球サッカーがプレイできる広場や道具を整備していこう。たくさんの実践の中で、そのアーキタイプを示しながら。
そして同時に、この「野ッカー」プレイヤーも増やしていく必要がある。さまざまな支援技術を使うことで、アクセスできるものを作っても、その技術を使える人が増えなければ、プレイヤーは増えない。「みんなで」はウェブアプリケーションをアクセシブルにするだけでは実現できない。
これは読書会でも筆者の伊原さんから言及があったが、何らかのディスアビリティのある人たちの、支援技術へのアクセシビリティも、さらに高めていく必要がある。アクセスとは、砂山のトンネルを両側から掘るようにして達成されるものなのだ。
さて、思いのほか長くなってしまったので、最後は 8 章に何度も登場したロックスター、上野さんのカッコいい言葉を引用して終わりにします。
新たな観点を獲得してもそのままでは人に伝搬しない。多くの人はそれを観る目を持たないから。言葉を尽くして詩を書けばいくらか伝搬する。それでもまだ多くの人は詩を聞く耳を持たない。仕方なくマニュアル化したりチェックリスト化したりする。すると急に複製されてみんなそれをいじくりだす。
しかしマニュアルやチェックリストはただの足跡にすぎない。獲物はもっと先にいる。獲物を捕らえるには足跡を追って森に分け入り自分の目と耳がそれの一部となるように自己を明け渡す必要がある。離散的なわかりやすさの向こうにある連続的なアイデアの生命と絡まり合う必要がある。
https://x.com/manabuueno/status/1600113294219436032
※ 最初「野球サッカー」という名称にしていたのですが、それだと「野球」と「サッカー」を並べただけで、新しい遊び感に欠けていると思っていたところ、＠manabuueno さんから「野ッカー」という名称を提案いただき、気に入ったのでタイトル含め「野ッカー」に変更しました。
この記事が気に入ったらサポートをしてみませんか？