愛される製品の、製品哲学をまなぶ

[製品哲学のない製品と「緩やかに死んでいくシステム」を考える - Qiita](https://qiita.com/e99h2121/items/f9e074823923747d8fc1) の続きです。この記事では、[前回テキトーに当たりをつけた](https://qiita.com/e99h2121/items/f9e074823923747d8fc1#%E7%B7%A9%E3%82%84%E3%81%8B%E3%81%AA%E6%AD%BB%E3%81%AB%E3%81%A9%E3%81%86%E5%90%91%E3%81%8D%E5%90%88%E3%81%86%E3%81%8B) 製品哲学に学びます。
最初に結論だけ書いてしまうと、以下です。

- 時代とともに変わるものはある。
- 変わらないから愛されるものもある。

長く愛される製品とは――

![](https://media.giphy.com/media/l3nWhI38IWDofyDrW/giphy.gif) <iframe src="https://giphy.com/embed/l3nWhI38IWDofyDrW" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/thinking-l3nWhI38IWDofyDrW">via GIPHY</a></p>

## おさらい

[製品哲学のない製品と「緩やかに死んでいくシステム」を考える - Qiita](https://qiita.com/e99h2121/items/f9e074823923747d8fc1#%E7%B7%A9%E3%82%84%E3%81%8B%E3%81%AA%E6%AD%BB%E3%81%AB%E3%81%A9%E3%81%86%E5%90%91%E3%81%8D%E5%90%88%E3%81%86%E3%81%8B) では以下のように考えました。
> もちろん製品もいつか死ぬ、沈むものかもしれないと考えます。とはいえ長く続くものに理由はあるとも思います。

## 製品の終焉・変遷の例

### 例: iPod

つい最近、iPod touch終了のお知らせの記事を読みました。
私が社会人になった2003年だとかの頃、音楽通の同期 (今も同僚) が喜々としてiPod初期世代版を持っていて、「へ～～～」と思った記憶があります。その頃音楽はストリーミングで楽しむというよりは、溜め込んで持ち歩きたい、それが嬉しいものだったのだと思っています。

[Apple、iPod touchの販売を終了へ　約20年の歴史に幕 - ITmedia Mobile](https://www.itmedia.co.jp/mobile/articles/2205/11/news070.html)
[[B! Apple] Apple、iPod touchの販売を終了へ　約20年の歴史に幕](https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/mobile/articles/2205/11/news070.html)
[Apple's iPod Touch Is Discontinued, Ending the Music Player's Legacy - CNET](https://www.cnet.com/tech/mobile/apples-ipod-touch-is-discontinued-ending-the-music-players-legacy/)
[Apple to discontinue the iPod after 21 years - BBC News](https://www.bbc.com/news/technology-61401626)

> Carolina Milanesi from Creative Strategies said the decline of iPod sales was connected to the rise of iPhone sales - like the move from digital sales to streaming.

> iPodの売上減少がiPhoneの売上増加と関係していると述べた。デジタル販売からストリーミングへの移行がそうであるように。

[緩やかに死んでいくシステム / You won't be in the team forever - Speaker Deck](https://speakerdeck.com/toricls/you-wont-be-in-the-team-forever) でも以下のように書かれていました。

>「なぜシステムを改善していくのか」

> 実装当時に最適解と考えられたものが、時間の経過とともに最適とは評価され得なくなるから

時間の経過とともに、音楽は溜め込むのではなくいつでも好きなものだけにアクセスできれば良い、それが最適解になったのだと解釈しています。それはオンプレ時代のソフトウェアの最適解がSaaS時代に果たしてどうなるのかという問いでもあるでしょう。

### 例: Slack

[既読機能を搭載しないSlack - リアクションこそが読んだ証拠 - Qiita](https://qiita.com/e99h2121/items/40e7eea415faa53614c4) にて、Slackが「既読機能」を頑なに搭載しない理由を調べたことがあります。

一方で [テレワーク支えるSlackに｢既読表示・予約投稿がない｣理由。共同創設者が語る日本市場 | Business Insider Japan](https://www.businessinsider.jp/post-208559) という記事があります。「予約投稿」という機能は、以前は搭載されていなかったが、待ち望まれて搭載に至ったケースのようです。以下課題感

> 予約投稿については｢いつでも送信できる、受け手は通知をオフにできるというSlackの強みに対して本当に必要か｣という課題があるという。

しかしその後、2021年にSlackは予約投稿機能を搭載したという経緯のようです。
[Slackの予約投稿機能とは? 予約や確認の方法をわかりやすく解説 | マイナビニュース](https://news.mynavi.jp/article/20220218-2250341/)
[Slack is rolling out a new scheduled send feature - The Verge](https://www.theverge.com/2021/6/16/22535774/slack-scheduled-send-feature-new-messages)

> Today we launched Scheduled Send to empower users to communicate and collaborate in a way that works best for them,” the company announced in a statement, explaining that “teams shouldn’t be obligated to sync their schedules in order to communicate effectively.”

> The ability to schedule messages is a critical one given the various time zones and locations that offices — both remote, in-person, and hybrid — stretch across in today’s work world. And while email services like Gmail have offered the ability to schedule emails for later (so that users aren’t pinging teams at odd hours or getting messages lost overnight), the feature has been notably absent from Slack until now.

> 本日、ユーザーが自分に合った方法でコミュニケーションやコラボレーションを行えるようにするため、Scheduled Sendを発表しました」とし、**「チームが効果的にコミュニケーションを行うために、スケジュールを同期させる義務はないはずです」と説明しています。**

> **今日の仕事の世界では、リモート、対面、ハイブリッドなど、さまざまな時間帯や場所をまたぐオフィスがあるため、メッセージをスケジュール化する機能は非常に重要なものです。** Gmailのようなメールサービスでは、メールを後日送信するようにスケジュールする機能がありますが、Slackにはこれまでこの機能がありませんでした。

### 例: ドラえもん

[ドラえもん (2005年のテレビアニメ) - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A9%E3%81%88%E3%82%82%E3%82%93_(2005%E5%B9%B4%E3%81%AE%E3%83%86%E3%83%AC%E3%83%93%E3%82%A2%E3%83%8B%E3%83%A1))
ここで唐突にですがテレビアニメの「ドラえもん」もそうです。声優たちや主題歌を一新させることをやってのけたほか、少しずつ子どもたちのために、表現方法を変えている。

> のび太たちは月見台小学校5年3組の設定。ドラえもんやのび太らは東京都練馬区月見台という下町に住んでいるという設定であり、原作および前シリーズでは町の中に「ドブ川」と呼ばれるほど汚れた川が流れていたのに対し、本作では緑あふれる散歩道の中に自然のままの小川も流れている。また、町のシンボルでもある「うら山」は、前シリーズでは町のど真ん中に位置し、周りを交通量の多い車道に囲まれていたが、本作では周囲をのどかな田園地帯が囲んでいる。

### 例: おかあさんといっしょ

同様「おかあさんといっしょ」なども今の時代に「おかあさん」？等と言われてしまいそうなところ、人形劇の物語づくりでしっかり変化に対応していたりするのです。この「ガラピコぷ～」の「チョロミー」というウサギの女の子キャラクターは科学者になりました。

[【ネタバレあり】Eテレ「ガラピコぷ～」、最終回直前の神展開にネット騒然　ガラピコ誕生の秘密に「衝撃的で感動」の声（1/2 ページ） - ねとらぼ](https://nlab.itmedia.co.jp/nl/articles/2203/30/news090.html)



## 一方、変わらない例

変わるものがあれば、変わらない例もあります。

### 例: UNIX

[「UNIXという考え方」を読んで、その共感したポイント - Qiita](https://qiita.com/e99h2121/items/10e80990f68031e58b97)

> - **スモール・イズ・ビューティフル（小さいものは美しい）**
> - 一つのプログラムには一つのことをうまくやらせる
> - できるだけ早く試作する
> - 効率性よりも移植性を優先する
> - 数値データはASCIIフラットファイルに保存する
> - ソフトウェアを梃子(てこ)として使う
> - シェルスクリプトによって梃子の効果と移植性を高める
> - 過度の対話的インターフェースを避ける
> - すべてのプログラムをフィルタとして設計する

ファイルをコピーするプログラムを例にして説明しています。コピー元からコピー先へ、ファイルの内容をコピーする処理（目的の処理）の前後には、ファイルの存在有無のチェックなどの処理が必要。しかしそれらは他の小さなプログラムに任せるべきといいます。実例として、ファイルの存在有無に `test` コマンドが使われる点を挙げています。

小さなプログラムのメリットは、わかりやすい、保守しやすい、システムリソースにやさしい、他のプログラムと組み合わせやすい、となるよう。


### 例: 秀丸

[「惰性でやっている」「ビジョンはない」 30年続くソフトウェア稼業「秀丸」がいまも最前線に立ち続ける理由 | Coral Capital](https://coralcap.co/2022/05/hidemaru-01/)

> 秀丸の値段、なんと最初の発売時から変わっていない

> 実は1回だけ、ホームページのデザインを変えようと思ったことはあるんですけれども、やっぱり僕らはそういうことがあまり得意じゃないので、結局そのままです。

> スマホ向けに直したほうがいいという話もあがったんですけど、直すのは大変だな、と。あとは外国からアクセスした場合は英語で出るように、みたいなことも少しやってみましたが、途中で挫折したままですね。

そして称賛の声: [[B! ソフトウェア] 「惰性でやっている」「ビジョンはない」 30年続くソフトウェア稼業「秀丸」がいまも最前線に立ち続ける理由 | Coral Capital](https://b.hatena.ne.jp/entry/s/coralcap.co/2022/05/hidemaru-01/)
[技術的盆栽 - ぱろすけのブログ](https://parosky.hatenablog.com/entry/2022/05/11/213645) などというお話もあるが、この記事を読んで思い出したのが [(3517) 中川家の寄席2021「中小企業のCM」 - YouTube](https://www.youtube.com/watch?v=hQm-Kxw5PV4) です。中小企業？いやいや、こんな中小企業素敵じゃないですか、など。

### 例: 阿部寛のホームページ

変わらない例として「阿部寛のホームページ」も記載しておきます。以下参考記事。

[海外のガチHTMLコーダーに阿部寛のホームページを見てもらった - Qiita](https://qiita.com/NagayamaToshiaki/items/b56380aecf55803f52a5)
[「阿部寛のホームページ」はHTML界のシーラカンスである - Qiita](https://qiita.com/NagayamaToshiaki/items/dd36acb2658220c04b94)
[阿部寛のホームページ的開発エッセンス - Qiita](https://qiita.com/e99h2121/items/d547934df764e206d930)
[なぜ阿部寛のホームページはベストを尽くさないのか。 - Qiita](https://qiita.com/mackey0022/items/0258ceddc7acd8626332)

> 今時、ベストを尽くせばどれだけでもオシャレでカッコいいサイトを作る事は出来ます。
> それは、お金の問題ではありません。Wixなどで作ることだって可能です。

> でも、阿部寛のホームページはそうしないんです。
> それは今時のサイト構成がユーザーにとってベストとは限らないからです。

変わらないとはもちろん、メンテナンスしないというわけではなく、画像を微修正などはしており、IPv6対応なども済ませている。[阿部寛のホームページ - Wikipedia](https://ja.wikipedia.org/wiki/%E9%98%BF%E9%83%A8%E5%AF%9B%E3%81%AE%E3%83%9B%E3%83%BC%E3%83%A0%E3%83%9A%E3%83%BC%E3%82%B8)


## まとめ

> - 時代とともに変わることはある。
> - 変わらないから愛されるものもある。

ドラえもん、あるいは阿部寛。変えないことが悪いのではない。変わることが悪いのでもない。大事なのは、**開発者自身が、何故変えるのか、なぜ変えないのかを、説明できること。** 製品の理由と目的を、中の人である開発者が意思を持って語れること。それが愛される製品の条件なのではないでしょうか、とおもいました。

![](https://media.giphy.com/media/Ky53ckyw4Y6JnZeMXP/giphy.gif)
<iframe src="https://giphy.com/embed/Ky53ckyw4Y6JnZeMXP" width="480" height="270" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/heyduggee-Ky53ckyw4Y6JnZeMXP">via GIPHY</a></p>

関連: [製品哲学の言語化にいどむ。「カタログ」概論 - Qiita](https://qiita.com/e99h2121/items/2e992ba08be2ad324124)
ソフトウェア製品も20年なんていう時が流れたら、開発者自身も移り変わる、時代も移り変わるのではないだろうか。[製品哲学のない製品と「緩やかに死んでいくシステム」を考える - Qiita](https://qiita.com/e99h2121/items/f9e074823923747d8fc1) と合わせて次回は、製品哲学を「蒸留」するコツのようなものを紐解きたいと思います。

以上お楽しみいただければさいわいです。