柔軟なソフトウェア：ロックダウンされたアプリの世界でユーザーの主体性を取り戻す (2025)

モチベーション 私たちは自身の環境を適応させたい 環境は重要です。最高の仕事をし、最高の人生を送るためには、私たち一人ひとりのユニークな可能性を表現できる空間が必要です。ギター職人は、ノコギリ、ハンマー、ノミ、ヤスリをちょうど良い配置で作業場にセットアップします。また、最良の結果を得るために必要に応じて新しいツールを構築することもできます――例えば、ブロックを支えにする、あるいはペンチを適切な形に削るなどです。長年かけて、家庭料理の達人は、ナイフ、まな板、鍋やフライパンの組み合わせを徐々に集め、自分に合ったものを見つけます。彼らは天井にフックを取り付けたり、棚を移動させたりして、ワークフローをサポートできます――それが平日の夕食作りであれ、手の込んだ週末のバーベキューであれ。 これらは日常的な状況です。物理世界では、私たちの環境を工夫する行為は自然に行われます。なぜなら、物理的な現実は柔軟だからです。壁にポストイットを貼る、引き出しを整理する、家具を移動するなど、多くの小さな調整は、誰かの許可を求めることなく瞬時に行うことができます。また、より多くの労力とスキルを必要とする、ワークショップを建設したりキッチンを改装したりするような、より大きな変更に取り組むこともできます。そして、私たち自身にそれらのスキルがない場合でも、地域社会の職人に協力を求めることができます。私たちが管理する物理的な空間で働き、生活するとき、私たちはその空間を自分たちのニーズに合わせて進化させる傾向があります。Stewart Brandが著書『How Buildings Learn』で書いているように、「建物を愛されるものにするのは、経年と適応性の組み合わせです。建物は居住者から学び、居住者は建物から学びます。」 大量生産されたソフトウェアは硬直的すぎる 最近では、私たちはますます多くの時間を、原子ではなくコードから作られた環境で過ごしています。この変化で多くの能力を獲得しました――大陸を越えて瞬時に共同作業ができ、数千のファイルを瞬時に検索できます。しかし、重要な何かを失ってもいます。それは、私たちの環境を適応させ、それを自分たちのものにする能力です。 例を挙げましょう。著者のうちの一人が、壁に貼られたインデックスカードで作業を追跡していたソフトウェアチームで働いていました。チームは常にトラッカーを進化させていました――線のテープは移動し、チェックリストが現れ、メイングリッドの周りにカードの特別なゾーンが出現しました。ツールの流動性は、プロセスの流動性を促進しました。インデックスカードの壁は、ソフトウェア開発を管理するための柔軟な媒体でした。後に、チームはリモートの共同作業者をサポートするためにウェブベースの課題トラッカーに切り替えました。すると、特別なカードゾーンをモデル化したり表示したりする方法がなくなり、チームはそのプロセスの部分を断念しました。さらなるプロセス変更も停滞しました。以前は、新しいアイデアを試すのに数分で済みましたが、今では設定をいじるのに数時間かかることもありました。もし可能であってもです。仕事のコンピュータ化は、主体性の喪失につながりました。 ソフトウェアの硬直性は単なる些細な不便ではありません。それは、重要な仕事をしている人々を深刻に妨げる可能性があります。医師であり作家でもあるAtul Gawandeは、医療分野でのコンピュータ化が記録的なレベルの燃え尽き症候群につながっていると書いています。例えば、医師はかつて紙のフォームに記入する際に無関係なフィールドをスキップしていましたが、今ではソフトウェアがそれらのフィールドをすべて記入することを強制し、彼らはそのソフトウェアのルールを編集する力を持っていません。Gawandeが医師の一人について語るように、「追加の時間を費やすことは彼女を怒らせませんでした。その無意味さが彼女を怒らせたのです。」柔軟性のない電子カルテシステムは、医師を燃え尽き症候群に追い込んでいます。 ソフトウェアがニーズを満たさない状況に直面した場合、開発者にフィードバックを提供しようとするかもしれませんが、それは通常、即時の行動につながりません。異なるユーザーが異なるニーズを持っている場合、中央集権的な開発チームはすべての人の問題を解決することは不可能です。さらに、開発者が単一の製品にあまりにも多くのソリューションを詰め込もうとすると、結果は肥大化した混乱になります。この落とし穴を避けるために、優れた製品チームはほとんどのユーザーリクエストを断ることを学び、ニッチなニーズの長いテールを未対応のままにします。 私たちの特定の要件がソフトウェアによって満たされないのは避けられないように思えるかもしれませんが、それはソフトウェアが中央集権的な開発チームによって制御されていることを当然のことと考えているためだけです。もし、自分たちのニーズを最もよく知っているユーザーに、より多くのコントロールを移したらどうなるでしょうか？ Gawandeは、ある神経外科医がITアナリストと協力して、彼らの部署の医療記録システムを適応させた話を紹介しています。「すぐに、彼らは神経外科の外来診療のために特別に設計された、より高速で直感的なインターフェースを構築しました。」要件は、国中のすべての医師のニーズではなく、彼らの特定の部署のニーズによって駆動されました。直接的な生産性の向上に加えて、医師たちは自分たちのツールによりコントロールされていると感じました――燃え尽き症候群の解毒剤です。 この話は感動的ですが、例外的なケースです。なぜなら、ソフトウェアを展開するために使用されるツールとインフラストラクチャは、ユーザーを能動的な共同作成者ではなく、受動的な受容者として扱っているからです。ソフトウェアは、柔軟で再構成可能なツールキットではなく、モノリシックなアプリケーションとして編成されています。カスタマイズにはほとんどの人が持っていないプログラミングスキルが必要であり、さらに、ほとんどのソフトウェアはソースが公開されていません。ソフトウェアは、ユーザーがソフトウェアを編集するためのツールなしで出荷されます。アプリストアは、企業が消費者にソフトウェアを配布するためのものであり、アマチュアが友人とツールを共有するためではありません。これは、小規模な職人技ではなく、産業的な大量生産のシステムです。 公平を期すために言えば、大量生産されたソフトウェアは多くの利点をもたらしました。私たちは、合理的な価格で、膨大な数の洗練されたアプリケーションにアクセスできます。ソフトウェアは、信頼性、アクセシビリティ、セキュリティの面で進歩しました。開発者は、継続的に改善されたソフトウェアを提供するチームに持続的に支払いを行うビジネスモデルを作成しました。しかし、これらの話や数え切れないほどの他の例が示すように、柔軟性のない大量生産されたソフトウェアは、邪魔にもなります。平均的なユーザーからあなたがどれだけ異なっているかによって、カスタマイズの利点はプロフェッショナルな洗練の利点を上回ります。誰もが何らかの形でユニークです――おそらく、執筆、音楽制作、議論、プロジェクト計画のためのツールについて強い意見を持っているでしょう。特定のニーズがある場合、主体性は重要です。 私たちの目標：柔軟なソフトウェア 私たちは、ユーザーに共同作成者としての主体性を与える新しい種類のコンピューティングエコシステムを構想しています。私たちはこのアイデアを「柔軟なソフトウェア」と呼んでいます――誰でも最小限の摩擦で自分のニーズに合わせてツールを適応させることができるソフトウェアエコシステムです。「ソフトウェアエコシステム」とは、ソフトウェアとそのユーザーを取り巻く広範な技術的および文化的環境を意味します。柔軟性とは狭い技術的問題ではありません。「誰でも」とは、広範なアクセシビリティが目標であることを意味します。そして、個人の自立を育むことは有用ですが、地域社会との協力も同様に価値があります。私たちが「ツールを適応させる」と言うとき、既存のソフトウェアの小さな調整から、深い改修、既存のツールと連携してうまく機能する新しいツールの作成まで、あらゆる範囲のカスタマイズを含みます。適応とは、ゼロからやり直すことを意味しません。最後に、「最小限の摩擦」が鍵です。ツールの編集は迅速であるべきです。軽く感じるべきです。最良の場合、それは必要が生じた瞬間にできることであり、そうすれば私たちは手元のタスクに戻ることができます。 既存のアプローチ 設定やプラグインについてはどうですか？と疑問に思うかもしれません。ソフトウェアの動作を変更するための多くの技術が存在し、それらは称賛されるべきものです。しかし、それらには、私たちが掲げた目標を完全に達成することを妨げる限界もあります。 設定 設定は、アプリケーションの動作を変更する一般的な方法です。適切な設定が存在する場合、チェックボックスを切り替えるだけで、その日の作業を続けることができます。しかし、設定はアプリケーション開発者が公開することを考えたコントロールしか提供しないため、目的の機能を行う設定がない場合、あなたは行き詰まります。設定はまた、それらを結びつける一貫したメンタルモデルを持たない、ばらばらのチェックボックスの長いリストになりがちです。設定は、アプリケーション開発者によって事前に選択された特定のカスタマイズを可能にします。 プラグイン 中央集権的な開発チームの帯域幅を超えてスケールアップする一つの方法です。