- ソフトウェアの本質的な役割は、自分が解決すべき問題を明確に理解し、その限界を認識することにある
- 良いソフトウェアはすべての機能を盛り込もうとせず、改善が必要な部分だけを扱い、目的から逸脱しない
ls コマンドがAI機能に置き換えられる架空の事例を示し、既存ツールが不必要に拡張される現象を風刺- 37Signalsの 『Getting Real』 と 『Rework』 で示された原則を引用し、制約を強みに変え、不必要な機能要求を拒むべきだと強調
- AIブームの中でも、既存標準の安定性と明確な問題定義が新しい流行よりも大きな価値を持つことを思い起こさせる
ソフトウェアの役割と限界
- 記事は、Linuxディストリビューションを更新した後、
ls コマンドが AIベースのディレクトリ・インテリジェンス に変わってしまう想像上の場面から始まる
- 新しい
als コマンドはユーザーの意図を予測し、ファイルを順位付けし、従来の ls は30日後にサポート終了となるというメッセージを表示する
- この場面は、機能過剰と不要なイノベーションを風刺する例である
- 「幸いこのようなことは実際には起こらない」としつつ、良いソフトウェアは自分がいつ止まるべきかを知っていると強調する
良いソフトウェアの中核原則
- 良いソフトウェアは、自分がどんな目的を果たすのかを理解し、何でもやろうとはせず、いつ止まるかと何を改善するかを区別する
- 人間の**「最大主義的な思考様式」**には、あらゆるものをより大きく、より複雑にしようとする傾向がある
- しかしソフトウェアは、自分が属する役割と位置づけを明確に定義すべきであり、新しいアイデアが既存のビジョンに合わないなら別のプロジェクトとして切り分けるべきである
37Signalsの製品哲学
- Basecamp創業者たちが書いた 『Rework』 と 『Getting Real』 は、製品設計における重要な教訓を与えてくれる
- 制約は強みである (Constraints are advantages): 小さなチーム、限られた予算、限定されたスコープが、より良い意思決定を導く
- 機能リクエストを無視する (Ignore feature requests): ユーザーが求めた機能をそのまま実装するのではなく、根本的な問題を理解するアプローチが必要
- 早く出し、何度も出す (Ship early, ship often): 完璧でも公開されない製品より、不完全でも実際に動く製品のほうが価値がある
- エピセンター設計 (Epicenter design): ナビゲーションや周辺要素よりも、中核となるインターフェースと相互作用から設計する
- デフォルトで「ノー」と言う (Say no by default): 新機能には、複雑性、保守コスト、例外処理の増加という隠れたコストがある
- 自分が必要とするものを作る (Scratch your own itch): 自分が本当に必要とする問題を解決する製品のほうが、より良い意思決定ができる
変化より継続の価値
- 最近は多くの製品で、AIを中心に名称や機能を再構成する流れがある
- MinIO → AIStor
- Oracle Database → Oracle AI Database
- すべてが劇的に変わる必要はない
- 特定の問題領域でデファクトスタンダードとして定着することのほうが、より大きな価値を持つ
1件のコメント
Hacker Newsのコメント
「機能リクエストは無視しろ」という助言を見て、BlizzardとWorld of Warcraft Classic の事例を思い出した
長年ユーザーがクラシック版を求めていたが、Blizzardは「それは君たちの望むものではない」として拒んでいた
最終的にクラシックWoWをリリースし、圧倒的な成功を収めた
後になって開発陣は「ユーザーは本当に自分たちが欲しいものを分かっていた」と認めた
つまり、常に機能リクエストを無視するのではなく、ときにはユーザーが正しく言い当てている可能性も認めるべきだ
逆に無礼だったり自己中心的なユーザーだと、会話そのものが疲れるので対応しなくなる
結局のところ、教訓は、要望を出すなら礼儀正しくあるべきだということだ
そのうえで、それが有効な要求なのかを判断し、実装方法を考えるべきだ
根本的な問題は「本来の感覚を失ったゲーム」にあり、それを理解していれば、クラシック以外の方法でも解決できたはずだ
WoW Classicは「昔の雰囲気」を取り戻したいという表層的な欲求の表れだったが、その下には「信頼できない開発方針」への不信感があった
理想的な世界なら、両バージョンの長所を混ぜた完璧な形も可能かもしれないが、現実には意見の衝突で混乱が増すだけだろう
ユーザーの要望に従って非PVPインスタンスを追加したところ、緊張感が失われてゲームが平板になってしまった
この場合は、開発者のほうがユーザーよりよく分かっていたことになる
機能追加を止めた完成済みのソフトウェアがもっと増えるべきだと思う
「これで十分だ」と言える勇気が必要だ
EvernoteやDropboxのように、完璧だった時期のあとで 機能過多 によって混乱した例は多い
箱に入れて売られ、新しいバージョンが出たら新しい箱を買う仕組みだった
今のように絶えず更新されるWebアプリ以前の時代だった
むしろアップデートするほど悪くなることが多い
本当に改善される製品はごくわずかだ
結局、もともと解決しようとしていた問題をまた作り出してしまった
しかし時間が経つにつれてiOSのバージョン互換性が失われ、最終的には使えなくなった
完成の美しさと技術進化の残酷さを同時に感じた
2020年にインフラ担当から Java開発者 に転向したとき、主要ライブラリの多くがメンテナンスモードだったので、「Javaは死んだのか？」と思った
だが後になって、それは 機能的に完成した状態 だったのだと分かった
数多くのエッジケースが解決された安定した状態だったのだ
問題は、人々がそうした安定性を求めず、常に新しいものを欲しがることだ
結局、同じフレームワークを言語だけ変えて繰り返し作っている
そのため、開発が続いているプロジェクトを好む
また企業によっては、コンプライアンス要件 のために更新が続いているソフトウェアしか使えないこともある
「ただ完成していて、もう改善することがないだけだ」と冗談を言っていたが、結局は切り替えた
Sublime Text が好きな理由は、シンプルさと速さにある
AIや複雑な機能を入れず、一つの目的 に集中している
良いソフトウェアが必ずしも儲かるソフトウェアとは限らない
だが儲けるには、人々が実際に使う機能が必要だ
ユーザーごとに 異なる20%の機能 を使うので、多様性を考慮しなければならない
Notepad.exe は完成したソフトウェアの代表例だと思っていたが、
Windows 11でファイル関連付けを変えるには ハック同然の操作 が必要で驚いた
Windows Insiderブログと
セキュリティ通知を見ると、
止まることを知らないアップデートこそが問題だという
完成したソフトウェアの美しさ は認めるが、今では多くが「永遠のベータ」状態だ
インターネット接続が前提になったことで、「いつでも更新できる」という構造が生まれ、
バグ修正と望まれない機能追加が切り分けられていない
YouTubeのようなWebサービスではバージョンを選ぶことすらできない
特に Canvas機能 が追加されてから、本来のシンプルな哲学が揺らぎ始めた
オープンソースだったら、その時点でフォークしていたかもしれない
Signal は無料で、オープンソースで、プライバシー重視なので機能が少ない
だが、それがむしろ気に入っている
WhatsAppは不要な機能ばかり増やしている
37signalsの本で語られていた 「常に必要なもの（evergreen）」、特に 速さ の重要性を昔は分かっていなかった
だが時間が経つにつれ、アプリがどんどん遅くなるのを見て、速いソフトウェアの価値がどれほど大きいかに気づいた
Neal Stephensonの『REAMDE』に出てくる「作家は居場所を好む」という一節を思い出す
作家が居場所を維持するために仕事を作り続けるように、開発者にも 仕事を作るためにコードを変える傾向 がある
結局、私たちも 変化のための変化 を繰り返している